一、平臺介紹
財務自營計費主要承接京東自營數據在整個供應鏈中由C端轉B端的功能實現，在整個供應鏈中屬於靠後的階段了，系統主要功能是計費和向B端的彙總。
二、問題描述
近年來自營計費數據量大增，有百億+的數據量，一天中彙總佔據了一半的數據庫資源。
1、每天從單表千萬W+中定位幾萬數據執行彙總，即全庫全表執行group by操作，32庫*32表，每天要花12小時處理。
2、彙總期間，系統基本停滯，導致了消息、任務處理慢，積壓多，數據無法及時計費。
3、數據庫壓力大，有隨時崩潰的風險。
4、影響供應商體驗，大促期間供應商要實時查看銷售數據，出戰報，系統無法及時響應。
三、原技術介紹
系統彙總核心是依靠MySQL物理機在每庫每表通過group by進行，彙總是按費用類型分而治之，每種類型彙總維度不一樣，每次如有新的彙總維度引入，需從前到後，寫一遍新的彙總邏輯，主要是鎖定新維度的數據範圍，確定新的group by 字段，之前邏輯還得迴歸測試，很蠢是吧，我也覺得。
四、解決問題的思路和辦法
根據以上的背景和問題，確定大致的解決問題思路
1、首先要脫離MySQL彙總，數據庫是很脆弱的，要保護數據庫，不然量級一直遞增，總有天塌的一天。
2、順帶解決新需求重複開發的弊端。
五、實踐過程描述
由於量大，業務上允許T+1處理，既然是離線數據處理，一般都能想到spark，spring batch，finlk等，在技術調研階段，主要考慮成熟性，社區活躍度，主要採用spark技術。按照彙總的流程劃分4個步驟。以下內容爲了通俗易懂，簡化了邏輯進行簡單描述下。
1、數據抓取
彙總前數據，就是業務數據，type泛指業務數據中劃分數據費用類型的字段，ou、dept泛指源數據的維度，可以是別的一個或者多個字段，amount就是要彙總求和的字段，此處用金額表示。
配置表，就是針對源數據衍生出來的，配置數據可以由很多個，是泛指，本系統只用到了一張。type表示費用類型用來和源數據關聯使用，關聯可以用一個或者多個字段關聯，此處用一個字段舉例，merge_key是彙總的字段，字段取值是從源數據的表結構的一個或者多個字段組成。invoice_type，代表彙總後的結果集需要填充的公共字段，此處用發票類型來泛指。可以根據填充的字段擴充，擴充的話在配置表中往後增加列即可。如下示例圖以單個字段表達這個意思。
2、規則匹配
進行第一次加工，即把源數據中的每一行和配置表中的唯一一行關聯，如下圖，特殊說明下，源數據的每一行，在配置表中有且僅有一行配置可以關聯上，即left join，無法關聯上的，即無配置，過濾掉，不進行彙總。第一步驟加工操作是在內存中操作完成。
然後進行第二步驟加工，此步驟我們需要把從配置表中取出的merger_key字段進一步解析成當前left join後的行所對應字段的具體值。解析後的結果如下圖，此步驟說明下，根據merger_key的字段，比如第一行ou，獲取本行對應列的字段值，就是81，原理是通過Java反射實現，現在已有各種開源的工具包可以直接用，如spring的表達式等工具。以此類推，也能獲取多個字段的值，多個字段可以按照一定的連接符號拼接，此圖以_拼接。填充字段也同步進行添加。
3、數據彙總
規則匹配數據加工完畢後，我們只需要對加工完畢後的merger_key字段進行彙總，彙總引擎中只需要按照固定的彙總字段（此處舉例是第二步驟加工完畢後的merger_key字段），彙總的邏輯就能夠固化下來，只需要1個通用sql即可實現所有費用類型的彙總，最終產生的彙總結果。
4、彙總結果
彙總後的數據和通過原技術實現彙總出來的數據能保持一樣的結果，同時還能填充一些公共的字段。如下圖，其中綠色的2行源數據，按ou彙總在結果表中變成1行；橙色的3行源數據按dept彙總在結果表中變成2行；黃色的源數據按ou、dept字段彙總變成3行。
最後把這個彙總結果回寫到MySQL即可。
六、實踐過程思考和效果評價
1、在測試環境驗證的過程中，測試表和線上表表數量級別不一樣，初上線時，讀取數據超慢。由於spark讀取單錶速度很快，讀取分庫分表數據效率直線下降，此處採用多線程方式去讀符合條件的未彙總數據，最後彙總一個大集合。
2、上線穩定運行一段時間後，性能對比圖，主要是通過剝離了MySQL中執行group by的操作，彙總時長下降了，數據庫性能提高了，進而處理消息和異步任務能力也提高了，牽一髮而影響全局。
3、後續有新的彙總需求上線時，通過配置即可實現新維度彙總功能，簡化了研發工作，提高了需求交付時效。弊端也是有的，目前彙總維度的字段必須要從主表裏取，因爲spark讀取業務數據只讀取了主表，未讀取擴展表。後續對hive表數據質量有信心，可以改成spark直接讀取hive表，或者讀es，ck等庫。
4、通過spark框架引入、把大庫彙總從在線改成離線，緩解了數據庫壓力，數據庫性能提升後，從而也提升了計費的實效性，同時還增加了系統的穩定性，提升了供應商體驗。
作者：王石根
來源：京東雲開發者社區 轉載請註明來源