1樓：邱同學
就我目前專案組的情況談談：
1、linux基本操作、shell等指令碼：伺服器為linux系統，排程為crontab。編輯排程任務時間，就等於是用vi修改乙個檔案；如果有一些稍微複雜一點的邏輯，不方便在etl工具中處理的，得用shell或python之類的，寫一些指令碼；排程日誌檔案可能需要統計分析之類的，要用到shell指令碼，或者簡單的使用awk、grep、sed等命令。
2、業務依賴：得知道先執行哪些，再執行哪些。這樣，第一，不至於把資料跑錯了；第二，某天，中間有一處邏輯報錯了，不至於不知道哪些要重新更新（據我的了解，有的依賴關係並沒有十分完善）。
3、資料庫、sql效能：需要排程的作業很多的的話，全部序列執行作業是不行的。並行的話，得考慮並行作業的資料量，對資料庫資源的消耗（排序，分組之類的），不同程度的單配能降低因資源不足帶來的報錯風險。
先這些了。
2樓：大表哥
只是排程的話，你的崗位性質是不是有點接近運維了？因為你不用關心ETL的實現邏輯，只需要知道排程關係（作業/作業流依賴關係），而且這些關係應該都是開發人員提供。
你需要精通排程工具和作業系統
3樓：李宓
排程的話，要看你在專案中的角色是什麼？
流程設計？排程實施？監控維護？
1.首先還是需要熟悉具體業務。
2.如果是流程開發的話，需要有一定的程式設計思想和經驗。
3.如果是實施人員的話，作業系統知識是必備的。
4.監控維護的話，需要熟練使用對應的ETL工具。
參考：TASKCTL - ETL排程技術平台
4樓：徐江
和PM明確設計思路完善資料流在ETL流程中的每乙個形態設計思路不能侷限於某種ETL工具。 Kettle是不錯的選擇免費開源功能強大業務量和資料量都大的情況可以考慮IBM的Datastage。
另外不同形態的資料載入和轉換的思路也很重要，簡單的說如何在XML和資料庫之間傳接資料等等。
資料庫開發和ETL以後的發展方向是什麼？
用心閣 我的觀察和猜測 資料倉儲會與大資料技術結合，比如Apache Kylin。ETL工具也會跑在Hadoop集群上，利用集群能力來應對大資料的ETL需求，各種DataFlow的專案，比如Apache Pig，Cascading，Hortonworks DataFlow等 OLAP會利用批量和流式...
大算資料的未來和發展方向？
會飛的魚66 未來，大資料可能成為最大的交易商品。但資料量大並不能算是大資料，大資料的特徵是資料量大 資料種類多 非標準化資料的價值最大化。因此，大資料的價值是通過資料共享 交叉復用後獲取最大的資料價值。未來大資料將會如基礎設施一樣，有資料提供方 管理者 監管者，資料的交叉復用將大資料變成一大產業。...
2023年之後資料庫的發展歷史怎樣
我記得比較大的幾個坑就是 column store,main memory,key value store,SQL on Hadoop,geo distributed transaction 這個更多是噱頭 cloud multi tenancy,resource isolation,auto sc...