見出し画像

2020-07-15 Data Engineering Study #1 #DataEngineeringStudy

2020/07/15 に開催された Data Engineering Study #1 「DWH・BIツールのこれまでとこれから」 のイベントレポートです。

●イベント概要
本イベントは、Infra Study Meetup を運営する Forkwell と、分析基盤向けデータ統合SaaS「trocco」の開発・運営を行う primeNumber による共催イベントです。データ分析に精通した講師をお招きし、データ分析基盤の「これまで」と「これから」を学ぶことを趣旨として開催いたします。

プログラム第1回「モダンなDWH/BIツールの選び方と、実際の運用事例」
分析基盤において、必須の構成要素であるDWHとBIツール(可視化・ダッシュボードツール)。昨今では多くのツールが存在し、これから分析基盤を作る方にとっては最も悩ましい選択を強いられるでしょう。
このセッションでは水先案内人にゆずたそ氏をお招きし、データ分析基盤の全体像を説明して頂いた上で、DWH/BIツールの位置づけを確認します。
その後、実際にDWH・BIツールを最大限活用されている2社に、選定の理由・運用してみてのリアルな声を発表いただきます。


■Data Platform Guide - 事業を成長させるデータ基盤を作るには

ゆずたそさん

スクリーンショット 2020-07-15 19.40.00

・今日の発表内容
  SoftwareDesign 2020年7月号に準拠

●データ基盤人材は年々増えている
・ニーズが増えている
・実際にこういう事やっているよという人も増えてきた
・注目度の上がっている分野

●最初の落とし穴
・どうやって基盤を作ればよいかわからない
・つくったのに全然使われない

●苦い思い出
・いろいろ考えて最強のダッシュボードを作った
  1週間で全然見られなくなった
・最初に描いた基盤は使われない

●本日のゴール
・使われるデータ基盤の勘所を学ぶ

●Why
・データ基盤をなんのために作るのか
  顧客のため
  現場のため
  経営のため
・現場→経営→顧客に価値を提供していく
・事例:営業活動の指標を変えたらどうなるかの分析
  契約をとったらインセンティブ
  → 契約後に3ヶ月後に解約されなかったら
・営業、解約のデータをBigQueryに統合
  DataPortalで分析
・データ活用をドライブする基盤
  複数データソース、複数ユースケースを繋ぐ
  1:1なら直接参照で済む
  複数だと基盤が必要
・データはどんどん複雑になっていく
  部署ごとに売上がずれる
    消費税、解約、返金
  チームで数値が変わってくると
  横断での意思決定は難しい

●What:手軽にデータを参照できるツール
  とりあえずデータを集めましたではNG
  ModelとViewを分ける
  適切なViewは部署や役割によって異なる
・データを統合するというのと合わせて
  どうしたら使いやすいかを考える
・その人にとって何がベストか
  試さないとわからない
  現場と向き合うのが重要

●What:安全にデータを受け渡せるシステム
・データの階層を分ける
  データレイク
    加工せずに1つのシステムに集約したもの
    加工方法を間違ったときに
    加工前のデータが残ってないと直せない
  データウェアハウス
    複数データを統合・蓄積して、分析向けに整理したもの
  データマート
    特定の利用者向けに分離したもの
・開発プロセスは挟み撃ち
  処理の流れと違ってくる
  事業やシステムの全データをコピーする
  ダッシュボードやレポートと対になる
  どうまとめるかが決まる
・BigQueryの命名規則で管理
  enokilog__datalake__mysql.users

●What:安心してデータを扱えるプロセス
・部署や用途ごとに暗黙的に期待されている品質を洗い出す
  毎朝見るのであれば、朝までにレポートを出力しておく必要がある
  明確に話されないけれど存在する期待
・インシデント対応の仕組み化
  優先順位
    深夜休日でも対応
    案件を止めて対応
    案件と調整
  対応手順
    再実行
    代替データ案内
    関係者にレポート
・オペレーションを型化する
  不安感が減る
  利用者からすると安心感がある
・品質を計測する
  結果をモニタリングして改善、悪化を止める
・定期的に見直す
  定期のミーティングに改善を含めてしまう

●How:データの取得元となる対象
・webサービスの場合
  ユーザー
  画面
    アクセス解析ツール
  サーバーサイドアプリ
    アプリケーションログ
    データストア
    webサーバログ
・注意:元データの品質に注意しよう
  元のデータがないと分析では利用できない
・注意:元データの仕様を管理しよう
  DBのテーブルやカラムに一言コメントがあるだけでも分析は楽になる
・注意:手入力のデータにも目を向けよう
  手入力するデータにも向き合う必要がある

●How:データを集約するテクノロジー
・技術要素
  ETL、DWH、ワークフローエンジン、BIツール
・BIツール
  データの分析や可視化
  選定の観点
    予算がある / 無料 / 使い慣れたツール
    構築の有無
・DWH
  大量データの保存や集計
  選定の観点
    処理規模
    クラウド / オンプレ
    サポート有無
・ETL
  データの抽出・変換・格納
  選定の観点
    定期バッチ / ストリーミング
    クラウド / オンプレ
    コード / 画面
・ワークフローエンジン
  処理の流れを管理
  選定の観点
    コード / GUI / その他
    どれも癖があるので手に馴染むものを

●事例
・スタートアップ、大手、メガベンチャーの事例を書いてます
・時間がないので興味がある人はスライド読んでください

●おわりに
・利用者に寄り添って最適なテクノロジーを活用していく
・この領域は総合格闘技
  エンジニアリングの面白さや難しさが詰まってます

●QA
・BigQueryのview運用とBIツールへの知見の蓄積で
 2重管理になってしまうのはどうすれば?
  2つのフェーズに分ける
    アナリストがBIツール上で試行錯誤
    ロジックをデータウェアハウス側に取り込む
  スピードと品質のバランスが取れる

・ゼロからDWHやBIを作り始める上で
 まず何から始めればよいでしょうか?
  目的の整理
  データを入れたあと、結局これをどうする?になりがち
  上司などと目的を整理すると
  使われるもの価値があるものがつくれる


■スポンサーセッション primeNumber


■ZOZOTOWNの事業を支えるBigQueryの話

塩崎 健弘さん

スクリーンショット 2020-07-15 20.20.57

●ZOZO
・ZOZOTOWN
・WEAR
・MS マルチサイズ
  身長と体重を入力すると
  理想のサイズが見つかる
・ZOZOMAT
  スマホで足の3Dサイズを計測
  ピッタリのサイズを

●データ基盤
・構成
  基幹の複数SQLServer
  → 中間DB SQLServer
  → BigQuery
  → PowerBI, Lookerなど
・基幹の複数DB → 中間DB
  ETL: bcp
    SQL Serverのバルクコピーツール
  ワークフローエンジン: Digdag
    TreasureDataのOSS
  インフラ: オンプレ
・中間DB → BigQuery
  ETL: Embulk
  ワークフローエンジン: Digdag
  インフラ: AWS
    移行前がRedshiftだったので
・BI
  PowerBI
  Looker
    ガバナンスで利用
・AIもやってます
  検索結果のパーソナライズ
    おすすめ順の並べ替え
  類似アイテム検索
    Cloud Composer + GKE

●Amazon Redshift から Google BigQuery に移行
・日次レポート、月次レポートなら使えていた
・ZOZO研究所発足
  Try&Errorのサイクルが早い
・BigQueryなら
  インデックスを事前にはらなくても力技で回せる

●オンプレDWH vs クラウドDWH
・Redshiftの前から使っていた
  メルマガなどに利用
・クラウドだと圧倒的に運用が楽
・一回買うと冗長構成などでコストは掛かる

●BIツールの使い分け
・Power BI
  オフィシャルなBI
・Looker
  データガバナンス
・Redash
  SQLを書けるエンジニアチーム
  グラフ化したいがBIチームに依頼すると長いのでつなぎ
・Google Sheets
  根強い人気

●Looker導入
・SQLでデータ集計処理を記述していたことの問題点
  WHERE句のみを切り出して再利用できない
  カラムの扱いが違う
  など
・LookML
  WHERE句のコピペ防止
  ○○_idに名前をつける
  Gitでバージョン管理
・ETLバッチとLooker連携
  ETLの完了をPubSubにpublish
・tech blogに書いてます

●懺悔
・Redshift時代
  S3→Redshiftは知っている
  中間DBの存在は知っている
  基幹DBは秘境
・取りやすかったS3からデータを取得していた
  無加工だと思ったら、一部加工されていた
・ゆずたそさんのブログそのまま書いてあった

●ここが辛いよBigQuery
・コスト
  噂を聞きつけた人が触り始めて
  気軽な SELECT * で数千円が溶けた
  検知して、違反者講習へ
・セキュリティ
  IAMで設定できる最小粒度はデータセット
  権限境界とGCPのプロジェクトを合わせておくと幸せ
・コスト予測
  Flat-rate pricing
  でコンピューティングコストが固定になる

●リアルタイム系データ基盤紹介(構築中)
・更新タイムスタンプで差分反映
  更新ルールが統一されていなくて諦めた
・Change Trackingで変更があった主キーをpubsubへ
  HAにしたので、pubsubには必ず2つ入る
・Dataflowで重複排除
  行の値からハッシュ計算
・差分データをBigQueryにStreaming Insert
  Dynamic Destination
・読み出し口
  差分情報だけのPubSub Subscription
  BigQuery

●QA
・今注目しているサービスや技術は?
  AutoML、BQ omni

・データエンジニアリング自体に避けている時間の割合は?
  他のシステムも見ている
    マーケティング系とデータ分析は相性が良いので一緒に
    避けている時間は半分もない
  チーム 4人
    半分はデータではないもの
    リアルタイム系データ基盤に一人がフルコミット

・BIツールはどう使い分けるべき?
  データ基盤としてはたくさんのBIにつながるものに
  アドホックとダッシュボードは自然と別れていく印象


■スポンサーセッション Forkwell


■freeeのデータ基盤におけるDWH/BIの運用事例紹介

中山 裕介さん

スクリーンショット 2020-07-15 21.02.55

●freee
・スモールビジネスを世界の主役に
・昨年末に上場
・7つのメインプロダクト
  はじめる
    開業フリー、会社設立フリー
  運営する
    フリーカード、会計フリー
  育てる
    マイナンバー管理フリー、人事労務フリー
  納税する
    申告フリー

●データ基盤紹介
・特徴
  様々なユーザー
    データサイエンティスト、MLエンジニア
    PM、サポートなど
    KPIの分析などにも利用
  多様なデータソース
    プロダクトのデータ以外にも必要に応じて
    他社のクラウドサービスを利用することにも積極的
  セキュリティ大事
    センシティブなデータが多い
    セキュリティレベルに応じて、マスキングやカラムを落としている
・現状のデータ基盤の全容
  データソース
    RDS/Aurora, S3
    外部SaaS
  データ抽出・加工・取り込み
    S3: Data Lake
    EC2, Lambda, ECS, Batch, Glue
    Digdag
  DWH
    Athena
    Redshift
  BI
    redash

●運用事例紹介
・内製のBIツールを開発していたが
  処理が終わらないのでredashを採用
・Redshiftの運用
  データ
    カラム落とし
      文字列データは取り込まない
      ホワイトリスト形式で絞り込み
      問い合わせで個人情報を入れてしまうこともある
    マスキング
  クラスター3台を使い分け
    primary
      毎朝snapshot作成
    replica-1
    replica-2
      redash用
  良いところ
    ノード単位の起動時間課金
    ちょっと集計クエリを回す分には良い
    S3との相性が良い
  苦労しているところ
    キャパシティプランニング
      気づいたらディスクフル
    テーブルのチューニングが必要
      DISTSTYLE / DISTKEY / SORTKEYなどの指定
      再分散が起こるとクエリが重い
・Redashの運用
  データソースは都度追加
    サクッと出せるので便利
  EC2にDockerで稼働
  Mackerelで監視
  全社員に開放
    エンジニアから企画までSQLをゴリゴリ書いている
    使う人が気を使ってくれて爆弾クエリはない
  良いところ
    インスタンス費用だけ
      有償版で500名だといくら掛かるか
    定期的にKPI集計用クエリを回す分には十分
    Spreadsheetへの集計結果も連携可能
  苦労しているところ
    SQL書く前提のツール
      普及に限界
      営業の人
    スケジュール実行のクエリが同時多発で実行されQueueがつまる

●こういう方におすすめ
・Redshift
  予算決定に確実な金額が必要
  全社的にAWSを使っている
・Redash
  無料で使ってみたい
  サクッと簡単な可視化
  SQLを書くことが苦でない
  metabaseも良いです

●今後
・Redshiftの新しいインスタンスタイプ
・データカタログ整備
・ETL周りの処理のリファクタ

●QA
・日々進歩している製品、サービスの情報キャッチアップの方法や
 選定眼の鍛え方は?
  twitterで一次情報を拾ってます
  選定時の事情や、組み合わせによる

・ダッシュボードをほか担当者に引き継ぐ際の注意点は?
  目的の共有と独自項目の説明
  Google Docにチョロっと書いたり
  redashだとクエリにコメント入れたり

・未経験者がデータエンジニアになるための過程と学習方法は?
  パスは2つ
    社内の異動
      データ基盤チームを立ち上げる
    未経験を採用している企業に応募
  学習方法
    キャッチアップ
    データ基盤を自分で作ってみる
・ゆずたそさん
  異動や転職はなるほど
  個人だと大量データを扱える環境が遠い


■感想

以前にDXの情報を整理したときに挙げた、DXプロジェクトの種類、データ活用のすべてで、データマネジメントとデータ基盤がベースになってくると考えています。

画像5

画像4

最前線を走っていただいている皆さんのおかげで、データ基盤がどうあるべきか、どう成長させるべきかの型が見えてきたのを感じました!

どうつくるかの部分もこれから、利用者を顧客と捉えて、顧客向けのシステム開発と同様に型が出来上がってくるのだろうな、と楽しみです。

登壇者の皆さん、運営の皆さん、ありがとうございました!



この記事が参加している募集

いつも応援していただいている皆さん支えられています。