高德深度資訊接入的平臺化演進

導讀
本文介紹了高德地圖中POI深度資訊接入在平臺化過程中的一些思考和實踐，從最開始的單體應用，隨著業務發展面臨挑戰，從業務角度提出解決問題的思路和方案，進而轉化成技術設計並落地實現的過程。

背景
POI是Point of Interest的縮寫，即我們通常理解的地點資訊。對普通使用者而言， POI資料除包含名稱、座標等基本資訊外，還會展示圖片、評論、營業資訊等內容，這些我們統稱為深度資訊。作為真實世界線上上的直接體現，其豐富度、準確度、新鮮度對使用者的出行決策起到了至關重要的作用，也是高德地圖從生活服務等多方面服務大眾的基礎。

為了豐富深度資訊，我們透過多種途徑對接採集資料。每個資料接入源稱之為一個CP(Content Provider)。最初只有少量CP的時候，每個CP建立一個應用，完全獨立的儲存、獨立的程式碼，甚至採用的是完全不同的技術棧。

然而，隨著接入規模不斷上漲，這種單體應對模式逐漸無力支撐，無法批次生產、更新、運維、監控等問題成為了業務迭代路上的絆腳石，大家花在基礎維護等事務上的精力佔比甚至超過了業務迭代。

用一組資料說明下深度業務的發展速度：一個季度工作日130天左右，新接入的任務數量卻多達到120個以上。截止目前接入的任務總數是研發人數的100倍以上，單日處理資料量達十億規模。基於對這個趨勢的預判，深度團隊提前開始了平臺化的探索。

平臺化實踐
平臺化的思路是明確的，但是平臺化的具體設計實施卻有諸多不同的選擇。

大多數資料接入系統的設計目標都相對比較純粹：作為接入系統，只要把資料拿到並輸入到本業務體系內就可以，剩餘的如資料解析，業務處理都由下游的其他系統再次加工才可形成真正的業務資料，即接入系統從設計之初就是無狀態的，對資料本身的理解也基本與業務無關。

但是考慮高德深度資訊接入業務的特殊性，我們平臺化時並沒有採用這個方案，而是採用一種更集約化的思路，接入平臺本身對資料就需要有充分的理解，不僅負責資料接入，還要負責資料解析、維度對齊、規格對映及生命週期維護等相關內容，平臺直接內建了深度資訊處理流程的全部管控邏輯。

另外，不同於一般的接入系統，除研發(RD)外，產品(PM)也是系統的第一使用者，平臺需要有能力讓PM在瞭解有限技術約束的條件下自主完成全流程資料接入、分析和除錯，這就對平臺所見即所得的實時設計除錯能力提出了極高的要求。從平臺設計角度要解決以下一些難點：

• 資料規模不均勻：不同CP的資料量和資料體積相差巨大，有的源資料量有幾億條，最少的CP甚至只有一條資料。具體到每條資料大小也差距懸殊，如部分資料單條達到7.5M，有的則只有一個欄位，僅幾個位元組。
• 業務場景不收斂：深度資料來源多且雜：有三方合作介面、離線檔案、經濟體內OSS、ODPS、MetaQ等，且CP資料結構和關聯匹配規則多種多樣、無法預知，需要平臺在設計上能支援各種場景下的維度對齊。
• 對映清洗邏輯複雜：這裡還有一個和常規業務不同的點，高德深度資料採用Schema比較鬆散的JSON方式組織，有多層巢狀物件及陣列欄位，且不同行業的規格並不一樣，平臺最終需要把資料組織成近百套不同規格的資料，這種鬆散的、非扁平二維表的資料處理也是挑戰之一，尤其是存在陣列上下文的場景裡。

最終我們設計出如圖所示的平臺架構，平臺整合了基礎、轉換、推送和任務排程四個模組，配合完成深度資訊接入的全部工作。

平臺分為幾個模組：

基礎模組：負責CP、行業、規格、許可權等基礎資訊的線上化，實現統一管理。

轉換模組：負責資料獲取、維度對齊、規格對映等處理。

推送模組：負責轉換後規格資料推送至下游准入服務。

任務模組：負責對任務的管理，如任務型別、積壓策略和資料差分等。

• 轉換引擎設計

轉換模組由轉換引擎、轉換管理器、設計器和偵錯程式四部分組成。

為了降低系統的設計複雜度，所有業務規則的自定義部分均由轉換模組支援。轉換模組作為業務自由度最高的模組，使用相同的底層支援了上層業務的預轉換、轉換和資料分析三種場景，是系統能支援各種複雜業務場景的核心部分，轉換引擎要支援資料獲取、維度對齊、規格對映清洗等配置化及除錯功能最複雜多變的部分。

資料獲取
資料獲取能力不僅要支援常見的HTTP、OSS、ODPS、MTOP、MetaQ及Push服務等多種方式，而且還要支援組合疊加。比如先從OSS下載一個檔案，解析檔案行，根據解析的資料，再呼叫HTTP服務等場景。

為了支援近乎無限的業務疊加能力和所見即所得的設計效果，我們調研了阿里經濟體內外的多種解決方案，如Blink、Stream平臺等，沒有發現可以直接滿足我們業務需求的元件，主要問題為：

• 基於技術維度組織，需要大量寫程式碼或理解技術語義，無法提供業務視角，對資料PM的理解和使用有極大的障礙。
• 步驟資料檢視是扁平二維表，無法實現鬆散結構傳遞和處理。如果在步驟間自定義業務約束及協議則過於複雜。
• 無法支援實時無副作用除錯，執行流程和除錯流程資料會互相汙染。

基於以上分析，我們決定不在上述平臺上進行二次開發，而且直接基於當前業務場景定製一套引擎，雖然這些引擎無法直接使用，但是PDI的步驟組織及驅動方式和我們的業務場景比較匹配，從自由度、表達力和直觀性幾個角度考慮，轉換引擎捨棄了DAG這種依賴計算和並行排程都相對容易的技術模型，使用和PDI類似的有向圖模型進行組織。

為了最大限度的支援PM直接對業務場景進行描述，我們最終採納了PDI的轉換引擎設計思路，直接以原始有向圖方式對步驟進行驅動執行，最大限度保持設計直覺和執行時的邏輯一致，從而不需要實現引擎層面的翻譯器、最佳化器、執行器等複雜元件。

為了保證引擎的執行效率和安全性，我們保證步驟間資料傳遞不會跨程式，所有資料互動全部在記憶體內完成，且步驟之間均為非同步並行執行，透過背壓感知機制從後向前傳導，平衡各步驟間的處理速度差異。

維度對齊
維度對齊是指把不同資料來源、不同維度的資料透過給定的業務規則關聯整合成某一種維度的資料，比如深度資訊業務一般需要整合成POI維度的資料。理論上有了引擎提供，能直觀表達並堆疊業務的能力可以實現維度對齊的需求。但是，深度資訊還有一個問題要解，即面對資料PM使用實時除錯的需求，所以無論複雜還是簡單的轉換都需要能隨時除錯，並直觀地展示結果，方便資料PM快速分析和排查。

常規ETL裡都會涉及維度對齊的問題，但是由於常規業務一般都是二維資料表間的關聯整合，所以像PDI之類的方案基本都是透過SQL+臨時表的方案進行處理，在設計時即繫結了輸入輸出，除錯和執行並無本質的區別，或者除錯時需要修改配置，強制輸出到一個臨時儲存，這意味轉換引擎需要依賴特定的外部環境（如特定的資料庫表），造成除錯和執行時的資料會互相汙染。

我們的資料天然不是二維結構，無法平鋪到表中，自然也就無法使用這種方案。我們採用的是隻依賴本機記憶體+磁碟的方式進行資料處理，如flatten這種資料打散的需求直接用記憶體實現，不需要藉助儲存；像merge join等可能全量資料交叉運算的直接採用本地磁碟做輔助，實現了全部功能都不需要外部特殊環境支援，秉承這個思路，我們最終實現了具備如下能力的轉換引擎：

純引擎

• 不寫資料，不生成執行記錄。
• 不依賴任務及特殊執行環境。
• 可以隨時初始化並執行。

資料透出

• 轉換配置不需要指定輸出，資料輸出步驟動態掛接。
• 多種場景管理器：任務場景會寫到DB，除錯場景透過WebSocket回傳到前端頁面。

有了這樣的引擎，綜合考慮除錯場景的要求，轉換在設計時不再需要指定輸出目標，輸出目標會在執行時由場景管理器根據除錯場景和正常執行場景動態掛接，避免資料互相汙染。平臺在Web端支援幾乎所有層次的所見即所得的除錯分析功能，覆蓋了預轉換、轉換、清洗、推送等幾乎所有環節。

規格對映清洗

為了支援鬆散Schema對映和透明擴充套件，轉換的行模型(RowSchema)創新性的設計為雙容器結構。

• 主資料：承載上游步驟的直接結果資料。
• 資料托盤：承載轉換引數、步驟變數、對映結果等內容。

對映步驟透過對映型別、對映規則和清洗引數支援對映清洗一體化。

• 正向對映：自上而下進行資料提取，以擴充套件JSONPath表示式（擴充套件了主資料、資料托盤、陣列迴圈item等上下文語義）為主，多種對映型別為輔。
• 反向清洗：自下而上逐層清洗，可任意疊加策略。

轉換模組透過步驟、對映、欄位清洗三個層次對資料進行處理，PM使用時只需要透過Web介面拖拽對應元件並簡單填寫一些業務引數即可完成配置。

為了避免業務黑盒問題，系統設計不同於Stream平臺的一個地方是系統元件會向後相容，步驟外掛、對映外掛、清洗外掛都沒有版本的概念。系統不支援的自定義業務在各個系統模組均可以寫指令碼(Groovy)的方式託底實現，但是不允許上傳二進位制包，程式碼必須以配置形式直接體現，避免後期的維護問題。

生命週期管理

生命週期是指系統要在適當的時機觸發資料的新增、更新、刪除操作。站在資料接入的角度，刪除是一個較為複雜的過程，業務術語稱之為下線。要說清楚下線問題得先說下深度資訊的任務模型。

目前我們支援批處理和流處理兩種模型，如大家直觀理解的，批處理任務每次執行都會遞增一個批次號，比如常見的定時任務型別。流模型指任務一旦開啟就會始終保持執行，資料一般是透過MetaQ、Push服務等方式被動接收的，沒有批次概念。

為了滿足業務需求我們支援批次過期、時間過期、條件下線三種策略，且支援多策略疊加使用。而這些策略設計時也有各自要考慮的內容，如批次過期怎樣避免掃描全批次的歷史記錄、歷史和重試場景批次號的共享遞增問題；時間過期如何避免對每條記錄繫結定時器造成的定時器數量爆炸等等。

生命週期管理涉及到比較多的任務模組設計內容，比如任務排程模型及多機分片機制設計，任務預警熔斷邏輯設計，儲存表的設計等，由於深度資訊業務的整合需求，接入平臺沒有選用開源或阿里經濟體現有的任務排程框架，而是自己定製開發了一個，篇幅有限這裡不再展開論述。

小結展望
深度資訊接入平臺見證了高德深度接入飛速發展的幾年，以極低的人力投入支撐了高德在各垂類領域的深耕拓源，為高德向生活服務類高頻應用擴充提供了底層資料支援。未來我們還將在全鏈路Debug、運營精細化場景支援、非標資料處理、自由業務編排平臺等方面繼續深化和演進。