文章目录
1. 元数据管理
数据中台的支撑技术大致可以分为元数据管理,指标管理,模型设计,数据质量等。
首先先说说在数据中台占首要位置的元数据管理。在提到数据中台的构建,必然提到元数据,那元数据都涉及什么呢?比如,为了确保全局指标的业务口径一致,要把原先口径不一致的、重复的指标进行梳理,整合成一个统一的指标字典,而这项工作的前提就是要搞清楚指标的业务口径,数据来源和计算逻辑。其中所涉及到的数据就是元数据。
根据我的理解,元数据具体可分为三类:
-
数据字典
数据的结构信息,这个不用多说。 -
数据血缘
一般指一个表是直接通过哪些表加工而来,甚至可以做到指标字段级。
这里多说一点,血缘采集,一般可以通过三种方式:
-
通过静态解析SQL,获得输入表和输出表。这种方法面临准确性的问题,因为任务没有执行,这个 SQL 对不对都是一个问题;
-
通过任务日志解析的方式,获取执行后的SQL输入表和输出表。这种方法血缘虽然是执行后产生的,可以确保是准确的,但是时效性比较差,通常要分析大量的任务日志数据。
-
通过实时抓取正在执行的SQL,解析执行计划,获取输入表和输出表,例如开源Atlas。
- 数据特征
主要指数据的属性信息,比如一个表的存储空间大小,访问热度,主题域,分层,表关联的指标。
1.1 数据地图
数据地图是基于元数据中心构建的一站式企业数据资产目录,可以看作是元数据中心的界面。数据开发、分析师、数据运营、算法工程师可以在数据地图上完成数据的检索,解决了“不知道有哪些数据?”“到哪里找数据?”“如何准确的理解数据”的难题。
数据地图提供了多维度的检索功能,使用者可以按照表名、列名、注释、主题域、分层、指标进行检索,结果按照匹配相关度进行排序。考虑到数据中台中有一些表是数仓维护的表,有一些表数仓已经不再维护,在结果排序的时候,增加了数仓维护的表优先展示的规则。同时数据地图还提供了按照主题域、业务过程导览,可以帮助使用者快速了解当前有哪些表可以使用。
数据地图对于提高数据发现的效率,实现非技术人员自助取数有重要作用。经过我的实践,数据地图是数据中台中使用频率最高的一个工具产品,在网易,每天都有 500 以上人在使用数据地图查找数据。
1.2 指标管理
指标是一种特定类型的元数据,公司的运营会围绕它进行工作,可以说,它是业务和数据的交汇点。:
1.2.1 现状:指标混乱
一般情况,公司在没有考虑中台战略的时候,每个部门的数仓都是烟囱式开发,这样就会导致一些问题,这些问题大致可以分为6类:
- 相同指标名称,口径不一致
- 相同口径,指标名称不一致
- 不同限定词,描述相同事实过程的两个指标,相同事实部分口径不一致
- 指标口径描述不清晰
- 指标命名难于理解
- 指标数据来源和计算逻辑不清晰
1.2.2 规范化定义指标
-
面向主题域管理
为了提高指标管理的效率,需要按照业务线、主题域和业务过程三级目录方式管理指标(业务线是顶级目录)。 -
拆分原子指标和派生指标
- 对于原子指标,指标名称适合用“动作 + 度量”的命名方式(比如注册用户数、购买用户数),标识的命名用英文简写或者汉语拼音缩写比较好。
- 对于派生指标,指标名称应该严格遵循“时间周期 + 统计粒度 + 修饰词 + 原子指标”的命名方式,标识命名要用“修饰词 _ 原子指标 _ 时间周期”的方式
- 指标命名规范
指标命名规范要遵循两个基本的原则:
- 易懂,就是看到指标的名称,就可以基本判断这个指标归属于哪个业务过程;
- 统一,就是要确保派生指标和它继承的原子指标命名是一致的。
-
关联的应用和可分析维度
在全局的指标字典中,还应该有指标被哪些应用使用,除此之外,还应该有指标的可分析维度,方便分析师从不同的维度分析指标的变化趋势。 -
分等级管
- 一级指标:数据中台直接产出,核心指标(提供给公司高层看的)、原子指标以及跨部门的派生指标。
- 二级指标:基于中台提供的原子指标,业务部门创建的派生指标。
不同等级的指标意味着管理方式不同:
- 一级指标,要确保指标按时、保证质量产出,指标创建由中台负责;
- 二级指标,允许业务方自己创建,中台不承诺指标的产出时间和质量。
1.2.3 构建全局的指标字典
指标治理的最终结果,就是要形成一个全局业务口径一致的指标字典。让使用指标的人,可以通过指标字典,快速了解指标的业务含义和计算过程,不会对指标口径产生歧义。
构建全局的指标字典分为两个场景:
- 一个是面对一个新的指标需求,如何基于指标系统完成指标开发流程;
这个图详细地描述了新建指标的流程,流程中参与的各个角色。
- 另外一个是面对已经存在的,混乱的指标现状,如何进行全局梳理。
首先,成立以数据产品或者分析师为核心工作小组,专门负责指标的全局梳理,制定指标梳理计划,明确指标梳理目标,覆盖多少个业务线,与业务方共同制定时间计划;
其次,对于每一个业务线,需要对还在使用的数据报表、数据产品进行盘点,这里顺便可以把没用的报表和数据产品应该下线;对于每一个报表和数据产品中涉及的指标,按照以下几个方面需要确定:- 指标展示名称
- 指标标识
- 业务口径
- 数据来源
- 分析维度
- 数据应用
- 计算逻辑
然后,需要进行指标确权工作,保证全局唯一性。根据指标业务口径,明确指标所属的主题域、业务过程。
最后,区分指标类型,对于派生指标,要明确指标的统计粒度、修饰词、时间周期以及关联的原子指标,完成指标的规范化定义,梳理成全局指标字典。
2. 数据模型设计
这块内容在我的其他文章中有写过,这里只强调几个关键点:
- 接管ODS层,控制源头。
- 划分主题域,构建总线矩阵。
- 构建一致性维度。
维度统一的最大的难题在于维度属性(如果维度是商品,那么商品类别、商品品牌、商品尺寸等商品的属性,我们称为维度属性)的整合。
其中建设的时候有几个建议:
- 公共维度属性与特有维度属性拆成两个维表
- 产出时间相差较大的维度属性拆分单独的维表
- 出于维表稳定性产出的考虑,你可以将更新频繁的和变化缓慢的进行拆分,访问频繁的和访问较少的维表进行拆分
- 事实表整合遵循的最基本的一个原则是,统计粒度必须保持一致。
- 模型开发时,所有任务都必须严格配置任务依赖,同时将生命周期的管理,并将dwd层的数据使用lzo压缩的方式存储。
3. 数据质量
说到数据质量,那肯定每个人都深有感触。对这些事件的原因进行了归纳,主要有下面几类:
- 业务源系统变更
- 首先是源系统数据库表结构变
- 源系统环境变更
- 源系统日志数据格式异常
- 数据开发BUG
- 任务发布上线,代码中引用的测试库没有修改为线上库,结果污染了线上数据
- 任务发布上线,代码中使用了固定分区,没有切换为“${azkaban.flow.1.days.ago}”,导致数据异常
- 前面例子中,数据格式处理错误,代码忽略了异常,导致数据错误
- 任务配置异常,它通常表现在任务没有配置依赖,前一个任务没有运行完,后一个任务就开始运行,输入数据不完整,导致下游数据产出错误。
- 物理资源不足
- 在多租户下,Hadoop 生态的大数据任务(MR,Hive,Spark)一般运行在 yarn 管理的多个队列上(调度器为 CapacityScheduluer),每个队列都是分配了一定大小的计算资源(CPU、内存)。
- 基础设施不稳定
3.1 提高数据质量方法
为了提高数据质量,最重要的就是“早发现,早恢复”:
- 早发现,是要能够先于数据使用方发现数据的问题,尽可能在出现问题的源头发现问题,这样就为“早恢复”争取到了大量的时间。
- 早恢复,就是要缩短故障恢复的时间,降低故障对数据产出的影响。
以下总结了一套数据质量建设的方法:
- 添加数据稽核校验
这部分在作者的其他文章中有所总结。 - 建立全链路监控
由于数据中台的模型设计是分层的,确保中间结果可以被多个模型复用。所以会导致数据加工的链路变长,加工过程中,依赖关系会非常复杂,所以这就形成了一个风险,如果下游指标出问题了,排查定位会非常耗时。所以有必要基于数据血缘关系,建立全链路数据质量监控。 - 智能预警,确保任务按时产出
当物理资源不足时,则会导致任务产出延时。所以需要对指标加工链路中的每个任务的产出时间进行监控,基于任务的运行时间和数据血缘,对下游指标产出时间进行实时预测,一旦发现指标无法按时产出,则立即报警。同时也对任务进行分级管理,遵循核心任务优先计算的原则。 - 规范化管理制度
保证稽核规则的完备性,可以通过数据架构师团队对每个域下的核心表进行评审的方式保障,同时问题回溯和复盘,也可以不断地完善。
4. 成本优化
节约成本中的8种陷阱:
- 数据上线容易下线难
- 低价值的数据应用消耗了大量的资源
- 烟囱式的开发模式
- 数据倾斜
- 数据未设置生命周期
- 调度周期不合理
- 任务参数配置
- 数据未压缩
其中,1~3 是广泛存在,但是容易被忽略的,需要你格外注意;
4~8 涉及数据开发中一些技能,你在开发过程中注意一下就可以了。
发现问题全局盘点,为我们发现问题提供了数据支撑,而你需要重点关注下面三类问题:
- 持续产生成本,但是已经没有使用的末端数据(“没有使用”一般指 30 天内没有访问);
- 数据应用价值很低,成本却很高,这些数据应用上游链路上的所有相关数据;
- 高峰期高消耗的数据。
那么为什么你要关注这三类数据呢?
- 其实第一类就是没有使用,但一直在消耗成本的表,对应的就是我提到的陷阱1。
- 第二类其实就是低价值产出,高成本的数据应用,对应的是陷阱2。
- 第三类高成本的数据,对应的就是陷阱4~8。
那么如何精细化成本管理呢?
- 无用数据的下线应该从全链路数据资产视图的末端入手,然后抽丝剥茧,一层一层,向数据加工链路的上游推进。
- 应用层表的价值应该以数据应用的价值来衡量,对于低价值产出的应用,应该以应用为粒度进行下线。
- 对高消耗任务的优化只要关注集群高峰期的任务,项目的整体资源消耗只取决于高峰期的任务消耗,当然,如果你使用的是公有云的资源,可以高峰和低谷实施差异化的成本结算,那低谷期的也是要关注的。
5. 数据安全
机制一:数据备份与恢复
核心问题是 HDFS 的数据备份,网易 HDFS 数据的备份,是基于 HDFS 快照 + DistCp + EC 实现的。
Hadoop 在 3.x 就正式引入了 EC 存储,它是一种基于纠删码实现的数据容错机制,通过将数据进行分块,然后基于一定的算法计算一些冗余的校验块,当其中一部分数据块丢失的时候,可以通过这些冗余的校验块和剩余的数据块,恢复出丢失的数据块。EC 存储,在不降低可靠性的前提下(与 HDFS 3 副本可靠性相同),通过牺牲了一定的计算性能(因为计算校验块需要消耗额外的计算资源),将数据存储成本降低了一半,非常适合低频访问的冷数据的存储,而备份数据就是这种类型的数据。
快照,Hadoop在2.x版本就已经支持了对某个文件或者目录创建快照,你可以在几秒内完成一个快照操作。在做快照前,你首先要对某个目录或者文件启用快照,此时对应目录下面会生成一个.snapshot 的文件夹。
在上图中, 我们对 /helloword 目录启用快照,然后创建一个 s1 的备份。此时,在.snapshot 下存在 s1 文件。然后我们删除 /helloword/animal/lion 文件时,HDFS 会在 animal 目录创建 differ 文件,并把 diifer 文件关联到 s1 备份,最后把 lion 文件移动到 differ 目录下。
有了快照之后,我们就需要把快照拷贝到冷备集群中,这里选择的是 Hadoop 自带的 DistCp。为什么考虑 DistCp 呢?因为它支持增量数据的同步。它有一个 differ 参数,可以对比两个快照,仅拷贝增量的数据。同时,DistCp 是基于 MapReduce 框架实现的数据同步工具,可以充分利用 Hadoop 分布式计算的能力,保证数据的拷贝性能。
机制二:垃圾回收箱设计
HDFS 本身提供了垃圾回收站的功能,对于意外删除的文件,可以在指定时间内进行恢复,通过在 Core-site.xml中添加如下配置就可以开启了,默认是关闭状态。
<property>
<name>fs.trash.interval</name>
<value>1440</value>
</property>
当 HDFS 一旦开启垃圾回收功能后,用户通过命令行执行 rm 文件操作的时候,HDFS 会将文件移到 /user/[用户名]/.trash/current/ 目录下。这个目录下的文件会在 fs.trash.interval 配置的时间过期后被系统自动删除。当你需要恢复文件的时候,只需要把 /user/[用户名]/.trash/current/ 被删除文件移到要恢复的目录即可。
但需要注意,它只能支持通过命令行执行rm操作,对于在代码中通过 HDFS API调用Delete接口时,会直接删除文件,垃圾回收机制并不生效。尤其是我们在Hive中执行drop table删除一个Hive内表,此时删除的数据文件并不会进入 trash 目录,会存在巨大的安全隐患。
那么建议可以对HDFS的Client进行修改,对Delete API通过配置项控制,改成跟 rm相同的语义。也就是说,把文件移到trash目录。对于Hive上的HDFS Client 进行了替换,这样可以确保用户通过drop table删除表和数据时,数据文件能够正常进入HDFS trash 目录。
机制三:精细化的权限管理
权限这个问题,在数据中台构建之初,必须提前规划好。
网易数据中台支撑技术体系是基于OpenLDAP + Kerberos + Ranger实现的一体化用户、认证、权限管理体系。
权限的申请流程
在数据中台中,每一张表都有对应的负责人,当我们在数据地图中找到我们想要的数据的时候,可以直接申请表的访问权限,然后就会发起一个权限申请的工单。表的负责人可以选择授权或者拒绝申请。申请通过后,就可以基于我们自己的 Keytab访问该表了。
另外,需要特别强调的是,由于数据中台中会有一些涉及商业机密的核心数据,所以数据权限要根据数据资产等级,制订不同的授权策略,会涉及到不同的权限审批流程,对于一级机密文件,可能需要数据中台负责人来审批,对于一般的表,只需要表的负责人审批就可以了。
机制四:操作审计机制
进行到第三步,权限控制的时候,其实已经大幅降低了数据泄露的风险了,但是一旦真的出现了数据泄露,我们必须能够追查到到底谁泄露了数据,所以,数据中台必须具备审计的功能。
机制五:开发和生产集群物理隔离
总结:数据备份要同时兼顾备份的性能和成本,推荐采用EC存储作为备份集群的存储策略;数据权限要实现精细化管理,基于OpenLDAP+Kerberos+Ranger 可以实现一体化用户、认证、权限管理;开发和生产环境物理隔离,我提到了两种部署模式,需要综合权衡效率和安全进行选择。
6. 数据研发流程管理
建设数据中台是一项系统性的工程,不但要有技术的思维,更要有管理者的视角。所以也需要建立标准的数据研发流程,数据研发的需求是从指标的规范化定义开始,数据产品、数据开发和应用开发要建立一致的指标业务口径、计算逻辑和数据来源,从而才能确保需求被高质量的交付;数据服务承载了数据标准化交付的功能,通过发布成服务API的方式,把数据中台的数据接入到数据产品中。