Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DWH御三家の各特徴と選び方〜SnowflakeとBigQueryとRedshiftと〜

06986333d704c400f7a2053994058e6e?s=47 tama-chang
December 02, 2020

 DWH御三家の各特徴と選び方〜SnowflakeとBigQueryとRedshiftと〜

06986333d704c400f7a2053994058e6e?s=128

tama-chang

December 02, 2020
Tweet

Transcript

  1. DWH御三家の各特徴と選び方
 〜SnowflakeとBigQueryとRedshiftと〜
 玉井 励
 クラスメソッド株式会社 データアナリティクス事業本部
 1

  2. 2 自己紹介 玉井 励(タマイ レイ) • クラスメソッド株式会社 ◦ Snowflakeの国内初ソリューションパート ナー

    • 自分の職種 ◦ BIツールの技術支援など ◦ BIとDWHは切っても切り離せない関係 • 奈良県出身、奈良県在住
  3. 3 今回お話すること(アジェンダ)

  4. 4 今回お話すること • DWHの簡単なおさらい(DWHとは?) • DWHの選び方における結論 • DWH御三家の特徴を簡単にご紹介 ◦ Snowflake

    ◦ Google BigQuery ◦ Amazon Redshift • DWH御三家の選び方
  5. 5 データウェアハウス(DWH)とは?

  6. 6 データウェアハウスとは 分析しやすいようにデータを蓄積するDB

  7. 7 DWHをもっと知りたい方は https://youtu.be/G7weKwUE6KY

  8. 8 DWHの選び方における結論

  9. 9 世の中そんなに甘くない 「これを選んでおけば間違いない」 というDWHはありません

  10. 10 結局はこれ 自分たちの(データ分析における)要件に 合ったDWHが一番良い

  11. 11 いちばんだいじなこと 自分たちが計画している データ分析の要件を徹底的に洗い出す

  12. 12 DWH御三家の紹介

  13. 13 Snowflake • Snowflake社が提供する サービス • フルマネージド • 従量課金 ◦

    メインは仮想ウェアハウス の稼働時間
  14. 14 Snowflakeのいいところ • 面倒な管理不要 ◦ コンピュート部分は管理可能 • 最先端の機能が多数存 在 ◦

    仮想ウェアハウス ◦ ステージ ◦ ゼロコピークローン ◦ タイムトラベル ◦ snowpipe ◦ 半構造化データの取り扱い ◦ データシェアリング
  15. 15 Snowflakeの注意点 • 主要なパブリッククラウド サービスと独立してしまう ◦ 料金支払等がバラける ◦ 各種連携は可能 •

    事前の見積は難しい
  16. 16 Google BigQuery • GCPサービスの1つ • フルマネージド • 従量課金 ◦

    メインは処理するデータ 量(スキャン量)
  17. 17 Google BigQueryのいいところ • 管理不要 • GCPやGoogleサービスと の連携 • SQLだけで機械学習

    (BQML)
  18. 18 Google BigQueryの注意点 • コストマネジメントに一定 のスキルが必要 ◦ パーティショニングなど • BQ独自のデータの扱い

    方がある ◦ STRUCT型、UNNEST • 事前の見積は難しい
  19. 19 Amazon Redshift • AWSのサービスの1つ • マネージドサービス • 従量課金 ◦

    起動している時間
  20. 20 Amazon Redshiftのいいところ • とっつきやすい ◦ 従来のDBと似た感覚で使 える ◦ オンプレDWHの知見を流

    用できる • 事前の見積がしやすい • AWSである ◦ 既存AWSサービスとの連 携
  21. 21 Amazon Redshiftの注意点 • それなりに管理は必要 ◦ スケーラビリティ ◦ WLM ◦

    VACUUM • それなりにチューニング は必要 ◦ 列圧縮タイプ ◦ 分散スタイル ◦ 各種キー
  22. 22 DWHの選び方

  23. 23 切り口は人それぞれ どういう観点で選ぶか

  24. 24 DWHを選ぶ観点の例 • パフォーマンス • セキュリティ • バックアップ(&リカバリー) • スケーラビリティ

    • エコシステム • コスト
  25. 25 DWHを選ぶ観点の例 • パフォーマンス • セキュリティ • バックアップ(&リカバリー) • スケーラビリティ

    • エコシステム • コスト
  26. 26 ぶっちゃけ パフォーマンスはどれも同じ (環境や状況による)

  27. 27 ベンチマーク記事は冷静に https://aws.amazon.com/jp/blogs/big-data/fact-or-fiction-google-big-query-outperforms-amazon-redshift-as-an-enterprise-data-warehouse/

  28. 28 DWHを選ぶ観点の例 • パフォーマンス • セキュリティ • バックアップ(&リカバリー) • スケーラビリティ

    • エコシステム • コスト
  29. 29 セキュリティもバックアップも どのDWHもしっかりしてる

  30. 30 サービスとしてのセキュリティ https://www.snowflake.com/%E8%A3%BD%E5%93%81/snowflake%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%81%A8% E3%83%88%E3%83%A9%E3%82%B9%E3%83%88%E3%82%BB%E3%83%B3%E3%82%BF%E3%83%BC/?lang=ja https://cloud.google.com/data-security-governance?hl=JA https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/iam-redshift-user-mgmt.html

  31. 31 機能としてのセキュリティ • アクセス制御 ◦ IP縛りとか • 認証 • 権限管理

    • 暗号化
  32. 32 バックアップについて • タイムトラベル • Fail-safe • 各種ステージへの UNLOAD •

    7日間の自動履歴保存 • Cloud Storageへのエク スポート • 自動スナップショット • 手動スナップショット • S3へのUNLOAD
  33. 33 DWHを選ぶ観点の例 • パフォーマンス • セキュリティ • バックアップ(&リカバリー) • スケーラビリティ

    • エコシステム • コスト
  34. 34 データが加速度的に増えていく時代 https://iotnews.jp/archives/150335

  35. 35 自分で管理 vs サービスにおまかせ https://fivetran.com/blog/warehouse-benchmark

  36. 36 BigQueryが楽そうだが…? • 仮想ウェアハウスのサイ ズ変更 • 自動 • インスタンスタイプの変 更

    • ノード数の変更 • Spectrum • RA3
  37. 37 DWHを選ぶ観点の例 • パフォーマンス • セキュリティ • バックアップ(&リカバリー) • スケーラビリティ

    • エコシステム • コスト
  38. 38 基盤を1つのエコシステムで統一するメリット

  39. 39 DWHを選ぶ観点の例 • パフォーマンス • セキュリティ • バックアップ(&リカバリー) • スケーラビリティ

    • エコシステム • コスト
  40. 40 まずはSnowflakeとBigQueryの2つで考えてみる • 仮想ウェアハウスが起動し ていた時間(秒単位) • クエリで処理するデータの 量(スキャン量)

  41. 41 Snowflakeのコストマネジメント • 仮想ウェアハウスの扱い がコストの鍵を握る • ワークロード別に用意し て調整 ◦ サイズ

    ◦ 稼働時間 ◦ クラスタ数 ◦ オートサスペンド(&レ ジューム) • いつでも変更可
  42. 42 BigQueryのコストマネジメント • スキャンデータ量 ◦ LIMIT句は無意味 • 無駄なスキャンを避けるテクニックが必要 ◦ テーブル分割(パーティショニング)

    ◦ 無駄なクエリは実行しない(中身を見るだけ等) ◦ 必要なカラムのみ対象にする ◦ 実行前にクエリの見積をする(見積ツールあり) ◦ 処理可能サイズに制限をかける
  43. 43 考え方の例 • 仮想ウェアハウスが起動し ていた時間(秒単位) • 大量のデータを定期的に 処理し続ける要件がある 場合はSnowflakeの方が よい?

    • クエリで処理するデータの 量(スキャン量) • 特定のタイミングだけ重い 処理が行われる(アイドル 状態も多い)要件がある場 合はBigQueryの方がよ い?
  44. 44 Redshiftという選択肢 • 立ち上がっている時間=コ スト ◦ クエリの処理量や処理時 間を気にしなくて良い ◦ 見積がしやすい

    ◦ リザーブドインスタンス
  45. 45 まとめ

  46. 46 まとめ • DWHとは、データ分析に特化したDB • 一番いいDWH = 自分の要件に合ったDWH • 実際に使ってみるのが一番の近道(トライアル、無料枠)

  47. 47