文章目录
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的方式，把数据中台的数据接入到数据产品中。
