前言
隨著大數據近幾年的發(fā)展，已經在國內外的開發(fā)市場積累出一大批大數據開發(fā)的技術型人才，不論是批處理還是流處理各大公司都研究出一套專門解決自身公司業(yè)務的大數據解決方案。它們是市面上大數據組件的融合碰撞產生的適合自身的。
在數據處理的最前端一定是數據的采集技術，數據的采集技術也是百家爭鳴，一片藍海，對于一個優(yōu)秀的大數據開發(fā)工程師，我們怎么將這些技術棧靈活的應用，前提是我們要對其認真的研究，理解其最佳的應用場景，今天我來帶大家認識5種數據采集工具。
1、Flume
適用場景
適合用于日志數據的采集
Flume是Cloudera提供的一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸的系統(tǒng)，Flume支持在日志系統(tǒng)中定制各類數據發(fā)送方，用于收集數據；同時，Flume提供對數據進行簡單處理，并寫到各種數據接受方（可定制）的能力。
當前Flume有兩個版本Flume 0.9X版本的統(tǒng)稱Flume-og，Flume1.X版本的統(tǒng)稱Flume-ng。由于Flume-ng經過重大重構，與Flume-og有很大不同，使用時請注意區(qū)分。
工作方式
Flume-og采用了多Master的方式。為了保證配置數據的一致性，Flume引入了ZooKeeper，用于保存配置數據，ZooKeeper本身可保證配置數據的一致性和高可用，另外，在配置數據發(fā)生變化時，ZooKeeper可以通知Flume Master節(jié)點。Flume Master間使用gossip協(xié)議同步數據。
Flume-ng最明顯的改動就是取消了集中管理配置的 Master 和 Zookeeper，變?yōu)橐粋€純粹的傳輸工具。Flume-ng另一個主要的不同點是讀入數據和寫出數據由不同的工作線程處理（稱為 Runner）。 在 Flume-og 中，讀入線程同樣做寫出工作（除了故障重試）。如果寫出慢的話（不是完全失?。鼘⒆枞?Flume 接收數據的能力。這種異步的設計使讀入線程可以順暢的工作而無需關注下游的任何問題。
2、Flink CDC
適用場景
CDC 是變更數據捕獲（Change Data Capture）技術的縮寫，它可以將源數據庫（Source）的增量變動記錄，同步到一個或多個數據目的（Sink）。在同步過程中，還可以對數據進行一定的處理，例如分組（GROUP BY）、多表的關聯（JOIN）等。例如對于電商平臺，用戶的訂單會實時寫入到某個源數據庫；A 部門需要將每分鐘的實時數據簡單聚合處理后保存到 Redis 中以供查詢，B 部門需要將當天的數據暫存到 Elasticsearch 一份來做報表展示，C 部門也需要一份數據到 ClickHouse 做實時數倉。隨著時間的推移，后續(xù) D 部門、E 部門也會有數據分析的需求，這種場景下，傳統(tǒng)的拷貝分發(fā)多個副本方法很不靈活，而 CDC 可以實現一份變動記錄，實時處理并投遞到多個目的地。下圖是一個示例，通過騰訊云 Oceanus 提供的 Flink CDC 引擎，可以將某個 MySQL 的數據庫表的變動記錄，實時同步到下游的 Redis、Elasticsearch、ClickHouse 等多個接收端。這樣大家可以各自分析自己的數據集，互不影響，同時又和上游數據保持實時的同步。
工作方式
目前 Flink CDC 支持兩種數據源輸入方式。
（一）輸入 Debezium 等數據流進行同步
例如 MySQL -> Debezium -> Kafka -> Flink -> PostgreSQL。適用于已經部署好了 Debezium，希望暫存一部分數據到 Kafka 中以供多次消費，只需要 Flink 解析并分發(fā)到下游的場景。
（二）直接對接上游數據庫進行同步
我們還可以跳過 Debezium 和 Kafka 的中轉，使用 Flink CDC Connectors（https://github.com/ververica/flink-cdc-connectors）對上游數據源的變動進行直接的訂閱處理。從內部實現上講，Flink CDC Connectors 內置了一套 Debezium 和 Kafka 組件，但這個細節(jié)對用戶屏蔽，因此用戶看到的數據鏈路如下圖所示：
3、Sqoop
適用場景
Sqoop(發(fā)音：skup)是一款開源的工具，主要用于在Hadoop(Hive)與傳統(tǒng)的數據庫(mysql、postgresql…)間進行數據的傳遞，可以將一個關系型數據庫（例如 ： MySQL ,Oracle ,Postgres等）中的數據導進到Hadoop的HDFS中，也可以將HDFS的數據導進到關系型數據庫中。
Sqoop項目開始于2009年，最早是作為Hadoop的一個第三方模塊存在，后來為了讓使用者能夠快速部署，也為了讓開發(fā)人員能夠更快速的迭代開發(fā)，Sqoop獨立成為一個Apache項目。
工作方式
Sqoop的優(yōu)點:
- 可以高效、可控的利用資源，可以通過調整任務數來控制任務的并發(fā)度。
- 可以自動的完成數據映射和轉換。由于導入數據庫是有類型的，它可以自動根據數據庫中的類型轉換到Hadoop中，當然用戶也可以自定義它們之間的映射關系。
- 支持多種數據庫，如mysql，orcale等數據庫。
sqoop工作的機制:
將導入或導出命令翻譯成MapReduce程序來實現在翻譯出的MapReduce中主要是對InputFormat和OutputFormat進行定制。
sqoop版本介紹:sqoop1和sqoop2
sqoop的版本sqoop1和sqoop2是兩個不同的版本，它們是完全不兼容的。
4、Canal
適用場景
Canal是阿里巴巴旗下的一款開源項目，用Java開發(fā)。
對數據庫日志增量解析，提供增量數據的實時同步，目前支持MySQL
工作方式
- canal 模擬 MySQL slave 的交互協(xié)議，偽裝成 MySQL slave ，向 MySQL master 發(fā)送dump 協(xié)議
- MySQL master 收到 dump 請求，開始推送 binary log 給 slave (即 canal )
- canal 解析binary log 對象(原始為 byte 流)----->kafka等
5、Kettle
適用場景
Kettle最早是一個開源的ETL工具，全稱為KDE Extraction, Transportation, Transformation and Loading Environment。在2006年，Pentaho公司收購了Kettle項目，原Kettle項目發(fā)起人Matt Casters加入了Pentaho團隊，成為Pentaho套件數據集成架構師；從此，Kettle成為企業(yè)級數據集成及商業(yè)智能套件Pentaho的主要組成部分，Kettle亦重命名為Pentaho Data Integration 。Pentaho公司于2015年被Hitachi Data Systems收購。
Pentaho Data Integration以Java開發(fā)，支持跨平臺運行，其特性包括：支持100%無編碼、拖拽方式開發(fā)ETL數據管道；可對接包括傳統(tǒng)數據庫、文件、大數據平臺、接口、流數據等數據源；支持ETL數據管道加入機器學習算法。
Pentaho Data Integration分為商業(yè)版與開源版，開源版的截止2021年1月的累計下載量達836萬，其中19%來自中國 。在中國，一般人仍習慣把Pentaho Data Integration的開源版稱為Kettle。
文章來源：http://www.zghlxwxcb.cn/news/detail-430070.html
工作方式
ETL（Extract-Transform-Load的縮寫，即數據抽取、轉換、裝載的過程），對于企業(yè)或行業(yè)應用來說，我們經常會遇到各種數據的處理，轉換，遷移，所以了解并掌握一種etl工具的使用，必不可少，這里我介紹一個我在工作中使用了3年左右的ETL工具Kettle,本著好東西不獨享的想法，跟大家分享碰撞交流一下！在使用中我感覺這個工具真的很強大，支持圖形化的GUI設計界面，然后可以以工作流的形式流轉，在做一些簡單或復雜的數據抽取、質量檢測、數據清洗、數據轉換、數據過濾等方面有著比較穩(wěn)定的表現，其中最主要的我們通過熟練的應用它，減少了非常多的研發(fā)工作量，提高了我們的工作效率。文章來源地址http://www.zghlxwxcb.cn/news/detail-430070.html
到了這里，關于猿創(chuàng)征文｜大數據開發(fā)必備的數據采集工具匯總的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
