ジョブ内のKafkaとAVRO
Talendジョブでは、AVROフォーマットのデータを(非)シリアライズするためにAVROが提供するアプローチに反映されているように、Kafkaコンポーネント(通常のKafkaコンポーネント)とAVROのKafkaコンポーネントは、AVROデータを異なる方法で処理します。
- 通常のKafkaコンポーネントはJSON形式を読み書きします。KafkaがAVROデータを生成または消費する場合は、標準ジョブでスキーマレジストリーと共にProducerレコードとConsumerレコードを持つtKafkaInputとtKafkaOutputを使用できます。
- SparkフレームワークのKafkaコンポーネントはAVRO形式のデータを直接処理します。KafkaクラスターがAVROデータを生成し、消費する場合は、tKafkaInputAvroを使ってKafkaからデータを直接読み取り、tWriteAvroFieldsを使ってAVROデータをtKafkaOutputに送信します。
ただし、これらのコンポーネントはavro-toolsライブラリーによって作成されたAVROデータを処理しません。これは、avro-toolsライブラリーとAVROのコンポーネントが、AVROの提供するアプローチと同じアプローチを使わないためです。
AVRO形式のデータを(逆)シリアライズするためにAVROが提供する2つのアプローチは次のとおりです。
- AVROファイルは、各ファイルに埋め込まれたAVROスキーマを使用して生成されます（ org.apache.avro.file.{DataFileWriter/DataFileReader} ）。avro-toolsライブラリーはこのアプローチを使います。
- AVROレコードは、各レコードにスキーマを埋め込むことなく生成されます(org.apache.avro.io.{BinaryEncoder/BinaryDecoder}を使用)。AVROのKafkaコンポーネントは、このアプローチを使います。
この方法は、AVROでエンコードされたメッセージが常にKafkaトピックに書き込まれる場合に強く推奨されます。この方法では、すべてのメッセージにAVROスキーマを再び埋め込むためのオーバーヘッドが発生しないためです。AVROスキーマのサイズは比較的大きく、そのため、各メッセージにスキーマを埋め込むのは費用対効果が低い方法になります。他方、レコード(メッセージ)は通常小さいため、Spark Streamingを使ってデータをKafkaに読み書きする場合、これは他のアプローチに比べて大きな利点です。
2つのアプローチの出力を同じ読み書きの処理で混在させることはできません。