【个推CTO谈数据智能】之我们理解的数据中台

引言

在本系列的前面两篇文章（《数据智能时代来临：本质及技术体系要求》和《多维度分析系统的选型方法》）之中，我们概括性地阐述了对于数据智能的理解，并根据工作中团队涉及到的多维度分析系统的选型方法进行了穿插介绍。按照原先的规划，我们接下去的内容会涉及数据智能平台中的治理、安全计算以及质量保证方面。

不过，计划不如变化快，最近这段时间“数据中台”这个词非常热，有人问了我两个问题：“数据中台”与这个系列的核心“数据智能的技术体系”有什么区别？你们是怎么理解“数据中台”这个概念的呢？

顺着这两个问题，这篇文章就和大家聊聊我们对于“数据中台”的理解，以及和“数据智能的技术体系”间的区别。

正文内容

再从数据的价值谈起

数据的产生来源于我们的产品和服务所提供的直接价值。以打车软件为例，因为APP需要提供给乘客所在地点周围的司机信息，因此系统需要及时收集司机的位置以及车载乘客状态以确定是否可被调度，然后把乘客的轿车需求发送给设定参数范围内的可用车辆。司机在进行抢单或者配单后，就可以接上乘客并按照导航送至目的地。

在这个过程中，乘客的上车位置、下车位置、司机车辆的位置、状态以及车辆行驶过程中的位置信息等数据都是为“打车”这个动作的直接价值服务。

正如大家所知，我们可以利用这些几千几万辆车的位置信息，聚合出每个道路的交通状况，再把这些知识提供给交通优化等。这就是数据的扩展价值，数据的多种价值汇总起来就是数据的选择价值。

再打个比方，数据的首要价值被挖掘后仍能够不断给予，它的真实价值就像漂浮在海洋中的冰山，绝大部分被隐藏在表面下。数据的选择价值也就是“取之不尽，用之不竭”的数据创新成果。这些数据创新并不是事先就规划好或者事先都能想到的。

那么为了保证这种创新的可能性，我们需要让这些数据都能被保存下来，而不是在实现了直接价值后，就弃之如敝屣。这个也是接下来要提到的“数据湖”的由来。

数据湖与数据仓库

数据湖【1】的概念是2011年提出的。由于无法对已流失的数据进行回溯，一些大数据厂商在Hadoop为基础的技术栈上，把一个组织中产生的原始数据存储在一个单一的系统中。一般大家会用开源的Hadoop来构建数据湖，不过数据湖的概念比Hadoop更为广泛。

看到数据湖，大家肯定会想到数据仓库或者数据集市，那么两者的区别在哪里呢？我们先来看看下面的这个图。

图 1 数据湖示意

数据湖存储数据源提供的原始数据，没有对数据的形式进行任何假设。每个数据源可以使用其选择的任何形式，最终数据的消费者会根据他们自己的目的来使用数据，这是数据湖区别于数据仓库的一个非常重要的原因。同时，这也是数据仓库没有走得更远的原因，因为数据仓库首先需要考虑数据方案(schema)。

图 2 数据仓库示意

数据仓库倾向于为所有分析需求设计一个总体的方案表示，但是实际上即使是一个非常小的组织，想要通过一个统一的数据模型来涵盖一切，也是不太实用的。另外，数据仓库在使用中会出现数据质量问题：不同的分析需求对数据的构成有不同的质量要求和容忍度。数据仓库的这个特征导致了漫长的开发周期、高昂的开发成本和维护成本、细节数据丢失等问题的出现。

数据湖在直观上更像一个数据质量差异很大的数据倾倒场，如果只是聚合后的数据，意味着会丢掉很多数据。数据湖应该包含所有数据，因为你不知道人们可以在什么时候找到有价值的东西，可能是在今天，也可能是在未来几年的时间里。

数据湖的这种原始数据的复杂性意味着我们可以通过一些方式来将数据转变成一个易于管理的结构，这样还可以减少数据的体量，更易于处理。数据湖还是不应该经常性地被直接访问，因为数据是很原始的，需要很多技巧才能使之变得有意义。一般可以按照下图来处理，我们可以把它称为数据湖岸集市。

图 3数据湖岸集市

把所有数据放入湖中的一个很关键的点是需要有一个清晰的治理。每个数据项应该有一个清晰的跟踪，以便于知道数据从哪个系统中来以及什么时候产生等，也就是元数据管理、数据血缘以及必要的数据安全。

数据中台

数据中台这个概念是阿里巴巴提出来的。随着业务的快速发展，企业的多条业务线都产生了大量的数据，而且数据都按照不同的形式进行采集、存储、处理等。为了快速满足每个前端业务的需求，公司通常会让前台直接去联系后台。譬如，大部分公司的大后台就是财务，初始可能比较有效，但是随着需求越来越多、越来越频繁，沟通成本大大提高，效率大大降低。

同时，对于一个公司的多个业务来说，哪怕看起来很个性的需求，经过抽象以及合并同类项后，我们发现也可以形成共有的能力。其实，对于后台的很多功能，同样可以抽象出来，成为各业务共有的能力。这样可以让数据更灵活更敏捷地服务于前台的各项业务，这个就是数据中台的初衷。

对于阿里来说，如何更好地把包括自己不同业务的数据、被收购公司的数据在内的多个数据变成One Data , 然后为整个公司的业务服务，也是数据中台的一个核心目标。

事实上，数据中台的建设与数字化转型一样，其实也是一个螺旋上升的过程，往往需要不断根据业务变化需求进行完善。哪怕再宏大的数据中台战略，也必须要用真实的业务场景去实践，通过以小到大的场景不断去锻炼中台。

总结而言，数据中台是练出来的，即数据的复用率决定了数据中台的成功与否。一个数据中台的成功意味着不少数据都在进行着重复使用。此外，我们需要注意数据安全策略的执行，包括底层数据安全的实现以及业务层数据的合规使用。

如果一个公司的数据中台没有和业务中台紧密配合，那么这种纯粹的数据中台只是蹭热点，不会有很大的效果。所以我们认为，更有价值的中台是业务偏向的数据中台，而不是通用型的数据中台。这个观点，和前阿里数据委员会主席车品觉是一致的。

根据上面的分析，我们建议公司在业务或者产品比较单一抑或数据战略并不太清晰的情况下，可以建设数据湖，而不是为了建设中台而去建设。从本系列第一篇文章《数据智能时代来临：本质及技术体系要求》的整体介绍来看，我们数据智能的体系和数据中台的目标是一致的。

结语

从我们自身的理解来看，数据智能体系和数据中台一样，本质上是把数据作为资产，整理出企业的元数据和数据血缘关系，再以这些数据为中心，抽象出公共服务的能力。最后，让前端流程的构造和企业的稳定数据公共服务解耦。这样就沉淀出了公共服务能力，即把这些能力SaaS化。

数据智能体系或者说中台，最根本的目的是敏捷地支撑业务部门的业务创新需求，打造快速服务商业需求的服务能力，并且尽量实时处理，体现数据的资产化及价值最大化。

我们认为中台最主要的用户是数据开发者群体，包括数据研发人员、数据分析及建模人员。建设中台的目的在于提高他们的效率、降低学习曲线、提高数据质量。

下一个系列，我们将回到主线，继续讲讲数据治理、安全计算、数据质量保证等方面的内容，敬请期待。

作者简介

安森，个推CTO

毕业于浙江大学，现全面负责个推技术选型、研发创新、运维管理等工作，已带领团队开发出针对移动互联网、风控等行业的多项前沿数据智能解决方案。

曾任MSN中国首席架构师，拥有十余年资深技术开发与项目管理经验，在大数据处理系统、大规模并发平台、分布搜索系统、手机应用开发、无线通信领域和智慧金融系统等领域拥有丰富实践经验。