資料管理：業務資料清洗，落地實現方案

知了一笑發表於2021-06-09

一、業務背景

在系統業務開發的過程中，都會面臨這樣一個問題：面對業務的快速擴充套件，很多版本在當時沒有時間去全域性考慮，導致很多業務資料儲存和管理並不規範，例如常見的問題：

而分析業務通常都是要面對全域性資料，如果出現大量的上述情況，就會導致資料在使用的時候難度非常大，隨之也會帶來很多問題：資料分散不規範，導致響應效能差，穩定性低，同時提高管理成本。

當隨著業務發展，資料的沉澱越來越多，使用的難度就會陡增，會導致在資料分析之前，需要大量時間去清洗資料。

核心思想：

業務資料清洗本質上理解起來並不難，即讀取待清洗的資料來源，經過清洗服務規範化處理後，再把資料放到指定的資料來源，但是實際操作起來絕對叫人眼花撩到。

資料儲存的方式本身就是多種選擇，清洗資料要面對的第一個問題就是：資料容器的遷移；

所以清洗資料的第一步就是明確整個流程下要適配多少資料來源，做好服務的基礎功能設計與架構，這是支撐清洗服務的基礎；

讀取的清洗資料可能並不是基於庫表管理的結構化資料，或者在資料處理過程中在中間臨時容器儲存時，為了方便下次操作取到資料，都需要對資料做簡單的結構管理；

例如：通常讀取檔案的服務效能是很差，當資料讀取之後在清洗的過程中，一旦流程中斷，可能需要對資料重新讀取，此時如果再次讀取檔案是不合理的，檔案中資料一旦讀取出來，應該轉換成簡單的結構儲存在臨時容器中，方便再次獲取，避免重溫處理檔案的IO流；

常見資料結構管理的幾個業務場景：

注意：這裡的結構管理可能不是單純的庫表結構，也可能是基於庫表儲存的JSON結構或者其他，主要為了方便清洗流程的使用，以至最終資料的寫入。

標準化內容則是資料清洗服務中的一些基本準則，或者一些業務中的規範，這塊完全根據需求來確定，也涉及到清洗資料的一些基本方法；

於業務本身的需求而言，可能常見幾個清洗策略如下：

基於字典統一管理：例如常見的地址輸入，如果值浦東新區XX路XX區，這樣要清洗為上海市-浦東新區-XX路XX區，省市區這種地域肯定是要基於字典方式管理的表，事實上在系統中很多欄位屬性都是要基於字典去管理值的邊界和規範，這樣處理之後有利於資料的使用、搜尋、分析等；
資料分析檔案化：例如在某個業務模組需要使用者實名認證，如果認證成功，基於手機號+身份證所讀取到的使用者資訊則是變動極小，特別是基於身份證號分解出來的相關資料，這些資料則可以作為使用者檔案資料，做資料資產化管理；
業務資料結構重組：通常分析都會基於全域性資料來處理，這就涉及到資料分分合合的管理，這樣可能需要對部分資料結構做搬運，或者不同業務場景下的資料結構做合併，這樣整體分析，更容易捕獲有價值的資訊資料；

然對於資料清洗本身來說，也是有一些基本策略：

在資料清洗的策略中並沒有一個標準化的規範，這完全取決資料清洗後的業務需求，例如資料質量差，嚴重缺失的話可能直接丟棄，也可能基於多種策略做彌補，這完全取決於結果資料的應用場景。

通常在資料清洗的服務中，會圍繞資料的讀-洗-寫基本鏈路來做架構，各個場景本身並沒有過於複雜的邏輯：

資料來源讀取

資料來源讀取兩面對兩個關鍵問題之一：適配，不同的儲存方式，要開發不同的讀取機制；

另一個關鍵問題就是資料讀取規則：涉及讀取速度，大小，先後等；

事實上服務間如何互動，如何管理資料在整個清洗鏈路上的流動規則，需要根據不同服務角色的吞吐量去考量，基本互動邏輯為兩個：直調、非同步；

直調：如果各服務節點處理能力相同，採用直調方式即可，這種方式流程比較簡單，並且可以第一時間捕獲異常，做相應的補償處理，但實際上清洗服務要處理的規則非常多，自然要耗時很多；
非同步：每個服務間做解耦，通過非同步的方式推動各個節點服務執行，例如資料讀取之後，非同步呼叫清洗服務，當資料清洗完成後，在非同步呼叫資料寫入服務，同時通知資料讀服務再次讀取資料，這樣各個服務的資源有釋放的空隙，降低服務壓力，為了提高效率可以在不同服務做一些預處理，這樣的流程設計雖然更合理，但是複雜度偏高。

資料的清洗是一個細緻且耗費精力的活，要根據不同需求，對服務做持續優化和通用功能的沉澱。