Flink實戰(八) - Streaming Connectors 程式設計

1 概覽

1.1 預定義的源和接收器

Flink內建了一些基本資料來源和接收器，並且始終可用。該預定義的資料來源包括檔案，目錄和插socket，並從集合和迭代器攝取資料。該預定義的資料接收器支援寫入檔案和標準輸入輸出及socket。

1.2 繫結聯結器

聯結器提供用於與各種第三方系統連線的程式碼。目前支援這些系統：

• Apache Kafka (source/sink)
• Apache Cassandra (sink)
• Amazon Kinesis Streams (source/sink)
• Elasticsearch (sink)
• Hadoop FileSystem (sink)
• RabbitMQ (source/sink)
• Apache NiFi (source/sink)
• Twitter Streaming API (source)
• Google PubSub (source/sink)

要在應用程式中使用其中一個聯結器，通常需要其他第三方元件，例如資料儲存或訊息佇列的伺服器。

雖然本節中列出的流聯結器是Flink專案的一部分，並且包含在源版本中，但它們不包含在二進位制分發版中。

1.3 Apache Bahir中的聯結器

Flink的其他流處理聯結器正在通過Apache Bahir釋出，包括：

• Apache ActiveMQ (source/sink)
• Apache Flume (sink)
• Redis (sink)
• Akka (sink)
• Netty (source)

1.4 其他連線到Flink的方法

1.4.1 通過非同步I / O進行資料渲染

使用聯結器不是將資料輸入和輸出Flink的唯一方法。一種常見的模式是在一個Map或多個FlatMap 中查詢外部資料庫或Web服務以渲染主資料流。

Flink提供了一個用於非同步I / O的API， 以便更有效，更穩健地進行這種渲染。

1.4.2 可查詢狀態

當Flink應用程式將大量資料推送到外部資料儲存時，這可能會成為I / O瓶頸。如果所涉及的資料具有比寫入更少的讀取，則更好的方法可以是外部應用程式從Flink獲取所需的資料。在可查詢的狀態介面，允許通過Flink被管理的狀態，按需要查詢支援這個。

2 HDFS聯結器

此聯結器提供一個Sink，可將分割槽檔案寫入任一Hadoop檔案系統支援的檔案系統 。

• 要使用此聯結器，請將以下依賴項新增到專案中：
  
  

請注意，流聯結器當前不是二進位制釋出的一部分

2.1 Bucketing File Sink

可以配置分段行為以及寫入，但我們稍後會介紹。這是可以建立一個預設情況下彙總到按時間拆分的滾動檔案的儲存槽的方法

• Java
  
• Scala
  

唯一必需的引數是儲存桶的基本路徑。可以通過指定自定義bucketer，寫入器和批量大小來進一步配置接收器。

預設情況下，當資料元到達時，分段接收器將按當前系統時間拆分，並使用日期時間模式"yyyy-MM-dd--HH"命名儲存區。這種模式傳遞給 DateTimeFormatter使用當前系統時間和JVM的預設時區來形成儲存桶路徑。使用者還可以為bucketer指定時區以格式化儲存桶路徑。每當遇到新日期時，都會建立一個新儲存桶。

例如，如果有一個包含分鐘作為最精細粒度的模式，將每分鐘獲得一個新桶。每個儲存桶本身都是一個包含多個部分檔案的目錄：接收器的每個並行例項將建立自己的部件檔案，當部件檔案變得太大時，接收器也會在其他檔案旁邊建立新的部件檔案。當儲存桶變為非活動狀態時，將重新整理並關閉開啟的部件檔案。如果儲存桶最近未寫入，則視為非活動狀態。預設情況下，接收器每分鐘檢查一次非活動儲存桶，並關閉任何超過一分鐘未寫入的儲存桶。setInactiveBucketCheckInterval()並 setInactiveBucketThreshold()在一個BucketingSink。

也可以通過指定自定義bucketer setBucketer()上BucketingSink。如果需要，bucketer可以使用資料元或元組的屬性來確定bucket目錄。

預設編寫器是StringWriter。這將呼叫toString()傳入的資料元並將它們寫入部分檔案，由換行符分隔。在a setWriter() 上指定自定義編寫器使用BucketingSink。如果要編寫Hadoop SequenceFiles，可以使用提供的 SequenceFileWriter，也可以配置為使用壓縮。

有兩個配置選項指定何時應關閉零件檔案並啟動新零件檔案：

• 通過設定批量大小（預設部件檔案大小為384 MB）
• 通過設定批次滾動時間間隔（預設滾動間隔為Long.MAX_VALUE）

當滿足這兩個條件中的任何一個時，將啟動新的部分檔案。看如下例子：

• Java
  
• Scala
  
• 這將建立一個接收器，該接收器將寫入遵循此模式的儲存桶檔案：
  
• Java
  
• 生成結果
  
• date-time是我們從日期/時間格式獲取的字串
• parallel-task是並行接收器例項的索引
• count是由於批處理大小或批處理翻轉間隔而建立的部分檔案的執行數
  

然而這種方式建立了太多小檔案，不適合HDFS！僅供娛樂！

3 Apache Kafka聯結器

3.1 簡介

此聯結器提供對Apache Kafka服務的事件流的訪問。

Flink提供特殊的Kafka聯結器，用於從/向Kafka主題讀取和寫入資料。Flink Kafka Consumer整合了Flink的檢查點機制，可提供一次性處理語義。為實現這一目標，Flink並不完全依賴Kafka的消費者群體偏移跟蹤，而是在內部跟蹤和檢查這些偏移。

為用例和環境選擇一個包（maven artifact id）和類名。對於大多數使用者來說，FlinkKafkaConsumer08（部分flink-connector-kafka）是合適的。

然後，匯入maven專案中的聯結器:

環境配置參考

3.2 ZooKeeper安裝及配置

• 下載zk
  http://archive.cloudera.com/cdh5/cdh/5/zookeeper-3.4.5-cdh5.15.1.tar.gz
• 配置系統環境
  
• 修改配置資料儲存路徑
  
• 啟動3.3 Kafka部署及測試假設你剛剛開始並且沒有現有的Kafka或ZooKeeper資料

由於Kafka控制檯指令碼對於基於Unix和Windows的平臺不同，因此在Windows平臺上使用bin  windows \而不是bin /，並將指令碼副檔名更改為.bat。

Step 1:下載程式碼

• 下載
  
• 解壓
  
• 配置環境變數
  
  
  
• 配置伺服器屬性
• 修改日誌儲存路徑
• 修改主機名

Step 2: 啟動伺服器

Kafka使用ZooKeeper，因此如果還沒有ZooKeeper伺服器，則需要先啟動它。

• 後臺模式啟動

Step 3: 建立一個主題

• 建立topic
  

Step 4: 傳送一些訊息

Kafka附帶一個命令列客戶端，它將從檔案或標準輸入中獲取輸入，並將其作為訊息傳送到Kafka叢集。 預設情況下，每行將作為單獨的訊息傳送。

執行生產者，然後在控制檯中鍵入一些訊息以傳送到伺服器。

• 啟動生產者
  

Step 5: 啟動一個消費者

Kafka還有一個命令列使用者，它會將訊息轉儲到標準輸出。

• 分屏，新建消費端
  
• 在不同的終端中執行上述每個命令，那麼現在應該能夠在生產者終端中鍵入訊息並看到它們出現在消費者終端中
  所有命令列工具都有其他選項; 執行不帶引數的命令將顯示更詳細地記錄它們的使用資訊。

3.4 Kafka 1.0.0+ Connector

從Flink 1.7開始，有一個新的通用Kafka聯結器，它不跟蹤特定的Kafka主要版本。 相反，它在Flink釋出時跟蹤最新版本的Kafka。

如果您的Kafka代理版本是1.0.0或更高版本，則應使用此Kafka聯結器。 如果使用舊版本的Kafka（0.11,0.10,0.9或0.8），則應使用與代理版本對應的聯結器。

相容性

通過Kafka客戶端API和代理的相容性保證，通用Kafka聯結器與較舊和較新的Kafka代理相容。 它與版本0.11.0或更高版本相容，具體取決於所使用的功能。

將Kafka Connector從0.11遷移到通用(V1.10新增）

要執行遷移，請參閱升級作業和Flink版本指南和

• 在整個過程中使用Flink 1.9或更新版本。
• 不要同時升級Flink和操作符。
• 確保您作業中使用的Kafka Consumer和/或Kafka Producer分配了唯一識別符號（uid）：
• 使用stop with savepoint功能獲取儲存點（例如，使用stop --withSavepoint）CLI命令。

用法

• 要使用通用Kafka聯結器，請為其新增依賴關係：
  
  然後例項化新源（FlinkKafkaConsumer）
  
  Flink Kafka Consumer是一個流資料來源，可以從Apache Kafka中提取並行資料流。 使用者可以在多個並行例項中執行，每個例項都將從一個或多個Kafka分割槽中提取資料。

Flink Kafka Consumer參與了檢查點，並保證在故障期間沒有資料丟失，並且計算處理元素“恰好一次”。（注意：這些保證自然會假設Kafka本身不會丟失任何資料。）

請注意，Flink在內部將偏移量作為其分散式檢查點的一部分進行快照。 承諾給Kafka的抵消只是為了使外部的進展觀與Flink對進展的看法同步。 這樣，監控和其他工作可以瞭解Flink Kafka消費者在多大程度上消耗了一個主題。

和接收器（FlinkKafkaProducer）。

除了從模組和類名中刪除特定的Kafka版本之外，API向後相容Kafka 0.11聯結器。

3.5 Kafka消費者

Flink的Kafka消費者被稱為FlinkKafkaConsumer08（或09Kafka 0.9.0.x等）。它提供對一個或多個Kafka主題的訪問。

建構函式接受以下引數：

• 主題名稱/主題名稱列表
• DeserializationSchema / KeyedDeserializationSchema用於反序列化來自Kafka的資料
• Kafka消費者的屬性。需要以下屬性：
  • “bootstrap.servers”（以逗號分隔的Kafka經紀人名單）
  • “zookeeper.connect”（逗號分隔的Zookeeper伺服器列表）（僅Kafka 0.8需要）
  • “group.id”消費者群組的ID
    
    

• 上述程式注意配置ip主機對映
• 虛擬機器hosts
  
• 本地機器 hosts
• 傳送訊息
  
• 執行程式消費訊息
  
  Example:
• Java
  
• Scala
  

The DeserializationSchema

Flink Kafka Consumer需要知道如何將Kafka中的二進位制資料轉換為Java / Scala物件。

在 DeserializationSchema允許使用者指定這樣的一個架構。T deserialize(byte[] message) 為每個Kafka訊息呼叫該方法，從Kafka傳遞值。

從它開始通常很有幫助AbstractDeserializationSchema，它負責將生成的Java / Scala型別描述為Flink的型別系統。實現vanilla的使用者DeserializationSchema需要自己實現該getProducedType(...)方法。

為了訪問Kafka訊息的鍵和值，KeyedDeserializationSchema具有以下deserialize方法T deserialize（byte [] messageKey，byte [] message，String topic，int partition，long offset）。

為方便起見，Flink提供以下模式：

• TypeInformationSerializationSchema（和TypeInformationKeyValueSerializationSchema）建立基於Flink的模式TypeInformation。如果Flink編寫和讀取資料，這將非常有用。此模式是其他通用序列化方法的高效能Flink替代方案。
• JsonDeserializationSchema（和JSONKeyValueDeserializationSchema）將序列化的JSON轉換為ObjectNode物件，可以使用objectNode.get（“field”）作為（Int / String / ...）（）從中訪問欄位。KeyValue objectNode包含一個“key”和“value”欄位，其中包含所有欄位，以及一個可選的“後設資料”欄位，用於公開此訊息的偏移量/分割槽/主題。
• AvroDeserializationSchema它使用靜態提供的模式讀取使用Avro格式序列化的資料。它可以從Avro生成的類（AvroDeserializationSchema.forSpecific(...)）中推斷出模式，也可以GenericRecords 使用手動提供的模式（with AvroDeserializationSchema.forGeneric(...)）。此反序列化架構要求序列化記錄不包含嵌入式架構。
  - 還有一個可用的模式版本，可以在Confluent Schema Registry中查詢編寫器的模式（用於編寫記錄的 模式）。使用這些反序列化模式記錄將使用從模式登錄檔中檢索的模式進行讀取，並轉換為靜態提供的模式（通過 ConfluentRegistryAvroDeserializationSchema.forGeneric(...)或ConfluentRegistryAvroDeserializationSchema.forSpecific(...)）。

要使用此反序列化模式，必須新增以下附加依賴項：

當遇到因任何原因無法反序列化的損壞訊息時，有兩個選項 - 從deserialize(...)方法中丟擲異常將導致作業失敗並重新啟動，或者返回null以允許Flink Kafka使用者以靜默方式跳過損壞的訊息。請注意，由於使用者的容錯能力（請參閱下面的部分以獲取更多詳細資訊），因此對損壞的訊息執行失敗將使消費者嘗試再次反序列化訊息。因此，如果反序列化仍然失敗，則消費者將在該損壞的訊息上進入不間斷重啟和失敗迴圈。

3.6 Kafka生產者

Flink的Kafka Producer被稱為FlinkKafkaProducer011（或010 對於Kafka 0.10.0.x版本。或者直接就是FlinkKafkaProducer，對於Kafka>=1.0.0的版本來說）。

它允許將記錄流寫入一個或多個Kafka主題。

自應用

• Pro
• 確保啟動埠
  
• Pro端生產訊息
  
• 消費端接收
  Example
• Java
  
• Scala
  

上面的示例演示了建立Flink Kafka Producer以將流寫入單個Kafka目標主題的基本用法。對於更高階的用法，還有其他建構函式變體允許提供以下內容：

• 提供自定義屬性
  生產者允許為內部的KafkaProducer提供自定義屬性配置。
• 自定義分割槽程式
  將記錄分配給特定分割槽，可以為FlinkKafkaPartitioner建構函式提供實現。將為流中的每個記錄呼叫此分割槽程式，以確定應將記錄傳送到的目標主題的確切分割槽。
• 高階序列化模式
  與消費者類似，生產者還允許使用呼叫的高階序列化模式KeyedSerializationSchema，該模式允許單獨序列化鍵和值。它還允許覆蓋目標主題，以便一個生產者例項可以將資料傳送到多個主題。

3.8 Kafka消費者開始位置配置

Flink Kafka Consumer允許配置如何確定Kafka分割槽的起始位置。

• Java
  
• Scala
  

Flink Kafka Consumer的所有版本都具有上述明確的起始位置配置方法。

• setStartFromGroupOffsets（預設行為）
  從group.idKafka代理（或Zookeeper for Kafka 0.8）中的消費者組（在消費者屬性中設定）提交的偏移量開始讀取分割槽。如果找不到分割槽的偏移量，auto.offset.reset將使用屬性中的設定。
• setStartFromEarliest()/ setStartFromLatest()
  從最早/最新記錄開始。在這些模式下，Kafka中的承諾偏移將被忽略，不會用作起始位置。
• setStartFromTimestamp(long)
  從指定的時間戳開始。對於每個分割槽，時間戳大於或等於指定時間戳的記錄將用作起始位置。如果分割槽的最新記錄早於時間戳，則只會從最新記錄中讀取分割槽。在此模式下，Kafka中的已提交偏移將被忽略，不會用作起始位置。

還可以指定消費者應從每個分割槽開始的確切偏移量：

• Java
  
• Scala
  

上面的示例將使用者配置為從主題的分割槽0,1和2的指定偏移量開始myTopic。偏移值應該是消費者應為每個分割槽讀取的下一條記錄。請注意，如果使用者需要讀取在提供的偏移量對映中沒有指定偏移量的分割槽，則它將回退到setStartFromGroupOffsets()該特定分割槽的預設組偏移行為（即）。

請注意，當作業從故障中自動恢復或使用儲存點手動恢復時，這些起始位置配置方法不會影響起始位置。在恢復時，每個Kafka分割槽的起始位置由儲存在儲存點或檢查點中的偏移量確定。

3.9 Kafka生產者和容錯

Kafka 0.8

在0.9之前，Kafka沒有提供任何機制來保證至少一次或恰好一次的語義。

Kafka 0.9和0.10

啟用Flink的檢查點時，FlinkKafkaProducer09和FlinkKafkaProducer010 能提供至少一次傳輸保證。

除了開啟Flink的檢查點，還應該配置setter方法：

• setLogFailuresOnly(boolean)
  預設為false。啟用此選項將使生產者僅記錄失敗日誌而不是捕獲和重新丟擲它們。這大體上就是計數已成功的記錄，即使它從未寫入目標Kafka主題。這必須設為false對於確保 至少一次
• setFlushOnCheckpoint(boolean)
  預設為true。啟用此函式後，Flink的檢查點將在檢查點成功之前等待檢查點時的任何動態記錄被Kafka確認。這可確保檢查點之前的所有記錄都已寫入Kafka。必須開啟，對於確保 至少一次

總之，預設情況下，Kafka生成器對版本0.9和0.10具有至少一次保證，即

setLogFailureOnly設定為false和setFlushOnCheckpoint設定為true。

預設情況下，重試次數設定為“0”。這意味著當setLogFailuresOnly設定為時false，生產者會立即失敗，包括Leader更改。
預設情況下，該值設定為“0”，以避免重試導致目標主題中出現重複訊息。對於經常更改代理的大多數生產環境，建議將重試次數設定為更高的值。
Kafka目前沒有生產者事務，因此Flink在Kafka主題裡無法保證恰好一次交付

Kafka >= 0.11

啟用Flink的檢查點後，FlinkKafkaProducer011

對於Kafka >= 1.0.0版本是FlinkKafkaProduce

可以提供準確的一次交付保證。

除了啟用Flink的檢查點，還可以通過將適當的語義引數傳遞給FlinkKafkaProducer011,選擇三種不同的運算元操作模式

• Semantic.NONE
  Flink啥都不保證。生成的記錄可能會丟失，也可能會重複。
• Semantic.AT_LEAST_ONCE（預設設定）
  
  類似於setFlushOnCheckpoint(true)在 FlinkKafkaProducer010。這可以保證不會丟失任何記錄（儘管它們可以重複）。
• Semantic.EXACTLY_ONCE
  使用Kafka事務提供恰好一次的語義。每當您使用事務寫入Kafka時，不要忘記為任何從Kafka消費記錄的應用程式設定所需的isolation.level（read_committed 或read_uncommitted- 後者為預設值）。

注意事項

Semantic.EXACTLY_ONCE 模式依賴於在從所述檢查點恢復之後提交在獲取檢查點之前啟動的事務的能力。如果Flink應用程式崩潰和完成重啟之間的時間較長，那麼Kafka的事務超時將導致資料丟失（Kafka將自動中止超過超時時間的事務）。考慮到這一點，請根據預期的停機時間適當配置事務超時。

Kafka broker預設 transaction.max.timeout.ms 設定為15分鐘。此屬性不允許為生產者設定大於其值的事務超時。

FlinkKafkaProducer011預設情況下，將_transaction.timeout.msproducer config_中的屬性設定為1小時，因此_transaction.max.timeout.ms_在使用 Semantic.EXACTLY_ONCE 模式之前應該增加 該屬性。

在_read_committed_模式中KafkaConsumer，任何未完成的事務（既不中止也不完成）將阻止來自給定Kafka主題的所有讀取超過任何未完成的事務。換言之，遵循以下事件順序：

1. 使用者事務1開啟並寫記錄
2. 使用者事務2開啟並寫了一些其他記錄
3. 使用者提交事務2

即使事務2已經提交了記錄，在事務1提交或中止之前，消費者也不會看到它們。這有兩個含義：

• 首先，在Flink應用程式的正常工作期間，使用者可以預期Kafka主題中生成的記錄的可見性會延遲，等於已完成檢查點之間的平均時間。
• 其次，在Flink應用程式失敗的情況下，讀者將阻止此應用程式編寫的主題，直到應用程式重新啟動或配置的事務超時時間過去為止。此註釋僅適用於有多個代理/應用程式寫入同一Kafka主題的情況。

Semantic.EXACTLY_ONCE 模式為每個FlinkKafkaProducer011例項使用固定大小的KafkaProducers池。每個檢查點使用其中一個生產者。如果併發檢查點的數量超過池大小，FlinkKafkaProducer011 將引發異常並將使整個應用程式失敗。請相應地配置最大池大小和最大併發檢查點數。
Semantic.EXACTLY_ONCE 採取所有可能的措施，不要留下任何阻礙消費者閱讀Kafka主題的延遲事務，這是必要的。但是，如果Flink應用程式在第一個檢查點之前失敗，則在重新啟動此類應用程式後，系統中沒有關於先前池大小的資訊。因此，在第一個檢查點完成之前按比例縮小Flink應用程式是不安全的 FlinkKafkaProducer011.SAFE_SCALE_DOWN_FACTOR。

3.10 Kafka消費者及其容錯

啟用Flink的檢查點後，Flink Kafka Consumer將使用主題中的記錄，並以一致的方式定期檢查其所有Kafka偏移以及其他 運算元操作的狀態。如果作業失敗，Flink會將流式程式恢復到最新檢查點的狀態，並從儲存在檢查點中的偏移量開始重新使用來自Kafka的記錄。

因此，繪製檢查點的間隔定義了程式在發生故障時最多可以返回多少。

檢查點常用引數

enableCheckpointing

啟用流式傳輸作業的檢查點。 將定期快照流式資料流的分散式狀態。 如果發生故障，流資料流將從最新完成的檢查點重新啟動。

該作業在給定的時間間隔內定期繪製檢查點。 狀態將儲存在配置的狀態後端。

此刻未正確支援檢查點迭代流資料流。 如果“force”引數設定為true，則系統仍將執行作業。

setCheckpointingMode

setCheckpointTimeout

setMaxConcurrentCheckpoints

要使用容錯的Kafka使用者，需要在執行環境中啟用拓撲的檢查點：

• Scala
  
• Java
  

另請注意，如果有足夠的處理插槽可用於重新啟動拓撲，則Flink只能重新啟動拓撲。因此，如果拓撲由於丟失了TaskManager而失敗，那麼之後仍然必須有足夠的可用插槽。YARN上的Flink支援自動重啟丟失的YARN容器。

如果未啟用檢查點，Kafka使用者將定期向Zookeeper提交偏移量。

參考

Streaming Connectors

Kafka官方文件