[2]中提到了下面這些

玩遍Informatica 、DataStage、Kettle、ETL Automation

業(yè)務數(shù)據(jù)庫， 業(yè)務數(shù)據(jù)的設計會遵從OLAP的設計，

而后面我們所說的數(shù)據(jù)可視化和數(shù)據(jù)分析數(shù)據(jù)會遵從OLTP的數(shù)據(jù)設計，

更多的冗余換來更快的處理時間，這就涉及到之間轉(zhuǎn)換的ETL

http://www.hadoop1024.com/category/etl/

?

[3]中提到:
每天銀行的ods用kattle spoon把數(shù)據(jù)抽取出來，
打包ftp傳到我們的服務器上，
我這邊寫shell腳本調(diào)sqlldr和存儲過程，
用crontab定時跑批。
每天大概要處理45G的數(shù)據(jù)，花3個小時跑批，全程250+存儲過程。

?

[4]中提到:

Datastage的實時監(jiān)控做的更加好

Datastage < Informatica < kettle,相對來說，Datastage跟Informatica在遇到問題去網(wǎng)上找到解決方法的概率比較低，kettle則比較多。

自己結(jié)論，kettle和datastage記得都學習下

?

[5]中提到

1、你在ETL平臺里設計的任務，是不是橫平豎直、每一個TASK都對齊了，每條數(shù)據(jù)線都水平或者垂直？

2、你的整個ETL過程是冪等(谷歌上可以找到這個詞語的具體含義)的嗎？也就是通過源數(shù)據(jù)反復執(zhí)行多少次，都不會對目標庫產(chǎn)生影響？

3、有沒有充分利用本地存儲來處理數(shù)據(jù)，是不是嚴格執(zhí)行了E-T-L的分離，并且盡量減少對數(shù)據(jù)庫資源的占用？

4、有沒有做到源入源出，也就是每一條進入的數(shù)據(jù)，都有出口（不符合規(guī)則的源數(shù)據(jù)輸出到獨立的錯誤數(shù)據(jù)日志里面）

5、每一類ETL任務都有一個標準設計和開發(fā)流程。

6、先設計、再開發(fā)，先有ETL文檔，然后才在工具上形成任務。

?

[6]中提到的sh-etl一定要學習下．

?

[7]中的下面內(nèi)容很重要:

Narkhede 是 Confluent 的聯(lián)合創(chuàng)始人和 CTO，在演講中，

他首先闡述了在過去的十年間，數(shù)據(jù)和數(shù)據(jù)系統(tǒng)的重要變化。

該領域的傳統(tǒng)功能包括提供聯(lián)機事務處理（online transaction processing，OLTP）的操作性數(shù)據(jù)庫以及提供在線分析處理（online analytical processing，OLAP）的關(guān)系型數(shù)據(jù)倉庫。

來自各種操作性數(shù)據(jù)庫的數(shù)據(jù)會以批處理的方式加載到數(shù)據(jù)倉庫的主模式中，批處理運行的周期可能是每天一次或兩次。這種數(shù)據(jù)集成過程通常稱為抽取 - 轉(zhuǎn)換 - 加載（extract-transform-load，ETL）。

?

?

?

Reference:

[1]開源ETL工具-kettle初識

[2]ETL 轉(zhuǎn) Hadoop 怎么樣？

[3]國內(nèi)的ETL工程師日常工作是什么樣的？

[4]ETL常用的三種工具介紹及對比Datastage，Informatica和Kettle

[5]請問ETL工程師是吃青春飯么？

[6]sh-etl：五臟俱全的簡單etl系統(tǒng)

[7]批處理ETL已死，Kafka才是數(shù)據(jù)處理的未來？

總結(jié)

以上是生活随笔為你收集整理的ETL工作内容调研的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。