為什麼說資料服務是資料中臺的標配？

有人認為，多維的資料分類體系已經夠用了，標籤就是一個“雞肋”；也有人認為標籤體系有有利於大資料的萃取和分析，提供畫像能力，實現精準推薦，必須是資料中臺的標配。

如果“標籤體系”確有爭議的話，那麼今天介紹的這個功能一定沒有爭議，它絕對是資料中臺的真正標配，它就是——資料服務。

資料服務的類別相當廣泛，有提供資料傳輸能力的叫做資料傳輸服務，有提供資料儲存能力的叫做資料儲存服務，有執行各種型別分析的叫做資料分析服務，還有提供資料安全管理的叫做資料安全服務等等。

這些都叫資料服務，但這些資料服務強調的是能力，更準確的定義是“Data as a Service——資料即服務”，但這不是我們今天要講的資料中臺的資料服務！

資料中臺的資料服務到底是什麼？

我的理解：不同系統之間使用服務的方式進行互動， 資料服務為資料和應用之間建立了一座“溝通的橋樑”，這座橋樑的存在形式是API。

可以把它想象成一個電源插座，例如，只需要你的吹風機有一個匹配的插頭，並將其插入，電流就會流向你的吹風機，就像資料流向你的資料應用一樣。

網上的很多文章中，喜歡將資料中臺用“廚師做菜”來形象比喻。廚師做菜一般有幾個步驟：買菜、洗菜擇菜、制定選單、炒菜。這幾個步驟在資料中臺的資料加工流程中被稱為：資料採集、資料清洗、資料建模、資料分析/資料應用。 資料採集

跟廚師做菜一樣，巧婦難為無米之炊，需要做幾道好菜，首先得有原材料，那麼資料採集/資料接入就是買菜的過程。

買回來菜需要摘洗乾淨，才能下鍋，資料清洗就是摘菜洗菜的過程，是需要把髒資料清洗掉。

菜摘洗好了，但炒什麼菜要需要根據客人下的選單來做。資料建模就像對為客人制定選單一樣，例如：客人喜歡什麼菜？魚香肉絲還是宮保雞丁，口味是甜一點，辣一點還是清淡一點等問題都要描述清楚並傳遞給“廚師”。資料建模就是將資料消費者的需求轉化為計算機能夠理解的語言。

根據客人的“選單”要求，炒菜裝盤。

好了，看到這裡有人不禁要問：說了這麼多，資料服務在哪裡？資料中臺到底為什麼需要資料服務？

在這個“廚師做菜”的過程中，有一個不能忽略的角色，不知道你有沒有發現，這個角色就是“服務員”。 他的任務是幫助客戶點菜，並將炒好的菜端到客人的桌上。而資料中臺的“服務員”就是資料服務，英文名字：OneService。

想象一下，你正坐在餐廳的一張桌子旁，那裡有可供選擇的選單。但如果沒有服務員，就會缺少的是將你的選單傳達給廚房並將你的食物送回餐桌的關鍵環節。這就是“服務員”（資料服務）的用武之地，接受資料消費者的請求，並告訴系統做什麼，將做好的資料服務以API的方式提供給資料消費者。

另外，在整個過程中， 資料服務還有一個作用，它遮蔽了底層資料的技術細節，資料消費者不需要關心“這些資料來自哪裡，哪個庫，哪張表，資料庫型別是什麼等”問題，只需要關心“這些資料能否滿足我的需要”就行了。

就如同你去餐廳吃飯，不用關心菜是從哪買回來的，誰是配菜的，誰是炒菜的等這些問題一樣，只需要關心這個菜合不合你的口味就行了。

在傳統的資料整合方案中，往往需要將資料從一個系統匯出/匯入，或複製到另一個系統當中。隨著企業資料應用規模的不斷擴大，需要在幾十個甚至上百個系統中進行資料整合，傳統的資料整合方式難度越來越大，暴露的問題也越來越多。

傳統資料整合需要將資料從一個系統複製到另一個系統中，過程中由於網路、介面、程式、任務以及其他的一些不確定因素都會導致資料在“搬家”的過程中“丟失”，從而造成資料不一致問題。

而透過資料中臺提供的資料API交付資料，大部分情況下不需要資料“落地”，強調使用權而不是擁有權，這樣就大大減少了資料在流向下游系統過程中造成不一致問題。

資料中臺會根據企業資料的型別、資料量大小、資料的應用需求等，設計相應的不同資料接入和儲存方案。例如：透過MySQL、Oracle接入資料量相對較小的資料，透過Greenplum接入資料量大且需要多維分析的資料，透過Hbase接入大量的keyValue資料，以及透過ES建立資料索引提升資料的查詢效率等等。這種情況下，如果按每種資料接入方式暴露資料的話，無疑是一個非常複雜事情。

而透過資料中臺將各型別資料封裝為統一的資料API，對外提供介面，能夠遮蔽資料接入多樣性帶來的資料整合複雜、效率低下等問題。

傳統的資料專案中，即使用了後設資料這樣的工具，也無法實現資料的採集、彙總、清洗、處理、應用的全鏈路血緣分析。尤其是資料平臺到資料應用的鏈路幾乎全部是割裂的，資料平臺透過匯出/匯入或資料複製的方式為資料應用提供資料，資料一旦進入到下游系統中，資料平臺就無法監控其使用情況了。

而資料中臺提供的統一資料服務API，為資料應用和資料中臺搭建了一座橋樑。 資料API只有透過授權才能被訪問，在給資料應用授權以及應用程式訪問資料API的時候，可以“標籤”的形式，將資料訪問鏈路通知給後設資料中心，從而打通了資料中臺到資料應用的鏈路，形成了資料的全生命週期血緣。

在很多資料專案中，還有一種情況比較常見：資料應用直接呼叫資料平臺的資料庫來訪問資料。這就會導致，一旦上游資料發生變更就會對下游的資料應用造成較大影響。

而資料中臺提供統一的資料API供資料應用呼叫，實現了資料中臺與資料應用的解耦。在資料服務內部建立與與各資料來源建立對映， 上游資料發生變更，只需要調整資料服務的對映即可，不會對資料應用的使用造成影響。

在資料中臺架構中資料服務層位於資料中臺上層，連線資料消費層，將已整合的資料以服務的形式提供給資料消費者，以獲得更好的效能和體驗。資料服務層具備的功能如下：

資料中臺接入資料的多樣性，決定了資料中臺的技術架構需要由多個大資料元件組成，例如：Hive、HBASE、GP、ES、Redis、MySQL、Oracle等等，而業務上對資料的使用可能是跨多個資料庫的。資料服務層提供的跨源資料服務，遮蔽了底層資料來源的技術差異，可以從不同資料來源提取資料，並按照業務需要進行編排，形成統一API進行對外共享。

按照不同的業務主題，組織形成統一的資料API。資料中臺繼承了資料倉儲面向主題的思想， 將位於不同資料中間儲存的同一業務主題的資料整合到一起，遮蔽多資料來源與多物理表，形成標準的資料服務供外部使用。例如：銷售主題，需要將企業的批發、零售、線上、線下、代理等等各個渠道的銷售資料彙集起來。

資料服務最終將使用者訪問的API 轉化為底層對各種資料來源的訪問，實現對資料中臺資料的一站式查詢，提供資料檢索、聯機分析、實時查詢等，提升資料查詢的效率。

資料和應用的分離會導致資料血緣無法完整追溯，資料服務不僅提供了連線資料和應用能力，還透過服務授權以及訪問監控等功能，將資料API的訪問情況實時寫入後設資料中心，形成完整的資料血緣。

資料API構建完成，並不需要資料消費者重複構建整合通道，而是透過授權“訂閱”的方式，讓資料消費者透過介面快速使用資料。

API閘道器服務使用雲原生技術提供了服務API的統一管理和監控能力，包括：服務註冊、服務自動發現、認證授權、流量控制、超時熔斷、安全控制、監控分析等。

服務拆分的越細則複用性越好，但如果只考慮服務重用，大量的細顆粒度服務將很難管理並且勢必會對整體效能帶來影響。服務的設計需要從業務需求、管理難以程度、效能特性等方面綜合考量。

服務的開發採用Restful API技術，該技術具有結構清晰、易於理解、方便擴充套件等特點，且介面規範標準，不論前端應用是java、.net、C#還是PHP都能夠呼叫。就像設計一個插座，一定要具備普適性，這樣不論你的吹風機插頭是美標的、歐標的還是國標均的都能夠適配。

DataOps是將DevOps的理念延伸到資料世界，提供了一種資料服務的持續運營方式。透過API閘道器進行服務的註冊和管理，實現資料服務的動態發現、自動部署、自動化監控。根據服務的執行監控資料對資料服務的進行有效治理，包括資料服務的迭代最佳化、服務編排、自動測試、服務下架等。

資料服務不是簡單的對外暴露一個API就行了