> 只想寫單表和檔案的搬運，資料不過百最好；

# 一、業務背景

最近遇到這樣一個場景：在業務正式開始前1-2天，需要匯入一批來自合作渠道的資料，在業務週期結束後，再將同一批資料匯出，交付給渠道方；

簡單理解，就是資料的「匯入」和「匯出」；

但是場景複雜度的高低與否，與實現流程和邏輯的複雜度並無什麼必然聯絡，資料在「匯入」和「匯出」之間，通常還會橫著複雜的「業務邏輯」；

![](http://img.blog.itpub.net/blog/2023/03/26/564e19e3a2be5628.png?x-oss-process=style/bb)

資料如果只是在檔案和單表直接來回搗騰，解決的方案簡直花裡胡哨，然而在應用中資料匯入匯出，更多還是要整合業務需求，自然也就繞不開業務的處理邏輯；

# 二、場景分析

**1、檔案特徵**

檔案：「Excel」型別，並且表頭是固定格式，欄位內容雖然有要求，但是難免存在細微的誤差問題；

內容：條數「1000」以內，單條資料「150+」個欄位，業務結束後匯出，會新增業務結果和明細相關欄位，最終在「200」個欄位左右；

**2、業務特徵**

檔案匯入後，資料在業務之間流轉時，需要構建相應的主體結構，比如基礎的「客戶檔案」，「業務檔案」，業務處理過程中會生成「明細」，處理完成後會生成「結果」；

**3、資料規則**

【**客戶檔案**】

資料在入庫的過程中，需要校驗「客戶歸屬」問題，庫內已有的客戶基於「跟進時間」執行「更新邏輯」，庫內沒有的客戶需要「新增」並「分配跟進人員」；

【**業務檔案**】

跟隨「客戶檔案」的邏輯，如果客戶更新，則「業務檔案」更新，如果客戶不更新，則「業務檔案」不更新，如果客戶新增，則「業務檔案」直接新增即可；

【**資料校驗**】

客戶的「基礎檔案」和「業務檔案」的入庫邏輯，完全遵守產品體系現有的限制規則，在邏輯攔截時儘量輸出全面的攔截原因，方便商務人員對檔案資料進行修改調整；

# 三、流程設計

## 1、業務流程

![](http://img.blog.itpub.net/blog/2023/03/26/564d36d19d81726d.png?x-oss-process=style/bb)

業務流程從整體上可以拆分四段來看：動作確認、動作監聽、資料處理、業務處理；

【**動作確認**】

- 「匯入」應用前端完成檔案上傳OSS的處理，嚮應用後端提交資料匯入的請求，接收請求後會非同步處理；
- 「異常記錄下載」會實時響應，功能上看就是一個單表匯出，需要返回業務攔截和異常資訊；
- 「匯出」因為交付時間不確定性，所以由商務人員手動觸發匯出，後端組裝完成後提交OSS檔案伺服器，等待下載；

【**動作監聽**】

- 「匯入」和「匯出」的動作監聽，進而觸發相應的流程邏輯；

【**資料處理**】

- 「客戶檔案」提交給客戶服務處理，如果處理失敗，無法圍繞客戶構建業務流，直接中斷全部流程；
- 「業務檔案」提交給業務服務處理，這裡指業務屬性的資料資訊，並非場景流程；

【**業務處理**】

- 「資料匯入」的真正目的，依賴系統的處理能力，從而實現相應的業務流程，在過程中會生成關鍵明細和結果資料；

## 2、匯入流程

![](http://img.blog.itpub.net/blog/2023/03/26/7be55aa3941cd130.png?x-oss-process=style/bb)

- 【1】應用後端接收使用者提交的「匯入」請求，動作接收成功後立即響應；
- 【2】完成「匯入」記錄的儲存之後，透過MQ訊息佇列，解耦檔案資料的處理流程；
- 【3】對檔案進行解析，讀取源資料並儲存到明細表；
- 【4】遍歷明細資料分別實現「客戶」和「業務」的檔案儲存，此處會把失敗原因最大限度回寫到明細記錄中，方便商務二次匯入；
- 【5】完成資料入庫後，更新「匯入」動作的狀態，最核心的是提供失敗記錄的明細和下載功能；

## 3、匯出流程

![](http://img.blog.itpub.net/blog/2023/03/26/1e5ddc85df631e7b.png?x-oss-process=style/bb)

- 【1】應用後端接收使用者提交的「匯出」請求，動作接收成功後立即響應，初始狀態為：「處理中」；
- 【2】完成「匯出」記錄的儲存之後，透過MQ訊息佇列，解耦檔案的「建立」和「上傳」流程；
- 【3】檔案資料分為兩部分，檔案原內容和業務處理結果，組裝為新的資料結構；
- 【4】建立新的檔案，涉及資料表頭的合併，資料內容的合併，以及「Excel」的格式構建，從而完成檔案的生成過程；
- 【5】將生成的檔案上傳到檔案伺服器，由商務人員自行下載並匯出，然後交付給渠道方；

# 四、結構設計

資料匯入的表結構，是由具體業務場景決定的，此處就不做展示了；這裡只看一看匯入匯出的排程表結構，即操作記錄和狀態以及資料明細的儲存；

![](http://img.blog.itpub.net/blog/2023/03/26/66f2b81190de1913.png?x-oss-process=style/bb)

【**動作記錄**】

儲存「匯入」和「匯出」的請求記錄，都涉及檔案資訊的管理，至於「業務ID」和「批次ID」是指整合業務的處理流程，同時也可以基於該「ID」限制同批次下的重複動作，降低不必要的資源佔用；

【**資料明細**】

在「匯入」的時候，對檔案資料的臨時記錄表，方便對資料的多次讀取和處理，避免流程中斷導致檔案的重複解析；

在「匯出」的時候，需要依賴原資料的構建新的「Excel」檔案，在交付渠道方時保證原內容的不變，只新增系統中業務的處理明細和結果；

# 五、實踐總結

雖然對於「Excel」或者其他檔案的「匯入」和「匯出」的參考案例很多；

但是在研發實踐中，這依舊是一個不容易實現的過程，在資料和檔案互相搬運的過程中，如何與「業務場景」進行平穩的整合，才是真正的複雜邏輯；

從開始工作直到現在，關於「匯入」和「匯出」的實現方案參考或者落地過很多個，整體可以從兩個方向考慮；

【**應用系統**】

![](http://img.blog.itpub.net/blog/2023/03/26/8cbf1c8af64e9cd5.png?x-oss-process=style/bb)

通常檔案格式是「Excel」、「Word」、「Pdf」等，並且涉及的資料體量並不大，採取「非同步」的方式解耦即可；

對於檔案的「匯入」來說，需要重點考慮的邏輯，在於如何與業務平穩整合，在出現問題時，能夠給產品頁面準確的資訊反饋，從而提高檔案的二次處理效率；

對於資料的「匯出」來說，是一個「高危」的操作，通常是不分配大量資料的匯出「許可權」，如果有需求則要對資料進行計算分「批次」匯出；

【**資料系統**】

資料體量較大的情況下，不推薦從應用系統考慮「最佳化」的策略；

如何確定「資料體量較大」的臨界值，需要測試系統的處理能力，系統業務流量高峰時，去「併發」執行匯入和匯出，從而得出合理的數值，不過大部分產品都是限制單檔案最大「5000」條；

從分散式架構中組裝大量的資料並「匯出」檔案，其資源佔用過高，並非主流的實踐方案；

當下比較常見的方式，直接從「資料層面」入手，搭建「傳輸」或「轉換」的通道，以「API」或者「頁面入口」的方式，觸發流程即可；

![](http://img.blog.itpub.net/blog/2023/03/26/205e963c461d1655.png?x-oss-process=style/bb)

在資料體量超過應用系統的處理能力時，會搭建專用的「資料傳輸通道」來處理；

這種模式在資料型業務中很常用，可以隔離大量資料的「IO流」操作，確保應用系統執行的安全穩定，也可以極大提升資料和檔案互相搬運的處理效率；

# 六、參考原始碼

```
程式設計檔案：
https://gitee.com/cicadasmile/butte-java-note

應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent
```

複雜「場景」資料匯入匯出

相關文章