這些傳統數據集成的痛,你還在經歷嗎?

20多天後,我們將步入2020年。在即將過去的2019年,人工智能、5G、數字貨幣等技術不斷衝擊着傳統的數據治理模式,你所在的企業是否同樣感受到了衝擊?在這些難以言說的痛中間,又有多少是傳統數據集成所帶來的?

 

今年,隨着數據驅動決策的理念逐漸深入人心,越來越多的企業開始逐步對存量的數據資產進行消費,在數據消費過程中引入各種數據集成的工具,來解決數據打通的問題,並用於後端數據消費:如分析報表、數據查詢、和數據挖掘等工作。

 

大數據時代的到來,不僅意味着數據來源更加廣泛,數據存儲量增加,同時對於數據及時性要求也越來越高,傳統數據集成工具的瓶頸越發明顯。其中主要表現在以下幾點,看完後,你正在經歷哪幾種?

 

一、數據及時性

 

各行各業的業務部門對於數據時效性的看法是:希望越快越好。金融行業的客戶經理希望第一時間得到客戶的動賬通知;客戶在申請貸款時,希望能夠秒批秒貸;數字化營銷部門的負責人希望能根據渠道投放的實時反饋及時調整投放策略;連鎖零售門店也希望能實時掌握各個門店的庫存,避免外賣的騎手取貨時才發現貨品已經售罄,而客戶不得不提出退款;而在互聯網行業,任何用戶的行爲分析都需要實時,以便在客戶短暫的上線時間段能抓住客戶的需求點。業務追求的是增長,快對於業務的改變不僅僅是減少低效的投入,及時止損,快速試錯,更重要的是能加快業務的微創新,提升客戶的體驗,在更短的週期內快速迭代,應對千變萬化的市場。

 

而隨着業務的快速增長,數據源端應用系統的數據結構往往會快速變化,更多異構數據源以及外部數據也會不斷地被引入,這給基於傳統數據集成工具的開發流程帶來了不小的挑戰。傳統的數據集成從取數任務的開發到用戶能夠用上數據,整個開發週期耗時較長,跨越多個部門,難以敏捷響應,往往一邊是火燒眉毛的業務用戶,另一邊是加班加點的數據工程師們。

 

二、異構數據源和目的地

 

企業在發展過程中會採購不同供應商提供的服務系統,這就導致數據源採用的數據庫技術不盡相同。隨着大數據技術的發展以及 NoSQL 接受程度越來越高,導致數據的存儲方式也多種多樣。出現關係型數據庫和非關係型數據庫並存,多種結構化和非結構化數據亟待打通的情況。

 

而在數據服務側,從傳統的數據倉庫技術到現在的大數據平臺,從報表展現到預測分析,數據的目的地從數倉,MPP 數據集市,基於 Hadoop 的大數據平臺到雲上的各種數據服務,數據集成產品需要支持多樣化的數據目的地。由於存在多種異構數據源和目的地並存的情況,如何快速打通數據孤島,實現數據資產的消費成爲困擾很多企業 IT 部門的難題。而傳統的數據集成工具由於本身的技術架構在應對異構數據源,尤其是非結構化數據方面表現乏力,或是實現異構兼容的代價較高,因此在落地的項目中,二次開發工作量較大,並且上線後維護成本非常高。

 

三、人工開發和維護成本

 

隨着業務的開展和渠道的多樣化,業務和決策部門對於數據及時性的要求越來越高,這給數據部門帶來了很大壓力。傳統數據集成工具在數據需求愈加旺盛的現代化企業裏面臨以下的困難:

 

1. 數據開發週期長、工作量大


傳統的數據集成工具開發流程,首先需要在目的端創建數據表,其次通過工具進行數據表字段類型的映射、選擇增量或全量同步規則和編寫清洗規則,最後將開發好的任務配置發佈到調度 Sequence 中。如果一個數據源需要 20 張數據表,意味着至少需要開發 20 個任務。

 

2.維護成本高

 

傳統 ETL JOB 需要依靠調度配置任務的依賴關係,存在數據同步的先後次序。這樣不僅拉長了數據消費的週期,也增加了運營成本。需要運營人員充分了解數據之間的依賴關係,增加了運營的難度;且同步採用的單表同步方式,導致數據同步數量龐大,增加了監控的難度。

 

3. 源端數據表結構變化監控難

 

隨着業務的發展,源端的數據表結構會做對應的調整,爲保證數據的準確性和一致性,目的端也需要能夠及時做響應。傳統的數據集成工具很難實現源端數據表結構變化的自適應。


4. 異構數據源兼容難

 

傳統數據集成工具,在支持關係型數據庫方面大多能夠提供強大的解決方案,但是對於支持非結構化數據庫能力偏弱。這就導致很多企業在打通異構數據源時,需要使用多套產品來解決異構數據源打通的問題。


針對上述提到的情況,一位相關工作人員就提出了以下幾點讓人崩潰的問題:

問題1:業務部門數據由於歷史原因,使用的RDS(關係型數據庫服務)類型多種多樣,有Oracle、SQLServer等 ,如何整合這些數據庫的部分數據到一個大數據平臺進行數據分析?

 

問題2:業務部門數據表設計之初,沒有考慮ETL數據抽取的問題,換言之沒有時間字段,如何在上百G的數據中抽取增量數據?

 

問題3:關於實時計算的大數據項目,目前我們業務部門需要5~10分鐘獲得一次當前Call Center(呼叫服務中心)的工作情況,數據量較大。如果不能實時運算,難道要不斷藉助各種傳統的ETL 進行增量數據提取?

 

問題4:業務部門中有數據分析人員,有人精通 T-SQL, 有人擅長 PL/SQL,還有人只會JAVA,如何滿足多種多樣的數據目的地需求?

 

問題5:由於數據庫更新,需要使用PostgreSQL代替Oracle。目前需要進行灰度發佈,Oracle 和 PostgreSQL 數據之間進行實時同步,當程序跑通,上線兩個禮拜沒有問題後將Oracle 清除。

 

問題6:傳統ETL在數據權限管理上問題較多,從與技術無關的角度來說,至少公司尤其是外企的審計、安全部門,對數據的流向、權限是非常重視的。有一個良好的用戶權限管理,非常有必要。

 

以上幾個問題只是其中的冰山一角,當多個數據源數據獲取不及時造成數據獲取延遲,數據獲取不準確,數據提供的格式錯誤時,就會給業務系統帶來負擔,造成業務投訴。這期間集中了大數據部門工作人員、機器、程序等各種問題。各種不滿和委屈在這個數據通道的需求中,集中爆發。

 

四、新型數據融合平臺做了哪些優化工作

 

1. 針對及時性問題

 

實時的數據供應鏈是數據驅動企業的命脈,如果流計算足夠快的話,批處理和流處理將採用同一個技術框架,採集、集成、分發數據,這也是 DataPipeline 基於流計算框架設計面向未來數據融合平臺的出發點。DataPipeline 基於流式數據處理的模式,實現在不間斷的時間軸上,不間斷地處理無限數據集。不僅能實時獲取源端的數據變化,還能及時消費掉,這樣可以保證數據的實時傳輸。

 

2. 針對多源異構數據同步問題


DataPipeline 在產品設計之初,就深刻意識到只有打通各種異構的數據源,才能真正實現企業級的數據融合。目前 DataPipeline 產品已經適配了市場上主流的關係型數據庫和非關係型數據庫,對象存儲等。同時還可以快速實現雲上數據平臺、以及各種大數據平臺的數據打通、以及文件系統同步等功能。

3. 針對開發和後期維護

 

DataPipeline繼承了開源的優勢,靈活、自主可控、可擴展,同時側重於豐富用戶所需的管理功能:數據管理,監控,運維,穩定性,容錯性,以及故障排查的能力。

 

另外在用戶管理權限方面,工作人員通過可視化運維看板(數據任務看板、速率進度信息、報表統計、日誌審計),可以看到數據同步的狀態、數據的來源與結構,及時瞭解數據的接入、交換和數據流向。當數據同步出現問題時,基於完善的糾錯機制與系統狀態監控,可第一時間找到數據源並進行處理。在提升工作效率的同時,降低了工作負荷。

 

如果步入2020年,你是否已經想好如何平穩渡過數字化轉型的深水區?藉助新型數據融合技術,也許會帶你走出欲濟無舟楫的尷尬境地。

 

部分內容來自:AustinDatabases

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章