01 平臺介紹

 

/ 簡介

數據服務平臺可以在保證服務高可靠性和高安全性的同時，為各業務線搭建數據服務統一出口，促進數據共享，為數據和應用之間建立了一座“溝通橋梁”。

 

同時，解決數據理解困難、異構、重復建設、審計運維困難等問題，實現統一且多樣化數據服務以及數據應用價值最大化的目標。

 

 

在業務開發過程中，用戶可以自行選擇直查各種引擎，但各種引擎請求方式不同，返回數據格式不統一，需要針對各種引擎適配對應的查詢代碼，取數邏輯需要維護在代碼中。

 

這樣的取數方式，會給研發帶來較大的接入成本、運維成本。當取數邏輯變更也會需要研發更改代碼上線，可能導致上線期間線上取數邏輯的不一致。

 

而數據服務平臺創建的API統一了查詢和數據返回的格式，用戶只需維護API中SQL的取數邏輯和請求參數即可，大大降低了上層應用獲取數據的成本。

 

 

/ 領域介紹

用戶可以在數據服務平臺上創建：項目、數據源、物理表/邏輯表、就緒時間、API、API編排，App應用（psm）等主體資源；

其中數據源包含查詢數據庫連接信息；物理表是底層數據源中的表；邏輯表是數據服務平臺的概念，目的是能夠增強物理表的能力，例如邏輯表監控報警、切換主備、授權調用等等；就緒時間是數據的最新可用日期；API和API編排是數據出口，應用即消費者身份標識。

 

 

/ 架構概覽

DataLeap數據服務平臺整個系統主要分為兩個服務，平臺服務和引擎服務。

 

在過去的一段時間內，主要從質量、效率、成本幾個方面對數據服務平臺的能力進行建設，在保障數據服務核心通道能力質量同時，提高用戶使用平臺承接數據鏈路需求的效率，降低使用數據服務的成本。

 

當前，數據服務平臺已經具備了以下能力：

 

 

 

質量：保障數據通道的穩定與安全，為用戶提供事前監控告警以及事中容災的平臺能力。

 

1. 監控告警

 

● 監控能力：數據服務引擎對查詢的全部流量的，請求狀態、耗時情況進行上報。基于上報數據，為用戶搭建了API粒度監控看板，可以對API調用的SLA、PCT99等指標進行監控和分析。

 

● 告警能力：數據服務平臺在API創建過程會為API綁定默認的失敗率告警規則，并支持用戶在平臺上直接為API配置失敗率以及耗時相關的告警。

 

2. 權限管控

 

● 項目級別：可以對PSM授予整個項目的權限，即PSM對該項目下所有API都有調用權限。

 

● API級別：可以對PSM授予API的權限，授權后，PSM具備該API的調用權限。

 

3. 限流能力

 

● 數據源：平臺支持在數據源粒度上配置限流，即可以控制存儲集群或庫的整體從數據服務平臺的出口流量的大小，主要用于存儲并發能力較低的情況。數據源上層的所有物理表、邏輯表、API鏈路會共享數據的限流配置，能夠有效防止突發流量對存儲整體造成的沖擊。

 

● API：平臺支持在API粒度上配置限流，主要用于API共享場景，API Owner可以通過設置API限流，防止整體流量對底層造成過大壓力，API上的所有訪問PSM會共用該限流配置。

 

● API x PSM：平臺支持對API配置訪問PSM的精確限流，對于每個API已授權的PSM可以進行限流，超過QPS配置后，該PSM調用當前API的后續請求都會被拒絕。

 

4. 切流能力

 

● 數據源切流：數據服務平臺支持在數據源上進行集群粒度的同機房、跨機房切流。在數倉提前進行了數據雙鏈路建設的情況下，能夠在集群整體故障、或者其他區域機房故障的情況下，對集群進行容災切流。

 

● 邏輯表主備切換：

 

- 整表切換：邏輯表上支持對物理表配置備份表，并且能夠一鍵切換鏈接的物理表，提供了表級別的容災切流能力。

 

- 字段切換：對于NoSQL類存儲，數據服務平臺在整表備份的基礎上，還提供了細化到字段級別的備份和切流能力。

 

● API版本管理：數據服務平臺的API提供了版本管理的能力

 

- 一鍵回退：在API誤上線的情況，我們支持對版本進行一鍵回退。

 

- 版本灰度：基于API版本，我們支持了版本灰度發布（完全隨機灰度、逐漸HASH灰度）能力，用戶基于版本管理的新數據口徑可以灰度發布到線上。

 

 

 

效率：

 

1. 多種API形式

 

● 腳本式：支持自行編寫API的查詢SQL，該方式可滿足高階需求，支持選擇同源多張邏輯表進行處理。同時也支持了動態SQL(XML)。適用于同源多表Join等復雜SQL查詢場景。

 

● 向導式：無需代碼編寫，在界面勾選配置即可快速生成API(僅支持單張邏輯表)。請求參數為Where條件、返回參數為Select字段，系統自動生成查詢語句。簡單易上手，適用于簡單取數場景。

 

● 原生式：支持用戶靈活查詢數據集的一種Query，目標是對在圈選范圍內邏輯表進行靈活的重組查詢，適合數據分析面板類場景。

 

● 指標查詢API：結合Nuwa的指標、維度配置，組合為一個API進行指標查詢。

 

2. API編排能力：將于本文第二板塊詳細介紹

 

3. 函數能力：可以創建自定義函數，支持Python，JAVA等方式，在API前置或后置執行，以滿足特定的數據處理。

 

4. 邏輯表輕加工

 

● 邏輯資產主題：數據服務平臺的邏輯表支持了輕加工能力，用戶可以將多張物理表或者邏輯表，通過主鍵關聯的形式，聚合成一張新的邏輯表。主要用于構建邏輯寬表、數據主題、邏輯數倉APP層建設等場景。

 

5. 運維中心

 

● 智能問答：用戶可以輸入在使用過程中遇到的各種問題，基于數據服務平臺的文檔中心，分析助手會提煉出可能的解決方案和可供參考的文檔鏈接。

 

● 查詢分析：用戶輸入LOGID，系統會自動診斷本次查詢過程中數據服務出現的報錯情況，以及耗時情況。

 

結合報錯信息，會給用戶提供診斷意見。這個能力在部分場景提高線上問題排查定位的效率，解決了上層業務接入數據服務后對查詢鏈路問題黑盒的情況。

 

● 運維大盤：提供整體的運維概況，支持按照項目或者業務線的粒度，來聚合查看整體API、數據源、物理表、邏輯表、PSM的使用情況。

 

提供了包括QPS、SLA、PCT以及活躍率等多種信息。讓開發者和運維人員更方便地掌握數據資產的運行狀況，能及時發現問題，來保證用戶服務的穩定性和可用性。

 

● 自助分析：采用了AI技術來構建智能助手，提供智能問答和查詢分析兩種能力。

 

成本：目標幫助平臺用戶對數據服務平臺的數據資產進行成本管理和治理，本模塊能力處于建設中，未來會上線成本中心功能。

 

 

02 API編排介紹

 

/ API編排簡介

 

1. 什么是API編排？

 

隨著 API 的數量不斷增加，單一的 API 調用已經無法滿足復雜業務流程的需求。這就像我們平時做菜的時候面對眾多食材，單靠直覺和經驗可能難以保證每次都能烹飪出完美的菜肴。

 

這時候，我們需要一本食譜來指導如何將食材結合起來，使之成為一道佳肴。在 API 的世界里，這本食譜就是 API 編排。

 

2. 解決什么問題？

 

一個復雜的業務邏輯可能需要多個 API 的參與，業務側還需要編寫大量的代碼將多個 API 關聯使用，如果關聯邏輯發生變更，還需要研發修改代碼上線來支持，這樣的模式，研發成本較高、可維護性較差。

 

基于類似的場景，下面舉幾個例子以幫助大家來更好的理解 API 編排可以解決哪些復雜業務場景：

 

● 目前有兩個 API，一個是獲取實時數據的 API，另一個是獲取離線數據的 API，根據就緒時間判斷是否要獲取離線數據，如果就緒時間未就緒就查實時 API，已就緒就查離線 API。

 

● 業務場景中使用了多方數據源，想實現異構數據源的數據整合。

 

● 想對 API 的返回參數進行一些數據處理或者計算，例如電商平臺希望根據用戶的購買歷史和瀏覽行為來提供個性化的產品推薦。API 節點首先調用產品信息 API 和用戶行為 API 獲取所需數據，然后編程節點對這些數據進行分析和處理，最終生成推薦列表。

 

API 編排主要是依賴各個 API 節點來拓展 API 的數據能力，所以想要高效快速實現一個 API 編排，API 的生產是第一步。

 

同時 API 編排的測試、調用和 API 一樣，可以把一個 API 編排視為一個 API。

 

 

針對編排中目前已有的七個節點，下面表格中有詳細的介紹：

 

節點類型	節點含義	節點依賴
開始節點	編排的起始節點，需要輸入參數，類似 API 的請求參數	輸入參數
結束節點	編排的輸出節點，數據出口，類似 API 的返回參數	上游輸出
API節點	可以選擇當前項目下所有腳本式、向導式API	當前項目下的API
函數節點	支持Faas、自定義函數	Faas、Python、Jar
分支節點	控制數據的流向，根據上游節點的輸入進行條件判斷，從而決定數據流向下游哪個節點	上游輸入&條件判斷
編程節點	支持Python，可以編寫Python腳本進行數據處理	tos、Minio、lego
合并節點	支持上游多個節點的append、merge、join配置	上游節點的輸出

 

 

/ 原理介紹

 

1. 編排架構

 

 

 

API編排目前作為數據服務平臺較為進階的功能，一方面需要保證調用方式和原有API調用一致，盡量讓用戶以最小的方式接入編排；

 

另一方面又要求數據服務平臺的引擎在執行編排過程中無需進行復雜的元信息拼裝。我們將編排的元信息拼接到了API的元信息中，這樣編排也能復用API的一些例如QPS、緩存等配置信息。

 

因為考慮到目前API元信息結構已經比較復雜，在一些SQL較長，輸入輸出參數、綁定邏輯表較多的業務場景中屬于大Key，大Key的元信息會一定程度上導致引擎執行耗時長，元信息存儲使用的redis、abase的內存消耗大等一系列問題。

 

所以我們并沒有將編排內所有節點的元信息一并組裝到API元信息中。目前元信息中存儲的是編排的調用鏈路，各個節點的元信息作為單獨的key單獨存儲。

 

 

 

2. 編排執行原理

 

● 整體方案設計

 

在API編排 中，主要有兩類元素：節點和有向邊，節點是進行數據處理的基本單元，也是數據服務平臺提供給用戶進行自定義數據處理的節點；有向邊是數據傳輸的抽象表示，是用戶設置的數據輸入和輸出。

 

 

調度執行流程圖：

 

 

數據服務平臺的編排調度能力如下：

- 編排DAG 合法性檢測，例如：環的校驗、孤立節點檢測

- 節點可以選擇性調度下游節點，沒有被任意上游節點調度的節點不會被執行

- 節點的超時設置、限流、重試

- 日志和埋點接入

 

每個節點的狀態機如下：

 

 

 

 

● 詳細方案設計

 

數據服務平臺的編排任務主要是讓輸入數據通過特定的工作流加工后，返回輸出結果。編排服務主要是工作流的構建和調度，與很多其它的編排調度系統類似，核心在于構建 DAG（Directed Acyclic Graph，有向無環圖）。

 

數據服務平臺的編排調度與其它編排調度框架構建 DAG 圖 Directed Acyclic Graph，有向無環圖）并調度執行的不同之處在于：

 

1. 只有一個開始節點和一個結束節點

 

2. 數據經過每個節點的加工之后，可以有選擇的傳遞給下游若干個節點

 

3. 部分節點可以在運行時有選擇的調度它的下游節點，而不是全部調度

 

數據服務平臺對編排調度框架的要求是高性能、低時延，易擴展，根據自己的需求，我們開發了一套更適合的編排調度框架，主要細節如下：

 

1. 靜態構建 DAG 結構，運行時節點可以參數和判斷條件動態選擇調度下游

 

2. 數據保存在各個節點的輸入輸出中，減少存儲在公共變量中導致的競態訪問

 

3. 通過任務隊列保存可以并發執行的任務，同一任務隊列中的任務并發執行

 

4. 任務之間相互獨立，任務與調度器解耦

 

代碼UML類圖如下：

 

1. 調度節點設計

每個節點會轉換成一個執行任務，結構定義如下：

 

 

 

2. 數據封裝設計

3. 調度器設計

 

4. 調度執行邏輯

 

在初始時，根據元信息構建 DAG，并進行有效性驗證，然后初始化每個節點的 inDegree 和 skipInDegree 為上游節點依賴數，最后按照調度執行邏輯進行調度，在全部任務執行完成之后，返回最終數據或者執行中發生的錯誤。

 

 

 

03 電商場景最佳實踐

 

/ 場景一：直播大屏分鐘數據的冷熱分離

 

1. 業務背景

 

 

直播大屏是面向電商主播、商家，提供直播間核心實時數據，在直播過程中依據實時數據做相關決策，比如在流量下降時投流、發福袋等，是典型實時盯盤場景。

 

數據團隊提供的實時數據需具備查詢QPS高、數據延遲秒級、數據更新秒級、數據準確性高和穩定性高的特點，尤其是當大屏上核心指標出現的短暫GMV停更、分鐘數據跌0的情況，如5～8分鐘，會有大面積用戶客訴。

 

為了滿足實時數據的上述特點，我們的存儲選型主要是Abase，數據格式是hash結構，此結構在分鐘數據or 大in的場景下，查詢放大非常的明顯，極端情況下可能會打爆底層存儲，出現大量查詢失敗，從而導致線上故障的發生。

 

2. 當前痛點

 

● Abase Hgetall性能低下，頻繁出現查詢失敗的問題：

 

當前我們的分鐘數據主要是Abase hash列存表，在數據服務平臺的查詢過程中，底層是使用了hgetall指令，該指令的性能比較差，會走到rocksdb的scan操作，由于scan queue限制可能導致部分hgetall命令查詢失敗，平臺查詢會報查詢你失敗。

 

因scan queue的size是abase側配置的，為了對磁盤進行保護，不可能無限制的調大scan queue。

 

為了解決此問題，我們對所在的核心Abase集群HashScan進行摸查，查詢流量TOP2表分別是直播間分鐘、直播間商品分鐘，流量達到了85%以上。

 

因此我們只需要完成這兩份數據的遷移，很大程度上可以緩解查詢失敗頻繁的問題，達到提升Abase集群整體的穩定性、降低OS服務的查詢失敗率

 

● 數據下游服務多，服務端實現編排邏輯，切換成本高：

 

下游服務20+，不同業務方都需實現一堆ifelse編排邏輯，代碼可讀性較低，彼此間不能復用，按照以往切換經驗來說，一般需花費一個Q下游才能切換完成

 

● 底層存儲持續迭代時，服務端均需迭代，迭代成本高：

 

當后續切換到新存儲時，下游服務端需要再走一次之前的切換流程，如新建API->服務端編排邏輯調整->新服務測試->新服務發布等等，迭代成本比較高

 

 

3.解決方案

 

● 冷熱數據分離：直播間開播是冷熱分布非常的明顯，即開播7天內直播間占比達到99.9%以上，因此直播大屏上的查詢同樣具備冷熱分布的特點。

 

我們只需要在熱查詢時換存儲，如redis，承擔主要的查詢壓力，冷數據的查詢打到abase，通過這樣的查詢策略，可以很大程度上緩解Abase集群的壓力，同時保證了大屏鏈路的穩定性

 

● 使用API編排來實現冷熱數據編排邏輯：以直播間分鐘趨勢API編排接口為例，如下圖，整體鏈路中，最核心的是分支節點，通過是否開播7天的標識位分別查詢對應的冷熱數據，即開播7日內讀redis，開播超過7日的讀取abase

 

PS：API編排對應的時間比較函數還不支持整型，我們需要服務端對開播時間進行簡單加工，未來時間比較函數支持整型的話，可以去掉此處加工邏輯

 

 

3.效果&收益

 

● 服務加工邏輯清晰：通過API編排的能力，我們實現了可視化拖拽式服務開發，無需盤點底層的代碼邏輯，一眼識別出服務加工邏輯，對服務后續迭代、線上問題排查都非常的友好；

 

● 服務邏輯切換口徑統一：口徑使用API編排來收斂，理論上均可通過PSM授權來接入，但由于涉及到跨團隊權限問題，目前是相同項目下可授權使用，不同項目下可復制對應的API編排接口后使用

 

● 迭代成本低：后續再遇到底層存儲切換類似的場景，只需要在API節點替換新的API，走一次API編排的版本發布即可

 

● 大屏穩定性提升：下游切換完成后，Abase集群的hgetall查詢次數下降77.6%（19.34億->4.3億），下游查詢基本不會再出現失敗頻繁的情況

 

 

/ 場景二：電商天指標的實時離線數據切換

 

1. 業務背景

 

 

某大屏產品上需透出電商一些天指標，一般的查詢流程為 當離線數據未就緒時用實時數據兜底，離線數據就緒后直接查詢對應的離線數據表，返回離線數據，并在產品上進行相關數據披露

 

2. 當前痛點

 

● 服務端維護實時離線切換的代碼邏輯，分散在各處，迭代成本高：

 

在數據服務平臺完成對應邏輯表就緒時間回調配置，會生產對應的回調任務，下游服務端會使用OS 平臺提供的RPC接口拿到離線表的就緒時間，跟查詢參數中的日期進行大小比對后，從而實現實時離線切換的邏輯，當遇到底層存儲頻繁切換時，迭代成本高

 

● 下游大量使用原生式API，動態生成的查詢SQL支持多個場景，運維成本極高：

 

因歷史技術債務，下游使用了大量的原生API，同一個API可復用在多個場景，由于業務數據平臺目前是不支持此類API字段級別血緣，因此不能準確識別到此類API到底有幾種查詢、具體的返回結果等，當線上出現問題時，需要服務端人肉檢索出相應的查詢語句，問題排查定位時間花費大，運維成本極高

 

3. 解決方案

 

● API編排支持就緒時間：分支節點能夠拿到離線表的就緒時間，基于就緒時間進行判斷是讀離線數據，還是實時數據

 

 

以電商分載體天指標實時離線切換接口為例，我們對圖中核心的兩個節點，進行簡單闡述：

 

● 分支節點，實現實時離線切換邏輯：

 

- 讀離線數據接口：查詢日期 = 離線就緒日期 or 就緒日期> 查詢日期，即 date = LOGIC_TABLE_DATE_PARTITION(logic_table_id) or LOGIC_TABLE_DATE_PARTITION(logic_table_id) > date

 

- 讀實時數據接口：查詢日期 為 今日 or （ 日期為昨日，離線就緒日期 < 昨日）即date = curdate or LOGIC_TABLE_DATE_PARTITION(logic_table_id) < date

● 合并節點，實現實時離線接口數據合并邏輯：

 

建議是兩邊API返回參數完全一致，且采用Append模式合并，未來的話能夠支持API返回參數不一致，取他們的并集來實現合并

 

4. 效果&收益

 

● API編排收口實時離線切換邏輯，加工邏輯清晰，迭代成本低：

 

通過API編排的能力，我們實現了可視化拖拽式服務開發，無需盤點底層的代碼邏輯，一眼識別出服務加工邏輯，后續若遇到存儲切換 or 其他類似場景的話，前者切換對應的API節點，后者直接在現有的API編排接口上另存新編排接口，只需要替換相關API接口即可，開發迭代成本低

 

● 下游使用腳本式API，能夠建立清晰的產品模塊->API->OS表的消費血緣，大幅度降低API運維成本：

 

使用API編排的附加收益，我們能夠建立比較系統且全面的消費端血緣，當線上遇到問題時，能夠快速定位到OS表、查詢腳本以及影響的產品模塊，并能給出恰當的止損手段，能有效提升線上問題的排查效率。