如何實現一個跨庫連表SQL生成器？

簡介： 用戶只需在前端簡單配置下指標，系統便可自動生成大寬表，讓用戶查詢到他所須要的實時數據，數據源支持跨庫並支持多種目標介質。這樣的數據全局實時可視化如何實現？本文從需求分析開始，分享自動生成SQL功能開發中運用到的設計模式和數據結構算法設計。

一 概述

ADC（Alibaba DChain Data Converger）項目的主要目的是作一套工具，用戶在前端簡單配置下指標後，就能在系統自動生成的大寬表裏面查詢到他所須要的實時數據，數據源支持跨庫並支持多種目標介質。說的更高層次一點， 數據的全局實時可視化這個事情自己就是解決供應鏈數據「神龍效應」的有效措施（參考施雲老師的《供應鏈架構師》[1]一書）。作ADC也是爲了這個目標，整個ADC系統架構以下圖所示：

架構解析：

• 初始數據來自於元數據中心。
• 通過元數據適配層後轉換爲內部格式數據。
• 調度中心把內部格式的數據傳到計劃中心，計劃中心分析數據需求並建模，經過SQL生成器生成資源和SQL，分別經過告警中心、對帳中心設定監控標準和對帳標準。
• • 對帳中心定時對帳，查看數據的對齊狀況。
• • 告警中心能夠針對任務錯誤、延遲高等狀況發送報警。
• 資源的生命週期管控在資源管理中心下，view刪除時資源管理中心負責回收資源。
• 基礎資源適配層主要藉助集團基礎資源管理能力串聯阿里各種數據服務， 好比阿里雲MaxComputer、Flink、阿里雲AnalyticDB等。

其中，SQL生成器的上游和下游主要涉及：

• 上游計劃中心
• • 配置指標：用戶在前端配置他想看的數據有哪些。
• • 生產原始數據：根據用戶輸入獲得哪些表做爲數據源， 以及它們之間的鏈接關係。
• 下游基礎資源適配層適配器
• 把SQL發佈到Flink， 根據建表數據建物理表。

本文主要從技術角度介紹下SQL生成器相關的內容。

二 技術實現

在項目實施階段，須要從需求分析、技術方案設計、測試聯調幾個步驟展開工做。本文重點不放在軟件開發流程上， 而是就設計模式選擇和數據結構算法設計作下重點講解。

需求分析

在需求分析階段， 咱們明確了自動生成SQL模塊所須要考慮的需求點， 主要包含以下幾點：

• 須要支持多個事實表（流表）、多個維度表連表，其中一個事實表是主表，其餘的均爲輔助表。
• 維表變更也應當引發最終數據庫更新。
• 主表對輔助表爲1:1或N1，也就是說主表的粒度是最細的， 輔表經過惟一鍵來和主錶鏈接。
• 流表中可能存在惟一鍵一致的多張流表， 須要經過全鏈接關聯。惟一鍵不一樣的表之間經過左鏈接關聯。
• 只有連表和UDF，沒有groupby操做。
• 要求同步延時較小，支持多種源和目標介質。因爲查詢壓力在目標介質，因此查詢qps沒有要求。

系統流程圖

明確需求後， 咱們把SQL生成器整體功能分爲兩塊：

• 同步生成SQL和建表數據
• 異步發佈SQL和建表

之因此把生成SQL階段作成同步是由於同步階段內存操做爲主，若是發現數據有問題沒法生成SQL能作到快速失敗。發佈階段調用基礎資源適配層須要同步等待較長時間， 每一個發佈步驟要作到有狀態記錄， 可回滾或者重試。因此異步實現。SQL生成器同步階段的總體功能細化到小模塊，以下圖所示：

檢查階段

檢查原始數據是否有問題， 沒法生成SQL則快速失敗。

• 參數檢查：檢查上游是否提供了基本的參數， 好比事實表信息（能夠沒有維表， 可是必須有事實表）。
• 表類型檢查：檢查數據來源類型是否支持。
• 分區字段檢查：是否提供了大寬表分區字段。
• 鏈接約束：檢查流表，維錶鏈接信息是否正確。
• 主表惟一性約束：檢查主表是否含鏈接信息，惟一鍵是否有ETL信息。
• 元數據檢查：檢查是否包含HBase配置信息。
• 主鍵修正：修正維錶鏈接鍵， 必須是維表的惟一鍵。

數據同步

• 同步全部原始表和原始表的鏈接數據（好比源表同步進來， 生成1:1的HBase表）。
• 生成優先級隊列：生成鏈接和發佈等任務的執行優先級。
• 同步填充：填充源表對應的同步階段HBase表數據，和對應的配置項， 類型轉換（好比源表是MySQL表，字段類型要轉換爲HBase的類型）， ETL填充， 添加消息隊列（經過發送消息的方式通知下游節點運行）。
• 重複列修剪：刪除重複的列。
• 空白列打標：對於知足必定條件（好比不須要在大寬表展現， 不是惟一鍵列， 鏈接鍵列， 保序列）的列打上空白列標識。
• 保序字段填充：若是上游提供了表示數據建立時間的字段， 則用該字段做爲數據保序字段， 沒有則填充系統接收到數據的時間做爲保序字段。

計算階段

生成大寬表，填充SQL。

• 中間表填充：填充全鏈接產生的中間表。
• 鏈接關係升級：會在本文後面說明。
• 反向索引填充：填充「反向索引」信息。
• 消息填充：中間表添加消息隊列（中間表更新能夠觸發下游節點）。
• 大寬表填充：填充大寬表數據。
• 鏈接鏈對齊：中間表和大寬錶鏈接鍵對齊。
• ETL填充：填充大寬表列的ETL信息。
• 分區字段填充：填充大寬表分區字段。
• SQL填充：填充Flink同步表映射SQL語句， Flink計算SQL語句， Flink結果表映射SQL語句。
• 保存：把SQL和建表數據存入數據庫， 以後的請求能夠複用已有的數據， 避免重複建表。

異步發佈階段會把SQL語句發佈到Flink。

添加反向索引的緣由

假若有A、B兩錶鏈接，那麼鏈接方式爲A表的非主鍵鏈接B表主鍵。從時序上來講可能有如下三種狀況：

• B表數據先於A表數據多天產生
• B表數據後於A表數據多天產生
• B表數據和A表數據同時產生

下面咱們就這三種狀況逐一分析。

場景1：B表數據先於A表數據多天產生

咱們假如B表數據存儲於某個支持高qps的數據庫內，咱們能夠直接讓A表數據到來時直接鏈接此表（維表）來實現連表。

場景2：B表數據後於A表數據多天產生

這種場景比較麻煩。A表數據先行產生，所以過早的落庫，致使B表數據到來時即便鏈接B維表也拿不到數據。這種場景還有一個相似的場景：若是AB鏈接完成後B發生了更新，如何讓B的更新體如今寬表中？

爲了解決這種問題，咱們增長了一個「反向索引表」。假如A的主鍵是id，鏈接鍵是ext_id,那麼咱們能夠將ext_id和id的值存儲在一張表內，當B的數據更新時，用B的主鍵鏈接這種表的ext_id字段，拉取到全部的A表id字段，並將A表id字段從新流入Flink。

三 設計模式

對系統總體流程有了解之後， 咱們再來看看系統的設計模式選擇，選擇設計模式時，咱們考慮到數據處理相關的開發工做存在一些共性：

• 拆解後小功能多
• 小功能存在複用狀況
• 小功能執行有嚴格的前後順序
• 須要記錄小功能運行狀態， 流程執行可回滾或者中斷可恢復執行

因爲數據處理任務的步奏比較冗長，並且因爲每一個階段的結果與下階段的執行有關係，又不能分開。

參考 PipeLine（流水線）設計模式[2]，綜合考慮後咱們系統的總體設計以下圖所示：

首先有一個全局的PipeLineContainer管理多個pipeLine和pipeline context， 每一個pipeline可獨立執行一個任務， 好比pipeline1執行同步生成sql任務。pipeline2執行異步發佈任務。發佈必須在生成SQL結束後執行， pipeline有狀態而且按必定順序串聯。每一個pipeline包含多個可重用的valve（功能）。valve能夠重用， 任意組合，方便完成更多的數據處理任務（好比之後若是要支持Tisplus dump平臺接入， 則簡單拼接現有的valve就能夠）。

四 數據結構和算法

問題說明

SQL生成器關鍵點， 就是把各個表（Meta節點）之間的關係表示出來。Meta之間的關係分爲兩類，分別是全鏈接關聯和左鏈接關聯（由於左鏈接關聯涉及到數據的時序問題， 須要添加反向索引較爲複雜， 因此和全鏈接區分了一下， 爲了簡化問題咱們先執行全鏈接， 再執行左鏈接）。

咱們要解決的問題是， 多個數據源同步數據進來以後， 按必定的優先級關聯， 最終獲得一個大寬表並須要自動發佈。抽象到數據結構層面就是：

• 每一個同步進來的數據源對應一個葉子節點
• 節點之間有關聯關係，關聯關係有多類並有執行優先級
• 全部節點和關聯關係組成一棵樹
• 最終獲得一個根節點（大寬表）併發布

算法思路

下面說明下解決該問題的算法思路。

優先級隊列

由於葉子節點之間鏈接執行優先級不一樣，先放入優先級隊列。以後每次取出高優先級任務執行。相同優先級任務能夠複用， 連續執行屢次。優先級隊列示意圖以下：

構建樹

有了優先級隊列的概念， 咱們來構建樹。構建主要分如下步驟：

1.首先獲得四種優先級的任務， 優先級從高到低分別爲：

• 優先級1， 六個節點的同步任務
• 優先級2，節點一、二、3和節點四、5的Full Join任務
• 優先級3，節點一、4和節點6的Left Join任務
• 優先級4， 發佈任務

2.取優先級1的任務執行，同步進來六個數據源對應六個葉子。

3.取優先級2的任務並執行獲得中間表1，2。

4.取優先級3的任務並執行，發現節點一、4有父節點， 則執行中間節點一、2分別和節點6 Left Join獲得根節點。

5.取優先級4的任務並執行，發佈根節點。

能夠看到最終的數據結構是一棵樹， 經過這種方式咱們能支持複雜sql的自動構建。進一步抽象， 這種「一個隊列驅動一棵樹生成」的模式能夠解決一類問題：

• 問題的解決由一系列不一樣優先級的任務組成， 任務須要複用。
• 經過從隊列取優先級高的任務的方式構建任務關係樹。
• 最後遍歷樹完成各個節點任務。

五 總結

限於篇幅， 本文重點在於介紹自動生成sql功能開發中運用到的主要數據結構和設計模式思想。

目前咱們實現了任意張表關聯sql自動生成併發布， 總體延遲控制在2s之內。以後SQL生成器主要會針對方便接入更多第三方實時計算平臺（好比Tisplus）， 下降總體系統延遲工做展開。方便接入主要考驗的是架構的設計， 也是本文着重寫的點（包括數據結構和算法設計、設計模式的選擇）。下降系統延遲則包括消息中間件優化，代碼執行效率提高等。

最後

阿里巴巴供應鏈國際化團隊歡迎廣大有識之士加入，共同打造東半球零售業首選的國際化供應鏈平臺。有意請聯繫：pengcheng.wang@alibaba-inc.com

相關連接

[1]https://book.douban.com/subject/26995807/
[2]https://blog.csdn.net/buyoufa/article/details/51912262