At least onceってぶっちゃけ問題の先送りだったよね #kafkajp

At least onceってぶっちゃ け問題の先送りだったよね - Apache Kafka Meetup Japan #3 - @shoe116

アジェンダ 1. はじめに：自己紹介とsemanticsについて 2. 言い訳をするしかない状況についての共有と 謝罪 3. at least onceとETL苦労話 4. KIP-98, 129で解決すること、しないこと

1. はじめに

1.1 about me • 広告系→データ分析屋→HadoopでETL • 利用なう：Storm/Tez/Hive. Kafkaはconsume のみ • Java = Python > JavaScript > C++ • No Music, No Life. No Music, No Idol. • 課外活動はこちら • https://shoe116.tumblr.com/

• https://shoe116.tumblr.com/

1.2 semanticsについて 1. at least once(少なくとも1回) • 重複するかもしれないが、欠損はしない 2. at most once（最大1回） • 欠損するかもしれないが、重複はしない 3. exactly once（正確に1回） • 欠損も重複もしない • 分散システムだと実装が非常に困難

2. 言い訳をするしかない 状況についての共有と謝罪

• at least onceだと、ETLする側としては「重複をどうす るか問題」は避けられないし、カジュアルに頼まれます • ここでLTすることになった当時（6月上旬）では確かに kafkaはexactly onceをサポートしてなくて、かつて僕 はkafka由来の重複排除の仕組みを考えました • それが、6/30（現地時間）のkafka0.11のリリースで exactly once(KPI-98, 129)対応がされて、僕が作った モノとLTで話すネタはオワコン化した可能性が・・・ • exactly once semanticsの詳しい話したかったけど コードまでは読む時間なかったです、ごめんなさい • 噂によると懇親会中に実装の解説してくれるらしいよ

3. at least onceと 重複排除苦労話

3.1 弊社のデータパイプライン At Least Once At Least Once At Least Once producer (DC1) kafka (DC1) producer (DC2) kafka (DC2) producer (DC3) kafka (DC3) kafka (DC4) storm (DC4) TEZ (DC4) Hive (DC4) storm (DC5) TEZ (DC5) Hive (DC5) At Least Once kafka (DC5) At Least Once Exactly once ( & unify) Partitioning

3.2 重複排除の方法 1. kafkaのmessageにIDを埋めてproduce 2. HDFSにIDをkey, DATAをvalueにして write 3. TezでIDをkeyにshuffleして重複排除処理 ID: asdfghjkl;:] ID: asdfghjkl;:] Body: {aaa, bbb, ccc} ID: asdfghjkl;:] Body: {aaa, bbb, ccc} DATA: {aaa, bbb, ccc} kafka storm $ID $ID $ID $ID $ID $ID $ID $DATA $DATA $DATA $DATA $DATA $DATA $DATA HDFS TEZ $ID $ID $ID $ID $ID $DATA $DATA $DATA $DATA $DATA HDFS

3.2 重複排除にまつわる苦労話 1. 完全な意味での重複排除は困難 • 読み込める重複IDの量には限りがある • time windowを決めてその中で排除するしかない 2. パイプラインの正常稼働をどう担保するか • at least once = 件数はそのままor増える • 重複排除 = 件数はそのままor減る • 「件数が同じならOK」みたいな確認はできなくなる

4. KIP-98, 129で 解決すること、しないこと

4.1 KIP-98, 129で新規追加 1. Partition単位でのidempotentなproduce • producerでsequentialなIDを発行 • messageとともにIDをbrokerに送ってhandlingする 2. 複数partitionに対するtransactionalなwrite • ごくごく一般的なTwo-Phase Commit • producerがtransactionをbegin, commit, abort 3. 同一Kafka内でのexactly-once stream処理 • messageのsendとoffsetのcommitを1リクエストで行う

4.2 KIP-98, 129で解決しない 1. Exactly onceなKafka mirroring • MirrorMakerはクラスタをまたぐ • クラスタまたぎのTransactionは管理されない 2. Kafka以外のコンポーネントに書き出す場合 • これまで通り、書き出す側でのstateの管理が必要 3. オペレーション/実装のミスでmessageが ダブってproduceされる場合（当然）

関連資料 • https://archive.apache.org/dist/kafka/0.11.0.0/RELEASE_NOTES.html • https://www.confluent.io/blog/exactly-once-semantics-are-possibleheres-how-apache-kafka-does-it/ • https://cwiki.apache.org/confluence/display/KAFKA/KIP-98++Exactly+Once+Delivery+and+Transactional+Messaging

• https://archive.apache.org/dist/kafka/0.11.0.0/RELEASE_NOTES.html
• https://www.confluent.io/blog/exactly-once-semantics-are-possible-
• https://cwiki.apache.org/confluence/display/KAFKA/KIP-98 -