大廠都用什麼存儲數據

⑴ 希捷，西數哪個移動硬碟更好

個人覺得西部數據的硬碟好一點。

1、希捷硬碟一般速度比較快，讀寫比較流暢，一般比較輕巧。

2、wd硬碟一般相對穩定，損耗率比較低。體積略微會比較希捷的厚一些。數據比較重要，速度要求是特別高建議購買wd硬碟。

西部數據公司（WesternDigitalCorp）是全球知名的硬碟廠商，成立於1970年，目前總部位於美國加州，在世界各地設有分公司或辦事處，為全球五大洲用戶提供存儲器產品。長期以來，西部數據一直致力於為全球個人電腦用戶提供完善的存儲解決方案，而作為全球存儲器業內的先驅及長期領導者，西數在為用戶及收集、管理與使用數字信息的組織方面具有豐富的服務經驗，同時也具有良好的口碑，特別是在歐美市場。

西部數據曾經是全球第一大硬碟生產商，但之後被希捷（Seagate）超越，導致西部數據成為全球第二大硬碟生產商，但西部數據的硬碟產品仍然在全世界廣受好評。

⑵ 移動硬碟, 硬碟和光碟存儲文件哪個更好(詳細介紹)

1。先說硬碟，硬碟屬於精密儀器，禁不起磕碰，而且長期使用容易出現壞道，到時候有可能數據不保。可以保存臨時數據，不建議保存重要數據。
2。移動硬碟，只不過是硬碟加了一個硬碟盒罷了，顧名思義嘛，移動硬碟是要經常移動的，主要是在電腦之間傳導大文件的，不是用來保存數據的，以下和1一樣就不再說了。從經濟角度來講，花幾百大洋卻用來保存數據怎麼也不太合適。可靠性還不如硬碟高
2。光碟。如果要長期保存重要數據的話還是建議選用質量好的光碟來保存，從存儲文件這點來看的話，用光碟保存數據更加保險，總不會象硬碟一摔就壞。可是一定要選大廠名牌光碟，質量有保證，要想保存的好還要避潮，避磁，避熱，通風，還有要將光碟樹著放，大不了再買一個質量好的光碟箱或光碟盒子。注意點的話保存10年不成問題。

⑶ 希捷和西部數據移動硬碟哪個好

個人覺得西部數據移動硬碟好一點。

從外觀上來看西部數據移動硬碟與希捷都採用的是中規中矩的純色搭配，並且兩款產品也都均提供了多達5種顏色的選擇，這也足矣滿足更多消費者的 選擇。在外觀的設計上西部數據移動硬碟更為圓潤，而希捷的稜角要小上一些，顯得更為硬朗。

西部數據移動硬碟在各方面的優勢也是非常明顯的。但是這也並不能說希捷的移動硬碟就沒有一點能夠吸引人的。針對對移動硬碟的不同功能的需求，對移動硬碟的選擇也是有差別的。所以在選擇這兩種不同品牌的移動硬碟時，還需要確切的結合自身的需要，選擇最適合自己的產品。

希捷硬碟一般速度比較快，讀寫比較流暢，一般比較輕巧。wd硬碟一般相對穩定，損耗率比較低。體積略微會比較希捷的厚一些。數據比較重要，速度要求是特別高建議購買wd硬碟。移動硬碟希捷和西數真的差距不大。使用過程是基本感覺不出來差別的。從銷量上來說希捷是比西數好一些。

因為這兩個介面都不是即插即用，不能作為外置介面。應該選擇USB或者ESATA介面，至於硬碟盒裡面什麼介面不影響實際使用，根本無須在意．轉速一般是5400和7200，後者當然比較快，希捷西數日立都有自家原產的移動硬碟。

希捷和西部數據移動硬碟的區別

西部數據移動硬碟2.5寸移動硬碟My Passport Essential僅為110×83×15mm的體積比FreeAgent GoFlex的111×83×14mm明顯要短上一截，再加上我們所拿到的FreeAgent GoFlex是需要增加轉接頭才能實現USB 3.0介面的。

在介面部分My Passport Essential與FreeAgent GoFlex所採取的則是完全不同的設計，其中My Passport Essential所採取的是一體化設計，介面就在機身上，無需任何配件。而FreeAgent GoFlex的機身則僅提供了SATA介面，如需轉換為USB 3.0介面，則需要另外加一個轉接器。

⑷ 西數黑盤和希捷酷魚哪個好

希捷和西數都是硬碟行業比較有名的牌子了，應該各有各的特點和優勢。據我了解西數黑盤適用於企業級用戶，而希捷酷魚是PC硬碟，兩者定位不大一樣哈。我這邊是希捷酷魚的重度老用戶，來給樓主推薦一下希捷酷魚的硬碟哈。我現在用的是希捷酷魚1TB的台式機硬碟(型號ST1000DM010)。從價格上，我在京東上對比了同一容量的西數，價格要比希捷的要貴一點，從存儲速度上講，酷魚主軸轉速7200rpm，緩存64M，西數黑盤是7200rpm,緩存是32M，對比可以看出，從這兩個參數上來看，兩者的主軸轉速一致，但酷魚的緩存容量比西數要高，實際工作中，同樣的條件下，酷魚的讀寫速度比西數要快。酷魚的硬碟不僅工作效率比較高，穩定性也很贊，我平時存儲視頻這些大文件不僅傳得很快，傳輸速度也很平穩，更沒有出現過傳輸無故中斷的問題。此外酷魚的售後服務做的也不錯，兩年內，非人為故障可以免費更換新盤，這個比較貼心，畢竟一塊硬碟的價格還是挺貴的，有這樣的服務，還是挺安心的。不過不知道樓主的用途哈，總的來說，如果是個人用戶的話，希捷酷魚硬碟從各方面來講都更適合一點，樓主可以對比後抉擇。

⑸ 以下哪些屬於集中化大數據平台外部採集數據

如何從0到1搭建大數據平台
大數據時代這個詞被提出已有10年了吧，越來越多的企業已經完成了大數據平台的搭建。隨著移動互聯網和物聯網的爆發，大數據價值在越來越多的場景中被挖掘，隨著大家都在使用歐冠大數據，大數據平台的搭建門檻也越來越低。藉助開源的力量，任何有基礎研發能力的組織完全可以搭建自己的大數據平台。但是對於沒有了解過大數據平台、數據倉庫、數據挖掘概念的同學可能還是無法順利完成搭建，因為你去網路查的時候會發現太多的東西，和架構，你不知道如何去選擇。今天給大家分享下大數據平台是怎麼玩的。

00 架構總覽

通常大數據平台的架構如上，從外部採集數據到數據處理，數據顯現，應用等模塊。

01 數據採集

用戶訪問我們的產品會產生大量的行為日誌，因此我們需要特定的日誌採集系統來採集並輸送這些日誌。Flume是目前常用的開源選擇，Flume是Cloudera提供的一個高可用的，高可靠的，分布式的海量日誌採集、聚合和傳輸的系統，Flume支持在日誌系統中定製各類數據發送方，用於收集數據；同時，Flume提供對數據進行簡單處理，並寫到各種數據接受方的能力。

02 數據存儲

無論上層採用何種的大規模數據計算引擎，底層的數據存儲系統基本還是以HDFS為主。HDFS（Hadoop Distributed File System）是Hadoop項目的核心子項目，是分布式計算中數據存儲管理的基礎。具備高容錯性、高可靠、高吞吐等特點。

HDFS存儲的是一個個的文本，而我們在做分析統計時，結構化會方便需要。因此，在HDFS的基礎上，會使用Hive來將數據文件映射為結構化的表結構，以便後續對數據進行類SQL的查詢和管理。

03 數據處理

數據處理就是我們常說的ETL。在這部分，我們需要三樣東西：計算引擎、調度系統、元數據管理。

對於大規模的非實時數據計算來講，目前一樣採用Hive和spark引擎。Hive是基於MapRece的架構，穩定可靠，但是計算速度較慢；Spark則是基於內存型的計算，一般認為比MapRece的速度快很多，但是其對內存性能的要求較高，且存在內存溢出的風險。Spark同時兼容hive數據源。從穩定的角度考慮，一般建議以Hive作為日常ETL的主要計算引擎，特別是對於一些實時要求不高的數據。Spark等其他引擎根據場景搭配使用。

實時計算引擎方面，目前大體經過了三代，依次是：storm、spark streaming、Flink。Flink已被阿里收購，大廠一直在推，社區活躍度很好，國內也有很多資源。

調度系統上，建議採用輕量級的Azkaban，Azkaban是由Linkedin開源的一個批量工作流任務調度器。https://azkaban.github.io/

一般需要自己開發一套元數據管理系統，用來規劃數據倉庫和ETL流程中的元數據。元數據分為業務元數據和技術元數據。

業務元數據，主要用於支撐數據服務平台Web UI上面的各種業務條件選項，比如，常用的有如下一些：移動設備機型、品牌、運營商、網路、價格範圍、設備物理特性、應用名稱等。這些元數據，有些來自於基礎數據部門提供的標准庫，比如品牌、價格範圍等，可以從對應的數據表中同步或直接讀取；而有些具有時間含義的元數據，需要每天通過ETL處理生成，比如應用信息。為支撐應用計算使用，被存儲在MySQL資料庫中；而對於填充頁面上對應的條件選擇的數據，則使用Redis存儲，每天/月會根據MySQL中的數據進行加工處理，生成易於快速查詢的鍵值對類數據，存儲到Redis中。
技術元數據，主要包括數據倉庫中的模型說明、血緣關系、變更記錄、需求來源、模型欄位信息等，詳細的可以查看數據分析師應該了解的數據倉庫(3)

04 數據流轉
通過上面一張圖了解數據採集，數據處理，到數據展現的數據流轉。通常我們在實際工作中，從數據源到分析報告或系統應用的過程中，主要包括數據採集同步、數據倉庫存儲、ETL、統計分析、寫入上層應用資料庫進行指標展示。這是最基礎的一條線，現在還有基於數據倉庫進行的數據分析挖掘工作，會基於機器學習和深度學習對已有模型數據進一步挖掘分析，形成更深層的數據應用產品。

05 數據應用
俗話說的好，「酒香也怕巷子深」。數據應用前面我們做了那麼多工作為了什麼，對於企業來說，我們做的每一件事情都需要體現出價值，而此時的數據應用就是大數據的價值體現。數據應用包括輔助經營分析的一些報表指標，商城上基於用戶畫像的個性化推送，還有各種數據分析報告等等。

數據採集系統
01 「大」數據

海量的數據

當你需要搭建大數據平台的時候一定是傳統的關系型資料庫無法滿足業務的存儲計算要求了，所以首先我們面臨的是海量的數據。

復雜的數據

復雜數據的概念和理想數據完全相反。所有數據集都有一定的復雜性，但有一些天生更難處理。通常這些復雜數據集沒有定義結構(沒有行列結構)，經常變化，數據質量很差。比如更新的網頁日誌，json數據，xml數據等。

高速的數據

高速數據通常被認為是實時的或是准實時的數據流。數據流本質上是在生成後就發給處理器的數據包，比如物聯網的穿戴設備，製造業的感測器，車聯網的終端晶元等等。處理實時數據流有很多挑戰，包括在採集時不丟失數據、處理數據流中的重復記錄、數據如何實時寫入磁碟存儲、以及如何進行實時分析。

02 採集工具
日誌採集

我們業務平台每天都會有大量用戶訪問，會產生大量的訪問日誌數據，比如電商系統的瀏覽，加入購物車，下訂單，付款等一系列流程我們都可以通過埋點獲取到用戶的訪問路徑以及訪問時長這些數據；再比智能穿戴設備，實時都會採集我們的血壓、脈搏、心率等數據實時上報到雲端。通過分析這些日誌信息，我們可以得到出很多業務價值。通過對這些日誌信息進行日誌採集、收集，然後進行數據分析，挖掘公司業務平台日誌數據中的潛在價值。為公司決策和公司後台伺服器平台性能評估提高可靠的數據保證。系統日誌採集系統做的事情就是收集日誌數據提供離線和在線的實時分析使用。目前常用的開源日誌收集系統有Flume、Logstash、Filebeat。可以根據自己公司的技術棧儲備或者組件的優缺點選擇合適的日誌採集系統，目前了解到的Flume使用的比較多。各個採集工具的對比如下：

具體組件的相關配置可以參考之前的文章《日誌收集組件—Flume、Logstash、Filebeat對比》

資料庫抽取

企業一般都會會使用傳統的關系型資料庫MySQL或Oracle等來存儲業務系統數據。每時每刻產生的業務數據，以資料庫一行記錄的形式被直接寫入到資料庫中保存。

大數據分析一般是基於歷史海量數據，多維度分析，我們不能直接在原始的業務資料庫上直接操作，因為分析的一些復雜SQL查詢會明顯的影響業務資料庫的效率，導致業務系統不可用。所以我們通常通過資料庫採集系統直接與企業業務後台資料庫伺服器結合，在業務不那麼繁忙的凌晨，抽取我們想要的數據到分析資料庫或者到HDFS上，最後有大數據處理系統對這些數據進行清洗、組合進行數據分析。

常用資料庫抽取工具：

阿里開源軟體：DataX
DataX 是一個異構數據源離線同步工具，致力於實現包括關系型資料庫(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各種異構數據源之間穩定高效的數據同步功能。開源的DataX貌似只能單機部署。

Apache開源軟體：Sqoop
Sqoop(發音:skup)是一款開源的工具，主要用於在HADOOP(Hive)與傳統的資料庫(mysql、postgresql...)間進行數據的傳遞，可以將一個關系型資料庫(例如 : MySQL ,Oracle ,Postgres等)中的數據導進到Hadoop的HDFS中，也可以將HDFS的數據導進到關系型資料庫中。可以集群化部署。

爬蟲爬取

有很多外部數據，比如天氣、IP地址等數據，我們通常會爬取相應的網站數據存儲。目前常用的爬蟲工具是Scrapy，它是一個爬蟲框架，提供給開發人員便利的爬蟲API介面。開發人員只需要關心爬蟲API介面的實現，不需要關心具體框架怎麼爬取數據。Scrapy框架大大降低了開發人員開發速率，開發人員可以很快的完成一個爬蟲系統的開發。

03 數據存儲
HDFS

2003年，Google發布論文GFS，啟發Apache Nutch開發了HDFS。2004年，Google 又發布了論文《MapRece: Simplified Data Processing on Large Clusters》，Doug Cutting等人實現計算框架MapRece ，並與HDFS結合來更好的支持該框架。2006年項目從Butch搜索引擎中獨立出來，成為了現在的Hadoop。

GFS隱藏了底層的負載均衡，切片備份等細節，使復雜性透明化，並提供統一的文件系統介面。其成本低，容錯高，高吞吐，適合超大數據集應用場景。

HDFS原理:橫向擴展，增加「數據節點」就能增加容量。
增加協調部門，「命名節點」維護元數據，負責文件系統的命名空間，控
外部訪問，將數據塊映射到數據節點。還會備份元數據從命名節點，它只與命名節點通信。
數據在多個數據節點備份。
通常關系型資料庫存儲的都是結構化的數據，我們抽取後會直接放到HDFS上作為離線分析的數據源。

HBase

在實際應用中，我們有很多數據可能不需要復雜的分析，只需要我們能存儲，並且提供快速查詢的功能。HBase在HDFS基礎上提供了Bigtable的能力; 並且基於列的模式進行存儲。列存儲設計的優勢是減少不必要的欄位佔用存儲，同時查詢的時候也可以只對查詢的指定列有IO操作。HBase可以存儲海量的數據，並且可以根據rowkey提供快速的查詢性能，是非常好的明細數據存儲方案，比如電商的訂單數據就可以放入HBase提供高效的查詢。

當然還有其他的存儲引擎，比如ES適合文本搜索查詢等。

04 總結
了解了上面的技術棧後，在實際數據接入中，你還會面臨各種問題，比如如何考慮確保數據一致性，保障數據不能丟失，數據採集存儲的效率，不能產生數據積壓等，這些都需要對每個組件進行研究，適配適合你自己業務系統的參數，用最少的資源，達到最好的結果。

調度系統
目前大數據平台經常會用來跑一些批任務，跑批處理當然就離不開定時任務。比如定時抽取業務資料庫的數據，定時跑hive/spark任務，定時推送日報、月報指標數據。任務調度系統已經儼然成為了大數據處理平台不可或缺的一部分，可以說是ETL任務的靈魂。

01 原始任務調度

記得第一次參與大數據平台從無到有的搭建，最開始任務調度就是用的Crontab，分時日月周，各種任務腳本配置在一台主機上。Crontab 使用非常方便，配置也很簡單。剛開始任務很少，用著還可以，每天起床巡檢一下日誌。隨著任務越來越多，出現了任務不能在原來計劃的時間完成，出現了上級任務跑完前，後面依賴的任務已經起來了，這時候沒有數據，任務就會報錯，或者兩個任務並行跑了，出現了錯誤的結果。排查任務錯誤原因越來麻煩，各種任務的依賴關系越來越復雜，最後排查任務問題就行從一團亂麻中，一根一根梳理出每天麻繩。crontab雖然簡單，穩定，但是隨著任務的增加和依賴關系越來越復雜，已經完全不能滿足我們的需求了，這時候就需要建設自己的調度系統了。

02 調度系統
調度系統，關注的首要重點是在正確的時間點啟動正確的作業，確保作業按照正確的依賴關系及時准確的執行。資源的利用率通常不是第一關注要點，業務流程的正確性才是最重要的。（但是到隨著業務的發展，ETL任務越來越多，你會發現經常有任務因為資源問題沒有按時啟動！）

實際調度中，多個任務單元之間往往有著強依賴關系，上游任務執行並成功，下游任務才可以執行。比如上游任務1結束後拿到結果，下游任務2、任務3需結合任務1的結果才能執行，因此下游任務的開始一定是在上游任務成功運行拿到結果之後才可以開始。而為了保證數據處理結果的准確性，就必須要求這些任務按照上下游依賴關系有序、高效的執行，最終確保能按時正常生成業務指標。

一款成熟易用，便於管理和維護的作業調度系統，需要和大量的周邊組件對接，要處理或使用到包括：血緣管理，許可權控制，負載流控，監控報警，質量分析等各種服務或事務。

03 調度系統分類
調度系統一般分為兩類：定時分片類作業調度系統和DAG工作流類作業調度系統

定時分片類作業調度系統

這種功能定位的作業調度系統，其最早的需要來源和出發點往往是做一個分布式的Crontab。

核心：

將一個大的任務拆成多個小任務分配到不同的伺服器上執行， 難點在於要做到不漏，不重，保證負載平衡，節點崩潰時自動進行任務遷移等。
保證任務觸發的強實時和可靠性
所以，負載均衡，彈性擴容，狀態同步和失效轉移通常是這類調度系統在架構設計時重點考慮的特性。

DGA工作流調度系統

這一類系統的方向，重點定位於任務的調度依賴關系的正確處理，分片執行的邏輯通常不是系統關注的核心，或者不是系統核心流程的關鍵組成部分。

核心：

足夠豐富和靈活的依賴觸發機制：比如時間觸發任務，依賴觸發任務，混合觸發任務
作業的計劃，變更和執行流水的管理和同步
任務的優先順序管理，業務隔離，許可權管理等
各種特殊流程的處理，比如暫停任務，重刷歷史數據，人工標註失敗／成功，臨時任務和周期任務的協同等
完備的監控報警通知機制
04 幾個調度系統
Airflow

Apache Airflow是一種功能強大的工具，可作為任務的有向無環圖（DAG）編排、任務調度和任務監控的工作流工具。Airflow在DAG中管理作業之間的執行依賴，並可以處理作業失敗，重試和警報。開發人員可以編寫Python代碼以將數據轉換為工作流中的操作。

主要有如下幾種組件構成：

web server: 主要包括工作流配置，監控，管理等操作
scheler: 工作流調度進程，觸發工作流執行，狀態更新等操作
消息隊列：存放任務執行命令和任務執行狀態報告
worker: 執行任務和匯報狀態
mysql: 存放工作流，任務元數據信息
具體執行流程：

scheler掃描dag文件存入資料庫，判斷是否觸發執行
到達觸發執行時間的dag,生成dag_run，task_instance 存入資料庫
發送執行任務命令到消息隊列
worker從隊列獲取任務執行命令執行任務
worker匯報任務執行狀態到消息隊列
schler獲取任務執行狀態，並做下一步操作
schler根據狀態更新資料庫
Kettle

將各個任務操作組件拖放到工作區，kettle支持各種常見的數據轉換。此外，用戶可以將Python，Java，JavaScript和SQL中的自定義腳本拖放到畫布上。kettle可以接受許多文件類型作為輸入，還可以通過JDBC，ODBC連接到40多個資料庫，作為源或目標。社區版本是免費的，但提供的功能比付費版本少。

XXL-JOB

XXL-JOB是一個分布式任務調度平台，其核心設計目標是開發迅速、學習簡單、輕量級、易擴展。將調度行為抽象形成「調度中心」公共平台，而平台自身並不承擔業務邏輯，「調度中心」負責發起調度請求；將任務抽象成分散的JobHandler，交由「執行器」統一管理，「執行器」負責接收調度請求並執行對應的JobHandler中業務邏輯；因此，「調度」和「任務」兩部分可以相互解耦，提高系統整體穩定性和擴展性。（後來才知道XXL是作者名字拼音首字母縮寫）

調度系統開源工具有很多，可以結合自己公司人員的熟悉程度和需求選擇合適的進行改進。

海豚調度

Apache DolphinScheler是一個分布式去中心化，易擴展的可視化DAG工作流任務調度平台。致力於解決數據處理流程中錯綜復雜的依賴關系，使調度系統在數據處理流程中開箱即用。

高可靠性
去中心化的多Master和多Worker服務對等架構, 避免單Master壓力過大，另外採用任務緩沖隊列來避免過載
簡單易用
DAG監控界面，所有流程定義都是可視化，通過拖拽任務完成定製DAG，通過API方式與第三方系統集成, 一鍵部署
豐富的使用場景
支持多租戶，支持暫停恢復操作. 緊密貼合大數據生態，提供Spark, Hive, M/R, Python, Sub_process, Shell等近20種任務類型
高擴展性
支持自定義任務類型，調度器使用分布式調度，調度能力隨集群線性增長，Master和Worker支持動態上下線
05 如何自己開發一個調度系統
調度平台其實需要解決三個問題：任務編排、任務執行和任務監控。

任務編排，採用調用外部編排服務的方式，主要考慮的是編排需要根據業務的一些屬性進行實現，所以將易變的業務部分從作業調度平台分離出去。如果後續有對編排邏輯進行調整和修改，都無需操作業務作業調度平台。
任務排隊，支持多隊列排隊配置，後期根據不同類型的開發人員可以配置不同的隊列和資源，比如面向不同的開發人員需要有不同的服務隊列，面向不同的任務也需要有不同的隊列優先順序支持。通過隊列來隔離調度，能夠更好地滿足具有不同需求的用戶。不同隊列的資源不同，合理的利用資源，達到業務價值最大化。
任務調度，是對任務、以及屬於該任務的一組子任務進行調度，為了簡單可控起見，每個任務經過編排後會得到一組有序的任務列表，然後對每個任務進行調度。這裡面，稍有點復雜的是，任務里還有子任務，子任務是一些處理組件，比如欄位轉換、數據抽取，子任務需要在上層任務中引用實現調度。任務是調度運行的基本單位。被調度運行的任務會發送到消息隊列中，然後等待任務協調計算平台消費並運行任務，這時調度平台只需要等待任務運行完成的結果消息到達，然後對作業和任務的狀態進行更新，根據實際狀態確定下一次調度的任務。
調度平台設計中還需要注意以下幾項：

調度運行的任務需要進行超時處理，比如某個任務由於開發人員設計不合理導致運行時間過長，可以設置任務最大的執行時長，超過最大時長的任務需要及時kill掉，以免佔用大量資源，影響正常的任務運行。
控制同時能夠被調度的作業的數量，集群資源是有限的，我們需要控制任務的並發量，後期任務上千上萬後我們要及時調整任務的啟動時間，避免同時啟動大量的任務，減少調度資源和計算資源壓力；
作業優先順序控制，每個業務都有一定的重要級別，我們要有限保障最重要的業務優先執行，優先給與調度資源分配。在任務積壓時候，先執行優先順序高的任務，保障業務影響最小化。
06 總結與展望
ETL 開發是數據工程師必備的技能之一，在數據倉庫、BI等場景中起到重要的作用。但很多從業者連 ETL 對應的英文是什麼都不了解，更不要談對 ETL 的深入解析，這無疑是非常不稱職的。做ETL 你可以用任何的編程語言來完成開發，無論是 shell、python、java 甚至資料庫的存儲過程，只要它最終是讓數據完成抽取（E）、轉化（T）、載入（L）的效果即可。由於ETL是極為復雜的過程，而手寫程序不易管理，所以越來越多的可視化調度編排工具出現了。

調度系統作為大數據平台的核心部分之一，牽扯的業務邏輯比較復雜，場景不同，也許需求就會差別很多，所以，有自研能力的公司都會選擇市面上開源系統二次開發或者完全自研一套調度系統，已滿足自身ETL任務調度需求。

不管是哪種工具，只要具備高效運行、穩定可靠、易於維護特點，都是一款好工具