Cloudera, Inc. 共同創設者兼CTO: Amr AwadallahによるCloudera World Tokyo 2015の講演資料です

1. 1
©
Cloudera,
Inc.
All
rights
reserved.
新製品Kudu 及びRecordService の概要
セキュリティ強化 + ファストデータの⾼高速分析
Amr Awadallah | Cloudera 共同創業者、CTO
Twitter: @awadallah

2. 2
©
Cloudera,
Inc.
All
rights
reserved.
現在のセキュリティアーキテクチャ: 統⼀一性の⽋欠如 = 限定的なアクセス
HDFS
Hive
ポリシー A
Hive
しかしその⼀一⽅方で ...
細かな制約を
サポートするエンジンも存在 ...
統⼀一的でよりきめ細かな
ポリシーの提供
RecordService とは
総合的なアクセスコントロールの適⽤用
MapReduce
(テーブルレベル)
RecordService
(ポリシー適⽤用)
Impala
Sentry
(ポリシー定義)
Sentry
(ポリシー定義)
...
Impala
(カラムレベル)
HDFS HDFS
Spark MR
Spark
(テーブルレベル)

3. 3
©
Cloudera,
Inc.
All
rights
reserved.
アジェンダ
Kudo とは？ (動機と⽬目標)
ユースケース
デザインと内部構造概要
簡単なベンチマーク
現状、そしてこれから始めるには

4. 4
©
Cloudera,
Inc.
All
rights
reserved.
Kudu とは ?

5. 5
©
Cloudera,
Inc.
All
rights
reserved.
Hadoop の現状のストレージランドスケープ
HDFS の優位点:
• ⼤大量量データの効率率率的なスキャン
• ⾼高スループットでデータを蓄積
HBase の優位点:
• 各⾏行行に対する効率率率的な検索索と書き込み
• データは変更更可能
こうした特性が同時に必要な場合、ギャップ
が発⽣生する
Hadoop の
ストレージに
存在する「ギャップ」

6. 6
©
Cloudera,
Inc.
All
rights
reserved.
• ⼤大規模なスキャンを⾼高スループットで実⾏行行
• 低レイテンシでランダムアクセスを実⾏行行
• ⾼高いCPUパフォーマンスを確保するため、RAMと
フラッシュの優位性を活⽤用
• １カラムのスキャンレートを、HBase の 10~∼100倍⾼高速に
• ⾼高効率率率 I/O
• 型独⾃自のエンコーディングによる、カラムストア
• 特定のカラムにアクセスする場合の効率率率的な分析
• 叙述的（Expressive）で進化可能なデータモデル
• マルチデータセンター運⽤用が可能なアーキテクチャ
Kudu の設計⽬目標

7. 7
©
Cloudera,
Inc.
All
rights
reserved.
ハードウェアのランドスケープを変える
• HDD → SSD
• NAND フラッシュ: iops: 最⼤大 450k (read), 250k (write), スループット: 約 2GB/sec (read), 1.5GB/sec (write)
価格は $3/GB 以下でさらに低下する傾向
• 3D XPoint memory (NAND の 1,000倍⾼高速。RAMよりも低価格)
• RAM は価格が低下し、容量量は増加
• 過去の数年年で 64 → 128 → 256GB 以上に
結論 1 :
次のボトルネックは CPU に発⽣生する。現状のストレージシステムは
CPUの効率率率を考慮して設計されていない
結論 2:
ランダムアクセスには、カラムストアがふさわしい

8. 8
©
Cloudera,
Inc.
All
rights
reserved.
Kuduの概要
ファストデータに対する⾼高速分析のためのストレージ
• Hadoop向けの新たなカラムストア
• 更更新されるデータに対する分析アプリ
ケーション構築のためのアーキテクチャを
シンプル化
• ⾼高速分析を実⾏行行するためのデザイン
• Hadoopとネイティブに統合
• Apacheライセンスオープンソース
（ASFインキュベータ提案中）
• ベータ版が利利⽤用可能
ファイルシステム
HDFS
NoSQL
HBASE
インジェスト – SQOOP, FLUME, KAFKA
データ統合とストレージ
セキュリティ – SENTRY
リソース管理理 – YARN
統合データサービス
バッチ ストリーム SQL 検索索 モデル オンライン
データエンジニアリング データディスカバリと分析 データアプリ
SPARK,
HIVE, PIG
SPARK IMPALA SOLR SPARK HBASE
リレーショナル
KUDU

9. 9
©
Cloudera,
Inc.
All
rights
reserved.
Kudu を使う
• テーブルは SQLライクなスキーマを持っている
• 無限数のカラム（HBase/Cassandraとは異異なる）
• タイプ: BOOL, INT8, INT16, INT32, INT64, FLOAT, DOUBLE, STRING, BINARY,
TIMESTAMP
• カラムの⼀一部はパッシブリー複合主キー(possibly-‐‑‒composite primary key) を形成
• ⾼高速 ALTER TABLE
• Java および C++ “NoSQL” スタイルの API
• Insert(), Update(), Delete(), Scan()
• MapReduce, Spark, and Impala との統合
• 乞うご期待！
9

10. 10
©
Cloudera,
Inc.
All
rights
reserved.
Kudu は何ではないか
• SQL インタフェースそのものではない
• ストレージレイヤに過ぎない － 「SQLは⾃自分で⽤用意」（例例えば Impala や Spark）
• HDFS上で稼働するアプリケーションではない
• ネイティブな Hadoop ストレージエンジン
• HDFSと共存させるのが望ましい
• HDFSやHBase を置き換えるものではない
• 適切切なユースケースに適切切なストレージを選択
• Cloudera はこれらを引き続きサポート、投資する

11. 11
©
Cloudera,
Inc.
All
rights
reserved.
Kudu のユースケース

12. 12
©
Cloudera,
Inc.
All
rights
reserved.
Kudu ユースケース
Kudu は、シーケンシャルとランダム READ/WRITE を同時に組み合わせて使⽤用する
といったユースケースに最適。例例えば:
● 時系列列
○ 例例: ストリームマーケットデータ、不不正アクセス検知・防御、リスクモニタリング
○ ワークロード: Insert, Update, Scan, Lookup
● マシンデータの分析
○ 例例: ネットワークへの侵⼊入の検知
○ ワークロード: Insert, Scan, Lookup
● オンラインレポーティング
○ 例例: ODS
○ ワークロード: Insert, Update, Scan, Lookup

13. 13
©
Cloudera,
Inc.
All
rights
reserved.
業界適⽤用例例
• ストリーミングマーケット
データ
• リアルタイム不不正検知と防御
• リスクモニタリング
• リアルタイム商品提案
• ローケーションベース
ターゲティング
• 地理理空間モニタリング
• リスクおよび侵⼊入の検知
（リアルタイム）
⾦金金融サービス ⼩小売 公共

14. 14
©
Cloudera,
Inc.
All
rights
reserved.
現在の Hadoop のリアルタイム分析
実世界における不不正検知 ＝ ストレージが複雑になりがち
考慮点:
● プロセス実⾏行行中に障害が発⽣生した
場合の対処⽅方法は？
● レポーティング⽤用フォーマットに、
どの程度度の頻度度でストリーミング
データを再構成し投⼊入すればよい
のか？
● レポーティングする場合、データ
がまだ再構成されていないことを
どう確認すればよいのか？
● 重要なジョブがメンテナンスで
停⽌止しないようにするには？
新規のパーティション
直近⽤用のパーティション
過去データ
HBase
Parquet
File
⼗十分にデータが
蓄積されたか ?
HBase ファイル
をParquet に
再構成
• 実⾏行行処理理の完了了を待機
• 新しく書き込まれた Parquet ファイルを
参照し、新規 Impalaパーティションを定義
⼊入⼒力力データ
(メッセージング
システム)
レポーティング
リクエスト
Impala on HDFS

15. 15
©
Cloudera,
Inc.
All
rights
reserved.
Kuduを使⽤用したHadoop のリアルタイム分析
ハイブリッドアプリーチに⽐比べ、シンブルでより優れたパフォーマンスのアーキテクチャ
Impala on Kudu
⼊入⼒力力データ
(メッセージング
システム)
レポーティング
リクエスト

16. 16
©
Cloudera,
Inc.
All
rights
reserved.
デザインと内部構造

17. 17
©
Cloudera,
Inc.
All
rights
reserved.
Kudu の基本的なデザイン
• 型付けされた (typed) ストレージ
• 基本構造: テーブル
• テーブルはタブレットに分解される (ほぼパーティションと同義）
• Paxos に似たクォーラムモデル (Raft) により、⼀一貫性を維持
• 地理理的に離離れた、アクティブ/アクティブなシステムをサポートするアーキテクチャ

18. 18
©
Cloudera,
Inc.
All
rights
reserved.
テーブルとタブレット
• テーブルはパーティションに⽔水平分割される
• 範囲パーティショニング または ハッシュパーティショニング
• プライマリキー（ホスト、メトリック、タイムスタンプ）は、ハッシュ（タイムスタンプ）により
100以上のバケットに分散
• 各タブレットは Raft コンセンサスで、N個（3または５）の複製を持つ
• 任意のレプリカからの読み込み、低いMTTRでリーダ主導の書き込みが可能
• タブレットサーバがタブレットを保持する
• データはローカルディスクに保存（HDFSは不不要）
18

19. 19
©
Cloudera,
Inc.
All
rights
reserved.
クライアント
メタキャッシュ

20. 20
©
Cloudera,
Inc.
All
rights
reserved.
Client
Meta
Cache
「todd@cloudera.com の⾏行行はテーブルTのど
こにありますか？」(Masterに尋ねる)

21. 21
©
Cloudera,
Inc.
All
rights
reserved.
クライアント
メタキャッシュ
「todd@cloudera.com の⾏行行はテーブルTのど
こにありますか？」(Masterに尋ねる)
サーバ {Z,Y,X} の タブレット2にあります。
さらに、他のタブレット:T1,T2,T3, ... についての情
報もあります

22. 22
©
Cloudera,
Inc.
All
rights
reserved.
クライアント
「todd@cloudera.com の⾏行行はテーブルTのど
こにありますか？」(Masterに尋ねる)
サーバ {Z,Y,X} の タブレット2にあります。
さらに、他のタブレット:T1,T2,T3, ... についての情
報もあります
メタキャッシュ
T1: …
T2: …
T3: …

23. 23
©
Cloudera,
Inc.
All
rights
reserved.
クライアント
UPDATE
todd@cloudera.com
SET …
メタキャッシュ
T1: …
T2: …
T3: …
「todd@cloudera.com の⾏行行はテーブルTのど
こにありますか？」(Masterに尋ねる)
サーバ {Z,Y,X} の タブレット2にあります。
さらに、他のタブレット:T1,T2,T3, ... についての情
報もあります

24. 24
©
Cloudera,
Inc.
All
rights
reserved.
タブレットのデザイン
• インメモリストアにInsertがバッファされる（HBaseの memstore と同様）
• ディスクにフラッシュ
• カラムナレイアウト、Apache Parquet に類似
• MVCC を使ってアップデート（タイムスタンプでタグをアップデート: in-‐‑‒place ではない）
• “SELECT AS OF <timestamp>” クエリを許可、またタブレットスキャン全体で整合性を維持
• “current time” スキャンにほぼ最適な READパス
• ⾏行行毎の分岐がなく、⾼高速なベクトル化でコーディングと術語評価 (predicate evaluation)
• 直近のアップデート数に応じてパフォーマンスが劣劣化
24

25. 25
©
Cloudera,
Inc.
All
rights
reserved.
メタデータ
• マスタは複製される (Replicated master) *
• タブレットのディレクトリとして機能 (“META” テーブル)
• カタログとして機能（テーブルスキーマなど）
• ロードバランサーとして機能（TS の⽣生存を追跡、レプリケーション中の
タブレットの再レプリケーション）
• パフォーマンス確保のためすべてのメタデータをRAMにキャッシュ
• 80ノードによるロードテスト、GetTableLocations RPC のパフォーマンス:
• 99パーセンタイル:68us、99.99パーセンタイル:657us
• CPU使⽤用率率率はピークで 2% 未満
• マスタのアドレスをクライアントに設定
• 必要に応じてマスタにタブレットの場所を問い合せてキャッシュする
25

26. 26
©
Cloudera,
Inc.
All
rights
reserved.
Kudu のトレードオフ
• ランダムアクセスの速度度劣劣化
• HBase モデルは、ディスクシーク無しにランダムアップデートが可能
• Kudu はアップデート前のキー検索索、インサート前の Bloom検索索が必要
• 1⾏行行だけの READ 速度度が劣劣化する場合がある
• カラムナはスキャンに対して最低化されたデザインになっている
• 今後: 1⾏行行だけのアクセスが重要がアプリケーションのために、カラムグループ
(Column groups) を提供予定

27. 27
©
Cloudera,
Inc.
All
rights
reserved.
ベンチマーク

28. 28
©
Cloudera,
Inc.
All
rights
reserved.
TPC-‐‑‒H（分析向けベンチマーク）
• 75TS + 1 マスタクラスタ
• 各クラスタに 12 のハードドライブとデータセットに⼗十分なRAMを搭載
• Kudu 0.5.0、Impala 2.2 with Kudu support、CDH 5.4 を使⽤用
• TPC-‐‑‒H Scale Factor 100 (100GB)
• サンプルクエリ:
• SELECT n_name, sum(l_extendedprice * (1 - l_discount)) as revenue FROM customer,
orders, lineitem, supplier, nation, region WHERE c_custkey = o_custkey AND
l_orderkey = o_orderkey AND l_suppkey = s_suppkey AND c_nationkey = s_nationkey
AND s_nationkey = n_nationkey AND n_regionkey = r_regionkey AND r_name = 'ASIA'
AND o_orderdate >= date '1994-01-01' AND o_orderdate < '1995-01-01’ GROUP BY
n_name ORDER BY revenue desc;
28

29. 29
©
Cloudera,
Inc.
All
rights
reserved.
-‐‑‒ RAM上のデータに対して、Kudu が Parquet を 31% 上回る（幾何平均）
-‐‑‒ HDD内のデータ（より⼤大きな I/Oリクエスト）に対しては、Parquet が Kudu を上回ると想定される

30. 30
©
Cloudera,
Inc.
All
rights
reserved.
Apache Phoenix の場合
• 10 ノードクラスタ（9 ワーカ、 1 マスタ)
• HBase 1.0、Phoenix 4.3
• TPC-‐‑‒H LINEITEM テーブルのみ (六六⼗十億⾏行行)
30
2152
219
76
131
0.04
1918
13.2
1.7
0.7
0.15
155
9.3
1.4
1.5
1.37
0.01
0.1
1
10
100
1000
10000
Load
TPCH
Q1
COUNT(*)
COUNT(*)
WHERE…
single-­‐row
lookup
時間 (秒)
Phoenix
Kudu
Parquet

31. 31
©
Cloudera,
Inc.
All
rights
reserved.
NoSQL スタイルランダムアクセス (YCSB)
• YCSB 0.5.0-‐‑‒スナップショット
• 10 ノードクラスタ
(9 ワーカ、1 マスタ)
• HBase 1.0
• ⼀一億⾏行行、⼗十億ops
31

32. 32
©
Cloudera,
Inc.
All
rights
reserved.
Xiaomi ユースケース
• モバイルアプリやバックエンドサービスから、重要な RPC トレーシングイベントを収集
• サービスモニタリングおよびトラブルシューティング⽤用ツール
• 優れた WRITE スループット
• 1⽇日 50 億超のレコード、さらに成⻑⾧長中
• 最新データをクエリし、素早く応答
• 問題を迅速に特定し解決することが可能
• 個別レコードの検索索が可能
• 容易易なトラブルシューティング

33. 33
©
Cloudera,
Inc.
All
rights
reserved.
ビッグデータ分析パイプライン
Kudu 以前
• ロングパイプライン
⼤大きなレイテンシ（1時間~∼1⽇日）、データ変換がネック
• 順序付けがない
ログの到着（ストレージ）順序がそのまま論論理理的な順番とは限らない
例例えば、1⽇日のログ確認に２~∼3⽇日のログの読み込みが必要

34. 34
©
Cloudera,
Inc.
All
rights
reserved.
ビッグデータ分析パイプライン
Kudu による簡素化
• ETL パイプライン (0~∼10秒のレイテンシ)
バックプレッシャーを避ける必要がある、あるいは ETLが必要なアプリ
• ダイレクトパイプライン（レイテンシなし）
ETLを必要としないバックプレッシャーの問題のないアプリ
OLAP スキャン
サイドテーブル検索索
結果のストア

35. 35
©
Cloudera,
Inc.
All
rights
reserved.
ユースケース１:ベンチマーク
環境
• 71 ノードクラスタ
• ハードウェア
• CPU: E5-‐‑‒2620 2.1GHz * 24 core Memory: 64GB
• ネットワーク: 1Gb ディスク: 12 HDD
• ソフトウェア
• Hadoop2.6/Impala 2.1/Kudu
データ
• サーバ側の 1⽇日のトレースデータ
• 最⼤大 26億⾏行行
• 最⼤大 270 byte/⾏行行
• 列列:17, キー列列:5

36. 36
©
Cloudera,
Inc.
All
rights
reserved.
ユースケース1: ベンチマーク結果
1.4
2.0
2.3
3.1
1.3
0.9
1.3
2.8
4.0
5.7
7.5
16.7
Q1
Q2
Q3
Q4
Q5
Q6
kudu
parquet
合計時間(s) スループット（合計） スループット（ノードあたり）
Kudu 961.1 2.8M record/s 39.5k record/s
Parquet 114.6 23.5M record/s 331k records/s
Impala を使⽤用したバルクロード (INSERT INTO):
クエリレイテンシ:
* HDFS Parquet ファイルレプリケーション = 3、kudu テーブルレプリケーション = 3
* 各クエリを5回実⾏行行した平均値

37. 37
©
Cloudera,
Inc.
All
rights
reserved.
現状、そしてこれから始めるには

38. 38
©
Cloudera,
Inc.
All
rights
reserved.
現状
✔ アーキテクチャのコアとなるコンポーネントはすべて完了了
✔ Java と C++ API
✔ Impala、MapReduce および Spark の統合
✔ SSD と HDD をサポート
✔ フォールトリカバリ
✔ パブリックベータ利利⽤用可能

39. 39
©
Cloudera,
Inc.
All
rights
reserved.
これから始めるには
ユーザー:
ベータをインストールまたは VMで試す:
getkudu.io
サポートは:
kudu-‐‑‒user@googlegroups.com
ホワイトペーパー:
getkudu.io/kudu.pdf
開発者:
コントリビューション:
github.com/cloudera/kudu (コミット)
gerrit.cloudera.org (レビュー)
issues.cloudera.org (JIRA は2013年年)
開発者リストに参加:
kudu-‐‑‒dev@googlegroups.com
コントリビューションを歓迎しています！

40. 40
©
Cloudera,
Inc.
All
rights
reserved.
ご静聴ありがとうございました

41. 41
©
Cloudera,
Inc.
All
rights
reserved.
Appendix

42. 42
©
Cloudera,
Inc.
All
rights
reserved.
Fault
tolerance
• Transient
FOLLOWER
failure:
• Leader
can
s]ll
achieve
majority
• Restart
follower
TS
within
5
min
and
it
will
rejoin
transparently
• Transient
LEADER
failure:
• Followers
expect
to
hear
a
heartbeat
from
their
leader
every
1.5
seconds
• 3
missed
heartbeats:
leader
elec]on!
• New
LEADER
is
elected
from
remaining
nodes
within
a
few
seconds
• Restart
within
5
min
and
it
rejoins
as
a
FOLLOWER
• N
replicas
handle
(N-­‐1)/2
failures
42

43. 43
©
Cloudera,
Inc.
All
rights
reserved.
Fault
tolerance
(2)
• Permanent
failure:
• Leader
no]ces
that
a
follower
has
been
dead
for
5
minutes
• Evicts
that
follower
• Master
selects
a
new
replica
• Leader
copies
the
data
over
to
the
new
one,
which
joins
as
a
new
FOLLOWER
43

44. 44
©
Cloudera,
Inc.
All
rights
reserved.
LSM
vs
Kudu
• LSM
–
Log
Structured
Merge
(Cassandra,
HBase,
etc)
• Inserts
and
updates
all
go
to
an
in-­‐memory
map
(MemStore)
and
later
flush
to
on-­‐disk
files
(HFile/SSTable)
• Reads
perform
an
on-­‐the-­‐fly
merge
of
all
on-­‐disk
HFiles
• Kudu
• Shares
some
traits
(memstores,
compac]ons)
• More
complex.
• Slower
writes
in
exchange
for
faster
reads
(especially
scans)
44

45. 45
©
Cloudera,
Inc.
All
rights
reserved.
Kudu
storage
–
Compac]on
policy
• Solves
an
op]miza]on
problem
(knapsack
problem)
• Minimize
“height”
of
rowsets
for
the
average
key
lookup
• Bound
on
number
of
seeks
for
write
or
random-­‐read
• Restrict
total
IO
of
any
compac]on
to
a
budget
(128MB)
• No
long
compac7ons,
ever
• No
“minor”
vs
“major”
dis7nc7on
• Always
be
compac]ng
or
flushing
• Low
IO
priority
maintenance
threads
45