實時資料融合之法，穩定高容錯

陳雷 | DataPipeline 合夥人 & CPO

曾任 IBM 大中華區認知物聯網實驗室服務部首席資料科學家、資深顧問經理。十年管理經驗，十五年資料科學領域與金融領域經驗。綜合交通大資料應用技術國家工程實驗室產業創新部主任，西安交通大學軟體學院大資料智慧創新中心主任，中國電子學會區塊鏈專委會委員。

上週我們釋出了“實時資料融合之道，博觀約取，價值驅動”，文章提到實時資料既要全面覆蓋能被利用的各類資料，也要基於價值分清先後順序；既要高效釋放資料價值，也要選好抓手、切入點。而觸客業務因為直接與收入相關，無疑成為實時資料最好的切入點。也正因為其重要性和敏感性，所以大家更為關注實時資料融合過程中的穩定高容錯。

不管是絕地求生還是企業級系統，穩定輸出都是最重要的。

上下游不穩定時，你得穩定

實時資料在獲取與載入過程中，上下游節點一般都是序號產生器制而不是納管機制，系統很難實時感知到上下游節點的實際狀態和發生的問題，在實際企業環境中，實時資料融合的上下游節點往往在業務連續性和服務級別上高於實時資料融合系統，因此，實時資料的處理需要遵循上下游節點的管理機制，例如認證方式、安全加密方式、連線時長、最大連線數，甚至於日誌模式也需要你來適應，更不用說上下游節點可不止一種型別，在充分調研準備和依賴管理機制之外，需要實時資料融合具備足夠的策略配置與容錯機制來應對上下游系統不穩定帶來的不確定性，從而保證自身的穩定性。

結構不穩定時，你得穩定

上下游節點我們們穩住之後，你就需要考慮節點內部物件不穩定的問題了，也就是所謂的DDL問題，原因同上，可能在一些資訊化水平較高的企業中，任何的資料結構調整需要首先在資料管控平臺進行影響分析，通知所有下游系統聯調測試後統一上線切換，可這畢竟是別人家的孩子，到了自己家，還有各種各樣的原因會出現。上游系統結構變化是在你意想不到的時候出現的，而下游系統嗷嗷待哺，定責分鍋那是後面的事，先得保證業務不能停，因此就要求實時資料處理需要能夠提供完善的結構變化應對策略，而針對不同的資料節點型別和增量獲取機制，結構變化的感知方式也不盡相同，有的簡單高效，有的成本極高，這又需要實時資料融合能夠按照不同的場景進行取捨與配置，從而保證自身的穩定性。

流量不穩定時，你得穩定

一開始處理實時資料時，我們往往把實時資料與交易資料，行為資料等時序資料掛鉤，而在實際企業環境中，往往會出現部分系統某些情況下大面積更新操作，上游增量會突然增大，平時他安靜得像山間的小溪，一轉臉它變成了壺口的黃河，所以實時資料的流量往往和上游應用系統、資料模型、資料管理機制的設計有關，而不能僅僅基於交易量進行評估，在精確的容量評估與資源準備之外，還需要考慮資源的利用率和成本問題，因此就要求實時資料融合擁有強大的反壓處理機制和靈活的讀取、寫入限制配置，可以透過控制讀取速率、並行度、批次大小的方式，實現增量資料反壓的處理，從而保證自身的穩定性。

環境不穩定時，你得穩定

一般來說，企業級環境中網路、儲存、計算裝置的穩定性還是可以保證的，但我敢保證，就像每個謝頂的程式設計師都有那麼幾個加班的夜晚一樣，每個運維工程師都能講幾個系統莫名其妙出問題又莫名其妙就恢復了的靈異故事，因此就要求實時資料處理能夠提供預設策略在無計劃的網路不可用、出現未知異常等情況下進行重新連線，重置執行緒乃至重啟任務等自動化操作，從而保證自身的穩定性。

——好穩呀，不過領導，這麼多配置，這得搞多長時間呀？

——時間？時間是沒有的。我們們什麼時候有過時間？所以你再往下看。

下一期我們將從配置便捷、部署便捷、分層管理、按需服務四個方面詳談“ 實時資料融合之法，便捷可管理”，請大家持續關注！