做者介紹： TJ，唐建法，Tapdata 鈦鉑數據 CTO，MongoDB中文社區主席，原MongoDB大中華區首席架構師，極客時間MongoDB視頻課程講師。
「怎樣能夠來搭建一個數據中臺？」 身處數據處理行業，常常被客戶問到這樣的問題。
數據中臺究竟是什麼，是產品、技術仍是一個架構……，
在關於數據中臺的概念鋪天蓋地的時候，咱們來聊一聊數據中臺的架構，技術上實現，以及如何在企業落地，實實在在解決問題。
1、現代企業數據架構及痛點
– 數據孤島：低效率和利用困難的根源
– 應用瓶頸：傳統方案數據倉庫、數據湖的不足
咱們先以航空公司的場景爲例：
航空公司的市場部計劃推出一個新產品或者是一個客戶活動，會但願瞭解哪種渠道是某類客戶最經常使用的？當想到這個問題的時候，發現航空公司的客戶觸點太多了。
PSDP行程訂單，投訴、行李系統，常旅客系統，手機App系統等等。這些系統都是航空公司在不一樣階段，不一樣的業務部門創建的應用。這些應用在部署時只會以本業務爲目標，而不會考慮到企業其餘業務可以很好的對接。若是這些應用中的數據沒有作到統一的話，那要花費數天或者數週才能獲得結果，甚至都不知道哪裏可以拿到數據。有時就算知道，還要協調其餘業務部門來正確地給到。
再來看一個保單貸小程序的案例。
當客戶經過這個保單貸小程序申請現金貸的時候，若是客戶在保險公司中已購買太重疾險、人壽險或財產險，系統能夠根據客戶的保單額，在一分鐘內判斷出提供給客戶適合類型的現金貸。
在上線的時候發現，這個保單貸小程序很快開發好了，可是數據在人壽、重疾、財險等不一樣的系統裏面，有些還須要推薦系統和標籤系統。因此要花不少的時間來作數據的對接，這個時間是數週、甚至數月。由於其中不僅是數據問題，還涉及到權限等問題。
以上的情形都是企業中常見的數據孤島的問題，並且隨時 IT 建設的發展，這個問題會原來越常見。
數據孤島成因，是因爲事業部門在建設 IT 服務的時候，分別以各自業務建設爲核心，而不是以數據建設爲目標而造成的。
其次，經常使用的數據庫如Oracle, SQLServer, DB2, Sybase，這些關係型數據庫一直以來存在性能擴展的瓶頸。致使在上大的系統，或者客戶量增長時，須要採用分庫分表的方式。由於單個庫沒有辦法支撐到太多的業務量。這也造成了大量數據孤島。
數據孤島帶來的影響嚴重阻礙了新業務對已有數據的重複利用:
- 須要大量時間對接和同步；
- 用戶體驗降低，數據不完整不實時；
- 重複建設，複用率低等。
爲了解決數據孤島的問題， 目前的解決方案，有應用層面 ESB 企業總線、MQ等；從存儲角度來講，有數倉Teradata，Greenplum，以及數據湖。這些方案均可以在必定層面上解決問題，可是存在侷限性：
首先，這些方案都是面向分析場景，對於數據抽取不及時，多數是 T+1 方式，也就是說業務獲取的數據，是系統昨天生產出來的。這些數據在數倉及數據湖中處理造成了大量報表及結果數據，經過下載、導出等方式進行交付，形式粗放。全部目前市面上的大數據平臺，大部分的場景是偏重於分析，主要用於作BI，作報表、Dashboard，來對企業的運營和客戶有所洞察。
而對於企業運營來講，關鍵的、核心的能力不是後端的分析，而是在前端與客戶交互，與業務交互，與流程交互。
基於上述狀況，數據中臺應運而生。
Tapdata 鈦鉑數據
新一代實時數據融合平臺產品和解決方案提供商
行業領先的同異構數據庫實時同步解決方案提供商
聯繫咱們獲取企業版 Demo：team@tapdata.io
當即體驗線上異構數據庫同步服務：cloud.tapdata.net