数据中台建设：千万级的瀑布式，和十万级的迭代式，你会选择哪一个？

2023-04-21
江苏
本文字数：5932 字
阅读完需：约 19 分钟

中台十年，再看已成桑田。

最初，为了解决互联网行业快速发展催生出的海量数据累积和碎片化问题，企业开始尝试将数据整合到一个中央平台，以提高数据的使用效率和管理水平，中台建设雏形初现。巨头领跑之下，从“大中台”到“拆中台”，再到“去中台”，中台似乎已经以极快的速度跑完了作为一个新的方法论从越炒越热到逐渐落寞的一生。

但中台的发展果真要止步于此了吗？

一、中台「陷阱」：画皮不画骨的浅表模仿

为搭建中台，某制造业公司先后投入一年半的时间和 6000 万元的资金成本。但这样一个耗费大量资源的“中台成品”，在实际运行中却发挥的价值却未能达到预期。一方面是因为中台在搭建初期没有充分考虑到业务需求和数据质量问题，导致后期无法对接业务；另一方面是因为中台的建设缺乏数据治理和数据质量保障，导致数据质量不可靠，业务部门不愿意使用。最终，中台被认定为一场“失败的投资”，投入成本无法收回。

无独有偶，某公司为了搭建中台，需要引进专业的技术人才进行支持和维护。然而，由于技术人才的稀缺性和高昂的薪资要求，公司不得不将大量的资源投入到技术人才的招聘和培训上，导致其他部门的资源被迫压缩，业务发展受到阻碍。中台的建设和运维也受到专业技术人才变动的制约，牵一发而动全身……

类似的“中台翻车”传闻还有很多，不同于初时的舆论一片向好，眼下提及“中台”，第一时间更多会联想到资源投入过大、极其依赖专业技术支持、无法及时验证效果、高风险等，这些多被诟病的问题。

事实上，关于中台的发展与价值，在舆论层面和实践层面一直是存在割裂的——当中台理论被捧上“神坛”，塑造为解决企业一切数字化问题的“万能银弹”之时，虽不断有新的企业或从旁观望，或借鉴模仿，却一直未能在实践中得到广泛且有效的复制，对中小企业而言尤是如此；但伴随着中台理论的舆论性退热与“唱衰”渐起，反倒有越来越多的企业开始真正拨开迷雾，研究起了中台建设在过渡营销的泡沫下，所掩盖的本质，也即“中台”的核心价值。

换言之，潮水退去，中台作为一个 IT 架构和企业组织模式变革理念，仍在不断优化和演进，而其真正具备积极意义与借鉴价值的内核，也正在逐步显露真容。

借鉴核心思想，而非形式模仿

所谓溯本清源，在研究“要不要建中台”这个问题之前，企业需要知道自己真正追求的目标是什么，想要通过中台解决什么问题。显然，答案不会是搭建一个空中楼阁式的华丽中台，却因为无法适配自身业务需求与组织架构而导致运转失败，最终不了了之——而这恰恰是中台建设问题上，容易掉入的“美丽陷阱”——跟风下倾力打造的千万级数据中台，空余“形似”，而忽略了中台建设的长远价值和战略意义。

脱离实际谈建设，都是耍流氓。

舍本逐末搭建起的“伪中台”不仅不能真正解决数据孤岛的问题，也无法发挥中台所应具备的数据共享和数据协同的作用，更无法为业务创新和效率提升带来实质性的贡献，一番折腾下来，只剩下传统中台的那些弊病构成的一地鸡毛，遂得出结论——“中台误我”——这口“锅”终归还是让中台背了。

而破题的关键就在于去粕存精——既然知道陷阱在哪儿，那就绕开它，直接抓取并拆解中台理论的核心思想，跳过形式，实现本质上的革新。

那么，这里所说的“中台”的精华又是指什么呢？

服务化：中台建设的灵魂

在回答这个问题之前，我们得先弄清楚何中台的价值。

以零售行业为例，新零售时代当前，企业依托电商平台与社交平台大力推进线上销售业务，社交电商及电商市场规模不断扩展。这些平台为零售行业提供了更多的营销和销售渠道，极大地丰富了消费者的购物选择和体验。同时，这也意味着零售企业需要整合更多渠道的客户、订单和库存等信息，以便更好地管理其业务并优化其供应链。面对这样的需求，中台首先可以作为一个数据中心，对内对接企业的订单管理、库存管理、供应链管理、财务管理等系统；向外对接呈现给消费者的购物车、支付、物流追踪、售后服务、客服等，通过集中整合管理各个渠道、系统的数据，实现数据的一致性和准确性。一方面可以让消费者可以获得更加流畅、便捷、高效的购物和售后体验，另一方面也为企业提供更准确、及时的数据分析和决策支持，提高内部运营效率，优化服务质量。其次，中台的灵活性和可扩展性也为企业提供了更大的自由度，从而根据业务需求进行定制化的开发和集成，帮助企业更好地应对市场变化和不断变化的消费者需求。

以制造业背景为例，企业内部有很多系统和业务场景，可分成两类：一类是内部使用的、不面向用户的系统，像是 ERP、BPM、MES 等，这些系统构成了企业的后台；另一类则是面向用户的可视系统，例如 CRM、渠道管理系统、客户服务中心等，这便是前台；而中台顾名思义，就是连接后台和前台，提供业务能力服务的平台，可以为企业提供数据、业务流程、资源调度等基础服务，让企业的前台系统更加高效、智能化，提升整体生产力和客户体验。

由此可见，数据中台本质上是一套结合互联网技术和行业特性的企业数据架构，通过将企业核心能力以共享服务的形式进行沉淀，形成一个具有开放性、共享性、可扩展性、可复用性为主要特征的中间平台，用于整合和管理企业内部和外部各类分散的数据和资源，为业务提供快速的数据准备能力，是为业务创新赋能，提高业务创新的效率的关键机制。中台的重要性正在于此。

当我们了解了中台理论的作用原理，也就抓住了它的精髓——服务化——其核心是将企业的核心数据进行沉淀和转化，形成一组自带“万能插头”、可供内外部随时调用的服务。

于是，我们得出了这样一条结论：数据中台理论符合时代发展诉求，对于谋求进一步转型升级或者降本增效的企业而言，仍然具有无可替代的价值，但借鉴绝不是形式上的照搬，而是因地制宜地“移植”——取其“服务化”精华，去其“无视风险、盲目投入”的糟粕。

既然动辄千万级的数据中台建设不可取，那么我们又该如何在技术层面突破传统桎梏，利用什么样的技术或工具，实现合理、低成本构建一个务实、业务价值导向的中台？这当中使用什么样的技术或工具呢？

二、由大化小，拆分迭代：从现代数据栈的崛起中看到的新思路

这就得先聊聊我们在面向分析领域的数据技术路线变迁里看到的一些有趣变化。

目前，当企业希望提高经营洞察，构建一个以数据分析为目标的数据平台时，有两个技术路线可以选择：

一是以 Hadoop 技术生态为代表的大数据体系；

二是以 Snowflake、Fivetran、DBT 为代表的现代数据栈。

以下是对两种技术栈的一些分析：

Big Data 的陨落

A 团队: 立一个大数据项目

在传统的技术栈中，数据处理主要依赖于大数据技术，如 Hadoop、Spark 等，这些技术主要面向离线批处理，适合对大量数据进行处理和分析。然而，当前的互联网应用场景对数据处理提出了更高的实时性和交互性需求。

大数据正在逐渐被时代发展边缘化，其发展在一定程度上出现了问题，其中比较有代表性的几点包括：

长时间的设置和学习过程：建立和学习大数据系统需要大量的时间和精力。从采集数据开始，到数据的清洗、处理和存储，再到对数据进行分析和应用，这个过程需要不断地调整和改进，使其适应不断变化的业务需求和市场趋势。

对新信息的响应缓慢：大数据分析系统通常需要在大量数据上运行模型和算法，以找到有用的信息和趋势。这个过程需要消耗大量的计算资源和时间，所以它的响应速度相对较慢，可能需要一段时间才能产生有意义的结果。

洞察的成本消耗较高：在大数据分析过程中，需要大量的技术和资源投入，包括硬件和软件的设备、人才的培训和招聘、以及数据的存储和处理等。这些成本很高，可能会让企业和组织在决定是否要投资大数据时感到犹豫和困惑。

很多大数据项目只能做到数据的收集和存储，但对数据的应用却无从下手。因此，尽管有些项目在一两年的时间内取得了一定成果，但往往也只能搁浅在这个阶段，无法进一步推进。由于大数据技术栈庞大且复杂，规划和人才配备需要大量的时间和资源，且一旦需要调整或改动，投入的成本也非常高。

此外，历史数据的采集和存储对于大数据而言也是个棘手的问题。虽然历史数据在大数据分析中也存在价值，但对于许多业务场景来说，最有价值的数据通常是最新的这一部分。很多时候需要对这些数据进行实时收集和分析，以便及时做出决策和调整。而大数据技术对于存储、计算和使用数据的成本都很高，相较于产生的价值来说，其代价实在是过高了。

因此，从 2018 年开始，大数据领域的三大厂商 Cloudera、MapR 和 Hortonworks 相继被收购或合并。对于陷入瓶颈的大数据而言，发展的颓势已是避无可避。

现代数据栈的升起

B 团队: 小步走，使用现代数据栈，快速迭代

大数据的发展现状正在催促我们引入更加灵活的技术栈，现代数据技术栈（Modern Data Stack，MDS）的概念由此被提出，并获得越来越多的认可。其基础定义为：“由于云数据仓库的兴起而出现的一系列数据工具生态系统”。

现代数据技术栈是由于云数据仓库的兴起而出现的一系列数据工具生态系统

翻译过来就是，将我们数字化建设过程中所需要的工具拆分成各个模块，然后从问题出发，根据业务需求选择需要的模块，而不是像过去那样，一口气建立一个大一统的数据平台或数据中台。现代数据栈通常结合了云数仓等云服务，并展现出如下几点关键特征和优势：

云原生、可托管：现代数据栈通常是云原生的，可以在云平台上构建和托管。这意味着可以随时增加或减少计算和存储资源，并且可以灵活地扩展或缩小规模。这种可托管的方式能够帮助企业降低运营成本和管理负担。

可组合、可插拔：现代数据栈的组件通常都是可组合和可插拔的。这意味着企业可以根据自身需要选择和组合不同的组件来构建数据处理流程。这种灵活性能够帮助企业快速适应不同的业务需求和数据场景。

迭代式：相较于传统的中台或大数据项目自上而下的开发方式，现代数据栈更倾向于采用迭代式的方式进行构建和演进，具有敏捷开发、轻量级和可扩展、开放性和组件化等差异，能够更快地响应业务需求和变化，并且能够通过持续集成和持续部署等方式实现快速迭代和交付。

自助服务：无需供应商介入即可完成自助选型，非技术专家也能够轻松地使用数据处理和分析工具。这种自助服务的方式能够帮助企业降低对技术人员的依赖，同时也能够更加快速地实现业务需求。

从源头开始，数据会经过数据接入采集、加工处理和业务价值展现等步骤。现代数据栈据此提供了各种各样的工具，包括云上的数仓、集成的工具以及分析工具等，可以帮助企业在短时间内完成一个快速的项目，时间成本可压缩至周为单位，资金成本则可低至几千到几万元，甚至可能免费。

相比于传统的大数据技术栈，现代数据栈更加注重服务化。或者说，现代数据栈本身就是一种服务化的技术栈，同样强调面向全业务支撑和交互式业务，允许用户使用多种不同的工具和技术来管理和处理数据，旨在提供更加全面、灵活、高效的数据服务，更好地支持业务需求，帮助企业更好地实现数字化转型。

现代数据栈的发展模式下，企业如果能在正确的环节选择正确的工具，则无异于为自身的数字化转型开了个事半功倍的好头。那么，如果我们将这样的理念应用到我们上文提到的面向全域业务的数据中台建设呢？

三、以现代数据栈理念来建设数据中台

首先，让我们参照现代数据栈的逻辑，按照不同的功能模块对数据中台进行拆解。

数据中台通常包含包含以下几层架构：

数据集成层：负责将不同数据源的数据整合到一起，并进行必要的数据清洗和转换。
数据存储层：负责将数据存储在统一的数据仓库中，并提供高效的数据查询和存储能力。
数据开发层：为数据分析师和开发人员提供了一系列工具和平台，使其能够快速地开发和部署数据分析应用和数据产品。
数据治理层：负责管理和维护数据的元数据、标准、质量等，保证数据的正确性、一致性和可靠性。
数据服务层：为企业内部不同的业务部门、数据分析师以及外部客户等提供数据服务，推动数据成为企业价值的重要组成部分。

这些模块分而治之，共同构成了一个可扩展、可维护的系统，数据经由每一层流转，最终形成企业所需的高价值、可复用的珍贵资源。而在这个过程中，每一个或多步骤都可以有一个独立的工具或产品来完成。这就又涉及到企业该如何选型的问题。

以下是针对不同环节的一些常用方案或工具的列举：

数据集成：Fivetran / Airbyte / Tapdata
数据存储：Hive / MongoDB / Doris
数据开发：DBT / Tapdata
数据治理：Atlan / Informatica

这时，为了从源头上避免传统中台建设场景下常见的，因一次性投入过大却无法实现预期目标的风险，企业可以采取迭代式推进的方式，逐步实现数据中台的构建。

先按照实际需求，在综合考虑包括企业规模、业务复杂度、系统数量、支持业务场景的多少、业务价值、预算以及人力资源等在内的一系列因素的前提下，确定一个初步的数据中台架构方案。再根据这个方案，选择一个或多个关键模块，进行搭建、测试和优化，并在这个基础上分阶段、逐步建立数据中台的基础设施和数据资产。除了能有效降低投入产出风险，迭代式推进还可以让企业在整个搭建过程中不断积累经验和知识，为未来的数据分析和业务创新提供更加可靠的支持。

下面我们就来从这里的“第一步”，往往也是数据平台搭建最为关键和价值点最明显的一部分——打通数据，入仓出发，来看如何落实服务化理念与现代化技术栈的完美融合。

四、从传统数据集成架构到数据服务架构的升级

就以 Tapdata LDP（Live Data Platform）为例，作为“数据中台的服务化理念 + 现代技术栈模式”在产品层面的实现，其本质是一个自带实时数据复制能力的数据即服务（DaaS）平台，能够以无代码方式快速连接企业的数据孤岛，将数据实时集成到中央数据平台，形成可复用的标准数据模型，为多个下游交互式应用提供始终新鲜的数据。