一、業務背景
最近遇到這樣一個場景：在業務正式開始前1-2天，需要導入一批來自合作渠道的數據，在業務周期結束后，再將同一批數據導出，交付給渠道方；
簡單理解，就是數據的「導入」和「導出」；
但是場景復雜度的高低與否，與實現流程和邏輯的復雜度并無什么必然聯系，數據在「導入」和「導出」之間，通常還會橫著復雜的「業務邏輯」；
數據如果只是在文件和單表直接來回搗騰，解決的方案簡直花里胡哨，然而在應用中數據導入導出，更多還是要集成業務需求，自然也就繞不開業務的處理邏輯；
二、場景分析
1、文件特征
文件：「Excel」類型，并且表頭是固定格式，字段內容雖然有要求，但是難免存在細微的誤差問題；
內容：條數「1000」以內，單條數據「150+」個字段，業務結束后導出，會添加業務結果和明細相關字段，最終在「200」個字段左右；
2、業務特征
文件導入后，數據在業務之間流轉時，需要構建相應的主體結構，比如基礎的「客戶檔案」，「業務檔案」，業務處理過程中會生成「明細」，處理完成后會生成「結果」；
3、數據規則
【客戶檔案】
數據在入庫的過程中，需要校驗「客戶歸屬」問題，庫內已有的客戶基于「跟進時間」執行「更新邏輯」，庫內沒有的客戶需要「新增」并「分配跟進人員」；
【業務檔案】
跟隨「客戶檔案」的邏輯，如果客戶更新，則「業務檔案」更新，如果客戶不更新，則「業務檔案」不更新，如果客戶新增，則「業務檔案」直接新增即可；
【數據校驗】
客戶的「基礎檔案」和「業務檔案」的入庫邏輯，完全遵守產品體系現有的限制規則，在邏輯攔截時盡量輸出全面的攔截原因，方便商務人員對文件數據進行修改調整；
三、流程設計
1、業務流程
業務流程從整體上可以拆分四段來看：動作確認、動作監聽、數據處理、業務處理；
【動作確認】
- 「導入」應用前端完成文件上傳OSS的處理，向應用后端提交數據導入的請求，接收請求后會異步處理；
- 「異常記錄下載」會實時響應，功能上看就是一個單表導出，需要返回業務攔截和異常信息；
- 「導出」因為交付時間不確定性，所以由商務人員手動觸發導出，后端組裝完成后提交OSS文件服務器，等待下載；
【動作監聽】
- 「導入」和「導出」的動作監聽，進而觸發相應的流程邏輯；
【數據處理】
- 「客戶檔案」提交給客戶服務處理，如果處理失敗，無法圍繞客戶構建業務流，直接中斷全部流程；
- 「業務檔案」提交給業務服務處理，這里指業務屬性的資料信息，并非場景流程；
【業務處理】
- 「數據導入」的真正目的，依賴系統的處理能力，從而實現相應的業務流程，在過程中會生成關鍵明細和結果數據；
2、導入流程
- 【1】應用后端接收用戶提交的「導入」請求，動作接收成功后立即響應；
- 【2】完成「導入」記錄的存儲之后，通過MQ消息隊列，解耦文件數據的處理流程；
- 【3】對文件進行解析，讀取源數據并存儲到明細表；
- 【4】遍歷明細數據分別實現「客戶」和「業務」的檔案存儲，此處會把失敗原因最大限度回寫到明細記錄中，方便商務二次導入；
- 【5】完成數據入庫后，更新「導入」動作的狀態，最核心的是提供失敗記錄的明細和下載功能；
3、導出流程
- 【1】應用后端接收用戶提交的「導出」請求，動作接收成功后立即響應，初始狀態為：「處理中」；
- 【2】完成「導出」記錄的存儲之后，通過MQ消息隊列，解耦文件的「創建」和「上傳」流程；
- 【3】文件數據分為兩部分，文件原內容和業務處理結果，組裝為新的數據結構；
- 【4】創建新的文件，涉及數據表頭的合并，數據內容的合并，以及「Excel」的格式構建，從而完成文件的生成過程；
- 【5】將生成的文件上傳到文件服務器，由商務人員自行下載并導出，然后交付給渠道方；
四、結構設計
數據導入的表結構，是由具體業務場景決定的，此處就不做展示了；這里只看一看導入導出的調度表結構，即操作記錄和狀態以及數據明細的存儲；
【動作記錄】
存儲「導入」和「導出」的請求記錄，都涉及文件信息的管理，至于「業務ID」和「批次ID」是指集成業務的處理流程，同時也可以基于該「ID」限制同批次下的重復動作，降低不必要的資源占用；
【數據明細】
在「導入」的時候，對文件數據的臨時記錄表，方便對數據的多次讀取和處理，避免流程中斷導致文件的重復解析；
在「導出」的時候，需要依賴原數據的構建新的「Excel」文件，在交付渠道方時保證原內容的不變，只新增系統中業務的處理明細和結果；
五、實踐總結
雖然對于「Excel」或者其他文件的「導入」和「導出」的參考案例很多；
但是在研發實踐中，這依舊是一個不容易實現的過程，在數據和文件互相搬運的過程中，如何與「業務場景」進行平穩的集成，才是真正的復雜邏輯；
從開始工作直到現在，關于「導入」和「導出」的實現方案參考或者落地過很多個，整體可以從兩個方向考慮；
【應用系統】
通常文件格式是「Excel」、「word」、「Pdf」等，并且涉及的數據體量并不大，采取「異步」的方式解耦即可；
對于文件的「導入」來說，需要重點考慮的邏輯，在于如何與業務平穩集成，在出現問題時，能夠給產品頁面準確的信息反饋，從而提高文件的二次處理效率；
對于數據的「導出」來說，是一個「高危」的操作，通常是不分配大量數據的導出「權限」，如果有需求則要對數據進行計算分「批次」導出；
【數據系統】
數據體量較大的情況下，不推薦從應用系統考慮「優化」的策略；
如何確定「數據體量較大」的臨界值，需要測試系統的處理能力，系統業務流量高峰時，去「并發」執行導入和導出，從而得出合理的數值，不過大部分產品都是限制單文件最大「5000」條；
從分布式架構中組裝大量的數據并「導出」文件，其資源占用過高，并非主流的實踐方案；
當下比較常見的方式，直接從「數據層面」入手，搭建「傳輸」或「轉換」的通道，以「API」或者「頁面入口」的方式，觸發流程即可；
在數據體量超過應用系統的處理能力時，會搭建專用的「數據傳輸通道」來處理；
這種模式在數據型業務中很常用，可以隔離大量數據的「IO流」操作，確保應用系統運行的安全穩定，也可以極大提升數據和文件互相搬運的處理效率；
