数据中台如何建？

一个企业在决定开始数据中台建设时，应该已经大致知道企业的信息化、大数据建设目前处于什么阶段，离数据中台的建设目标还有多远的距离。那么在开始数据中台建设之前，企业还需要注意哪些事项？本文将就此问题进行深入探讨。

数据中台建设需要一套方法论

虽然目前关于数据中台的文章有很多，但有一个关键问题一定要首先澄清，那就是数据中台既不是一项技术，也不是一款产品，而是一套方法论，或者说是企业的一套战略，其本质是企业运营思路和模式的转变。数据中台并不是购买一套产品就能实现的，成功的数据中台战略的实施不仅需要工具和产品的支持，更需要公司架构和流程层面的配合。

在数据中台的建设与信息化过程中，ERP、CRM系统的建设有很多相似之处。以ERP为例。一方面，ERP系统中的计划体系主要包括主生产计划、物料需求计划、能力计划、采购计划、销售执行计划、利润计划、财务预算和人力资源计划等，而且这些计划功能与价值控制功能已完全集成到整个供应链系统中；另一方面，ERP系统通过定义事务处理相关的会计核算科目与核算方式，保证了资金流与物流的同步记录和数据的一致性，从而根据财务资金现状就可以追溯资金的来龙去脉，便于事中控制和实时做决策。

此外，流程与流程之间则强调人与人之间的合作精神，以便在有机组织中充分发挥每个人的主观能动性与潜能，实现企业管理从“高耸式”组织架构向“扁平式”组织架构的转变，从而提高企业对市场动态变化的响应速度。

总之，借助IT技术的飞速发展与应用，ERP系统得以将很多先进的管理思想变成现实中可实施应用的计算机软件系统，这与数据中台将数据驱动的理念贯穿始终，并借助各种工具和产品，实现数据驱动企业的目标不谋而合。

在明确需要数据中台之后，企业究竟应该如何规划数据中台的建设？我们认为，企业首先需要回答以下几个重要问题：

• 如何判断当前已有数据的价值，规划并继续深入思考数字化转型如何为企业创造价值；
• 如何制定数据中台落地的策略和路线；
• 如何精确评估数据中台的ROI；
• 如何设计相应的组织架构及划分责权利；
• 如何进行合适的技术选型，以及把握购买产品和自主研发之间的平衡。

数据中台建设需要一套方法论

显然，并不是所有的数据中台项目都会成功。数据中台的概念出现时间不长，虽然已经有一些关于失败的数据中台项目的报道，但还只是零星的个例，我们难以从中总结出可靠的经验。而大数据技术已经发展十多年了，项目众多，我们完全可以从失败的大数据项目中总结经验，吸取教训，然后用其指导数据中台的建设工作，以少走弯路，避免失败。

自2012年起，NewVantage Partners公司每年面向财富美国1000强企业的管理层调查大数据和AI在其企业内的实施情况。2019年的调查报告揭示了企业数据平台窘境—尽管在大数据和AI领域投入超过5亿美元的公司较上一年增长了66%，但在65家受访企业里表示“未能或尚早体现可量化业务结果”的企业却增加了41%。

在研究企业数据平台项目失败案例的过程中，我们发现导致企业数据平台建设失败的核心原因有以下4个。

• 启动难：缺少用例支持，无法获得业务支持；需要进行长时间的数据湖设计与技术评估；需要统一组织内多个业务或技术部门。
• 数据源难以规模化：缺少对错综复杂的源数据系统进行管理的手段；难以跟上不断增长的数据源系统规模。
• 数据使用难以规模化：数据平台项目跟不上企业创新要求；用例过窄，难以满足规模化需求；平台能力跟不上错综复杂的用例需求。
• 难以实现数据商业化：开发和运营成本极高；难以将数据平台真正转化为商业竞争力；难以形成创新文化。

基于此，我们把企业数据平台的成功要素归结为：在错综复杂的企业技术环境中快速启动，规模化地引入高价值的新数据源和使用场景，尽早实现数据对整个企业商业系统的价值（对内或对外）。

其中的关键词是“快速启动”“高价值”“使用场景”“尽早实现数据价值”，第6章将会详细介绍如何才能达到这样的建设效果。数据中台虽然是个较新的概念，但是它要解决的问题并不新鲜，实际上就是大数据平台建设方式错误或不当造成的问题。所以，在建设数据中台的时候，我们一定要实事求是，根据实际业务场景确定建设路线和评估建设成果，快速实现可衡量的数据价值，避免数据中台建设重蹈覆辙。

数据中台建设中的常见问题

前文提到过，国内企业在建设大数据平台的过程中出现了很多问题，其中涉及多部门合作时问题尤其严重，例如各个部门数据重复开发、浪费存储与计算资源、数据标准不统一、数据使用成本高、业务数据孤岛问题严重、数据利用效率低等。为了解决这些问题，阿里提出了数据中台这个概念，将其作为一种新的架构方式。
那么，在数据中台建设过程中还会出现什么问题？我们根据业界数据中台的建设实践，列出了以下常见的问题。

• 数据标准建立和协调困难：业务板块和业务线众多，数据标准难建立，协调扩展困难。
• 技术选型困难：技术选型众多，不同业务方有不同的数据需求，技术选型时依据这些客观需求及主观偏好，会选择不同的计算框架和数据组件。
• 数据需求多样：业务部门需求多样化，包括报表计算、可视化看板、数据探索、数据服务、结果推送、数据采集及迁移、A/B测试、标签体系、用户触达、数据应用等。
• 数据需求多变：为应对市场的快速变化，业务方的数据需求也是多变的，看板必须能够按需调整，标签必须能自主配置，诸如此类的需求需要有大量自助工具来支撑。
• 数据正确性难以确定：随着数据的复杂度越来越高，数据链条越来越长，数据源越来越多，保证数据的正确性及验证数据将成为一个很耗时的问题。
• 数据管理复杂：业界对数据的可解释性、可管理性要求越来越高，各种新存储架构的加入，使得元数据管理和数据流程标准化更加复杂。
• 数据安全管理复杂：如果无法保证数据安全，数据就是不可用的，数据合规使得数据安全成为刚需，这里要求能够支撑多级数据安全策略、数据链路可追溯、敏感数据可加密。
• 数据权限管理：在数据赋能的体系中权限控制是很关键的功能，需要实现各种级别的数据权限，组织架构、角色、权限策略自动化，以及对新的计算架构的权限管理。
• 数据成本高，难以量化：数据成本包括集群成本、运维成本、人力成本、时间成本等，持续系统地计算这些成本需要在系统架构中加入相应的统计接口，而现有的大多数平台并没有将这些接口考虑在内。

数据中台建设的人员规划

在数据中台的建设中，除了传统的大数据团队以外，还需要业务部门的积极参与。因为共享的数据能力是与业务相关的，而且开发和迭代的流程需要与各个业务部门、IT部门协调沟通，所以在建设数据中台时需要对参与人员进行统筹安排。这也是我们在数据中台的规划过程中经常碰到的问题。下面列出了数据中台建设过程中一般会涉及的人员及其主要职责。

• 业务部门主管：深入了解业务流程和优先级，能够将业务场景与数据对应，指导建模的流程。
• 业务系统架构师：了解企业的系统架构、技术框架。
• 业务流程工程师：对业务流程非常熟悉，通常是技术部门与业务部门的纽带。
• 数据工程师

数据平台工程师：通常有系统工程师背景，负责建设和运维数据平台，安装和运维各种大数据组件，以及保证数据平台的性能和稳定性。

数据开发工程师：以数据仓库技能为背景，懂业务，负责建模、数据清洗和编写ETL程序。数据应用开发工程师：以应用开发为背景，开发服务于业务部门的数据应用。

• 数据中台架构师：全面掌握数据平台的功能，对公司的产品提出数据的支持和要求，负责公司产品与数据平台的集成、与业务系统进行衔接的架构规划以及公司的数据标准推动和把控。
• 数据分析师：以统计学背景为主，能够从数据中产生合理、准确的商业智能报表。
• 数据科学家：以机器学习为背景，提供基于机器学习和人工智能的数据分析产品和结果。
• 数据产品经理：负责公司内部数据能力的规划和开发流程的协调，有时这个角色由数据架构师承担。

下图列出了以上主要角色与数据中台各个组件交互的对应关系。

数据中台团队角色

由于建设阶段不同，角色可能会有细微变化，如在数据中台建设的早期阶段，可能每个部门都有数据应用开发工程师、数据分析师、数据科学家，或者需要这些角色的参与。

数据中台建设团队的组织模式一般有两种。一种是去中心化的数据中台搭建模式，这种搭建模式下一般有一个数据平台团队来打造这个“数据中台”，然后各个业务部门（一般都有自己的开发团队）在这个平台上开发和使用自己的数据应用。通过这个数据运营平台，在有共享和复用需要的时候，各个业务团队可以快速共享自己的数据能力。这种模式在硅谷比较普遍，好处是比较容易推进，因为数据中台实际上分为两部分：一部分是数据技术，这一部分最好由数据平台团队负责；另一部分是业务数据能力，这一部分最好由业务部门的人完成，因为他们最理解业务，并且业务也是经常需要迭代的。这种模式的难点在于数据平台团队的业绩难以直接衡量，而且推行统一数据标准需要业务部门积极参与和配合，在业务部门比较繁忙的情况下难以协调。

另一种模式是组建一个专门的数据中台团队，并由中台团队来负责所有共享的数据能力的规划和开发，它相当于公司内部的一个支持团队，负责满足其他部门的需求。这种模式的好处在于数据能力的规划和实现比较直接，难点主要在于数据中台团队需要理解业务，在业务快速变化的情况下迭代速度不一定能跟上，而且数据中台团队会和各个业务部门产生一定的职能冲突。

下表列出了两种模式的一些对比。

集中式与去中心化的数据中台实现对比

对于具体企业而言，到底应该采用何种模式来实现自身的数据中台，主要看企业所处的阶段以及企业的真实需求，必须实事求是，根据企业的实际情况来做出更优的选择。

实际上，数据中台与技术中台不一样，数据是跟着业务走的，而技术的共性比较多。让数据中台部门天天跟着业务部门学习数据显然不现实，Twitter、Facebook、Airbnb等硅谷公司的做法是，大数据部门提供足够好用的工具，赋能业务部门共享数据能力。而有些公司的情况又不一样，它们将某项能力抽取出来由专门的组来负责。这两种方式各有优势，因此要视公司的具体情况而定。而国内有些行业的大数据平台建设往往是搭建一个Hadoop集群且仅供该部门内的项目使用。其他部门需要大数据应用时，由于没有一个很好的大数据平台架构，使用这个部门的大数据平台会非常困难，最后只能再独立搭建一个Hadoop集群。这样就会产生大量的数据孤岛和应用孤岛。

因此，最好在建设大数据平台之初就要求各个部门共享集群，每个数据应用都必须接入现有的平台。