数据中台无疑是近几年最火的概念了，在ToB领域可谓“无人不知，无人不晓”，从2018年末，原先市场上各种关于大数据平台的招标突然不见了，取而代之的是数据中台项目，建设数据中台已经成为不少企业数字化转型的必选。
那么数据中台到底是什么、为什么要建、怎么建？带着这三个灵魂拷问，结合自己近两年的学习和实践，做下总结，希望对你有所帮忙。
一、什么是数据中台？
数据中台定义
正如“一千个观众眼中有一千个哈姆雷特”一样，数据中台也没有一个标准的定义，下面是笔者觉得比较准确的定义。
数据中台是一种让企业数据用起来的机制，是一种企业级的战略选择和组织形式，通过有形的技术产品和实施方法为支撑，构建出来的把数据变成资产，并服务于业务的机制。
数据来源于业务，又要反哺业务，从而实现“业务的数据化，数据的业务化”。数据中台不仅仅是技术，也不仅仅是产品，而是一套完整的让数据用起来的机制。既然是机制，就需要从企业战略、组织、人才等方面全面规划和配合，而不仅仅停留在工具层面。要做数字化转型，不仅是技术部门的问题，更是组织与业务模式改造的问题，需要顶层战略规划和组织架构改变，需要作为“一把手”工程规划落实。
数据领域的发展历程
看完定义，你可能更迷惑了：以前我就知道有数据仓库、大数据平台、数据湖等概念，现在又出来个数据中台，他们到底都是什么，又有什么不同？
启蒙时代：数据仓库
BI(Business Intelligence)诞生于上世纪90年代，是将企业已有的数据转化为知识，帮助企业做经营分析决策，所以我们通常管它叫“经分系统”。
从实现上讲，经分需要聚合多个业务系统的数据，比如CRM、计费等，同时需要保存历史数据，进行大数据量的范围查询。而业务系统所使用的数据库，是面向事务的增删改查，无法满足经分的业务场景，于是“数据仓库”概念出现了。
在1991年出版的《Building the Data Warehouse》，数据仓库之父Bill Inmon给出如下的定义。
数据仓库是面向主题的、集成的、非易失的、反映历史变化的数据集合。
数据仓库不是一个技术产品，而是一种数据的组织方式，其技术载体依然是Orale、DB2等传统数据库。
除了基础概念，Bill Inmon还提出了数据仓库建模的方法，即三范式建模法。这是一种自上而下的建模方法，首先把不同业务系统的数据同步到统一的数据仓库中，然后按照主题域（如用户域、交易域等）组织数据。不久，Kimball提出了一种自下而上的建模方法，也就是维度建模。维度建模从数据分析的需求出发，拆分事实和维度。
这两种方式各有优劣，三范式建模从数据源构建，对整个业务通盘考虑，冗余数据较少，但开发成本高、不够灵活，适用于业务比较稳定的领域，如电信、金融。维度建模从分析场景出发，适用于变化比较快的业务，适用于互联网等业务变化快的领域。例如，阿里的数据中台产品，就是以维度建模作为方法论。
数据工厂时代：大数据平台
进入互联网时代，数据发生了三点变化：
- 数据的规模急剧膨胀，采集的数据量远超人们预期。
- 数据出现了异构化，除了系统本身的结构化数据外，有大量的图片、视频、日志等半结构化或非结构化数据。
- 数据的实时性有了新要求，传统数据仓库通常以天或月为周期同步数据，已经无法满足新的数据分析场景。
所以，受数据规模、数据实时性和数据异构性的限制，传统的数据仓库已经无法支撑互联网时代的经营分析。
以谷歌为代表的互联网巨头率先进行了探索，2003年起，建设性地发表了GFS、MapReduce、Bigtable三篇论文，奠定了现代大数据的技术基础。
2005年，Hadoop的出现后，大数据迅速普及开来。Hadoop几乎成为大数据的代名词，我们可以简单地认为Hadoop是谷歌三篇论文的开源版实现。Hadoop及Hive、Spark、Flink等生态产品，解决了大数据落地所面临的存储、计算等基础技术问题。
随着大数据技术的日趋成熟，2010年，Pentaho公司的创始人兼首席技术官James Dixon提出了数据湖的概念，即：数据湖是种以原始格式存储数据的存储库或系统。数据湖从本质上来讲，是一种企业数据架构方法，物理实现上则是一个数据存储平台，用来集中化存储企业内海量的、多来源，多种类的数据，并支持对数据进行快速加工和分析。
大数据技术的发展解决了海量、实时、异构数据处理的需要，但也使得数据开发过程变得极其复杂，于是“大数据平台”就产生了。
大数据平台是面向数据开发场景的，覆盖数据研发完整链路的数据工作平台。
该平台以Hadoop为技术底座，面向数据开发者，覆盖数据集成、开发、测试、运维等各场景。
数据价值时代：数据中台
在大数据盛行的年代，很多企业都加入了大数据建设的热潮，但似乎并没有太多人去思考为什么要建大数据平台。当企业在使用数据的时候，各种问题就暴露出来了：
- 业务部门：随便要个数据就得一两周，能不能快点？
- 数据开发：需求太多，人太少，数据口径不统一，活干不完。
- 企业老板：连续多年做数据建设，钱没少花，看不到什么成效，各部门还不满意。
由于各种原因，烟囱式建设在现实中大量存在，不同业务线、不同部门间的数据都是割裂的，指标口径不统一等问题也大量存在。数据缺乏统一的管理，大量的重复计算、开发效率低下，计算、存储等资源的浪费，数据应用的成本居高不下。数据明明在那里，但就是用不起来，于是“数据中台”产生了。
数据中台强调数据的复用，而不是复制。基于一套数据模型进行数据开发和管理，避免重复计算，通过数据服务化，向数据应用赋能。
数据中台与既有概念的关系
- 数据仓库：数据中台包含了数据体系建设，也就是包含数据仓库的完整内容，能够将企业数据仓库建设的投入最大化。
- 大数据平台：数据中台依赖大数据平台，大数据平台完成了数据研发全流程的覆盖，数据中台则在此基础上增加了数据治理和数据服务化。
- 数据湖：数据中台构建于数据湖上，具备异构数据统一计算、存储的能力，同时让数据的管理更规范。
二、为什么需要数据中台？
数据工作常见的五个痛点
1. 口径不一致
“口径”是数据工作者心中最魔幻的词语，很多数据问题都可以用口径不一致来解释。其产生的原因，大致有三种：业务口径不一致、加工过程不一致、数据来源不一致。
2. 需求响应时间长
业务部门发起需求，汇聚到技术部门，然后再组织开发。数据开发团队承接整个公司的数据需求，而且每次开发基本都是纯手工作业，大量的加工过程无法复用，有时两个人做了同样的数据处理，还互相不知道。
3. 取数效率低下
以电信运营商为例，省级公司数据仓库的表数量是以万为单位的。面对海量的数据表，数据开发人员想找到与需求匹配的数据，是很有难度的。通常每个人对自己熟悉领域的表很熟，如果跨领域的话，凭个人的脑力是很难应对的，往往需要较高的沟通成本。
4. 数据质量差
做过数据的人都知道，使用频度越高的数据，其质量越好。数据服务能力需要通过数据应用的反馈，不断打磨才能持续提升。然而，由于缺少有效的质量管控体系，即使知道某个环节有问题，但搞不清其影响面，也不敢贸然修复。
5. 数据成本不断攀升
前面说的都是开发人员和业务人员的问题，老板们更在意的是年年花钱搞数据建设，到底做了什么，有没有给企业带来效益？很多公司缺乏数据ROI管理，大量的数据有进无出，导致数据存储计算成本不断增加，比如一些多年没人使用的报表还在定期生成数据，空耗资源。
数据中台需要具备的四项能力
1. 数据汇聚整合
随着业务多元化的发展，企业内部往往有多个信息部门和数据中心，大量系统、功能和应用重复建设，存在巨大的数据资源、计算和存储资源、人力资源的浪费，同时部门墙、组织壁垒导致数据孤岛的出现，使得数据难以全局规划。数据中台需要站在整个企业的角度，对数据进行统筹规划，协助不同的部门和团队更好地定位数据、理解数据。
2. 数据加工提纯
数据像石油一样，需要经过加工处理，才能使用，这个过程就是把数据资产化的过程。数据中台贯通全域数据，通过统一的数据标准和指标体系，构建出数据资产体系，以满足企业对数据的需要。
3. 数据服务可视化
数据的汇聚和加工是比较偏技术的，业务人员难以理解。加工完成后，需以可视化的方式将数据资产目录、元数据、数据质量、数据血缘、数据生命周期等进行管理，以直观的方式展现企业的数据资产，提升企业的数据意识。
4. 数据价值变现
无论是大数据平台还是数据中台，都不能为了建设而建设，要真正给企业带来价值。一方面，可以充分利用已有数据的服务能力，发现和探索应用场景，带来新的价值。例如，疫情期间三大运营商的位置数据，对防控起到了积极的作用。另一方面，分析数据资产的成本消耗情况，及时地执行清理无用调度任务及数据、归档低频数据等操作，以节约计算和存储资源。
数据中台解决问题了吗？
答案是肯定的，通过汇聚整合能力和加工提纯的能力，实现了全域的数据汇聚、规范的数据开发、标准的数据体系构建、可视的数据资的管理。
- 做到了“书同文，车同轨”，解决了口径不一致的问题；
- 克服了数据孤岛和重复开发弊病，解决了需求响应时间长的问题；
- 描绘了数据全貌及血缘关系，数据变动全程可量化，对业务人员友好，避免了对个人经验的过渡依赖，解决了取数效率低下及数据质量难以改善的问题；
- 引入了数据服务的能力，让数据赋能业务有了抓手，解决了数据商业价值问题。
那么，理想的数据中台是什么样子，又该如何建设呢？我后面继续讨论。
网友评论