#cwt2016 apache kudu 構成とテーブル設計

1©Cloudera,Inc.Allrightsreserved.

ApacheKudu構成とテーブル設計

矢野智聡/Cloudera株式会社

2016/11/08


自己紹介

• 矢野智聡(やのともあき)

• Customer Operations Engineer(テクニカルサポート)

• お客様がクラスタを運用する上での懸念や問題の解消を支援

©Cloudera,Inc.Allrightsreserved.

アジェンダ

• What’s Apache Kudu?

• ユースケース

• 構成要素と動作

• テーブルとパーティションの設計

• Kuduの関連情報


What’sApacheKudu?

4


ApacheKuduStorageforFastAnalyHcsonFastData

• 更新可能なカラムナストレージ• ApacheFoundaHonの

オープンソースプロジェクト• Cloudera Managerで

管理可能(ベータ版)

Columnar Store Kudu


HDFS with Parquet: •  入力はバッチ処理に特化 •  分析時などの大規模データのスキャンが高速

HBase : •  個別のデータの入出力が高速•  データのアップデートが可能

更新可能なデータを高速に分析する基盤の不在

Hadoopエコシステムのストレージ関係図


スケーラブルで高速なテーブル指向のストレージ

• Scalable• デザインとしては数千ノード,数十PBまでの拡張が可能

• Fast• クラスタ上で百万単位のI/O処理が可能• ノードあたり秒間数GB程度の読み込み性能

• Tabular•  SQL-likeschema:有限の型のある列(数十程度)の表(HBaseとは異なる)•  SQL(Impala/Spark/etc)と “NoSQL” APIs: Java/C++/Python でのアクセス• ALTER TABLEによる高速なメタデータの変更

©Cloudera,Inc.Allrightsreserved.©Cloudera,Inc.Allrightsreserved.

他のエコシステムとのインテグレーション

Kuduは計算処理のためのフレームワークと協調して動作します

•  インテグレーションのあるエコシステム•  Impala•  Spark•  MapReduce•  Flume•  Drill


ユースケース


Kuduのユースケース

Kuduはシーケンシャルな読み込みとランダムな読み込み、書き込み処理が同時に発生するような状況に適している● 時系列データ

○ 例:センサーデータ、連続的な市場データ、、ネットワークモニタリング、不正検知/抑止など○ 想定ワークロード:Insert,updates,scans,lookups

● オンラインレポーティング○ 例:OperaHonalDataStore○ 想定ワークロード:Inserts,updates,scans,lookups


Hadoop上でのストリーミングデータ分析の現状不正検知システムでのストレージの複雑性

考慮点: ●  Parquetへの変換処理の頻度 ●  レポート作成時の変換処理の完

了していないデータの扱い ●  メンテナンスに対する可用性

新しいパーティション

最近のパーティション

過去のパーティション

HBase

Parquet File

データの蓄積を待機して

HBaseデータのParquetへの

変換

•  現在実行中の処理の待機 •  新しいParquetファイルを参照する

Impalaのパーティションの作成

入力データ(Messaging)

Reporting

Impala on HDFS


Hadoop上でのストリーミングデータ分析とKudu

改善点: ●  単一システムでの処理

●  Cronなどでのバックグラウンド処理が不要

●  新しいデータが即時分析処理に使用可能

過去のデータと新しいデータ

入力データ(Messaging)

Reporting Request

Storage in Kudu


Xiaomiのユースケース

•  世界4位のスマートフォンメーカー

•  モバイルアプリケーションとバックグラウンドサービスのイベント情報の収集

•  サービスの監視とトラブルシューティング

◆  高い書き込み要求

•  >200億records/day からさらに増大する流量

◆  最新のデータに対するクエリ要件と応答速度

•  問題の特定と速やかな解決

◆  トラブルシューティングを容易にするための各行検索


Xiaomiのビッグデータ解析パイプライン Kudu 導入前

•  処理の長時間化データ変換における高レイテンシ(1 時間 ~ 1 日)

•  時系列でないデータログの到着順は生成順とは異なることがある例: 一日分のログのために2,3日分のログを処理する必要がある


Xiaomiのビッグデータ解析パイプラインKudu導入後

•  ETL 高速化(0~10s のレイテンシ) アプリのためにデータの変換が必要な処理も高速化

•  Kuduへの直接格納(no latency) 格納後即時処理可能

OLAP scan Side table lookup Result store

©Cloudera,Inc.Allrightsreserved. 16

構成要素と動作


テーブル

•  テーブルは複数のカラムから構成される•  カラムは下記のいずれかの型を取る必要がある•  BOOL,INT8,INT16,INT32,INT64,UNIXTIME_MICROS,FLOAT,DOUBLE,STRING,BINARYカラムはNull値を取りうる

•  カラムはbitshuffleなどでエンコーディングおよび圧縮が可能•  圧縮形式はlz4, snappy, gzipが使用可能•  エンコーディングおよび圧縮は適用できない組み合わせがあるので注意


プライマリキー

•  全ての表でプライマリキーは必須•  プライマリキーは一つ以上の列の組み合わせ

•  プライマリキーの値はユニークである必要がある•  プライマリキーには下記は使用できない

•  Booleanまたは浮動小数点型•  Nullが含まれる列

•  プライマリキーの値は更新できない•  プライマリキーのカラムは表のはじめの列に定義する


タブレット/タブレットサーバ

• タブレットは表をパーティションで分割したもの• 各タブレットはタブレットサーバによって管理される• タブレットの分割にはプライマリキーの値を使用する

• 各列のハッシュ、レンジおよびその組み合わせを分割に使用可能

• タブレット毎にRadconsensusによるN個のレプリカを持つ(default=3)

• レプリカのタブレットサーバは一つのリーダーと複数のフォロワーからなる

• 書き込みはリーダーに対してリクエストされる• 各タブレットサーバのデータはローカルディスクにあり、他のレプリカとは独立している


ImpalaでのCreate tableの例

BIGINTのハッシュとSTRINGのRANGEによるパーティショニング

Kuduの表とのマッピング


Metadata/MasterServer

• MetadataはMasterServerに管理される• 表の構成情報

• タブレットの構成情報• タブレットサーバの死活監視やレプリケーション管理

• メタデータはメモリ上にキャッシュされる• クライアントはマスターにアクセスし、アクセスするタブレットの情報を得る


Client

‘tlipcon’ は table “T”に存在するか?

Tablet2(Tablet ServerはX,Y,Z)にあるそのうちリーダーはZ…

UPDATE tlipcon SET col=foo where id=‘tlipcon’

Updateの動作例


TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

1a.Client->Leader:Write()RPC

RadConsensus


TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

RadConsensus

TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

2a.LeaderwriteslocalWAL

2b.Leader->Followers:UpdateConsensus()RPC


RadConsensus

TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

3.Follower:writeWAL 3.Follower:writeWAL


TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

RadConsensus

TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

4.Follower->Leader:success


TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

RadConsensus

TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

5.Leaderhasachievedmajority


TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

RadConsensus

TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

6.Leader->Client:Success!

©Cloudera,Inc.Allrightsreserved.©Cloudera,Inc.Allrightsreserved. 29

書き込み(insert/update)

•  Insertはメモリ上のrow storeに格納される• フラッシュ時にParquetに似たカラムナフォーマットのBase Imageとして

ディスクに格納される• Updateはメモリ上のdeltastoreに格納される

• フラッシュ時にディスクにdeltafilesとして格納される• コンパクションにより以前に書き出されたBase Imageに適用される


Kudustorage–InsertsandFlushesMemRowSet

name pay role

DiskRowSet1

name pay role

DiskRowSet2

INSERT(“doug”,“$1B”,“Hadoopman”)

flush


Kudustorage-UpdatesMemRowSet

name pay role

DiskRowSet 1

name pay role

DiskRowSet 2 Delta MS

Delta MS

DiskRowSetはそれぞれ専用のDeltaMemStoreをもちupdateはこちらで処理する

base data

base data


Kudustorage–UpdatesMemRowSet

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を利用した絞り込み


TSA

Tablet1(LEADER)

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL

耐障害性

TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

TSC

Tablet1(FOLLOWER)

WAL

WALWAL


TSA

Tablet1(LEADER)

TSB

Tablet1(FOLLOWER)

WAL

WAL

耐障害性

?

TSA

Tablet1(LEADER)

Client

TSB

Tablet1(FOLLOWER)

WAL

WAL


耐障害性(一時停止)

• フォロワーの一時的な停止:1.  リーダーは依然過半数の取得が可能なのでサービスを継続2.  5分以内に起動すれば透過的に再度フォロワーとして加入

• リーダーの一時的な停止:1.  フォロワーは1.5秒毎のリーダーからのハートビートを待機2.  3回ハートビートがなかった場合:リーダーの再選出

新しいリーダーは数秒の内に選出される3.  停止した元リーダーが5分以内に起動した場合はフォロワーとして加入

• N個のレプリカは(N-1)/2までのタブレットサーバ停止に対応可


耐障害性(永続停止)

1.  リーダーが5分を閾値に検知2.  該当のフォロワーを排除3.  マスターが新しいタブレットサーバーを選択4.  リーダーが新しいタブレットサーバーにデータをコピー5.  新しいタブレットサーバーがフォロワーとして参加

©Cloudera,Inc.Allrightsreserved.©Cloudera,Inc.Allrightsreserved.

チューニングガイドライン•  タブレットサーバー毎のタブレットの数

•  HWにもよるが、10-40程度•  タブレットのサイズ数百GiB程度

•  SSDが使える場合はWALを優先的に割り当てる•  Diskが多く使えたり、SSDが使える場合はMaintenanceManagerのThread数

を増加させる(MaintenanceManager=Delta RowSetのコンパクションなどを行うスレッド)

•  パーティションは分割されないので設計が重要


表とパーティションの設計


時系列データの例

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


想定状況

• データ流入は各ソースの最新のtimestampのもの• 読み込みは特定のシリーズの広範囲のtimestamp

SELECT time, value FROM timeseries WHERE series = "us-west.dbserver03.rss" AND time >= 2016-05-08T00:00:00;

クエリ例


時刻のレンジによるパーティション


時刻のレンジによるパーティション(inserts)

新しいデータは全て一つのタブレットへ


時刻のレンジによるパーティション(scans)

多くのtimestampにまたがるクエリはパーティション間で分散される


ノードのレンジによるパーティション


ノードのレンジによるパーティション(inserts)

Insertは複数のパーティションに分散される


ノードのレンジによるパーティション(scans)

Scanは特定のパーティションに限定される


ノードのレンジによるパーティション

特定のシリーズ(同一サービスのノード群など)で多くのデータが生成されると流量が偏り、パーティションのサイズが偏る


ノードのハッシュパーティション


ノードのハッシュパーティション(inserts)

Insertは複数のパーティションに分散される(Hashによる平均化も期待される)


ノードのハッシュパーティション(scans)

Scanは特定のパーティションに限定される


ノードのハッシュパーティション

関連するシリーズ(同一サービスのノード群など)のデータが分散されるので平均化されやすくなる


時刻のレンジとノードハッシュ

時刻

ノードハッシュ


時刻のレンジとノードハッシュ(inserts)

Insertは最新のtimestampのパーティション間で分散される

時刻

ノードハッシュ


多くのtimestampにまたがるクエリはパーティション間で分散される

時刻

時刻のレンジとノードハッシュ(scans)ノードハッシュ


表とパーティション設計の考慮点

• プライマリキーにする列の検討

• 複数列とする場合の分割性能

• パーティションの種類と組み合わせの検討(Range/Hash)

• データ流入、更新パターンの検討/テスト

• アクセスパターンの検討/テスト

• Cloudera Managerで管理していれば処理実行時の負荷をチャートで把握可能


Kuduの関連情報


インストール情報

• 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とのインテグレーションが組み込まれている)


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


Kuduの情報

• Apache Kudu project page

http://kudu.apache.org/

ドキュメントをはじめ各コミュニティ(slack, JIRA, mailing listなど)へのアクセス方法やBlog形式でのWeekly Reportを確認できる

• Cloudera Engineering Blog

https://blog.cloudera.com/

今後の方針やパフォーマンステスト、ベストプラクティスなど


Kuduの詳細情報

• Kudu Design Docs

https://github.com/apache/kudu/tree/master/docs/design-docs

Tabletのコンパクションやバックグラウンドでのメンテナンス処理、

APIなどのデザインについて情報がまとまっている


まとめ

• Apache KuduはHadoopクラスタの新しいカラムナストレージエンジン

• タブレットサーバーによりデータが管理され、Raft consensus による

レプリケーション、耐障害性を備えている

• 使用用途によってはHDFS+ParquetやHBaseの方が適切なことはあるので

検討と検証が不可欠

• パフォーマンス維持と安定運用のためにはパーティションの設計が重要


Thankyou!

#cwt2016 apache kudu 構成とテーブル設計

Software