第1回『データエンジニアリングの基礎』読書会を開催しました

はじめに

先日、友人Aさん（仮称）と雑談をしていて、

私「そういえばオライリーの『データエンジニアリングの基礎』が積読だった」

Aさん「私も私も」

という流れから、お互いの空いている時間に『データエンジニアリングの基礎』について読書会をする運びとなり、早速第1回を開催いたしました。今回のブログはそんな第1回読書会の記録（memo）となります。

読書会の記録

1章感想＆まとめ

私

• データエンジニアリングとは？
  • 「生データを取り込み、下流の分析や機械学習などで利用しやすい高品質で一貫性のある情報を生成するシステムとプロセスの開発、実装、維持管理」を意味する。
• データエンジニアとは？
  • 上記のデータエンジニアリングのライフサイクルを管理する人。
• データエンジニアとビシネスリーダーシップ
  • CDO(Chief Data Officer)
    • 最高データ責任者。データプロダクト・戦略・新規PJ・マスターデータ管理やプライバシーなどのコア機能を監督。
  • CAO(Chief Analytics Officer)
    • 最高分析責任者。CDOの職務の一部を担当する。CDO、CAOが両方存在する場合、CDOはテクノロジ、CAOはビジネス寄りの業務に注力する。
• 上流の利害関係者
  • データアーキテクト
  • SWエンジニア
  • DevOpsとSRE
• 下流の利害関係者
  • データサイエンティスト
  • データアナリスト
  • 機械学習エンジニアとAI研究者

Aさん

• データ成熟度
  • 組織全体でより高いデータ活用、能力、統合の度合いを指す
    • これはどういうこと？
    • 高いデータ活用：データを利用して社会的・利益率的にインパクトのある意思決定に貢献すること
    • 高いデータ能力：一部の社員だけでなく、組織全体がデータ抽出と業務利用ができること
    • 高いデータ統合：業務で使う些細なデータでも横断的な検索システム上で利用可能できること

第1章の疑問

• 今現在(2024年10月)、CDO、CAOが役職として明確に存在する企業ってどのくらいあるのだろうか？
  • Bayer、Chubb、Cognizant、McDonalds、Microsoft、Panera Bread、Sainsbury’sといった企業ではあるっぽい
  • 専門性というよりかは、組織統制とかデータ大事だよねと組織に根付かせる役割の期待かも。
  • そもそも経営幹部なので、技術的な専門性はそこまで要求されていないかもしれない。
• データライフサイクルって具体的になに？
  • 生データの生成から取得、変換、保存、活用、廃棄までの一連の流れ
• アジャイルってどう？
  • スプリントプランニング、ストーリポイント、バーンダウンチャートとかやってるけど、そもそも最終到達地点とか目標の共通認識が形成できてないとブレブレ
  • 技術的にアジャストしきれなくなってくるので、最初にチーム内の認識をある程度合わせていく必要がある
  • バーンダウンチャートの理想線は、これまでのチームの実績を考慮したものにできると、見通しが良くなるのではないか
    • 人の入れ替わりが激しいと、実績データ自体が意味をなさない可能性が高くなる
    • 使わないデータはコストだから取らなくていいのでは？
• データ成熟度ってなに？
  • 年数とかではない
  • 具体的に計測可能にできるか？
    • データの信頼性をアンケートとれば計測可能では？
    • 調査会社あった
  • データをもとに意思決定した結果を検証して、直感と反していたらデータ自体の不信感につながるかも
• 要はコミュニケーションできる人？
  • 分野で人は動く

脱線(大事)

• 最初の要求要件定義が大事
  • 松尾研 ゴミ出し
  • 努力目標なのにリテイク！！！！
  • 予算をもらうためにビッグマウスになって大事になりがち
    • 効率40%上がりますの計画にもコストかかっている
• AIの幻想はまだ続く
  • バズワードすぎる

2章感想＆まとめ

私

• バッチvsストリーミング
  データエンジニアが扱うデータはほぼ全て本質的に「ストリーミング」データである。そのストリームを日次単位などで大きな塊として処理する為に便宜的に用いられる方法が、「バッチ」である。

  • 多くの一般的なユースケースで適しているのは、バッチの方である。真のリアルタイムストリーミングを採用するのは、バッチの使用に対するトレードオフを正当化するビジネスユースケースを特定できた場合のみ。

• DataOpsの三本柱

  • 自動化
  • 観測と監視
  • インシデント対応
    • MLモデルが古くなって間違った予測を出力するのもインシデントの一つ。

• セキュリティはデータエンジニアにとって最重要課題

  • ただし、完全閉域網でやる場合にはデータ分析環境内に機密データが入ってくることは問題ではない
  • そもそもデータエンジニアが介在する前から考慮はされていると思われるので、それに付加的に考えることの方が多いかも。
  • BIツールで見る際の権限付与など。

• IaCは重要

• ソースシステム側の責任は大きい

  • 入力側のデータが間違っているとその後のシステムの全てがダメになる

• データの品質

  • 安全性は、SWエンジニアがあらかじめ考慮をある程度している？

Aさん

• ソースシステムとは、サイクルで使用するデータの起源を指す
• ソースシステムは直接所有しないことがほとんど
  • 間接的に、その動作や生成する方法・タイミングなどを把握する必要がある
• ストレージはデータエンジニアリングライフサイクル全体で利用する
• バッチ処理は特別な方法
  • とりこみが容易になっている
  • そもそもリアルデータはストリーミングと言っても、人間の働き方が大きく変わっていないから
    • いくつかの領域はストリーミングになるだろうって、どこやねん？
• 何のための変換か？
  • 最終消費者に対する付加価値を与える変換
  • MLのためのデータ特徴量化
• 最低限の変換
  • ビジネスロジックや経済圏や商業慣習に合わせた変換などがある
    • 広告予算の計算でレートと取得し、通貨単位を円やドルにする
    • 時刻データのタイムスタンプをJSTにする
    • ヘルスデータであれば、身長体重をもとにBMIカラムを追加するかも
  • 使うツールのインターフェースに合わせる
• データ品質の要素
  • 正確性
  • 完全性
  • 適時性
• これらは純粋な技術的手段で解決負荷。ビジネスドメインが求める水準をベースにして設定する必要がある。
• セキュリティ
  • 違反できない仕組みにするのが重要
  • 個人情報の法規制対応とかはつらいで！！！
• IaCは管理が楽でいい
  • コマンド操作から解放されるのと、バリデーションが回せる
  • 運用業務やオレオレスクリプトから解放

第2章の疑問

• 世の中のデータ分析案件は、ストリーミング的なものが多いのか？

  • 一般的なユースケース (以下リンク元より引用)

    • 位置情報データ
    • 不正の検出
    • リアルタイムの株式取引
    • マーケティング、営業、ビジネス分析
    • 顧客/ユーザーのアクティビティ
    • 社内 IT システムの監視とレポーティング
    • ログの監視 : システム、サーバー、デバイスなどのトラブルシューティング
    • SIEM (セキュリティ情報イベント管理): 監視、測定、脅威検知のためのログとリアルタイムイベントデータの分析
    • 小売/倉庫の在庫管理 : すべてのチャネルと場所を対象とした在庫管理とあらゆるデバイスでのシームレスな顧客体験の提供
    • ライドシェアのマッチング : 位置情報、ユーザー、価格設定データを組み合わせて予測分析を実現 - 距離、目的地、価格、待ち時間などから利用者とドライバーをマッチング

    • 現状でも結構あるし、今後はストリーミングのデータ分析も増えていくみたい。
• 色々なシステムのメタデータを見てみたい。
  • Glueだとこんな感じの構成
  • データリネージ
  • LayerXスライド
  • atma capスライド
• いくつかの領域はストリーミングになるだろうって、どこやねん？
  • IoT
  • 金融
  • 自動運転
  • 物流・倉庫管理
• MLモデルの更新頻度はどのくらい？
  • スクラムで動いていれば、２週間に１回更新。要はサイクルごとに確認という感じ。

個人的まとめ

第1章、第2章はともに概説という感じで、これから読み進めていく中でより詳細がわかるような感じになっているらしいことがわかりました。しかしながら、概説として、改めてデータエンジニアリングとは？データエンジニアとは？といった少々曖昧だった広い概念について、輪郭が掴めたような気がしています。また、お互い各章で生じた疑問について議論したり、脱線した内容で重要な話題があったりと、非常に実りのある読書会になったと思います。これからも読書会を続けていきたいと思います。