极光笔记 | 极光基于元数据驱动数据治理浅谈

作者：极光数据平台部  计算平台组经理 ——蔡祖光

前言
 

极光大数据平台目前支撑着公司开发者、广告、金融风控、行业洞察、公共安全在内的核心业务的数据生产活动,随着公司业务体量的增长,数据平台的规模也在不断扩大,其中调度任务数量每年增长30%、数据表每年增长40%.数据平台的数据治理工作从成本、SLA、安全、质量等多个方面面临着巨大挑战。

在这个过程中极光数据平台在具体的技术优化手段、相关的理论方法等方面都积累了一些落地可行的数据治理经验，今天这篇文章主要分享一下在极光数据治理过程中,对于元数据起到的作用的一些思考和经验总结，本文包括以下方面内容：

• 元数据的采集

• 元数仓的加工和建设

• 元数据的服务应用

• 基于元数据分析的数据治理规则

• 元数据的开放与数据治理共建

01元数据的采集

---

不同类型数据的采集

基于元数据驱动的数据治理,首先要从元数据的收集开始讲起,参考DAMA对于元数据类型的定义,元数据可以分为业务元数据、技术元数据和操作元数据,三者在元数据的使用上区别不大,主要是从元数据的采集,也就是数据来源上进行划分的。

业务元数据的采集方面,目前极光元数据平台对于增量的数据模型,主要通过体系化建模规范进行约束,在数据建模阶段进行卡点采集,对于存量的历史数据模型,主要是依托于第三节会介绍到的数据地图,人工手动录入的方式进行采集。

 

在技术元数据和操作元数据方面,自动化采集的方式会更多一些,极光目前这部分元数据的主要来源是数据平台的组件和数据系统,组件方面有HDFS、Hive、Yarn、Spark、Flink、Hbase等来源, 数据系统方面有调度系统、数据质量监控系统、数据开发系统等来源。

对于数据采集的手段、频次、粒度,根据不同的组件和系统的实际情况而定,可以是被动拉取、可以是主动推送,可以是定时、可以是实时,但是核心的要点就是在条件允许的情况下,尽可能多的去采集元数据字段,收集尽量多的信息,因为只有更多的维度、更多的事实才能在后面的元数据使用上挖掘更多有价值的信息,包括我们这篇文章要聊到的数据治理工作也是以此为基础的不断去丰富上层应用的，当然，实际的执行过程中还是需要数据产品经理或项目经理提前规划元数据需求，按正常流程去开展工作。

下面列一些采集案例的部分信息

• 离线任务: Spark、Hive、MR的applicationid、耗时、cpu/内存计算时、读写表、开始结束时间等

• 实时任务: Flink的applicationid、cpu/内存计算时、上下游数据源、任务重启次数、资源利用等

• 离线存储: HDFS、Hive的文件目录名称、表名称、空间大小、创建读写时间、文件大小等

• 在线存储: Hbase、Kafka的表名、topic名、流量大小、空间大小、读写用户、读写明细等

• 数据系统: 调度系统、质量系统、数据API的调用频率、成功失败明细、质量检测异常明细等

 

采集效果的度量

元数据的采集是后面一切治理工作的前提，元数据质量的好坏直接影响后面工作的效果，所以如何去衡量元数据的质量，以及通过什么方式指导我们发现问题、优化问题是我们一直在思考的事情，目前极光在这方面主要定义了三个北极星指标来辅助解决这类问题，分别是组件系统接入率、血缘关系覆盖率、元数据信息完善度，由于本文主要是分享数据治理方面的内容，关于这三个北极星指标的具体应用我们放在极光元数据系统的分享时再具体说明。

02元数仓的加工和建设

---

在完成了相关元数据的采集以后，我们需要把这些采集好的元数据进行统一的存储和维护，确保元数据的版本、定义、关联关系,为此我们需要像加工业务数据一样,建立一个属于元数据的数仓,更好的去进行元数据管理和分析,提升元数据的易用性、可扩展性。

在极光我们按照标准的数仓建设方式对元数仓进行了数据分层和主题域划分,目前对现有的元数据我们划分出了7大主题域,确保一致性维度,对大部分常见维度进行统一的业务含义定义,防止由于前期定义模糊导致的分析结果有出入,例如,部门维度中的事业线、产品线含义,成本维度中资源高峰期的定义。

下面对元数仓中的7个主题域进行展开说明,这7个主题域分别是计算域、存储域、流量域、安全域、质量域、成本域、模型域:

 

计算域

计算域内主要收集的是和计算过程相关的数据,比如SQL脚本、Jar包程序的执行,在这个主题域中可以查看到和计算相关任何明细信息,例如,某个表读写的SQL、SQL的执行耗时、CPU/内存消耗明细、读写的分区和字段信息、底层的计算引擎、存在数据倾斜的stage、IO读写的时长等相关信息。

计算域的数据经常被用在计算资源消耗的分析、隐患问题的排查,还有成本分摊上。

 

存储域

存储域内主要收集的是和存储过程相关的数据,目前所有基于HDFS存储的系统组件信息,Kafka存储的元数据都可以在这个主题域下查到,例如,某个文件的大小、最近访问时间、副本数、block数,某个Hive表、Hbase表的大小、文件数量、读写时间、文件格式,某个目录的quota大小等。

后续我们会把极光自建的分布式缓存系统Jcache的存储信息和数据湖组件的元数据信息都同步更新到这个主题域下。

存储域下的数据经常被用在基于表粒度、部门粒度的存储增长情况分析、小文件分析上,以及成本分摊。

 

流量域

流量域内主要收集的是像消息队列、在线查询等跟流量相关的数据,当前Kafka的流量信息、极光自建在线数据服务平台ODS的流量信息都归属在这一主题域下,例如,Kafka单位时间内的records、bytes,写入和读取的上下游、CPU和内存的负载等。

流量域下的数据经常被用在Kafka容量评估,流量成本核算等方面。

 

安全域

安全域内主要收集的是数据权限、数据资产分级分类等过程的数据,目前在数据权限层面主要是通过Kerberos+Ranger的方式进行权限管理,相关的权限明细数据都会同步到这个主题域下,并且对于每个数据表字段都会进行安全类别、安全等级的打标。

安全域下的数据经常被应用在对数据安全治理活动的状态跟踪和问题评估上。

 

质量域

质量域内主要收集的是任务的SLA、数据质量检测等过程的数据,目前任务调度平台的执行明细、数据质量检测平台的检测明细都会同步到这个主题域下,例如,调度的执行周期,上下游依赖,每个Job执行的开始结束时间、最终状态、异常重试情况,数据质量的检测目标、检测出有问题的执行记录、每个质量检测指标每次执行的具体结果等。

质量域下的数据经常被应用在对产品线稳定性、数据可靠性等治理问题的分析上.由于数据质量检测本身目前在极光还没有实现全面检测,所以这个主题域下的数据更多的是辅助治理工作。

 

成本域

成本域内主要收集的是和平台每月财务成本相关的数据,该主题域内的数据也是企业经营者、数据负责人最为关心的.目前该主题域下的数据主要从财务系统、自建IDC维护平台、各云厂商系统中进行数据同步,例如,自建机房中每月每批机器的折旧成本、机柜成本、带宽电费等成本,云厂商的各项成本数据等。

成本域下的数据在实际使用中是要经历一系列成本转化过程的,因为数据负责人不会去关心具体的机器成本,他们更希望看到自己产品线的成本,甚至是产品线下每张表的存储成本、计算成本.所以我们每月会按照实际的财务成本和使用情况核算出存储单价和计算单价,再关联相关的部门维度进行成本信息展示,并且会基于血缘关系,对基础数仓的成本进行分摊,分摊到各产品线的成本上。

 

模型域

模型域内主要收集的是各数据模型在开发建设过程中的数据,该主题域也是我们在重点维护的一个主题域,其中对于物理模型,例如,Hive表、Hbase表、在数据接入平台定义过Schema的Kafka Topic、在数据服务平台定义过数据映射关系的API,都可以通过自动化方式进行同步.对于一些上层的逻辑模型的信息同步,像前一小节介绍的,目前还是半自动半手工的在维护。

这里面重点的信息收集在逻辑模型上面,需要收集到该模型的业务信息、主题域、维度属性、表粒度、生命周期,对应的数据指标等。

模型域的使用除了日常的数据字典功能,目前主要是在数仓建设方面,我们通过模型域下的数据去建设数仓衡量指标,例如,数仓各层级表分布情况,跨层引用率等.我们相信未来该主题域还会带来更多的数据治理价值。

03元数据的服务应用

---

这一节主要介绍一些基于元数据开发的数据治理服务应用,目前对于元数据系统的上层应用主要是数据地图这个产品,前期我们对这个产品的定位更多是一个系统化的数据字典,可以查看每个元数据的明细、血缘关系.后面在实际的推广使用中,业务同学越来越多的反馈希望可以更多的展示一些资源相关的使用情况,让他们除了从业务视角去查看数据,还可以从技术视角去了解自己维护的数据资产,我们也希望可以通过可视化的方式让业务同学更关注数据治理的事情。

基于上述目的,我们从部门管理者和数据负责人的视角出发,分别进行了各类数据资产大盘和数据资源明细的开发,底层数据是我们上一节聊到的元数仓。

大盘主要是以趋势、TOP、聚合、占比的方式进行数据展示,让用户可以从宏观的视角了解到部门数据的实际情况。

 

明细数据主要是根据数据的归属情况,对相关数据负责人进行展示,数据负责人可以了解到归属于自己的数据资产的资源使用情况,更好的了解现状。

 

除了系统的可视化展示,相关的资产数据我们也会以邮件、钉钉的方式进行定时推送,让部门管理者和数据负责人更关心自己负责数据的实际情况。

04基于元数据分析的数据治理规则

---

除了日常的数据运营情况展示,让数据负责人去自行进行数据治理之外,我们也希望通过一些数据分析的方法,整理出一些有效并且可实际落地的数据治理规则,帮助数据负责人去更好的发现问题,解决问题,并且可以看到治理后的结果,形成一个完整的治理流程闭环。

目前我们分别从存储层面、计算层面、质量层面探索出了一些有共性的数据治理规则,这些数据治理规则会基于元数据定期进行数据探测,创建可优化的数据治理事件,我们会对这些治理事件按规则和数据负责人进行归类展示,数据负责人可以基于这些治理事件进行有针对性的优化,对于某类治理事件,数据负责人如果认为没有必要优化,可以对对应的元数据实体设置白名单,避免规则扫描。

05元数据的开放与数据治理共建

---

数据治理本身是个复杂的事情,需要协同各方共同探索建设,为了更好的总结有共性、可复制的数据治理经验,为了提高数据治理的效率,我们会把元数仓的部分数据权限面向业务开放,让业务部门和数据平台一道探索数据治理新的可行性方案,经验共享。

后续规划

以上介绍的基于元数据发现数据治理问题的方式,多是基于固定规则,靠单纯的数据分析去处理的,后续我们希望加强元数仓模型域的建设,通过一些数据挖掘的手段去发现更深层次的数据治理问题,例如,对相似粒度、相似维度表的定位,发现重复性建设的数据模型,通过血缘关系发觉相似数据pipeline,指导业务进行合并和下线等。

总结

本文分享了一些基于元数据进行数据治理的思考和经验,但是还是像前文提到的,数据治理本身是个复杂的事情,不会因为有了一个基于元数据的治理平台就完全能把数据治理工作做好,在这个过程中还需要从公司的数据战略、制度、监督等多个方面共同建设,当有了一个清晰的目标之后,才能更好的依靠技术手段去进行实现。

关于极光

极光（Aurora Mobile，纳斯达克股票代码：JG）成立于2011年，是中国领先的客户互动和营销科技服务商。成立之初，极光专注于为企业提供稳定高效的消息推送服务，凭借先发优势，已经成长为市场份额遥遥领先的移动消息推送服务商。随着企业对客户触达和营销增长需求的不断加强，极光前瞻性地推出了消息云和营销云等解决方案，帮助企业实现多渠道的客户触达和互动需求，以及人工智能和大数据驱动的营销科技应用，助力企业数字化转型。