轉轉One-Service資料服務體系建設

來源：轉轉技術

導讀

本次分享主題為轉轉 One-Service 資料服務體系建設，主要介紹轉轉在建設資料服務體系過程中的三個階段，其中將詳細介紹 One-Service 統一查詢服務建設思路。

主要內容包括以下幾大部分：

1. 轉轉資料服務發展歷程
2. One-Service 查詢服務建設
3. 未來規劃

一、轉轉資料服務發展歷程

在第一階段，隨著業務增長與人力資源的緊張，為了滿足各個業務線的資料需求，快速的使用統計資料做資料分析，本階段產生的資料結果大多以Excel或者資料統計到庫的方式提供資料，對外提供分析或者對接應用。此階段目標是快速產出資料結果，為業務決策提供資料支撐。

第二階段隨著業務的發展，分析資料的需求不斷的增多，分析的要求也更多樣化。針對不同主題下的資料，我們開發了各個主題的應用報表、多維分析報表，用來支援業務多樣化的分析的訴求。雖然在一定程度上解決了業務使用資料的痛點，但是在資料查詢服務上各做各的，不同的主題對應不同的查詢服務後端，形成了來一個主題開發一個主題的查詢服務的煙囪式開發模式。

第三階段是統一查詢服務One-Service，為了解決階段二暴露的問題，避免重複開發降低開發工作量，打造支援各類資料儲存的資料查詢服務，提供統一、穩定、便捷、安全、可控的資料查詢出口，我們針對不同的主題資料形成的資料集，設計和實現了一套統一的資料服務，可以完成所有主題資料服務的查詢，並提供支援不同的協議以在不同的使用場景中使用。

接下來，將詳細介紹統一查詢服務實現的具體細節。

二、One-Service 查詢服務建設

2.1 背景

在日常的資料開發過程中，我們會把資料結果儲存在各類資料庫中或者匯入到OLAP查詢引擎中供上層應用使用。對於不同的資料庫和OLAP引擎上層應用都要自行構建查詢服務處理各自的資料邏輯，存在大量重複的開發工作，因此為了提升資料使用效率、減少重複性開發工作、降低開發成本，我們在各類儲存引擎的基礎上需要開發一套統一的資料查詢服務。

2.2 系統目標

目標：打造支援各類資料儲存的資料查詢服務，提供統一、穩定、便捷、安全、可擴充套件的資料查詢出口。

需要支援常用的OLTP與OLAP資料儲存引擎，比如MySQL、Kylin、Druid、Clickhouse、StarRocks等，所有資料出口由同一套查詢服務支援，並且需要保證服務的可控、穩定、安全，對接BI需求、資料服務、資料應用工具開發等上層各類資料應用場景。

2.3 整體架構

針對之前闡述的系統背景要求與目標，我們設計了一套統一查詢服務One-Service，打通了基礎資料平臺中的元資訊，透過配置管理資料來源、資料集的方式來應對不同的多樣性資料需求。並且接入了許可權管理平臺，支援對資料集進行許可權管理與配置。在服務本身設計了一些服模組功能模組，許可權控制模組、查詢歷史記錄、監控告警模組等功能來輔助完成相應的系統要求。

1. 基礎資料平臺：根據基礎資料平臺維護的各類表與指標的元資訊，透過配置生成不同業務的資料集；
2. 管理後臺：包括資料來源管理、資料集管理、資料許可權管理。資料集管理是把不同的資料來源的資料抽象成一個資料集合，根據儲存引擎的不同採用對應的組合與配置方式，比如支援SQL的儲存引擎，可以透過SQL來生成對應不同業務的各類資料集，並且可以透過子查詢來形成不同的資料集來多樣化支援不同場景與需求，同時各類欄位格式轉換、特殊過濾條件處理都可以放到資料集中進行配置處理；
3. 許可權管理中臺：透過話許可權管理平臺，用來對用的資料集許可權進行管理，查詢平臺許可權管理粒度為資料集；
4. 查詢服務：包括查詢介面服務、後臺管理服務、儲存引擎查詢器，以及其他輔助功能。針對不同的儲存引擎會有與之對應的查詢器進行資料查詢支援。

2.4 查詢引擎設計

在查詢引擎方面，因為我們要支援不同的查詢引擎進行查詢，所以我們抽象出了一些抽象類，其中有通用統一的Map型別資料來源引數、資料集引數、通用的介面呼叫方法等，透過繼承查詢器抽象類的方式實現各類儲存引擎的查詢器，可以方便的對查詢器進行管理、擴充套件與功能開發。同時針對不同的查詢引擎可以做定製化的查詢控制與最佳化。查詢器抽象類抽象方法大致如下：

• getSchemas 獲取庫資訊
• getTables 獲取表資訊
• getDatasetDetail 查詢資料集配置
• queryDimVals 查詢維度資訊
• queryAggData 查詢資料
• viewAggDataQuery 查詢生成查詢sql或者執行計劃資訊
• getAggregateDataDownload 同步下載資料
• getDataDownloadAsync 非同步下載資料介面

統一查詢引數cfg設計與查詢資訊封裝：上層應用透過資料集元資訊，根據查詢場景生成組裝Json格式的查詢引數，包括維度、過濾、聚合、指標查詢資訊。後端收到對應資料集與查詢資訊組裝對應查詢邏輯，然後呼叫查詢介面對資料進行查詢與結果返回。引數示例如下：

{
    "rows": [
        {
            "columnName": "date",
            "filterType": "eq",
            "values": []
        },
        {
            "columnName": "channelname",
            "filterType": "eq",
            "values": []
        }
    ],
    "filters": [
        {
            "columnName": "date",
            "filterType": "=",
            "values": [
                "2023-05-10-00"
            ]
        }
    ],
    "values": [
        {
            "column": "active_count",
            "aggType": "sum"
        }
    ],
    "pageSize": 10,
    "pageNum": 1
}

常用查詢引數簡要說明：

• rows欄位為group by的維度
• filters為過濾條件，支援各類過濾條件定義表達
• values為查詢指標 aggType支援：count、sum、avg、max、min、distinct、raw原始值
• orders為排序屬性，columnName為列名，orderType為排序升序降序值為 ASC、DESC
• pageSize 頁面行數
• pageNum 頁碼

前端或者後端開發，透過資料開發配置的資料集資訊，可以快速的生成自己的場景查詢的cfg配置，然後把請求傳送到統一查詢服務上，服務會根據資料集配置的資料來源資訊，獲取到對應資料儲存引擎的查詢器，然後把對應的查詢配置引數透過邏輯轉換成對應引擎的查詢邏輯，完成資料查詢並組裝會返回結果。

至此我們基本完成了One-Service核心功能的設計，當有新的查詢引擎需要支援的時候，我們透過繼承對應的抽象類，完成相應的方法即可以對該查詢引擎的資料進行查詢，開發工作量相對比較小，可以快速支援新引擎，截止目前我們已經完成了大多數引擎的查詢支援。對於具體的複雜的應用場景，我們可以透過資料開發的結果表，配置生成不同的資料集來做二次邏輯加工，來支援多樣的資料需求。同時我們開發了https、微服務兩個資料查詢服務版本方便於前端、後端開發人員對接資料需求。

2.5 資料安全

資料安全管控對於保護資料資產、維護資料完整性和合規性至關重要。透過資料安全管控，企業可以降低資料洩露、濫用和損壞的風險，確保資料安全。在資料安全方面，目前控制到資料集粒度。整體上透過兩種方式來管理：

• 一個種是對接了許可權認證的系統，使用者登入之後透過配置的使用者角色與資料集對應關係來管理使用者對應的資料集許可權，在使用者進行資料查詢請求時後端服務會校驗使用者許可權，對沒有對應資料集許可權的查詢請求進行攔截；
• 另一種沒有使用者認證的情況，採用授權碼的方式來控制使用者資料集的訪問許可權，這種情況一般多用在內部的後端服務呼叫上，保證後端在使用查詢服務的情況下依然有許可權管控，不能看到許可權以外的資料集資訊。

同時在系統中，有對應請求的查詢記錄資訊和監控告警模組，對於異常查詢、鑑權異常、慢查詢等進行相應的監控，可以透過告警或者限流的方式篩選出異常查詢情況並做出相應的處理，來保證系統的穩定與資料的安全。

2.6 智慧查詢

在服務投入使用的過程中，我們發現很多請求其實請求的結果資料量級很小邏輯很輕，這種請求如果都傳送到OLAP的引擎中進行查詢，在早高峰資源佔用緊張的情況下也會受到影響，影響使用者查詢體驗。而且各種資料庫或者OLAP引擎都有著各自適用的場景，目前針對大資料並沒有一個完美引擎，因此在這套查詢體系裡為了最大化使用者體驗，提升查詢效率，設計根據資料集優先順序，以及查詢條件自動選擇最適合的查詢引擎來進行資料查詢與載入。

1. 底層寬表：比如我們在Hive當中有訂單主題的寬表，我們會按照業務分析場景，把寬表拆成最常用分析維度資料集，較常用維度資料集，全量資料集等資料集；
2. 資料子集：根據寬表與分析場景的情況，我們會配置定義出各類資料分析子集，分析場景下的全量資料集會儲存在ClickHouse當中進行最後命中查詢，不同維度的子集與儲存引擎可以多對一進行任意優先配置與組合；
3. 優先順序：根據分析場景與資料量級大小，把最常用的資料集按照引擎特性分別儲存在不同的資料庫或者OLAP引擎當中，根據查詢效能、資料量級的不同常規優先順序 MySQL（高）-> Kylin(中) -> ClickHouse(低)；
4. 引擎選擇器：當我們查詢某一個資料集的時候，會去判斷該資料集所屬資料集組，在改組下有各種維度不同儲存引擎下的資料集，再根據查詢條件按照配置好的優先順序順序，進行匹配查詢。追求最好的查詢效率。

這是一種常用的處理方式，用儲存空間換取查詢效率與使用者體驗的方案，這個方案中在不同的引擎裡會冗餘不同維度的子資料集資料，具體的都要視查詢場景與資料集特點進行拆分最佳化，充分利用每個引擎的特點與優勢，來提供更快更穩定的查詢體驗。

2.7.平臺建設

在系統核心功能完成之後，在易用性上我們基於該服務建設了管理功能與自助分析平臺。整體如上圖所示，我們可以檢視自己有許可權的資料集，並對資料集的資料進行自助分析，選擇維度過濾，確定查詢的指標與分組的維度進行自助的資料查詢與分析。同時展示了對應的查詢引數cfg引數與最終生成的查詢SQL，方面前後端開發人員快速上手使用該查詢服務，提升開發效率。

至此透過該系統基本上解決了資料查詢服務統一的問題，在統一的指標管理、資料集管理的體系下，保證了資料出口邏輯的一致性。並且該系統可以支援橫向擴充套件來適應更多的查詢請求。完成支援各類資料儲存的資料查詢服務，提供統一、穩定、便捷、安全、可擴充套件的資料查詢出口統一查詢服務One-Service系統。

三、未來規劃

1. 許可權管理細化：主要是要以更細的粒度管控資料許可權，把資料許可權控制到指標欄位級別，進一步保證資料使用的安全。並且在異常請求訪問攔截上增強識別能力，透過多種手段及時干預防止發生資料洩露等情況。

2. 多引擎支援：目前已經支援了大部分的OLAP的儲存分析引擎，後續考慮到應用場景的多樣性，準備接入Redis、ElasticSearch等儲存引擎，擴充套件服務使用場景。

3. 線上服務化：目前各個查詢之間沒有做資源隔離，對高QPS高穩定性要求的場景不能夠很好的支援，如果同時有一些大查詢在處理，那麼勢必會對其他查詢有一定的影響，所以為了滿足上面的場景需要對查詢資源進行隔離或者劃分服務等級，來區分使用場景區別對待，使統一查詢服務能夠直接對線上提供有保障的查詢服務。因為要對接線上的查詢服務，所以對系統穩定查詢穩定有了更高的要求，要對各個查詢效能進行監控與有針對性的最佳化，從而保障服務的穩定。

4. 易用性：在目前的使用過程中由於前後端都需要根據使用場景生成cfg查詢引數，雖然提供了一些圖形化工具來幫助快速生成，但是也有一定的溝通和理解成本，為了提升開發效率，打算支援預製查詢引數組合，讓前後端在使用的時候可以簡單的透過設定屬性值的方式來完成傳參，整體上更易於理解，不用關心cfg引數具體的格式和各種拼接規則，採用常規的方式能夠更直接更簡單的使用查詢服務，提升易用性。同時完善自助分析的功能，增加更多的展示形式，最佳化操作邏輯，讓使用資料集進行自助分析取數變的更簡單更智慧，提升使用者體驗與資料分析效率。

關於作者

張業成，轉轉資料智慧部高階資料開發工程師，專注於資料開發與資料應用平臺建設。