DataPipeline CPO 陳雷:實時資料融合之法,便捷可管理

DataPipeline發表於2020-11-19

陳雷 | DataPipeline 合夥人 & CPO

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


在確保了實時資料融合的穩定性之後,企業開始關注資料管理能否滿足數字化轉型和多速IT的敏捷要求。實時資料融合產品的敏捷性、便捷性成為一個重點考量要素。


配置便捷

傳統資料處理過程的構建,往往是以月為單位交付的,例如構建一個資料倉儲或一個大資料平臺,我們經常聽到的建議是建設週期不要超過半年,即使是資料倉儲構建完成之後,由於需要進行大量的程式碼開發,新的業務分析需求或者資料需求的交付週期也是以周為單位計算的,這很難滿足業務應對市場競爭的需要,更不用說面對紛繁複雜的市場環境和競爭格局,業務形態是在不斷調整變化的,這也對後端的資料支撐提出了更高的要求,資料資源作為戰略資源必須在合適的時間出現在合適的地點,實時資料更是如此。

而眾所周知,資料處理交付週期長的根本原因是處理過程中要面對從異構語義、對映關係到執行方式、運維方式等大量問題,這就要求實時資料融合能夠在提供配置式鏈路定義,無程式碼任務構建的基礎上,能夠將各類涉及到執行穩定,運維管理的設定也配置化、自動化,從而幫助使用者將實時資料融合從原有的研發模式轉變為系統配置管理模式。


部署便捷

CPU、記憶體、儲存、網路、作業系統、補丁、編譯器、使用者組,許可權、安裝、節點註冊、負載再平衡,系統部署一直以來都不是一件讓人心情愉悅的事情,這還是你做好了資源規劃能夠拿到系統資源的前提下,雖然近年來隨著雲端計算技術被普遍接受,系統資源的申請、部署已經不成問題。但現在大部分的資料處理系統的部署擴充套件方式都不是很友好,也許就像程式碼才能體現程式設計師的價值一樣,命令列才能體現運維工程師的專業性,而實時資料流量的不確定性與業務部門對實時資料利用的快捷交付要求都需要能夠靈活便捷的進行部署與擴充套件,因此就要求實時資料融合透過高效便捷的容器化部署、高度自動化的系統資源發現、註冊、負載平衡機制和高度配置化的系統資源分組管理模式滿足使用者對部署的便捷可管理需求。


分層管理

在今天的市場環境與技術發展的共同作用下,資料管理不僅僅需要可靠與可控性,同時為了應對移動網際網路帶來的客戶行為和市場需求的改變,必須能夠滿足數字化轉型和多速IT的敏捷要求,但作為業務資訊化數字化的底層基礎平臺,資料節點的安全性、穩定性、業務連續性是不容有失的,資料本身的一致性、準確性、完整性也是業務創新的前提條件,更不用說對整個系統的監控、日誌、預警等基礎運維工作需要遵循企業整體的資訊化管理機制,因此,如何在有效地滿足資料系統管理需求的前提下,提升資料獲取在各個環節的配合效率就顯得至關重要。

實時資料融合作為敏捷性要求最高、覆蓋業務系統資料來源最廣的系統就需要對資料節點註冊、資料鏈路配置、資料任務構建、系統資源分配等各個環節能夠分層次、分租戶、分使用者進行解耦。


按需服務

當前的企業環境中,再去區分資料的所有者、使用者已經沒有意義,隨著企業級的資料倉儲、大資料平臺、主資料管理系統、資料管控系統的逐步建成,獲取企業級的資料已經不是十分困難。而隨著雲端計算的不斷深入,系統資源的獲取也已經隨需應變,而對於實時資料來說,由於敏捷性要求較高,流量變化頻繁,就更需要能夠做到按需服務,在分層管理的基礎上,在保障資料資源可控的前提下,為資料應用提供更多的自主性也是體現實時資料處理便捷可管理的一個重要方面。

實時資料處理應當將資料獲取的範圍、資料任務的生命週期、系統資源投入的多寡等許可權更多的交給實際使用資料的業務部門或應用開發人員。

——無程式碼配置式鏈路定義,任務也交給下游部門自己跑了,我可以去看看我的排位了。

——事物都是在發展變化的,所以實時資料融合也需要能應對不斷的進化,所以你再往下看。


在下一期的“ 實時資料融合之法,開放可擴充套件”中,我們將從資料節點開放性、語義特性開放性、清洗方式可擴充套件、配置功能可擴充套件四個方面展開討論,請大家持續關注!


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31556703/viewspace-2732960/,如需轉載,請註明出處,否則將追究法律責任。

相關文章