BI項目記（二）：給我接套數據

此次故事的主角仍是小D，小D工做在一家傳統公司的信息部門，負責數據倉庫系統的運維和開發。

話說有一天，小D被教導老闆的office，老闆給佈置了一個任務，讓小D在現有數據倉庫裏接入剛上線的兩個系統的數據。

因而小D找到了對應系統的開發團隊。多是對方剛上線的緣故，最終也沒有人搭理小D，因而直接把數據庫只讀權限open給了小D，讓小D須要什麼數據本身去抓取，若是一個查詢不知道怎麼寫再單獨去發郵件問。

話說其中一個系統還好，是SQL Server，這個跟小D的數據倉庫一致，直接抽取就行。

可是另一個系統就麻煩了，是Oracle，因而小D查閱了不少資料，安裝Oracle相應的組件在數據倉庫中，而後磕磕絆絆的終於鏈接到了這個數據庫。

收集完報表的需求，確認了用戶須要看到的每個原子數據在界面上的位置，而後在開發平臺經過抓取的方式也獲取到了相應的查詢方式，有些實在抓取不到的就發郵件問，雖然對方很忙但郵件回覆的也還算及時。（數據建模的故事這裏暫且不談，話題太大。）

可是隨後問題就來了，小D發現這兩個接口常常報錯，多數錯誤集中在源端數據結構的變動，好比名字變了，類型變了，長度變了，是否容許爲空變了。

這個也能夠理解，由於對端源系統用的是敏捷開發方式，幾個禮拜上線一個變動是屢見不鮮。而對於源端系統團隊，下游到底拿了哪些數據，他們也沒法獲知，因此也不能在第一時間通知到下游受影響的部門。

因此小D想到一個方法，就是把他所要的數據，提交給源端系統，讓源端系統負責幫忙組織這些數據，放在一個平面文件裏，在這個平面文件中，全部的字段名都是提早約定好的。

這樣一來，源端系統知道了下游系統須要什麼數據，在每次作變動的時候，就會有一個地方知曉，這個變動對於下游的影響。而對於有些變動，徹底在能夠不改變這個接口的狀況下實現，減小了下游系統的開發和測試成本。

小D對於這個方法仍是很滿意的，只是對於那個Oracle的系統，操做系統是Linux，他們只支持用SFTP的鏈接，而這個工具在Windows下是沒有微軟自帶工具解決的，不過還好經過第三方工具均可以搞定，並且第三方工具也都支持ETL接口編程，調度起來也都還方便。

這個方法確實方便了小D，但源端系統若是得不到實惠其實也是很難推進的，而這裏對於源端系統來講，最主要的一個實惠就是，對於同一份數據，可能下游好幾個系統都須要，相比先前的方案，他們只導出一次就能夠了，避免先前的數據庫直連，一樣的數據要被訪問屢次，影響系統的性能。

小D同時也發現，相比先前的數據庫直連，這個方法有效的避免了，數據倉庫因爲某些特殊緣由失敗，錯過數據的加載的時間的問題。先前有好幾回就是因爲小D的數據倉庫後半夜莫名其妙的打補丁重啓，而後錯了了約定的數據加載時間，結果等問題被發現的時候，源端業務系統已經開始新一天的業務運營，先前的數據根本追不回來。

因而，接口順利的運行了好長時間。

再後來，報表的需求愈來愈多，更多的明細數據提了出來，而此時經過平面文件的導出就顯得很笨拙，跟傳統數據庫直連的方法來比較，這個方法多出了額外的IO開銷，以及序列化和反序列化成本，直接致使的問題就是直到次日上班的時候，要麼是文件尚未導出完畢，要麼是文件尚未加載完畢。

因而，經過中間數據庫的方法被小D提起。就是在源系統和數據倉庫間，創建另一個單獨的數據庫，天天源系統會把下游系統系統須要的數據送到這裏，下游系統隨後直接從這個中間庫加載數據。

就這樣，系統平穩的運行了很久很久。

再後來，隨着大數據的火熱，好多部門都搭建起來了本身的大數據平臺。忽然有一天小D被通知道：請求的數據能夠直接從大數據平臺裏獲取，就不須要再走中間庫了。

因而小D作了一番研究，發現源端系統每次是把數據發送給大數據平臺存儲，他們主要是方便本身部門報表平臺，主要是Tableau系統的對接。

就這樣，小D也跟着踏上了大數據之路。。。