# 一、業務背景

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

- 地址採取輸入的方式，而非三級聯動；
- 沒有統一管理資料字典獲取介面；
- 資料儲存的位置和結構設計不合理；
- 不同服務的資料庫之間存在同步通道；

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

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

# 二、資料清洗概述

## 1、基本方案

![](http://img.blog.itpub.net/blog/2021/06/08/30682fc4155b0fe5.jpeg?x-oss-process=style/bb)

核心思想：

- 讀-洗-寫入業務庫持續服務；
- 讀-洗-寫入檔案資料資產庫；

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

## 2、容器遷移

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

- 讀資料來源：檔案、快取、資料庫等；
- 臨時容器：清洗過程儲存節點資料；
- 寫資料來源：清洗後資料注入的容器；

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

## 3、結構化管理

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

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

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

- 資料容器更換，需要重組結構；
- 髒資料結構刪除或者多欄位合併；
- 檔案資料(Json、Xml等)轉結構；

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

## 4、標準化內容

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

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

- **基於字典統一管理**：例如常見的地址輸入，如果值`浦東新區XX路XX區`，這樣要清洗為`上海市-浦東新區-XX路XX區`，省市區這種地域肯定是要基於字典方式管理的表，事實上在系統中很多欄位屬性都是要基於字典去管理值的邊界和規範，這樣處理之後有利於資料的使用、搜尋、分析等；

- **資料分析檔案化**：例如在某個業務模組需要使用者實名認證，如果認證成功，基於手機號+身份證所讀取到的使用者資訊則是變動極小，特別是基於身份證號分解出來的相關資料，這些資料則可以作為使用者檔案資料，做資料資產化管理；

- **業務資料結構重組**：通常分析都會基於全域性資料來處理，這就涉及到資料分分合合的管理，這樣可能需要對部分資料結構做搬運，或者不同業務場景下的資料結構做合併，這樣整體分析，更容易捕獲有價值的資訊資料；

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

- 資料基礎結構的增、刪、合併等；
- 資料型別的轉變，或者長度處理；
- 資料分析中數值轉換、缺失資料彌補或丟棄；
- 資料值本身的規範化處理，修復等；
- 統一字串、日期、時間戳等格式；

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

# 三、服務架構

## 1、基礎設計

![](http://img.blog.itpub.net/blog/2021/06/08/550db91342ced1ff.jpeg?x-oss-process=style/bb)

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

**資料來源讀取**

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

- 資料庫：MySQL、Oracle等；
- 檔案型：XML、CSV、Excel等；
- 中介軟體：Redis、ES索引等；

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

- 如果資料檔案過大可能要做切割；
- 資料間如果存在時序性，要分先後讀取；
- 根據清洗服務處理能力，測評讀取大小；

## 2、服務間互動

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

![](http://img.blog.itpub.net/blog/2021/06/08/a77c0e22e6d91ab6.jpeg?x-oss-process=style/bb)

- **直調**：如果各服務節點處理能力相同，採用直調方式即可，這種方式流程比較簡單，並且可以第一時間捕獲異常，做相應的補償處理，但實際上清洗服務要處理的規則非常多，自然要耗時很多；

- **非同步**：每個服務間做解耦，透過非同步的方式推動各個節點服務執行，例如資料讀取之後，非同步呼叫清洗服務，當資料清洗完成後，在非同步呼叫資料寫入服務，同時通知資料讀服務再次讀取資料，這樣各個服務的資源有釋放的空隙，降低服務壓力，為了提高效率可以在不同服務做一些預處理，這樣的流程設計雖然更合理，但是複雜度偏高。

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

## 3、流程化管理

對資料清洗鏈路做一個流程管理十分有必要，通常要從兩個方面考慮：節點狀態、節點資料；

![](http://img.blog.itpub.net/blog/2021/06/08/1f448b38c8d18209.jpeg?x-oss-process=style/bb)

**清洗節點**：這是重點記錄的節點，如果清洗規則過多，分批處理的話，對於每個關鍵流程處理成功後的資料和狀態做記錄尤其重要；

**讀寫節點**：根據資料來源型別選擇性儲存，例如檔案型別；

**轉發節點**：記錄轉發狀態，常見成功或者失敗狀態；

對於關鍵節點結果記錄，可以在清洗鏈路失敗的時候快速執行重試機制，哪個節點出現異常，可以快速構建重新執行的資料，例如讀取檔案A的資料，但是清洗過程失敗，那麼可以基於讀節點的資料記錄快速重試；

如果資料量過大，可以對處理成功的資料進行週期性刪除，或者直接在資料寫成功之後直接通知刪除，降低維護清洗鏈路本身對資源的過度佔用。

## 4、工具化沉澱

在資料清洗的鏈路中，可以對一些工具型程式碼做持續沉澱和擴充套件：

- 資料來源適配，常用庫和檔案型別；
- 檔案切割，對大檔案的處理；
- 非結構化資料轉結構化表資料；
- 資料型別轉換和校驗機制；
- 併發模式設計，多執行緒處理；
- 清洗規則策略配置，字典資料管理；

資料清洗的業務和規則很難一概而論，但是對清洗服務的架構設計，和鏈路中工具的封裝沉澱是很有必要的，從而可以集中時間和精力處理業務本身，這樣面對不同的業務場景，可以更加的快速和高效。

## 5、鏈路測試

資料清洗的鏈路是比較長的，所以對鏈路的測試很有必要，基本上從兩個極端情況測試即可：

- 缺失：非必要資料之外全部缺失；
- 完整：所有資料屬性的值全存在；

這兩個場景為了驗證清洗鏈路的可用性和準確性，降低異常發生的可能性。

![](http://img.blog.itpub.net/blog/2021/06/08/2dbda494887ca1fe.png?x-oss-process=style/bb)

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

相關文章