大數據服務化架構
關鍵技術一：配置即開發
平臺用戶分爲兩類角色：其一是數據服務生產方，其二是數據服務調用方。數據服務生產方只需要配置，做到“配置即開發”，配置包括：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網關，從而享受已有的基礎網關能力，爲業務提供數據服務能力。
參考文章:
統一數據架構業務概念視圖
統一數據服務層框架(Unified Data Service Layer, UDSL)
MongoDB、HBase、Redis等NoSQL數據庫的應用使得持久層的開發變得更爲複雜,開發者需要掌握和使用不同類型的開發接口。統一數據服務層框架(Unified Data Service Layer, UDSL)是一個持久層框架。它統一了持久層開發的API,開發者通過UDSL可以使用一致的讀寫接口進行持久層的開發,無需再關心數據源接口的差異。對不同類型的數據源,UDSL通過相應的擴展模塊提供支持,比如DB模塊對應着關係型數據庫,Text模塊則對應着MongoDB數據庫,這種良好的模塊化設計使UDSL具備了對新數據源進行擴展能力。
Cache模塊
Cache模塊是UDSL的核心模塊之一, 它在很大程度上提升了UDSL的查詢性能。在Cache模塊中,UDSL實現了一個基於Redis的高性能分佈式緩存,還提供了緩存規則的功能。通過制定緩存規則,應用可以把大部分不經常被訪問的查詢結果濾掉,以減少緩存的空間消耗。得益於面向切面的編程設計,UDSL的緩存是無侵入式的,只需要使用Java註解在被緩存的方法上進行配置即可使緩存生效,無需修改任何的業務邏輯代碼。