簡介：?本文介紹了高德地圖中POI深度信息接入在平臺化過程中的一些思考和實踐，從最開始的單體應(yīng)用，隨著業(yè)務(wù)發(fā)展面臨挑戰(zhàn)，從業(yè)務(wù)角度提出解決問題的思路和方案，進而轉(zhuǎn)化成技術(shù)設(shè)計并落地實現(xiàn)的過程。

導(dǎo)讀
本文介紹了高德地圖中POI深度信息接入在平臺化過程中的一些思考和實踐，從最開始的單體應(yīng)用，隨著業(yè)務(wù)發(fā)展面臨挑戰(zhàn)，從業(yè)務(wù)角度提出解決問題的思路和方案，進而轉(zhuǎn)化成技術(shù)設(shè)計并落地實現(xiàn)的過程。

背景
POI是Point of Interest的縮寫，即我們通常理解的地點信息。對普通用戶而言，POI數(shù)據(jù)除包含名稱、坐標等基本信息外，還會展示圖片、評論、營業(yè)信息等內(nèi)容，這些我們統(tǒng)稱為深度信息。作為真實世界在線上的直接體現(xiàn)，其豐富度、準確度、新鮮度對用戶的出行決策起到了至關(guān)重要的作用，也是高德地圖從生活服務(wù)等多方面服務(wù)大眾的基礎(chǔ)。

為了豐富深度信息，我們通過多種途徑對接采集數(shù)據(jù)。每個數(shù)據(jù)接入源稱之為一個CP(Content Provider)。最初只有少量CP的時候，每個CP建立一個應(yīng)用，完全獨立的存儲、獨立的代碼，甚至采用的是完全不同的技術(shù)棧。

然而，隨著接入規(guī)模不斷上漲，這種單體應(yīng)對模式逐漸無力支撐，無法批量生產(chǎn)、更新、運維、監(jiān)控等問題成為了業(yè)務(wù)迭代路上的絆腳石，大家花在基礎(chǔ)維護等事務(wù)上的精力占比甚至超過了業(yè)務(wù)迭代。

用一組數(shù)據(jù)說明下深度業(yè)務(wù)的發(fā)展速度：一個季度工作日130天左右，新接入的任務(wù)數(shù)量卻多達到120個以上。截止目前接入的任務(wù)總數(shù)是研發(fā)人數(shù)的100倍以上，單日處理數(shù)據(jù)量達十億規(guī)模?；趯@個趨勢的預(yù)判，深度團隊提前開始了平臺化的探索。

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

大多數(shù)數(shù)據(jù)接入系統(tǒng)的設(shè)計目標都相對比較純粹：作為接入系統(tǒng)，只要把數(shù)據(jù)拿到并輸入到本業(yè)務(wù)體系內(nèi)就可以，剩余的如數(shù)據(jù)解析，業(yè)務(wù)處理都由下游的其他系統(tǒng)再次加工才可形成真正的業(yè)務(wù)數(shù)據(jù)，即接入系統(tǒng)從設(shè)計之初就是無狀態(tài)的，對數(shù)據(jù)本身的理解也基本與業(yè)務(wù)無關(guān)。

但是考慮高德深度信息接入業(yè)務(wù)的特殊性，我們平臺化時并沒有采用這個方案，而是采用一種更集約化的思路，接入平臺本身對數(shù)據(jù)就需要有充分的理解，不僅負責(zé)數(shù)據(jù)接入，還要負責(zé)數(shù)據(jù)解析、維度對齊、規(guī)格映射及生命周期維護等相關(guān)內(nèi)容，平臺直接內(nèi)置了深度信息處理流程的全部管控邏輯。

另外，不同于一般的接入系統(tǒng)，除研發(fā)(RD)外，產(chǎn)品(PM)也是系統(tǒng)的第一用戶，平臺需要有能力讓PM在了解有限技術(shù)約束的條件下自主完成全流程數(shù)據(jù)接入、分析和調(diào)試，這就對平臺所見即所得的實時設(shè)計調(diào)試能力提出了極高的要求。從平臺設(shè)計角度要解決以下一些難點：

• 數(shù)據(jù)規(guī)模不均勻：不同CP的數(shù)據(jù)量和數(shù)據(jù)體積相差巨大，有的源數(shù)據(jù)量有幾億條，最少的CP甚至只有一條數(shù)據(jù)。具體到每條數(shù)據(jù)大小也差距懸殊，如部分數(shù)據(jù)單條達到7.5M，有的則只有一個字段，僅幾個字節(jié)。
• 業(yè)務(wù)場景不收斂：深度數(shù)據(jù)來源多且雜：有三方合作接口、離線文件、經(jīng)濟體內(nèi)OSS、ODPS、MetaQ等，且CP數(shù)據(jù)結(jié)構(gòu)和關(guān)聯(lián)匹配規(guī)則多種多樣、無法預(yù)知，需要平臺在設(shè)計上能支持各種場景下的維度對齊。
• 映射清洗邏輯復(fù)雜：這里還有一個和常規(guī)業(yè)務(wù)不同的點，高德深度數(shù)據(jù)采用Schema比較松散的JSON方式組織，有多層嵌套對象及數(shù)組字段，且不同行業(yè)的規(guī)格并不一樣，平臺最終需要把數(shù)據(jù)組織成近百套不同規(guī)格的數(shù)據(jù)，這種松散的、非扁平二維表的數(shù)據(jù)處理也是挑戰(zhàn)之一，尤其是存在數(shù)組上下文的場景里。

  轉(zhuǎn)存失敗重新上傳取消

最終我們設(shè)計出如圖所示的平臺架構(gòu)，平臺集成了基礎(chǔ)、轉(zhuǎn)換、推送和任務(wù)調(diào)度四個模塊，配合完成深度信息接入的全部工作。

平臺分為幾個模塊：

基礎(chǔ)模塊：負責(zé)CP、行業(yè)、規(guī)格、權(quán)限等基礎(chǔ)信息的在線化，實現(xiàn)統(tǒng)一管理。

轉(zhuǎn)換模塊：負責(zé)數(shù)據(jù)獲取、維度對齊、規(guī)格映射等處理。

推送模塊：負責(zé)轉(zhuǎn)換后規(guī)格數(shù)據(jù)推送至下游準入服務(wù)。

任務(wù)模塊：負責(zé)對任務(wù)的管理，如任務(wù)類型、積壓策略和數(shù)據(jù)差分等。

轉(zhuǎn)換引擎設(shè)計

轉(zhuǎn)換模塊由轉(zhuǎn)換引擎、轉(zhuǎn)換管理器、設(shè)計器和調(diào)試器四部分組成。

為了降低系統(tǒng)的設(shè)計復(fù)雜度，所有業(yè)務(wù)規(guī)則的自定義部分均由轉(zhuǎn)換模塊支持。轉(zhuǎn)換模塊作為業(yè)務(wù)自由度最高的模塊，使用相同的底層支持了上層業(yè)務(wù)的預(yù)轉(zhuǎn)換、轉(zhuǎn)換和數(shù)據(jù)分析三種場景，是系統(tǒng)能支持各種復(fù)雜業(yè)務(wù)場景的核心部分，轉(zhuǎn)換引擎要支持數(shù)據(jù)獲取、維度對齊、規(guī)格映射清洗等配置化及調(diào)試功能最復(fù)雜多變的部分。

數(shù)據(jù)獲取
數(shù)據(jù)獲取能力不僅要支持常見的HTTP、OSS、ODPS、MTOP、MetaQ及Push服務(wù)等多種方式，而且還要支持組合疊加。比如先從OSS下載一個文件，解析文件行，根據(jù)解析的數(shù)據(jù)，再調(diào)用HTTP服務(wù)等場景。

為了支持近乎無限的業(yè)務(wù)疊加能力和所見即所得的設(shè)計效果，我們調(diào)研了阿里經(jīng)濟體內(nèi)外的多種解決方案，如Blink、Stream平臺等，沒有發(fā)現(xiàn)可以直接滿足我們業(yè)務(wù)需求的組件，主要問題為：

• 基于技術(shù)維度組織，需要大量寫代碼或理解技術(shù)語義，無法提供業(yè)務(wù)視角，對數(shù)據(jù)PM的理解和使用有極大的障礙。
• 步驟數(shù)據(jù)視圖是扁平二維表，無法實現(xiàn)松散結(jié)構(gòu)傳遞和處理。如果在步驟間自定義業(yè)務(wù)約束及協(xié)議則過于復(fù)雜。
• 無法支持實時無副作用調(diào)試，運行流程和調(diào)試流程數(shù)據(jù)會互相污染。

基于以上分析，我們決定不在上述平臺上進行二次開發(fā)，而且直接基于當(dāng)前業(yè)務(wù)場景定制一套引擎，雖然這些引擎無法直接使用，但是PDI的步驟組織及驅(qū)動方式和我們的業(yè)務(wù)場景比較匹配，從自由度、表達力和直觀性幾個角度考慮，轉(zhuǎn)換引擎舍棄了DAG這種依賴計算和并行調(diào)度都相對容易的技術(shù)模型，使用和PDI類似的有向圖模型進行組織。

轉(zhuǎn)存失敗重新上傳取消

為了最大限度的支持PM直接對業(yè)務(wù)場景進行描述，我們最終采納了PDI的轉(zhuǎn)換引擎設(shè)計思路，直接以原始有向圖方式對步驟進行驅(qū)動執(zhí)行，最大限度保持設(shè)計直覺和運行時的邏輯一致，從而不需要實現(xiàn)引擎層面的翻譯器、優(yōu)化器、執(zhí)行器等復(fù)雜組件。

轉(zhuǎn)存失敗重新上傳取消

為了保證引擎的執(zhí)行效率和安全性，我們保證步驟間數(shù)據(jù)傳遞不會跨進程，所有數(shù)據(jù)交互全部在內(nèi)存內(nèi)完成，且步驟之間均為異步并行執(zhí)行，通過背壓感知機制從后向前傳導(dǎo)，平衡各步驟間的處理速度差異。

維度對齊
維度對齊是指把不同數(shù)據(jù)源、不同維度的數(shù)據(jù)通過給定的業(yè)務(wù)規(guī)則關(guān)聯(lián)整合成某一種維度的數(shù)據(jù)，比如深度信息業(yè)務(wù)一般需要整合成POI維度的數(shù)據(jù)。理論上有了引擎提供，能直觀表達并堆疊業(yè)務(wù)的能力可以實現(xiàn)維度對齊的需求。但是，深度信息還有一個問題要解，即面對數(shù)據(jù)PM使用實時調(diào)試的需求，所以無論復(fù)雜還是簡單的轉(zhuǎn)換都需要能隨時調(diào)試，并直觀地展示結(jié)果，方便數(shù)據(jù)PM快速分析和排查。

常規(guī)ETL里都會涉及維度對齊的問題，但是由于常規(guī)業(yè)務(wù)一般都是二維數(shù)據(jù)表間的關(guān)聯(lián)整合，所以像PDI之類的方案基本都是通過SQL+臨時表的方案進行處理，在設(shè)計時即綁定了輸入輸出，調(diào)試和運行并無本質(zhì)的區(qū)別，或者調(diào)試時需要修改配置，強制輸出到一個臨時存儲，這意味轉(zhuǎn)換引擎需要依賴特定的外部環(huán)境（如特定的數(shù)據(jù)庫表），造成調(diào)試和運行時的數(shù)據(jù)會互相污染。

我們的數(shù)據(jù)天然不是二維結(jié)構(gòu)，無法平鋪到表中，自然也就無法使用這種方案。我們采用的是只依賴本機內(nèi)存+磁盤的方式進行數(shù)據(jù)處理，如flatten這種數(shù)據(jù)打散的需求直接用內(nèi)存實現(xiàn)，不需要借助存儲；像merge join等可能全量數(shù)據(jù)交叉運算的直接采用本地磁盤做輔助，實現(xiàn)了全部功能都不需要外部特殊環(huán)境支持，秉承這個思路，我們最終實現(xiàn)了具備如下能力的轉(zhuǎn)換引擎：

純引擎

• 不寫數(shù)據(jù)，不生成執(zhí)行記錄。
• 不依賴任務(wù)及特殊執(zhí)行環(huán)境。
• 可以隨時初始化并執(zhí)行。

數(shù)據(jù)透出
轉(zhuǎn)換配置不需要指定輸出，數(shù)據(jù)輸出步驟動態(tài)掛接。

多種場景管理器：任務(wù)場景會寫到DB，調(diào)試場景通過WebSocket回傳到前端頁面。

有了這樣的引擎，綜合考慮調(diào)試場景的要求，轉(zhuǎn)換在設(shè)計時不再需要指定輸出目標，輸出目標會在運行時由場景管理器根據(jù)調(diào)試場景和正常運行場景動態(tài)掛接，避免數(shù)據(jù)互相污染。平臺在Web端支持幾乎所有層次的所見即所得的調(diào)試分析功能，覆蓋了預(yù)轉(zhuǎn)換、轉(zhuǎn)換、清洗、推送等幾乎所有環(huán)節(jié)。

規(guī)格映射清洗
為了支持松散Schema映射和透明擴展，轉(zhuǎn)換的行模型(RowSchema)創(chuàng)新性的設(shè)計為雙容器結(jié)構(gòu)。

• 主數(shù)據(jù)：承載上游步驟的直接結(jié)果數(shù)據(jù)。
• 數(shù)據(jù)托盤：承載轉(zhuǎn)換參數(shù)、步驟變量、映射結(jié)果等內(nèi)容。

  轉(zhuǎn)存失敗重新上傳取消

映射步驟通過映射類型、映射規(guī)則和清洗參數(shù)支持映射清洗一體化。

• 正向映射：自上而下進行數(shù)據(jù)提取，以擴展JSONPath表達式（擴展了主數(shù)據(jù)、數(shù)據(jù)托盤、數(shù)組循環(huán)item等上下文語義）為主，多種映射類型為輔。
• 反向清洗：自下而上逐層清洗，可任意疊加策略。

轉(zhuǎn)換模塊通過步驟、映射、字段清洗三個層次對數(shù)據(jù)進行處理，PM使用時只需要通過Web界面拖拽對應(yīng)組件并簡單填寫一些業(yè)務(wù)參數(shù)即可完成配置。

為了避免業(yè)務(wù)黑盒問題，系統(tǒng)設(shè)計不同于Stream平臺的一個地方是系統(tǒng)組件會向后兼容，步驟插件、映射插件、清洗插件都沒有版本的概念。系統(tǒng)不支持的自定義業(yè)務(wù)在各個系統(tǒng)模塊均可以寫腳本(Groovy)的方式托底實現(xiàn)，但是不允許上傳二進制包，代碼必須以配置形式直接體現(xiàn)，避免后期的維護問題。

生命周期管理
生命周期是指系統(tǒng)要在適當(dāng)?shù)臅r機觸發(fā)數(shù)據(jù)的新增、更新、刪除操作。站在數(shù)據(jù)接入的角度，刪除是一個較為復(fù)雜的過程，業(yè)務(wù)術(shù)語稱之為下線。要說清楚下線問題得先說下深度信息的任務(wù)模型。

目前我們支持批處理和流處理兩種模型，如大家直觀理解的，批處理任務(wù)每次執(zhí)行都會遞增一個批次號，比如常見的定時任務(wù)類型。流模型指任務(wù)一旦打開就會始終保持運行，數(shù)據(jù)一般是通過MetaQ、Push服務(wù)等方式被動接收的，沒有批次概念。

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

生命周期管理涉及到比較多的任務(wù)模塊設(shè)計內(nèi)容，比如任務(wù)調(diào)度模型及多機分片機制設(shè)計，任務(wù)預(yù)警熔斷邏輯設(shè)計，存儲表的設(shè)計等，由于深度信息業(yè)務(wù)的集成需求，接入平臺沒有選用開源或阿里經(jīng)濟體現(xiàn)有的任務(wù)調(diào)度框架，而是自己定制開發(fā)了一個，篇幅有限這里不再展開論述。

小結(jié)展望
深度信息接入平臺見證了高德深度接入飛速發(fā)展的幾年，以極低的人力投入支撐了高德在各垂類領(lǐng)域的深耕拓源，為高德向生活服務(wù)類高頻應(yīng)用拓展提供了底層數(shù)據(jù)支持。未來我們還將在全鏈路Debug、運營精細化場景支持、非標數(shù)據(jù)處理、自由業(yè)務(wù)編排平臺等方面繼續(xù)深化和演進。

總結(jié)

以上是生活随笔為你收集整理的高德深度信息接入的平台化演进的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。