陳雷 | DataPipeline 合夥人 & CPO
曾任 IBM 大中華區認知物聯網實驗室服務部首席數據科學家、資深顧問經理。十年管理經驗，十五年數據科學領域與金融領域經驗。綜合交通大數據應用技術國家工程實驗室產業創新部主任，西安交通大學軟件學院大數據智能創新中心主任，中國電子學會區塊鏈專委會委員。
上週我們發佈了“實時數據融合之道，博觀約取，價值驅動”，文章提到實時數據既要全面覆蓋能被利用的各類數據，也要基於價值分清先後順序；既要高效釋放數據價值，也要選好抓手、切入點。而觸客業務因爲直接與收入相關，無疑成爲實時數據最好的切入點。也正因爲其重要性和敏感性，所以大家更爲關注實時數據融合過程中的穩定高容錯。
不管是絕地求生還是企業級系統，穩定輸出都是最重要的。
上下游不穩定時，你得穩定
實時數據在獲取與加載過程中，上下游節點一般都是註冊機制而不是納管機制，系統很難實時感知到上下游節點的實際狀態和發生的問題，在實際企業環境中，實時數據融合的上下游節點往往在業務連續性和服務級別上高於實時數據融合系統，因此，實時數據的處理需要遵循上下游節點的管理機制，例如認證方式、安全加密方式、連接時長、最大連接數，甚至於日誌模式也需要你來適應，更不用說上下游節點可不止一種類型，在充分調研準備和依賴管理機制之外，需要實時數據融合具備足夠的策略配置與容錯機制來應對上下游系統不穩定帶來的不確定性，從而保證自身的穩定性。
結構不穩定時，你得穩定
上下游節點咱們穩住之後，你就需要考慮節點內部對象不穩定的問題了，也就是所謂的DDL問題，原因同上，可能在一些信息化水平較高的企業中，任何的數據結構調整需要首先在數據管控平臺進行影響分析，通知所有下游系統聯調測試後統一上線切換，可這畢竟是別人家的孩子，到了自己家，還有各種各樣的原因會出現。上游系統結構變化是在你意想不到的時候出現的，而下游系統嗷嗷待哺，定責分鍋那是後面的事，先得保證業務不能停，因此就要求實時數據處理需要能夠提供完善的結構變化應對策略，而針對不同的數據節點類型和增量獲取機制，結構變化的感知方式也不盡相同，有的簡單高效，有的成本極高，這又需要實時數據融合能夠按照不同的場景進行取捨與配置，從而保證自身的穩定性。
流量不穩定時，你得穩定
一開始處理實時數據時，我們往往把實時數據與交易數據，行爲數據等時序數據掛鉤，而在實際企業環境中，往往會出現部分系統某些情況下大面積更新操作，上游增量會突然增大，平時他安靜得像山間的小溪，一轉臉它變成了壺口的黃河，所以實時數據的流量往往和上游應用系統、數據模型、數據管理機制的設計有關，而不能僅僅基於交易量進行評估，在精確的容量評估與資源準備之外，還需要考慮資源的利用率和成本問題，因此就要求實時數據融合擁有強大的反壓處理機制和靈活的讀取、寫入限制配置，可以通過控制讀取速率、並行度、批次大小的方式，實現增量數據反壓的處理，從而保證自身的穩定性。
環境不穩定時，你得穩定
一般來說，企業級環境中網絡、存儲、計算設備的穩定性還是可以保證的，但我敢保證，就像每個謝頂的程序員都有那麼幾個加班的夜晚一樣，每個運維工程師都能講幾個系統莫名其妙出問題又莫名其妙就恢復了的靈異故事，因此就要求實時數據處理能夠提供預設策略在無計劃的網絡不可用、出現未知異常等情況下進行重新連接，重置線程乃至重啓任務等自動化操作，從而保證自身的穩定性。
——好穩呀，不過領導，這麼多配置，這得搞多長時間呀？
——時間？時間是沒有的。咱們什麼時候有過時間？所以你再往下看。
下一期我們將從配置便捷、部署便捷、分層管理、按需服務四個方面詳談“實時數據融合之法，便捷可管理”，請大家持續關注！