前言

数据中台的概念从刚刚提出时的火热到最近的降温，似乎已经加速走过了Gartner技术成熟度曲线的一半周期：从出现，到受吹捧，到遭质疑，再到进入低谷。数据中台将逐渐消失，还是在成熟后成为像数据仓库一样的数据基础架构？最终的答案当然要由市场给出，但我们想在本书中基于我们的经验与思考，介绍数据中台出现的根本原因、它在实现数据价值中的关键作用以及它的建设方式。

对于数据的价值，在大数据概念普及多年后的今天，大家应该是普遍认可的。我一直都在从事与数据相关的工作和研究，1996年在武汉大学跟随何炎祥老师做分布式数据挖掘方面的研究，2000年在美国马里兰大学做流式数据引擎相关的探索，2005年加入Ask.com做分布式操作系统的数据存储工作。2008年大数据概念出现，我在Ask.com做了一个非常明智的决定——使用开源的Hadoop（而不是我们内部的分布式操作系统）替代日益昂贵、不堪重负的Oracle数据仓库，虽然我们的内部系统比Hadoop快一个数量级。替换了Oracle之后，我们还基于Hadoop平台开发了一系列数据驱动的产品，满足了不断增长的数据产品需求。2011年，我加入Twitter并负责大数据流水线的建设，我在实践中看到公司如何从数据中获取价值，实现整个企业的数据驱动。与此同时，我也与硅谷其他公司同行进行了广泛的探讨，这些使我坚定了自己的认识：未来的企业一定是数据驱动的企业，未来的大数据一定会和Word、Excel、数据库一样，成为企业运营人员的必备技能。

虽然数据的价值得到普遍认可，企业数字化转型的必要性也是大部分CEO的共识，但业界对一个关键问题的看法还远没有达成一致：数据中台是不是支撑企业数字化转型的最合理的数据基础架构？在我们与国内企业交流的时候，很多企业的CEO、CIO仍对数据中台到底应该是什么形态有不少疑问。与之不同的是，硅谷的大多数知名独角兽公司有与数据中台架构相似的数据基础架构，即数据平台（Data Platform），并以此作为企业数字化运营的基础。这些数据平台虽然没有被称为中台，但却包含了我们通常认为中台需要承载的任务：打通企业各个部门之间的数据，形成统一的数据开发和使用规范，在企业各个部门之间实现数据能力的抽象、共享和复用。因此，本书试图找到这些数据平台的架构与国内普遍认可的数据中台架构之间的通用理念，并从对业务的实际需求层面探讨这些架构设计理念的合理性和必要性。

与传统技术中间件不一样，数据中台虽然也是承接底层数据和上层业务的中间层，但它的价值更多体现在与业务结合的能力矩阵，而不是简单的数据标准化和报表工具上。各个业务部门可以使用不同的技术中间件，这样虽然效率可能低一些，但是同样可以满足业务的要求。然而，分割的数据层无法对核心业务流程进行全局还原和支持，无法实现数据驱动的全局决策和产品研发。与传统的数据仓库受事前建模的限制不一样，数据中台一般使用数据湖来存储可以反映全局业务情况的原始数据，能够对核心业务流程进行更全面、更深入的分析，并在此基础上加快对市场的认识和反应，降低产品研发和试错的成本，缩短时间。因此，定义好业务能力矩阵，让业务部门看到数据中台实现从0到1的关键数据能力，将大数据平台从成本中心变成利润中心，应该是每个企业建设数据中台的目标。

除了确定对于业务的价值之外，建设数据中台的一个根本问题是技术架构的选择及设计。我在Twitter架构师委员会担任负责大数据平台的架构师期间，每个星期都会参加由CTO组织的产品架构评审和讨论会。这些会议给我留下最深印象的不是对各种前沿技术的讨论，也不是架构设计中的技术难点攻关，而是技术架构对业务的重大影响。很多时候，我们看到一个快速发展的业务因为早期架构设计的问题而难以迭代，或者企业的发展受限于IT部门的效率。而一个高效的架构能够解放业务部门的生产力，真正赋能业务人员去完成以前想都不敢想的任务。其实数据中台这个概念会在国内出现，很大程度上也是因为架构的问题。试想一下，如果我们在设计大数据平台的时候就已经考虑到了消除数据孤岛、应用孤岛，统一数据规范，那么还需要单独建设一个数据中台吗？

因此，我们在本书中讨论了云原生架构对于数据中台的必要性。数据中台的一个天然特性是支持多元异构的数据以及处理这些数据的工具。虽然很多时候孤岛的产生有组织架构的原因，但是缺乏统一的数据平台，无法快速支持不同部门对数据的不同需求，这些也是产生孤岛的重要原因——因为业务部门需要不断建设独立的系统以满足眼前的紧迫需求。在Twitter的大数据平台建设过程中，公司规模从300人发展到4000人，集群规模从80台服务器扩展到8000台服务器，利用云原生架构我们快速满足了各个部门对不同数据的需求，并极大简化了统一数据规范的工作。各个业务部门可以快速自主地在平台上开发自己的数据应用，很少需要额外的系统支持，从而大大降低了出现孤岛的可能性。随着云平台及容器技术的不断成熟，我们认为云原生架构一定是未来数据平台建设的必然选择。

当然，选择一个合适的技术架构只是数据中台建设的开始，明确了最终目标也不能保证实施一定会成功，我们还需要清晰的实施路径和可落实的方法论。例如：建设数据中台是否需要改变组织架构？如何进行顶层设计以及管理实施迭代？我们认为，虽然数据中台是一个复杂的项目，但是其建设流程是非常明确和可控制的。与业务中台建设一般需要与业务组织架构对齐不同，数据中台建设很少要求对现有业务流程进行大的改动，它的目的是深刻理解当前的业务流程，提出优化建议并提供能力支持。因此，数据中台落地应该采取业务驱动、快速落地、小步快跑的方式，而不是一开始就做一把大而全的“万能钥匙”。在这个过程中，使用合适的指标体系衡量数据中台的投入产出比，以及提供合适的工具赋能业务部门，有助于数据中台得到业务部门的支持和认可，顺利完成中台的实施。在本书中，我们根据自己的经验和业界的一些成功实践对数据中台建设方法论进行了深入的探讨，希望能对读者有所帮助。

1995年，我作为一名程序员参与了中国农业银行武汉分行办公自动化系统的建设，此后25年，我有幸在国内和美国硅谷见证了IT技术为企业带来的运营效率的巨大提升。虽然一直在一线，参与了很多有挑战的技术工作，但是让我收获最大的还是作为企业技术管理者和数据负责人，与CEO、CMO、CIO一起探讨如何用数据为企业产生价值，以及作为架构师来推动OA、数据仓库、ERP、CRM、大数据、人工智能在企业的各种复杂场景中的落地。对这两个方面进行交叉审视，可以发现技术架构和业务能力间的独特连接：二者看似没有必然的因果关系，但在深层次上业务能力永远是技术架构的推动力、决策者和买单方。从这个角度来讲，数据库的出现解决了交易的问题，数据仓库的出现解决了关系型数据高维度的深度分析问题，大数据的出现解决了海量异构数据的存储和分析问题，而数据中台的出现是为了解决业务打通和提供全局数据能力的问题。数据库、数据仓库、大数据已经成为企业IT架构不可或缺的部分，我们认为，无论数据中台这个名称是否会继续存在，它所涉及的问题都是企业的数据基础架构必须解决的。因此，本书重点讨论了对于业务需求和架构设计而言数据中台这个概念出现的必然性，也深入介绍了架构选择与业务需求之间的联系，试图为正在解决这些问题的企业和机构提供一些架构设计和落地方案上的参考。

本书是智领云团队协作的结晶，除了署名的三位作者之外，产品经理王龙飞、王纯、黄艳以及设计师龚清、市场部刘丹等也在本书的内容组织、图片设计方面做了大量工作。此外，非常感谢机械工业出版社华章公司的编辑杨福川和罗词亮，他们在本书的写作过程中提供了大量的帮助和反馈，让我们得以顺利完成本书的写作。

希望本书能在应对数字化转型挑战方面为读者提供一些思路和参考，感谢大家的支持。

彭锋

2021年4月