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.

ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -

4,058 views

Published on

ビッグデータ処理基盤の分野では、オンプレ・クラウド問わず様々なプロダクトが続々と登場していますが、それぞれの位置づけを明確にします。また代表的なプロダクトについて紹介し、使い分けを明確にします。具体的には、Amazon Redsfhit Spectrum, Cloud Spanner, Big Query, Oracle Exadata, MapR, cloudera, Hortonworks, EMR, Cloud Dataproc, Azure HDInsight, Amazon Athena, TREASURE DATA、Amazon DynamoDB, Azure Cosmos DB, cassandra, HBase, redis, MongoDB, TERADATA, NETEZZA,等を紹介します。

Published in: Data & Analytics
  • p14にHadoopのSQLではトランザクション、DELETE、UPDATEは無い って記載がありますが、Hiveでは機能が提供されているため、誤りとなります。ご認識下さい。 https://cwiki.apache.org/confluence/display/Hive/Hive+Transactions https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DML#LanguageManualDML-Update。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -

  1. 1. (C) Recruit Technologies Co.,Ltd. All rights reserved. ビッグデータ処理データベースの 全体像と使い分け 2017/9/6 株式会社リクルートテクノロジーズ ビッグデータ部 渡部徹太郎 2017年 Version
  2. 2. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department自己紹介 {"ID" :"fetaro" "名前":"渡部 徹太郎" "研究":"東京工業大学でデータベースと情報検索の研究 (@日本データベース学会)" "仕事":{前職:["証券会社のオンライントレードシステムのWeb基盤", "オープンソースなら何でも。主にMongoDB,NoSQL"], 現職:["リクルート分析基盤,Exadata,Hortonworks,EMR"] 副業:["MongoDBコンサルタント" ]} "エディタ":"emacs派", "趣味": ["自宅サーバ","麻雀"] } 1
  3. 3. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentリクルートテクノロジーズ ビッグデータ部  リクルートのサービス  ビジネスモデル  「リボンモデル」 2 カスタマ (ユーザ) クライアント (企業)  主業務  分析:KPIの測定/競合分析  施策:マッチング/ユーザ属性推 定/ターゲッティング  ミッション  ビッグデータ処理を駆使して 売上向上・コスト削減  いろんなユースケースに併せて 適材適所の基盤を用意 ・・・100以上のサービス
  4. 4. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department発表をしようと思った背景  適材適所をするためには、ビッグデータ処理技術全体を把握必要がある 3 Amazon DynamoDB Kinesis Amazon EMR Amazon Redshift Google BigQuery Oracle Exadata Impala Google Cloud Spanner Cloud Dataproc Azure HDInsight
  5. 5. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department目次 1. データベースの分類 2. データベースの紹介 3. その他のビッグデータキーワードの説明 4. リクルートテクノロジーズにおける使い分け 5. まとめ 4
  6. 6. (C) Recruit Technologies Co.,Ltd. All rights reserved. 1. データベースの分類 5
  7. 7. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentデータベースを分類する軸:重視する性能 6  レスポンスを重視  主にオペレーション用途  少量のデータに対するランダムアクセス  行志向アクセス アプリケーションサーバ オペレーション 用途 データベース 登録画面 リクエスト 参照 更新 挿入 参照画面 編集画面 即時応答 1 1982年生 2 1967年生 3 2000年生 4 2000年生 男 女 女 男 ID 年齢性別 ID=2のデータを取り出すのは高速 年齢の集計は低速 1 1982年生男 2 1967年生女 3 2000年生女 4 2000年生男 1 2 3 4 index この方向のアクセスが高速 インデックス ディスク上の配置
  8. 8. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentデータベースを分類する軸:重視する性能 7  スループットを重視  主に分析用途  大量のデータに対するレンジアクセス  列志向アクセス マスタ データベース BIツール 集計 バッチ ロード 分析用途 データベース レポート生成 ジョブ 抽出 CSV バッチ ロード レポート 20分で全件集計 10秒で全件取得 1 1982年生 2 1967年生 3 2000年生 4 2000年生 男 女 女 男 ID 年齢性別 メモリ 性別 男 女 1男 4 女 1982年生 1967年生 2000年生1 2 3 42 3 年齢 1982年生 1967年生 2000年生 ディスク上の配置この方向のアクセスが高速 ID=2のデータ取り出すのは低速 年齢の集計は高速 インデックス
  9. 9. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department  スケールアップ型(整合性重視)  ハードウェアのスペックを向上させる  トランザクションの提供など、強い整合性を提供するために、 スケールアップせざるを得ない  特別なハードウェアが必要になり、一般的に高価 データベースを分類する軸:性能向上の方法 8 app app app app app app スケールアップ 性能限界 CPU↑ ディスク↑ メモリ N/W↑ 1 2 3 4 1 2 3 4 5 6 7 8
  10. 10. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department  スケールアウト型(拡張性重視)  一般的なハードウェアを複数台用意し、負荷を分散  結果整合性。トランザクションは提供しない。 データベースを分類する軸:性能向上の方法 9 スケールアウト性能限界 app app app 1 2 3 4 app app app 1 2 3 5 6 7 84 Master
  11. 11. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentデータベースの分類 10 レスポンス重視 (オペレーション用途) スループット重視 (分析用途) スケールアップ(整合性重視) RDB(OLTP) NoSQL Hadoop RDB(DWH) スケールアウト(拡張性重視)
  12. 12. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department BigQuery データベースの分類 11 レスポンス重視 オペレーション用途 スループット重視 分析用途 スケールアップ DynamoDB Redshift EMR Exadata Athena RDS RDB(OLTP) NoSQL Hadoop RDB(DWH) スケールアウト Cloud Dataproc Azure HDInsight Azure SQL Database Cloud Spanner
  13. 13. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department BigQuery データベースの分類 12 レスポンス重視 オペレーション用途 スループット重視 分析用途 スケールアップ DynamoDB Redshift EMR Exadata Athena RDS RDB(OLTP) NoSQL Hadoop RDB(DWH) スケールアウト Cloud Dataproc Azure HDInsight Azure SQL Database Cloud Spanner 越えられない壁 BigDataの事例の大半はココ
  14. 14. (C) Recruit Technologies Co.,Ltd. All rights reserved. RDB(DWH) 13 オペレーション 分析用途 RDB(OLTP) NoSQL スケールアップ スケールアウト Hadoop RDB(DWH) BigQuery Cloud Spanner
  15. 15. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department オンプレ サービス アプライアンス ソフトウェア RDB(DWH)の概要  ひとことで言うと  データの抽出・集計に特化したRDB  アーキテクチャの特徴  データをパーティショニングして複数ディスクから同時に読む (製品によっては)ハードウェアを最適化して、アプライアンスとして提供  列志向で圧縮してデータ格納 14 Amazon RedshiftExadata
  16. 16. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentRDB(DWH)の用途  処理イメージ  レスポンス:数秒、数分  データサイズ:直近13ヶ月(1T〜数10T)  計算:SQLベース  UPDATE,DELETE,トランザクションはできるが遅い  ユースケース  アドホック分析、OLAP  レポート  BIツールのデータソース  EDW(Enterprise Data Warehouse)ともよばれる 15
  17. 17. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department ストレージノード ストレージノード ストレージノード RDB(DWH)の注目プロダクト (1/2)  Oracle Exadata  ソフトウェアとハードウェアを密結合して、高いパフォーマンスを発揮  基本はオペレーション用途だが、分析もできる • →「二兎追うものは一兎も得ず」な部分はある 16 データベースノード HDD SSD 絞込み処理 HDD HDD HDD HDD SSD 絞込み処理 HDD HDD HDD HDD SSD 絞込み処理 HDD HDD HDD データベースノード CPU WHERE句を解釈し、 読み込むブロックを最小化 ディスクIOを削減 キャッシュして ディスクIOを削減 CPUを多数搭載 40Gbpsのラック内SAN CPU CPUCPU CPU CPU 40G bps
  18. 18. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentRDB(DWH)の注目プロダクト (2/2)  Amazon Redshift Spectrum  RedShiftの裏にS3のデータをフィルタするSpectrum Layerを用意  IOのスループットを向上 17 Spectrum Layer (不可視領域) Data Catalog L C C C SQL S3 Get S S S S ・ ・ ・ S3 RedShift
  19. 19. (C) Recruit Technologies Co.,Ltd. All rights reserved. Hadoop 18 オペレーション 分析用途 RDB(OLTP) スケールアップ スケールアウト Hadoop RDB(DWH) BigQuery NoSQL Cloud Spanner
  20. 20. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentHadoopの概要  ひとことで言うと  分散したファイルに、様々 な分散処理をできるソフト ウェア群  アーキテクチャの特徴  データはファイル  ストレージと処理が分離  途中でノードがダウンして も処理を継続 1919 分散ファイルシステム 分散処理エンジン ABC A B C クライアント 計算 ノード 計算 ノード 計算 ノード コーディネータ ①データの配布 ②提出 ③計算 計算 結果 プログラム プログラム クライアント プログラムプログラム
  21. 21. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentHadoopのプロダクト  SQL on Hadoopとは  Hadoop上の分散集計を SQLで表現できる  基本はSELECTとLOAD のみ  UPDATE,DETELEは出 来ない  トランザクションがない 20 プロダクト 分散ファイルシ ステム 分散処理エンジン オンプレ MapR-FS マネージ ド Hadoop クエリ サービス EMR S3 Impala Cloud Dataproc GCS Athena SQL on Hadoop S3 Azure BLOB Storage Azure HDInsight
  22. 22. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentHadoopの用途  処理のイメージ  レスポンス:数十分〜数時間  データサイズ:全データ(10T〜数P)  計算:分散できる計算なら何でも  ユースケース  長期的なビジネストレンド分析  RDB(DWH)に入れる前のデータ加工  機械学習による予測、クラスタリング  自然言語処理  Datalakeを担うことも有る 21
  23. 23. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentクラウドのHadoop  特徴  分散処理エンジンとストレージの分離  データはオブジェクトストレージに格納  計算ノードは使い捨て。 負荷に応じて計算ノードの台数変更  Hortonworks, Clouderaも対応 22 Slave Slave Slave HDFS(MapR-FS) オブジェクトストレージ Master データ データ コンテナ データ データ コンテナ データ データデータ データ 計算 コンテナ Master コンテナ 計算 コンテナ 計算 コンテナ オンプレのHadoop クラウドのHadoop NEWNEW データ移動 が必要 データ移動 不要 0:00 12:00 0:00 12:00 ク ラ ス タ 起 動 台 数 オンプレ クラウド 計算に必要なリソース
  24. 24. (C) Recruit Technologies Co.,Ltd. All rights reserved. BigQuery 23 オペレーション 分析用途 RDB(OLTP) スケールアップ スケールアウト Hadoop RDB(DWH) BigQuery NoSQL Cloud Spanner
  25. 25. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentBigQuery  BigQueryとは  GoogleがHadoop(Hive)を進化させて作った分散SQLエンジン  クエリ課金  速度が別格(1TBを1秒でスキャン)  GROUP BYやJOIN等の重い処理は、処理量に合わせて計算ノードを動 的に割り当てて実行。利用できるノードは1000台 24 分散ストレージ Colossus File System シャード シャード シャード シャード シャード ミキサー ミキサー ミキサー ルート ミキサー 参考)オライリー・ジャパン社「BigQuery」
  26. 26. (C) Recruit Technologies Co.,Ltd. All rights reserved. NoSQL 25 オペレーション 分析用途 RDB(OLTP) スケールアップ スケールアウト Hadoop RDB(DWH) BigQuery NoSQL Cloud Spanner
  27. 27. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentNoSQLの概要  ひとことで言うと  分散して、シンプルなオペレーションができるデータベース  アーキテクチャの特徴  RDB(OLTP)とは異なり、 以下の2つによりスケーラビリティを獲得 1. 「強い整合性」を犠牲にして「結果整合性」を採用 2. 分散しやすいデータモデルと、分散しやすいクエリだけを提供する 26 データモデル キーバリュー ワイドカラム ドキュメント データ構造 オンプレ クラウド キー 値 キー 値 キー 列 Amazon ElastiCache Amazon DynamoDB array hash 階層構造
  28. 28. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentNoSQLがなぜスケールできるか  分散しやすいデータモデル  データ間の参照関係を定義させない  分散しやすいクエリ  一つのデータでクエリが完結するようにする • トランザクションを提供しない • (トランザクショナルな)JOINを提供しない 27 ユーザ1 取引1 取引2 ユーザ1 取引1 トランザクション 取引2 参照 制約 結合
  29. 29. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentNoSQLがなぜスケールできるか  レガシーな手法(2PC)では整合性を保証するとスケールアウトが困難  整合性を緩めればスケールアウトできる 28 アプリケーション アプリケーション 整合性は 保証される ②準備O K ④コミッ ト ②準備O K ④コミッ ト ②準備O K ④コミッ ト ①コミット準備の確認 ③コミット指示 アプリケーション アプリケーション 待たされ る A B C 分散トランザクションで ABCを一括更新 アプリケーション 待たされ る 待たされる アプリケーション スケールアウト構成 更新 一括更新はできないので A→B→C の順番で更新 A B C 更新 アプリケーション アプリケーション アプリケーション アプリケーション 更新 更新 更新 待たない 更新 更新 割り込まれて 整合性が 崩れる 可能性あり
  30. 30. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentNoSQLとHadoopの違い  NoSQL 29 分散ファイルシステム (HDFS等) 分散処理フレームワーク (MapReduce, Spark等) ABC A B C クライアント 計算 ノード 計算 ノード 計算 ノー コーディネータ ①データの配 ②提出 ③計算 計算 結果 プログラム プログラム クライアント プログラムプログラム NoSQL シャード シャード シャード A クエリルータ B C アプリケー ション2 アプリケー ション1 クエリA クエリB  Hadoop
  31. 31. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentNoSQLの用途  ユースケース  大規模Webのバックエンド • ユーザセッションの格納 • ユーザ属性格納 • 事前計算データのキャッシュ  メッセージングシステム  できないこと  トランザクション  集計  JOIN  セカンダリインデックス(無いものもある) 30
  32. 32. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentNoSQLはバズワード  NoSQL ≠ スキーマレス  スキーマ定義が必須  ドキュメントバリデーション機能あり  NoSQL ≠ SQLが使えない  多くのNoSQLはSQLライクなクエリ言語を採用  NoSQL ≠ スケールアウト  JSONが入るRDBはたくさんある 31
  33. 33. (C) Recruit Technologies Co.,Ltd. All rights reserved. Google Cloud Spanner 32 オペレーション 分析用途 RDB(OLTP) スケールアップ スケールアウト Hadoop RDB(DWH) BigQuery NoSQL Cloud Spanner
  34. 34. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentGoogle Cloud Spanner  一言で言うと  トランザクションを提供でき、かつワールドワイドで分散できるRDB  どうやっているか  トランザクションで「読み取り専用」か「ロック型読み書き」を宣言  読み取り専用の場合は、ロックを取らず、タイムスタンプで読むデータを判断す る  ノード間で時刻を正確に同期する必要があるが、それは不可能  代わり、コミットを待つこと(よりロックを長くとる)により、 ノード間の時間の差を吸収できるよう待つにする  各データセンタに電子時計を配置し、 ノード間の時刻の差を最小化 →コミットの待ち時間を最小化 33 tx2 tx1 tx3 t tx1完了時点のタイムスタンプの データを読み取る
  35. 35. (C) Recruit Technologies Co.,Ltd. All rights reserved. 3. その他のビッグデータキーワードの説明 34
  36. 36. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentSpark  データサイエンティストのために作られた分析ライブラリ群  Hadoopが無くても動く  データベースではない  データ蓄積はHadoopのHDFSでもよいし、そうでなくても良い  以下の様なものが含まれる  Spark 本体 :メモリベースで集計などをする  Spark MLLib:機械学習  Spark SQL:SQLライクなインターフェース  Spark Stream:マイクロバッチ 35
  37. 37. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentマイクロバッチ  続々と流れてくるデータに対して、短い期間で集計を行う処理  データベースではない。データを永続化しない。  使いドコロ  初回来訪者の属性推定  デバイス異常値検出 36 Kinesis Analytics Kinesis Streams マイクロバッチ マイクロバッチ PUB (出版) SUB (購読) 分散キュークライアント クライアント クライアント クライアント Cloud PubSub
  38. 38. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department ディスク ディスク インメモリデータグリッド  KVSに似ているが、アプリケーションのローカルに置かれるキャッシュ  メモリ上での処理を前提として、永続化はオプション  ユースケース  金融の取引処理  ミリ秒以下の応答時間 37 Javaアプリ インメモリDB Javaアプリ インメモリDB メモリ 同期
  39. 39. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentElasticsearch  検索エンジン  ドキュメントデータベースに非常に近い  JSONが入る  レプリケーションできる  シャーディング出来る  ドキュメントデータベースとの違い  Kibanaと連携できる  全文検索が強力  集計できる 38 Elasticsearch Service Kibana
  40. 40. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentグラフDB  グラフ演算に特化したDB  RDB以上にスケールアウトできない  ユースケース  最短経路探索  金融取引の詐欺検出  ソーシャルネットワークにおける人物間の計算  RDBだとJOINの多重入れ子になるような計算 39 ノード リレー ション ノード ノード リレー ション
  41. 41. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentその他のビッグデータキーワードをマッピングすると 40 レスポンス重視 (オペレーション用途) スループット重視 (分析用途) RDB(OLTP) NoSQL スケールアップ スケールアウト グラフデータベース マイ クロ バッ チElasticSearch インメモリ データ グリッド Hadoop RDB(DWH) BigQueryCloud Spanner
  42. 42. (C) Recruit Technologies Co.,Ltd. All rights reserved. 4.リクルートテクノロジーズにおける使い分け 41
  43. 43. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentビッグデータ処理の主な活用先  データドリブンな意思決定支援  KPIの測定  レポート  Webマーケティング  ターゲティングメール/広告  UI改善  画面のパーソナライズ  アイテムのレコメンド 42
  44. 44. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentデータドリブンな意思決定支援  目的  KPIを測定するために、データを集計する  DBの要件  BIツールとの接続  アドホックな分析クエリがメイン  SQLによる集計がメイン  SLAは低い:停止しても直接的な利益影響なし  選択  BI接続、アドホック分析はBigQuery  データ前処理・加工・マート作成はHadooop 43 Amazon Redshift Impala← ← ← ←BigQuery 15ヶ月分(1年+1四半期)の データに対する 数秒〜数分のクエリ
  45. 45. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department  目的  個人に最適化されたメール/広告を出すことにより、集客コストを下げる  DBの要件  統計解析・機械学習が出来る  バッチ処理がメイン  SLAは高い:メール・広告が出せないと売上棄損が有る可能性がある  選択  豊富な計算力を求める場合はHadoop  特に高いSLAを求める場合 かつ SQLで十分ならばRDB(DWH) Webマーケティング ターゲティングメール・広告 44 EMR Exadata
  46. 46. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA DepartmentUI改善  目的  個人の属性を推定して、UIをパーソナライズし、コンバージョンレートを上げる  DBの要件  統計解析・機械学習が処理できること  バッチ処理メイン  計算した推定結果を、Webサイトに提供する  SLAは中程度:バッチに失敗した場合ユーザ推定の精度が下がる  選択  ユーザ推定計算はHadoop  Webサイトへの提供はNoSQL 45 EMR DynamoDB Kinesis Streams Cloud PubSub  ユーザの滞在中にアクションする場 合はマイクロバッチ
  47. 47. (C) Recruit Technologies Co.,Ltd. All rights reserved. 5. まとめ 46
  48. 48. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentまとめ 1. データベースの分類  スケールアウト/スケールアップ  オペレーション用途/分析用途 →越えられない壁 2. データベースの紹介  RDB(DWH),Hadoop,NoSQLの代表プロダクトを説明  Google製の飛び抜けた二つのプロダクトを説明 3. その他のビッグデータキーワードの説明  Spark/マイクロバッチ/インメモリデータグリッド/Elastic/グラフDB 4. リクルートテクノロジーズにおける使い分け  3つの代表的なユースケースに対して、DBの選択を説明 47

×