Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

「新製品 Kudu 及び RecordServiceの概要」 #cwt2015

6,542 views

Published on

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

Published in: Technology
  • Be the first to comment

「新製品 Kudu 及び RecordServiceの概要」 #cwt2015

  1. 1. 1  ©  Cloudera,  Inc.  All  rights  reserved.   新製品Kudu  及びRecordService  の概要 セキュリティ強化  +  ファストデータの⾼高速分析 Amr  Awadallah  |  Cloudera  共同創業者、CTO Twitter:  @awadallah
  2. 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. 3  ©  Cloudera,  Inc.  All  rights  reserved.   アジェンダ Kudo  とは?  (動機と⽬目標) ユースケース デザインと内部構造概要   簡単なベンチマーク 現状、そしてこれから始めるには
  4. 4. 4  ©  Cloudera,  Inc.  All  rights  reserved.   Kudu  とは  ?
  5. 5. 5  ©  Cloudera,  Inc.  All  rights  reserved.   Hadoop  の現状のストレージランドスケープ HDFS  の優位点: •  ⼤大量量データの効率率率的なスキャン •  ⾼高スループットでデータを蓄積 HBase  の優位点: •  各⾏行行に対する効率率率的な検索索と書き込み •  データは変更更可能 こうした特性が同時に必要な場合、ギャップ が発⽣生する Hadoop  の   ストレージに 存在する「ギャップ」
  6. 6. 6  ©  Cloudera,  Inc.  All  rights  reserved.   •  ⼤大規模なスキャンを⾼高スループットで実⾏行行 •  低レイテンシでランダムアクセスを実⾏行行 •  ⾼高いCPUパフォーマンスを確保するため、RAMと フラッシュの優位性を活⽤用 •  1カラムのスキャンレートを、HBase  の  10~∼100倍⾼高速に •  ⾼高効率率率  I/O •  型独⾃自のエンコーディングによる、カラムストア •  特定のカラムにアクセスする場合の効率率率的な分析 •  叙述的(Expressive)で進化可能なデータモデル •  マルチデータセンター運⽤用が可能なアーキテクチャ Kudu  の設計⽬目標
  7. 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. 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. 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. 10  ©  Cloudera,  Inc.  All  rights  reserved.   Kudu  は何ではないか •  SQL  インタフェースそのものではない   •  ストレージレイヤに過ぎない  -  「SQLは⾃自分で⽤用意」(例例えば  Impala  や  Spark) •  HDFS上で稼働するアプリケーションではない •  ネイティブな  Hadoop  ストレージエンジン •  HDFSと共存させるのが望ましい •  HDFSやHBase  を置き換えるものではない •  適切切なユースケースに適切切なストレージを選択 •  Cloudera  はこれらを引き続きサポート、投資する
  11. 11. 11  ©  Cloudera,  Inc.  All  rights  reserved.   Kudu  のユースケース
  12. 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. 13  ©  Cloudera,  Inc.  All  rights  reserved.   業界適⽤用例例 •  ストリーミングマーケット データ •  リアルタイム不不正検知と防御 •  リスクモニタリング •  リアルタイム商品提案 •  ローケーションベース ターゲティング •  地理理空間モニタリング •  リスクおよび侵⼊入の検知 (リアルタイム) ⾦金金融サービス ⼩小売 公共
  14. 14. 14  ©  Cloudera,  Inc.  All  rights  reserved.   現在の  Hadoop  のリアルタイム分析 実世界における不不正検知  =  ストレージが複雑になりがち 考慮点: ●  プロセス実⾏行行中に障害が発⽣生した 場合の対処⽅方法は? ●  レポーティング⽤用フォーマットに、 どの程度度の頻度度でストリーミング データを再構成し投⼊入すればよい のか? ●  レポーティングする場合、データ がまだ再構成されていないことを どう確認すればよいのか? ●  重要なジョブがメンテナンスで 停⽌止しないようにするには? 新規のパーティション 直近⽤用のパーティション 過去データ HBase Parquet   File ⼗十分にデータが 蓄積されたか  ? HBase  ファイル をParquet  に 再構成 •  実⾏行行処理理の完了了を待機 •  新しく書き込まれた  Parquet  ファイルを 参照し、新規  Impalaパーティションを定義 ⼊入⼒力力データ   (メッセージング システム) レポーティング リクエスト Impala  on  HDFS
  15. 15. 15  ©  Cloudera,  Inc.  All  rights  reserved.   Kuduを使⽤用したHadoop  のリアルタイム分析 ハイブリッドアプリーチに⽐比べ、シンブルでより優れたパフォーマンスのアーキテクチャ Impala  on  Kudu ⼊入⼒力力データ  (メッセージング システム) レポーティング リクエスト
  16. 16. 16  ©  Cloudera,  Inc.  All  rights  reserved.   デザインと内部構造
  17. 17. 17  ©  Cloudera,  Inc.  All  rights  reserved.   Kudu  の基本的なデザイン •  型付けされた  (typed)  ストレージ •  基本構造:  テーブル   •  テーブルはタブレットに分解される  (ほぼパーティションと同義) •  Paxos  に似たクォーラムモデル  (Raft)  により、⼀一貫性を維持 •  地理理的に離離れた、アクティブ/アクティブなシステムをサポートするアーキテクチャ
  18. 18. 18  ©  Cloudera,  Inc.  All  rights  reserved.   テーブルとタブレット •  テーブルはパーティションに⽔水平分割される •  範囲パーティショニング  または  ハッシュパーティショニング •  プライマリキー(ホスト、メトリック、タイムスタンプ)は、ハッシュ(タイムスタンプ)により 100以上のバケットに分散 •  各タブレットは  Raft  コンセンサスで、N個(3または5)の複製を持つ •  任意のレプリカからの読み込み、低いMTTRでリーダ主導の書き込みが可能 •  タブレットサーバがタブレットを保持する •  データはローカルディスクに保存(HDFSは不不要) 18  
  19. 19. 19  ©  Cloudera,  Inc.  All  rights  reserved.   クライアント メタキャッシュ
  20. 20. 20  ©  Cloudera,  Inc.  All  rights  reserved.   Client   Meta  Cache   「todd@cloudera.com  の⾏行行はテーブルTのど こにありますか?」(Masterに尋ねる)
  21. 21. 21  ©  Cloudera,  Inc.  All  rights  reserved.   クライアント メタキャッシュ 「todd@cloudera.com  の⾏行行はテーブルTのど こにありますか?」(Masterに尋ねる) サーバ  {Z,Y,X}  の  タブレット2にあります。 さらに、他のタブレット:T1,T2,T3,  ...  についての情 報もあります
  22. 22. 22  ©  Cloudera,  Inc.  All  rights  reserved.   クライアント 「todd@cloudera.com  の⾏行行はテーブルTのど こにありますか?」(Masterに尋ねる) サーバ  {Z,Y,X}  の  タブレット2にあります。 さらに、他のタブレット:T1,T2,T3,  ...  についての情 報もあります メタキャッシュ T1:  … T2:  … T3:  …
  23. 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. 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. 25  ©  Cloudera,  Inc.  All  rights  reserved.   メタデータ •  マスタは複製される  (Replicated  master)  * •  タブレットのディレクトリとして機能  (“META”  テーブル) •  カタログとして機能(テーブルスキーマなど) •  ロードバランサーとして機能(TS  の⽣生存を追跡、レプリケーション中の タブレットの再レプリケーション) •  パフォーマンス確保のためすべてのメタデータをRAMにキャッシュ •  80ノードによるロードテスト、GetTableLocations  RPC  のパフォーマンス: •  99パーセンタイル:68us、99.99パーセンタイル:657us   •  CPU使⽤用率率率はピークで  2%  未満 •  マスタのアドレスをクライアントに設定 •  必要に応じてマスタにタブレットの場所を問い合せてキャッシュする 25  
  26. 26. 26  ©  Cloudera,  Inc.  All  rights  reserved.   Kudu  のトレードオフ •  ランダムアクセスの速度度劣劣化 •  HBase  モデルは、ディスクシーク無しにランダムアップデートが可能 •  Kudu  はアップデート前のキー検索索、インサート前の  Bloom検索索が必要 •  1⾏行行だけの  READ  速度度が劣劣化する場合がある •  カラムナはスキャンに対して最低化されたデザインになっている •  今後:  1⾏行行だけのアクセスが重要がアプリケーションのために、カラムグループ  (Column  groups)  を提供予定
  27. 27. 27  ©  Cloudera,  Inc.  All  rights  reserved.   ベンチマーク
  28. 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. 29  ©  Cloudera,  Inc.  All  rights  reserved.   -‐‑‒  RAM上のデータに対して、Kudu  が  Parquet  を  31%  上回る(幾何平均) -‐‑‒  HDD内のデータ(より⼤大きな  I/Oリクエスト)に対しては、Parquet  が  Kudu  を上回ると想定される
  30. 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. 31  ©  Cloudera,  Inc.  All  rights  reserved.   NoSQL  スタイルランダムアクセス  (YCSB) •  YCSB  0.5.0-‐‑‒スナップショット •  10  ノードクラスタ (9  ワーカ、1  マスタ) •  HBase  1.0 •  ⼀一億⾏行行、⼗十億ops 31  
  32. 32. 32  ©  Cloudera,  Inc.  All  rights  reserved.   Xiaomi  ユースケース •  モバイルアプリやバックエンドサービスから、重要な  RPC  トレーシングイベントを収集 •  サービスモニタリングおよびトラブルシューティング⽤用ツール •  優れた  WRITE  スループット •  1⽇日  50  億超のレコード、さらに成⻑⾧長中 •  最新データをクエリし、素早く応答 •  問題を迅速に特定し解決することが可能 •  個別レコードの検索索が可能 •  容易易なトラブルシューティング
  33. 33. 33  ©  Cloudera,  Inc.  All  rights  reserved.   ビッグデータ分析パイプライン Kudu  以前 •  ロングパイプライン ⼤大きなレイテンシ(1時間~∼1⽇日)、データ変換がネック •  順序付けがない ログの到着(ストレージ)順序がそのまま論論理理的な順番とは限らない 例例えば、1⽇日のログ確認に2~∼3⽇日のログの読み込みが必要
  34. 34. 34  ©  Cloudera,  Inc.  All  rights  reserved.   ビッグデータ分析パイプライン Kudu  による簡素化 •  ETL  パイプライン  (0~∼10秒のレイテンシ) バックプレッシャーを避ける必要がある、あるいは  ETLが必要なアプリ •  ダイレクトパイプライン(レイテンシなし) ETLを必要としないバックプレッシャーの問題のないアプリ   OLAP  スキャン サイドテーブル検索索 結果のストア
  35. 35. 35  ©  Cloudera,  Inc.  All  rights  reserved.   ユースケース1:ベンチマーク 環境 •  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. 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. 37  ©  Cloudera,  Inc.  All  rights  reserved.   現状、そしてこれから始めるには
  38. 38. 38  ©  Cloudera,  Inc.  All  rights  reserved.   現状 ✔ アーキテクチャのコアとなるコンポーネントはすべて完了了 ✔ Java  と  C++  API ✔ Impala、MapReduce  および  Spark  の統合 ✔ SSD  と  HDD  をサポート ✔ フォールトリカバリ ✔ パブリックベータ利利⽤用可能
  39. 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. 40  ©  Cloudera,  Inc.  All  rights  reserved.   ご静聴ありがとうございました
  41. 41. 41  ©  Cloudera,  Inc.  All  rights  reserved.   Appendix  
  42. 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. 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. 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. 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  

×