为了能够理解Atlas,我们先来看看元数据和数据治理。
一.元数据
元数据就是描述数据的数据。如果是用java编程来说:
public class Customer {
private String id;
private String name;
private String address;
private String ID;
public Customer(String id, String name, String address, String ID) {
this.id = id;
this.name = name;
this.address = address;
this.ID = ID;
}
}
这里的Customer 就是元数据的集合,而类的属性就是元数据,用来描述数据是什么的问题。
二.元数据和数据
如果一条数据采用如下表示的时候:
1001 张三 深圳南山区高新南四道20号 123456789100123456
这条数据并没有任何含义,我们也不清楚该条数据所要表达的内容,但当我们换成如下的方式:
编号 姓名 地址 身份证
1001 张三 深圳南山区高新南四道20号 123456789100123456
使用编号,姓名,地址,身份证来描述1001 张三 深圳南山区高新南四道20号 123456789100123456。这条数据就有了具体的含义,让我们获取到"编号1001的人的名字是张三,地址在深圳南山区高新南四道20号,身份证号123456789100123456"这样的信息。这里类似与java代码中的Customer zhangsan = new Customer('1001','张三','深圳南山区高新南四道20号','123456789100123456'); 是一个对象。简单的总结就是当我们使用元数据+数据就形成了信息。
三.数据治理
数据不会无缘无故的产生,也不会自己表述其具有的含义,更不会自己管理自己,所以我们才会有数据治理。如果用数据库的表设计来说明的话,我们大概分为三个部分,分别如下:
1.概念设计,主要用来描述业务对象或者业务关系
2.逻辑模型,通常指ER图来描述概念设计的模型
3.物理模型,用来存储ER图实际的物理结构,包括存储结构和存储方法。
按照元数据的功能来划分:1是业务元数据;2和3属于技术元数据;还有一个是操作元数据,主要就是描述数据是怎么产生,如DB的日志,数据使用的时候安全,审计,血缘等信息。数据治理实际就是在管理业务元数据,技术元数据,操作元数据这三方面的内容。那么Atlas的数据治理,有提供了那些核心功能了?
1.Atlas认为数据治理有如下类型:
可以看出其包括了数据装载名称,数据库名称和权限拥有者,表名称,视图名称,字段名称,还有数据访问方式,维度,度量,ETL这些分类特性等内容。
2.Atlas提供的核心功能如下图:
从上往下,我们看到的是搜索,血缘,交换,知识存储,审计,数据生命周期,访问控制和策略。
2.1搜索:这里是指搜索对应的元数据,如下图所示:
能够方便的让我们了解有什么数据。
2.2血缘:从数据产生,如ETL的过程,到数据的存储,再到数据的使用。能够方便的让我们定位数据问题,是上游ETL,或者下游数据报表发生数据变化。
2.3.交换:和已有的元数据做对接,比如已经在SAS,BIEE中已经建好的元数据,可以直接导入到Atlas中,或者将Atlas中已有的元数据导出到其他。
2.4.知识存储:数据存储中,Atlas会根据自己的分类,策略规则,类型约束,或者元模型自动的进行存储。例如如下类型的数据:
customer_id order_id product_id time_id sales
Atlas将sales分类为度量Metric。或者如下类型的数据:
customer_id name address
Atlas将address分类为PII(Personally Identifiable Information,个人验证信息),这里也是对外提供Rest Api服务的时候涉及的数据标准。另外自己感觉这里的知识存储和DIKW中的K相似,都是让我们知道这些数据如何去使用。
2.5.审计:审计是出于数据安全,隐私,或者法律政策。什么数据应该存,或者怎么存都会有一定的要求或者标准。例如如下类型的数据:
customer_id name phone_num address ID
很显然phone_num,address,ID属于敏感信息,是受隐私保护的。只可惜在中国对数据安全大家都不重视,比如在淘宝购买了商品,然后骗子获取到了你未做敏感信息处理的订单信息和身份信息,然后对你实施诈骗。
2.6.数据生命周期:数据是有时效性的,最简单的例子就是如果你设计数据中心为3年的话,到第四年开始,在第一年进入数据中心的数据就可以转做进线存储或者离线存储,即第一年的数据在这个数据中心的生命周期结束。更别说数据库查询中的临时表,临时为了某个业务场景验证,做开发和测试,完成后就直接删了,这种数据生命周期更短。
2.7.标签策略:最简单的标签就是将元数据的分类,如元数据属于Metric,ETL。或者接6所说的,数据是有时效性的。例如市场部门往往关注今天有多少订单产生,然后偶尔关注这个月产生了多少订单,越往前的数据,使用频率和访问频率越底。这里就可以对数据使用热度标签。
2.8.安全:也就是Atlas中的基于标签的访问控制,最简单的标签就是允许和不允许。数据应该只被该访问的人访问,如果一个用户是报表用户,那他就只能访问那些report的数据,而不会是其他数据,更别说不具有数据访问权限的用户。
上面只是简单的介绍了Atlas是什么和具有的功能,我们来看个简单的例子,业务人员想要了解“2015年12月1日广东的空调销售额是多少”,可以解析为如下内容:
a.时间:2015年12月1日(时间维度)
b.地区:广东(地理维度)
c.产品:空调 (产品维度)
d.指标:销售额
最终的数据类型呈现如下表示:
time address product sales
2015年12月1日 广东 空调 xxx,xxx.xx元
那我们应该如何去实现?大概过程如下:1.查询2015年12月1日所有的订单 --> 2.过滤出其中客户地址是广东的订单 --> 3.对这些订单的销售额进行求和。可是要完成这个报告接着发现有这些问题:订单数据从那里来,怎么获取,获取后存储到那里?实现过程大概如下:1.发现我们需要客户表,产品表,订单表的数据 --> 2.发现这3张表保存在销售数据库 --> 3.采用ETL,将数据加载到报表数据库 --> 4.产生数据报告,结论。在这个过程中会涉及如下图所示的元数据:
说明:这里对sales_fact中的时间字段做了规范化设计,所以产生了时间维度表time_dim。
1.是表或者视图名称;
2.是字段名称;
3.是分类特性;
4.是装载名称;
5.是数据库名称和元数据存储。
Atlas采用Text File或者ORC File的方式,简单表述如下图所示:
可以看出,Atlas只是对元数据层进行操作,并不会直接操作到数据层。比如上面中的客户表,可能有手机号,身份证号等字段,但是在"2015年12月1日广东的空调销售额是多少"这个业务中没有任何作用,所以不会管理这两个字段,或者初始设计的时候管理了这两个字段,然后发现没有使用到的时候可以进行del操作。注意,这里的del不涉及到数据层,不同于navicat连接的mysql,直接操作的数据层,把表的列给删除,只是删除了元数据层。
从上面的例子就可以看出数据治理的好处:
1.数据整合:如果没有元数据,你不可能把客户表,订单表的数据整合在一起,从而发现更多的数据价值;
2.数据追朔:报表数据库中的客户表的数据来源是否是销售数据库的客户表数据;
其他还有数据质量,有助于数据理解,数据重用等。