本次分享主題為轉轉 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參數具體的格式和各種拼接規則，采用常規的方式能夠更直接更簡單的使用查詢服務，提升易用性。同時完善自助分析的功能，增加更多的展示形式，優化操作邏輯，讓使用數據集進行自助分析取數變的更簡單更智能，提升用戶體驗與數據分析效率。

關于作者

張業成，轉轉數據智能部高級數據開發工程師，專注于數據開發與數據應用平臺建設。