スライド中のURI - Kuduのインストール(Cloudera Manager使用) http://www.cloudera.com/documentation/betas/kudu/latest/topics/kudu_installation.html - Impala-Kuduのインストール(CDH5.8以前) http://www.cloudera.com/documentation/betas/kudu/latest/topics/kudu_impala.html#install_impala - Apache Kudu Troubleshooting http://kudu.apache.org/docs/troubleshooting.html - Apache Kudu project page http://kudu.apache.org/ - Cloudera Engineering Blog https://blog.cloudera.com/ - Kudu Design Docs https://github.com/apache/kudu/tree/master/docs/design-docs

1. 1 © Cloudera, Inc. All rights reserved.
Apache Kudu 構成とテーブル設計
矢野 智聡 / Cloudera株式会社
2016/11/08

2. 2 © Cloudera, Inc. All rights reserved.
自己紹介
• 矢野 智聡(やの ともあき)
• Customer Operations Engineer(テクニカルサポート)
• お客様がクラスタを運用する上での懸念や問題の解消を支援

3. © Cloudera, Inc. All rights reserved.
アジェンダ
• What’s Apache Kudu?
• ユースケース
• 構成要素と動作
• テーブルとパーティションの設計
• Kuduの関連情報

4. 4 © Cloudera, Inc. All rights reserved.
What’s Apache Kudu?
4

5. 5 © Cloudera, Inc. All rights reserved.
Apache Kudu
Storage for Fast AnalyHcs on Fast Data
• 更新可能なカラムナ
ストレージ
• Apache FoundaHonの
オープンソースプロジェクト
• Cloudera Managerで
管理可能(ベータ版)
Columnar Store
Kudu

6. 6 © Cloudera, Inc. All rights reserved.
HDFS with Parquet:
• 入力はバッチ処理に特化
• 分析時などの大規模データの
スキャンが高速
HBase :
• 個別のデータの入出力が高速
• データのアップデートが可能
更新可能なデータを高速に分析す
る基盤の不在
Hadoop エコシステムのストレージ関係図

7. 7 © Cloudera, Inc. All rights reserved.
スケーラブルで高速なテーブル指向のストレージ
• Scalable
• デザインとしては 数千ノード, 数十PBまでの拡張が可能
• Fast
• クラスタ上で百万単位のI/O処理が可能
• ノードあたり秒間数GB程度の読み込み性能
• Tabular
• SQL-like schema: 有限の型のある列(数十程度)の表(HBaseとは異なる)
• SQL (Impala/Spark/etc) と “NoSQL” APIs: Java/C++/Python でのアクセス
• ALTER TABLEによる高速なメタデータの変更

8. © Cloudera, Inc. All rights reserved. © Cloudera, Inc. All rights reserved.
他のエコシステムとのインテグレーション
Kudu は計算処理のためのフレームワークと協調して動作します
• インテグレーションのあるエコシステム
• Impala
• Spark
• MapReduce
• Flume
• Drill

9. 9 © Cloudera, Inc. All rights reserved.
ユースケース

10. 10 © Cloudera, Inc. All rights reserved.
Kuduのユースケース
Kudu はシーケンシャルな読み込みとランダムな読み込み、書き込み
処理が同時に発生するような状況に適している
● 時系列データ
○ 例: センサーデータ、連続的な市場データ、、
ネットワークモニタリング、不正検知/抑止など
○ 想定ワークロード: Insert, updates, scans, lookups
● オンラインレポーティング
○ 例: OperaHonal Data Store
○ 想定ワークロード: Inserts, updates, scans, lookups

11. 11 © Cloudera, Inc. All rights reserved.
Hadoop上でのストリーミングデータ分析の現状
不正検知システムでのストレージの複雑性
考慮点:
● Parquetへの変換処理の頻度
● レポート作成時の変換処理の完
了していないデータの扱い
● メンテナンスに対する可用性
新しいパーティション
最近のパーティション
過去のパーティション
HBase
Parquet
File
データの蓄積
を待機して
HBaseデータ
のParquetへの
変換
• 現在実行中の処理の待機
• 新しいParquetファイルを参照する
Impalaのパーティションの作成
入力データ
(Messaging)
Reporting
Impala on HDFS

12. 12 © Cloudera, Inc. All rights reserved.
Hadoop上でのストリーミングデータ分析とKudu
改善点:
● 単一システムでの処理
● Cronなどでのバックグラウンド処
理が不要
● 新しいデータが即時分析処理に
使用可能
過去のデータと
新しいデータ
入力データ
(Messaging)
Reporting
Request
Storage in Kudu

13. 13 © Cloudera, Inc. All rights reserved.
Xiaomiのユースケース
• 世界4位のスマートフォンメーカー
• モバイルアプリケーションとバックグラウンドサービスのイベント情報の収集
• サービスの監視とトラブルシューティング
◆ 高い書き込み要求
• >200億 records/day からさらに増大する流量
◆ 最新のデータに対するクエリ要件と応答速度
• 問題の特定と速やかな解決
◆ トラブルシューティングを容易にするための各行検索

14. 14 © Cloudera, Inc. All rights reserved.
Xiaomiのビッグデータ解析パイプライン
Kudu 導入前
• 処理の長時間化
データ変換における高レイテンシ(1 時間 ~ 1 日)
• 時系列でないデータ
ログの到着順は生成順とは異なることがある
例: 一日分のログのために2,3日分のログを処理する必要
がある

15. 15 © Cloudera, Inc. All rights reserved.
Xiaomiのビッグデータ解析パイプライン
Kudu導入後
• ETL 高速化(0~10s のレイテンシ)
アプリのためにデータの変換が必要な処理も高速化
• Kuduへの直接格納(no latency)
格納後即時処理可能
OLAP scan
Side table
lookup
Result store

16. © Cloudera, Inc. All rights reserved. 16
構成要素と動作

17. 17 © Cloudera, Inc. All rights reserved.
テーブル
• テーブルは複数のカラムから構成される
• カラムは下記のいずれかの型を取る必要がある
• BOOL, INT8, INT16, INT32, INT64, UNIXTIME_MICROS, FLOAT, DOUBLE,
STRING, BINARYカラムはNull値を取りうる
• カラムはbitshuffleなどでエンコーディングおよび圧縮が可能
• 圧縮形式はlz4, snappy, gzipが使用可能
• エンコーディングおよび圧縮は適用できない組み合わせがあるので注意

18. 18 © Cloudera, Inc. All rights reserved.
プライマリキー
• 全ての表でプライマリキーは必須
• プライマリキーは一つ以上の列の組み合わせ
• プライマリキーの値はユニークである必要がある
• プライマリキーには下記は使用できない
• Boolean または浮動小数点型
• Nullが含まれる列
• プライマリキーの値は更新できない
• プライマリキーのカラムは表のはじめの列に定義する

19. © Cloudera, Inc. All rights reserved. 19
タブレット/タブレットサーバ
• タブレットは表をパーティションで分割したもの
• 各タブレットはタブレットサーバによって管理される
• タブレットの分割にはプライマリキーの値を使用する
• 各列のハッシュ、レンジおよびその組み合わせを分割に使用可能
• タブレット毎にRad consensusによるN個のレプリカを持つ(default=3)
• レプリカのタブレットサーバは一つのリーダーと複数のフォロワーからなる
• 書き込みはリーダーに対してリクエストされる
• 各タブレットサーバのデータはローカルディスクにあり、他のレプリカとは独立し
ている

20. © Cloudera, Inc. All rights reserved.
ImpalaでのCreate tableの例
BIGINTのハッシュとSTRINGのRANGE
によるパーティショニング
Kuduの表とのマッピング

21. © Cloudera, Inc. All rights reserved. 21
Metadata/Master Server
• MetadataはMaster Serverに管理される
• 表の構成情報
• タブレットの構成情報
• タブレットサーバの死活監視やレプリケーション管理
• メタデータはメモリ上にキャッシュされる
• クライアントはマスターにアクセスし、アクセスするタブレットの情報を得る

22. © Cloudera, Inc. All rights reserved. 22
Client
‘tlipcon’ は table “T”に存在するか?
Tablet2(Tablet ServerはX,Y,Z)にある
そのうちリーダーはZ…
UPDATE tlipcon
SET col=foo
where id=‘tlipcon’
Updateの動作例

23. © Cloudera, Inc. All rights reserved. 23
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
1a. Client->Leader: Write() RPC
Rad Consensus

24. © Cloudera, Inc. All rights reserved. 24
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
Rad Consensus
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
2a. Leader writes local WAL
2b. Leader->Followers:
UpdateConsensus() RPC

25. © Cloudera, Inc. All rights reserved. 25
Rad Consensus
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
3. Follower: write WAL 3. Follower: write WAL

26. © Cloudera, Inc. All rights reserved. 26
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
Rad Consensus
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
4. Follower->Leader: success

27. © Cloudera, Inc. All rights reserved. 27
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
Rad Consensus
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
5. Leader has achieved majority

28. © Cloudera, Inc. All rights reserved. 28
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
Rad Consensus
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
6. Leader->Client: Success!

29. © Cloudera, Inc. All rights reserved. © Cloudera, Inc. All rights reserved. 29
書き込み (insert / update)
• Insertはメモリ上のrow storeに格納される
• フラッシュ時にParquetに似たカラムナフォーマットのBase Imageとして
ディスクに格納される
• Updateはメモリ上のdelta storeに格納される
• フラッシュ時にディスクにdelta filesとして格納される
• コンパクションにより以前に書き出されたBase Imageに適用される

30. © Cloudera, Inc. All rights reserved. 30
Kudu storage – Inserts and Flushes
MemRowSet
name pay role
DiskRowSet 1
name pay role
DiskRowSet 2
INSERT (“doug”, “$1B”, “Hadoop man”)
flush

31. © Cloudera, Inc. All rights reserved. 31
Kudu storage - Updates
MemRowSet
name pay role
DiskRowSet 1
name pay role
DiskRowSet 2
Delta MS
Delta MS
DiskRowSetはそれぞれ専
用のDeltaMemStoreをもち
updateはこちらで処理する
base data
base data

32. © Cloudera, Inc. All rights reserved. 32
Kudu storage – Updates
MemRowSet
name pay role
DiskRowSet 1
name pay role
DiskRowSet 2
Delta MS
Delta MS
UPDATE set pay=“$1M”
WHERE name=“todd”
Bloom says: no!
Bloom says: maybe!
150: col 1=$1M
base data
Bloom Filterを利用し
た絞り込み

33. © Cloudera, Inc. All rights reserved. 33
TS A
Tablet 1
(LEADER)
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL
耐障害性
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
TS C
Tablet 1
(FOLLOWER)
WAL
WAL WAL

34. © Cloudera, Inc. All rights reserved. 34
TS A
Tablet 1
(LEADER)
TS B
Tablet 1
(FOLLOWER)
WAL
WAL
耐障害性
?
TS A
Tablet 1
(LEADER)
Client
TS B
Tablet 1
(FOLLOWER)
WAL
WAL

35. © Cloudera, Inc. All rights reserved. © Cloudera, Inc. All rights reserved. 35
耐障害性(一時停止)
• フォロワーの一時的な停止:
1. リーダーは依然過半数の取得が可能なのでサービスを継続
2. 5分以内に起動すれば透過的に再度フォロワーとして加入
• リーダーの一時的な停止:
1. フォロワーは1.5秒毎のリーダーからのハートビートを待機
2. 3 回ハートビートがなかった場合: リーダーの再選出
新しいリーダーは数秒の内に選出される
3. 停止した元リーダーが5分以内に起動した場合はフォロワーとして加入
• N個のレプリカは (N-1)/2 までのタブレットサーバ停止に対応可

36. © Cloudera, Inc. All rights reserved. © Cloudera, Inc. All rights reserved. 36
耐障害性(永続停止)
1. リーダーが5分を閾値に検知
2. 該当のフォロワーを排除
3. マスターが新しいタブレットサーバーを選択
4. リーダーが新しいタブレットサーバーにデータをコピー
5. 新しいタブレットサーバーがフォロワーとして参加

37. © Cloudera, Inc. All rights reserved. © Cloudera, Inc. All rights reserved.
チューニングガイドライン
• タブレットサーバー毎のタブレットの数
• HWにもよるが、10-40程度
• タブレットのサイズ数百GiB程度
• SSDが使える場合はWALを優先的に割り当てる
• Diskが多く使えたり、SSDが使える場合はMaintenanceManagerのThread数
を増加させる(MaintenanceManager=Delta RowSetのコンパクションなどを
行うスレッド)
• パーティションは分割されないので設計が重要

38. © Cloudera, Inc. All rights reserved. 38
表とパーティションの設計

39. © Cloudera, Inc. All rights reserved. 39
時系列データの例
Series Time Value
us-east.appserver01.loadavg.1min 2016-05-09T15:14:30Z 0.44
us-east.appserver01.loadavg.1min 2016-05-09T15:14:40Z 0.53
us-west.dbserver03.rss 2016-05-09T15:14:30Z 1572864
us-west.dbserver03.rss 2016-05-09T15:15:00Z 2097152

40. © Cloudera, Inc. All rights reserved. 40
想定状況
• データ流入は各ソースの最新のtimestampのもの
• 読み込みは特定のシリーズの広範囲のtimestamp
SELECT time, value FROM timeseries
WHERE series = "us-west.dbserver03.rss"
AND time >= 2016-05-08T00:00:00;
クエリ例

41. © Cloudera, Inc. All rights reserved.
時刻のレンジによるパーティション

42. © Cloudera, Inc. All rights reserved.
時刻のレンジによるパーティション(inserts)
新しいデータは全て一つのタブレットへ

43. © Cloudera, Inc. All rights reserved.
時刻のレンジによるパーティション(scans)
多くのtimestampにまたがるクエリは
パーティション間で分散される

44. © Cloudera, Inc. All rights reserved.
ノードのレンジによるパーティション

45. © Cloudera, Inc. All rights reserved.
ノードのレンジによるパーティション(inserts)
Insertは複数のパーティションに分散される

46. © Cloudera, Inc. All rights reserved.
ノードのレンジによるパーティション(scans)
Scanは特定のパーティションに限定される

47. © Cloudera, Inc. All rights reserved.
ノードのレンジによるパーティション
特定のシリーズ(同一サービスのノード群など)で多くのデータが生
成されると流量が偏り、パーティションのサイズが偏る

48. © Cloudera, Inc. All rights reserved.
ノードのハッシュパーティション

49. © Cloudera, Inc. All rights reserved.
ノードのハッシュパーティション(inserts)
Insertは複数のパーティションに分散される
(Hashによる平均化も期待される)

50. © Cloudera, Inc. All rights reserved.
ノードのハッシュパーティション(scans)
Scanは特定のパーティションに限定される

51. © Cloudera, Inc. All rights reserved.
ノードのハッシュパーティション
関連するシリーズ(同一サービスのノード群など)のデー
タが分散されるので平均化されやすくなる

52. © Cloudera, Inc. All rights reserved.
時刻のレンジとノードハッシュ
時
刻
ノードハッシュ

53. © Cloudera, Inc. All rights reserved.
時刻のレンジとノードハッシュ(inserts)
Insertは最新のtimestampのパーティション間で分散される
時
刻
ノードハッシュ

54. © Cloudera, Inc. All rights reserved.
多くのtimestampにまたがるクエリは
パーティション間で分散される
時
刻
時刻のレンジとノードハッシュ(scans)
ノードハッシュ

55. © Cloudera, Inc. All rights reserved.
表とパーティション設計の考慮点
• プライマリキーにする列の検討
• 複数列とする場合の分割性能
• パーティションの種類と組み合わせの検討(Range/Hash)
• データ流入、更新パターンの検討/テスト
• アクセスパターンの検討/テスト
• Cloudera Managerで管理していれば処理実行時の負荷をチャートで把握可能

56. © Cloudera, Inc. All rights reserved. 56
Kuduの関連情報

57. © Cloudera, Inc. All rights reserved.
インストール情報
• Kuduのインストール(Cloudera Manager使用)
http://www.cloudera.com/documentation/betas/kudu/latest/topics/
kudu_installation.html
OSDのダウンロードと設置、Cloudera Manager Server再起動が必要なので
注意
• Impala-Kuduのインストール(CDH5.8以前)
http://www.cloudera.com/documentation/betas/kudu/latest/topics/
kudu_impala.html#install_impala
(CDH5.9以降のImpalaはKuduとのインテグレーションが組み込まれている)

58. © Cloudera, Inc. All rights reserved.
Kuduのトラブルシューティングと注意事項
• Apache Kudu Troubleshooting
http://kudu.apache.org/docs/troubleshooting.html
トラブルシューティング集、スパースファイルを処理するためのHole Punching
についてはLinux Kernelのバージョンとファイルシステムの要件があるので特
に注意
Linux: RHEL/CentOS 6.4 + patch or later, Ubuntu 14.04
FileSystem: XFS/Ext4

59. © Cloudera, Inc. All rights reserved.
Kuduの情報
• Apache Kudu project page
http://kudu.apache.org/
ドキュメントをはじめ各コミュニティ(slack, JIRA, mailing listなど)へのアクセス
方法やBlog形式でのWeekly Reportを確認できる
• Cloudera Engineering Blog
https://blog.cloudera.com/
今後の方針やパフォーマンステスト、ベストプラクティスなど

60. © Cloudera, Inc. All rights reserved.
Kuduの詳細情報
• Kudu Design Docs
https://github.com/apache/kudu/tree/master/docs/design-docs
Tabletのコンパクションやバックグラウンドでのメンテナンス処理、
APIなどのデザインについて情報がまとまっている

61. © Cloudera, Inc. All rights reserved.
まとめ
• Apache KuduはHadoopクラスタの新しいカラムナストレージエンジン
• タブレットサーバーによりデータが管理され、Raft consensus による
レプリケーション、耐障害性を備えている
• 使用用途によってはHDFS+ParquetやHBaseの方が適切なことはあるので
検討と検証が不可欠
• パフォーマンス維持と安定運用のためにはパーティションの設計が重要

62. © Cloudera, Inc. All rights reserved.
Thank you!