Low latency high throughput streaming using Apache Apex and Apache Kudu
#cwt2016 Apache Kudu 構成とテーブル設計
-
Upload
cloudera-japan -
Category
Software
-
view
872 -
download
3
Transcript of #cwt2016 Apache Kudu 構成とテーブル設計
1©Cloudera,Inc.Allrightsreserved.
ApacheKudu構成とテーブル設計
矢野 智聡/Cloudera株式会社
2016/11/08
2©Cloudera,Inc.Allrightsreserved.
自己紹介
• 矢野 智聡(やの ともあき)
• Customer Operations Engineer(テクニカルサポート)
• お客様がクラスタを運用する上での懸念や問題の解消を支援
©Cloudera,Inc.Allrightsreserved.
アジェンダ
• What’s Apache Kudu?
• ユースケース
• 構成要素と動作
• テーブルとパーティションの設計
• Kuduの関連情報
4©Cloudera,Inc.Allrightsreserved.
What’sApacheKudu?
4
5©Cloudera,Inc.Allrightsreserved.
ApacheKuduStorageforFastAnalyHcsonFastData
• 更新可能なカラムナ ストレージ• ApacheFoundaHonの
オープンソースプロジェクト• Cloudera Managerで
管理可能(ベータ版)
Columnar Store Kudu
6©Cloudera,Inc.Allrightsreserved.
HDFS with Parquet: • 入力はバッチ処理に特化 • 分析時などの大規模データの スキャンが高速
HBase : • 個別のデータの入出力が高速• データのアップデートが可能
更新可能なデータを高速に分析する基盤の不在
Hadoopエコシステムのストレージ関係図
7©Cloudera,Inc.Allrightsreserved.
スケーラブルで高速なテーブル指向のストレージ
• 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
9©Cloudera,Inc.Allrightsreserved.
ユースケース
10©Cloudera,Inc.Allrightsreserved.
Kuduのユースケース
Kuduはシーケンシャルな読み込みとランダムな読み込み、書き込み処理が同時に発生するような状況に適している● 時系列データ
○ 例:センサーデータ、連続的な市場データ、、 ネットワークモニタリング、不正検知/抑止など○ 想定ワークロード:Insert,updates,scans,lookups
● オンラインレポーティング○ 例:OperaHonalDataStore○ 想定ワークロード:Inserts,updates,scans,lookups
11©Cloudera,Inc.Allrightsreserved.
Hadoop上でのストリーミングデータ分析の現状不正検知システムでのストレージの複雑性
考慮点: ● Parquetへの変換処理の頻度 ● レポート作成時の変換処理の完
了していないデータの扱い ● メンテナンスに対する可用性
新しいパーティション
最近のパーティション
過去のパーティション
HBase
Parquet File
データの蓄積を待機して
HBaseデータのParquetへの
変換
• 現在実行中の処理の待機 • 新しいParquetファイルを参照する
Impalaのパーティションの作成
入力データ(Messaging)
Reporting
Impala on HDFS
12©Cloudera,Inc.Allrightsreserved.
Hadoop上でのストリーミングデータ分析とKudu
改善点: ● 単一システムでの処理
● Cronなどでのバックグラウンド処理が不要
● 新しいデータが即時分析処理に使用可能
過去のデータと新しいデータ
入力データ(Messaging)
Reporting Request
Storage in Kudu
13©Cloudera,Inc.Allrightsreserved.
Xiaomiのユースケース
• 世界4位のスマートフォンメーカー
• モバイルアプリケーションとバックグラウンドサービスのイベント情報の収集
• サービスの監視とトラブルシューティング
◆ 高い書き込み要求
• >200億records/day からさらに増大する流量
◆ 最新のデータに対するクエリ要件と応答速度
• 問題の特定と速やかな解決
◆ トラブルシューティングを容易にするための各行検索
14©Cloudera,Inc.Allrightsreserved.
Xiaomiのビッグデータ解析パイプライン Kudu 導入前
• 処理の長時間化 データ変換における高レイテンシ(1 時間 ~ 1 日)
• 時系列でないデータ ログの到着順は生成順とは異なることがある 例: 一日分のログのために2,3日分のログを処理する必要がある
15©Cloudera,Inc.Allrightsreserved.
Xiaomiのビッグデータ解析パイプラインKudu導入後
• ETL 高速化(0~10s のレイテンシ) アプリのためにデータの変換が必要な処理も高速化
• Kuduへの直接格納(no latency) 格納後即時処理可能
OLAP scan Side table lookup Result store
©Cloudera,Inc.Allrightsreserved. 16
構成要素と動作
17©Cloudera,Inc.Allrightsreserved.
テーブル
• テーブルは複数のカラムから構成される• カラムは下記のいずれかの型を取る必要がある• BOOL,INT8,INT16,INT32,INT64,UNIXTIME_MICROS,FLOAT,DOUBLE,STRING,BINARYカラムはNull値を取りうる
• カラムはbitshuffleなどでエンコーディングおよび圧縮が可能• 圧縮形式はlz4, snappy, gzipが使用可能• エンコーディングおよび圧縮は適用できない組み合わせがあるので注意
18©Cloudera,Inc.Allrightsreserved.
プライマリキー
• 全ての表でプライマリキーは必須• プライマリキーは一つ以上の列の組み合わせ
• プライマリキーの値はユニークである必要がある• プライマリキーには下記は使用できない
• Booleanまたは浮動小数点型• Nullが含まれる列
• プライマリキーの値は更新できない• プライマリキーのカラムは表のはじめの列に定義する
©Cloudera,Inc.Allrightsreserved. 19
タブレット/タブレットサーバ
• タブレットは表をパーティションで分割したもの• 各タブレットはタブレットサーバによって管理される• タブレットの分割にはプライマリキーの値を使用する
• 各列のハッシュ、レンジおよびその組み合わせを分割に使用可能
• タブレット毎にRadconsensusによるN個のレプリカを持つ(default=3)
• レプリカのタブレットサーバは一つのリーダーと複数のフォロワーからなる
• 書き込みはリーダーに対してリクエストされる• 各タブレットサーバのデータはローカルディスクにあり、他のレプリカとは独立している
©Cloudera,Inc.Allrightsreserved.
ImpalaでのCreate tableの例
BIGINTのハッシュとSTRINGのRANGEによるパーティショニング
Kuduの表とのマッピング
©Cloudera,Inc.Allrightsreserved. 21
Metadata/MasterServer
• MetadataはMasterServerに管理される• 表の構成情報
• タブレットの構成情報• タブレットサーバの死活監視やレプリケーション管理
• メタデータはメモリ上にキャッシュされる• クライアントはマスターにアクセスし、アクセスするタブレットの情報を得る
©Cloudera,Inc.Allrightsreserved. 22
Client
‘tlipcon’ は table “T”に存在するか?
Tablet2(Tablet ServerはX,Y,Z)にあるそのうちリーダーはZ…
UPDATE tlipcon SET col=foo where id=‘tlipcon’
Updateの動作例
©Cloudera,Inc.Allrightsreserved. 23
TSA
Tablet1(LEADER)
Client
TSB
Tablet1(FOLLOWER)
TSC
Tablet1(FOLLOWER)
WAL
WALWAL
1a.Client->Leader:Write()RPC
RadConsensus
©Cloudera,Inc.Allrightsreserved. 24
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
©Cloudera,Inc.Allrightsreserved. 25
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
©Cloudera,Inc.Allrightsreserved. 26
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
©Cloudera,Inc.Allrightsreserved. 27
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
©Cloudera,Inc.Allrightsreserved. 28
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に適用される
©Cloudera,Inc.Allrightsreserved. 30
Kudustorage–InsertsandFlushesMemRowSet
name pay role
DiskRowSet1
name pay role
DiskRowSet2
INSERT(“doug”,“$1B”,“Hadoopman”)
flush
©Cloudera,Inc.Allrightsreserved. 31
Kudustorage-UpdatesMemRowSet
name pay role
DiskRowSet 1
name pay role
DiskRowSet 2 Delta MS
Delta MS
DiskRowSetはそれぞれ専用のDeltaMemStoreをもちupdateはこちらで処理する
base data
base data
©Cloudera,Inc.Allrightsreserved. 32
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を利用した絞り込み
©Cloudera,Inc.Allrightsreserved. 33
TSA
Tablet1(LEADER)
TSB
Tablet1(FOLLOWER)
TSC
Tablet1(FOLLOWER)
WAL
WALWAL
耐障害性
TSA
Tablet1(LEADER)
Client
TSB
Tablet1(FOLLOWER)
TSC
Tablet1(FOLLOWER)
WAL
WALWAL
©Cloudera,Inc.Allrightsreserved. 34
TSA
Tablet1(LEADER)
TSB
Tablet1(FOLLOWER)
WAL
WAL
耐障害性
?
TSA
Tablet1(LEADER)
Client
TSB
Tablet1(FOLLOWER)
WAL
WAL
©Cloudera,Inc.Allrightsreserved.©Cloudera,Inc.Allrightsreserved. 35
耐障害性(一時停止)
• フォロワーの一時的な停止:1. リーダーは依然過半数の取得が可能なのでサービスを継続2. 5分以内に起動すれば透過的に再度フォロワーとして加入
• リーダーの一時的な停止:1. フォロワーは1.5秒毎のリーダーからのハートビートを待機2. 3回ハートビートがなかった場合:リーダーの再選出
新しいリーダーは数秒の内に選出される3. 停止した元リーダーが5分以内に起動した場合はフォロワーとして加入
• N個のレプリカは(N-1)/2までのタブレットサーバ停止に対応可
©Cloudera,Inc.Allrightsreserved.©Cloudera,Inc.Allrightsreserved. 36
耐障害性(永続停止)
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のコンパクションなどを行うスレッド)
• パーティションは分割されないので設計が重要
©Cloudera,Inc.Allrightsreserved. 38
表とパーティションの設計
©Cloudera,Inc.Allrightsreserved. 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
©Cloudera,Inc.Allrightsreserved. 40
想定状況
• データ流入は各ソースの最新のtimestampのもの• 読み込みは特定のシリーズの広範囲のtimestamp
SELECT time, value FROM timeseries WHERE series = "us-west.dbserver03.rss" AND time >= 2016-05-08T00:00:00;
クエリ例
©Cloudera,Inc.Allrightsreserved.
時刻のレンジによるパーティション
©Cloudera,Inc.Allrightsreserved.
時刻のレンジによるパーティション(inserts)
新しいデータは全て一つのタブレットへ
©Cloudera,Inc.Allrightsreserved.
時刻のレンジによるパーティション(scans)
多くのtimestampにまたがるクエリはパーティション間で分散される
©Cloudera,Inc.Allrightsreserved.
ノードのレンジによるパーティション
©Cloudera,Inc.Allrightsreserved.
ノードのレンジによるパーティション(inserts)
Insertは複数のパーティションに分散される
©Cloudera,Inc.Allrightsreserved.
ノードのレンジによるパーティション(scans)
Scanは特定のパーティションに限定される
©Cloudera,Inc.Allrightsreserved.
ノードのレンジによるパーティション
特定のシリーズ(同一サービスのノード群など)で多くのデータが生成されると流量が偏り、パーティションのサイズが偏る
©Cloudera,Inc.Allrightsreserved.
ノードのハッシュパーティション
©Cloudera,Inc.Allrightsreserved.
ノードのハッシュパーティション(inserts)
Insertは複数のパーティションに分散される(Hashによる平均化も期待される)
©Cloudera,Inc.Allrightsreserved.
ノードのハッシュパーティション(scans)
Scanは特定のパーティションに限定される
©Cloudera,Inc.Allrightsreserved.
ノードのハッシュパーティション
関連するシリーズ(同一サービスのノード群など)のデータが分散されるので平均化されやすくなる
©Cloudera,Inc.Allrightsreserved.
時刻のレンジとノードハッシュ
時刻
ノードハッシュ
©Cloudera,Inc.Allrightsreserved.
時刻のレンジとノードハッシュ(inserts)
Insertは最新のtimestampのパーティション間で分散される
時刻
ノードハッシュ
©Cloudera,Inc.Allrightsreserved.
多くのtimestampにまたがるクエリはパーティション間で分散される
時刻
時刻のレンジとノードハッシュ(scans)ノードハッシュ
©Cloudera,Inc.Allrightsreserved.
表とパーティション設計の考慮点
• プライマリキーにする列の検討
• 複数列とする場合の分割性能
• パーティションの種類と組み合わせの検討(Range/Hash)
• データ流入、更新パターンの検討/テスト
• アクセスパターンの検討/テスト
• Cloudera Managerで管理していれば処理実行時の負荷をチャートで把握可能
©Cloudera,Inc.Allrightsreserved. 56
Kuduの関連情報
©Cloudera,Inc.Allrightsreserved.
インストール情報
• 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とのインテグレーションが組み込まれている)
©Cloudera,Inc.Allrightsreserved.
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
©Cloudera,Inc.Allrightsreserved.
Kuduの情報
• Apache Kudu project page
http://kudu.apache.org/
ドキュメントをはじめ各コミュニティ(slack, JIRA, mailing listなど)へのアクセス方法やBlog形式でのWeekly Reportを確認できる
• Cloudera Engineering Blog
https://blog.cloudera.com/
今後の方針やパフォーマンステスト、ベストプラクティスなど
©Cloudera,Inc.Allrightsreserved.
Kuduの詳細情報
• Kudu Design Docs
https://github.com/apache/kudu/tree/master/docs/design-docs
Tabletのコンパクションやバックグラウンドでのメンテナンス処理、
APIなどのデザインについて情報がまとまっている
©Cloudera,Inc.Allrightsreserved.
まとめ
• Apache KuduはHadoopクラスタの新しいカラムナストレージエンジン
• タブレットサーバーによりデータが管理され、Raft consensus による
レプリケーション、耐障害性を備えている
• 使用用途によってはHDFS+ParquetやHBaseの方が適切なことはあるので
検討と検証が不可欠
• パフォーマンス維持と安定運用のためにはパーティションの設計が重要
©Cloudera,Inc.Allrightsreserved.
Thankyou!