❤️手把手教你打造一个企业级实时数据中台❤️熬夜爆肝&&万字图文

Posted 2021-09-20 孤寒者

引言——首先来聊聊现代企业数据架构及痛点：

1. 数据孤岛：低效率和利用困难的根源
2. 应用瓶颈：传统方案数据仓库、数据湖的不足
    
   单讲这两个问题你可能会疑惑——为什么会出现这样的问题？
    

所以下面来讲讲两个实际的例子来细讲一下这两个问题：

第一部分——两个实际的场景例子引入

1.以航空公司的场景为例：

  航空公司的市场部计划推出一个新产品或者是一个客户活动，会希望了解哪一种渠道是某类客户最常用的？当想到这个问题的时候，发现航空公司的客户触点太多了。

  PSDP行程订单，投诉、行李系统，常旅客系统，手机App系统等等。这些系统都是航空公司在不同阶段，不同的业务部门建立的应用。这些应用在部署时只会以本业务为目标，而不会考虑到企业其他业务能够很好的对接。如果这些应用中的数据没有做到统一的话，那要花费数天或者数周才能得到结果，甚至都不知道哪里能够拿到数据。有时就算知道，还要协调其他业务部门来正确地给到。

2.以保单贷小程序的场景为例：

  当客户通过这个保单贷小程序申请现金贷的时候，如果客户在保险公司中已购买过重疾险、人寿险或财产险，系统可以根据客户的保单额，在一分钟内判断出提供给客户适合类型的现金贷。

  在上线的时候发现，这个保单贷小程序很快开发好了，但是数据在人寿、重疾、财险等不同的系统里面，有些还需要推荐系统和标签系统。所以要花很多的时间来做数据的对接，这个时间是数周、甚至数月。因为其中不只是数据问题，还涉及到权限等问题。

以上的情形都是企业中常见的数据孤岛的问题，而且随时 IT 建设的发展，这个问题会原来越常见。

综合分析：

1. 有关于第一个问题——数据孤岛：
   数据孤岛成因：
     是由于事业部门在建设 IT 服务的时候，分别以各自业务建设为核心，而不是以数据建设为目标而形成的。

2. 有关于第二个问题——应用瓶颈：
     其次，常用的数据库如Oracle, SQLServer, DB2, Sybase，这些关系型数据库一直以来存在性能扩展的瓶颈。导致在上大的系统，或者客户量增加时，需要采用分库分表的方式。因为单个库没有办法支撑到太多的业务量。这也形成了大量数据孤岛。
   

3. 上述两个问题形成大量的数据孤岛，所带来的的对应的问题主要有（数据孤岛带来的影响严重阻碍了新业务对已有数据的重复利用）:
   ①需要大量时间对接和同步；
   ②用户体验下降，数据不完整不实时；
   ③重复建设，复用率低等。

第二部分——各种解决方案的分析

为了解决数据孤岛的问题， 目前的解决方案：

  有应用层面 ESB 企业总线、MQ等；从存储角度来说，有数仓Teradata，Greenplum，以及数据湖。这些方案都可以在一定层面上解决问题，但是存在局限性：

  首先，这些方案都是面向分析场景，对于数据抽取不及时，多数是 T+1 方式，也就是说业务获取的数据，是系统昨天生产出来的。这些数据在数仓及数据湖中处理形成了大量报表及结果数据，通过下载、导出等方式进行交付，形式粗放。所有目前市面上的大数据平台，大部分的场景是偏重于分析，主要用于做BI，做报表、Dashboard，来对企业的运营和客户有所洞察。

  而对于企业运营来说，关键的、核心的能力不是后端的分析，而是在前端与客户交互，与业务交互，与流程交互。

基于上述情况，数据中台应运而生。

第三部分——优胜劣汰留下唯一解决方案->数据中台

以打通部门或数据孤岛的统一数据平台为基础，构建统一数据资产体系，并以API服务方式为全渠道业务（分析 + 应用）提供即时交付能力的企业级数据架构。

• 首先，统一数据平台。
  数据中台也是一个数据统一的平台，它不会取代原来的系统，而是把原来组织中分散在各系统中的数据实时地汇聚到统一平台之中。

• 其次，数据资产体系建立。
  与数仓及其它大数据平台不同的是，汇聚统一之后，做数据资产体系规划。对数据打标签，组织目录和结构，便于发现和使用。

• 最后，提供数据服务。
  以API的标准接口方式向前端的业务场景，或分析场景提供服务。而不是通过传统的SQL，或者是dump的方式来导出数据。我们称之为DaaS（Data as a Service），数据即服务。

  构建企业数据中台，所支撑的场景不仅仅是分析（如可视化分析，数据发现，数据报表等等），也包括满足各种前端业务应用对数据的需求，如CRM、BPM、SCM、MES等。所以这里提供的数据服务是全渠道业务，而不是传统数仓做的BI类似的工作。更多前端业务应用如掌上商城、手机银行、保单管理、客户360、统一订单、销售大屏等。汇聚在中台的数据可以直接推到手机、App等各类前端，并且是实时的，交互的数据。

这些都是传统数仓这样的平台所无法比拟的。  

以下是金融企业的数据中台架构参考（银行业）：

• 最低下蓝色是EDW、Hadoop、DB2、Oracle等是已有的各类系统的数据源。

• 通过CDC、批量导入、API集成等方式把数据汇聚到中台。

• 在中台里面进行资料的建模和分类，比如按照客户、账户、交易等纬度。

• 然后以API方式交付到他们的各个业务中心。

• 最后做成各种业务开发，如金融商城，手机App，社交系统等。

在没有数据中台的时候。实现这些前端场景需要各个业务中心找每一个需要用到的数据中心去协商，前端业务直接连到后台的核心系统。因此而产生两个问题：

1. 当数据量上来时，如做促销活动，核心系统DB2，Oracle等跟不上。

2. 当有业务中心有新的需求产生，对数据模型要改变的时候，核心系统很难支撑。

当企业有了可以灵活组织新的业务模型的数据中台，才可能真正快速地响应前端的业务需要。

在上图的右上角，可以看到数据中台依旧可以支持一些分析的场景。

当然，这样的数据中台必须具备数据的治理能力，如质量，编目，建模等等。

所以数据中台的主要价值在于，数据的协同效率、复用效率和交付速度。原各个系统中的数据不再各自为政，而协同到一起效率提高很多。同样，一份数据可以给多个业务场景使用，而不再需要 ETL 到不同的系统，还要去维护它们的一致性，去掉重复，或防止遗失。最大的价值更在于，加快数据的交付速度。

（1）技术需求：

我们讲完了这个中台的一个架构和它的逻辑模型，如果我们要来考虑实施数据中台有哪些技术模块要考量。还回到刚才那张图，首先中台必须是基于一个数据统一平台的，那数据统一的时候，其实刚才没有讲到的，还需要把数据同步和汇聚过来。所以有一部分的工作你是少不了的，如果你没有做过这种中台甚至统一平台的话，你必须有一个ETL平台来把你的来自各个来源的数据抽取过来，抽到你的数据统一平台上。

数据统一平台你用什么样的解决方案？那是另外一个问题，回头我们会讨论。那进到里面了以后，我们在上面才构建我们的资产体系，这个是需要用到中台相应的一些比如数据治理的模块能力来做这个事情。那最上面层就是一套服务化能力，要把它做成API server 的方式，把这个数据快速的可以交付出去。

基于上述对于数据中台的理解和定义，我们列出了数据中台所应该具备的技术需求。主要是分为：数据存储系统、数据同步汇聚工具、数据治理和开发、数据交换和发布、数据管理能力五大模块。

如下表：

• 我按照各每个系统大概列了一些数据中台比较核心需要的能力，当大家在采用某一种系统的时候，某一种方案的时候，可以对照一下。也不是每一个你们都会关注，但是这是从我们经验中经常用得到的。比如作为数据平台存储系统的话，你第一个肯定是要横向扩展。为什么？你做的是一个企业级的数据平台，你要把所有的原系统有可能真的做到其极致的话，可能全部把他拿过来，所以你必须得有一个横向扩展能力。不能想今天我的数据这个数据在mysql可以放得下了，或者是一个Oracle可以放得下了，但你要考虑到明年、后年，甚至是三年、五年以后，因为这个架构放上去以后是一时半会不会动的，那灵活的数据模型，这些也是我们的经验，我们要这个是做一个数据汇聚。往往你的一套同一个客户系统，同一个客户模型会来自于多个不同的系统。这个时候，你有一种灵活的模型和相对的一种比较死板模型的话，你会发现这种灵活模型会比较容易的把数据整合进来，能够接受不同的一些字段的变化，也可以方便的把它合并到一个模式里面。

• 高并发低延迟就是我们这个中台最终不仅仅是支撑分析，还要支撑前面的业务，所以必须得有这种潜在的直接穿透到前端，例如我们的移动端用户，或者会有大量的这种高并发。作为这个核心数据，高可用、备份、安全都是不用说的了。这是关于存储系统数据平台的一些最基本的一些要素，所以大家考虑的时候，可以从这方面来想这个问题。

• 其他还有涉及到就是同步工具。批量导入能否实时同步？批量导入一般都有，但是能够实时同步，比如说因为我们要做的事情真的是比如说我们在一家银行做的需要这边刷卡，刷完卡，这个数据在三秒之内直接要进到我们的中台里面，因为上面有一些业务场景会给予中台来做一些推送。所以这个时候实时同步的能力是非常关键的，然后还有一些断点续传或者是所有的数据源的支持，这个就是比较常见的这种同步工具的一些需求了。

• 治理开发就是我们刚才讲的很多就是说怎么样之间数据体系，你必须得有一系列的能力。数据目录、原数据管理、建模、开发、质量管理等等，匹配去重都是，需要在考察的时候，看他们中台有没有这个能力来做这些事情。

• 数据交换的发布就是我们的data API。我们说这是一个数据开发平台，我们面对的使用者，比如大数据团队也好，或者数据管理团队也好或者DBA也好，往往不会是开发人员来做这事情。这更像是一个比较中央化的数据平台团队，所以他们关注的可能是一些管理能力，无代码能力就不用让他们写很多代码，所以这个API能否很方便、很快速地按照需求来接通到为前端做服务，这是很关键的。当然，接口的多样性也是非常关键。SQL方式，大数据、流数据，这些接口都按照我们的需求考虑是否需要。

• 最后一点就是系统管理能力，就是常见的就是这种可视化。因为这里面做很多的事情要有一些相应的任务管理、任务设计、监控、告警啊等等，权限管理,一般的系统都会有这种需求。

（2）技术选型：

常见搭建数据中台的技术产品!

数据中台包括：统一数据平台，数据同步，数据治理，数据服务四大部分。

下表列出了这四大部分中相应的技术产品，有同步汇聚工具、有数据治理、还有数据服务。

• 数据平台最常见的是以 Hadoop 大数据为基础的。在最近十年，有很多家公司投入很多来做这个事情，把数据已经收集到中央化的一个 datalake 里面，那这个就是个很好的起点。其他的还有用数仓来做的，用 Teradata 或者是 Oracle， Gleenplum，MySQL Cluster，MongoDB，国内的话，有星环或者一些大数据公司。有一些特殊的场景，有人会用一些其它产品，比如说 ElasticSearch 会用来做一些全文搜索，但往往那个只是配合，他不会整体的放在这上面。

• 同步工具就很多，有开源的，有商用的。开源的话，比如有 Kafka、Kettle, Spark ETL 、Talend，商用的的话要有 Informatica、Golden Gate，包括我们 Tapdata 也提供这种类似的数据同步工具。

• 治理方面比较做的比较好的可能是开源的话，有 Apache Atlas，那如果是开源商用的话 Informatica 应该是最老牌的，Erwin 这些都是比较经典的这种数据治理的公司,可以配合这些产品来把中台里面数据进行编目和治理管理，Oracle 也有相应的产品。

• 数据服务就是涉及到API。我们见的最多的可能还是大家用 spring 来搭建一个 API 框架，或者有一些比较现成的 API 机，像 Kong 比较流行。Kafka 是提供一种流式数据的服务，可以做 streaming,Loopback也是可以用 nodejs 的方式来提供 API。Mulesoft 和 CA 都是一个非常成熟的 API 产品，当然他们的价格也不便宜。

• 他们的优势是他会给你一套整体的 API。不仅仅是服务方案，还有管理方案，他的监控、安全、认证、鉴权，然后把你所有的不管是 data API也好，你的业务API也好，都有个统一的管理界面和一个 gateway的方式来帮他做好。

• 这里面大家可以看到有非常非常多的选择。如果咱们已经有的话，基本上是用已有的工具，如果没有的话就可能要好好的来看一下看看哪些厂商，或者是一些共享的方案。下边我们也会分享一个方案，可以参考一下来一个快速的选型。

（3）数据平台产品分类：

对数据平台比较关注的来看一下数据平台产品分类。

1. 数据平台的这种产品从90年代开始，从关系型数据库到21世纪的数仓MPP，到后来的大数据，到现在的很多的NoSQL，NewSQL，有非常多的种类。他们都有什么样的特色呢？是否合适来做数据中台的一个存储呢？

2. 数据统一平台的特点对比：
   

3. 数据统一平台选项参考：
   这里简单来看一下，如果是做数据统一平台选型参考的话，从它的海量数据能力，响应时间和并发能力和他支持多结构数据的能力上，我的个人见解。比如说我们说的现在的NewSQL的吧，他就是对多结构数据支持不是特别的理想。包括RDBMS、MPP也都是这样，那这个时候大家可以考虑一下用哪种方式。这取决于你的场景，MongoDB确实他有他自己的一些弱点，比如做多表关联的时候其实并不是他的优势，我们会建议尽可能避免这种多表关联的场景。但是如果你真的是避免不了的话，那他可能就不是一个很好的选择。
   

4. 选型建议:
   

这里是我的一些小小的选型建议，从我个人的出发点，按照我的自己的跟客户的一些交流的经验看了他们的一些情况，然后也是经过一些项目的实施，就是提供的一些情况，然后也是经过一些项目的构实施提供的一些建议。

• 如果你已经有Hadoop或者数仓的统一平台，我们很多的头部企业，大型企业都是已经有的，这个时候你是不希望从头开始构建一套新的什么所谓的中台架构。你基本上可以基于这个基础之上，配合他的数据治理，把它打造成一个数据资产体系，然后加上他的Data API。对于这种情况，我们刚才看到的很多的已有的数据中台的解决商，他都是基于这种大数据的方案来做的，所以他们的一些能力。往往是已经跟你Hadoop Hive之类的或者数仓呀做比较好的结合，那些同步工具，ETL工具都是有比较不错的结合了，你就可以在这个基础上只是用它的理念来构建。

• 如果你还没有数据统一平台，没有数仓，没有这个Hadoop之类的话，这个时候我们觉得可以考虑一下，就是我们推荐的这种MongoDB的方案，会非常理想，因为我们相对来说是比较简单一些。起步会快，假设真的不行，你也可以很快就见效，我们叫做非常 fail fast，错就错的快一点，不要花很长的时间才发现不行，那如果你还没开始构建的话，一步到位就可以拿到。因为我们刚才讲的MongoDB在数据平台上是有很大的优势的。如果是Hadoop的话，最近几家合作的海外的那几家都三家只剩下了一家Cloudera，其他两家都已经被收掉了或者被合并了，这也是因为它的本身有很大的局限性，很复杂很难用，投入很大，收效比较小。

• 如果你的中台主要目的想支撑前端交互式应用。那MongoDB是最理想的，因为我们的特点就是高并发、低延迟、横向扩展。然后非常面向开发，非常面向JSON API，这是非常理想的。那Hadoop的话，他一开始大数据都是以分析为主的，不是为前端为主的。

• 反过来，如果你的中台数据目前你看不到有什么前端的业务场景会来使用。最主要的还是解决这个数据统一。而且你觉得有很多复杂的表。要做很复杂关联，这个时候一下子把它合并到一个JSON里面是几个JSON里面是比较麻烦的，那可能是MongoDB的适用度就一般了。那反而是那些基于传统的数仓的，那个会比较做的会比较好一点，相对来说是功能上比较完善一点。

• 如果你是比较喜欢有些比较快速，能够比较轻一点的，比较简单一点的。下载下来就可以安装可就可以跑起来，那我们Tapdata这种方案会比较轻便一点。

• 如果你没有数据工程师的话，我们MongoDB的一个的优势就是比较自然，比较直接，比较容易理解数据模型，会是一个不错的选择。

• 如果你没有明确你这个中台搭建的想做什么，我们可能不合适，因为我们可能这个事情做出来以后没有什么太大的效果的话，你就发挥不了我们的所谓的这种价值。其他的方案，我也不知道是不是合适了。

有了这么多解决方案，我们来看一下，如果是基于一个 MongoDB 的方案会是怎么样？我们刚才只是讲的数据平台在做一些选择，但是做一个完善的数据中台的话还需要很多其他模块，所以这里面是用到了另一个产品，就是Tapdata DaaS。通过 MongoDB 和 Tapdata DaaS 这样一个组合，一起来做这个中台的解决方案。

第四部分——tapdata DaaS 基于 MongoDB 的数据中台落地方案

（1）落地

MongoDB 作为中台架构的数据平台

• 我们先来看MongoDB作为中台架构的平台优势。
  ①MongoDB 是一个多模数据库。所谓多模数据就是他一套系统里面一套分布式集群，里面可以做很多的不同的事情，有的时候你可以把它作为一个内存数据库，可以把它作为一个目录数据库，也可以把它作为一个IOT的数据模型。就是说它的多模性特性是比较有特长的，而且它的自动扩展能力也是非常适合这种中台的统一平台的需求。多模多态，对汇聚性也是非常重要，因为我们需要支撑不同结构、半结构化、非结构化、甚至一些图片文件能够来做到这一些。
  ②另外，就是MongoDB的API友好能力，采用 JSON 作为传输格式。我们知道现在都是微服务，都是通过Data API的方式交付数据中台的数据。前面业务中台往往都是用微服务，也是通过这种RESTful API,那MongoDB的这种JSON模型对新一代的这种架构式有得天独厚的优势，你会发现你花很少的时间就可以把这个API构建好。另外，MongoDB 也原生提供这种 Streaming API 帮助来做一些流处理的事情。所以MongoDB 作为一个中台的统一平台数据库，其实是有非常得天独厚的条件。
  ③当然，除了他的多表关联是可能是缺陷。
  
  ④MongoDB另外一个优势就是它的对象模型。我们的 JSON 模型就是非常接近于我们开发的对象，Json也好，或者是Java 里边的 Object，python 里面的 Dictionary。
  

• 一个传统的数仓，或者是现在的数据中台的数据统一平台，要做很多的数据治理。比如要做一系列的建模的工作有概念建模、逻辑建模、物理建模。而且物理建模就是我们所谓的物理层，那就涉及到关系模型。管理一个逻辑对象，怎么样转化成五张表，十张表，20张表遵从第三方指示，这里面其实是很复杂，也会很花时间。你要设计一个很好的模型，怎么样来支撑未来的业务，这也是为什么传统数仓会花那么多的落地项目代价来做这个事情。

• 而MongoDB的解决方案能轻松地处理这方面的事情，这就是为什么 MongoDB 会受很多开发者的喜欢：MongoDB 在建模方面是一个非常独特的形式，它的模型是基于类似于这种逻辑模型的对象模型。你可以把它理解为差不多是一对一。业务人员一般都会明白这个概念，比如建模、逻辑建模，这些模型他们心里都有数。他们就是可能不懂那种种 DBA 说出来的的 Oracle 的这种建模方式，但是对于 MongoDB 来说，其实你只需要达到逻辑建模层的话，你就可以把这事情做了。而且这个模型建完了以后，直接可以用REST API的方式交付出去。从这一点上来说，它是有一个技术上是非常独到的一个先天性的优势，尤其对我们想做这种基于API的这种服务中台来说。

• MongoDB 的读写分离，HTAP支持全渠道业务需求。 有一些开发者会说是 HTAP （Hybrid Transaction and Analytical Process），就是说又可以做分析业务，也可以做的交易型的业务。在MongoDB里面，我们怎么样来做这种事情呢？比如说一个集群里面，一个cluster，一个复制集，我们有五个节点，四个Secondary，一个primary。左边的primary节点可以用来直接。直接跟我们的手机或者是网页端的应用进行交互收集，采集数据，用户数据。那MongDB自动同步把的数据从primary同步到secondary里面。

• 然后我们还可以除去左边三个，作为正常的高可用集群来说，我们还可以拿出两个节点专门用来做分析，你看他这个use=analytics。就是一个标签，就比如说这两个节点是只是用来做于分析型的，那这个时候我们就可以用它来上面。加上我们的BI connector，或者是直接用我们的MongoDB charts和compass，直接可以对接MongoDB数据库做一些展示：kpi，dashboard等等。我们也可以通过一些大数据接口，比如说spark connector 来做一些大型的machine learning或者是AI都是，有很多的这种应用场景，那这些都可以最实时的，在你最新鲜的数据上通过一个读写分离的架构上来完成，你不需要再ETL。在MongoDB里面，这个ETL的需求量是非常非常少的，因为可以通过原生的这种同步来提供数据的汇聚，数据放到这个分析集群里面。

• MongoDB 还有一个触发器的 API 也是比较实用的。就是大家如果不是太了解的话从3.6开始有个change stream，你可以用来订阅数据库的更新事件。比如从IOT设备过来，有一个灯亮了，有一个设备进入一个地理围栏里面发个报警。你都可以通过一个非常简单的订阅方式获取这些事件，然后做一些实时的，响应式的处理，不管是在dashboard上面显示个警告，或者是把它推送到一个Message Queue 、Kafka之类的都可以，直接就用MongoDB的原生的功能来完成。

（2）Tapdata DaaS 是什么？

Tapdata DaaS 是钛铂数据为现代企业加速数字化转型设计的数据平台，通过提供采集、存储、组织和增强等一揽子解决方案，从而得到更加方便和友好的数据服务。

Tapdata DaaS 提供了4个主要的功能模块，数据采集和同步、数据转换和治理、元数据管理、和数据服务。

Tapdata: 为MongoDB量身定做的中台构建工具集

Tapdata DaaS 可以看做是 MongoDB 生态上一个工具集。 要做一个数据中台，要同步、要治理、要建模、还要做API发布，这些都不是 MongoDB 做的事情，MongoDB 主要是做数据库为它的核心的主要的功能，其他的相应的功能就可以通过一些外围的工具。而 Tapdata DaaS 可以快速的来实现这些不需要用代码的方式快速把数据的同步，建模和治理，以及发布给快速的做出来，这个大概就是一个整体，Tapdata DaaS 加 MongoDB 的架构。下图中的蓝色的部分就是中台的几个其他部分,绿色的就是MongoDB 的数据平台。

1. 数据同步及处理能力：
   结合 MongoDB ， Tapdata DaaS 这套方案是可以快速落地， 可以最快的时间对接上数据进行建模、同步，然后拉到中台里面并进行把它发布出来。举一些例子，比如说可以从 Oracle database 里面把它的表的数据拖到 Tapdata DaaS 的目标的中台库里面，然后对数据进行 JSON 建模，或者是一对一建模。在这个过程中，还可以是进行实时的同步，基于日志的同步。Tapdata DaaS 数据源可以支持 SQL server、Oracle、Sybase、MongoDB、DB2 、MySQL、Redis、Elasticsearch 等等，也支持文件，比如 excel、CSV。

2. 数据建模能力：
   基于这种内嵌的模型Embedded的模型，把一对一，一对多的关系，甚至多对一的关系就直接就合并到里面去。这个会对客户数据合并、产品数据合并、订单数据合并有非常好的效率的提升。Tapdata DaaS 提供一个可视化的建模见面，就可以很容易完成这种合并工作。

3. 数据治理能力：
   数据进到库里面，进到中台里面。有来自于不同的数据库，几十套，上百套都有可能，每一套库里面有几百张表在里面必须有一个非常好的分类，非常好的组织能力。按照不同的目的、不同的角色、不同的规则或者数据体系给它分门别类建好在这里面，把这数据打好标签，这样的话可以快速的让大家高效的来使用到这些数据。

4. 数据API发布能力：
   可以通过RESTful API快速的交付出去。提供图形化低代码开发工具，只需要几分钟的时间就可以简单的发布数据给其他使用方调用。兼容Open API，也可以支持行级列级的过滤。同时也会有一些API文档的测试能力，权限管控等等，这个是中台必不可少的能力之一。