系統日誌採集哪些數據

㈠ 系統日誌採集是大數據收集的主要來源之一對嗎

是。
數據的採集主要來源是日誌，日誌是用戶在網站上產生的一些行為信息。
應用程序日誌一方面記錄各種程序執行狀況，一方面記錄用戶的操作軌跡。

㈡ 日誌審計能夠採集同個ip不同數據嗎

日誌審計能夠採集同個ip不同數據。日誌審計能夠實時不間斷地採集匯聚企業中不同廠商不同種類的安全設備、網路設備、主機、操作系統、用戶業務系統的日誌信息。日誌審計系統是用於全面收集企業IT系統中常見的安全設備。

㈢ 採集數據 參數種類

採集數據參數種類是：Web數據（包括網頁、視頻、音頻、動畫、圖片等）、日誌數據、資料庫數據、其它數據。

1、web數據採集：網路數據採集是指通過網路爬蟲或網站公開 API 等方式從網站上獲取數據信息的過程。

網路會從一個或若干初始網頁的 URL 開始，獲得各個網頁上的內容，並且在抓取網頁的過程中，不斷從當前頁面上抽取新的 URL 放入隊列，直到滿足設置的停止條件為止。

2、系統日誌採集：系統日誌採集主要是收集公司業務平台日常產生的大量日誌數據，供離線和在線的大數據分析系統使用。

3、資料庫採集：傳統企業會使用傳統的關系型資料庫 MySQL 和 Oracle 等來存儲數據。

4、其他數據：感知設備數據採集是指通過感測器、攝像頭和其他智能終端自動採集信號、圖片或錄像來獲取數據。

數據源數據同步種類是：

1、直接數據源同步：是指直接的連接業務資料庫，通過規范的介面（如JDBC）去讀取目標資料庫的數據。這種方式比較容易實現，但是如果業務量比較大的數據源，可能會對性能有所影響。

2、生成數據文件同步：是指從數據源系統現生成數據文件，然後通過文件系統同步到目標資料庫里。

3、資料庫日誌同步：是指基於源資料庫的日誌文件進行同步。現在大多數資料庫都支持生成數據日誌文件，並且支持用數據日誌文件來恢復數據。因此可以使用這個數據日誌文件來進行增量同步。

㈣ 以下哪個不是系統日誌採集方法

系統日誌採集方法。
1、先右擊計算機，點擊管理然後點擊事件查看器的三角形圖標，再點擊「windows日誌」，接著打開「時間屬性」窗口。
2、查看當前日誌常規和詳細信息。
3、資料庫採集系統日誌採集。
4、網路數據採集，感知設備數據採集。
資料庫採集指使用關系型資料庫MySQL和Oracle等來存儲數據。

㈤ 大數據中的日誌數據包括哪些

日誌數據的類型包括：1.錯誤日誌(errorlog)；2.慢查詢日誌(slow query log) ；3.一般查詢日誌(general log)；4.二進制日誌(binlog)；5.中繼日誌(relay log)；。
日誌一般分成Undo與Redo：Undo一般用於事務的取消與回滾，記錄的是數據被修改前的值；Redo一般用於恢復已確認但未寫入資料庫的數據，記錄的是數據修改後的值。例如：資料庫忽然斷電重啟，資料庫啟動時一般要做一致性檢查，會把已寫到Redo的數據但未寫入資料庫的數據重做一遍。
大數據以容量大、類型多、存取速度快、應用價值高為主要特徵的數據集合，最早應用於IT行業，目前正快速發展為對數量巨大、來源分散、格式多樣的數據進行採集、存儲和關聯分析，從中發現新知識、創造新價值、提升新能力的新一代信息技術和服務業態。大數據必須採用分布式架構，對海量數據進行分布式數據挖掘，因此必須依託雲計算的分布式處理、分布式資料庫和雲存儲、虛擬化技術。

㈥ 「SpringCloud」（三十八）搭建ELK日誌採集與分析系統

 一套好的日誌分析系統可以詳細記錄系統的運行情況，方便我們定位分析系統性能瓶頸、查找定位系統問題。上一篇說明了日誌的多種業務場景以及日誌記錄的實現方式，那麼日誌記錄下來，相關人員就需要對日誌數據進行處理與分析，基於E(ElasticSearch)L(Logstash)K(Kibana)組合的日誌分析系統可以說是目前各家公司普遍的首選方案。

  作為微服務集群，必須要考慮當微服務訪問量暴增時的高並發場景，此時系統的日誌數據同樣是爆發式增長，我們需要通過消息隊列做流量削峰處理，Logstash官方提供Redis、Kafka、RabbitMQ等輸入插件。Redis雖然可以用作消息隊列，但其各項功能顯示不如單一實現的消息隊列，所以通常情況下並不使用它的消息隊列功能；Kafka的性能要優於RabbitMQ，通常在日誌採集，數據採集時使用較多，所以這里我們採用Kafka實現消息隊列功能。
  ELK日誌分析系統中，數據傳輸、數據保存、數據展示、流量削峰功能都有了，還少一個組件，就是日誌數據的採集，雖然log4j2可以將日誌數據發送到Kafka，甚至可以將日誌直接輸入到Logstash，但是基於系統設計解耦的考慮，業務系統運行不會影響到日誌分析系統，同時日誌分析系統也不會影響到業務系統，所以，業務只需將日誌記錄下來，然後由日誌分析系統去採集分析即可，Filebeat是ELK日誌系統中常用的日誌採集器，它是 Elastic Stack 的一部分，因此能夠與 Logstash、Elasticsearch 和 Kibana 無縫協作。

軟體下載：

  因經常遇到在內網搭建環境的問題，所以這里習慣使用下載軟體包的方式進行安裝，雖沒有使用Yum、Docker等安裝方便，但是可以對軟體目錄、配置信息等有更深的了解，在後續採用Yum、Docker等方式安裝時，也能清楚安裝了哪些東西，安裝配置的文件是怎樣的，即使出現問題，也可以快速的定位解決。

Elastic Stack全家桶下載主頁： https://www.elastic.co/cn/downloads/

我們選擇如下版本：

Kafka下載：

  安裝前先准備好三台CentOS7伺服器用於集群安裝，這是IP地址為：172.16.20.220、172.16.20.221、172.16.20.222，然後將上面下載的軟體包上傳至三台伺服器的/usr/local目錄。因伺服器資源有限，這里所有的軟體都安裝在這三台集群伺服器上，在實際生產環境中，請根據業務需求設計規劃進行安裝。
  在集群搭建時，如果能夠編寫shell安裝腳本就會很方便，如果不能編寫，就需要在每台伺服器上執行安裝命令，多數ssh客戶端提供了多會話同時輸入的功能，這里一些通用安裝命令可以選擇啟用該功能。

新建/usr/local/java目錄

將下載的jdk軟體包jdk-8u64-linux-x64.tar.gz上傳到/usr/local/java目錄，然後解壓

配置環境變數/etc/profile

在底部添加以下內容

使環境變數生效

備註：後續可通過此命令停止elasticsearch運行

  新建kafka的日誌目錄和zookeeper數據目錄，因為這兩項默認放在tmp目錄，而tmp目錄中內容會隨重啟而丟失,所以我們自定義以下目錄:

修改如下：

在data文件夾中新建myid文件，myid文件的內容為1（一句話創建：echo 1 > myid）

kafka啟動時先啟動zookeeper，再啟動kafka；關閉時相反，先關閉kafka，再關閉zookeeper。
1、zookeeper啟動命令

後台運行啟動命令：

或者

查看集群狀態：

2、kafka啟動命令

後台運行啟動命令：

或者

3、創建topic，最新版本已經不需要使用zookeeper參數創建。

參數解釋:
復制兩份
--replication-factor 2
創建1個分區
--partitions 1
topic 名稱
--topic test

4、查看已經存在的topic（三台設備都執行時可以看到）

5、啟動生產者：

6、啟動消費者：

添加參數 --from-beginning 從開始位置消費，不是從最新消息

7、測試：在生產者輸入test，可以在消費者的兩台伺服器上看到同樣的字元test，說明Kafka伺服器集群已搭建成功。

Logstash沒有提供集群安裝方式，相互之間並沒有交互，但是我們可以配置同屬一個Kafka消費者組，來實現統一消息只消費一次的功能。

  Filebeat用於安裝在業務軟體運行伺服器，收集業務產生的日誌，並推送到我們配置的Kafka、Redis、RabbitMQ等消息中間件，或者直接保存到Elasticsearch，下面來講解如何安裝配置：

1、進入到/usr/local目錄，執行解壓命令

2、編輯配置filebeat.yml
  配置文件中默認是輸出到elasticsearch，這里我們改為kafka，同文件目錄下的filebeat.reference.yml文件是所有配置的實例，可以直接將kafka的配置復制到filebeat.yml

後台啟動命令

停止命令

2、測試logstash是消費Kafka的日誌主題，並將日誌內容存入Elasticsearch

自動新增的兩個index，規則是logstash中配置的

數據瀏覽頁可以看到Elasticsearch中存儲的日誌數據內容，說明我們的配置已經生效。

Gitee: GitEgg: GitEgg 是一款開源免費的企業級微服務應用開發框架，旨在整合目前主流穩定的開源技術框架，集成常用的最佳項目解決方案，實現可直接使用的微服務快速開發框架。
GitHub: https://github.com/wmz1930/GitEgg

㈦ 數據類信息資源有哪些主要類型簡述各類資源的來源

是存就有關科研數據、教們,包括各種統計數據、實驗數據、臨床檢驗數據等數值型信息的資料庫。
數據主要三大來源：（1）大量人群產生的海量數據；（2）企業應用產生的數據；（3）巨量機器產生的數據。
數據採集的方法：（1）系統日誌採集；（2）互聯網數據採集；（3）APP移動端數據採集；（4）與數據服務機構進行合作。
數據採集流程：數據採集在明確數據來源之後，可以根據特定行業與應用定位，確定採集的數據范圍與數量， 並通過核實的數據採集方法，開展後續的數據採集工作。

㈧ 地點形式的地圖信息採集有哪些

1、通過系統日誌採集大數據。用於地圖信息採集的工具常見的有很多，常見的為ClouderaFlume、FacebookScribe和LinkedInKafka等。這些工具是分布式架構，滿足每秒數百MB的日誌數據採集和傳輸需求。
2、通過網路進行地圖數據採集。主要指通過網路爬蟲或者網站公開API等方式從網站上獲取大量數據信息方式，將網站上非結構化的數據抽取出來，採用結構化的方法，同意儲存在本地，支持圖片、音頻、視頻、文字等多種形式的素材採集。
3、通過其他數據採集方法。生產和業務數據或學術研究數據，如更高數據的保密性要求，可以通過與企業或者研究機構合作，使用特定系統介面等相關方式採集數據。

㈨ 電腦里的日誌有什麼作用查看的是哪些內容

作用就是記錄系統（程序）運行的狀態。打開開始菜單,然後在開始菜單中點擊控制面板選項即可查看了。

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

如何從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任務調度需求。

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