Upload
mapr-technologies-japan
View
287
Download
0
Embed Size (px)
Citation preview
®© 2016 MapR Technologies 1 ®© 2016 MapR Technologies 1 © 2016 MapR Technologies
®
Fast Data を扱うためのデザインパターン
Ian Downard, Technical Evangelist with MapR Portland Java ユーザーグループ 2016 年 10 月 18 日
®© 2016 MapR Technologies 2 ®© 2016 MapR Technologies 2
概要 • このプレゼンテーションでは Apache Kafka を紹介し、Kafka API の
使い方について説明します。また、Fast Data への適用のために Kafka パイプラインのスループットを最大化するための戦略についても解説します。
• 説明で使われているコード例はこちらで入手可能: github.com/iandow/design-patterns-for-fast-data.
®© 2016 MapR Technologies 3 ®© 2016 MapR Technologies 3
• Ian Downard は MapR の技術エバンジェリストで、開発者フレンドリーな MapR コンバージド・データ・プラットフォーム の使い方を生み出す活動に従事
• 個人ブログ: http://www.bigendiandata.com
• Twitter: https://twitter.com/iandownard
• GitHub: https://github.com/iandow
• LinkedIn: https://www.linkedin.com/in/iandownard
著者
®© 2016 MapR Technologies 4 ®© 2016 MapR Technologies 4
Kafka とは? • 分散 Publish-Subscribe 型メッセージングシステム • ディスク上にデータを格納 (“インメモリ” ではない) • 真のストリーミングをサポート (ただの高速バッチではない) • データストレージとデータ処理の両方に利用できる (ただのストレージ
ではない) • 小さいメッセージおよび動的なデータセット (いわゆる “ストリーム”) に
向いている
®© 2016 MapR Technologies 5 ®© 2016 MapR Technologies 5
サービス A
サービス B
サービス C
ログ
サービス 1
サービス 2
サービス 3
n 個の Producer m 個の Consumer
コネクションがいくつ必要か? n×m 個。もしどれかを再スタートすると多くのコネクションを復旧する必要がある。システムが大きくなるにつれデータパイプラインの管理が難しくなる
®© 2016 MapR Technologies 6 ®© 2016 MapR Technologies 6
サービス A
サービス B
サービス C
ログ
サービス 1
サービス 2
サービス 3
n 個の Producer m 個の Consumer
コネクションがいくつ必要か? n+m 個。Kafka はユニバーサルなメッセージバス。 単一障害点になるように見えるが、Kafka は冗長性を持つ分散システムでスケーラブル
®© 2016 MapR Technologies 7 ®© 2016 MapR Technologies 7
• 変化に柔軟、耐障害性、低遅延 – マイクロサービスアーキテクチャによく適合
• 少ない設備投資で済むビッグデータ向けメッセージングバス
• リアルタイム処理と短期ストレージの両方をサポート
• Kafka はサービス間通信の第一の選択肢になりつつある
Kafka の長所
®© 2016 MapR Technologies 8 ®© 2016 MapR Technologies 8
誰がデータをストリーミングしているか?
• 小売: 注文, 売上, 出荷, 価格調整
• 金融サービス: 株価, クレジットカード不正利用
• Web サイト: クリック, インプレッション, 検索, Web 不正クリック
• オペレーティングシステム: 機器のメトリクス, ログ
®© 2016 MapR Technologies 9 ®© 2016 MapR Technologies 9
ストリーミングデータセットの例 • ソーシャルメディア
– https://dev.twitter.com/streaming/overview • IoT
– https://data.sparkfun.com/streams/ に多くのサンプル – http://dweet.io はとてもイケてる
• サーバ: – /var/log/syslog – tcpdump
• 銀行 – Yahoo Finance API: https://github.com/cjmatta/TwitterStream,
http://meumobi.github.io/stocks%20apis/2016/03/13/get-realtime-stock-quotes-yahoo-finance-api.html
– NYSE 市場: http://www.nyxdata.com/Data-Products/Daily-TAQ • その他
– スクリーンスクレイピング
®© 2016 MapR Technologies 10 ®© 2016 MapR Technologies 10
®© 2016 MapR Technologies 11 ®© 2016 MapR Technologies 11
“テキストマイニングは自然言語処理技術のアプリケーションであり、関連情報を抽出するためのテキストデータ分析手法”
http://adilmoujahid.com/posts/2014/07/twitter-analytics/
®© 2016 MapR Technologies 12 ®© 2016 MapR Technologies 12
https://heroku.github.io/kafka-demo/
®© 2016 MapR Technologies 13 ®© 2016 MapR Technologies 13
● メッセージは <Key, Value> を含む ● 配信には順序がある ● バイト列として送信 (シリアライザ/デシリアライザを指定) ● TTL (生存期間, Time-To-Live) の期間保管される ● At least once セマンティクスに準じる
1 2 3 4 5 6 7 8
トピック “topic1” Consumer Producer
Consumer Producer
メッセージログ
®© 2016 MapR Technologies 14 ®© 2016 MapR Technologies 14
● Producer は1つずつメッセージを送信 ● Consumer はトピックを Subscribe してメッセージをポーリングし、
一度に複数のメッセージを受信
“topic1” Consumer Producer
Consumer Producer
1 2 3 4 5 6 7 8
メッセージログ
®© 2016 MapR Technologies 15 ®© 2016 MapR Technologies 15
● Producer はトピックを1つの論理オブジェクトとして扱う ● 個々のパーティション内のメッセージの順序は保証される
1 2 3 4
“topic1”, パーティション1
Producer 1 2 3 4
“topic1”, パーティション2
パーティショニング
®© 2016 MapR Technologies 16 ®© 2016 MapR Technologies 16
● 個々のパーティションは1つの Consumer だけが読むことができる ● パーティショニングにより Consumer の並列動作が可能になる ● 新しい Consumer は自動的にパーティションが割り当てられる
Producer 負荷分散されたConsumer
1 2 3 4
1 2 3 4
“topic1”, パーティション1
“topic1”, パーティション2
パーティショニング
®© 2016 MapR Technologies 17 ®© 2016 MapR Technologies 17
● コミットを呼び出すことで Consumer が処理を完了した場所を記録する
1 2 3 4 5 6 7 8
“topic1”, パーティション1
Consumer
commit (p1, o6)
コミット
®© 2016 MapR Technologies 18 ®© 2016 MapR Technologies 18
● コミットしてしまえば Consumer がクラッシュしても問題がない
1 2 3 4 5 6 7 8
“topic1”, パーティション1
Consumer
コミット
®© 2016 MapR Technologies 19 ®© 2016 MapR Technologies 19
● 別の Consumer が引き継いだときに、前の Consumer が中断したところから再開する
1 2 3 4 5 6 7 8
“topic1”, パーティション1
新しい Consumer
コミット
カーソル
®© 2016 MapR Technologies 20 ®© 2016 MapR Technologies 20
Kafka は Zookeeper に依存
• リーダー選出 – 各パーティションがリーダーを持つ
• クラスタメンバーシップ – ブローカーの稼働状況
• トピック設定 – トピック名、パーティション、レプリカ、TTL…
®© 2016 MapR Technologies 21 ®© 2016 MapR Technologies 21
デモ: Kafka CLI • トピックの作成、変更、Pub/Sub、削除 • トピックがどこに保存されるかを確認してください
®© 2016 MapR Technologies 22 ®© 2016 MapR Technologies 22
デモ: Java API • 基本的な Producer/Consumer の例
®© 2016 MapR Technologies 23 ®© 2016 MapR Technologies 23
デモ: Heroku Kafka-as-a-Service • デモアプリ:
– https://github.com/iandow/heroku-kafka-demo-java
• ドキュメントと価格: – https://devcenter.heroku.com/articles/kafka-on-heroku – $1,500/月 !!! – あ、でもクレジットの四捨五入があります
®© 2016 MapR Technologies 24 ®© 2016 MapR Technologies 24
デモ: Web アプリで Kafka を利用 • メッセージの送信方法
– 配信保証の実現方法 – 障害の対処方法
• 実演: – DemoResources.java の20秒のタイムアウトを変更 – java.util.concurrent を確認。ユーザ指定のコールバック内でタイムアウト – メッセージが最終的に到達するかどうかも確認 (送信中の場合)
• Dropwizard メトリクスを取り除くには、DemoApplication.java のタイムアウトを変更
– reporter.start(1, TimeUnit.MINUTES);
®© 2016 MapR Technologies 25 ®© 2016 MapR Technologies 25 © 2016 MapR Technologies © 2016 MapR Technologies
Consumer グループ、カーソル、パーティション
®© 2016 MapR Technologies 26 ®© 2016 MapR Technologies 26
ProducerRecord と ConsumerRecord の比較
• Producer は ProducerRecord としてメッセージを1つずつ送信
• Consumer はトピックを Subscribe してメッセージをポーリングし、ConsumerRecords として一度に複数のメッセージを受信
®© 2016 MapR Technologies 27 ®© 2016 MapR Technologies 27
Consumer グループ、カーソル、パーティション • Consumer グループ – 協調動作する Consumer のグループ
• カーソル – Consumer の位置を追跡
• パーティション – スケールさせるためにトピックを細分化
• レプリケーションファクター – 耐障害性のためにパーティションをノード間で複製する
®© 2016 MapR Technologies 28 ®© 2016 MapR Technologies 28
パーティションのバランシング • パーティションは同じグループに所属する Consumer 間でバランスされる
– 個々のパーティションは1つの Consumer だけが読むことができる – 個々の Consumer は複数のパーティションを読むことができる – 例:
• 3つのパーティション, 2つの Consumer: 2 と 1 • 5つのパーティション, 1つの Consumer: 5 • 3つのパーティション, 4つの Consumer: 1, 1, 1, 0 (4つ目の Consumer はメッセージを受信し
ない)
• 新しい Consumer が加わる、または新しいパーティションが追加される場合、再バランスが起こる – パーティションを獲得する、または失う Consumer があり、これが発生する時はメッ
セージの配信が少しの間停止する可能性がある – Consumer が正しくカーソルをコミットしていない場合は重複を引き起こす可能性があ
る
®© 2016 MapR Technologies 29 ®© 2016 MapR Technologies 29
Consumer グループ
• 個々のトピック/パーティションを同時に Consume できるのは、「同じグループ内では」1つの Consumer だけ
• 異なるグループに所属する Consumer であれば、同じトピック/パーティションを読んでいれば同じメッセージを見ることができる
http://kafka.apache.org/documentation.html
®© 2016 MapR Technologies 30 ®© 2016 MapR Technologies 30
カーソルの永続化
• Consumer が停止後、中断したところから読めることを保証 • メッセージを読んだことを示す最後のコミット位置を追跡 • デフォルトでは、5秒の自動コミット (auto.commit.interval.ms)
– 遅い Consumer コードの場合、処理完了前に自動 commit() が実行されてしまうかも – consumer.commit() で明示的にコミットすることが可能
• Consumer の並列実行が必要な場合、Consumer グループまたはトピックパーティションを使いますか?
8 7 6 5 4 3 2 1
トピック “topic1”
Consumer グループA
Consumer グループB
カーソルA
カーソルB
®© 2016 MapR Technologies 31 ®© 2016 MapR Technologies 31
At Least Once セマンティクス • メッセージは複数回現れる可能性がある
– Producer 側 • ネットワーク上での再送 • Producer が異常終了し、再開時にすでに送ったメッセージを再送する可能性がある
– Consumer 側 • クライアントがメッセージ取得後、cursor.commit() の前にクラッシュする可能性がある
• アプリケーションは冪等な (何回行っても結果が同じ) メッセージ処理コードでなくてはならない
®© 2016 MapR Technologies 32 ®© 2016 MapR Technologies 32
バッチの振る舞い • Producer.send() はクライアント側のメモリバッファにメッセージを置く
• 次の3つの条件のいずれかが満たされるまでは、このバッファはフラッシュされない: – タイムアウト (linger.ms) – メモリ上限 (buffer.memory) – Producer.flush() 呼び出し
®© 2016 MapR Technologies 33 ®© 2016 MapR Technologies 33
シリアライゼーション • 各 Kafka メッセージはバイト列
• <K,V> をバイト列にシリアライザで変換する必要がある
• 2つのシリアライザが提供されている: – ByteArraySerializer/ByteArrayDeserializer – StringSerializer/StringDeserializer
• 独自のシリアライザを実装することも可能
®© 2016 MapR Technologies 34 ®© 2016 MapR Technologies 34
基本的な考え方 – シリアライゼーション
• バイト列データをストリーミングする場合、ByteArraySerializer を使う
• String データをストリーミングする場合、StringSerializer を使う
• POJO データをストリーミングする場合、何を使う?
®© 2016 MapR Technologies 35 ®© 2016 MapR Technologies 35
POJO のストリーミング方法 1. Serializable にする
– これをしないと後でオブジェクトをバイト列に書き出すときに java.io.NotSerializableException が発生
2. オブジェクトをバイト列に書き出す 3. バイト列を送信
– なぜ Person オブジェクトをそのまま 送信できないのか?
4. Consumer でトピックをポーリングし、record.value() を POJO に変換する
もし Person オブジェクトからバイト列への変換を省略すると、Kafka がバイト列に変換しようとした時に SerializationException が発生
®© 2016 MapR Technologies 36 ®© 2016 MapR Technologies 36
POJO のストリーミングの問題 • もし生データに異常があり、ストリーミングした POJO フィールドの欠
損が原因でキャストが失敗したらどうなるか?
• POJO からバイト列またはその逆のエンコーコーディング/デコーディングのオーバーヘッドは冗長で、特に Kafka パイプラインの複数のステージで行われる場合はそれが顕著
• パースやキャストは下流の処理まで延期したほうがよい
®© 2016 MapR Technologies 37 ®© 2016 MapR Technologies 37
これをどのようにストリーミングするか? 080449201DAAT00000195700000103000N0000000000000004CT1000100710071007080449201DAAT00000131000000107000N0000000000000005CT10031007080449201DAAT00000066600000089600N0000000000000006CT10041005080449201DAAT00000180200000105100N0000000000000007CT100310051009080449201DAAT00000132200000089700N0000000000000008CT100410051005080449201DAAT00000093500000089400N0000000000000009CT10031007080449201DAAT00000075100000105400N0000000000000010CT100410081006080449201DAAT00000031300000088700N0000000000000011CT1004100810081007080449201DAAT00000021800000105100N0000000000000012CT100410091005080449201DAAT00000191300000104500N0000000000000013CT10041006080449201DAAT00000124500000105100N0000000000000014CT1001100610071008
®© 2016 MapR Technologies 38 ®© 2016 MapR Technologies 38
選択肢A? • 各レコードをパースして JSON オブジェクトにする • json_object.toString() を Publish • String シリアライザでストリーミング
下流の処理でフィールドへのアクセスが簡単 (開発者に優しい)。 しかし、多くのオブジェクトを作ることになり、オブジェクトはネイティブ型に比べてコストが高い
®© 2016 MapR Technologies 39 ®© 2016 MapR Technologies 39
選択肢B? • 各フィールドを属性として持つ
POJO (“Tick”) を作成 • 各レコードをパースして Tick オブ
ジェクトを作る • Tick オブジェクトを カスタムシリア
ライザを使ってストリーミング
パースのコストが高い。多くのオブジェクトを作ることになり、オブジェクトはネイティブ型に比べてコストが高い。多くの文字列を作ることになりメモリの利用効率が悪くなる可能性
®© 2016 MapR Technologies 40 ®© 2016 MapR Technologies 40
選択肢C? • 単一の byte[] 属性と、
byte[] のインデックスを直接計算してフィールドを返す Getter を持つ POJO “Tick” を作成
• @JsonProperty で Getter をアノテート
フィールドへのアクセスが簡単で、JSON オブジェクトの作成も容易。byte[] の検索が高速でパースを下流の処理に先送りできる。メモリ局所性が向上し、キャッシュのスラッシングを最小化する
®© 2016 MapR Technologies 41 ®© 2016 MapR Technologies 41
A
B
C
®© 2016 MapR Technologies 42 ®© 2016 MapR Technologies 42
性能に影響する主な要因 • レプリケーションが有効になっているか? • 大きなメッセージをストリーミングしているか? • Producer は同期送信しているか、非同期か? • 次の3つの条件のいずれかが満たされるまでは、バッファのフラッシュ
および送信は行われない: – タイムアウト (linger.ms) – メモリ上限 (buffer.memory) – Producer.flush() 呼び出し
• トピック / Producer 間のアフィニティ (関連付け)
®© 2016 MapR Technologies 43 ®© 2016 MapR Technologies 43
• 何が Producer のレイテンシに影響を及ぼすか? – send 機能 (同期送信) を利用? – acks=all,1,0 (リーダーがロギング後に ack / 全ての複製がロギング後 / ack なし) – ”Nagle アルゴリズム” と linger.ms 設定
• 何が Producer のスループットに影響を及ぼすか? – Producer の batch.size – producer.send() の並列呼び出し – トピック数 – メッセージサイズ
• 何が Consumer のスループットに影響を及ぼすか? – パーティション
性能に影響する主な要因
®© 2016 MapR Technologies 44 ®© 2016 MapR Technologies 44
性能に影響する主な要因 • 何が Kafka サーバの安定性に影響を及ぼすか?
– ガベージコレクション: 大きなメッセージの送信に伴う長い GC により Kafka/Zookeeper 接続が中断する可能性がある
– トピックは容易にディスク容量消費の原因となる – ファイルハンドラ上限を増やす必要性
• トピックデータとインデックスファイルは log.dir (例: /tmp/kafka-logs) に保存される • Kafka は各トピックのオープンファイルを保持する
– 参考: http://www.michael-noll.com/blog/2013/03/13/running-a-multi-broker-apache-kafka-cluster-on-a-single-node/
®© 2016 MapR Technologies 45 ®© 2016 MapR Technologies 45
読み込み並列性と処理並列性 • Consumer の読み込みの並列性
– 並列読み込みはトピックパーティションと Consumer グループにより実現できる
– Consumer ロジックが CPU の能力に依存する処理の場合、パーティションか Consumer グループを使う
• 下流の処理の並列性 – 読み込みスレッドよりも多くの処理スレッドが必要な場合、データを複数のト
ピックに“fan-out (展開)” する
®© 2016 MapR Technologies 46 ®© 2016 MapR Technologies 46
“Fan-out” とはどういうことか:
Kafka API
v v
SQL
15 分毎
デイトレード
取引情報を投入
取引情報の アーカイブ
マイクロサービス 送信者/受信者毎にインデックス
証券情報ストリーム
マイクロサービス STREAMING
https://www.mapr.com/appblueprint/overview
®© 2016 MapR Technologies 47 ®© 2016 MapR Technologies 47
性能上のアンチパターン • 問題: 各 Consumer スレッドで読んだ全てのメッセージの数をカウント
したい
• アンチパターン: synchronized ブロック内でカウンタを加算しよう
®© 2016 MapR Technologies 48 ®© 2016 MapR Technologies 48
性能上のアンチパターン • 各 Consumer スレッドで読んだ全てのメッセージの数をカウントしたい
• よし、synchronized ブロック内でカウンタを加算しよう
– 教訓: 同期処理はスループットに深刻な影響を与える – 解決策: 各スレッドにメトリクス構造体を用意し、1秒程度ごとにロックを使って
共有メトリクス構造体を更新することで、メトリクス収集のコストをほとんどゼロにまで削減
®© 2016 MapR Technologies 49 ®© 2016 MapR Technologies 49
性能上のアンチパターン • 重複メッセージを絶対読むことがないようにしたい
• よし、各メッセージを Consume するたびに読んだ位置をコミットしよう
®© 2016 MapR Technologies 50 ®© 2016 MapR Technologies 50
性能上のアンチパターン • 重複メッセージを絶対読むことがないようにしたい
• よし、各メッセージを Consume するたびに読んだ位置をコミットしよう
– 教訓: そのようにしても重複メッセージを読まないという保証はない。Kafka Consumer は冪等でなくてはならない
– 解決策: 重複排除は下流の処理まで延期 (つまり、あきらめて後でやる)
®© 2016 MapR Technologies 51 ®© 2016 MapR Technologies 51
性能上のアンチパターン • Spark での DB 格納とカラム選択をシンプルにするために、JSON 文
字列をストリーミングしたい
• よし、パイプラインの最初の段階ですべてのメッセージを JSON オブジェクトに変換して JSON シリアライザを使おう
®© 2016 MapR Technologies 52 ®© 2016 MapR Technologies 52
性能上のアンチパターン • Spark での DB 格納とカラム選択をシンプルにするために、JSON 文字列
をストリーミングしたい
• よし、パイプラインの最初の段階ですべてのメッセージを JSON オブジェクトに変換して JSON シリアライザを使おう
– 教訓: パースにはコストがかかる! パースエラーの扱いにはコストがかかる。カスタムシリアライザは思っていたほど簡単ではない
– このアンチパターンの解説はこちら: https://github.com/mapr-demos/finserv-ticks-demo/commit/35a0ddaad411bf7cec34919a4817482df2bf6462
– 解決策: 生データを保持する byte[] を含むデータ構造をストリーミングして、com.fasterxml.jackson.annotation.JsonProperty でアノテート
– 例: https://github.com/mapr-demos/finserv-ticks-demo/blob/35a0ddaad411bf7cec34919a4817482df2bf6462/src/main/java/com/mapr/demo/finserv/Tick2.java
®© 2016 MapR Technologies 53 ®© 2016 MapR Technologies 53
グッドプラクティス • Java または Scala 標準のコレクションクラス (例: HashMap) ではなく、
オブジェクト配列やプリミティブ型を使うようにデータ構造を設計 • トピックと Producer スレッド間のアフィニティを管理
– Kafka は複数の送信をまとめてバッチ送信する。もし送信先のトピックが1つだけなら、シーケンシャルなメモリ空間への書き込みによるメリットがある
– 参考コード: https://github.com/mapr-demos/finserv-application-blueprint/blob/master/src/test/java/com/mapr/demo/finserv/ThreadCountSpeedIT.java
• キーに文字列ではなく数値 ID もしくは列挙オブジェクトを使うことを考慮
®© 2016 MapR Technologies 54 ®© 2016 MapR Technologies 54
3つの性能上の知見 1. パイプラインでは最低限の処理を行う
– バイト列で転送すること。文字列や POJO のシリアライザや、カスタムシリアライゼーションよりも高速
2. JSON アノテーションを利用する。最終ステージでデータ格納が楽になる。簡易なスキーマが提供されるため、データ分析も容易になる
3. 生データを複数トピックのカテゴリに分ける (別名 “fan-out”)。リアルタイム分析が容易になる
4. Kafka をチューニングするために JUnit でパラメータ化テストを利用する
®© 2016 MapR Technologies 55 ®© 2016 MapR Technologies 55
デモ: JUnit で Kafka をチューニング
https://github.com/iandow/kafka_junit_tests
®© 2016 MapR Technologies 56 ®© 2016 MapR Technologies 56
JUnit パラメータ化テストの作成方法 1. テストクラスを @RunWith(Parameterized.class) でアノテート
2. テストデータセットとしてオブジェクトのコレクションを (Array として) 返す、@Parameters でアノテートされた public static メソッドを作成
3. テストデータの1"行"を引き受ける public なコンストラクタを作成
®© 2016 MapR Technologies 57 ®© 2016 MapR Technologies 57
ベンチマーク • LinkedIn の Jay Kreps による Lazy benchmark (2014年):
– https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines
• 次のような疑問への回答: – もしメッセージを Consume しなかったら Kafka は遅くなるのか? – (スループットを最大化するために) 小さいメッセージもしくは大きいメッセージ
のどちらをストリームすべきか?
®© 2016 MapR Technologies 58 ®© 2016 MapR Technologies 58
Kafka MapR Streams 標準 Kafka API 準拠 ✓ ✓ 数千トピックまでのスケール ✗ ✓ 大きなパーティションのクラスタノードをまたいだ自動展開
✗
✓
Consumer および Producer のミラークラスタ間フェールオーバー
✗ ✓
データセンター間のリアルタイムクラスタレプリケーション
✗ ✓
Kafka と MapR Streams の比較
®© 2016 MapR Technologies 59 ®© 2016 MapR Technologies 59
• MapR-FS から効率的な I/O パターンを継承、トピックはより多くのデータを保存し効率的に複製することが可能に
• トピックおよびパーティションの負荷分散がより効率的
• 複数データセンターのクラスタをまたいでトピックの利用が可能で、クラスタ間でオフセットを同期
• コア MapR プラットフォームから効率的な I/O パターンを継承
MapR Streams は Kafka よりスケーラブル
®© 2016 MapR Technologies 60 ®© 2016 MapR Technologies 60
コンバージド・アプリケーションのブループリントリアルタイム証券情報ストリーミング
Kafka API
v v
SQL
15 分毎
デイトレード
取引情報を投入
取引情報の アーカイブ
マイクロサービス 送信者/受信者毎にインデックス
証券情報ストリーム
マイクロサービス STREAMING
https://www.mapr.com/appblueprint/overview
®© 2016 MapR Technologies 61 ®© 2016 MapR Technologies 61
オープンソースエンジンおよびツール 商用エンジンおよびアプリケーション
エンタープライズグレードプラットフォームサービス
デー
タ
プロ
セッ
シン
グ
Web スケールストレージMapR-FS MapR-DB
Search and Others
リアルタイム 統合セキュリティ マルチテナント 災害復旧 グローバル名前空間高可用性
MapR Streams
クラウド・マネージドサービス
Search and Others
統合
管理
・監
視
検索その他
イベントストリーミングデータベース
カスタムアプリ
HDFS API POSIX, NFS HBase API JSON API Kafka API
MapR コンバージド・データ・プラットフォーム
®© 2016 MapR Technologies 62 ®© 2016 MapR Technologies 62
• Kafka と Spark Streaming についての記事をご覧ください • https://www.mapr.com/blog/real-time-streaming-data-pipelines-
apache-apis-kafka-spark-streaming-and-hbase
• Streaming Architecture 電子ブックをご覧ください • https://www.mapr.com/streaming-architecture-using-apache-kafka-
mapr-streams
• このプレゼンテーションとデモコードはこちら • https://github.com/iandow/design-patterns-for-fast-data
次のステップ:
®© 2016 MapR Technologies 63 ®© 2016 MapR Technologies 63
無料トレーニング à http://learn.mapr.com
®© 2016 MapR Technologies 64 ®© 2016 MapR Technologies 64
Q & A
@mapr @iandownard
Engage with us!
mapr-technologies