數據，數據流，數據管道

最近比較忙，不過最近間接的獲取了不少關於數據流，及數據融合，管道等方面的知識，由於腦子記憶體小，不寫出來很快就會忘記，所以還是硬著頭皮寫一寫。

數據作為一個專有名詞，至少有10年的時間，圍繞這個詞衍生出很多辭彙。

大數據分析，數據敏捷分析，數據spss, 大數據應用，智慧數據AI，圍繞這些辭彙的產品也不少，HADOOP, SPARK, HIVE, Teradata,greenlum 等產品。

這些產品已經在很多公司中的大數據分析中得到廣泛的應用。今天想說的並不是這些產品，今天想談的是一個最近悄然熱門的行業 Datapiple，數據管道。

什麼是數據管道，為什麼需要數據管道軟體，數據管道在目前的企業中到底有什麼地位，如何應用。

有人馬上提到，你別糊弄人，你說的不就是ETL嘛，老掉牙了。是嗎那我提幾個問題，你看看如何解決。

問題1 ：業務部門數據由於歷史原因，使用的RDS 類型多種多樣，有ORALCE ，有SQL SERVER ，有MYSQL ，甚至有MONGODB ，現在大數據分析，要整合部分這些資料庫的數據，到一個大數據平台進行數據分析？

問題2：業務部門數據表設計之初，沒有考慮ETL數據抽取的問題，換言之沒有時間欄位，你如何在上百G的數據中，抽取增量數據？

問題3；業務部門多種需求，要求在業務獲得數據的1個小時內，將更新的業務數據傳遞到數據部門進行處理，獲得DATAVIEW

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

問題5,；目前由於資料庫更新，將ORACLE 資料庫替代，使用PostgresQL 來代替ORACLE。目前需要進行灰度發布，ORACLE 和 POSTGRESQL 數據之間進行實時同步，當程式跑通，上線兩個禮拜後沒有問題，將ORACLE 清除。

說沒有什麼了不起的同學，站出來，把我上面的問題一併解決吧，估計已經吐血了。

在提升一個高度，站到CDO的角度，你公司使用的資料庫類型，我不關心，我只關心，你的數據流，是否能及時的傳導到我的各種目的地，讓我進行分散式的運算。同時數據必須在管道中，進行加工處理，而我還要一些RAW的數據對我計算的數據進行驗證，也就是單點多傳，數據清洗，數據整理的要求。

估計說ETL 的同學你的膽汁都吐出來了吧！！

這時候我聽到一個聲音 ORACLE OGG ， I am sorry，

1 OGG 有多貴你知道嗎？

2 OGG 能滿足上面所有的需求嗎？

價格我們先放到一邊，讓OGG 支援 ORALCE 到 PG 的數據流， ORACLE 到 TIDB 的數據流， MONGO DB 到傳統數據的數據流（對你沒有聽錯是MONGO DB 到傳統資料庫的數據流）

OGG還需要在數據的源端，安裝AGENT，造成某些伺服器的負擔和不安全性，如果是外企，還要在評估一番你的數據獲取方式安全與否，然後在推諉，扯皮，審批一番，在中國市場瞬息變化的行情下，半年過去了。等批准的時候，市場早就變化了，數據變質了。

而每次數據不能及時供應的背鍋俠，運維，還是站在背鍋俠的最前端，多個數據源數據獲取不及時造成數據獲取延遲，數據獲取不準確，數據提供的格式不對，數據提取時，對業務系統的負擔，造成業務投訴。

終上所述，集中了業務數據分析，大數據部門，運維，人的，機器的，程式的，各種問題，在這個數據通道的需求中，集中爆發，各種不滿和委屈淋漓盡致。

我們需要什麼：

1 一個能實時獲取數據流，將業務數據像水一樣的方式，通過水管順暢的流向各個目的端，支援者。

2 一個能支援各種資料庫，及大數據軟體的數據交換中心的支援者

3 一個能在數據交換的過程中，還能做點數據的小變動，將不必要的數據，截止在數據的源端的工具。

4 一個能方便快捷，部署，不在數據源端做任何安裝的數據獲取軟體

5 將複雜的ETL + 數據調度，轉換為無需擔心的數據一致性必然傳輸。

——————————————————————————————

這樣的軟體有沒有，根本就沒有吧 NO NO NO

基於每個資料庫的底層原理， ORACLE REDO ,ARCHIVE , SQL SERVER CDC , MYSQL BINLOG , POSTGRESQL WAL， MONGODB 的OPLOG 將這些底層編碼破解的方法，就是獲得上述能力的先決條件。

避免有廣告的嫌疑，這裡不提任何公司的名字，但在中國市場，已經有這樣的高科技企業，實現了這樣的功能。每個高速發展的企業，也需要這樣的軟體，將死的數據，變化為數據流，讓每個數據的索取者，和數據提供者，皆大歡喜，一身輕鬆。