數據管理：業務數據清洗，落地實現方案
一、業務背景
在系統業務開發的過程中，都會面臨這樣一個問題：面對業務的快速擴展，很多版本在當時沒有時間去全局考慮，導致很多業務數據存儲和管理並不規範，例如常見的問題：
- 地址採取輸入的方式，而非三級聯動；
- 沒有統一管理數據字典獲取接口；
- 數據存儲的位置和結構設計不合理；
- 不同服務的數據庫之間存在同步通道；
而分析業務通常都是要面對全局數據，如果出現大量的上述情況，就會導致數據在使用的時候難度非常大，隨之也會帶來很多問題：數據分散不規範，導致響應性能差，穩定性低，同時提高管理成本。
當隨着業務發展，數據的沉澱越來越多，使用的難度就會陡增，會導致在數據分析之前，需要大量時間去清洗數據。
二、數據清洗概述
1、基本方案
核心思想：
- 讀-洗-寫入業務庫持續服務；
- 讀-洗-寫入檔案數據資產庫；
業務數據清洗本質上理解起來並不難，即讀取待清洗的數據源，經過清洗服務規範化處理後，再把數據放到指定的數據源，但是實際操作起來絕對叫人眼花撩到。
2、容器遷移
數據存儲的方式本身就是多種選擇，清洗數據要面對的第一個問題就是：數據容器的遷移；
- 讀數據源：文件、緩存、數據庫等；
- 臨時容器：清洗過程存儲節點數據；
- 寫數據源：清洗後數據注入的容器；
所以清洗數據的第一步就是明確整個流程下要適配多少數據源，做好服務的基礎功能設計與架構，這是支撐清洗服務的基礎；
3、結構化管理
讀取的清洗數據可能並不是基於庫表管理的結構化數據，或者在數據處理過程中在中間臨時容器存儲時，為了方便下次操作取到數據，都需要對數據做簡單的結構管理；
例如：通常讀取文件的服務性能是很差，當數據讀取之後在清洗的過程中，一旦流程中斷，可能需要對數據重新讀取，此時如果再次讀取文件是不合理的，文件中數據一旦讀取出來，應該轉換成簡單的結構存儲在臨時容器中，方便再次獲取，避免重溫處理文件的IO流；
常見數據結構管理的幾個業務場景：
- 數據容器更換，需要重組結構；
- 臟數據結構刪除或者多字段合併；
- 文件數據(Json、Xml等)轉結構；
注意：這裡的結構管理可能不是單純的庫表結構，也可能是基於庫表存儲的JSON結構或者其他，主要為了方便清洗流程的使用，以至最終數據的寫入。
4、標準化內容
標準化內容則是數據清洗服務中的一些基本準則，或者一些業務中的規範，這塊完全根據需求來確定，也涉及到清洗數據的一些基本方法；
於業務本身的需求而言，可能常見幾個清洗策略如下：
-
基於字典統一管理：例如常見的地址輸入，如果值
浦東新區XX路XX區，這樣要清洗為上海市-浦東新區-XX路XX區，省市區這種地域肯定是要基於字典方式管理的表，事實上在系統中很多字段屬性都是要基於字典去管理值的邊界和規範，這樣處理之後有利於數據的使用、搜索、分析等； -
數據分析檔案化：例如在某個業務模塊需要用戶實名認證，如果認證成功，基於手機號+身份證所讀取到的用戶信息則是變動極小，特別是基於身份證號分解出來的相關數據，這些數據則可以作為用戶檔案數據，做數據資產化管理；
-
業務數據結構重組：通常分析都會基於全局數據來處理，這就涉及到數據分分合合的管理，這樣可能需要對部分數據結構做搬運，或者不同業務場景下的數據結構做合併，這樣整體分析，更容易捕獲有價值的信息數據；
然對於數據清洗本身來說，也是有一些基本策略：
- 數據基礎結構的增、刪、合併等；
- 數據類型的轉變，或者長度處理；
- 數據分析中數值轉換、缺失數據彌補或丟棄；
- 數據值本身的規範化處理，修復等；
- 統一字符串、日期、時間戳等格式；
在數據清洗的策略中並沒有一個標準化的規範，這完全取決數據清洗後的業務需求，例如數據質量差，嚴重缺失的話可能直接丟棄，也可能基於多種策略做彌補，這完全取決於結果數據的應用場景。
三、服務架構
1、基礎設計
通常在數據清洗的服務中，會圍繞數據的讀-洗-寫基本鏈路來做架構，各個場景本身並沒有過於複雜的邏輯：
數據源讀取
數據源讀取兩面對兩個關鍵問題之一：適配，不同的存儲方式，要開發不同的讀取機制；
- 數據庫：MySQL、Oracle等；
- 文件型：XML、CSV、Excel等；
- 中間件：Redis、ES索引等；
另一個關鍵問題就是數據讀取規則：涉及讀取速度，大小，先後等；
- 如果數據文件過大可能要做切割；
- 數據間如果存在時序性，要分先後讀取；
- 根據清洗服務處理能力，測評讀取大小；
2、服務間交互
事實上服務間如何交互，如何管理數據在整個清洗鏈路上的流動規則，需要根據不同服務角色的吞吐量去考量，基本交互邏輯為兩個：直調、異步；
-
直調：如果各服務節點處理能力相同，採用直調方式即可，這種方式流程比較簡單，並且可以第一時間捕獲異常，做相應的補償處理，但實際上清洗服務要處理的規則非常多，自然要耗時很多；
-
異步：每個服務間做解耦，通過異步的方式推動各個節點服務執行，例如數據讀取之後，異步調用清洗服務，當數據清洗完成後，在異步調用數據寫入服務，同時通知數據讀服務再次讀取數據，這樣各個服務的資源有釋放的空隙，降低服務壓力，為了提高效率可以在不同服務做一些預處理，這樣的流程設計雖然更合理，但是複雜度偏高。
數據的清洗是一個細緻且耗費精力的活，要根據不同需求，對服務做持續優化和通用功能的沉澱。
3、流程化管理
對數據清洗鏈路做一個流程管理十分有必要，通常要從兩個方面考慮：節點狀態、節點數據；
清洗節點：這是重點記錄的節點，如果清洗規則過多，分批處理的話，對於每個關鍵流程處理成功後的數據和狀態做記錄尤其重要；
讀寫節點：根據數據源類型選擇性存儲，例如文件類型；
轉發節點：記錄轉髮狀態，常見成功或者失敗狀態；
對於關鍵節點結果記錄，可以在清洗鏈路失敗的時候快速執行重試機制，哪個節點出現異常，可以快速構建重新執行的數據，例如讀取文件A的數據，但是清洗過程失敗，那麼可以基於讀節點的數據記錄快速重試；
如果數據量過大，可以對處理成功的數據進行周期性刪除，或者直接在數據寫成功之後直接通知刪除，降低維護清洗鏈路本身對資源的過度佔用。
4、工具化沉澱
在數據清洗的鏈路中，可以對一些工具型代碼做持續沉澱和擴展：
- 數據源適配，常用庫和文件類型；
- 文件切割，對大文件的處理；
- 非結構化數據轉結構化表數據；
- 數據類型轉換和校驗機制；
- 併發模式設計，多線程處理；
- 清洗規則策略配置，字典數據管理；
數據清洗的業務和規則很難一概而論，但是對清洗服務的架構設計，和鏈路中工具的封裝沉澱是很有必要的，從而可以集中時間和精力處理業務本身，這樣面對不同的業務場景，可以更加的快速和高效。
5、鏈路測試
數據清洗的鏈路是比較長的，所以對鏈路的測試很有必要，基本上從兩個極端情況測試即可：
- 缺失：非必要數據之外全部缺失；
- 完整：所有數據屬性的值全存在；
這兩個場景為了驗證清洗鏈路的可用性和準確性，降低異常發生的可能性。
閱讀標籤
【Java基礎】【設計模式】【結構與算法】【Linux系統】【數據庫】
【分佈式架構】【微服務】【大數據組件】【SpringBoot進階】【Spring&Boot基礎】
