Google Cloud Data Platform Day
2019/9/5
既存のDWHやビッグデータの分析活用の今後の方向性、具体的には
- 増え続けるデータ量への対応
- リアルタイム性を追求しビジネス上の即時的な判断にどう活かせるか
- AI・機械学習をどう取り入れるか
といった点を具体的な事例も交えながらのセミナー内容であった。
今後さらに爆発的に増えていくデータに対して、必要なデータをどう抽出し、分析し、活用していくか、といった面では、目的を明確にし、キッチリと手法を定めて技術を利用していかないと全く追いつかなくなると感じた。
その中で、大規模なデータを効率的に、的確に処理するという部分では、もはや人間が処理するという範囲ではなくなってきており、AI,機械学習の分野への取り組みの必要性が急速に高まっているように思う。
初めに
- Google Cloud の注力エリア(6 workload)
- VM Migration
- SAP on GCP
- Hybrid Platform Modernization
- Data warehouse incl. AI ←今日はここ
- markenting Analytics
- Work Transformation with G Suite
データウェアハウスをモダナイズするGoogle Cloudのソリューション
Speaker : 寳野 雄太氏（Google Cloud 技術リード）
-
DWH
-
情報を集めて、格納して、分析する：目的は変わらない
-
ただし情報の種類、ボリュームなどが格段に増えている
-
DWH ＋ 大容量データ処理（Hadoop,Spark）
＋
-
ストリーミング（Kafka,etc）←リアルタイム分析・把握のニーズへの対応
-
-
新しいデータウェアハウス
- Google BigQuery
- エクサバイト規模のストレージとペタバイト規模のSQLクエリ
- セキュア、耐久性、メンテナンスフリー
- 他製品とのUniqueな特徴
- フルマネージド、サーバレス
- ストリーミングデータのリアルタイム分析
- MLとGIS（位置情報）をビルトイン
- ハイスピードでインメモリのBIエンジン
- ビジネス目線での利点
- 人的資源の活用
- インフラ設計、運用不要で分析に集中
- 高速なクエリで分析を繰り返し、より高い生産性
- 財務的資源の節約
-
低コストで使った分だけ支払い
or
-
定額プランで立てやすい予算計画 低TCO
-
- 情報資源の有効活用
- 社内データ流通を促進
- 全員が同じ最新のデータに基づいて意思決定可能に
- 人的資源の活用
- ESGの調査によると
- オンプレミスより52%低いTCO
- レガシーなDWHをパブリッククラウドに乗せた場合よりも41%低いTCO
- 価格体系
- クエリ計算能力の課金：オンデマンドもしくは定額レート
- ストレージの料金
- 長期保存ストレージの料金：90日以上保存したデータは割引
- BigQueryの内部構造
- 250ペタバイト／クラスタ分割なしでOK（通常のDWHだとクラスタ分割やストレージ拡張などの手間が必要）
- もともと分散型のストレージに格納：クラスタ分割不要で一つの仮想ストレージで実行可能
- コンピュートとストレージが分離されている
- 新機能：パーティションとクラスタリング
- ペタバイト級のクエリも数秒で完了まで性能向上
- 250ペタバイト／クラスタ分割なしでOK（通常のDWHだとクラスタ分割やストレージ拡張などの手間が必要）
- サーバレスデータ分析：様々な手間がすべて自動のため、分析と考察にほぼすべての時間を割ける
- BiqQueryの可用性
- ストレージ：フルマネージド
- それぞれのテーブルはゾーンをまたいで複製される
- 自動で圧縮、暗号化される
- バックアップも自動実行される
- コンピュート：サーバレス
- クエリ実行時のみコンピュート（コンテナ）が大量に起動される：ゾーンもまたいでコンピュート起動
- 一部のゾーンやワーカー障害も透過的に割り当て変更するだけ＝高可用性
- ワーカーはお客様に透過的にアップデートされる＝メンテナンス、パージョンアップのダウンタイムなし
- ユーザ側のクラスタ管理は一切不要
- ストレージ：フルマネージド
- オープン
- データレイクストレージ
- データレイクをデータウェアハウスに開放
- DWHがデータレイクを第2のストレージとして利用するとしたら？
- ＝フェデレーション（BigQuery外部データソース）
- 他のストレージ上のデータを直接クエリー可能
- Cloud Storage
- Cloud Bigtable
- Cloud SQL
- Google Drive
- Hadoop/Sparkジョブのリフトアンドシフトもサポート
- Cloud Dataprocで利用しているCloud Bigtableを直接利用も可能
- 他のストレージ上のデータを直接クエリー可能
- データレイクストレージ
- リアルタイム
- ストリーミングインサート
- テーブル当たり50GB/sec
- Cloud Dataflowとの連携
- ストリーミングインサート
- セキュリティと信頼
- 東西２フルリージョン
- Interconnectによる専用線サポート
- IP制限その他各種データ持ち出し防止（VPC Service Control）
- PCI-DSS、ISO27001
- デフォルト暗号化、暗号化関数、CMEK
- データ共有
- クエリ→レポート作成→結果をスプレッドシートで共有→Looker等その他ツール
- Connected Sheets(Analyze)
- スプレッドシートのピボットテーブルがBigQueryで演算
- BigQuery MLを使用してAIの基盤を構築
- Tensorflowモデルのインポートし、BigQueryで予測、など可能
- AutoML Tables
- 裏側でDeepLearningモデルを選択し、自動的に見せ方を変えられる
- Google BigQuery
BigQueryを活用したアサヒビールの小売り向けデータ分析プラットフォーム
Speaker : 清水 博 氏（アサヒプロマネジメント株式会社 IT Strategy & BPM Department BPR Section マネージャー）
- グループ内の急速なグローバル化
- 28000人中15000人以上（半分以上）が日本国籍外の社員
- 今までの国内のITのやり方では通用しない
- 28000人中15000人以上（半分以上）が日本国籍外の社員
- ビジネス側の想い
- 市場の変化、ニーズのサイクルの短期化と多様化
- 期待を超える価値のために
- 市場ニーズよりも早く答えにたどり着く、データドリブンであり続ける
- 社内で検討しても市場のニーズには追い付かない
- スピードとバリエーションを兼ね備えた提案に、様々なデータを活用して、小売り向けに最適な棚割りを提案したい
- 小売り向けの提案とは？
- アサヒビール本部の営業から、チェーン本部（＝小売り）への販促提案→商談内容の決定
- 販促提案の際に分析したデータを活用
- アサヒビール本部の営業から、チェーン本部（＝小売り）への販促提案→商談内容の決定
- 小売り向けの提案とは？
- Project カテゴリーマネージメントシステム刷新
- 2016年後半より、新カテゴリーマネージメントシステムの構想（やりたいことの明確化）スタート
- 2018年から新カテマネ構築スタート
- 2018年後半に1stリリース、BigQuery利用開始
- SaaSとPaaSのみで構築、インフラ運用がほぼゼロ
- アサヒビールのシステムの9割はまだデータセンター（オンプレ）で稼働
- 大きなバッチ処理をすべてBigQueryにお任せ
- 小売り向けの提案に際し、理由、根拠、価格等をすべて明確にする必要がある＝データを利用したバッチ処理
- すべての処理をマイクロサービス化（GKE利用）：追加改修に柔軟に対応可能
- 今年利用したシステムが来年そのまま使えるか？が予測不能な中でマイクロサービス化は必須と判断
- Cloud Composer（クラウド上のジョブ管理）利用
- インターフェース側、UI用データはAzureの利用が多い：BigQueryでバッチ処理したデータをAzureのSQLDatabaseに転送
- なぜBigQueryなのか
- 優位点
- マシンスペックを決めたりする手間がない
- 需要に応じた性能の拡張も考えなくてよい
- チューニングいらずで処理が驚異的に速い
- 週1のバッチ処理以外は課金ゼロ、使いたいときに使う
- 考慮点
- 粒度が細かい処理はあまり向いていない
- Except All処理
- 異なるロケーションのデータセットやGCSとのやりとり
- クエリ結果をローカル環境にダウンロードする際の上限サイズの引き上げ
- 期待すること
- 大量データに関するWindow関数のMemory不足
- Connected Sheetsの正式リリース
- BI Engine対応範囲の拡充
- 優位点
- 今後の展望
- SQLDatabaseに入れずに、BigQuery内で最終的なテーブル形成し、UI側と接続、展開する
Bridge to the Cloud
Speaker : ダミアン コントレラ氏（Google Cloud データアナリティクススペシャリスト）
- はじめに
- データウェアハウスの欠点
- コスト
- データ増加、データ形式対応外
- リアルタイムの負担は受けられない、セルフサービス分析が難しい
- ベンダーロックイン
- スタースキーマとディメンション表とファクト表に合わせる
- 構造を合わせるのはすごい手間がかかる
- データレイク（Hadoop等）の欠点
- コスト
- クラスターのリソースのバランス
- バージョンアップ
- 複数のデータレイクが構築される
- パートナー、人材採用が困難
- Google Cloudの価値
- コストパフォーマンスがよい：使った分だけ、ライセンスも不要、アップグレードも不要
- 弾力性のある構造：ノード数の構成とか、データストアの容量構成、クラスタ構成等を考えなくていい
- セキュリティ
- サイロはない
- サーバレスでNo-Ops
- ANSI SQL-2011
- データウェアハウスの欠点
- 移行する前に何を考えるべきか
- 社内にスキルがない場合
- グーグルの支援
- パートナーとGoogleリソースが協力しあう
- BigQueryのスターターパック
- TCO & ROI
- アンケートに記入するだけで、現状の所有データ等から算出可能
- 総所有コストも計算
- クラウドで構築
- サイロ化になっているデータセット→データと関連データの発見→ PoC → 基盤を構築 → 周りのシステムと通信用のツールの構築 →ソースデータを移行 → 機械学習→誰でもMLを使えるように
- GCP DataProc:Hadoop
- フルマネージドHadoop/Spark
- カスタマイズ可能なエンジン
- 90秒以内で立ち上げ
- 社内にスキルがない場合
- BiqQueryへのデータ連携、移行
- GCPのサービス
- メッセージ：Pub/Sub
- ストレージ：Cloud Storage
- GCP：BQ Load
- GCP（Cloud Storage経由）もしくは直接、BigQueryにデータをロードできる機能
- GCP:DataFusion
- No-opsのデータパイプライン構築と管理のための統合サービス
- フルマネージド
- GCP:Dataflow
- バッチ＆ストリーミング
- コードで複雑な処理を書きたい
- サーバレスでフルマネージド型のデータ処理
- Python,Javaで書けるバッチとストリーミング
- GCP:Data Transfer Service
- 様々なソースから（AWS S3,Redshift）
- 数クリックで設定
- スケジューラ、通知設定も
- Partner:Informatica
- データをオンプレからクラウドへ
- ビジュアルでフロー構築
- GCPのサービス
- BIツール
- Googleスプレッドシート
- BigQueryのデータを直接
- SQLできなくてもデータにアクセス可能
- BIツール：データポータル
- GUIでダッシュボード作れる
- データソースがまとまってなくても様々なデータソースをJoinできる
- テンプレートの用意あり
- BIツール：Looker
- BigQueryと統合
- スケーラブル
- どこからでもアクセス可能
- 50以上の連携元サービス
- Googleスプレッドシート
ZOZOTOWNのDWHをRedShiftからBigQueryにお引越しした話とその後の話
Speaker : 塩崎 健弘 氏（株式会社 ZOZOテクノロジーズ マーケティングオートメーション テックリード）
- ZOZOテクノロジーズ
- 「RedShiftからBigQueryにお引越しした話」：ZOZOTOWN DWHでググるとデブサミ発表時の資料が見つかる
- 今日はそのおさらいとその後の話
- Redshift から BigQueryへ移行
-
Redshift時代のデータフロー
-
OnPreDB → 閉域網でS3（DataLake) → Amazon Data PipelineでS3からRedShiftのデータ転送、集計クエリ実行 → RedShift（DWH）
- 当時入れていたデータ
- ZOZOTOWNやWEARのマスターデータ
- ユーザ情報、商品情報、注文情報
- Google Analyticsから取得したアクセスログ
- メール、プッシュの配信ログ
- 総テーブル数＞１００
- 総データサイズ＞10TB
- BigQuery移行後はどちらも桁が1つ増えたけど、運用コストはほぼ変化なし（増えたのも気が付かなかった）
- たぶんRedShift時代は制限がかかるたびに退避したりしてたと予想
- 当時入れていたデータ
-
RedShit時代のつらみ
- 自分たちで管理する必要のあるものが多い
- ノード数
- Distribution Key
- Sort Key
- ストレージの空き容量
- インデクスタイプ
- これらをチューニングするノウハウが少なかった
- 各種の設定がコードベースで管理されていなかった
- ※Redshiftが悪かったのではなく、運用にあっていなかった
- 自分たちで管理する必要のあるものが多い
-
どう移行したのか
- S3のデータを日次でBigQueryに転送するETL
- ETL作成時のツール
- Embulk
- ETLツール
- データの入力、加工、出力部分はプラグインとして提供、自作プラグインはRuby,Javaで
- 設定ファイルはYAML
- Digdag
- ワークフローエンジン
- 大量のEmbulkジョブを置く率的に管理
- 設定ファイルはほぼYAMLで書かれている
- シンプルな記法（好みがわかれる）
- Embulk
-
BigQueryでの問題とその対処
- データ保存料金はね上がり
- 過去分のテーブルのスナップショットを長期間保存していた
- 古すぎるスナップショットを自動削除するバッチを作成
- テーブル作成時に自動削除の設定をするほうがスマート
- クエリ料金はね上がり
- 非常に縦長なログをスキャンしたら、数TBをスキャンしてしまった
- partitioned tableの採用で対応
- 本番に出すまで落ちることがどうかわからないクエリ
- CircleCIでdry runすることでマージする前に気付けるように
- データ保存料金はね上がり
-
BigQueryにデータを入れた「だけ」では何も価値を生み出さない
- AIなどの分野へのデータ活用
- ZOZO画像検索でのMLOps実践とGKEインフラアーキテクチャ
- 類似アイテム検索機能のリリース
- データパイプラインをさらに使いやすく
- 速い、安い、安定を目指してデータパイプラインのアーキテクチャ改善
- AIなどの分野へのデータ活用
-
- 移行後の継続的な改善
- パッチワーク化したシステムの統合
- 3つのワークフロー、4つのチームにまたがったデータ連携処理
- システムの継ぎ足しを重ねた結果のアーキテクチャ
- 基幹DBのテーブルをBigQueryに追加するまでの手続きがながい
- 障害時のリカバリー範囲がチームをまたがる
- ↓
- 2つのワークフロー、1つのチームになるまでシステム統合済み
- 既存のワークフローとば別のワークフローを作り、BigQueryで全件突合
- BigQueryの新しい機能を使いたい気持ちを抑えて、地道な改善を積み重ねた
- ETL → ELT
- ワークフロー統合の結果、いろんな個所にあった変換処理（ETLのT）が一か所に集まる
- いろんなツールが暗黙的にやっていた変換処理を再実装する必要がでた
- 特殊文字を削除
- タイムスタンプのミリ秒切り捨て
- データ転送基盤のGCP移行
- 昔からAWSにETL基盤がある AWS→GCPのデータ転送コストがもったいない
- Cloud Dataflowを使ったフルマネージドな構成
- ETL部分をフルマネージドに置き換えしたい
- オンプレ環境のDWHの移行
- Redshift導入前からのDWHがオンプレにある
- 移行したい
- パッチワーク化したシステムの統合
- 今なら使える、引っ越し当時に欲しかった便利機能
- BigQuery Data Transfer Service
- 様々なデータソースからBigQueryへのデータ転送を行ってくれる
- 転送速度がやたら早い（実測値で10Gbps）
- Google SheetsをExternal Tableに
- Google Sheetsに対してBigQueryにクエリ実行できる
- Scheduled Query
- 特定の日時にクエリを自動実行し、結果をテーブルに吐き出し
- 簡単な日次集計なら十分使える
- BigQuery Data Transfer Service