Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

Apache Kafka Meetup Japan #3 https://kafka-apache-jp.connpass.com/event/58619/ 発表資料

  • Login to see the comments

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

  1. 1. At least onceってぶっちゃ け問題の先送りだったよね - Apache Kafka Meetup Japan #3 - @shoe116
  2. 2. アジェンダ 1. はじめに:自己紹介とsemanticsについて 2. 言い訳をするしかない状況についての共有と 謝罪 3. at least onceとETL苦労話 4. KIP-98, 129で解決すること、しないこと
  3. 3. 1. はじめに
  4. 4. 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/
  5. 5. 1. at least once(少なくとも1回) • 重複するかもしれないが、欠損はしない 2. at most once(最大1回) •欠損するかもしれないが、重複はしない 3. exactly once(正確に1回) •欠損も重複もしない •分散システムだと実装が非常に困難 1.2 semanticsについて
  6. 6. 2. 言い訳をするしかない 状況についての共有と謝罪
  7. 7. • at least onceだと、ETLする側としては「重複をどうす るか問題」は避けられないし、カジュアルに頼まれます • ここでLTすることになった当時(6月上旬)では確かに kafkaはexactly onceをサポートしてなくて、かつて僕 はkafka由来の重複排除の仕組みを考えました • それが、6/30(現地時間)のkafka0.11のリリースで exactly once(KPI-98, 129)対応がされて、僕が作った モノとLTで話すネタはオワコン化した可能性が・・・ • exactly once semanticsの詳しい話したかったけど コードまでは読む時間なかったです、ごめんなさい • 噂によると懇親会中に実装の解説してくれるらしいよ
  8. 8. 3. at least onceと 重複排除苦労話
  9. 9. 3.1 弊社のデータパイプライン producer (DC1) kafka (DC4) storm (DC4) TEZ (DC4) Hive (DC4) kafka (DC1) producer (DC2) kafka (DC2) kafka (DC5) storm (DC5) TEZ (DC5) Hive (DC5) producer (DC3) kafka (DC3) At Least Once At Least Once Exactly once ( & unify) Partitioning At Least Once At Least Once At Least Once
  10. 10. 3.2 重複排除の方法 1. kafkaのmessageにIDを埋めてproduce 2. HDFSにIDをkey, DATAをvalueにして write 3. TezでIDをkeyにshuffleして重複排除処理 ID: asdfghjkl;:] Body: {aaa, bbb, ccc}ID: asdfghjkl;:] Body: {aaa, bbb, ccc}ID: asdfghjkl;:] DATA: {aaa, bbb, ccc} kafka storm HDFS $ID $DATA $ID $DATA $ID $DATA $ID $DATA $ID $DATA $ID $DATA $ID $DATA TEZ HDFS $ID $DATA $ID $DATA $ID $DATA $ID $DATA $ID $DATA
  11. 11. 3.2 重複排除にまつわる苦労話 1. 完全な意味での重複排除は困難 • 読み込める重複IDの量には限りがある • time windowを決めてその中で排除するしかない 2. パイプラインの正常稼働をどう担保するか • at least once = 件数はそのままor増える • 重複排除 = 件数はそのままor減る • 「件数が同じならOK」みたいな確認はできなくなる
  12. 12. 4. KIP-98, 129で 解決すること、しないこと
  13. 13. 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リクエストで行う
  14. 14. 4.2 KIP-98, 129で解決しない 1. Exactly onceなKafka mirroring •MirrorMakerはクラスタをまたぐ •クラスタまたぎのTransactionは管理されない 2. Kafka以外のコンポーネントに書き出す場合 • これまで通り、書き出す側でのstateの管理が必要 3. オペレーション/実装のミスでmessageが ダブってproduceされる場合(当然)
  15. 15. 関連資料 • https://archive.apache.org/dist/kafka/0.11.0.0/RELEASE_NOTES.html • https://www.confluent.io/blog/exactly-once-semantics-are-possible- heres-how-apache-kafka-does-it/ • https://cwiki.apache.org/confluence/display/KAFKA/KIP-98+- +Exactly+Once+Delivery+and+Transactional+Messaging

×