本文是圍繞著快手的資料服務化中臺進行介紹。第一部分是背景介紹，包括資料開發的痛點，第二部分是介紹大資料服務化平臺，包括平臺架構以及關鍵細節詳解，第三部分是經驗總結和未來思考。
背景快手是一家資料驅動的公司，資料扮演了非常重要的角色，而資料的生產加工主要依靠資料開發工程師，其工作內容會涉及多個方面：資料開發工程師則首先根據業務需求開發好高質量的資料，通常是結構化資料（資料表）；其次，開發穩定可靠的資料服務，並透過API方式交付給業務方使用。資料開發工程師有兩個痛點：1）開發資料服務門檻高；2）重複開發資料服務。
痛點一：開發資料服務門檻高資料開發工程師除了開發完資料表外，通常還需要思考如下問題：
資料如何交付：業務通常期望使用資料介面方式來使用資料，而非資料表，這會更加靈活、解耦、高效。資料開發工程師因此需要建立對應的資料服務。服務如何開發：資料服務有多種形式，通常要求開發工程師有微服務知識、服務發現註冊、高併發等。許可權、可用性問題：開發完資料服務後，需要考慮許可權問題，確保資料資源能被安全的訪問；此外還需要考慮可用性問題，要以多種手段保障資料訪問的穩定性。運維問題：資料服務本身涉及多種運維問題，如擴容、遷移、下線、介面變更、服務報警等。以上問題都需要資料開發工程師去解決。這要求資料開發不僅僅是開發出資料表，還需要將資料表包裝成一個獨立的、靈活的、高可用的、安全的資料服務。這對於資料開發工程師要求很高：除了具備基本的業務需求捕獲、資料建模、SQL開發等能力外，還要具備開發高可用、高效能的資料服務能力（包括java開發、微服務等）。
痛點二：重複開發資料服務快手很多業務線（如支付業務、直播業務、賬戶業務等），都存在資料需求，各業務線都做著：1）資料同步到線上資料庫和快取；2）建設微服務等開發，其中不同業務線下，資料同步和微服務通常有很多共同之處，重複煙囪式的開發意味要重複開發資料服務，造成了人力資源浪費，而且開發效率低，從資料開發到最終交付資料服務，需要經歷較長的週期。
基於上述痛點，我們開始建設統一的資料服務化平臺。由此開啟一個新模式去解決問題。
大資料服務化平臺資料平臺本身的定位是一站式自助資料服務平臺。使用者透過平臺來建立資料服務介面、運維服務、呼叫服務。平臺秉承“配置即服務”的理念：資料開發工程師不再需要手寫資料服務，只需要在平臺上進行簡單配置，平臺便可自動生產和部署資料服務，從而提升效率。
系統架構大資料服務化業務架構如下所示，Data Lake 資料湖中儲存原始資料，經過資料開發之後，形成按主題域組織的資料資產。此時資料資產通常是在資料倉庫，訪問速度較慢，因此需要透過資料加速到更高速的儲存介質，最後經過多場景服務介面，服務於業務。
在技術架構方面，資料介面形式有 RPC 和 HTTP 兩類介面。RPC 介面不需要重複建立連結，且傳輸資料時會被高效序列化，適用於高吞吐場景下的微服務，實現負載均衡、流控、降級、呼叫鏈追蹤等功能。相對而言，HTTP 介面傳輸效率低一些，但使用非常簡單。
關鍵技術一：配置即開發平臺使用者分為兩類角色：其一是資料服務生產方，其二是資料服務呼叫方。資料服務生產方只需要配置，做到“配置即開發”，配置包括：1）資料來源；2）資料加速到何處；3）介面形態，訪問方式；4）配置獨立的測試環境，訪問隔離的測試資料。當配置完畢後，資料服務平臺便會根據配置清單，完成介面的自動化生產和部署。生產和部署完畢後，呼叫方在平臺申請服務許可權呼叫。透過自動化生產，達到配置即開發的目的，從而極大的提升效率。
關鍵技術二：多模式服務形態資料服務有多種服務形態，包括：
KV API：簡單點查，可以支撐百萬QPS、毫秒延遲。這類API是透過模板自動化創建出來，支援單查、批次查詢等介面，返回的結果是 Protobuf (PB) 結構體，從而將結果自動做了 ORM，對於主調方更加友好。典型場景包括：根據IP查詢geo位置資訊、根據使用者Id查詢使用者標籤畫像資訊等。SQL API：複雜靈活查詢，底層基於 OLAP/OLTP 儲存引擎。透過 Fluent API 介面，使用者可自由組合搭配一種或若干種巢狀查詢條件，可查詢若干簡單欄位或者聚合欄位，可分頁或者全量取回資料。典型場景包括：使用者圈選（組合若干使用者標籤篩選出一批使用者）。Union API：融合API，可自由組合多個原子API，組合方式包括序列和並行方式。呼叫方不再需要呼叫多個原子API，而是呼叫融合API，透過服務端代理訪問多個子查詢，可以極大降低訪問延遲。關鍵技術三：高效資料加速前面提及的資料資產，通常是存在於低速的儲存引擎中，無法支撐線上業務高訪問流量。因此需要以系統化的方式進行資料加速。目前有兩種加速方式：1）全量資料加速；2）多級快取（部分資料加速）。
全量資料加速
從多個數據源攝入原始資料（如Kafka，MySQL、線上訪問日誌等），進行加工建模後，得到資料資產。資料資產經由獨立的資料同步服務，同步至其他更高速的儲存引擎，如 redis、hbase、druid等。資料同步支援一次性或者週期性（小時、天、周等）將資料從Hive同步至其他儲存中，資料同步本身是基於分散式的排程系統，核心是基於 datax 進行資料同步。大資料服務化平臺單日同步的資料量達到1200億條，資料size達到20TB。
多級快取
大資料服務化平臺會使用 Redis、Hbase、Druid、Clickhouse 等方式儲存所有資料，但是部分儲存如Hbase速度可能較慢，針對熱點資料需要使用額外的熱點快取來Cache資料。熱點快取是多級快取，針對每個API介面，使用者可自由搭配組合多級快取、靈活設定快取策略。此外，針對資料較大的API，還可配置資料壓縮，透過多種壓縮方式（如 ZSTD, SNAPPY, GZIP 等），可將資料量顯著減少（部分API 甚至能減少90%的資料儲存量）
關鍵技術四：高可用保障服務可用性是微服務領域內的一大核心，服務的高可用通常需要組合多種手段來保障。快手資料服務化平臺透過多種方式來達到高可用的目的，主要包括：
彈性服務框架資源隔離全鏈路監控彈性服務框架
資料服務是部署在容器雲環境，容器雲是快手自研的彈性可伸縮的容器服務，部署在其中的RPC服務會註冊到 KESS （快手自研服務註冊與發現中心），供主調方去呼叫，如有離群壞點，會自動摘除。服務呼叫是基於 RPC，全鏈路都有監控，包括服務可用性、延遲、QPS、容器CPU、容器記憶體等情況。
資源隔離
資源隔離是可用性保障的常見手段之一，透過隔離將意外故障等情況的影響面降低。不管是微服務，還是儲存，我們都按照業務 + 優先順序（高、中、低）粒度隔離部署，獨立保障，業務之間互不影響、業務內不同級別也互不影響。同一業務線內可能有多個不同資料服務，透過混合部署，提高資源使用率。
全鏈路監控
服務很難避免出現問題或者故障，一旦出現問題，及早發現及早介入是非常重要的。服務平臺構建了全鏈路監控，包括：
資料同步：對資料資產同步至高速儲存的過程進行監控，包括資料質量檢測（過濾髒資料）、同步超時或者失敗檢測等服務穩定性：構建一個獨立的哨兵服務，來監測每個API的執行指標（如延遲、可用性等），客觀的評估健康度業務正確性：資料服務需要確保使用者訪問的資料內容和資料資產表內容是一致的，因此哨兵服務會從資料一致性層面去探查，確保每個API的資料一致性總結和展望大資料服務化平臺從2017年演化至今，已經支援多類應用場景，涵蓋直播、短影片、電商、商業化等線上業務，生產者中臺等準線上業務，運營系統等偏內部資料系統等，目前平臺線上業務總 QPS 達到 1000W，平均延遲在毫秒級；對於準線上業務和內部資料系統，基於CH、Druid等多種資料引擎，支援多種靈活查詢。資料服務平臺支援了多種模式API，很好滿足了多元化需求。此外資料服務平臺也支援服務許可權、API市場等豐富功能，進一步賦能業務。
大資料服務化平臺未來進一步發展方向主要包括：
貼近業務需求：資料服務平臺本身是為業務服務，透過賦能業務而對企業帶來價值，業務本身在不斷髮展，未來也會有更多的需求出現，因此資料服務平臺本身會不斷抽象和沉澱出公共資料服務能力。深耕資料資產：資料資產是資料服務之根本，如果沒有完善的資料資產建設，上面就很難構建出結構化的統一的資料服務，針對資料資產有較多內容，包括資產註冊和稽核、資產地圖、資產標籤、資產管理、資產開放和服務。大資料服務平臺的能力建設會朝著統一的 OneService 體系前進。主要包括三個方面：
支援豐富的資料來源：包括大寬表、文字檔案、機器學習模型（模型也是一種資料資產），來構建完善的資料服務。支援多樣取數方式：除了支援同步快速取數之外，還支援非同步查詢取數、推送結果、定時任務等多樣化方式，以滿足業務多種場景需求。建設統一的API閘道器：整合許可權管控、限流降級、流量管理等於一體，不僅平臺建立的服務可以註冊進API閘道器，使用者自己開發的API也可註冊進API閘道器，從而享受已有的基礎閘道器能力，為業務提供資料服務能力。作者：倪順，本碩畢業於北京大學，曾就職於Hulu，從事影片領域大資料研發工作，包括影片播放質量的資料建設以及基於資料驅動的播放體驗提升。目前就職於快手，從事資料中臺領域工作，主要負責大資料服務化基礎平臺建設。