云原生数据中台：架构、方法论与实践

by June 2021-07-16

数据中台虽然在实现路径上有很多关键的非技术因素，例如高层战略、组织架构、资源配置等，但是即使在这些非技术因素上有更好的支持，如果在整体架构和技术实现上不能实现好的层设计，其建设也是难以取得成功的。正如第1章所述，现在很多机构之所以需要单独建设数据中台，就是因为它们在建设大数据平台的时候没有设计好技术架构。而数据中台的投入和规模一般都很大，如果早期的整体架构没有设计好，后期迁移的成本巨大。

本章将首先介绍数据中台的功能定位和主要建设内容，然后讨论架构设计的原则以及如何设计合适的数据中台架构来支持企业的数据服务能力，最后简单介绍在这样一个架构设计下的各个主要功能组件。

数据中台的功能定位

数据中台的功能定位是完成公司内部数据能力的抽象、共享和复用，因此，数据中台的架构必须围绕这三个功能来设计。与传统的大数据平台不同，数据中台搭建于大数据平台及数据仓库之上，将大数据平台和数据仓库所实现的功能以通用数据能力的形式提供给企业的所有部门。因此，单从功能上来讲，大数据平台实现具体的数据能力，数据仓库是业务建模、数据治理发生的地方，而数据中台则需要把大数据平台、数据仓库的数据和接口组织起来，通过打通数据提升数据能力，通过共享提高全局使用效率。因此数据中台的架构设计应该考虑如何有效地完成抽象、共享和复用的功能。

思考试验：数据仓库+数据服务就是数据中台吗？

假设我们已经有一个很好的数据仓库，并且在上面设置了一些可以供大家使用的数据集市或者说主题数据。在此基础之上，我们又提供了一些可供大家使用的数据服务。那么能说这个系统就是数据中台吗？

在回答这个问题之前，让我们先回到数据中台的定义上，看看这个系统是不是提供了全局的数据能力的抽象、共享和复用。从另一个角度来讲，如果一个新业务应用需要使用新的数据能力，可以看看我们是需要直接与底层的原始数据打交道，还是能通过中间的这个系统来开发。因此，关键问题是这个数据仓库提供和共享的数据服务和数据能力，是否能够覆盖整个企业的业务范畴。如果每个部门都有这么一套数据仓库、数据服务、数据集市，那么岂不是每个部门都有一个小的数据中台？因此我们认为，这还不能称为数据中台。中台应该是要支持全局的，而不是局部的；数据能力的抽象、共享和复用也应该是全局的，而不是局部的。

大数据平台在各部门与整个公司的使用模式是有很大区别的。如何管理数据仓库的演变，如何管理数据服务的抽象，如何管理数据的产生与发布流程，这些都是数据中台需要解决的问题。而这些问题在传统数据仓库和大数据平台中的优先级通常会比较低。

实际上，数据中台的建设应该贯穿数据处理的全生命周期，即从原始数据到最后产生数据价值的整个流程，且整个流程都处于数据中台的管理之下。图7-1显示了从原始数据到实现数据价值的完整流程，其中每一步都是数据中台建设需要考虑的：

数据发现/探索
数据采集/导入
数据建模/治理
数据转换/分析
数据服务/共享
模型管理/更新
数据产品/集成
BI报表/可视化
应用开发/测试/发布
任务调度/运维

从流程来看，这些内容也都是大数据系统应该建设的内容，那么这些内容和数据中台建设应该是什么关系呢？数据中台的建设是包含底层大数据平台和数仓建设的，数据中台底层也是由（符合数据中台需要的）大数据平台和（符合数据中台规范的）数据仓库来支撑的。数据中台要做的就是把上述流程在全局标准化、规范化，让这个流程产生的结果和能力能够在全局共享和复用。

我们再来看看数据中台的架构设计，其核心在于用全局统一的标准和规范来实现数据赋能，这与单一部门实现上述流程的侧重点是不同的。在数据中台的设计中，需要考虑如何灵活地支持数据能力的抽象，管理各种数据复用，确保它们都符合统一的数据规范和安全规则，同时又使各个部门能够独立演变属于自己的数据，而不需要进行复杂的多部门协调。我们认为数据中台应该能够支持各个部门在一个统一平台上完成上述流程中的所需功能，同时在发现有全局共享需要的时候，能够方便地将特定的数据能力共享给全公司，并且在后续的演变中不会因为协调的原因而拉长数据能力的演进过程。

所以，已经有大数据平台、数据仓库的公司需要在此之上搭建负责数据应用开发和运营管理的平台，统一管理数据能力的流程。数据中台的功能定位也应该是一个数据运营管理平台：在原有的基础大数据平台和数据仓库的基础上，将独立的数据仓库研发和数据能力研发组织成整体数据能力的开发和共享平台。而没有大数据平台或者数据仓库的公司，需要在建设大数据平台和数据仓库的同时打造数据中台的能力。

此外，由于数据中台对于可扩展性、协同工作的要求，很多传统大数据平台难以满足数据中台的需求。应该考虑在基于现有大数据平台打造数据中台的同时，逐渐将大数据平台迁移到更适合新一代大数据人工智能组件的新框架之下，以便于数据中台的后续演变。例如，数据中台需要提供给各部门自助的数据工具，应该使用一种云原生的架构快速发布和支持新的大数据组件，并将其纳入整体的管理范畴。如果现有的大数据平台还不支持这种功能，就应该考虑将其逐步迁移到云原生的架构上。

数据中台架构设计的9大原则

基于数据中台的功能定位和需要解决的问题，我们认为其架构设计应遵循下面的设计原则。

面向未来：应该能够很容易地将新出现的大数据、人工智能、机器学习应用和框架加入系统。新技术以前所未有的速度出现，如果数据中台不能快速适应变化，各部门可能很快就会自己另起炉灶，形成新的应用及数据孤岛。
需求驱动：数据中台的存在是为了更快、更好地满足业务部门的需求，因此其架构设计应该以如何快速处理需求为核心，能否快速满足新需求应该是判断一个架构是否合理的标准之一。
面向个体：系统的每个使用者面对的都是系统的一个方面，但是他们都应该能够从系统中获得他们需要的数据能力，自助完成他们的目标，达到最优的效率。
面向协作：考虑系统的每个使用者的行动如何影响整个系统的功能。个体用户对系统的使用会以自适应的方式影响整个系统的演进，例如，多个用户在有类似的数据能力需求时如何协同开发，我们的架构应该能清楚地掌握系统中核心元素之间的关系和连接。
面向变化：对于系统中所有的元素（用户、数据、应用、资源），架构设计必须考虑其变化和生命周期。例如，新员工入职应该经过什么流程？离职又该如何处理？如何往系统里新增一个数据表？这个数据表里的数据应该存多久？如何知道这个数据表已经没有用途？如何移除这个数据表？
处理异常：对于数据中台这样复杂的系统，我们必须假设所有组件都有可能失败或出错。系统必须具备极强的容错性以及在发生大多数错误时自动恢复的能力。
预防恶意使用：数据越来越成为一个公司的核心价值，数据中台是公司数据处理和能力共享的核心组件，我们要假设所有的规则都有人违背，一定会有人试图违规访问数据。数据中台应该能让每个用户都放心使用系统，而不用担心会使系统意外崩溃。
不要重复造轮子：应该尽量避免重复开发系统功能组件，系统中的数据和能力要能高效安全地在各个部门之间共享。这意味着每个用户在使用数据中台的时候，都能够对系统中的可用数据和能力有个全局视图。
兼顾灵活性和易用性：作为数据中台，如果把所有组件都做得傻瓜化，虽然对于新手来说很容易上手，但是在功能和效率上会有一定限制；如果提供很多灵活的选项，则新手可能就会淹没在复杂的系统配置中。我们必须在二者之间找到一个比较好的平衡。

从某种意义上来说，这些原则也是建设一个好的大数据平台所需要遵循的。但是在建设单一的大数据平台时，第一优先级是解决局部的问题，以上面向未来、面向变化、面向协作、不要重复造轮子等原则的优先级就降低了。而在建设数据中台的时候，因为数据中台就是要解决这些问题的，所以必须重视这些原则。

典型的硅谷大数据平台架构

第1章简单介绍了EA和Twitter是如何使用大数据平台来驱动公司的运作的，并描述了它们是如何提供数据中台的典型功能的。本节我们分析一下典型硅谷互联网企业的大数据平台架构，作为我们数据中台架构的参考。

Twitter的大数据平台架构

Twitter是最早一批推进数字化运营的硅谷企业之一，其公司运营和产品迭代的很多功能是由其底层的大数据平台提供的。图7-2所示为Twitter大数据平台的基本示意图。

Twitter的大数据平台开发比较早，很多组件是其内部开发的，后面都有开源组件来对应。

Production Hosts：直接服务用户的生产服务器，也就是业务系统。
MySQL/Gizzard：用户关系图存在于Twitter的大规模MySQL分布式集群中，使用单个MySQL作为存储单位，在上面增加一层分布式协调数据分片（sharding）和调度的系统。
Distributed Crawler, Crane：类似于Sqoop和DataX的系统，可以从MySQL中将业务数据导出到Hadoop、HBase、Vertica里，主要用Java编写。
Vertica：大规模分布式数据处理系统（MPP），可以理解为一个以OLAP为主要任务的分布式数据库，主要用于建设数据仓库。类似的商业产品有Teradata、Greenplum等，类似的开源工具有Presto、Impala等。
Rasvelg：基于SQL的ETL工具，主要用于数据清洗、治理和数据仓库建设。
ScribeAggregators：日志实时采集工具，类似于Flume和Logstash，主要目的是将日志实时采集到Hadoop集群中（图7-2中的RT Hadoop Cluster）。
Log Events：主要是将客户端埋点的数据或其他需要实时处理的数据写入各种消息中间件中。
EventBus、Kafka、Kestrel queue：Kafka是开源的消息中间件，EventBus和Kestrel都是Kafka出现之前Twitter内部开发的消息中间件。需要内部系统的原因是有些业务需要类似于exactly-once（确定一次）的语义或者其他特殊需求，而Kafka成熟较晚，直到2017年的0.11版才推出exactly-once这种语义。
Storm、Heron：消息中间件的数据会被一个实时处理系统处理。Twitter早期用的是Storm，但后来发现Storm性能和开发问题比较大，就自己用C++开发了一个与Storm API兼容的系统Heron来取代Storm，并在2016年开源。
Nighthawk、Manhattan：Nighthawk是sharded Redis，Manhattan是sharded key-value store（用来取代Cassandra），推文、私信等用户信息存放在Manhattan里，Nighthawk作为缓存，这些组件是直接服务业务的；实时处理的数据和一些批处理分析的数据也会放在这里，被业务系统调用。
LogMover：日志复制工具，主要使用Hadoop的distcp功能将日志从实时服务器复制到另一个大的生产集群。
第三方数据：例如苹果应用商店的数据，这些数据使用定制的爬虫程序在Crane框架里执行。
Pig、Hive、Scalding、Spark：各种内部批处理分析框架，也用来开发ETL工具。
DirReplicator：用来在各个数据中心、冷热Hadoop集群、测试/生产集群中同步数据目录。
DAL：Twitter的数据门户，基本上所有的数据操作都要经过DAL的处理。
Tableau、Birdbrain：Twitter的数据可视化/BI工具，Tableau是通用的商业化工具，主要供具有统计背景的数据分析师使用；Birdbrain是内部的BI系统，它将最常用的报表和指标做成自助式的工具，确保从CEO到销售人员都可以使用。

实际上，Facebook、Twitter、LinkedIn、EA、Uber、Airbnb、Lyft、Pinterest以及很多其他硅谷公司的大数据平台架构都非常类似，下面我们以Airbnb和Uber的数据平台架构为例进行介绍，看看它们之间的共同点。

Airbnb的大数据平台架构

Airbnb采用可扩展的大数据平台以确保产品能满足业务的增长，并对Hive集群单独区分金集群和银集群，对数据存储和计算进行分离以保证灾难恢复。

数据源：包含各种业务数据的采集，例如将数据埋点事件日志发送到Kafka，MySQL数据通过数据传输组件Sqoop传输到Hive集群。
存储：使用的是Hadoop的HDFS和AWS的S3。
复制：有专门的复制程序在金、银集群中复制数据。
资源管理：用到了YARN，同时通过Druid和亚马逊的RDS实现对数据库连接的监控、操作与扩展。
计算：主要采用MapReduce、Hive、Spark、Presto。其中，Presto是Facebook研发的一套开源的分布式SQL查询引擎，适用于交互式分析查询。
调度：开发并开源了任务调度系统Airflow，可以跨平台运行Hive、Presto、Spark、MySQL等Job，并提供调度和监控功能。
查询：主要使用Presto。
可视化：开发了负责界面显示的Airpal、简易的数据搜索分析工具Caravel及Tableau公司的可视化数据分析产品。

Uber的大数据平台架构

下图显示了Uber的第二代大数据平台架构。

2015年前后，Uber开始围绕Hadoop生态系统重新构建新的大数据平台。Uber引入了一个Hadoop数据湖，其中所有原始数据仅从不同的在线数据存储中摄取一次，并且在摄取期间不进行转换。这种设计降低了在线数据存储的压力，使Uber能够从临时摄取作业过渡到可扩展的摄取平台。除了整合Hadoop之外，Uber还使该生态系统中的所有数据服务都可以横向扩展，从而提高了大数据平台的效率和稳定性，而且具有这种通用的水平可扩展性可以快速满足新业务需求。Uber第二代大数据平台中包括以下组件。

实时数据采集：Kafka。
键值数据库：类似于Twitter的Manhattan。
RDBMS DB：关系型数据库。
Ingestion：数据采集（这里它强调了强制类型检查，即schema enforced，强制类型检查是数据治理中的一环）。
数据采集、存储：主要使用Hadoop，采取Twitter开源的列式存储格式Parquet，构建了一个集中模式服务来收集、存储相关客户端库，将不同服务数据模式集成到这个中央模式服务中。
ETL：在Hadoop数据湖上进行数据的整合、治理、分析。
数据仓库：使用Vertica，主要存储从数据湖中计算出来的宽表，因为处理能力有限，一般只存储最近的数据。
计算框架：采用MapReduce、Hive、Spark和Presto。
查询工具：使用Presto来实现交互式查询，使用Spark对原始数据进行编程访问，使用Hive进行非常大的离线查询，并允许用户根据需求进行选择。
支持的数据应用：建模、机器学习、运营人员、A/B测试。
支持随机查询：运营人员、数据科学家。

云平台作为大数据平台的通用底座

在上面的几张架构图中，没有明确指出这样一个事实：绝大部分硅谷高科技公司的大数据平台是建立在一个底层云平台架构之上的。因为这是一个共识，所以大部分架构图中省略了这一层。例如，很多硅谷的公司，从几十人的小公司到几千人的上市公司，在基于Apache Mesos来打造它们的大数据平台。那么它们为何选择Apache Mesos作为基础平台呢？

Apache Mesos是一个分布式集群管理系统，提供了高效、跨分布式的资源隔离和共享以及分布式计算的管理和调度。该系统目前被业界领先公司广泛应用到生产环境和大数据系统中，如苹果公司使用Mesos管理3000台集群来支持Siri语音识别应用，Twitter使用Mesos管理近万台机器的生产环境集群。Apache Mesos是目前比较先进并经过生产环境验证的分布式集群管理系统。

作为一个数据中心管理系统，Mesos最重要的功能实际上就是基于混合技术做二层调度和资源管理。Mesos不仅支持容器技术，还支持非容器化的应用，实现整个资源池的混合架构、资源的抽象、扁平化管理，最终实现对上层分布式应用（如Spark、Cassandra、Hadoop等）的支持。Mesos最大的特征及优势是对海量集群的商业和企业级支持。在Mesos的发展历程中有很多问题被发现和解决，并据此在商业环境中持续迭代Mesos的代码仓库，这样就形成了持续迭代和持续优化的机制。Mesos能够用于大型甚至是超大型集群（主机数在万台以上的集群），在这之上，Mesos实现了企业级的高可用性。总的来说，这种对超大规模集群的支持以及被验证过的企业级高可用性是Mesos最主要的优势。

Mesos源于Google的论文“Large-scale cluster management at Google with Borg”，其中描述了Google的Borg系统是如何管理它的海量服务器和数据中心的。Mesos的主要作者Ben Hindman在加州大学伯克利分校读博期间，根据Borg的主要思路写了一个分布式数据中心管理系统。Twitter在2010年高速发展时碰到了数据中心的管理问题，于是就把Hindman招募过来，并将Mesos作为自己的数据中心管理系统。经过Twitter工程团队的大力推进和实际生产验证，Mesos在生产环境中很快就能管理上万台机器的集群，也因此在业界树立了数据中心管理的标杆。

同一时期，Uber、Airbnb、Lyft、Pinterest等公司正好也处于起步阶段，而它们在生产中碰到的问题与Twitter高度相似。因此，它们也就自然而然地选择了基于Mesos来打造自己的大数据平台。下面以Airbnb为例，看看它为什么会选择Mesos。

首先，在有Mesos之前，Airbnb大部分的开发人员和用户有很多数据需要计算，而用以前的方式很难平衡资源，不仅需要找机器来配置，还要安装一些Spark的集群工具。因此，数据开发人员难以及时处理数据并进行大数据计算。而Mesos正好解决了开发人员的数据计算需求与资源供给之间的矛盾。在解决这个矛盾的过程中，研发人员就能够很轻松地完成大数据的计算和对相关运维的支持，后续也为研发人员带来了很多益处。

其次，Airbnb研发人员会用到Cassandra之类的工具，在使用Mesos以前，这需要先准备机器，安装操作系统、Spark集群、相关的依赖包，安装和使用十分困难。而使用了Mesos之后，新分布式应用上线和开发人员之间的矛盾就得以解决，从而能够及时满足研发人员对于新应用、新分布式系统的需求。

体会到Mesos对分布式开发流程颠覆式的改进之后，Airbnb的两名早期数据平台员工Tobias Knaup及Florian Leibert在2013年共同创立了Mesosphere公司。Leibert曾是Twitter早期用户增长团队的成员和数据平台的用户，他也是在Twitter使用了Mesos之后意识到其优势并将Mesos引入Airbnb。2014年Hindman也加入其中，全职推广Mesos。他们认为Apache Mesos是一个开源的孵化项目，它不仅能服务于Twitter、Facebook这样的大公司，还应该更多地服务于早期Airbnb这样的中小企业。因此，他们创立了DC/OS这个项目，通过DC/OS的开发和商业化，帮助很多中小企业客户在工程师能力不足的情况下，也能受益于Mesos带来的好处。从广义上来说，他们普及了Mesos的应用。实际上，Apache Mesos类似于Linux的内核，DC/OS则是基于内核之上的分布式应用系统。随着DC/OS的发展，在DC/OS中的许多基于Mesos的监控、日志管理、用户管理、多租户、安全等外围运维服务也随之成长起来。总而言之，DC/OS是基于Mesos的开源技术，Mesosphere是基于DC/OS开源技术所做的企业级封装，也是构建数据基础架构的核心平台。

硅谷大数据平台架构的共性和建设思路

从以上大数据平台的架构范例中，我们可以看出以下几个共性。

统一的平台支持端到端的数据工具体系，尤其强调体现数据价值的应用。
强调数据能力的闭环，从数据的产生、使用到最后反馈到产品。
数据的采集、治理、分析、使用由所有部门在统一体系中完成。
主要的基础组件大部分采用成熟系统，如Hadoop、Hive、Kafka、Spark、Vertica。
自己开发一些侧重用户交互的组件，如ETL开发调度平台、数据门户、建模/数据治理。

这些共性体现在第1章中提出的TotalPlatform的概念中，即要求整个企业的数据工作在统一平台中完成。此外，还有一些在架构图中没有显示，却是大部分数据平台都很重视的部分，如在第1章中提出的TotalInsight的概念：

全局的数据和应用资产的管理和运营；
明确平台团队和业务团队的分工和合作；
重视可衡量的数据能力。

这些将在后续章节中详细介绍，这里只简单罗列。

从上述介绍可以看到，硅谷企业在数据平台的建设上一般都会采取比较开放的思路，从现有的比较合理的开源架构起步，搭建好自己的基础平台，解决基础问题之后再来迭代。它们在这个过程中会开发一些新技术，解决一些新问题，这些新技术和解决问题的新方法有的回馈到开源社区，有的就在自己公司内部使用。大家都想避免重复造轮子，这主要是基于以下几方面的考虑：

重复造轮子风险大、投入高、见效慢；
自己造的轮子没有社区，原始开发人员离职后难以招人替代；
开发人员更愿意使用现有开源工具，闭源系统很难招到顶尖人才；
闭源开发的系统迭代一般比开源要慢很多，如果赶不上，差距会越来越大；
涉及系统越来越复杂，一个公司很难自己覆盖所有系统。

我们知道很多大公司内部开发的优秀产品因为没有开源，后续迭代减慢，逐渐被开源产品取代。但是，并非所有层次的产品都适合开源，也并非所有的系统都适合选择开源产品。我们建议的思路如下。

基础架构组件：这方面的产品或组件最好选择成熟的开源体系，因为成熟的开源体系经过了众多企业的千锤百炼，具有较高的稳定性和可靠性，而如果自己重新来做，未知因素太多，坑也太多。
用户交互组件：在基础架构之上与用户打交道的交互产品，因为各个企业使用习惯不一样，底层技术栈不一样，所以最好选择定制服务或者自主开发。

第9章会详细介绍选择开源软件的一些思路和原则，以及常用的开源大数据组件。

数据中台架构

要搭建一个企业级的数据中台，我们认为在系统硬件资源和操作系统之上，还需要建设以下几个主要子系统。

（1）应用基础能力平台

应用基础能力平台也就是我们一般所说的PaaS（Platform as a Service）层，它提供资源管理、应用的全生命周期管理以及微服务的支持等。第8章将介绍云原生系统提供的能力支持及使用云原生的原因。例如，为什么PaaS层一些能力（例如多租户和资源隔离，对不同计算框架的支持）的缺失，造成了我们见到的数据孤岛和应用孤岛的问题；为什么数据中台需要的一些功能（快速的数据应用发布，ROI的精细化管理），必须要有PaaS层能力的支持。

（2）数据基础能力平台

数据基础能力平台也就是在第1章中定义的“传统大数据平台和数据仓库”包含的内容，例如各个常用的大数据平台组件、数据仓库、数据湖的工具、ETL工具、数据可视化工具等。很多企业在这方面已经有了一定的基础，因此本章只对其进行简单介绍。

（3）数据集成开发平台

数据集成开发平台能最高效地使用底层的组件和数据，提供从源数据到数据能力的转换。阿里巴巴所说的数据中台的主要建设内容OneID、OneModel和OneService都是通过数据集成开发平台提供的工具来实现的。

（4）数据资产运营平台

数据资产运营平台是管理全局数据资产及应用，提供数据能力变现的管理工具，它实际上实现的是整个大数据平台、数据仓库和数据中台的数字化运营。阿里巴巴所说的中台建设主要是针对数据集成开发平台的，而我们认为，除了直接服务业务的OneID、OneModel、OneService之外，负责运营数据中台的数据资产运营平台也很重要。它提供了整体体系里所有应用和数据的一个全局运营管理机制，与阿里巴巴的数据资产管理不同，数据资产运营平台是将数据中台整体当作一个运营管理的对象，而不只是处理数据中台中的数据。没有这个数据资产运营平台，我们只知其然而不知其所以然，后续数据中台的迭代将会因此而

受限制。

（5）数据业务能力层

这一层就是使用数据中台提供的工具，结合业务部门的需求，为业务部门提供实际可用的能力，例如具体的行业数据应用（如用户画像、产品推荐等），业务部门可以使用的BI报表、看板等。一般在这一层会形成一个数据能力矩阵，业务部门可以直接使用这里的数据能力实现数据的价值。

在云原生的体系中，系统的应用基础能力平台一般是由一个PaaS平台来承担，而数据基础能力平台也需要将大数据组件进行云原生的改造。图7-5展示了一个满足上面要求的云原生数据中台中的各个子系统及它们之间的关系。

这里的数据中台的架构与阿里巴巴提出的数据中台的架构（见图7-6）有一定的区别。可以看到，其核心能力包括数据采集及开发、数据连接与萃取、数据资产管理、数据主题式服务调用，基本属于上面所说的数据集成开发平台。上述架构和阿里巴巴的架构的最大区别是PaaS平台和数据应用的角色：阿里巴巴虽然在底层使用了一些PaaS平台的功能，但PaaS平台及数据应用在阿里巴巴的数据中台中并不是“一等公民”，而从我们的一些实践来看，如果不将数据应用使用PaaS平台管理起来，使其成为数据资产的重要组成部分，我们将无法最终体现管理数据能力和数据的价值，也无法真正实现TotalInsight，这样的数据中台在功能上是有缺失的。

数据中台子系统

下面分别介绍一下数据中台中的各个子系统。

应用基础能力平台

一般可以将应用基础能力平台称为云原生PaaS平台。从顶层设计的角度来看，应用基础能力平台应该提供以下内容。

资源管理：类似于Mesos、YARN的分布式资源管理系统，可以将一个分布式集群里的资源（CPU、内存、存储、网络）管理起来供上层使用，同时提供资源隔离、多租户等多部门共享协作的必要支持。
容器调度：类似于Kubernetes、Marathon的容器调度系统，允许我们使用容器将很多复杂的应用封装起来，避免它们在发布和运行时互相干扰，从而降低应用发布和共享的难度。在容器技术出来之前，我们在一个Hadoop集群上运行不同的应用程序时常常担心应用之间会相互干扰，因为各个应用的安装和依赖可能会对同一台机器上的其他应用造成影响。有了容器技术之后，大家可以随意发布应用而无须担心影响其他应用，这是数据中台能力共享的一个必要条件。
容器服务生命周期管理：即使有容器调度系统，企业级生产系统还需要一个专门的容器服务生命周期管理系统。容器服务主要是指以容器方式运行的系统服务，例如身份验证服务、系统监控报警服务、分布式调度服务等。这些服务的特点是持久运行（long-running service），一旦发布就在系统中一直运行，系统需要支持其发布、容错、监控、报警、扩容、降容、升级等一整套管理功能来确保其正常运行。
容器定时任务调度：所谓定时任务，就是在大数据平台上经常出现的指定时间运行的程序，而且有一个启动—运行—停止的过程（所谓的run-to-finish program，与long-running service相对），ETL程序是最好的例子。PaaS平台一般不提供这个功能，因为PaaS平台服务对象主要是持久运行的服务，run-to-finish的ETL程序一般是在Hadoop、YARN这样的平台上运行的。但是，随着大数据处理框架的多样化和容器化，能够支持容器化的定时任务的调度体系逐渐成为必需。

我们会在第8章展开描述这些子系统的相关技术和功能细节。

数据基础能力平台

数据基础能力平台可以理解为大数据平台需要的基础组件的集合，这里的“基础组件”是指与具体业务数据和数据应用不直接关联、在所有企业里都同样安装和使用的大数据平台组件。虽然图7-2中只列出了最基础的存储引擎、计算引擎以及一些典型的数据管理系统，但是一个数据基础能力平台包含的组件实际上非常多，比如下面这些。

分布式存储：包括分布式块存储（HDFS）、对象存储（Ceph）、文件存储（GlusterFS）。
关系型数据库：MySQL、PostgreSQL等RDBMS在很多子系统（如HiveMetaStore）中还是需要的，在支持BI系统时一般也是有需要的。
NoSQL数据库：MongoDB文档数据库、Redis内存数据库、InfluxDB时序数据库等具有特定用途的数据库。
分布式数据处理系统（MPP）：Presto、Druid、Impala等SQL-on-Hadoop系统。
键值存储：HBase、Cassandra、ClickHouse等专用的键值存储数据库，也有人把它们归为NoSQL数据库。
分布式计算框架：MapReduce、Spark、TensorFlow、Flink都可以算作分布式计算框架。
消息队列：Kafka、RabbitMQ、RocketMQ等技术可以让分布式系统之间方便地进行消息传递。
实时/流数据处理框架：Kafka Streaming、Spark Streaming、Flink、Storm、Heron、Pulsar等可以让实时/流处理更方便高效的框架。
日志采集工具：Flume、Logstash、Fluentd等日志采集工具。
数据库采集工具：Sqoop、DataX等从数据库往大数据系统导入数据的工具。
任务调度系统：Oozie、AirFlow等调度ETL程序的系统服务。
分布式调度系统：ZooKeeper、Consul等分布式应用之间进行协调所必需的系统服务。
安全系统：Kerberos、Ranger等大数据平台里必需的授权和鉴权的工具。

虽然这些组件的安装和管理是传统大数据平台的建设内容，但我们必须看到，很多时候正是对这些组件的使用方式欠妥造成了数据孤岛和应用孤岛。例如，Hadoop集群多租户功能的不完善，造成有的企业里有十几个Hadoop集群，每个部门都建有一个集群以避免与其他部门冲突。本书不会介绍大数据建设的全过程，但是会讨论与数据中台相关的一些特性。第9章会详细介绍数据基础能力平台常用的组件及开源产品。

更重要的一点是，由于有了云平台和容器技术，我们认为这里的大部分组件会逐渐以容器的方式在云平台上运行。例如，在之前的大数据平台中，Hive集群使用的HiveMetaStore必须在一个指定的IP地址上运行，如果希望做到高可用和自动容错，需要进行一系列复杂的操作、设置和开发，运维人员也要进行专门的运维操作。解决了HiveMetaStore的问题之后，可能还要去解决Sqoop 2 Server的类似问题。如果可以利用应用基础能力平台提供的功能，那么这些问题就不需要单独去解决了，从而极大减少发布、管理、运维的成本和复杂度，这样才更适合建设一个共享和赋能的环境。目前，数据库和分布式文件存储这种IO密集型（IO-intensive）的应用还不是很适合容器化运行，但是随着CSI（容器存储接口）等技术的成熟，应用的容器化运行会是一个不可逆转的趋势。

数据集成开发平台

在数据集成开发平台中，我们使用数据基础能力平台的各种组件将源数据采集到数据中台中并对其进行治理和转换，使之成为能够被业务部门使用的数据，并在此之上提供数据探索、开发、管理、服务的工具，使各个业务部门可以在这个平台上抽象、共享和复用它们的数据能力。我们认为，数据集成开发平台是数据中台的核心组件，它负责将底层的硬件资源、数据资源、应用资源、基础数据能力资源组织成一个业务部门可用、全局可管理的数据中台，真正赋能业务部门，快速实现数据价值。这一平台主要包含以下功能子系统。

数据仓库建设：数据的建模和管理（类似于OneModel）往往使用Hive、MPP来实现，主要功能包括数据建模、主数据管理、元数据管理。
数据集成：数据在系统中的流动，包括数据导入、ETL、数据清洗、数据治理，确保数据的互联互通和全局可用（类似于OneID）。
数据开发：各种数据应用的开发系统，包括数据探索、数据查询、机器学习、数据可视化。
数据服务：将数据变成业务系统可用的能力，包括数据看板、数据大屏、数据服务（类似于OneService）、模型服务。
应用调度系统：数据集成、数据开发、数据服务的应用都需要在集群上运行，我们需要一个数据应用调度系统来对它们进行全局管理。这里的应用调度系统和应用基础能力平台中的容器调度工具应该是应用层管理系统和后台服务的关系。
全局的多租户管理：这一部分主要管理数据应用/工具的集成，支持单点登录、用户体系集成、权限体系集成、资源隔离、数据隔离、配额管理、端到端安全审计。这里的能力一般需要应用基础能力平台和数据基础能力平台中相应的底层能力相配合。

虽然数据仓库、数据开发工具等也是传统大数据平台的建设内容，但是在数据中台的建设中对其有额外要求，例如前面提过的OneModel、OneID的数据仓库建设要求。以数据开发为例，在数据中台中，我们要求数据开发工具建立在全局数据应用资产管理之上（这样才能避免重复造轮子），为数据科学家、数据分析师提供稳定、高质量的跨主题数据资源，同时支持自然语言处理、机器学习建模平台、智能标签+动态知识图谱等多个易用的数据挖掘工具集。这里的数据开发工具更强调可扩展性、协调开发的重要性，例如：

支持方便的代码开发、测试、发布流程
版本管理
新工具的支持
运维、调试支持
协同工作的支持

在传统的大数据平台中，在进行数据分析之后，一般都需要专门的数据工程师针对数据分析的结果编写数据服务应用，才能使分析结果被其他应用使用。这个过程中有很多重复劳动，并且效率低下，难以管理。

在数据中台中，用户应该可以使用标准化、产品化的中台服务进行数据自助服务，从数据结果或者机器学习的模型自动生成数据服务，而无须编写代码。系统可以提供统一的、面向应用的、主题式的数据服务，将数据资产管理平台、数据分析挖掘平台的数据处理和分析结果以数据服务形式对外提供，同时生成以业务为导向的服务资源目录，让前台应用更清晰地使用数据中台里的各类数据，实现以数据驱动业务，促进前台业务。同时，系统应该采用应用基础能力平台提供的微服务架构形式，自动处理负载均衡、容错、调用审计等功能。

第13章将会详细介绍数据开发平台、数据即服务、模型即服务的工作等相关内容。

数据资产运营平台

数据资产运营平台负责数据中台本身的运营管理。在打造数据中台的早期阶段，我们看到的有可能主要是数据集成开发平台的工作成果，但是数据资产运营平台是这个系统长期高效持续发展的必要保障。如果说数据集成开发平台是数据中台的生产线，那么数据资产运营平台就是数据中台的ERP（我们系统里有什么资产，可以产生什么效益，实际花销多少，产生了多少效益）、CRM（有多少用户在使用我们系统里的产品，他们是如何使用的，如何与用户保持交流、获得用户反馈）、产品门户（用户会到这里来查询如何使用产品，有什么资源，并共享使用经验）。

数据资产运营平台是一个比较新的概念，它的功能有时部分存在于现有的组件（如数据血缘）中，有时由各个企业内部根据实际需要开发一些小工具（如数据门户工具）来完成，但是并没有形成体系。

思考实验实际上数据资产和数据血缘并不直接为业务系统提供价值，那为什么我们还需要这些功能？理论上，它们不属于数据中台价值输出的一部分，但在实际工作中，如果我们不能回答“系统中到底有什么数据”“这些数据之间是什么关系”这些问题，数据价值的开发将变得非常困难和低效，系统规模稍大就无法继续发展。在传统的关系型数据库时代，数据资产和数据血缘的管理相对简单，只需要处理关系型数据就可以了。但是在大数据时代，数据资产和数据血缘需要跨平台、跨架构，因而变得更加难以管理。那么，我们为什么要梳理数据资产和数据血缘？从根本上讲，我们需要的是让这个数据能力的开发和管理更加有序，也就是大数据平台的运营管理。

而这里提出的数据资产运营平台强调的是将数据和应用一起管理，其主要功能组件如下。

数据应用资产管理：将系统中的数据应用和数据作为资产统一管理。值得注意的是，这与传统只管理数据的数据资产管理还是有一定区别的。数据应用资产管理用于盘点数据和应用资产，以实现数据资产化为主要目的。其主要实现方式是通过数据开发引擎与底层大数据技术平台进行数据交互，采集底层数据的各种管理信息，构建数据资产的全局图谱，服务数据应用和管理的需求。除了数据资产，我们也需要管理系统内的应用资产，因为数据本身不会产生价值，必须通过特定的应用来产生价值，掌握系统中的应用及其对数据的使用是很关键的。
数据应用元数据管理：对于元数据管理，我们将其扩展到数据和应用的元数据，这样能对系统有更全面的了解。一般应用的元数据包括作者、代码位置、版本、历史变更记录、使用的数据源、产生的数据源、使用的文档等。应用的元数据对于跟踪数据的变化、解决生产问题都有非常重要的作用。
数据应用链路血缘管理：与传统关系型数据库中的数据血缘不一样，这里不仅需要发现和记录数据之间的血缘关系，而且需要发现和记录数据和应用之间的生产和引用关系，可能还存在应用和应用之间的关系，例如数据服务API的调用。这些关系的记录和梳理如同数据血缘在关系型数据中的作用一样，对整个系统的精细化运营和管理都是不可或缺的。
数据应用门户：这是数据应用资产的一个使用入口和搜索界面。当系统中的数据和应用资产超过一定数量时（系统中有几千个数据源、上万个日常任务是非常常见的），传统的数据管理和浏览方式是非常低效的，一个类似于Google搜索、百度搜索的数据应用资产搜索引擎就变得十分必要，这样企业内部的数据使用人员就可以随时查阅数据或数据应用了。

我们会在第14章详细介绍数据应用资产管理和数据门户功能。7.5.5数据业务能力层

数据业务能力层指的是通过数据集成开发平台开发、由数据资产运营平台管理、供业务部门使用的实际数据能力。这一层次的具体功能一般都与具体行业和业务相关，但是其表现形式一般在各行业都比较类似，包括以下几项。

数据API：通过数据即服务、模型即服务提供的API，供业务系统使用。
数据看板：由数据科学家定制的数据探索UI，可以提供预先做好或者轻度定制的数据查询工具。
数据报表：主要是预先制定好的商业决策需要的报表。
数据大屏：实时的数据展示方式，一般用来展示最重要、时效性很强的业务数据及其分析结果。

在有些数据中台的解决思路中，数据业务能力层是由一个专门的数据中台团队提供的。但是我们建议，应该由对业务最熟悉的人员来掌控数据的使用和演变，而中台部门提供工具、管理体系来赋能业务部门。我们会在第15章中介绍如何管理开发迭代的流程，以及在数据业务能力迭代中可能会发生的一些问题及其解决思路。7.5.6数据中台重点建设内容

根据上面的讨论，我们总结出以下在传统大数据平台和数据仓库建设之上建设数据中台功能的重点内容。

全域数据采集：以需求为驱动，采集与引入全业务、多形态的全域数据，确保对业务建模的全面支持。
标准数据规范及数据治理：确定基础层、公共中间层、应用层的数据分层架构模式，通过数据指标结构化、规范化的方式实现指标口径统一。
数据开发工具：提供高效易用的工具体系，赋能业务部门，形成高效的数据开发和迭代体系。
数据应用工具：形成以业务核心对象为中心的直接数据应用（如标签体系），可供业务人员直接使用。
全域数据应用资产管理：构建数据及应用资产管理体系，实现数据中台本身的数字化管理，实现数据资产化，降低数据管理成本，充分发挥数据价值。
统一主题式服务：通过构建数据即服务、模型即服务的自助引擎，面向业务统一数据出口与数据查询逻辑。
数据中台运营工具：高效、稳定运行的数据中台才能提供价值，数据中台运维工具与传统运维工具的区别在于前者更加智能、可自助。

本章小结

本章介绍了数据中台架构的一些原则、其中需要的各个子系统以及它们的主要功能。需要强调的是，在数据中台的建设中，底层平台架构固然重要，但关键还在于使用这些工具将企业的数据组织起来，实现价值。在底层平台之上的数据组织、最后实现的数据能力（包括实现这些数据能力的过程），都是数据中台建设的重要内容。

以上内容摘自《云原生数据中台：架构、方法论与实践》部分章节。