数据中台被誉为大数据的下一站，由阿里兴起，核心思想是数据共享，并在 2018 年因为“腾讯数据中台论”再度成为了人们谈论的焦点。在 3 月 15 日 ThoughtWorks 技术雷达峰会上，关于数据中台的话题也获得了众多参会者的热烈关注。如今似乎人人都在提数据中台，但却不是所有人都清楚数据中台到底意味着什么。数据中台是只有大厂才需要考虑的高大上的概念吗？普通企业该不该做数据中台？数据中台的出现会给现有数据从业者们带来颠覆式的挑战吗？

首先它不是一个平台，也不是一个系统，如果有厂商说他们有个数据中台卖给你，对不起，它是个骗子。

要回答数据中台是什么，首先要探讨一下中台到底是什么。虽然没有明确的定义，但是作为理工直男，我们可以先把中台看作是一种中间层。既然是一种中间层，那么中台确实是一种十足技术用语，我们可以完全从技术角度来探讨了。

我们可以应用 Gartner 的 Pace Layer 来理解为什么要有中间层，这样可以更好地理解中台的定位和价值。Pace Layer 里提到，可以按照事物变化的速度来分层，这样可以逐层分析并设计合理的边界与服务。

在数据开发中，核心数据模型的变化是相对缓慢的，同时，对数据进行维护的工作量也非常大；但业务创新的速度、对数据提出的需求的变化，是非常快速的。

数据中台的出现，就是为了弥补数据开发和应用开发之间，由于开发速度不匹配，出现的响应力跟不上的问题。

数据中台解决的问题可以总结为如下三点：

效率问题：为什么应用开发增加一个报表，就要十几天时间？为什么不能实时获得用户推荐清单？当业务人员对数据产生一点疑问的时候，需要花费很长的时间，结果发现是数据源的数据变了，最终影响上线时间。

协作问题：当业务应用开发的时候，虽然和别的项目需求大致差不多，但因为是别的项目组维护的，所以数据还是要自己再开发一遍。

能力问题：数据的处理和维护是一个相对独立的技术，需要相当专业的人来完成，但是很多时候，我们有一大把的应用开发人员，而数据开发人员很少。

这三类问题都会导致应用开发团队变慢。这就是中台的关键——让前台开发团队的开发速度不受后台数据开发的影响。

史凯总结说，“数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念”。

如下图所示：

DData API 是数据中台的核心，它是连接前台和后台的桥梁，通过 API 的方式提供数据服务，而不是直接把数据库给前台、让前台开发自行使用数据。至于产生 DataAPI 的过程，怎么样让 DataAPI 产生得更快，怎么样让 DATA API 更加清晰，怎么样让 DATA API 的数据质量更好，这些是要围绕数据中台去构建的能力。

这是现在数据行业大家经常讨论的问题，到底数据仓库、数据平台和数据中台的区别是什么。

概括地说，三者的关键区别有以下几方面：

数据中台是企业级的逻辑概念，体现企业 D2V（Data to Value）的能力，为业务提供服务的主要方式是数据 API；

数据仓库是一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表；

数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台，为业务提供服务的方式主要是直接提供数据集；

数据中台距离业务更近，为业务提供速度更快的服务；

数据仓库是为了支持管理决策分析，而数据中台则是将数据服务化之后提供给业务系统，不仅限于分析型场景，也适用于交易型场景；

数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

数据仓库具有历史性，其中存储的数据大多是结构化数据，这些数据并非企业全量数据，而是根据需求针对性抽取的，因此数据仓库对于业务的价值是各种各样的报表，但这些报表又无法实时产生。数据仓库报表虽然能够提供部分业务价值，但不能直接影响业务。

数据平台的出现是为了解决数据仓库不能处理非结构化数据和报表开发周期长的问题，所以先撇开业务需求、把企业所有的数据都抽取出来放到一起，成为一个大的数据集，其中有结构化数据、非结构化数据等。当业务方有需求的时候，再把他们需要的若干个小数据集单独提取出来，以数据集的形式提供给数据应用。

而数据中台是在数据仓库和数据平台的基础上，将数据生产为为一个个数据 API 服务，以更高效的方式提供给业务。

大数据和人工智能大火之后这几年，很多人一直在提一个说法，那就是“数据是新的石油”。但史凯的观点却有些不同，在他看来，数据不等于数据资产，如果没有从业务的角度对数据进行规划，再多的数据也无法产生价值。

史凯认为数据中台最核心的一个关键组件是数据资产目录。“我们认为，一个企业的数据要能够充分发挥价值，很重要的一个前提条件就是这个企业的数据结构和数据资产目录是对整个企业开放的。所有人都能够通过这个资产目录了解公司有哪些类别的数据、包含什么属性、源数据由谁管理，这样就可以快速搞清楚这些数据是不是自己需要的。但数据本身可以不开放，因为数据是有隐私信息和安全级别的。”

大企业内部业务众多，不同业务可能存在很多重复数据。所谓的数据资产目录就是把数据的模型去重、归一、梳理，变成一个树状结构，这个树状结构不直接对应数据库中的字段。以航空货运为例，其数据资产可能包括货机、客运机的辅舱，一架货机就是一个数据资产目录的节点，而货机的各种属性（如货机型号、空间大小、年份等）就是这个节点下面的数据模型。数据资产目录做的事情就是从业务层面出发制定数据标准，将企业业务相关的数据资产模型抽取出来，这跟后面用什么数据库去存储、用什么结构去存储、存成结构化还是非结构化都没有关系。它相当于把企业的业务从数据层面做了一个梳理，用数据的语言把企业的业务模型还原出来。数据资产目录做好之后，后面才是用什么技术手段、从哪里提取数据来映射到这个数据资产目录。

除了开放，数据资产目录还应该具有标签描述、可检索，这样才能最大程度地方便真正使用数据的人，以最快的速度找到他们需要的东西。

在 ThoughtWorks 提出的精益数据创新体系中将企业所需要具备的数据能力概括为以下六种，具备了这六种能力，企业才具备成为数据驱动的智能企业的基础，而这些能力的承载平台，就是数据中台：

数据资产的规划和治理

做中台之前，首先需要知道业务价值是什么，从业务角度去思考企业的数据资产是什么。数据资产不等同于数据，数据资产是唯一的，能为业务产生价值的数据。 对于同一堆数据，不同业务部门所关注的数据指标可能完全不同，怎么让各个跨域的业务变成统一的标准，就需要规划企业的数据全景图，将所有有可能用上的、所有对企业有可能有价值的数据都规划出来，最终梳理出企业的数据资产目录。在这个时候不需要考虑有没有系统、有没有数据，只需要关注哪些数据是对企业业务有价值的。这一层不建议做得太细，太细就难以形成标准，不能适用于多个场景了。数据治理是数据中台很重要的一个领域，ThoughtWorks 认为在现在业务边界消失、需求快速变化的情况下，企业需要具备精益数据治理的能力——Lean Data Governance。传统的中心化、事前控制式的数据治理方式，要改变为去中心化、事后服务式的治理方式。

数据资产的获取和存储

数据中台要为企业提供强大的数据资产的获取和存储的能力。

 3. 数据的共享和协作

企业的数据中台一定是跨域的，需要让所有的人都知道数据资产目录在哪里。不能因为数据安全，就不让大家知道企业有什么数据。没有共享和开放，数据没有办法流动起来，没有流动的话数据的价值产生的速度就会非常慢。所以在数据安全的基础上，企业的数据资产目录要对利益相关者、价值创造者开放，要让业务人员能够做到“Self-Service”。

  4. 业务价值的探索和分析

数据中台不仅要建立到源数据的通路，还需要提供分析数据的工具和能力，帮助业务人员去探索和发现数据的业务价值。一个好的数据中台解决方案中需要针对不同业务岗位的用户提供个性化的数据探索和分析的工具，并且在此基础上一键生成数据 API，以多样化的方式提供给前台系统。

数据服务的构建和治理

数据中台需要保证数据服务的性能和稳定性，以及数据质量和准确性，还需要具备强大的服务治理能力。数据中台是一个生态平台，在数据中台上面会不断生长各种数据服务，所以从一开始就构建好数据服务的治理结构是非常重要的，数据服务需要可以被记录、可被跟踪、可被审计、可被监控。

   6. 数据服务的度量和运营

如果数据中台最终只是做到把数据给到业务人员，那它就只是一个搬运工的角色。数据中台还需要具备度量和运营数据服务的能力，能够对中台上提供的数据服务及相关行为持续跟踪和记录，包括哪些数据服务被哪个部门用了多少次等，通过这些去度量每一个数据服务的业务价值。

史凯认为，数据中台是一个需要用互联网思维去经营的利润中心平台，数据中台的经营分析人员需要分析业务，了解为什么今天上午这个财务部门的人用了数据中台、调用了十次，下午他不用了，原因是什么，调用了这些数据服务的人通常还会调用哪些其他的数据服务。这些都需要相应地做记录、做日志、做分析，要把数据当做像电商平台一样去经营，然后实时地根据这些业务行为数据去提醒数据服务提供方，调整、改变、优化数据服务，这才是可经营的数据中台，也只有这样业务部门才能得到最快的支持和响应。

数据中台并非只有大公司才需要的高大上的玩意。

ThoughtWorks 从 2017 年到现在，已经帮助多家大型国内外企业建设数据中台，其中有体量巨大的企业级数据中台，也有部门级的小数据中台。

“未来所有的企业核心都会变成加工数据的企业，而数据中台是数据价值化的加工厂，所以所有的企业都需要数据中台的能力，数据中台一定是未来每个企业的标准配置。”

在史凯看来，数据中台并不意味着“大而全”的数据平台。根据企业的规模和业务的不同，数据中台可大可小，规模、复杂度可能都不相同，但它对业务产生的价值是一样的。

当企业评估自己是否应该建设数据中台时，应该从哪些方面来考虑？史凯认为，从战略角度来说，每个企业都需要建立自己的数据中台；从战术角度来说，当企业发现自己的数据开发利用的速度和应用开发的速度不匹配的时候，就需要考虑构建数据中台。

原来很多企业在做应用系统的时候，什么都不考虑直接上单体架构，一上来就先做数据库，然后在上面建应用。ThoughtWorks 建议现在的企业，即使不做数据中台、不去立一个叫做“数据中台”的项目，但是在做应用的时候，最好把这个应用分成三层，业务层、数据中台层、源数据层，在一开始做应用的时候就把三个层次抽象出来。

历史遗留的数据质量问题经常让大家对数据的利用和价值产生质疑。2018 年，史凯在与不同企业沟通过程中经常听到的一句话就是，“我们现在还没有到利用数据这一步，因为（应用系统中的）数据质量太差”。

每次听到这句话，史凯脑子里就好像听到了另外一句话，“还没到培养孩子的时候啊，孩子太小了”。

不能因为数据质量差，就不去利用数据。恰恰是因为没有去做后面的事情，所以数据质量才差。而且也不能因为数据质量差就抛开业务场景、试图全面解决数据质量的问题，这样得不到业务部门的支持，也无法从数据工作中产生业务价值。所以 ThoughtWorks 建议的恰恰是利用做应用、做业务的需求，同步解决数据质量问题。

史凯认为，数据质量问题，根本上是在构建应用之初缺乏整体数据规划和数据思维导致的问题。原来的流程类应用构建之初，只考虑了如何让流程跑起来，缺乏对这个应用在整个企业的数据全景图（Data Landscape）中的定位的分析，没有从源头上优化数据的存储、流转，从而更好地与其他的系统中的数据去对齐口径、统一语言，将流程问题抽象成领域模型问题，再将领域模型抽象成数据模型。

建设数据中台最大的挑战在于前期能否从业务层面梳理清楚有业务价值的场景，以及数据全景图，而不仅在于后期的技术建设。

数据中台建设面临的挑战包括：