阿裡推出“資料中台”時，點明其兩個核心概念，一個是One Data，一個是One Service。
阿裡One data 資料中台建設過程
很多人都隻注意到了One Data，中繼資料中心、名額字典、資料模型設計等等都屬于One Data理念下資料中台架構的重要部分。
但其實One Service——資料服務也是資料中台的核心，目前市面上的資料中台沒有好用的産品很大的原因就是資料服務沒做好。
資料服務平台架構
反而國内外專門做資料服務的産品好評不斷，今天展開介紹資料服務是如何提高企業資料開發效、降低資料開發成本、讓企業快速挖掘資料價值的。
01
屏蔽中間存儲，提高資料開發效率
資料平台加工好的資料，通常會以Hive表的形式存儲在HDFS 上。
如果想直接通過資料報表或者資料産品前端展現，為了保證查詢的速度，會把資料導出到一個中間存儲上：
- 資料量少的可以用MySQL , Oracle 等資料庫，具有部署維護友善、資料量小、查詢性能強等優勢。例如，資料量小于500W條記錄，建議使用資料庫作為中間存儲；
- 涉及大資料量、多元度查詢的可以用GreenPlum，它在海量資料的線上分析處理場景中有優異的性能表現。例如，資料量超過 500W 記錄，要進行多個條件的過濾查詢；
- 涉及大資料量的單Key查詢，可以用HBase。在大資料量下，HBase擁有不錯的讀寫性能。例如，超過500W記錄，根據Key查詢Value的場景。
由于不同的中間存儲，涉及的通路API也不一樣，是以對資料應用開發，每個資料應用都要根據不同的中間存儲，開發對應的代碼。
如果涉及多個中間存儲，還需要開發多套代碼，資料接入效率很低。
以資料API作為資料服務的主要方式
此時，資料服務為資料開發屏蔽了不同的中間存儲，通過使用統一的API接口通路資料，可以大幅度提高資料應用的研發效率。
02
完成資料接口複用，降低資料開發成本
如下圖所示，當我們開發“資料應用-經營分析”時，資料開發會基于a表加工c表，然後資料應用開發會把a和b的資料導出到“資料應用-經營分析的資料庫db1”中，然後開發經營分析的服務端代碼，通過接口1對web提供服務。
當我們又接到任務開發“資料應用-毛利分析”時，我們同樣需要用到b表的資料，雖然b的資料已經存在于db1中，但db1是“資料應用-經營分析”的資料庫，無法共享給“資料應用-毛利分析”。
同時，經營分析的服務端接口也無法直接給毛利分析用，因為接口歸屬在經營分析應用中，已經根據應用需求高度定制化。
以上，我們看到這樣的現象：即使資料重複，不同資料應用之間，在中間存儲和服務端接口上，也是無法複用的。
這種煙囪式的開發模式，導緻了資料應用的研發效率非常低。
此時，資料服務使得暴露的不再是資料，而是接口，接口不再歸屬于某個資料應用，而是在統一的資料服務上。
這就使接口可以在不同的資料應用之間共享，同時因為資料服務具備限流的功能，使接口背後的資料共享成為可能，解決了不同應用共享資料互相影響的問題。
03
建立從資料到應用全鍊路血緣
傳統的資料項目中，由于資料平台通過導出/導入或資料複制的方式為資料應用提供資料，資料一旦進入到下遊系統中，資料平台就無法監控其使用情況了。
即使用了中繼資料中心，也無法實作資料全鍊路血緣分析。
想象一個真實的場景：某技術人員突然接到了一堆電話報警：有大量的任務出現異常。經過緊張的定位後，他确認問題來源于業務系統的源資料庫：因為一次資料庫的表結構變更，導緻資料中台的原始資料清洗出現異常，進而影響了下遊的多個任務。
這時，擺在他面前的是一堆需要恢複重跑的任務。可是隊列資源有限，到底先恢複哪一個呢？哪個任務最終會影響到老闆第二天要看的報表？
雖然資料血緣建立了表與表之間的鍊路關系，但是在表的末端，我們卻不知道這個表被哪些應用通路，是以應用到表的鍊路關系是割裂的。
當某個任務異常時，我們無法快速判斷出這個任務影響了哪些資料應用，也無法根據影響範圍決定恢複的優先級，最終可能導緻重要的報表沒有恢複，不重要的報表卻被優先恢複了。
API調用分析
此時，資料服務打通了資料和應用的通路鍊路，建立了從資料應用到資料中台資料的全鍊路資料血緣關系，這就相當于我們在迷宮中拿到了一個地圖，當任何一個任務出現問題，我們都可以順着地圖，找到這個故障影響了哪些應用，進而針對重要應用加速恢複速度。
麥聰軟體，全球領先的DaaS廠商，輕量級資料中台上司者。世界500強集團中已有30多家選用，兩年内幫助近400家企業數字化轉型更進一步。核心産品麥聰DaaS平台包含統一資料管理和統一資料服務兩大子產品，具備資料內建、資料開發、資料品質、資料服務相關功能，歡迎大家帶着企業數字化問題與我們一起讨論。