引言——首先來聊聊現代企業資料架構及痛點：

1. 資料孤島：低效率和利用困難的根源
2. 應用瓶頸：傳統方案資料倉庫、資料湖的不足
   ?
   單講這兩個問題你可能會疑惑——為什么會出現這樣的問題？
   ?

所以下面來講講兩個實際的例子來細講一下這兩個問題：

第一部分——兩個實際的場景例子引入

1.以航空公司的場景為例：

??航空公司的市場部計劃推出一個新產品或者是一個客戶活動，會希望了解哪一種渠道是某類客戶最常用的？當想到這個問題的時候，發現航空公司的客戶觸點太多了，

??PSDP行程訂單，投訴、行李系統，常旅客系統，手機App系統等等，這些系統都是航空公司在不同階段，不同的業務部門建立的應用，這些應用在部署時只會以本業務為目標，而不會考慮到企業其他業務能夠很好的對接，如果這些應用中的資料沒有做到統一的話，那要花費數天或者數周才能得到結果，甚至都不知道哪里能夠拿到資料，有時就算知道，還要協調其他業務部門來正確地給到，

2.以保單貸小程式的場景為例：

??當客戶通過這個保單貸小程式申請現金貸的時候，如果客戶在保險公司中已購買過重疾險、人壽隙訓財產險，系統可以根據客戶的保單額，在一分鐘內判斷出提供給客戶適合型別的現金貸，

??在上線的時候發現，這個保單貸小程式很快開發好了，但是資料在人壽、重疾、財險等不同的系統里面，有些還需要推薦系統和標簽系統，所以要花很多的時間來做資料的對接，這個時間是數周、甚至數月，因為其中不只是資料問題，還涉及到權限等問題，

綜合分析：

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 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檔案的測驗能力，權限管控等等，這個是中臺必不可少的能力之一，