概述
前面大概介绍了数据数据的质量如何维护，成本如何降到最低，数据服务的功能。现在给大家讲解一下数据安全，数据研发，数据分析以及最贱实践的例子。
数据安全
在刚开始构建数据中台的时候，我们就重点考虑了数据中台的安全保障，我把它归结为五大法宝。
接下来，我就带你深入分析一下，希望学完这部分内容之后，
你可以回答这样三个问题：如何解决数据误删除问题；如何解决敏感数据泄露问题；如何解决开发和生产物理隔离问题。
它们是你在数据中台建设中一定会面临的，学完之后，你一定可以找到解决这些问题的方法。
数据备份与恢复
对于绝大多数的企业，数据中台的数据都存储在 HDFS 中，即使是实时的数据（存储于 Kafka），也会归档一份到 HDFS，因为要保存历史数据进行回算或者补数据。所以我们要解决的核心问题是 HDFS 的数据备份。HDFS 数据的备份，是基于 HDFS 快照 + DistCp + EC 实现的。
我们分为线上集群和冷备集群两个集群，数据加工任务访问的是线上集群，存储采用的是 HDFS 默认的 3 副本。而冷备集群，主要考虑到存储成本的因素，采用的是 EC 存储。
为了让你了解 EC 存储的基本原理，我多说几句。其实，Hadoop 在 3.x 就正式引入了 EC 存储，它是一种基于纠删码实现的数据容错机制，通过将数据进行分块，然后基于一定的算法计算一些冗余的校验块，当其中一部分数据块丢失的时候，可以通过这些冗余的校验块和剩余的数据块，恢复出丢失的数据块。这么说可能不太形象，我做个比喻。比如有三个数据块，分别存储的是 1、2 和 3。我们非常担心其中一个数据块坏了，丢失内容。所以增加了一个块，这个块存储的内容是前面三个数据块之和。那么如果其中任意一个数据块坏了，我们可以根据现有的数据块计算出丢失的数据块内容。 比如 1 丢失了，我们可以根据 6-3-2 计算出 1，当然这个只是最简单的 EC 算法，只能容忍一个数据块丢失，实际的 EC 算法要再复杂一些 。在这里我只想告诉你的是，EC 存储，在不降低可靠性的前提下（与 HDFS 3 副本可靠性相同），通过牺牲了一定的计算性能（因为计算校验块需要消耗额外的计算资源），将数据存储成本降低了一半，非常适合低频访问的冷数据的存储，而备份数据就是这种类型的数据。
那线上集群的数据又是如何同步到冷备集群的呢？在回答这个问题前，你有必要先了解一下快照的基本原理，因为这样你才能理解后续的数据同步流程。Hadoop 在 2.x 版本就已经支持了对某个文件或者目录创建快照，你可以在几秒内完成一个快照操作。在做快照前，你首先要对某个目录或者文件启用快照，此时对应目录下面会生成一个.snapshot 的文件夹。
在上图中， 我们对 /helloword 目录启用快照，然后创建一个 s1 的备份。此时，在.snapshot 下存在 s1 文件。然后我们删除 /helloword/animal/lion 文件时，HDFS 会在 animal 目录创建 differ 文件，并把 diifer 文件关联到 s1 备份，最后把 lion 文件移动到 differ 目录下。通过这个案例，我们不难发现，HDFS 快照实际只记录了产生快照时刻之后的，所有的文件和目录的变化，非常适合每天只有少数文件被更新的数据中台，代价和成本也很低。有了快照之后，我们就需要把快照拷贝到冷备集群中，这里选择的是 Hadoop 自带的 DistCp。为什么考虑 DistCp 呢？因为它支持增量数据的同步。它有一个 differ 参数，可以对比两个快照，仅拷贝增量的数据。同时，DistCp 是基于 MapReduce 框架实现的数据同步工具，可以充分利用 Hadoop 分布式计算的能力，保证数据的拷贝性能。我提供给你一张详细的图，透过这张图，你可以看到具体的数据从线上集群拷贝到冷备集群的流程。
首先，对于第一次开始数据备份的文件，我们会先创建一个快照，然后利用 DistCp 拷贝全量的备份数据到冷备集群。然后后续的每一天，我们都会定时生成一个快照，并和前一天的快照基于 distcp --differ 参数进行对比，将有更新的部分再同步到冷备集群。同步完成以后，会删除前一天的快照，这样就完成了每日数据的增量同步。这里需要特别注意的是，拷贝数据会对线上 I/O 产生比较大的压力，所以尽量在任务运行的低峰期进行同步（比如白天 12 点到晚上 24 点之间的时间），同时 DistCp 的 bandwidth 参数可以限制同步的速率，你可以根据 I/O 负载和数据同步速率，动态调整。比如说，I/O 利用率 100%，应该限制数据拷贝带宽，为 10MB/s。讲到这儿，你已经了解了数据中台中，文件目录的备份了，但是光这些还不够，我们还需要备份数据的产出任务，表相关的信息：
任务的备份，要保存任务代码、任务的依赖关系、任务的调度配置以及任务的告警、稽核监控等信息；表的备份主要是备份表的创建语句。
我们提供了产品化的解决方案，数据开发可以在我们提供的数据管理平台上，选择一张表，创建备份，然后系统就会自动地完成任务、文件和表的备份。平台也提供了一键恢复的功能，系统会自动地帮数据开发创建任务和表，拷贝数据从冷备集群到线上集群。那么你可能会有疑问：什么样的数据应该备份呢？ 在我看来，数据的备份策略应该和数据资产等级打通，对于核心数据资产，数据中台应该强制进行备份。那假如说，数据没有备份，但我们误删除了，还有没有其他的补救方法呢？ 你可以试一下接下来地的这个机制。
垃圾回收箱设计
HDFS 本身提供了垃圾回收站的功能，对于意外删除的文件，可以在指定时间内进行恢复，通过在 Core-site.xml 中添加如下配置就可以开启了，默认是关闭状态。
1 <property> 2 <name>fs.trash.interval</name> 3 <value>1440</value> 4 </property>
当 HDFS 一旦开启垃圾回收功能后，用户通过命令行执行 rm 文件操作的时候，HDFS 会将文件移到 /user/[用户名]/.trash/current/ 目录下。这个目录下的文件会在 fs.trash.interval 配置的时间过期后被系统自动删除。当你需要恢复文件的时候，只需要把 /user/[用户名]/.trash/current/ 被删除文件移到要恢复的目录即可。听到这儿，你是不是感觉问题已经解决了呢？但是我想强调的是 HDFS 垃圾回收机制在实际应用过程中，存在重大的缺陷。因为它只能支持通过命令行执行 rm 操作，对于在代码中通过 HDFS API 调用 Delete 接口时，会直接删除文件，垃圾回收机制并不生效。尤其是我们在 Hive 中执行 drop table 删除一个 Hive 内表，此时删除的数据文件并不会进入 trash 目录，会存在巨大的安全隐患。
那你要怎么解决呢？我建议你可以对 HDFS 的 Client 进行修改，对 Delete API 通过配置项控制，改成跟 rm 相同的语义。也就是说，把文件移到 trash 目录。对于 Hive 上的 HDFS Client 进行了替换，这样可以确保用户通过 drop table 删除表和数据时，数据文件能够正常进入 HDFS trash 目录。
通过这种方式，你可以解决数据误删除的问题。但 HDFS 回收站不宜保留时间过长，因为回收站中的数据还是三副本配置，会占用过多的存储空间。所以我给出的一个配合解决方案是，回收站保留 24 小时内的数据。这样解决的是数据还没来得及被同步到冷备集群，误删除的情况。对于一天以上的数据恢复，建议采取基于冷备集群的数据备份来恢复。好了，讲完如何解决数据的误删除之后，接下来我们来解决第二个问题，就是如何避免敏感数据的泄露，而这离不开精细化的权限管理。
精细化的权限管理
数据权限是数据中台实现数据复用的前提和必要条件。如果刚开始系统没有开启权限，后期接入权限，任务的改造成本会非常高的，几乎涉及到所有的任务。所以权限这个问题，在数据中台构建之初，必须提前规划好。网易数据中台支撑技术体系是基于 OpenLDAP + Kerberos + Ranger 实现的一体化用户、认证、权限管理体系。
试想一下，如果有几千台机器，却没有一个统一的用户管理服务，当我们想添加一个用户时，需要到几千台服务器上去创建初始化用户，这个管理和运维的效率有多低。而 OpenLDAP 就帮我们解决了这个问题。OpenLDAP 是一个轻量化的目录服务，数据以树型结构进行存储，能够提供高性能的查询服务，非常适合用户管理的场景。
Hadoop 可以使用 LdapGroupsMappings 同步 LDAP 创建的用户和用户组，这样当我们在 LDAP 中添加用户和组时，会自动同步到 Hadoop 集群内的所有机器上。通过这个方式，你就可以解决用户管理的问题了，而接下来要解决的就是认证的问题。在非安全网络中，除了客户端要证明自己是谁，对于服务端而言，同样也需要证明我是我。为了实现双向的认证，我们在生产环境启用了安全等级最高的，基于共享密钥实现的 Kerberos 认证。说起 Kerberos 认证的原理，我想举一个有趣的例子。
你肯定去过游乐场吧！ 为了进游乐场，首先你需要提供你的身份证，实名购买一张与你身份绑定的门票。在进入游乐场之后呢，每个游乐设施前，都有一个票据授权机器，你需要刷一下你的门票，授权机器会生成一个该游乐设施的票据，你拿着这个票据就可以玩这个游乐设施了。当然，当你想玩另外一个游乐设施的时候，同样需要刷一下你们的门票，生成对应游乐设施的票据。而且你的门票是有有效期的，在有效期内，你可以尽情地玩游乐设施，一旦超过有效期，你需要重新购买你的门票。
Kerberos 认证与上面这个故事类似，在上面的故事中，TGT（Ticket-granting ticket）可以看作是门票，Client 首先使用自己的密钥文件 Keytab 和用户标识 Principal 去认证服务器（AS）购买 TGT，认证服务器确认是合法的用户，Client 会获得 TGT，而这个 TGT 使用了 TGS（Ticket-granting service）的 Keytab 加密，所以 Client 是没办法伪造的。在访问每个 Server 前，Client 需要去票据授权服务（TGS）刷一下 TGT，获取每个服务的票据（ST），ST 使用了 Client 要访问的 Server 的 Keytab 加密，里面包含了 TGS 认证的用户信息，Client 是无法伪造 ST 的。最后基于每个服务的票据，以及客户端自己生成的加密客户认证信息（Autenticator）访问每个服务。每个 Server 都有归属于自己的 Keytab，Server 只有使用 Server 自己的 Keytab 才能解密票据（ST），这就避免了 Client 传给了错误的 Server。与此同时，解密后票据中包含 TGS 认证的客户信息，通过与 Authenticator 中 Client 生成的客户信息进行对比，如果是一致的，就认为 Client 是认证通过的。一般在 Hadoop 中，我们会使用 Kinit 工具完成 TGT 的获取，TGT 一般保存 24 小时内。我介绍 Kerberos 原理，其实是想让你知道，Kerberos 对于 Hadoop 集群来说，是一个非常安全的认证实现机制，我推荐你使用 Kerberos 实现 Hadoop 集群的安全认证。
你可能会问，Kerberos 使用的是 Principal 标识用户的，它又是怎么和 OpenLDAP 中的用户打通的呢？ 其实我们访问 HDFS，使用的是 Principal，Hadoop 可以通过配置 hadoop.security.auth_to_local，将 Principal 映射为系统中的 OpenLDAP 的用户。用户注册时，平台会为每一个新注册的用户生成 Principal 以及相对应的 Keytab 文件。认证完成之后呢，就要解决哪些客户可以访问哪些数据的问题了。我推荐你使用 Ranger 来解决权限管理的问题。为什么要选择 Ranger 呢？因为 Ranger 提供了细粒度的权限控制（Hive 列级别），基于策略的访问控制机制，支持丰富的组件以及与 Kerberos 的良好集成。权限管理的本质，可以抽象成一个模型：“用户 - 资源 - 权限”。数据就是资源，权限的本质是解决哪些人对哪些资源有权限。
在 Ranger 中，保存了很多策略，每一个资源都对应了一条策略，对于每个策略中，包含了很多组许可，每个一个许可标识哪个用户或者组拥有 CRUD 权限。讲完了用户、认证和权限实现机制，那你可能会问，权限的申请流程是什么样子的呢? 在数据中台中，每一张表都有对应的负责人，当我们在数据地图中找到我们想要的数据的时候，可以直接申请表的访问权限，然后就会发起一个权限申请的工单。表的负责人可以选择授权或者拒绝申请。申请通过后，就可以基于我们自己的 Keytab 访问该表了。另外，需要特别强调的是，由于数据中台中会有一些涉及商业机密的核心数据，所以数据权限要根据数据资产等级，制订不同的授权策略，会涉及到不同的权限审批流程，对于一级机密文件，可能需要数据中台负责人来审批，对于一般的表，只需要表的负责人审批就可以了。
操作审计机制
进行到第三步，权限控制的时候，其实已经大幅降低了数据泄露的风险了，但是一旦真的出现了数据泄露，我们必须能够追查到到底谁泄露了数据，所以，数据中台必须具备审计的功能。
由于用户每次访问数据，都要对权限进行验证，所以在校验权限的同时，可以获取用户访问表的记录，Ranger 支持审计的功能，用户的访问记录会由部署在各个服务（HDFS，HBase 等等）上的插件推送到 Audit Server 上，然后存储在 Solr 中，Ranger 提供了 API 接口查询表的访问记录。但是必须指出的是，Ranger 开启 Audit 后，会对服务内的插件性能产生影响。除了敏感数据泄露的风险，我还看到一些企业想要对开发和生产环境进行物理隔离。为什么企业会有这个诉求呢？
首先，很多传统公司的数据开发都是外包人员，从企业的角度，不希望数据开发直接使用生产环境的数据进行测试，从安全角度，他们希望生产和测试从物理集群上完全隔离，数据脱敏以后，给开发环境进行数据测试。其次，涉及一些基础设施层面的组件升级（比如 HDFS、Yarn、Hive、Spark 等），贸然直接在生产环境升级，往往会造成兼容性的事故，所以从安全性的角度，企业需要有灰度环境，而用开发环境承担灰度环境的职能，是一个不错的选择。最后，虽然可以为生产和开发环境设置不同的库和队列，从而实现隔离，避免开发任务影响线上任务和数据，但会导致任务上线需要改动代码，所以最理想的，还是实现开发和生产环境两套集群，同一套代码，在开发环境对应的就是开发集群，提交上线后，就发布到生产集群。这些就是企业希望开发和生产集群物理隔离的原因，那我们接下来看一看该如何满足。
开发和生产集群物理隔离
一部分来自传统企业，尤其是金融行业，他们对安全性的要求远大于对效率的诉求，严格禁止数据开发使用线上数据进行测试，他们希望有两套完全不同的环境，包括操作平台，任务在开发环境进行开发，配置任务依赖，设置稽核规则和报警，然后由运维人员进行审核后，一键发布到生产环境。当数据开发需要对数据进行测试时，可以同步生产环境的局部数据（部分分区），数据会进行脱敏。
上图是该模式下的部署架构。通过这张图我们可以看到，开发和测试环境本身是两套完全独立的平台，因为每次数据测试，都需要同步生产环境的数据，所以这种模式下，数据开发的效率会有比较大的影响，但是优势在于对数据安全实现了最高级别的保护。与这部分客户不同的是，很多企业需要同时兼顾安全和效率，他们没有办法接受同步生产环境数据，而是需要在开发环境能够直接使用线上的数据进行测试。
上图展示了该模式下的部署架构。我们可以看到，大数据平台和任务调度系统（Azkaban）都是一套，然后 Hive，Yarn 和 HDFS 都是两套，两套集群通过 Metastore 共享元数据。这样做的一个好处在于，一个集群的 Hive 可以直接访问另外一个集群的数据。在同一个 Metastore 中，开发环境的数据在 _dev 库中，生产环境的数据在 _online 库中，用户在代码中不需要指定库，在任务执行时，根据运行环境，自动匹配库。例如在开发环境执行，Hive 默认会使用 _dev 库下的表，而在生产环境执行，Hive 默认会使用 _online 库下的表，从而实现了不需要改代码可以实现一键发布。上面两种部署模式，你可以根据你所在的企业实际情况进行选择，对安全性要求高，推荐第一种方案，对于效率要求高，同时兼顾一定的安全性，就推荐第二种方案。
数据建设
对企业来说，用好数据非常关键，从我多年的数据建设经验来看，我把数据在企业的应用划分成三个阶段。
我们就从这三个阶段，谈一谈如何用好数据中台的数据。
初级阶段。一般企业的数据应用都是从数据报表开始的，分析师会为业务部门的负责人、运营制作一些 BI 报表，把数据通过可视化的方式呈现出来，这是数据应用的初始阶段。
发展阶段。只是可视化的展现数据已经不能满足业务的需求，业务需要根据数据持续监控业务过程，发现问题、诊断分析，并给出决策建议，最后需要一键执行，形成完成的业务过程闭环，这个时候就要借助数据产品来实现，网易也是在 2018 年才开始大规模构建数据产品体系。
高级阶段。无论是数据报表、还是数据产品，它们呈现的都是固化的分析思路，只能解决知道的业务问题，但是日常工作还有很多未知的业务问题，比如销售额指标突然下降了，需要基于数据进行探索分析。这个时候，如果都依赖分析师，肯定不现实，那么就要实现自助取数，让每个人都能基于数据去做分析和决策，实现普惠大数据。我认为这是数据应用的最高级阶段，网易在 2019 年开始开放越来越多的中台数据，让更多的非技术人员去使用数据。
数据中台该如何赋能 BI 工具
很多人对数据的了解，都是从 BI 工具做的报表开始的。关于 BI 工具的产品本身，不是我想说的重点，我主要想和你讨论的是数据中台时代，如何让数据中台帮助 BI 工具更强大。我会从四个方面带你了解这部分内容。
第一，统一报表指标业务口径。数据报表上会存在指标口径不一致的问题，相同指标名称，两个报表里的数据却相差很大，这会让数据使用者对数据失去信任。而数据中台的所有的指标都是由指标系统统一管理的，如果能在数据报表上直接看到指标系统中，指标的口径定义，就可以让看报表的人准确理解数据的含义，也可以避免不同报表之间指标口径不一致的问题。同时，如果我们在指标系统上修改了指标的口径定义，也可以同步到所有的呈现该指标的数据报表中。
第二，掌握任务影响了哪些数据报表。当某个任务异常，影响了下游多个任务时，我们往往要根据任务的影响范围，决定任务恢复的优先级。如果任务影响了老板每天看的一张报表，而你却不知道，没有优先修复它，那你就等着被批吧。那我们要怎么知道一个 任务影响了哪些数据报表呢？在网易，数据报表在保存时，BI 工具可以把报表和数据的链路关系，推送给数据中台的元数据中心。当数据中台的任何一个任务出现异常，我们通过数据血缘，就可以快速找到这个任务影响了哪些数据报表，尤其是在故障恢复的时候，根据报表的优先级，我们可以优先恢复高优先级的报表。
第三，治理低价值的数据报表。根据数据中台的全链路数据血缘，我们可以计算每一个报表上游所有的数据加工成本，然后得到这个报表的成本。然后根据报表的访问量和访问人群，我们可以计算报表的 ROI（投入产出比），下线低价值的数据报表。
第四，全维度钻取。在制作报表时，分析师只能依靠经验去判断一个指标有哪些可分析维度。如果 BI 工具能根据元数据中心提供的所有指标可分析维度，自动根据指标在各个维度下的取值，找出指标波动的原因，那这就是全维度钻取了，它是目前业界最为热门的研究领域，增强分析的一个方向。比如，有一个单车租赁公司，发现 8 月份的营业额下降了，系统通过根据各个维度的数据对比和分析发现，8 月份营业额下降，是因为那个月雨天的天数增多导致的。如果分析师不知道用天气的维度去分析营业额，很可能就不知道原因。但是全维度钻取，可以基于数据中台营业额的所有可分析维度，包括天气，自动计算出雨天的销售额相比晴天的销售额低，同时进行交叉分析，发现 8 月份的雨天数量比其他月份多，最后找到问题的原因。你看，数据中台是不是很大程度上增强了 BI 工具的产品能力？ 在 BI 工具的基础上制作数据报表，这才是数据应用的初级阶段，接下来，咱们继续看一下，基于数据中台，我们能做出什么数据产品，提升业务的运营效率。
让技术人员不再是数据的搬运工，释放取数效能
对于传统行业来说，BI 部门一般有两项职责，一个是做报表，一个是取数。而取数的工作量远远多于报表的工作量。一年中做的报表可能就几百张，但是取数，一年可能要取几千次，或者上万次。而大部分传统企业的取数会依赖技术人员，因为他们离数据更近，取数还涉及写代码，所以，如果你是非技术人员，根本不可能基于数据去做探索式的分析。所以，大量的取数工作就落在了懂技术的数据开发的头上。
靠别人取数，会存在大量的沟通和协作的成本，同时因为公共集市层数据不完善，导致无法基于现有的数据，直接完成取数，需要数据开发加工新的数据，所以耗时会非常的长，一般需要一周时间。高昂的取数成本，压制了取数的需求，也导致探索式的数据分析，根本不可能大规模的使用。对于数据开发来说，他们更希望自己的工作重心放在建设公共集市层的数据上，因为公共集市层越完善，取数的成本就越低，不需要额外的开发。但是他们忙于临时的取数需求，根本就没有时间和精力去做这些工作。最后就形成了不良循环，越是集市层数据不完善，取数的工作量就会越大（要开发新的模型），越多的时间去临时取数，集市层越没人建设。
这个问题该如何破解呢？ 我们研发了一个自助取数平台，叫 EasyFetch（意为简单取数）。这个平台主要有这样几个优点：用图形化的方式，替代了写 SQL 的方式；提供了对业务人员比较友好的业务过程、指标、维度的概念，替换了表、字段；每个指标的业务口径都能够直接显示；用户通过选取一些指标和维度，添加一些筛选值，就可以完成取数过程；界面非常简洁，使用门槛非常低。
数据研发
建设数据中台是一项系统性的工程，你不但要有技术的思维，更要有管理者的视角。所以接下来，我会带你了解数据中台中三个最常见的协作流程：数据研发、数据分析、资产管理。我们一起看一下，不同角色使用场景化的工具产品是如何进行高效协作的？
也许在很多人的印象中，数据研发就是写代码，其实对大规模、标准化的数据建设来说，这远远不够。标准的数据研发流程包括四个阶段：需求阶段、开发阶段、交付阶段和运维阶段。每个阶段中又涉及多个环节，如果你缺失了这些环节，就很容易出问题，数据也会因此没办法高效、高质量的交付。
需求阶段
需求是数据开发的起点。如果想让后面的流程高效运作，那需求的定义一定要清晰，这样协作者（数据开发、应用开发、数据产品 / 分析师）对需求的理解才能一致。在数据中台中，数据需求通常是以指标的形式出现的，比如李天真提了个需求（计算每日黑卡会员的消费额），而承载这个场景的产品就是指标系统。那什么时候会提需求？又什么时候会频繁用到指标系统呢？一般来说，分析师在制作新的报表，数据产品经理在策划新的数据产品时，会提一些新的指标需求，然后就会在指标系统登记指标（包括指标的业务口径、可分析维度、关联的应用、时间周期信息）。这个时候，指标的状态就是待评审状态。
然后，管理指标的数据产品（没有这个角色的，分析师也行）会叫上相关的数据开发、应用开发、提出这个需求的分析师或者数据产品，对指标进行评审：
指标是新指标还是存在的指标；如果是新指标，那么是原子指标还是派生指标；确认指标业务口径、计算逻辑和数据来源。那评审后的结果又是什么呢？如果是新指标，就在指标系统上录入相关信息，指标状态是待开发状态；如果是存在的指标，应用开发可以直接找到这个指标所在的表，然后看这个表是否已经有现成的接口可以被直接使用，如果有，就直接申请授权，如果没有，可以基于这张表发布一个新的接口。
研发阶段
现在，新指标的状态是待开发状态，接下来就要进入开发阶段。在这个阶段，你要秉持“先设计，后开发”的理念。为啥这么说呢？因为很多开发都习惯边开发、边设计，想到哪里，代码写到哪里，这其实并不是一个好习惯。这会造成缺少整体的设计，开发过程中经常出现表结构频繁修改、代码返工、整体研发效率不高。所以说，我们要先做好模型的设计，而承载这个场景的工具产品就是模型设计中心。这里我再强调一下，数据开发在设计的过程中，可能要用到一些已经存在的数据，这时就要利用数据地图发现已经存在的表，然后理解这些表中数据的准确含义。除此之外，在模型设计过程中，要对模型中每个字段关联前面设计好的指标，以及可分析的维度。
这里你要注意一下，数据域的负责人一般是数据架构师，他需要检查数据是不是重复建设，要保证自己管理的域下模型设计的相关复用性、完善度、规范性的相关指标。当然了，除了新建模型之外，已有模型也会存在变更的情况（比如增加一个字段或变更字段枚举值）。这个时候，要根据数据血缘，通知所有依赖这个表的下游任务的负责人，在负责人确认以后，才能进行模型变更。
比如，甄可爱是一名数据开发，她接到需求完成模型设计之后，就要开始模型的开发了。首先她要把数据从业务系统导入数据中台中，那她第一步就要申请对应数据库的权限，然后在数据传输中心建立数据传输任务，把数据同步过来。
接下来，要清洗和加工数据，那她要在数据开发中心开发数据的 ETL 任务，根据之前模型设计，编写对应任务的代码。任务代码完成以后，甄可爱要在数据测试中心，验证数据：一个是进行数据探查，确定新加工的数据是否符合预期；另外一类是对原有模型的重构，新增字段或者更新部分字段。此时不仅要验证新加工数据的正确性，还要确保原有未修改数据与修改前是否有改变，我们管它叫数据的比对。数据测试中心还提供了静态 SQL 代码检查的功能，主要是发现一些使用固定分区、使用测试环境的库、使用笛卡尔积等代码问题，我们把这个过程叫 SQL Scan。 在我们的开发规范中，只有通过 SQL Scan 的代码才被允许发布上线。
在数据测试完成后，甄可爱还要在数据质量中心里配置稽核校验规则。目的是对任务产出的数据进行校验，在数据出现问题时第一时间发现问题，快速地恢复故障。在开发规范中，主键唯一性监控、表行数绝对值以及波动率监控等属于基础监控，是必须要添加的，另外还需要根据业务过程，添加一些业务规则，比如一个商品只能归属一个类目等。配置完稽核规则，甄可爱要任务发布上线了。任务发布上线，要设置调度周期，配置任务依赖，设置报警规则以及报警对象，选择提交的队列。任务发布与模型发布一样，也需要进行审核。首先甄可爱需要发起任务发布上线的工单，然后工单会根据产出表所在域流转到对应域负责人贾英俊审批，审批的主要内容：确认任务参数设置是否合理，比如 Spark Executor 分配内存和 CPU 资源；检查任务依赖、报警设置是否正确，核心任务必须要开启循环报警，同时要开启报警上报；重点审核稽核规则是否完备，是否有缺失需要补充。
在审批通过以后，任务就会发布上线，每天就会有数据源源不断的产生了。到这里，甄可爱就完成了所有模型研发的流程了。你看，虽然是一个模型研发的环节，可涉及这么多的工具产品，还包括了多个审批流程，但是这些工具和流程，都是标准化研发不可或缺的。例如如果不测试，就会导致大量的 BUG 上线，如果没有稽核监控规则配置，就会导致出了 BUG 还不知道，等着被投诉。而数据研发完，接下来就是数据的交付了，如何让数据快速接入到数据应用中呢？
交付阶段
在数据中台之前，其实并不存在单独的交付阶段，因为数据开发加工好数据应用需要的表，他的工作就已经结束了，剩下的就是应用开发的事儿了。应用开发需要把数据导出到应用所属的数据库，然后开发 API 接口，供客户端调用。数据中台，提出了数据服务化的思想，数据中台暴露的不再直接是数据，而是服务。数据开发不仅需要加工数据，还需要把数据发布成 API 接口或者其他服务形式，提供给业务系统或者数据产品调用，从而形成了单独的数据交付阶段。数据服务承载了数据交付的整个流程。数据开发，可以直接选择一张数据中台的 Hive 表，然后在数据服务上创建一个数据抽取任务，把数据抽取到中间存储中（中间存储可以是 DB，KV，MPP 等）。这个过程，数据服务会自动根据中台数据的产出时间，在调度系统中创建数据导出任务，建立到产出任务的依赖。接下来，数据开发可以基于中间存储发布 API 接口，定义输入和输出参数，测试 API 后发布上线。这个时候，数据开发的工作才算完成。最后，应用开发在数据服务上创建应用，然后申请对该接口的授权，等数据开发审批通过后，就可以直接调用该接口获取数据了。数据交付完呢，还不算完，接下来数据开发的工作，还需要保证任务的正常运行，这就进入了第四个阶段，运维阶段。
运维阶段
承载运维阶段的工具产品主要是任务运维中心。在这个阶段的第一责任人是任务负责人（一般是这个任务对应的数据开发）。这里有这样几个过程：数据开发接到报警后，要第一时间认领报警；任务运维中心提供了报警认领的功能，数据开发点击认领，代表数据开发开始处理这个报警；如果报警迟迟没有人认领，任务运维中心会每隔 5 分钟会发起一次电话报警，直到报警认领；如果报警一直没有认领，系统会在 3 次报警，15 分钟后进行报警的上报，发送给模型所在域的负责人。这样的机制设计，确保了报警能够在第一时间被响应，我们在实施这项机制后，报警的平均响应时间从 2 个小时缩短到 15 分钟内。那么当数据开发认领报警之后，需要开始排查，首先要确认上游依赖任务稽核规则是否有异常（也就是输入数据是否存在异常）。如果没有异常，数据开发要通过任务运行日志，排查当前任务的问题原因，并进行紧急修复，接下来再重跑该任务，任务重跑完，还要通过数据地图，找到所有依赖该表的下游任务负责人，发送“下游任务需要进行重跑”的通知。
故障恢复完，还要进行复盘，其中重要的事情就是补充稽核规则，确保不再出现犯过的错误。通过这样不断沉淀和记录，数据中台的数据质量就会越来越高，数据质量问题也会减少。
数据分析
根据我的经验，我把数据分析过程划分五个步骤。接下来，我通过一个例子，为你呈现了一个典型的数据分析流程。
第一步：发现业务问题。数据分析的典型场景呢，起点都是业务出现了某个问题，我们需要基于数据找出业务问题背后的原因。电商平台 Q2 季度某个品类的商品销售额下降了 30%，老板要求给出问题的原因，并进行整改。这个任务落到了她的身上。 要解释这个问题，她必须要从现有的数据入手，看看到底是哪里出现问题。
第二步：理解数据。她首先要了解这样几点：要分析的业务过程；这些业务过程中涉及到了哪些关键指标；这些指标的业务口径是什么；有哪些可以分析的维度。这些事儿比较琐碎，为了提高效率，利用指标系统，将要分析的业务过程快速锁定到交易域下的业务过程，然后找到交易域下有哪些指标。通过指标系统，了解了“渠道销售额”这个指标的口径定义、计算逻辑和数据来源。接下来，去查看指标对应的数据，借助指标系统，可以直接跳转到指标关联到数据报表上，接下来需要申请报表的权限，查看数据。报表负责人审批通过后，就可以看到数据了。
这个时候发现，淘宝渠道销售额数据出现下降，拖累了整体品类销售额的数据。可是当想进一步探查渠道下降的原因时，却发现并没有渠道级别的商品库存和销售指标。现在，靠现有的指标和数据已经没办法进一步解读业务问题的原因了，需要进行探索式分析。
第三步：探索式分析。首先要找到当下有哪些数据可以用，借助数据地图，可以快速了解当前主题域下有哪些表，这些表分别代表什么含义。这个时候，会存在两种情况：如果现有的数据可以满足分析的需求，可以直接在数据地图表详情页上发起数据权限的申请流程；如果现有的数据没办法满足需求，就要对数据开发提出数据研发的需求，会稍显麻烦。幸运的是，发现，商品粒度的库存和销售表中有渠道的字段，按照渠道进行聚合、过滤，就可以满足分析的需求了。所以，在数据地图的相关表详情页里申请了这些表的权限。
接下来，权限申请流程会流转到表对应的负责人上：对于核心表（比如交易数据），除了表负责人审批，还需要中台负责人审批；核心表中的一些核心 KPI 数据（比如平台全年销售额），还需要 CTO 甚至 CEO 级别的审批。等了一段时间，权限审批终于通过，收到了来自权限中心的通知，于是马不停蹄地在自助分析上，基于 SQL 对相关表进行了探查分析。对比分析后发现，淘宝渠道销售数据下降的主要原因是：该品类下的部分畅销商品经常库存为 0，出现缺货情况，导致整体品类销售额下降。
第四步：可视化展现。现在，找到了问题原因，为了给老板讲清楚分析过程，还要通过报表的方式，把分析过程呈现出来。所以，又在 BI 工具网易有数上进行了报表的制作，把报表授权给相关的管理层。看到了原因后，管理层制订了供应链优化措施，加大了淘宝渠道的库存供货，整体品类销售额数据出现回升，终于解决了问题。
第五步：分析过程产品化。解决了现有问题，并不是数据分析的终点。我们还要建立长久的问题发现和解决机制。为了持续地监控该问题，并对其进行智能预警，需要将分析过程固化到数据产品中。策划并研发了供应链决策协同系统，能够自动检测商品的库存和销售，智能生成补货建议，然后推送给采购系统。到此，整个数据分析的全过程就完成了。
最后，我想再强调一个点，在这五个步骤中，你往往最容易忽略是最后一个步骤。当然，这也并不只是分析师的疏忽，本身数据产品的建设还需要有一定的研发资源的投入。为了解决大规模数据产品研发资源投入的问题，在网易，我们基于网易有数（BI 工具）实现了数据门户的功能，它实现了一个低代码构建数据产品的开发环境，允许分析师通过拖拉拽的方式构建企业数据门户，从而为高效的大规模数据产品构建提供了基础。基于数据门户，企业可以构建商品运营系统、供应链协同决策系统、流量看板系统、会员运营管理系统等不同的数据产品，满足不同场景下数据分析的需要。数据如何被使用讲完，接下来，我还想来谈谈数据的精细化管理流程，因为这个流程或者环节的缺失，会导致很多成本、安全、以及稳定性的问题。
最佳实践
而且建数据中台是一项系统性的工程，涉及人员组织架构的变动，需要研发大量的系统支撑工具，更要和业务部门达成密切的合作，形成双赢，反之会有失败的风险。还是分享一件我见过的事儿。甄英俊是某零售企业 IT 部门的老大，最近他也想在企业中建数据中台。设想一番后，他亲自操刀，组建了新的数据中台部门，还亲自规划了十个业务场景（包括会员看板、商品运营、供应链管理、售后管理、毛利分析、类目管理、门店管理、仓储管理、渠道分析、辅助选品）。但数据中台团队没有和业务部门达成一致的 KPI，在具体工作推进过程中，中台团队与业务部门脱节，业务部门也没有资源支撑中台的推进（例如指标的梳理）。最后，虽然基于原先规划的十个场景，数据中台确实做出了一些报表，但很少有人查看。于是，尴尬的一幕发生了：在年终总结汇报中，甄英俊自信地向 CEO 汇报了数据建设的成果（输出了多个报表，覆盖了多少业务场景）。可当 CEO 问业务老大是否感觉到数据的作用？业务老大摇了摇头，他们并没有认可数据中台的成果。这是一个很典型的失败项目，而问题的根源就在于数据中台团队虽然独立于业务，但是并不能脱离业务。 甄英俊最大的失误就是没有深入调研业务问题，也没有和业务达成一致的 KPI，更没有根据业务的反馈，不断完善数据应用。所以，如果你要建中台，要做到这样几点：
问问自己为什么要建中台，与业务达成一致的目标；
把数据中台作为一个公司级别的顶级项目来推进，而不是一个数据部门自己的 KPI；
数据中台必须要有清晰的、可量化的价值来衡量（从主观上也要得到业务部门的认可）。
立项数据中台项目
我认为，立项是建数据中台最关键的一步，因为它的核心就是挖掘业务的痛点，跟业务达成一致的建设目标。如果能达成一个一致的、可量化的目标，数据中台的项目就成功了一半。这里我多说几句，对一些传统企业来说，业务部门的数据思维能力比较薄弱，数据使用水平还比较初级，根本讲不出什么痛点。如果遇到这种情况，你要多关注一下业绩目标（比如，如何让数据帮助企业达成 KPI）。 如果谈论这种话题，业务部门的老大一定很感兴趣。经过调研，我总结了这样几个痛点。
第一，指标业务口径不一致。
第二，需求响应速度慢。
第三，取数效率低。我们问了很多的分析师、运营，他们集中认为取数效率太低，原因有两个。一个是他们不知道有哪些数据，也不知道到哪里去找数据。当时整个电商团队存在三个小数仓（供应链、市场和仓配客）加起来有近 4W 张表，对他们来说，找到并准确理解数据，其实是非常困难的事情。另一个是，基于 SQL 取数，对于非技术人员来说，门槛比较高。分析师经常遇到一个 SQL 异常就不知所措，更不要说不懂 SQL 的运营。
正是因为这两个原因，取数要靠数据开发帮助完成，效率很低。有多低呢？平均取数需求从提出到交付，需要一周（数据来源于项目管理工具 JIRA）。而这也抑制了数据的大规模使用，与此同时，临时取数的需求，占据了数据开发的大量时间（来自 JIRA 的数据统计，数据开发 50% 的时间都被临时性的取数需求占据）。
第四，数据经常违反常识。糟糕的数据质量也是各个业务部门对数据最为不满的地方，经过 POPO 群统计（网易内部办公协作通讯工具），平均每周，我们就有 10 个数据质量问题被业务方投诉。更为可怕的是，这些问题中，90% 都是由业务方先于数据提供方发现的问题，然后 50% 都是因为数据研发的 BUG 导致。在当时，我们经常出现数据经常无法按时产出，数据修复需要花费一天的时间！
第五，数据成本指数级增长。2018 年，电商业务的大数据资源从一年 4000CU(1 CU = 1 Core + 4 memory) 增长到 12000CU，并且还在持续高速增长。当时正好是 2018 年底，公司对业务毛利这块儿管控得非常严格，精简成本作为了各个业务推进的优先级，大数据这块也不例外。为了优化大数据的成本，我们排查后发现，至少有 20% 的数据在当时都属于废弃数据，这些数据每天仍在产生，却没有人访问，浪费着资源。
除了现有数据是否用得好以外，我们也对各个部门的业务目标进行了调研，目的就是让数据帮助解决更多的业务问题。
商品部门：主要目标是优化商品结构、降低滞销商品比例、提高商品库存周转，从而达到控制毛利水平的目标。所以他们最紧急的就是监控平台上滞销的商品。供应链部门：主要目标是尽可能保证商品的供货充足，尽量避免缺货商品出现。所以及时发现缺货商品，制订更精准的采购计划是最紧急的事儿。仓配客部门：最重要的业务目标是保障商品及时送达，优化物流成本。所以，基于各个仓库的数据和物流公司的报价，制订最合理的配送计划，是他们最重要的事儿。
推进数据中台项目落地
第一步，调整团队组织架构，明确各个团队的职责。在数据中台构建之前，电商业务主要存在 3 个独立的数仓：市场、供应链和仓配客。这些业务部门中有数据开发、数据产品还有分析师。而我们首先要做的，就是成立数据中台团队，这个团队是在原有市场数仓（除了服务市场，还服务于管理层）的基础上建起来的。而对供应链和仓配客，我们并没有立即把他们的数据开发团队并入中台团队，而是调整了团队职责，把他们的数据开发的职责调整成，基于数据中台数据，加工私有的集市层和应用层。这样处理的话，各方比较容易接受，不然业务部门会觉得中台团队在抢他们的人，对于员工个人，也可能因为团队定位、福利等原因不愿意转部门。
第二步，数据整合。中台团队成立后，首先面对的是混乱的指标业务口径，所以团队要先梳理指标，建立全局的指标管理规范（对应咱们的 05 讲）。这项工作由 1 名数据产品牵头，2 名数据产品辅助，对电商分布在各个业务线的 20 多个数据产品，800 多个指标进行了梳理，去除了冗余指标，对齐口径不一致的指标。最后，我们把指标梳理成 400 个，其中，原子指标 127 个，这个过程花了 1 个月的时间，不过大部分时间都是在理解业务，和业务的分析师、数据产品对口径。接下来，中台团队还要对模型进行重构、整合和迁移（对应咱们的 06 讲），而这部分工作可以分为设计阶段和实施阶段。设计阶段，由一名数据架构师牵头，根据梳理好的指标，构建主题域，然后在原有模型的基础上进行重新设计，构建一致性维度。这里需要强调的是，中台团队必须要完全接管 ODS 层数据，这可以强迫业务部门必须要基于中台数据进行再加工。当然，中台团队会肩负着巨大的压力，但是只有熬过最痛苦的时期，这种中台的机制才能建立起来，一旦原始数据没有管住，那中台就会功亏一篑。
第三步，研发工具产品。在数据中台构建过程中，我们积累了很多规范和经验，但数据中台如果要形成落地、长久的运行机制，就必须把这些规范和经验沉淀到产品中，通过产品化的方式实现。所以在原有数据研发、数据产品团队的基础上，我们开始构思数据平台（工具产品）研发团队。因为考虑到网易集团存在公共技术研发部门（杭州研究院），可以实现工具产品在集团内不同业务线之间复用，所以选择了与公技合作的方式，由公技承担数据中台支撑技术产品的研发。
第四，数据产品构建。最后，就是业务支撑。我们通过构建数据产品，帮助业务达成业绩目标。我们的重点是商品和供应链。分别研发了商品运营系统和供应链辅助决策系统，大幅度提升了业务决策的效率。数据产品团队，我们有 10 个人的团队规模，主要负责数据产品研发。
总结数据中台项目成果
耗时一年半（实际执行一年的时间），我们完成了电商数据中台的搭建，并产出了一些阶段性的成果，对于成果这部分，你可以重点参考一下，因为你也可以通过这种方式，说服你的老板启动数据中台的建设。
数据中台从哪里来？
关于组织关系，我曾经说过，数据中台的团队必须独立于业务部门，同时又不能脱离业务。独立于业务，是因为数据中台要实现多个业务之间数据的共享，如果在业务部门内部，单个业务部门没有动力去做这个事情。那为什么不能脱离业务呢？ 这就与今天的话题密切相关了。因为数据中台必须要解决业务的问题，我记得之前在和严选数据部门负责人交流时，他有一句话让我印象深刻，他说：“数据中台各项指标建设得再好，都比不上业务部门老大在管委会上，说一句数据有用，什么数据帮他们解决了什么问题。”我觉得，这其实反应了一个根本问题，那就是业务部门的口碑，是数据部门的生命线，如果没办法获得业务的认可，数据做得再多，也是无用功。那么要解决业务的问题，得先搞清楚业务存在哪些问题。我把这些问题归结为两类：
第一类是数据用的好不好的问题；第二类是怎么让数据帮助业务解决更多的问题。
据我所知，很多企业已经拥有了大数据研发的基础，也有了不少数据应用的场景，但是数据到底用的好不好，这是他们面临的最大的问题。从业务的视角看，需求响应速度慢、取数效率低、指标口径不一致、数据经常无法按时产出，违反常识，甚至是高昂的大数据成本，种种原因让很多想用数据，但是对成本比较敏感的业务望而却步。这些问题最终导致数据在业务部门用的并不好。我清楚记得，在数据中台构建前，一个业务部门的负责人向我反馈说：“别看现在有 3000 多张报表，其实能用的不超过 10 张，因为指标口径都不一致，根本无法用，不知道相信谁。“这个时候，数据中台要解决的核心问题就是效率、质量和成本的问题。只有解决好这些问题，才能让数据用的好，业务部门用的爽，真正实现让更多的人使用数据的目的。第二类问题，是如何让数据帮业务解决更多的问题。对一些企业来说，尤其是传统企业，如果连数据应用场景都还没有，你去跟他谈效率、质量和成本，他们根本就不会关心，因为他们还没有到达这个阶段。所以，对他们来说，数据到底能解决什么业务问题才是最重要的，因为他们还没尝到数据的甜头。比如，某项业务指标出现下降，你能基于数据，帮他找到下降的原因，并解决，那业务就会很认可数据的价值。
数据中台到哪里去？
当然，数据中台的价值最终是要回到业务价值上来的。对数据部门的负责人来说，最尴尬的地方，就是数据中台并不能直接产生业务价值，他们需要前台（也就是数据应用）来接触业务，所以数据中台的价值，最终还是要通过数据应用来体现。对应于前面两类业务问题，我认为数据中台的价值，最终也是体现在数据用的好不好和数据解决了什么业务问题上。数据用的好不好，主要看这样几点：
数据需求的交付时间到底有没有缩短；
还存不存在指标业务口径不一致的问题；
数据质量是否有显著的提升；数据成本是否增长变慢了。
其实我主要是想让你明白一个基本的道理：数据中台和业务的关系，就是鱼和水的关系，谁也离不开谁，不能把它们完全分开来看。业务想要获得更大的增长，就必须依赖数据中台，数据中台想要存活下去，就必须依赖业务的口碑和认可。这也是我这十多年来，数据建设过程中最重要的一条经验了。
总结
以后关于数据中台系列的总结大部分来自Geek Time的课件，大家可以自行关键字搜索。