データエンジニアリングの基礎 輪読会資料 第９章（第40回）分 20241021開催

本記事の位置付け

こちらの勉強会　「データエンジニアリングの基礎」を読もう_第9章　に参加し、発表するためにまとめたもの。当初は洋書を読む回でしたが、色々あって今は日本語版の紙の本を読んでいます。

• 今回の対象は以下,,,のはずだったのですが、時間がなくて機械学習の頭のところまでです。
  • 第9章　アナリティクス、機械学習、リバースETLへのデータの提供

第9章　アナリティクス、機械学習、リバースETLへのデータの提供

• こちらではデータエンジニアリングライフサイクルの最後のステージである、以下の図の「Serving」について記載する
  

• データを提供する先は以下の3つ

  • アナリティクスやBI：統計分析、レポート、ダッシュボードなど。
  • MLアプリケーション：高品質のデータが必要。
  • リバースETL：データソースへデータを送り返すこと

9.1 データ提供に関する一般的な考慮事項

• 信頼
• ユースケースとユーザ
• データプロダクト
• セルフサービス
• データ定義とロジック
• データメッシュ

9.1.1 信頼

評判を築くには20年かかるが、台無しにするには5分で済む。
（ウォーレン・バフェット）

• ユーザがデータを信頼していなければ、素晴らしいデータアーキテクチャーも、データ提供レイヤーも意味がない
• データエンジニアの仕事は、常に高品質で信頼できるデータを届けることにある
• この章ではデータに信頼を焼き込むという考え方を議論する
• 品質と信頼の為には、以下が必要
  • 利害関係者と共にデータを目視確認すること
  • データ検証の活用
    • データを分析して、財務情報、顧客とのやり取り、売上が正確に表されているかの確認
  • データ可観測性の活用
    • ライフサイクル全体を通してデータとデータプロセスの継続的なビューを提供すること
  • SLAやSLOに対する信頼を構築すること
    • データ契約、の形をとることもある
      • （第5章 ソースシステムにおけるデータ生成　参照）
    • SLA（Service Level Agreement）
      • データプロダクトに何が期待できるかをユーザに伝えるもので、データエンジニアと利害関係者との間の契約（合意・Agreement）
        • 例：データは確実に利用可能で、高品質である。
    • SLO（Service Level Objectives）
      • 合意した内容に対する性能を測定する方法（というか目標値か）
        • 例：データパイプラインの稼働率は99%で、データの95%に欠陥がないこと
  • 期待値を明確にし、合意したSLA/SLOの範囲内で稼働していることを確認しよう
  • 合意するだけでは十分ではなく、優れたSLAの特徴は継続的なコミュニケーション
    • 是正と改善のプロセスはどうなっているか？
      -信頼が全てだが、構築には長い時間がかかるし、失うのは一瞬だ。

9.1.2 ユースケースはなにか？ユーザーは誰か？

• データ活用で大事なことは、「誰が、何のために」それをするのか、ということをかんがえること。
  • 誰が：ユーザは誰なのか？
  • 何のために：ユースケースは何か？
• データは、どのようなアクションの引き金になるのか？誰がそれをやるのか？
• ROIの高いユースケースを優先しよう。
• エンジニアは手段にこだわりがちで、目的を見失いがちだ。
• 目的から入るべきで、ユースケースとユーザから始めよう。
  • データを使うのは誰か
  • データはどう使われるのか
  • 利害関係者の期待はなにか
  • 利害関係者とどのように協力すれば、データの利用のされ方がわかるのか

9.1.3 データプロダクト

データプロダクトの良い定義とは、データの利用によって最終目標の達成を促すプロダクト
（D.J.Patil）

• データプロダクトの作成は、プロダクトとビジネスが入り混じったフルコンタクトスポーツ
• 主要な利害関係者を巻き込むことが大事
• データエンジニアは、
  • エンドユーザからすこし離れたところにいるが
  • エンドユーザを理解しようとすることが大事だ
• データプロダクトを作るときには、ユーザがそのプロダクトを採用する動機を知らなければならない
• 良いデータプロダクトには正のフィードバックループが起きる
  1. データプロダクトの利用が増える
  2. より使えるデータが生まれる
  3. より良いデータプロダクトに改善される
  4. 1.に戻る
• データプロダクトを作る際には以下に注意
  • 利用者が達成したいことはなにか？
  • 内部ユーザと外部ユーザのどちらに役立つか？
    • 提供方法が異なる
  • データプロダクトの成果とROIはなにか？
• 望まれていないデータプロダクトは信頼を喪失し、台無しにする
• 利用状況に注意を払い、改善を継続しなければならない

9.1.4 セルフサービスにするべきか？

• ユーザはどのようにデータプロダクトを手に入れられるのか？
  • セルフサービスでデータを手に入れられるということは、まだ憧れの状態にとどまっている
  • 自分でBIやMLを触れるようになれば最高である
• データのセルフサービス化は失敗することが多い
  • 素晴らしい意図をもって開始されて、そのほとんどがうまくいかなくなる
  • その結果、アナリストやデータサイエンティストは、ビジネスユーザから、アドホックなレポートの提供やダッシュボードの管理という重労働を押し付けられる
    • 子どもが「犬を飼いたい！自分で世話するから！」といって犬を飼い始めたけど結局すぐ飽きて親が犬の世話をしなくちゃいけなくなる、みたいなものか
• なぜうまくいかないのか？
  • ユーザを理解して適切なツールを提供しないとうまくいかなさそう
    • ビジネス状況を理解したい経営幹部には、
      • 実用的なメトリクスが組み込まれたダッシュボードで十分
      • セルフサービスのツールは不要
      • 詳細に知りたければアナリストにやらせるだけ
    • アナリストであるユーザーには、
      • SQL等のより強力なツールを既に使っているはずなので、
      • BIは意味がない
    • データサイエンスも同じような状況
    • 上記の例ではセルフサービスのデータプロダクトは不適切
• セルフサービスのデータプロジェクト（！？）には適切なユーザーが必要
  • 彼らがやりたい仕事は何なのか？特定しよう
  • アナリストにやらせるのに比べて自分でできることのメリットは何なのか
    • 理想的なユーザー
      • データの知識のある経営幹部
      • データスキルを習得する意思のあるビジネスリーダー
• 誰にどのようにデータを提供するのかを考えよう
  • 時間的制約はどうなっているのか
  • より多くを欲したり、セルフサービスから逸脱する範囲の変更の要求が来ればどうなるか
    • データが増えれば質問も増える
    • 質問がふえれば更に必要なデータも増える
    • セルフサービスユーザのニーズは高まってくる
  • 誤解や混乱を招くことなく利用者が価値や洞察を見つけられるように以下のバランスが必要。
  • 柔軟性
  • ガードレール（制約）

9.1.5 データ定義とロジック

• データの有用性は以下に由来する
  • 信頼性
  • 正確性
    • ソースからイベント値が忠実に再現されている
    • 適切なデータ定義
      • 組織全体で理解されるデータの意味
      • 顧客、という言葉は部署によってそれぞれ厳密な意味を持つ
      • 定義が異なる場合は、文書化して管理しなければならない
        • この点については、私が以前書いたブログでも言及しています。
          • 正しい言葉のモノサシ、使っていますか？
    • データロジック
      • データからメトリクスを導き出す為の公式
        • メトリクス：様々な活動を定量化し、その定量化したデータを管理に使えるように加工した指標
      • データ定義と統計計算の詳細をコード化する必要がある
  • データの定義やロジックが組織内知識として組織内に流布することは多く、データ駆動ではなく逸話に従って行動するようになる
  • そうならないようにデータロジックと定義をデータカタログで宣言しておくことが大事
• データ定義が提供される方法は複数ある
  • 暗黙的に提供されることが多い
  • ユーザがSQLを記載する際も、暗黙の了解を前提としていることが多い
  • エンドユーザに対して、明示的にデータ定義とロジックを提供する必要がある

9.1.6 データメッシュ

• 今後増えていくデータ提供方法
• 個々のシステムが個別にデータを提供するのではない
• 各チームはデータを提供するし、消費もする
• セルフサービスで消費する場合もある
• 得られたデータは、ドメインチームのソフトウェアに組み込まれることもある
• 詳細は第3章を参照のこと

9.2 アナリティクス

• データ提供ユースケースの第1弾は、アナリティクス
  • データの中から洞察やパターンを探索、発見、特定、可視化すること
  • 実際には統計的手法、BI、レポートなどを使う
• ユースケースの特定が大事
  • 過去の傾向をみたいのか（ビジネス・アナリティクス）
  • 異常を早期に発見したいのか（オペレーショナルアナリティクス）
  • モバイルでリアルタイムのダッシュボードを見たいのか（組み込みアナリティクス）

9.2.1 ビジネスアナリティクス

• 実行可能な戦略的な意思決定の為に、過去と現在のデータを使用する
  • 長期的な傾向が考慮される
  • 以下が必要
    • ドメイン知識
    • 人間の判断力
    • 統計分析
    • 傾向分析
  • 科学であると同時に技芸である
• 以下に分類される
  • ダッシュボード
    • 主要なメトリクスに対して組織の性能を示すもの
    • 車のダッシュボードが状態を一瞥できるのと同じ
    • ユーザ別には、
      • 経営幹部：包括的なダッシュボード
      • その部下：特定のKPIのダッシュボード
      • アナリスト：ダッシュボードの作成と保守
    • 色々ツールがある。
  • レポート
    • アナリストが作成するように言われるもの
    • データを使って洞察と行動をうながすことが目的
    • 例：ランニングパンツの返品理由
      • 返品率が高い用品の原因を探り、記事が粗悪品であるとわかる
  • アドホックな分析
    • 上記の例で、「他にもないのか」のように都度の調査を依頼される場合
    • レポート、ダッシュボードにまとめられる。
      • エクセル、Python、Rのnotebook、SQL等もつかわれる。
  • 筆者が以前主催したハンズオンで使っていた例も似たような返品理由を探る事例を使っていました。(以下当時の資料より抜粋)
    
• 優れたアナリストは、
  • ビジネスと関わり、データに潜り込んで質問に答え、隠れた傾向や直感に反する傾向を明らかにする
  • データエンジニアと連携し、データ品質や信頼性についてフィードバックする
• データエンジニアはこれにこたえなければならない
• ランニングパンツの例
  • サプライチェーンの情報が入手可能になった場合
    • 返品されたパンツのシリアル番号と生地のサプライヤーを紐づける
    • 不具合の原因が特定のサプライヤーであることがわかる
    • このサプライヤーへの発注をやめる
• データ頻度
  • バッチで提供されることが多い
  • 下流のデータの頻度は上流の頻度に制約される

9.2.2 オペレーショナルアナリティクス

• ビジネス・アナリティクスは、実行可能な知見をえる為
• オペレーショナルアナリティクスは、即座に実行する為
  • リアルタイムのアプリケーション監視等
    • 1秒あたりのリクエスト数
    • データベースのI/O
  • 特定の条件になったらスケーリングイベントをキック
  • サーバが過負荷になったら容量増加
  • しきい値を超えたらメールで連絡

ビジネス・アナリティクスとオペレーショナルアナリティクスの境界線は曖昧になりつつある。
オンライン小売なら、オペレーショナルアナリティクスの結果はビジネスに直結する
ストリーミングデータをどうしたいのか？それを問うべきだ。
長期的にはストリーミングはバッチに取って代わるはず。
今後はストリーミングファーストになるだろう。

• 私も最近ストリーミングデータ処理の製品を扱い始めたので、このあたりの趨勢は今後も見ていきたいところです。

図9-2：Google Compute Engineから得たメトリクスのダッシュボード

似たようなものとして、私が最近使い始めたツールのオペレーショナルダッシュボード（画面の下半分から）

• ランニングパンツの例で、オペレーショナルアナリティクス
  • データエンジニア
    • 工場にリアルタイムアナリティクス導入
      • ストリーミングデータを出せる機械は有る
      • 監視カメラは有る
    • 現状
      • 技術者がリアルタイムで映像を見て不良品監視
      • 欠陥率が高くなるとアラートが上がる
    • 提案
      • クラウド上の機械学習済みのビジョンツール
        • リアルタイムで欠陥を特定
        • 不良品データは特定の製品のシリアル番号に紐づけられストリーム配送
        • リアルタイム分析プロセスが、不良品とストリーミングイベントを紐づけられる（？？？）
    • その後
      • 工場現場のアナリスト
        • 生地の在庫の品質が箱ごとに異なる事がわかる
        • 不良品率の高い箱はサプライヤに返送
      • サプライヤ
        • 同じようなリアルタイム分析システムを採用
      • データアナリスト
        • サプライヤと協力して品質を改善

9.2.3 組み込みアナリティクス

• 社外向けアプリケーションにダッシュボードが組み込まれていることが多くなった。
  • これを組み込みアナリティクスという
    • スマートサーモスタット等
    • Twitterのアナリティクスとかもですね。
  • ユーザはこれらを使ってリアルタイムで意思決定が可能になる
  • データエンジニアは
    • アプリレイヤ：知る必要はない
    • データのレイテンシ：理解しておく必要がある
    • アナリティクスの速度：理解しておく必要がある
  • 社外アプリのユーザは速さに厳しく、低レイテンシを求める
    • 必要なのは
      • 高いクエリ性能
      • 高い並行性
    • テクノロジ企業はそれに対応するテクノロジーを開発した
      • Cloud Data Warehouseとかのことだろうが、明記はされていない
    • スタートアップは当初はRDBだけで済むだろうが、処理がスケールするとそういうBigQueryみたいなものを使っていく必要になる

9.3 機械学習

• MLエンジニアリングはデータエンジニアリングとパラレルワールド
• ML、データサイエンス、データエンジニアリング、MLエンジニアリングの境界は曖昧になってきている
• 組織によっても異なる
• ランニングパンツの品質管理の事例
  • データサイエンティスト
    • 生地の品質が、原料の様々なパラメータに影響を受けることを発見
    • 織機のパラメータを最適化する基本モデルを開発
  • MLエンジニア
    • モデル学習を自動化
    • 入力パラメータに基づいて織機を自動的に調整するプロセスを設定
  • データエンジニア
    • MLエンジニアと協力して特徴量抽出パイプラインを設計
    • パイプラインを実装して保守する

9.4 データエンジニアがMLについて知っておくべきこと

• データエンジニアはMLを深く理解する必要はないが、知っておくべき概要や分野はある
  • 教師なし学習、教師有り学習
  • クラス分類と回帰の違い
  • などなど多数

以下、間に合わず、後半は、こちらをご参照ください！
- https://qiita.com/IQ_Bocchi/items/7e77578be9aa884f5b78