[系统运维]数据中台（01）- 全面了解数据中台

01 数据中台起源

尽管大数据产生于硅谷，数据中台与大数据关系密切，但硅谷却没有数据中台这个名词，“数据中台”的概念是在其倡议者阿里巴巴内部产生的。

2015 年年中，马云带领阿里巴巴集团高管拜访了一家芬兰的小型游戏公司Supercell。让马云及其高管团队感到惊讶的是，这家仅有不到 200 名员工的小型游戏公司竟创造了高达 15 亿美元的年税前利润！Supercell 之所以能够支持多个团队快速、敏捷地推出高质量的游戏作品，其强大的中台能力功不可没。因此，在拜访 SupercellE 的旅程结束之后，马云决定对阿里巴巴的组织和系统架构进行整体调整，建立阿里产品技术和数据能力的强大中台，构建“大中台，小前台”的组织和业务体制。

实际上，虽然硅谷并没有“数据中台”这一叫法，但硅谷的公司早已自然形成了中台的意识。从早期的中间件（Middleware）、面向服务的架构（SOA）到后来的IaaS/PaaS/DaaS平台、微服务(Microservice),都有中台思想的影子，都来源于避免重复造轮子、快速迭代、数据驱动、业务驱动这些硅谷工程师文化的核心理念。

02 数据中台的定义

在定义数据中台前，必须了解数据中台建设的目标。

2.1 数据中台建设目标

根据数据中台要解决的问题，我们可以确定数据中台建设的终极目标。数据中台首先是一种 IT 系统，而 IT 系统建设的最终目标是服务企业，因此数据中台的建设遵循我们常说的以业务为导向的路径。

例如：阿里巴巴的目标是“让天下没有难做的生意”，腾讯的目标是“以技术丰富互联网用户的生活”，但是这些大目标都有一个共同的子目标，即最高效地实现资源的合理配置和利用，创造最大的企业利润，简单来讲就是精细化运营，开源节流。从最早的会计系统，到计算机普及时代的信息化建设，到现在的大数据、数字化转型、智能化，都是服务于这个目标的。

因此，建设数据中台的最终目标是通过提供工具、流程和方法论，实现数据能力的全局抽象、共享和复用，赋能业务部门，提高实现数据价值的效率。

2.2 如何实现建设目标

第一，实现这些目标必须有相应的数据能力，也就是从数据中产生价值的能力。

例如，在 EA，各个游戏工作室都会用统一的大数据平台来完成用户行为分析、反欺诈、动态定价等一系列关键的数据驱动的功能。这些功能无法用预先设计好的算法或程序来完成，必须根据实际数据采取相应行动才能实现。这些都是数据能力的典型代表。

第二，要实现这些目标，必须完成全局的数据汇聚和治理

例如，EA 大数据团队花了一年时间整理出像字典一样厚的数据规范，形成连接生产数据的游戏工作室与消费业务数据的分析部门的桥梁。有了这种统一而详细的数据规范标准，各业务分析部门就可以轻松整合所有的游戏数据，形成公司层面的数据资产，然后对其进行挖掘和分析，得到各自需要的有价值数据。

第三，企业必须高效完成从汇总好的数据到价值的转换，需要进行数据能力的抽象，然后实现能力的共享和复用。

过程有两种实现方式。

• 一种是由大数据部门做顶层设计来实现。举例来讲，EA 大数据团队设计了一个反向索引的分析系统，各游戏工作室从黑市上买了游戏币以后，只要把这些游戏币的 ID
  输入系统里，就可以通过反向索引查到并清除掉收集这些游戏币的僵尸账号。这个数据能力是各个工作室都需要的，虽然它们的需求会有细微差异，但是大数据平台将其中的共同点提取出来，形成一个通用工具，各个工作室可以配合自己的特定参数来使用。
• 另一种方式是一个业务部门开发供自己使用的服务，但发现其他业务部门也需要，于是就对这种服务进行抽象，以供全公司复用。举例来讲，FIFA游戏推广团队有一个需求是，每天通过电子邮件向特定用户群体推送打折券。以往，需要进行很复杂的查询才能得到目标用户的
  ID，要从几百万个用户中筛选出几百个，而且一天可能只能做一次。FIFA
  游戏推广团队与大数据团队合作开发了一套标签系统，利用它可以快速定位这几百个用户。比如这个群体是美国加州的用户，年龄在
  35~45 岁，年收入为5 万~8 万美元，过去 7 天平均玩游戏的时间超过 1 小时，游戏内消费金额为2000~3000美元。确定这些标签后，几秒就可以完成层层过滤，锁定目标用户群体，然后可以很简单地通过模板将打折券推送给他们。

第四，在实现数据能力的共享和复用的过程中，需要协调复用和效率的矛盾。

如果一个业务部门为了满足其他部门复用某个服务的需求而做了大量工作，结果影响到自己的工作效率，这就得不偿失了。这里首先需要有一套平衡的工具和机制，其次是要有能够精确衡量数据能力的ROI，让业务部门有动力共享它们的数据能力。

2.3 数据中台定义与特点

综上所述，我们认为数据中台可以如下定义：

数据中台是企业数字化运营的统一数据能力平台，能够按照规范汇聚和治理全局数据，为各个业务部门提供标准的数据能力和数据工具，同时在公司层面管理数据能力的抽象、共享和复用。

数据中台需要具备以下特点:

1. 能够借助汇聚全局的数据为用户赋能;
2. 实现数据能力的抽象；
3. 可以通过工具体系让企业各部门方便地共享抽象出的数据能力。

03 大数据平台与数据中台

阿里巴巴提出数据中台的概念，只是为了强调与现有的很多大数据平台在实现方式上的区别，强调解决数据孤岛/重复开发的问题，强调数据共享和复用。

3.1 为什么要建设数据中台

数据中台的出现，与传统大数据平台项目的一些实践和弊端有关：

• 为了赶风口，为了大数据而大数据，安装一个 Hadoop 集群之后把数据都存上去，却发现除了有限的应用之外很难挖掘数据的价值；
• 企业内各个部门重复建设大数据平台，或者在同一个大数据平台上重复建设类似的数据应用，最后造成数据孤岛和应用孤岛；
• 由于架构选择问题，大数据平台缺乏灵活性和可扩展性，新的大数据应用和人工智能应用很难无缝扩展到现有平台上，每次新增功能都要经过冗长的流程甚至只能另起炉灶；
• 大数据平台的开发和运营花费巨大，大家都觉得必须建设，但是并不清楚建设后到底能产生多少效益。

数据中台与传统大数据平台、数据仓库的关系图：

3.2 数据中台与传统的大数据平台的区别

传统的大数据平台架构图如下：

可以看到大数据平台的架构由以下核心功能组成：

• 大数据基础能力层：Hadoop、Spark、Hive、HBase、Flume、Sqoop、Kafka、Elasticsearch 等。
• 在大数据组件上搭建的ETL 流水线，包括数据分析、机器学习程序。
• 数据治理系统。
• 数据仓库系统。
• 数据可视化系统。

在很多大数据项目里，只要把这些系统搭起来，每天可以生成业务报表（包括实时大屏），就算大数据平台搭建成功了。

但数据中台应该是大数据平台的一个超集，在大数据平台的基础之上，数据中台还应该提供下面的系统功能：

1. 全局的数据应用资产管理
2. 全局的数据治理机制
3. 自助的、多租户的数据应用开发及发布
4. 数据应用运维
5. 数据应用集成
6. 数据即服务，模型即服务
7. 数据能力共享管理
8. 完善的运营指标

数据中台的五大要求（OneID、OneModel、OneService、TotalPlatform TotalInsight）：

3.3 数据中台的评判标准

如何评判一个公司的大数据平台能否承担数据中台的任务？我们认为有以下几个比较明显的标准：

• 数据/数据应用标准的覆盖率和复用率：必须实现数据和数据应用标准的全覆盖和高复用率。
• 数据应用建设方式及周期：必须快速落地、快速迭代。
• 新的业务场景解决方案的迭代管理方式：新的业务场景必须能够快速复用现有数据能力，快速得到数据反馈。
• 对于数据/人员业务演进的适应能力：在数据/人员业务发生变化时有可靠的管理方式。
• 不同角色使用数据中台的方式：业务部门可以自助使用数据能力并方便共享。
• ROI的精确度：能精确量化数据在系统中的使用情况。
• 业务部门/IT部门/数据平台部门的责权利划分：各个部门的责权利清晰。

04 数据中台建设总纲

4.1 业务驱动，快速落地

所谓业务驱动，就是在建设数据中台的时候，一定要从企业的业务痛点、开发新业务的需要或者管理的需要出发，一步一步来，而不能期望一蹴而就。这是因为，数据中台的建设应该是先从 0 到 o.1, 要很快见效，不断迭代，分阶段地逐渐体现出数据中台的价值。如果能够快速解决各部门的业务痛点和需求，各个部门才会积极响应数据中台的建设。而且从工程师的角度来看，这样开发的服务不仅部门内部可以使用，公司其他部门也能用到。在能力得到大家认可后，其他部门的工程师还会帮助调试这个项目，一举两得。当其他部门的工程师也开始这样发布服务时，就形成了良性循环。贯彻数字化运营的理念，能够不断从数据中提取新的价值，这样才能充分调动各个部门使用数据中台的积极性。

4.2 顶层架构设计及数据规范

在确定有业务痛点，需要相应的数据能力来解决问题的时候，首先必须梳理顶层的组织架构和业务架构，并确定全局的数据架构和数据规范。值得注意的是，这里并不需要进行全局的业务梳理、数据梳理，因为我们在确定顶层架构和数据规范之后，可以根据具体的业务需求来梳理专门的业务流程和相关数据。只要有合适的顶层架构和数据规范并贯彻执行，系统中就不会出现数据孤岛。

4.3 平台管理，由工具来指导数据能力的抽象和共享

如果实现数据能力的抽象和共享需要建立大量规则，需要复杂的培训，还要小心使用，那么这个数据中台注定是很难长期演进的。数据中台的建设应该以提供一系列方便好用的工具和流程为目的，让工具引导人来完成工作，而不是靠人手动操作。例如，添加一个新的数据源，对现有数据源进行修改的时候，相应的工具应该能自动完成这个数据源相关的管理工作（元数据采集、监控、通知）而不是让使用人员手动添加很多相关的配置。

4.4 明确的责权利制定，并由工具来配合责权利的管理

任何一个系统的有效执行都需要参与人员的高效管理，高效的管理需要明确的责权利定义。特别是数据中台这种几乎涉及公司所有部门的体系，参与各方的责权利必须明确。一个常见的问题是，数据中台和大数据平台团队的价值无法明确体现，却要承担整个系统的高效、稳定、正确运行，而这个系统很多时候要运行来自业务部门的应用和服务。如果不将各个部门的责权利定义清楚，最后就会陷入相互推诿的境地。这是一个管理问题，但是也需要相应工具的支撑。

4.5 必须是一个安全、高效、稳定、可扩展的系统

实际上，中台并不是一个新概念，只不过以前受制于 IT 技术，企业无法建立安全、高效、稳定、可扩展的平台。如今，借助云原生、容器等技术，构建这样 的系统已经变得非常可行。有了这些技术，再加上快速稳定的DevOps和CI/CD 流程，整个应用开发和部署变得更快捷，从开发到上线的流程变得更加流畅，因此数据中台建设最好的开发基础就是云原生架构。而且，容器天然具有资源和数据的隔离性，可以很好地保证系统的安全性。在云原生架构下做数据服务有天生的好处，就是以微服务和容器化的方式发布数据服务，能够实现非常快速的部署和迭代。另外，数据中台能够实现数据服务的弹性扩展。在容器编排如 Kubernetes 等架构下，一个操作就可以把一个数据服务容器实例变成多个实例，从而充分满足系统的可扩展性。因此，数据中台的建设一定要基于云原生和容器。

05 文末

本文是《云原生数据中台：架构、方法论与实践》的读书笔记，谢谢大家的阅读，本文完！