导读
“不做会死，做了送命”，大概没有什么信息化建设像中台一样，拥有这如网红般的争议吧。大约从2019年上半年开始，“数据中台”这个词，相信大家或多或少都听到过，俨然已经成为了大数据领域的新任“网红”。那么数据中台究竟是“新瓶装旧酒”，还是真正可以助力企业的“大杀器”？本文主要从数据中台的前世今生，到典型企业的数据中台架构，再到企业究竟需要什么样子的数据中台，多个视角对数据中台进行解读。
数据中台从何而来
在谈论数据中台之前，不妨先看一下大数据的发展历史
有迹可循的大数据思想萌芽，可追溯至1974年，当时有学者在论文中首次提出了“大数据集”的概念，但一直到1991年，Bill Inmon出版了《建立数据仓库》一书，才真正算是在大数据领域有了被广泛接受的“数据仓库”定义。随后，在20世纪初，数据处理量达到TB级的情况下，数据处理、展现应用于业务带来的提升，学界的广泛认同和商界的快速产品化，证明了数据仓库的历史意义与价值。
2003年，可以被认定是大数据的第一个重要里程碑，在这一年，Google公开了一系列其内部实践的“海量数据”处理技术，也就是我们常说的Google三驾马车——基于冗余存储机制的分布式文件系统GFS、用于搜索索引计算的并行处理框架MapReduce、高效数据存储模型BigTable，随后便促进产生了大家更为熟知的分布式系统基础架构——Hadoop。
后面的历史便不多说了，本文的目的毕竟不是为了科普大数据，从大数据发展的编年史，也许能看出一些端倪，为什么数据中台会在短短数年内从默默无闻到炙手可热。从2011年开始，大数据的发展仿佛进入了高速公路，无论是国际知名组织，还是国家层面，都将大数据上升到战略级地位。伴随地位的提升，大数据领域的研究在广度和深度上都不断得到拓展，从早期以硬件、网络为主的单一领域分类，扩展到平台化及场景化的数据仓库、元数据管理、主数据管理、数据质量、数据安全、数据科学等多元的领域分类。与此同时，数据仓库的概念正在被外延——衍生出“大数据平台”、“商业智能”以及“数据湖”的“逻辑数据仓库”概念，数据处理量从TB级跃升至PB级，开源的Hadoop生态正式开始商业化，数据中台在这个时期脱颖而出，也似乎并不突兀。
不过，无论是数据仓库还是大数据平台，商业智能还是数据湖，其发展似乎一直伴随着一面看不见的墙，那便是关于大数据价值的探索。首先我们先看看在当时国内外大数据领域的主要玩家都在干什么。
Amazon、Google、Microsoft、Oralce均在自身强势业务之上，开启商业化的云计算和大数据服务；Informatica聚焦大数据领域，推进其SAAS化的大数据产品及平台；大数据新贵Palantir，则在其助力美国政府抓捕本拉登而一战成名的大数据风控及其第三方数据服务上，不断拓展数据应用的边界；回到国内，阿里云、腾讯云、电信天翼云、华为云等均在云计算及大数据领域投入了大量人力和物力。在这个大数据发展的黄金期，几乎所有的高科技企业都在思考一个问题：
海量数据作为大多数企业发展不可避免的一个趋势之后，企业该怎么去应用这部分数据资产，会对其商业产生什么影响，如何使数据对企业产生正面的推动而不是成为企业的负担。
作为国内的主要大数据玩家，阿里在2015年时提出了“大中台、小前台”的战略，奠定了其内部发展数据中台的基础。其实这件事情毋需过多挑战，国内有很多厂商怀疑数据中台的价值或者认为其是“新瓶装旧酒”，但作为阿里数据中台内部建设和对外商业化的亲历者，笔者确实见识了阿里内部数据中台对其生态带来的巨大推动作用，也见到过其在对外做数据中台商业化输出时遇到的水土不服，为什么会产生这种现象，透过现象看本质，接下来我们就从多个角度来看。
数据中台的多视角解读
从去年甚至更早开始，很多企业，包括互联网企业和传统企业，开始纷纷的提数字化转型并建设自己的中台模式，那就带来这样一个问题，就是数据中台该如何定义，或者说该怎么理解它，包括我也跟数十家企业的沟通交流过程中，听到过他们很多这样的困惑，比如说数据中台它是不是一个数仓，或者数据湖，它究竟是一个技术体系，还是一个具象的产品或应用，有很多不同的理解。
我们可以先了解一下阿里对数据中台的定义。
数据中台是一套数据资产化和价值化体系。它致力于构建既“准”且“快”的“全”“统”“通”的“智能”大数据体系；它在数据赋能业务中形成业务模式，在推进数字化转型中实现价值。
不难看出，阿里的数据中台主要核心将其定位为数据资产化和数据价值化，那么阿里究竟是怎么做的呢？
上图是阿里数据中台发展至今的一张全景图，大家应该在云栖大会等多个场合有看到过这张图。阿里数据中台的整体核心其实是位于中间的三层数据中心：垂直数据中心、公共数据中心和萃取数据中心。
- 垂直数据中心：阿里通过将包括淘宝、天猫、聚划算、阿里妈妈广告、优酷土豆、高德等来自不同BU的数据进行采集，在清洗和结构化处理后形成垂直数据中心
- 公共数据中心：在垂直数据中心已采集数据作为原料的基础之上，采用维度建模的方式，以业务过程作为粒度切分，处理成不因业务特别是组织架构变动而轻易推翻的数据中间层，由DWD明细层和DWS汇总层共同构成
- 萃取数据中心：更进一步以客观业务实体（如人、货、场、企业等）为对象，围绕其建立起以统计指标、标签、关系等数据为主的数据体系，作为直接面向业务的萃取数据中心
仅从这三层数据中心构成的数据资产体系来看，阿里的架构似乎并无太多先进之处，除萃取数据中心外，垂直数据中心和公共数据中心都能在数仓建模中找到其对应的架构，即便是萃取数据中心，在一些企业的商业智能或者大数据平台层面也能找到相应的雏形。所以，阿里数据中台的核心竞争力究竟是什么呢？
答案就是——“方法论”
阿里在建设自身数据中台的同时，花大精力对其数据架构、技术、流程、组织等实践形成了一套完整的方法论，并作为其不断迭代的指导性理论——OneData，其中包括OneModel（用于指导数据采集、数据建模、数据开发的规范性方法论）、OneID（用于指导打破部门墙的数据连通，在业务对象层面形成直接面向业务的数据体系规范性方法论）和OneService（用于指导如何提供数据服务，包括质量安全、资产管理、数据交换、组织协作等流程的规范性方法论）
有了这套方法论，对于阿里来讲，无论对其自身数据中台建设，还是对外输出解决方案，都提供了非常大的助力。
除了阿里，我们再看看其他企业是怎么做的。
无论是华为、OPPO为代表的高科技制造行业，还是网易、滴滴为代表的互联网行业，都纷纷在自建或者提出了数据中台的解决方案，但是我们又发现，每一家企业似乎对数据中台都有自己不同的理解，这点从四家企业的数据中台架构图就可以看出。
看到这里，是不是大家对数据中台的定义又更模糊了呢。接下来，我们站在企业用户的角度，从三个维度分析企业理解的或者说想要的数据中台到底是什么样子的。
- 从管理视角看——为什么是数据中台而不是数据XX
- 从技术视角看——数据中台与数仓、数据湖到底有没有本质区别
- 从业务视角看——企业需要什么样子的数据中台
从管理视角看——为什么是数据中台而不是数据XX
站在企业用户角度，尤其是中小企业老板，有一个非常关键的问题：“我到底需不需要数据中台？”
当商务同学费尽心思约到了客户老板，售前架构师熬了几个通宵准备了长篇大论的介绍材料，产品技术准备数据和环境，搭建了完善的演示平台，一切似乎都万事俱备，但最后老板听的昏昏欲睡，讲完后拍拍手客套几句，最后仍然不了了之。
相信很多toB的同学都遇到过吧，为什么会出现这种现象，因为绝大多数的企业老板（尤其是传统企业）一般不会关心你讲的是信息化还是云化，是大数据还是AI。但是正视威胁，业务竞争力的提升，以及通过机器长期吸纳业务专家的经验来优化人才结构，最终形成一个有竞争力的组织，这类战略和组织的问题，老板一定关心。
很多老板都在喊数字化转型，那么怎么转，转成什么样？恐怕大多数的老板都回答不上来。
数字化企业是以客户中心为基础，以科技为引领，在统一愿景下建立了实时战略机制和敏捷生态的生机型组织。
这段引用自ThoughtWorks对于数字化企业的定义，私以为非常准确，在当今互联网时代，客户是商业战场的中心，而为了快速响应客户需求，必须依靠平台化的力量才可以事半功倍。尤其是随着互联网巨头以平台的方式对各行各业带来的巨大影响，越来越多的企业主有了这样的危机意识：“自家企业要么平台化，要么成为平台的一部分”。
那么如何使自己的企业能够适应平台化，在企业的数字化转型中，客户正在变得越来越重要，不断快速响应、探索、挖掘客户的需求，才是企业得以生存和持续发展的关键因素。当企业与客户的触点越来越多，可以利用的数据越来越丰富，传统数仓或数据平台无法整合和打通拥有如此复杂业务逻辑的数据；企业传统的前台+后台的架构也已经无法做到对业务的快速响应；原有信息化系统与业务KPI脱节的现象也早已不能满足数字化企业的管理需要。
数据中台，在这个角度，正好与企业的需要不谋而合。
数据中台是为前台业务而生，它提供了一种数据与业务之间协作发生化学反应的最佳模式。数据中台形成可共享复用的数据资产，并且拥有与业务更近的关系（一般情况下的数据中台是要扛业务KPI的），让企业首次有了数据驱动业务的能力，以及随之带来的对组织和人才结构的优化，这些才是数据中台真正的竞争力。
数据中台是买不来的，虽然说离不开各种自研或采购的工具平台，但是，唯有管理者认识到，只有建立一个数字化、敏捷化，拥有快速业务响应能力的组织，才有资格进入这场战争；做到尊重客户，不惜调整自己颠覆自己来响应客户的企业，才能在这场以客户为中心的商业战争中得以生存和发展；而拥有一个强大的，足以随时快速和精准提供源源不断弹药的数据中台，才有可能赢得这场战争。
如果一个企业主没有认识到这一点，无论各大云计算或大数据厂商提供的产品多么智能，解决方案多么强大，都无法打通老板的心。
所以与其说是某某厂商提供了“数据中台”，倒不如说是企业用户自己命名了“数据中台”。
从技术视角看——数据中台与数仓、数据湖到底有没有本质区别
| 特性 | 传统数仓 | 数据湖 | 数据中台 |
|---|---|---|---|
| 数据 | 结构化数据为主 | 结构化数据、半结构化数据、非结构化数据 | 结构化数据、半结构化数据 |
| Schema | 设计在数据仓库实施之前（Schema-on-write） | 写入在分析时（Schema-on-read） | 设计以逻辑模型进行，在数据使用前写入和处理数据（混合方式） |
| 性价比 | 较高存储成本 | 较低存储成本 | 较低存储成本 |
| 数据质量 | 可以作为重要事实依据的高度监管数据 | 任何可以或无法进行监管的数据（如原始数据） | 以业务为导向，任何可控制、可计量、可变现的数据（数据资产） |
| 数据加工处理 | 以SQL、UDF为主，按需加工，主要处理离线数据 | 以SQL、UDF为主，按需加工，离线和实时数据均有 | 以数据模型为主，通过产品工具自动化处理 |
| 数据访问方式 | 通过标准化SQL或BI工具 | 标准化SQL、BI工具或大数据分析工具 | 标准化SQL、BI工具、大数据分析工具或者任何支持API对接方式的程序或系统 |
| 数据资产管理 | 无 | 无 | 有 |
| 数据产品开发 | 无 | 无 | 有 |
| 使用者 | 数据分析师 | 数据分析师、数据开发人员和数据科学家等专业人员 | 业务人员（业务一线员工和业务leader）、专业人员（数据分析师、数据开发人员和数据科学家） |
从技术视角看，数仓、数据湖和数据中台的区别主要在于其数据加工处理、数据提供服务以及面向对象方面的改变。下面我们分别来看一下其之间的一些差异和对比。
先看数仓和数据中台，20多年前，数据仓库出现，当时主要是应用于大型商业企业，帮助其高管做分析和决策，其展现形式更多是以报表方式实现。传统的数仓还是以TD，Oracle，IBM/DB2等传统数据库为主, 由于受限于数据的处理能力，很少有EDW的数据容量超过1TB。
传统数仓的基本特性可以概括为是一个面向主题的、集成的、具有高度监管性的一体化的用于支持管理人员决策的数据集合。
而数据中台首先在体系架构上与数仓就有很大的不同，数据中台是由多系统组成的，其计算和存储平台是建立在分布式系统之上，以满足不同业务需求和高并发高扩展性需求。除了计算和存储平台外，一般数据中台还应包含数据集成、数据开发、数据建模、数据资产管理、数据治理以及数据服务等多个组件，通过多个维度组件形成一整套方案。
再看数据湖和数据中台，数据湖的概念兴起也是近几年才出现，最早是在 2011 年由 Dan Woods 提出
数据湖是一个集中化存储海量的、多个来源，多种类型数据，并可以对数据进行快速加工，分析的平台，本质上是一套先进的企业数据架构。
数据湖的最初设计是为了作为数据仓库的一个中转区域，它的架构和理念是把原先不存储的基础数据也存储起来，汇总各个数据源的数据方便以后的数据分析和查询，因此数据湖是以数据的聚集、加工为目的数据资源池。当然后来的数据湖发展，也延伸出作为ETL和自助分析平台为目的的数据湖，但是数据湖对比数据中台仍有很多不足，比如说缺乏数据治理和元数据管理等。
不过，两者更大的区别，还是在于其传导的建设理念上，数据中台强调方法论、组织和工具的建设，强调数据赋能业务，通过中台模式更快更好的支持百花齐放的数据应用建设。
那么，数据中台、数仓和数据湖究竟有没有本质上的区别呢？
其实它们并不是一个类型和维度的概念，没有直接的可比性，对于现在数据中台的一些批评和质疑，其实在数据湖概念出来之时，也一样有很多的质疑，感兴趣的同学可以看一下这篇文章："Are Data Lake Fake News?"。
说到底，三者都是为企业提供数据计算、存储和应用的平台，最终各种平台的目的都是要更好地服务于业务。数据中台概念的产生，正是源于企业用户对于数据仓库或数据湖更深层次的期望，企业用户希望数据中台距离业务更近，能更快速的响应业务需求和满足业务应用。
从业务视角看——企业需要什么样子的数据中台
通过企业数据中台项目招标书，以及数据中台研究报告，我将其中涉及业务需求部分，通过词云热度分析，可以看到企业对数据中台建设的需求，主要是集中在以下几个核心诉求上：
- 业务价值
- 数据服务
- 部门壁垒
- 生产力
- 统一数据资产
- 打通数据孤岛
- 业务场景
- 赋能业务
- 数据管理
- 数据分析
- 精准营销
- 智能算法
其中最常被提的便是提升业务价值、提供数据服务和打破部门壁垒，这也正代表了多数企业对数据中台的真正需求。
- 提升业务价值，一家企业往往在其领域耕耘了数年甚至数十年，这些有成有败的业务经验，如何通过数据的方式来指导企业在未来的业务中正确决策。数据中台通过企业全域数据的整合和打通，沉淀企业数据形成数据业务模型，展现形式也许并不是特别重要，无论单纯的数据形式或者报表形式，业务的逻辑或者故事才是最重要的，让数据真正成为业务的驱动力而不是冷冰冰的数字。
- 提供数据服务，企业希望通过数据中台，来建立起统一的数据服务出口，避免数据口径不一致在业务上导致的决策失误，这个数据服务应该是多面手，既能让不懂技术的业务人员能够方便的通过数据服务获取信息，也需要考虑到专业技术人员，满足其在数据分析、挖掘、以及建设数据应用的需要。
- 打破部门壁垒，这个是每个企业都最为头疼的难题了，大多数企业中，数据的产权是分布在不同的部门手里，拥有优质数据的部门不愿意分享，因为其认为别的部门数据对自己无甚助力，没有优质数据的部门苦于无数据分享，但是却是组织里最需数据共享的一方（先富带动后富，看来不仅在社会制度层面，在企业层面也是一个大难题）。数据中台在技术层面，通过数据资产中心的建立，首先对于各部门持有数据进行规范和治理，然后通过打通并对数据资产进行清晰的界定和量化，为管理提供了有效基础去促进各部门数据之间的共享，然后，就要祭出数据中台的核心——方法论，或者说是管理规范也好，通过协作、激励、惩罚等多手段并用，来实现数据的共享共荣。
小结
可以解答最初的问题了，数据中台究竟是什么，或者说企业想要的数据中台究竟是什么样子的。数据中台不是技术体系，也不是一个具象的产品工具，它没有标准化的架构，但是一个成功的数据中台必然有其核心要素：
- 数据中台不是纯粹的技术定义，应是管理+技术+业务的混合输出
- 数据中台应该是数据资产的载体，提供基础的计算和存储平台，使数据可存可查可复用可共享可变现
- 数据中台存储的每一笔数据都理应有业务的价值，所以需要完善的数据治理体系对其进行规范和管理
- 数据中台应提供友好、自动化的工具来降低数据开发处理的门槛，让业务专注于业务
- 数据中台的持续演进离不开数据运营，在数据资产管理层面需要为管理思路提供必要的基础，如满足ROI的衡量
- 数据中台作为统一的数据出口，应在数据服务及消费的方式上满足多种需要，并有尽量优秀的查询性能
- 数据中台对比平台级系统建设更强调能力的输出，应有支撑数据探索、数据应用开发、智能化算法的能力或服务
- 数据中台需要与之配套的跨业务和技术的组织以及人才结构，需要为业务主动提供数据服务而非被动的需求响应
- 数据中台需要指导方向的方法论，其建设和实施上不能再只是满足建设起一套IT系统，搭建起指导方向和持续演进的方法论才能事半功倍
最后，别再纠结我需要不需要数据中台，我建设的是不是数据中台，或者数据中台这个概念和名字了，你建，或者不建，它都在那里，不来不去。