低程式碼實時數倉構建系統的設計與實踐

　　 1導讀

　　本文介紹58信安基於Flink實現低程式碼實時數倉構建系統，我們將數倉構建這一過程進行抽象，通過工程化的思想去解決，將固有領域問題交給系統，讓開發人員關注資料本身，解放人力縮短數倉構建週期。

　　 2背景

　　隨著資料驅動業務的需求日益增多，數倉的建設越發頻繁，開發人員在數倉構建這一個過程(埋點、埋點資料接收、資料補全、資料清洗、資料寫入儲存介質)，從事著大量且重複的工作，同時對於實時數倉構建，需要一定的專業技能，例如需要懂得如何利用Flink等框架做過濾、轉換、聚合等，對於後端業務團隊來說，學習成本高，很難快速上手，開發成本居高不下。為了解決這些問題，低程式碼數倉構建系統應運而生，通過工程化的思想去解決，將固有領域問題交給系統，讓開發人員關注資料本身，解放人力縮短數倉構建週期。

　　 3整體架構

　　參考數倉的分層，我們將系統分為ODS、DWD、DWS、ADS這四層，而這四層的運轉，就是靠系統的核心“執行引擎”來驅動的。資料經過這四層的逐層處理，最終為上游業務提供指標監控，資料大盤，Ad-Hoc Query 等應用支撐。

　　ODS層：記錄最原始的資料，包括使用者行為日誌，業務日誌，系統日誌等

　　DWD層：將ODS層的資料經過資料清洗、維度補全、拆分合並等操作，組織成業務明細表或主題明細寬表

　　DWS層：將DWD層的資料按照各種維度進行輕粒度的聚合統計，用來為上層應用場景提供統計上的便利

　　ADS層：將DWD或DWS層的資料，通過各種資料儲存介質進行實時儲存，用來給各種業務場景提供支撐，例如指標監控、資料大盤、Ad-Hoc查詢等

　　 4“零”開發的設計實現

　　為了解放開發人力，我們的設計理念就是“低程式碼”，通過自定義的專業領域語言(DSL)結合規則引擎驅動整體業務流程，使用者只需要配置DSL即可，避免了程式碼開發。在技術實現上的聚焦點為如何用DSL表達出整個業務流程，以及如何設計這個規則引擎來執行DSL，最終完成這個流程的處理。

　　DSL的設計：

　　這個業務核心流程的本質是利用Flink(流處理系統)進行資料TEL的過程，我們將這個流程劃分成這幾個階段，Source(輸入)->Transform(轉換)->Aggregation(聚合)->Sink(輸出) 簡稱STAS，最終把所有的資料流組織成一個有向圖： 

　　DSL本質上就是在表達這個有向圖，下面的語法舉例就是在描述某個流，資料來源是kafka，經過轉換和聚合，輸出到某個hive目錄上：

　　自定義規則引擎的設計：

　　目前業內有很多成熟的規則引擎如：drools，aviator，mvel，easyrules等，雖然他們橫向對比會有規則支援力度和效能的差異，但是他們基於通用規則的本質就決定了存在語法複雜和執行效率的問題。

　　由於我們面對的問題域相對固定，可以考慮對數倉構建這一業務領域進行抽象，進而完成貼合業務的自定義的規則引擎，這樣有形成針對性的規則語法複雜度會相應降低，同時也避免了語法執行效率低下的問題。

　　自定義規則引擎在流程處理上只需要解析多個DSL所構成的有向圖(上面介紹STAS有向圖)，而在規則處理方面就是在執行STAS的規則，其中“輸入和輸出”都是資料來源和儲存介質的問題，本身就是有限集，而“聚合”本身Flink就有SQL支援，所以我們只需要集中處理“資料轉換”的問題，資料轉換規劃可以說是無限集，但是在這個無限集中會有一個2/8原則，也就是說20%的規則可以滿足80%的需求，例如資料轉換經常面對的“屬性命名標準化”，“資料型別轉換”，“條件判斷”等，而剩餘的零散的規則可以採用定製化開發的方式。整個規則引擎的技術邏輯也就是上述描述的部分，如下圖(藍色為引擎，綠色為資料)：

最終我們將DSL資料轉化成頁面的配置化，引導使用者快速構建實時數倉，總體流程如下：

　　 5外掛化設計實現高擴充套件

　　基於DSL的技術實現代替了硬編碼，而DSL代替硬編碼的程度，就取決於其規則語法的豐富程度，當語法開始膨脹的時候，如何開發和維護語法，如何讓開發語法的人只關注語法本身，即使不瞭解系統本身也可以開發語法，我們的方案就是外掛化，一切皆外掛，如下圖(紅色框部分，每一個都是外掛)：

　　外掛的本質就是自定義的Java程式碼，同時外掛在定義上分為功能型和語法型兩種，功能型外掛描述這個資料是用什麼處理的，以$P開頭，語法型外掛描述著這個資料是怎麼處理的，以#開頭。

　　外掛的語法定義如下：

　　外掛的程式碼定義如下：

　　按照2/8原則系統會內建一部分外掛作為最基礎的能力，剩餘的部分通過下載Jar包的方式進行載入，外掛在系統中的執行過程為“下載”、“載入”、“命中”、“執行”這四步(系統內建的外掛不需要下載)，外掛的總體執行邏輯如下：

　　 6維表資料補全

　　維表補全在實時數倉構建中是一個必不可少的過程，一般分為業務關聯補全和資料字典補全，我們結合實際需求提供兩種補全方案：

　　(1)基於快取同步：

　　在程式啟動時，將mysql、hbase、wtable等外部儲存資源載入到記憶體，在transform過程中查詢對應記憶體資料做維表補全，這種方案由於受限於記憶體和資源的更新頻率，比較適合處理資料量有限並且變化頻率不高的資料，如某某基本資訊、資料字典等。我們提供了對應的補全外掛，以mysql的維表補全為例：

　　(2)基於實時查詢：

　　在transform過程中查詢對應資料庫或者服務介面，這種方案不限於記憶體且在實時性上有所保證，避免了基於快取的問題，但是在執行效率和併發性會受限，比較適合處理資料變化頻率高但是實時流本身體量不大的情況。對於實時查詢的維表補全方式，由於查詢的邏輯差異較大，這時候可以由接入方來編寫自定義外掛完成

　　 7多流合併

　　實時數倉構建過程中會經常遇到流合併問題，即將兩個流合併成一個流，Flink在流合併上提供兩種模式，一種是基於時間視窗（滑動，滾動，會話）的join ，一種是基於無時間視窗的interval join。

　　結合實際業務場景，真實的資料往往會出現跨時間視窗分佈的情況，舉個例子：將使用者的帖子瀏覽資料流和帖子點贊資料流合併，由於瀏覽和點贊有個天然的時間跨度，這種情況下，無論選擇什麼型別和多長跨度的時間視窗，都會有一部分資料會跨視窗，此時資料就無法合併，為了解決這個問題 ，我們利用官方提供的interval join做無時間視窗合併。

　　但是需要注意的是，interval join的本質就是流資料的等待，但是等待就意味著系統會佔用記憶體甚至儲存資源hold住當前資料，在面對具體需求的時候，使用者要根據當前的資料量級，可接受的延時等因素綜合來決策。

　　 8聚合運算

　　聚合運算用於DWS層的數倉構建，將DWD層經過輕粒度的聚合，可以為上游統計類應用減輕壓力，也可以作為基礎資料支撐報表、大盤等應用場景。我們提供兩種方式構建DWS層資料，對於簡單的聚合運算，我們提供基於原始Flink語法的聚合外掛進行處理，對於複雜的聚合運算，我們提供基於Flink SQL的聚合外掛進行處理。

　　 9數倉構建

　　構建系統支援hdfs，clickhouse，mysql 等多種儲存介質的寫入，用於支援應用層各種實時或者離線的統計需求，以下介紹兩種常用的儲存介質

　　sink to hdfs:

　　hdfs是數倉構建過程中的核心儲存介質，為了支撐快速檢索，我們將hdfs按照時間進行分割槽，分割槽粒度為小時級partition - {day} - {hour} ，在時間模式的選擇上我們採用flink 的 eventtime，這麼選擇一是考慮到eventtime可以真實反映資料的生成時間，更貼合業務場景，二是考慮到當實時流處理出現問題的時候，可以通過離線日誌按照eventtime進行重塑。

　　sink to clickhouse:

　　clickhouse作為OLAP資料庫 , 很好的支撐了海量資料實時深度挖掘的應用場景，我們對clickhouse的sink 操作採用集團支援的解決方案，即將資料來源推到kafka中，由集團訂閱kafka來構建clickhouse資料

　　 10階段性成果及展望

　　目前我們的低程式碼實時數倉構建系統支撐了部門內多個業務，完成日均30億+的資料處理工作，數倉構建成本從2~3人日降低到小時級，極大的縮短了數倉構建週期，支援了上游應用的快速迭代。

　　面向未來，我們期望本套系統起始於數倉構建但並不終止於數倉構建，基於實時流或是批流一體化處理的應用場景非常廣泛 ，例如實時監控預警、特徵工程、演算法模型訓練等等，這些都可以去探索。

　　參考文獻：

　　

　　作者簡介：

　　邢而康：58同城-資訊保安部-後端資深開發工程師

　　陸航：58同城-資訊保安部-後端高階開發工程師