Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Apache Kuduを使った分析システムの裏側

5.684 visualizaciones

Publicado el

Cloudera World Tokyo 2017 での Cloudera 佐藤の公演資料です。

Publicado en: Datos y análisis
  • Sé el primero en comentar

Apache Kuduを使った分析システムの裏側

  1. 1. 1© Cloudera, Inc. All rights reserved. Apache Kudu を使った分析システムの裏側 Takahiko Sato - Sales Engineer at Cloudera Nov 7, 2017
  2. 2. 2© Cloudera, Inc. All rights reserved. ⾃⼰紹介 • 佐藤貴彦 (さとうたかひこ) / takahiko at cloudera.com • セールスエンジニア • お客様がCloudera製品及び関連技術をを活⽤できるように、⼀緒に議論する のがメインの仕事 • これまでの経験 • Internet & Network(⼤学) • RDBMS(1社⽬) • NoSQL(2社⽬) • Hadoop(3社⽬) ←Now!
  3. 3. 3© Cloudera, Inc. All rights reserved. はじめに
  4. 4. 4© Cloudera, Inc. All rights reserved. いきなり今⽇のまとめ Apache Kuduとは? • ⼤規模データ(ペタバイト、1000億⾏以上)を扱えるデータベース • SQLを使って構造化データを分析 • 更新(INSERT/UPDATE/DELETE)を⾏いつつ、⼤規模スキャン(SELECT)可能 • HTAP: OLTPとOLAPの融合 Kuduで分析システムをつくるには? • 複数ノードで分散並列処理 • スキーマ設計パーティション戦略が重要 • 各ノードのディスクは複数本⽤意、SSDの利⽤を推奨 • あとはリレーショナルDBのようにSQLアクセスで分析!
  5. 5. 5© Cloudera, Inc. All rights reserved. 分析データベース
  6. 6. 6© Cloudera, Inc. All rights reserved. 分析データベースといわれて想像するものは? SQL? DWH? BI? OLAP?RDBMS? 分析データベース DataMart?
  7. 7. 7© Cloudera, Inc. All rights reserved. リレーショナルDBを⽤いたデータ分析 拡張性のつらさ • スケールアップするにも、OLTPはせいぜい1TBのRAMに収まるまで • スケールアウトは、シェアードナッシングが基本で設計運⽤で対処 OLTPとOLAPの世界は分離 • 異なる2種類のワークロード 進歩しつつはあるも、依然として⼤規模データの分析に困難 insert/update/delete 分析対象 OLTPの世界 OLAPの世界(DWH) BIツール select
  8. 8. 8© Cloudera, Inc. All rights reserved. Hadoopエコシステムを⽤いた⼤規模データ分析 スケーラビリティの⾼いHadoopエコシステム • スケールアウトでペタバイト(PB)級のデータも処理可能 HDFSは⼤規模スキャンが得意なので、OLAP系のアクセスは得意 • Impala/Hive経由でSQLによるスキャンもできる • しかしHDFSはデータの更新は得意ではない • HBaseでは⼤規模のOLTP系のアクセスは得意 しかしHBaseからの結局データ変換が必要ですぐさま分析することができない put Hadoopの世界 BIツール select HBase ETL Impala HDFS put
  9. 9. 9© Cloudera, Inc. All rights reserved. HTAP : 求められるOLTPとOLAPの融合 OLTP? OLAP? 次世代のデータ処理はこれらのハイブリッド • 流れ続けるデータに対して継続的な分析 • OLTPのようにデータを受け続け、OLAPの様に分析をし続ける、そんなハイ ブリッド型のアーキテクチャが求められる HTAP(Hybrid Transactional/Analytic Processing) • ガートナーによる造語 • 技術的に固まった定義があるわけではなく、様々な解釈があるが... • 「新たに発⽣したアーキテクチャ」 • KuduもこのHTAPと呼ばれるジャンルのデータベース HTAP
  10. 10. 10© Cloudera, Inc. All rights reserved. Kudu概要
  11. 11. 11© Cloudera, Inc. All rights reserved. Kudu: 急速に変化するデータに⾼速な分析 HDFS ⾼速スキャン, 分析及びストアされ たデータの処理 オンラインでの ⾼速な更新& データ提供 任意のストレージ (アクティブアーカイブ) ⾼速な分析 (急速に変化 or 頻繁に 更新されるデータ) 変化なし 急速に変化し 頻繁に更新 HBase 追記のみ リアルタイム Kudu Analytic Gap 分析のペース データの更新ペース
  12. 12. 12© Cloudera, Inc. All rights reserved. スケーラブルで⾼速な表形式のストレージ スケーラビリティ • 275ノード(〜3PBクラスター)までテスト済み • 1000ノード超、数⼗PBまでスケールできるような設計 ⾼速性能 • クラスターで秒間数百万のリード/ライト • 1ノードあたり数GB/秒のリードスループット テーブル形式 • リレーショナルDBのような構造化されたテーブルでデータを表現 • 厳密なスキーマ、有限個の列、⾮BLOB • 1000億⾏以上からなるテーブルの個々の⾏レベルのアクセスが可能 複数ノードで1つのデータベース ...
  13. 13. 13© Cloudera, Inc. All rights reserved. Kuduは次世代のハードウェアに対応 SSDは毎年安くなり速くなる。 永続性のあるメモリー (3D XPoint™)の登場。 KuduはIntelのNVMeライブラリを使ってお り、SSDやNVMeを効果的に扱える。 RAMは毎年安くなり毎年⼤きくなる。 Kuduは⼤規模なメモリー上でスムーズ に動作する。 GC問題を避けるために、C++で書かれ ている。 現在のCPUは、コア数の増加とSIMD 命令幅の増加であり、GHzの増加では なくなっている。 KuduはSIMD命令と同時並⾏性の⾼い データ構造を効果的に扱うことがで きる。 SSD より安くより⼤きなメモリ 現在のCPUにおける効率性
  14. 14. 14© Cloudera, Inc. All rights reserved. KuduのSQLインターフェース • Kudu はリレーショナルデータベースに似た構造を持つストレージだが、クエ リエンジン(SQL)は他に任せている Query Engine Storage Engine Catalog Query Engine (Impala) Catalog (HMS) モノリシックな 分析データベース モダンな分析データベース Storage (Kudu) Storage (S3) Storage (HDFS)
  15. 15. 15© Cloudera, Inc. All rights reserved. Apache Impala: Hadoop向けのセルフBI SQL on Hadoop • BIスタイルのSQLをHadoop(HDFSなど)に対して実⾏ • HiveのようにSparkやMapReduceの処理に変換せず直接実⾏ ⾼速性能 • アドホッククエリ⽤途 • レイテンシーを意識した設計(数秒〜数⼗秒で応答を返す) 同時並⾏性 • 複数ユーザーが同時にSQLを実⾏しても、⼗分な性能を発揮できる 互換性 • JDBC/ODBCドライバーにより、様々なBIツールと接続可能
  16. 16. 16© Cloudera, Inc. All rights reserved. Impalaを⽤いたKuduへのSQLアクセス
  17. 17. 17© Cloudera, Inc. All rights reserved. KuduへのAPIによるアクセス 各種プログラミング⾔語のバインディング • C++ • Java • Python 各種ミドルウェアとの統合 • MapReduce • YARN • Spark • Flume
  18. 18. 18© Cloudera, Inc. All rights reserved. KuduとSparkとの連携 • DataFrameからテーブルの操作 • SparkSQLの使⽤ • Kuduに保存されているデータをSpark 上で容易に処理することが可能
  19. 19. 19© Cloudera, Inc. All rights reserved. 構成例と事例
  20. 20. 20© Cloudera, Inc. All rights reserved. Kuduを⽤いた典型的なアーキテクチャ例 Spark Streaming ImpalaData Sources Applications KuduKafka 〜メッセージキュー〜 多種多様のデータソースに対 応するため、直接データベー スに⼊れるのではなく、⼀旦 受け⽌める層を設置。 〜データの前処理〜 Kuduは構造化データを格納す るため、⾮構造化データから の変換や、追加情報の付与な どを必要に応じて⾏う。 〜SQLアクセス〜 SQLアクセスを⾏うことに よって、BIツールをはじめ、 様々な分析アプリから容易に 接続可能 SQL w/ JDBC NoSQL API
  21. 21. 21© Cloudera, Inc. All rights reserved. ウェブのログ JD.comの事例 中国第2位のリテール系企業、ECサイト「JD.com」が有名 Kafka経由でリアルタイムにデータを取得しKuduへデータを収拾 • クリックログ • アプリケーション及びブラウザーのトレース 1⽇に100億トランザクション以上、ピーク時毎秒1000万インサート ブラウザの トレース Impala SQLによる直 接アクセス ウェブ アプリケー ション SQLSQL Kafka Kudu
  22. 22. 22© Cloudera, Inc. All rights reserved. Xiaomiの事例 世界第4位のスマートフォンメーカー • モバイルアプリとバックエンドサービスから、RPCの追跡イベントを取得 • サービスモニタリング&トラブルシューティングツールとして利⽤ ⾼い書き込みスループット • 現時点で 50億レコード/⽇ 以上ありさらに増加中 データ ソース Impala 結果の取得 SQL データの直接格納 Storm Kudu Kafka バックプレッシャーの制御 / ETL OLAPスキャン サイドテーブルのルックアップ 結果の格納
  23. 23. 23© Cloudera, Inc. All rights reserved. Comcastの事例 Comcast • 世界最⼤のケーブルテレビ会社 • テレビ視聴データのリアルタイム及びバッチ分析にKuduを利⽤ • データ増加は5億records/day以上 Real-time analytics using Kudu at petabyte scale • https://conferences.oreilly.com/strata/strata-ca- 2017/public/schedule/detail/56113
  24. 24. 24© Cloudera, Inc. All rights reserved. その他の例)リアルタイムの機械学習アーキテクチャ Spark Streaming Spark MLlib Spark Data Sources Applications 2) メッセージ配信 3) ストリーム処理 4) Kuduに格納 5) 機械学習ライブラリの適⽤ 1) イベント発⽣ KuduKafka Height Weight Height Weight 1 2 Height Weight 3 Height Weight 4 L M S XL L M S XS Near Custom ? 機械学習ライブラリの適⽤例 - クラスタリング 〜Note〜 機械学習を含む、Clouderaのデータサイ エンス製品には、Cloudera Data Science Workbench がある
  25. 25. 25© Cloudera, Inc. All rights reserved. Kuduのデータ構造
  26. 26. 26© Cloudera, Inc. All rights reserved. Kuduのデータモデル • リレーショナルデータベースに似ている • テーブル構造 • 各列は強いデータ型を持つ • 主キーを持つ
  27. 27. 27© Cloudera, Inc. All rights reserved. カラムナー(列指向)ストレージ • 物理構造として、列ごとにデータが分離している {25059873, 22309487, 23059861, 23010982} Tweet_id {newsycbot, RideImpala, fastly, llvmorg} User_name {1442865158, 1442828307, 1442865156, 1442865155} Created_at {Visual exp…, Introducing .., Missing July…, LLVM 3.7….} text
  28. 28. 28© Cloudera, Inc. All rights reserved. カラムナーストレージ {25059873, 22309487, 23059861, 23010982} Tweet_id {newsycbot, RideImpala, fastly, llvmorg} User_name {1442865158, 1442828307, 1442865156, 1442865155} Created_at {Visual exp…, Introducing .., Missing July…, LLVM 3.7….} text この1列だけを読む 1GB 2GB 1GB 200GB SELECT COUNT(*) FROM tweets WHERE user_name = ‘newsycbot’; 列ごとのエンコーディングと圧縮によって、IOの増加に対応できるようになった
  29. 29. 29© Cloudera, Inc. All rights reserved. 列のデザイン 制約 • 主キー列は必須かつユニーク制約だが、他の列はNULLも可能 データ型 • Boolean • 8/16/32/64 bit signed integer • timestamp (64-bit microseconds since the Unix epoch) • float/double (IEEE-754) • UTF-8 encoded string(64KBまで) • Binary (64KBまで) データ型の重要性 • エンコーディングと圧縮による、IOと保存容量の効率化
  30. 30. 30© Cloudera, Inc. All rights reserved. 列のエンコーディング エンコーディング(符号化) • データのbit表現をどうするか 列のデータ型がわからないと... • 容量効率やIO効率が悪い • 多くのNoSQLでは、Valueを単なるバイナリとしてしか扱っていない Kudu ではデータ特性に合わせ効率よくデータを扱える • Plain Encoding • Bitshuffle Encoding • Run Length Encoding(RLE) • Dictionary Encoding • Prefix Encoding
  31. 31. 31© Cloudera, Inc. All rights reserved. Kuduが対応しているエンコーディング⽅式 Plain Encoding • データ型ごとの標準的な形式で保存(つまり何もしない) Bitshuffle Encoding • ビット列を並び替え、その後LZ4圧縮を⾏う • 多くの反復値を持つ列、主キーでソートすると少量ずつ変化する値に有効 Run Length Encoding(RLE) • いわゆるランレングス圧縮を⾏う • 主キーでソートされた際、連続した反復値が多数⾒られる列に効果的 Dictionary Encoding • 列の値からディクショナリを作成時、実際の列側にはそのインデックスが格納 • カーディナリティの低い列に有効 • ユニークな値が多くなって圧縮が効かなくなってきたら、Plainにフォールバック Prefix Encoding • 共通プレフィックスを持つ値、主キーの最初の列に有効
  32. 32. 32© Cloudera, Inc. All rights reserved. データ型のエンコーディング • Kudu 1.5 / CDH 5.13 現在は以下のエンコーディング及びデフォルト設定 列のデータ型 可能なエンコーディング デフォルト設定 int8, int16, int32 plan, bitshuffle, run length bitshuffle int64, unixtime_micros plan, bitshuffle, run length bitshuffle float, double plan, bit shuffle bitshuffle bool plan, run length run length string, binary plain, prefix, dictionary dictionary
  33. 33. 33© Cloudera, Inc. All rights reserved. エンコーディング例 key string bool 1 sato true 2 tanaka true 3 tanaka true 4 sato false 5 suzuki false 6 suzuki true 7 suzuki true 8 sato true 9 sato true 10 sato true boolの列 - RLEの例stringの列 - dictionaryの例 dictionary 1:sato 2:suzuki 3:tanaka string 1 3 3 1 2 2 2 1 1 1 bool true x3 false x2 true x4 テーブル例
  34. 34. 34© Cloudera, Inc. All rights reserved. Kuduの列圧縮 • Kuduは列単位でデータの圧縮が可能 • LZ4、Snappy、zlib • 圧縮は圧縮速度と圧縮サイズのバランスを考える • 圧縮処理はCPUと時間を使うが、圧縮によってサイズが減ればIO量を減らす ことができる • ⼀般的に圧縮/展開速度と圧縮サイズの⾯でLZ4が最もバランスが良く • 圧縮率だけみるならzlibが最も⾼い • 通常の列はデフォルトでは無圧縮 • Bitshuffleエンコーディングは例外で、内部で⾃動的にLZ4で圧縮が⾏われる ので、その上に追加で圧縮を掛ける必要はない 〜Note〜 つまり圧縮とは、IOのボトルネックをCPU 側に寄せるものである
  35. 35. 35© Cloudera, Inc. All rights reserved. 主キーのデザイン • Kuduの表は、現在は主キーが必須 • 主キーは⼀意制約を持つ • null, boolean, float/double は許可されない • 現時点ではシーケンス機能(⾃動でインクリメントするinteger)を持たない ため、アプリケーションは挿⼊時に常に主キーを提供する必要がある • 主キー列の値は更新不可 • 通常のRDBMSでも同様
  36. 36. 36© Cloudera, Inc. All rights reserved. Kuduの物理構成 • KuduはMasterとTabletServer(ワーカー)から構成される TabletServer Master
  37. 37. 37© Cloudera, Inc. All rights reserved. タブレット • Kuduでテーブルを作成した際、1つのテーブルに格納されるデータは、タブ レットに分割されて、各タブレットサーバー上に保存される Tablet Kudu上のテーブル TabletServer
  38. 38. 38© Cloudera, Inc. All rights reserved. タブレットの複製 • ある1つのタブレットは、さらに複数のタブレット(デフォルト3)に複製さ れ、これもまた異なるタブレットサーバーに保持される • つまり実際のタブレット数は、3倍の数になる • タブレットではRaftコンセンサスアルゴリズムを使ってリーダーが選出される • タブレットへのデータの書き込み処理はリーダーでのみ受け付けられる • タブレットからのデータの読み込みは、どのレプリカからでも可能 タブレット リーダー タブレット フォロワー Tablet TabletServer タブレット フォロワー 〜Note〜 つまり実際のタブレット数は 3倍の数になる
  39. 39. 39© Cloudera, Inc. All rights reserved. CDHとKudu
  40. 40. 40© Cloudera, Inc. All rights reserved. CDH: ClouderaのHadoopディストリビューション • Cloudera's Distribution including Apache Hadoop • Hadoopディストリビューション • Hadoopエコシステムを⼀般利⽤者が利⽤できる形にまとめあげたもの • Cloudera が提供する CDH • 他で例えると・・・ • Linuxディストリビューション • Red Hat が提供する Red Hat Enterprise Linux
  41. 41. 41© Cloudera, Inc. All rights reserved. CDH 5.10 より Kudu をサポート! • 2016-09-19 Apache Kudu 1.0.0 リリース • 2016-10-11 Apache Kudu 1.0.1 リリース • 2016-11-21 Apache Kudu 1.1.0 リリース • 2017-01-18 Apache Kudu 1.2.0 リリース • 2017-01-31 CDH 5.10 で Apache Kudu 1.2 が GA に • 2017-03-20 Apache Kudu 1.3.0 リリース • 2017-04-19 Apache Kudu 1.3.1 リリース • 2017-06-13 Apache Kudu 1.4.0 リリース • 2017-09-08 Apache Kudu 1.5.0 リリース
  42. 42. 42© Cloudera, Inc. All rights reserved. エンタープライズとKudu • Apache Kudu 1.3.0 • Kerberos認証に対応 • 通信路の暗号化に対応
  43. 43. 43© Cloudera, Inc. All rights reserved. CDHへKuduが合流 • CDH 5.13 より CDH parcel に Kudu が取り込まれる • Cloudera の製品は Parcel と呼ばれるパッケージ形式で提供 • CDH 5 の Parcel(これにほどが⼊っているが...) • Kafka の Parcel • Spark 2系 の Parcel • Kudu の Parcel • Kudu 1.4 まではCDHとは別のParcelで提供されていた 〜Note〜 Parcelでインストールすると、 アップグレードなどもすべて Cloudera Managerから⼀元管 理できる
  44. 44. 44© Cloudera, Inc. All rights reserved. 最新のマニュアル • CDH 5.13 より、KuduはCDHに含まれるようになった • マニュアルもCDHに含まれるので古いものを参照しないよう注意 • 旧マニュアルは Kudu 1.4までのもの • Kudu 1.5/CDH 5.13 以降のマニュアルはこちら • https://www.cloudera.com/documentation/enterprise/latest/topics/kudu.ht ml ←古い
  45. 45. 45© Cloudera, Inc. All rights reserved. Kuduのインストール - サービスの追加 • Cloudera Managerより、数クリックでKuduのインストールが完了 • ⼊⼒する情報 • Kudu Master(マスターノード)とTabletServer(ワーカー)の配置 • WAL DirectoryとData Directoryの指定
  46. 46. 46© Cloudera, Inc. All rights reserved. Kuduサービスのホーム画⾯ • Cloudera ManagerよりKuduのメトリクス監視ができる
  47. 47. 47© Cloudera, Inc. All rights reserved. Impala連携の設定 • ImpalaからKuduにアクセスするには、Impala側に設定が必要 • Impala設定画⾯の「Kuduサービス」にてKudu選択するだけ
  48. 48. 48© Cloudera, Inc. All rights reserved. Hue(Impala経由)からのデータの投⼊ • Impalaと連携したKuduは、JDBC経由などでSQLにて処理を • もちろんHue経由でImpalaからKuduテーブルの作成や各種クエリを投げるこ とができる
  49. 49. 49© Cloudera, Inc. All rights reserved. Kuduのスキーマ設計とパーティション戦略
  50. 50. 50© Cloudera, Inc. All rights reserved. Kuduにおけるタブレットとパーティション • Kuduはパーティションを持ち、データを分割することができる • レンジパーティション • ハッシュパーティション • マルチレベルパーティション • レンジとハッシュの組合せ • 複数のハッシュの組合せ • Kuduのパーティションは、タブレットと対応する Tablet Partition パーティション に分割
  51. 51. 51© Cloudera, Inc. All rights reserved. レンジパーティション • レンジパーティションでは、完全に順序付けされたレンジパーティション キーを使って、⾏を分散させる • このパーティションキーは、主キーのサブセットである必要がある • ハッシュパーティションを併⽤しない場合、各レンジパーティションは、完 全に1つのタブレットと対応する • つまりレンジの個数だけ、タブレットが存在する
  52. 52. 52© Cloudera, Inc. All rights reserved. ハッシュパーティション • ハッシュ値によって、値を複数のバケットの1つに対応させる • ハッシュパーティション単⼀であれば、各バケットはそれぞれ1つのタブレッ トに⼀致する • バケットの数は、テーブル作成時に設定 • 通常は主キーをハッシュ⽤の列として使うが、主キー列のサブセットを使う こともできる • テーブルに順序アクセスをする必要がない場合は効果的 • 特に書き込みにおいて、ホットスポットや、タブレットサイズの不均衡を緩 和することに役⽴つ
  53. 53. 53© Cloudera, Inc. All rights reserved. マルチレベルパーティション • マルチレベルパーティションでは、0個以上のハッシュパーティションと、レ ンジパーティションを組み合わせることが可能 • 制約として、複数レベルのハッシュパーティションが、同じ列をハッシュし てはならない • マルチレベルパーティションでは、合計タブレット数は、各レベルのパー ティション数の積になる 〜Note〜 多⽤すると、タブレット数が膨⼤になる のでよく考えて設計をする
  54. 54. 54© Cloudera, Inc. All rights reserved. 適切なパーティションデザイン • タブレット数を意識 • タブレットはパーティションと対応、複数の種類のパーションを利⽤した 場合、その積になる • スキャンは1タブレットごとに1つのスキャナー • 基本的には、スキャンの並列度を考えると1ノードあたりのタブレットは多い ほうが良いが、CPUコア数を超過すべきではない • ⼤規模テーブルのタブレット数の⽬安 • CPUのコア数から並列度を考慮 • ⼩規模テーブルのタブレット数の⽬安 • 1タブレットに少なくとも1GB程度のデータが⼊るように調整 タブレット数 = ×ハッシュバ ケット1の数 ...×ハッシュバ ケット2の数 レンジの数
  55. 55. 55© Cloudera, Inc. All rights reserved. サイジングの⽬安 推奨される最⼤サイズ • 最⼤TabletServer(つまりワーカーノード)数は100 • TabletServerごとの最⼤タブレット数は、複製後2000 • TabletServerごとのデータサイズは、圧縮後で8TB • 最新のマニュアルを確認 ⼤量のパーティションと⼤量のスレッド • 現バージョンのKuduでは、1パーティション毎に最低でも2つの内部スレッ ドが⽣成される • 上記推奨値を越える様なパーティションを⽣成した場合、内部的にスレッ ドが⼤量⽣成され、動作に影響を与える可能性がある • 特にノード数が少ない場合に注意 • 効率よく動作するような改良を進めいている(KUDU-1913など) 〜Note〜 あくまで安全側に倒した値。適切なHW構 成やチューニングを⾏えば、これ以上で あっても動作する。
  56. 56. 56© Cloudera, Inc. All rights reserved. パーティションのプルーニング • Kuduは、スキャンの述語(いわゆる WHRER句)によって該当パーティショ ンを読む必要が無いと判断した時、⾃動的にそのパーティションの読み取り をプルーニング(スキップ)する • ハッシュパーティションのプルーニング • 全てのハッシュ列に等価(=)の述語を含める必要がある • レンジパーティションのプルーニング • レンジパーティション列に、等価(=)または範囲(<,>,≦,≧,etc.)を含む 必要がある
  57. 57. 57© Cloudera, Inc. All rights reserved. パーティション戦略 • ハッシュパーティションは書き込みスループットの最⼤化によい • レンジパーティションはタブレットの肥⼤化を防ぐことができる • 両者を組合せたマルチレベルパーティションでは、正しく設計できれば、両 者のメリットを享受することができる 戦略 書き込み 読み込み タブレットの肥⼤化 range(time) ❌全ての書き込みは最新の パーティションに⾏く ✅時間を指定して読み 込む場合、時間の境界 を超えた不要な読み取 りは発⽣しない ✅将来のレンジ⽤に、 新たなタブレットが追 加される hash(host, metric) ✅書き込みはタブレット全 体に均等に⾏く ✅特定のhostやmetricを スキャンする際、不要 な読み込みは発⽣しな い ❌各タブレットは肥⼤ 化する
  58. 58. 58© Cloudera, Inc. All rights reserved. パーティション vs インデックス パーティション • データをどのように複数パーティションに分散させるか • Kudu: tablet • HBase:region • Cassandra:vnode インデックス • 1パーティション内のデータをどのようにソートするか • 時系列データでは、⼀般に (series, time) でインデックス化する → なぜ? (us-east.appserver01.loadavg, 2016-05-09T15:14:00Z) (us-east.appserver01.loadavg, 2016-05-09T15:15:00Z) (us-west.dbserver03.rss, 2016-05-09T15:14:30Z) (us-west.dbserver03.rss, 2016-05-09T15:14:30Z) (2016-05-09T15:14:00Z, us-east.appserver01.loadavg) (2016-05-09T15:14:30Z, us-west.dbserver03.rss) (2016-05-09T15:15:00Z, us-east.appserver01.loadavg) (2016-05-09T15:14:30Z, us-west.dbserver03.rss) (series, time) (time, series)
  59. 59. 59© Cloudera, Inc. All rights reserved. 主キーのインデックスによるプルーニング • Kuduの主キーは、クラスターインデックスになっている • 1つのタブレット内にある全ての⾏は、主キーのソート順に保持される • スキャンの述語に、等価(=)、範囲(<,>,≦,≧,etc.)などがある場合、合 致しないものはIOをスキップする • 主キーによるプルーニングは、主キーのプレフィックスにのみ有効 • 複合主キーPK(A,B,C)があり、where C=‘...’ という条件をかけた場合、プレ フィックスではないのでプルーニングは起こらないので注意 • PK(series, time)はプルーニングされるが • PK(time, series)はプルーニングがされない (us-east.appserver01.loadavg, 2016-05-09T15:14:00Z) (us-east.appserver01.loadavg, 2016-05-09T15:15:00Z) (us-west.dbserver03.rss, 2016-05-09T15:14:30Z) (us-west.dbserver03.rss, 2016-05-09T15:14:30Z) (2016-05-09T15:14:00Z, us-east.appserver01.loadavg) (2016-05-09T15:14:30Z, us-west.dbserver03.rss) (2016-05-09T15:15:00Z, us-east.appserver01.loadavg) (2016-05-09T15:14:30Z, us-west.dbserver03.rss) (series, time) (time, series) SELECT * WHERE series = ‘us-east.appserver01.loadavg’;
  60. 60. 60© Cloudera, Inc. All rights reserved. レンジパーティションのメンテナンス • 実⾏時に、レンジパーティションを動的に追加及び削除可能 • この操作は他のパーティションの可⽤性に影響を与えない • パーティションの削除は、内部データも削除される • ⼀旦削除されたパーティションへの挿⼊は失敗となる • 追加に関しては、既存パーティションとレンジが重複してはいけない • alter table で操作可能
  61. 61. 61© Cloudera, Inc. All rights reserved. Impalaからの実際のテーブル構築例 ハッシュパーティションの例 コンポジットパーティションの例
  62. 62. 62© Cloudera, Inc. All rights reserved. Kuduと書き込みの⼀貫性 • Kuduのトランザクション設計は、2012年に出された、SpannerやCalvinの論⽂ を参考にして開発された • 将来的には複数⾏や複数タブレットにまたがったACIDトランザクション対応 に向けて進めている、現時点では⾏単位のACIDのみ対応 • まだコーナーケースに対応しきれてない • 実験的に幾つかの機能は提供している
  63. 63. 63© Cloudera, Inc. All rights reserved. Kuduと読み取りの⼀貫性 • Kuduは内部でMVCC(Multi-version Concurrency Control)を使っており、読 み込み時には、すでにコミットが完了したデータだけをみることができる • これは、リードつまり分析⽬的等でスキャンをする際、スキャン開始時点の データのスナップショット(断⾯)に対して読み取りを⾏う • WALとは別に、内部的にREDOとUNDOを⽤いている • よって、それ以降に裏側でデータの挿⼊や更新が⼊っても、読み取り時は⼀ 貫性を保ったまま分析処理を⾏うことができる 〜Note〜 過去の時間を指定することで、その時点 の静⽌断⾯をスキャンすることができる。 Kuduはこれをタイムトラベルリードと呼 んでいる。
  64. 64. 64© Cloudera, Inc. All rights reserved. 読み取り時のモード ⼤きく2種類 READ_LATEST(デフォルト) • タブレット内の最新のバージョンを読む • 単純に各タブレット上での最新の情報を⾒るだけなので、特定の静⽌断⾯ を⾒ているわけではない READ_AT_SNAPSHOT • 特定のタイムスタンプのバージョンを含んだ、MVCCのスナップショットを 取得し、それをスキャンする • 全ての書き込みにはタイムスタンプがタグ付けされているため、ある時間 断⾯のデータにアクセスができる(Repeatable Read)
  65. 65. 65© Cloudera, Inc. All rights reserved. 書き込みと読み込みの流れ 〜Note〜 WALはすべての書き 込み操作が記録され、 ディスクに保存され るため、ディスクが 遅いとここがボトル ネックとなりやすい。
  66. 66. 66© Cloudera, Inc. All rights reserved. Blog:Kuduにおけるリードとライトの流れ • Cloudera Engineering Blog - Apache Kudu Read & Write Paths • https://blog.cloudera.com/blog/2017/04/apache-kudu-read-write-paths/ • ⽇本語訳 • https://blog.cloudera.co.jp/11c3a749a81b
  67. 67. 67© Cloudera, Inc. All rights reserved. Kuduのステータス画⾯ • Kuduが持つ各種ステータス画⾯ • Masterは http://<マスターのIP>:8051 • TabletServerは各サーバーごとに http://<タブレットサーバーのIP>:8050 • Cloudera Managerはこれらの情報を集約して表⽰してるが... • Kudu側の画⾯でなければ得られない情報もある(細かいタブレットの配置な ど)
  68. 68. 68© Cloudera, Inc. All rights reserved. Kuduのステータス画⾯ • タブレットごとの各種情報など 〜Note〜 パーティションの実配置をみるのには、 この画⾯からみるのがよい。
  69. 69. 69© Cloudera, Inc. All rights reserved. Kuduのトレーシング機能 • サーバー内部のトレーシング機能 • トレースの記録を開始してから停⽌するまでの詳細なトレースを取得
  70. 70. 70© Cloudera, Inc. All rights reserved. Kudu環境の構築
  71. 71. 71© Cloudera, Inc. All rights reserved. インストール要件(Kudu 1.5 /CDH 5.13現在) Kudu 1.5よりCDH5.13に統合されたため、今後はCDH5.13のドキュメントを参照 • まだ過渡期のためKuduについては注記等があるので注意 ハードウェア構成 • CPU: SSSE3 及び SSE4.2 • マスターノード(Master): 1台(冗⻑性構成なし), 3台, 5台 • ワーカーノード(TabletServer): 任意台数 OS(⼀部抜粋) • RHEL/CentOS/Oracle Linux 6.4, 6.5, 6.6, 6.7, 6.8, 6.9, 7.1, 7.2, 7.3, 7.4 • Ubuntu 14.04, 16.04 • Debian 8.2, 8.4 • SLES 12 SP1 ファイルシステム • xfs, ext4 NTPによる時刻同期 • ずれていると起動しない(10秒ずれると強制終了) 参考ドキュメント https://www.cloudera.com/documentation/enterprise/release- notes/topics/rn_consolidated_pcm.html#pcm_kudu https://www.cloudera.com/documentation/enterprise/release- notes/topics/rn_consolidated_pcm.html#concept_mh3_sht_kbb
  72. 72. 72© Cloudera, Inc. All rights reserved. 推奨ハードウェア構成(Kudu 1.5 /CDH 5.13現在) ハードウェア推奨構成 • 基本的には⼀般的にHadoopが要求するものと同様 • ワークロードに応じて必要な構成は⼤きく変わるため、実際のサイジングには、POCなど の検証を⾏い検討をすることを強く推奨 • 実際にはKudu⾃⾝以外にも、ImpalaやHDFSやSparkなどが利⽤する分を考慮 CPU • ワークロードに応じて4〜16コアなど • IOの並列度とコア数を意識 メモリ • KuduのMasterは、あまりメモリーを使⽤せず、多くても1GB程度 • KuduのTabletServerは、ワークロード次第だが、10GB〜程度から始めて検証するとよい • 上記にプラスして相乗りするImpalaやHDFS、Spark等が利⽤する分を⾜す • 特にImpala利⽤時はImpalaが⼤量にメモリを必要とする点に注意 ディスク • 可能であればSSDの利⽤を強く推奨 • 詳細は後述のスライド ネットワーク • 10Gbps Ethernetを推奨、1Gbpsの線を使う場合は4Gbps(1Gbps x4)など複数本束ねる • 必要に応じてbondingなどの冗⻑構成を取る • 複数のネットワークを使い分けるようなマルチホームネットワークはサポート対象外
  73. 73. 73© Cloudera, Inc. All rights reserved. OK サーバーとネットワークトポロジー • マルチホームネットワークはサポート対象外 • サーバーが複数のネットワークに所属し、⽤途ごとに使うネットワークを 分けるような構成のこと 例1) サポートされるネットワーク構成 例2) サポートされないマルチホーム構成NG ... ... 外部へ 外部へ 参考ドキュメント:https://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html#cdh_cm_network_security 例えばノード間通信だけをこちらのネットワークを通したいなど
  74. 74. 74© Cloudera, Inc. All rights reserved. ロールの配置例 DNIDTS DNIDTS ZK NN KM ZK JN KMJN NN ZKKM JN ISS ICSHMS CM Kudu Master TabletServer Impala CatalogServer StateStore ImpalaDaemon Hive HiveMetaStore HDFS NameNode JournalNode DataNode ZooKeeper ZooKeeper その他 Cloudera Manager 任意のRDB ワーカー1 マスター1 マスター2 マスター3 ワーカーN NN JN DN ISS ICS ID ...... ZK CM KM TS RDB Cloudera Manager⽤ サーバー HMS RDB RDB アイコンの意味
  75. 75. 75© Cloudera, Inc. All rights reserved. HDFSは必要か? Kuduをメインで使う場合にもHDFSは必要なので注意 運⽤⾯(必須) • Kudu以外のHadoopエコシステムはHDFSがあることを前提としていることが多い • 実際のデータ保存だけでなく、運⽤やジョブの実⾏に際して、ノード間でのデー タ共有やログの保存なのど、様々な場⾯で使われる ⾮構造データの保存(任意) • Kuduは構造化データのみを扱うため、Kuduにinsertする前の⽣データなどを、⾮構 造化データとして保存する場合などには活躍する DRサイトの構築(任意) • 現時点で、KuduはCloudera ManagerのBDRに⾮対応であり、Kudu⾃⾝もHDFSの dstcpの様なクラスタ間レプリケーション機能を持っていない • Kuduのバックアップやクラスタ間レプリケーションを⾏う場合、HDFSにParquetと して書き出してBDRで別クラスタに転送する⽅法が取られる
  76. 76. 76© Cloudera, Inc. All rights reserved. 推奨ディスク構成 - OS領域 ⽤途 • ルートファイルシステム等のOS領域 • CDHを含む各種ソフトウェア • ログの保存 考慮点 • ルートファイルシステムを持つディスクが故障すると、OS全体が停⽌する恐れがあることを念頭に置く • マスターノード • 複数ノードで冗⻑構成が取ってはいるが、その重要度の⾼さから、RAID1などで可⽤性をもたせること を推奨 • ワーカーノード • 設計上ノードがダウンしても問題ないため、ルートファイルシステムを持つディスクを冗⻑化する必要 は本来はない • しかしワーカーがダウンした場合、該当ノードが持つデータの再複製と転送が⾏われるため、それによ る負荷を無視できない場合、要件次第ではルートファイルシステムを持つディスクを冗⻑構成にするこ とも検討 構成例 • ルートファイルシステム⽤に、1つのディスクまたはRAID1で冗⻑化された2つのディスクを使い、OS⾃⾝ やCDHを含む各種ソフトウェア⽤のディレクトリは、このディスクを使⽤ • 必要に応じて、CDHを含む各種ソフトウェア等が出⼒する「ログ」⽤のディレクトリは、専⽤ディスクを ⽤意する RAID1 / OS⽤
  77. 77. 77© Cloudera, Inc. All rights reserved. 推奨ディスク構成 - Kudu領域 ⽤途 • WALの保存:更新時のすべての操作がここに保存される • Dataの保存:ディスクにフラッシュされたデータが保存される 考慮点 • KuduはHDDも使えるが、SSDにより最適化されているため、SSDの利⽤を推奨 • 特にWALだけでも、SSDにすることを強く推奨 • マスターノード(Kudu Master) • Masterには管理⽤のTabletが1つずつあるだけなので、データ量負荷量共にそこま で⼤きくならない • マスターノードのKuduのWAL及びData⽤ディスクは KUDU-1620 のため、現時点 では、RAID1などで冗⻑化されたディスクに配置することを推奨 • ワーカーノード(Kudu TabletServer) • WAL⽤ディスクの負荷が⾮常に⼤きいため、WAL専⽤ディスクをSSDで⽤意する • Data⽤ディスクもSSD推奨だが性能要件が厳しくなければHDD複数のディスクを JBOD構成で⽤意する 構成例 • MasterにはSSDでRAID1を組みそこにWALとDataを保存 • TabletServerにはWAL⽤にSSD1本と、Data⽤にSSDかHDDで複数本 SSD SSD SSD SSD RAID1 wal, data SSD SSD ... wal data1 data2 dataN TabletServer⽤ Master⽤
  78. 78. 78© Cloudera, Inc. All rights reserved. 構成例 - マスターノード 各マスターノードのディスク構成例 OS • OS領域⽤ - HDD x2 (RAID1) Kudu • WAL+Data⽤ - SSD/HDD x1or2 HDFS • NameNode⽤ - HDD x2 (RAID1推奨) • JournalNode⽤ - HDD x1 • HDFSは様々な⽤途で利⽤されるためHDFS の設置は必要 • ただし主⽤途でなくアクセス負荷が低いこ とが予想されるなら、占有ディスクでなく Kuduのディスクと共⽤も可 ZooKeeper • Zookeeper⽤ - HDD/SSD x1 SSD SSD Kudu WAL+Data OS (RAID1) ZooKeeper 〜Note〜 Kudu⾃⾝はZooKeeperを使わない が、HMSやHDFSその他のサービス で使⽤される為、多くのケースで は必要とされる。 (RAID1) HDFS JN HDFS NN (RAID1)
  79. 79. 79© Cloudera, Inc. All rights reserved. 構成例 - ワーカーノード 各ワーカーノードのディスク構成例 OS • OS領域⽤ - HDD x1or2(RAID1も可) Kudu • WAL⽤ - SSD x1 • Data⽤ - SSD/HDD x複数本 • SSDに最適化されているがHDDも可 • TabletServerごとに保存可能な合計デー タサイズは、Kudu 1.5 / CDH 5.13 現在 8TBまでが⽬安 HDFS • DataNode⽤ - HDD x複数本 • KuduとHDFSはアクセス特性が異なる ため、ディスクは分けた⽅がよいが、 ⽤途次第ではではKuduとディスクの共 有もあり SSD SSD SSD SSD... Kudu WAL OS Kudu Data HDFS DN ...
  80. 80. 80© Cloudera, Inc. All rights reserved. ディスクのJBOD構成について • HDFSのDataNode⽤データディレクトリ、KuduのTabletServer⽤データディレクトリ は、複数本のディスクをJBOD(Just Bunch Of Disks)で構成する • JBODとは、RAIDなどを設定せず各ディスクをそのままOSに認識させること • JBODで性能が出るような実装がされている • 例えば4本のディスクがある場合 • 例1)それぞれをOS上で個別のブロックデバイス(/dev/sdb, /dev/sdc, /dev/sdd, /dev/sdf など) として認識できるようにし、それらをHDFSやKuduに使わせる • 例2)ハードウェアRAIDが既に組み込まれておりかつJBODモードが設定上できな い場合などは、4本それぞれを個別に「1ディスクだけのRAID0構成」として、OS 上から4本個別に認識できるようにしておくことはOK • 例3)RAID 0, 5, 6 などで4本を1つにストライピングする構成は⾮推奨 RAID0 RAID 0/5/60 0 0 0 例1) 通常のJBOD構成 例2) RAID0でのJBOD構成 例3) ストライピングNGOK OK
  81. 81. 81© Cloudera, Inc. All rights reserved. クラウドに構築する場合は? • クラウド環境に構築する場合はReference Architectureの資料を参考 • リファレンスアーキテクチャの公開ページ • https://www.cloudera.com/documentation/other/reference- architecture.html • AWS • http://www.cloudera.com/documentation/other/reference- architecture/PDF/cloudera_ref_arch_aws.pdf • Azure • http://www.cloudera.com/documentation/other/reference- architecture/PDF/cloudera_ref_arch_azure.pdf • GCP • http://www.cloudera.com/documentation/other/reference- architecture/PDF/cloudera_ref_arch_gcp.pdf
  82. 82. 82© Cloudera, Inc. All rights reserved. Cloudera Directorによるクラウド環境への⾃動構築 • Hadoopクラスターをクラウド上でデプロイ&管理するためのツール • ベストプラクティスを再利⽤可能な構成ファイルで提供 • クラスターのライフサイクル(grow & shrink)を管理 • Cloudera Manager との管理の同期 クラウド (AWS/Azure/GCP)Cloudera Director Client インスタンス インスタンス インスタンス Cloudera Director Server インスタンス インスタンス インスタンス 起動
  83. 83. 83© Cloudera, Inc. All rights reserved. Cloudera Directorを⼊れてクラウドにCDHクラスタを作ろう • 主にデモ環境や開発環境を作る視点で、Cloudera Directorをシンプルに使って、 クラスターを構築する例 • https://blog.cloudera.co.jp/getting-started-cloudera-director-35405d421084 • Cloudera Directorの構成ファイル • https://github.com/takabow/impala-demo-env
  84. 84. 84© Cloudera, Inc. All rights reserved. おわりに
  85. 85. 85© Cloudera, Inc. All rights reserved. Kuduまとめ Apache Kuduとは? • ⼤規模データ(ペタバイト、1000億⾏以上)を扱えるデータベース • SQLを使って構造化データを分析 • 更新(INSERT/UPDATE/DELETE)を⾏いつつ、⼤規模スキャン(SELECT)可能 • HTAP: OLTPとOLAPの融合 Kuduで分析システムをつくるには? • 複数ノードで分散並列処理 • スキーマ設計パーティション戦略が重要 • 各ノードのディスクは複数本⽤意、SSDの利⽤を推奨 • あとはリレーショナルDBのようにSQLアクセスで分析!
  86. 86. 86© Cloudera, Inc. All rights reserved. Thank you takahiko at cloudera.com

×