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也跟著踏上了大資料之路。。。

BI專案記（二） 給我接套資料