肉球でキーボード

MLエンジニアの技術ブログです

MicrosoftのMLOpsホワイトペーパー「Breaking the Wall between AI and DevOps with MLOps」要点まとめ

論文読み MLOps

Breaking the Wall between AI and DevOps with MLOps

microsoftの公式GitHubアカウントにMLOpsというレポジトリがあります。

その中に、MLOps whitepaper.pdfというファイルがあり、各章の要点をまとめました。

MLOps/MLOps whitepaper.pdf at master · microsoft/MLOps · GitHub

gitのcommit履歴を見るに、2019年10月に公開されたドキュメントです。

※注意

GitHubからPDFファイルをダウンロードすると執筆時のレビューコメントがある状態なので、本ドキュメントを正式なホワイトペーパーと捉えて良いか不明です。

2024年現在、他にMLOpsに関するホワイトペーパーとしての位置付けのドキュメントがmicrosoftから出ていないので、暫定的に本ドキュメントをホワイトペーパーとして取り上げます。

要点まとめ

  • MLOpsはDevOpsのCI/CDプロセスをMLモデルに適用すること
  • モデルライフサイクルのフェーズごとの、データサイエンティストとアプリ開発者の関係に着目
  • MLOpsの4つ領域に着目
    1. モデルのソース管理・再現性
    2. モデルの検証
    3. モデルのバージョン管理とストレージ
    4. モデルのデプロイメント

目次

Introduction

What is DevOps?

DevOpsはアプリケーションライフサイクル管理の標準的手法。

バージョン管理、テスト、ビルド、デプロイのツール(CI/CDパイプライン)を活用。

理想的には全工程を自動化。

Can we leverage DevOps processes for developing & deploying models?

推薦システム、画像分類、不正検知、音声テキスト変換など「AIを活用した」シナリオで機械学習モデルは開発、学習される。

MLモデルCI/CDの要件

  • 多様なデータソース、学習用ツール、分析・検証手法をサポート
  • 本番環境へのデプロイインフラストラクチャをサポート
  • データ変化に伴う定期的な新モデル作成
  • エッジとクラウドのハイブリッドデプロイに対応

大規模AIシステムの複雑さを定義する要素

  • データ量
  • モデル数
  • モデルとスコアリングパイプラインのパフォーマンス要件の関係

AIシステムのライフサイクル管理のベストプラクティスと手法は確立してない。

MLOpsの主な目的

  • モデルライフサイクル要素(学習・評価・保存・バージョニング・監視)の標準化
  • データサイエンティストとアプリ開発者の共同作業の簡素化
  • モデル開発から本番環境デプロイまでの時間短縮

本ホワイトペーパーは、モデルのCI/CDプロセスの進化とMLOps分野の主要な取り組みに着目

Evolution of the Data Scientist / App Developer relationship

DevOpsチームは全てのフローを自動化するよう努める。データサイエンティストは自動化の外側のサイロに留まる傾向がある。

モデルをアプリケーションと同じ周期のプロセスで使用することが困難となる。

Phase 1 – Enable Model Reproducibility & Auditability

データサイエンティストがモデルを開発した後

  • アプリ開発者に引き渡してアプリケーションに統合
  • アプケーションへのモデルの統合は、手動での組み込みや基本的なインターフェースの共有によって行われる
  • 特徴量前処理コードの書き換え・学習時と推論時のデータ不一致などで、統合コストが高くなる可能性がある

モデルが成熟し、本番環境で使用されるようになった後

  • アプリケーションで使用するモデルを簡単に再現できるようにする必要性が生じる
  • モデルの再学習や再デプロイが頻繁に必要となるシナリオが発生する
  • 学習・テストコードをソースコード管理・再現可能なパイプラインに組み込むことが重要

Phase 2 – Enable Model Validation

再現可能なパイプラインを導入後

  • モデル検証のプラクティスを確立する必要性が生じる
  • 学習コードの基本的な単体テスト、以前のバージョンのモデルとのABテスト、モデルのエンドツーエンドの機能とパフォーマンスのテストなど

特定のモデルを再現・反復可能になった後

  • モデル開発の速度が上がる
  • モデルのストレージとバージョン管理のためのスケーラブルな方法が必要になる

Phase 3 – Enable Controlled Rollout & Automated Retraining

検証パイプラインが整備、モデルのストレージとバージョン管理が確立された後

  • 新しいモデルをさまざまなプラットフォームに継続的にデプロイ
  • モデルを継続的に再学習する方法を実現

MLOps Overview

Focus areas

AIライフサイクルは、データ準備、モデル学習、モデルサービングという大きなバケットで構成される。

MLOpsは4つの領域に着目してる。

  1. モデルのソース管理・再現性
  2. モデルの検証
  3. モデルのバージョン管理とストレージ
  4. モデルのデプロイメント

1. Model source control / reproducibility

多くのデータサイエンティストは、ソース管理を伴わないNotebookや環境でモデル開発を始める。

データサイエンティストがソース管理をしない場合、発生する問題

  • モデルの再現性がなく、モデルの生成過程を追跡できない
  • 上流と下流でガバナンスとコンプライアンスを困難にする
  • チームがモデル間で共同作業できない
  • モデルごとソースコードの構造が異なる
  • モデルのソースコードをクローンし学習できない
  • アプリ開発者がモデルの仕組みと使い方を理解するのを困難にする

Automation & reproducibility

ソースコード管理は、アプリ開発者とデータサイエンティストが協力するための第一歩。

CI/CDソリューションは、設定が簡単で、自動化が容易であり、モデルを再現可能にする必要がある。

モデルの再現には、モデルの学習コードと入力データを追跡する。

Templates for source control

コードとソース管理のテンプレートで、モデルの土台を簡単に作成できる。

2. Model validation

標準化されたモデル検証の手段とプロセスは、高品質のモデルを継続的にリリースするのに役立つ。

モデル検証は、モデルの単体テストと、アプリ・サービスに組み込まれたモデルの機能・パフォーマンステストで構成される

モデル検証の目的は、品質の悪いモデルが本番環境に入ることを防ぐこと

Testing the model

機械学習では、アプリケーションの一部に統計的な結果がある。

モデルのテストと従来のアプリケーションのテストの違いは、明確な基準ではなく、許容される値の範囲があること

Testing the app and model together

モデルのテストに加え、より大きなアプリケーションの文脈で正常動作することを確認したい場合がある。

既存のアプリケーションのバージョンを取り込み、アプリケーションテストをモデル自体に対して実行することで実現する。

3. Model versioning and storage

データサイエンティストが多くのモデルを作成するようになると、以下のよう問題が起きる

  • 共有と共同作業の問題
  • モデルのアクセスコントロールの複雑化
  • 多様なモデル形式が再利用を難しくする

Sharing & collaboration

組織がデータサイエンスとAIに投資すると、組織全体で重複した作業を行うことに気づく。

ほとんどの場合、すべてのモデルを記録、検索可能にしたり、

マイクロサービスとしてモデルをデプロイする中央システムがない。

Permissions & traceability

モデルの保存に関するソリューションでは、アクセス制御を最優先として組み込む必要がある

Model format

機械学習の科学者の主な原則の1つは、幅広いツールを使って実験できること。

相互運用性を可能にすることで、優れたアイデアをより早く本番環境に導入できるようになる。

4. Model deployment

モデルデプロイのベストプラクティスの目的は、さまざまな推論ターゲットに対して、品質とセキュリティを維持しながら、モデルを簡単にデプロイできるようにすること

What are the targets for a model?

モデルのデプロイ方法

  • コンテナ化したスタンドアロンの推論サービスとしてデプロイ
  • バッチ処理パイプラインの一部として使用
  • 既存のアプリケーションやサービスに組み込む

デプロイの単位は、特定のシナリオでどの顧客をターゲットにしているかによって異なる。

Easy to deploy

優れたCI/CDソリューションは、エンジニアが最小限の設定でモデルを簡単にデプロイ・監視できるようにするシンプルなユーザーインターフェイスを提供する。

Easy to gate

モデルのリリースプロセスの管理は、アクセス制御、手動・自動チェック、デプロイプロセスの監査可能性が必要。

Easy to automate

ほとんどの学習パイプラインは、定義した順序で特定のジョブを実行するワークフローまたは依存関係グラフとして作成される。

現実の多くのユースケースでは継続的な学習が必要。

CI/CDソリューションは新しいデータの可用性や、特定のシグナルに基づいたトリガーをサポートする必要がある。

What’s Next?

MLOps は複雑で絶えず進化するエコシステム。

Azure DevOpsとAzure Machine Learningを使用することで、ソース管理、モデル検証、モデルのバージョン管理/ストレージ/共有、モデルのデプロイに関する問題点に対処するツールを提供する。

AWSのMLOpsホワイトペーパー「MLOps: Continuous Delivery for Machine Learning on AWS」一部要点まとめ

AWS 書籍紹介 MLOps

MLOps: Continuous Delivery for Machine Learning on AWS

AWSが2020年12月に公開した、AWSでMLOpsを実践するためのホワイトペーパーです。

MLOps: Continuous Delivery for Machine Learning on AWS

機械学習システムを運用するための要素、MLOpsと関連するAWSサービス機能の説明が書かれています。

前半のIntroductionの章はMLOps全般に関わる概念的な内容です。

Alteryx・Dataiku・Domino Data Lab・KNIMEの章はツール紹介に近い内容となっているため、本記事では割愛しています。

要点まとめ

  • AWSが2020年12月に公開した、AWSでMLOpsを実践するためのホワイトペーパー
  • 機械学習モデルを本番運用する際の手順・要素を説明
  • MLOpsに関わるAWSサービス機能を紹介

目次

1. Introduction

継続的デリバリー(CD)の原則と実践が、ソフトウェアを安全かつ信頼できる方法で継続的に本番環境に提供する。

多くの組織が機械学習が大きな価値を生むと分かり、本番環境にデプロイしようとしたが、本番環境での機械学習システムの運用課題に気づいた。

一般的な問題は、多くの機械学習プロジェクトがPoCから抜けられないこと。

機械学習システムの運用化プロセスを作成することで、組織は機械学習の新しい機会を活用できる。

ソフトウェア開発でMLモデルを使用する場合、バージョニング、品質管理、信頼性、再現性、説明性、監査可能性の課題がある。

チームのサイロ化によりプロセスに摩擦が生じる組織課題がある。

MLOpsはDevOpsを機械学習領域に拡張したもの。

MLOpsは人々が一緒に機械学習システムを構想、開発、デプロイ、運用、改善する文化を指す。

Figure 1

1.1 Continuous delivery for machine learning

継続的デリバリーは、ソフトウェアを本番環境にリリースするための信頼性の高い反復可能プロセスを作成するアプローチです。

機械学習のための継続的デリバリー(CD4ML)は、コード、データ、モデルに基づく機械学習アプリケーションを安全な小さいインクリメントで生産し、信頼性の高いリリースサイクルでリリースするアプローチ。

CD4MLのコア原則には、職務横断チームの重要性、変化する多様な変更ソースの取り込み、小さな変更の高頻度の実施、フィードバックループが含まれる。

1.2 The different process steps of CD4ML

Figure 2

CD4MLエンドツーエンドのプロセス要素

  • モデル開発
  • モデル評価・実験
  • モデルのサービス応用化
  • テスト
  • モデルデプロイ
  • 監視と可観測性

1.2.1 Model building

データサイエンティストが異なるアルゴリズムの組み合わせやパラメータ調整を行い、最適なモデルを探索・実験する。

自動化された再現可能な機械学習パイプラインは、他のデータサイエンティストが同じコードベースで共同作業し、異なる環境やデータセットに対しての作業を可能にする

1.2.2 Model evaluation and experimentation

データサイエンスプロセスは研究志向であり、複数の実験が並行して実行され、その多くが本番環境に投入されないことが一般的。

CD4MLは、異なる実行からの結果を追跡、視覚化、比較するだけでなく、有効モデルを本番環境に投入できるようサポートする必要がある。

1.2.3 Productionize the model

適切なモデルが見つかると、モデルが本番環境でどのように提供され、使用されるかを決定する必要がある。

モデルとその使用方法との間にはインターフェイス(API)が存在し、インターフェイスが変更されるとシステム統合のバグが発生する可能性がある。

1.2.4 Testing and quality

機械学習のワークフローでは、従来のソフトウェアシステムのテストとは異なるテストが必要。

テストの例: データの検証・品質テスト、コンポーネントの統合テスト、モデルの精度指標の評価、モデルのバイアスと公平性の検証。

CD4MLプロセスでは、モデルスコアなどのメトリクス収集を自動化し、トレンドの時間変化を追跡できる。

1.2.5 Deployment

最小限のリスクで本番環境にモデルをデプロイする方法

  • 同一タスクを実行する複数モデルのデプロイ
  • 新しいモデルのシャドウデプロイ
  • ユーザーセグメント別のモデルデプロイ
  • 継続的に学習するオンライン学習モデルのデプロイ

弾力的なクラウドインフラストラクチャは異なるデプロイシナリオを実装するための重要な要素

1.2.6 Monitoring and observability and closing the feedback loop

本番環境の実際のデータに対するモデルパフォーマンスを理解するために、監視、可観測性が必要。

Human in the loop は、本番環境からキャプチャされた新しいデータを人が分析、整理、ラベリングを行い、将来のモデルを改善するための新しい学習データセットを作成すること。

1.3 The technical components of CD4ML

Figure3

CD4MLの技術的要素

1.3.1 Discoverable and accessible data

良い機械学習モデルには良いデータが必要。データは簡単に発見できアクセス可能でなければならない。異なる利害関係者のニーズを考慮して設計する必要がある。

1.3.2 Version control and artifact repositories

バージョン管理ツールはチームが効率的に作業し、結果の再現性のために必須。機械学習プロジェクトはデータの複雑性が加わる。

1.3.3 Continuous delivery orchestration

継続的デリバリーのオーケストレーションツールを使用することで、エンドツーエンドのCD4MLプロセスを実装するための複雑な依存関係とワークフローをモデル化できる。

これらのツールは、デプロイパイプラインの実行を自動化し、研究から本番環境へのモデルの昇格に必要なデータガバナンスプロセスをモデル化する。

1.3.4 Infrastructure for multiple environments

クラウドインフラストラクチャを使用することはCD4MLに多くの利点があるが、厳格な要件ではない。

  • 必要に応じてリソースを増減できる弾力性とスケーラビリティ
  • 機械学習モデルの学習に特化した専用ハードウェアの利用が可能
  • データと機械学習プラットフォーム管理に特化したサービスへのアクセス
  • インフラの使用状況に基づく従量制課金モデルの利用が可能

1.3.5 Model performance assessment tracking

モデル、パラメータ、結果を開発チーム全体が透明な方法で追跡できることが重要。

1.3.6 Model monitoring and observability

本番環境の機械学習モデルを、以下の疑問に答えるために継続的に監視する必要がある

  • モデルの性能はどうか？
  • モデルに供給される実際のデータは何？
  • データは学習データと異なる特性を持つか？
  • パフォーマンスは低下しているか？
  • データやモデルのパフォーマンスに偏りはあるか？

2~5. Alteryx・Dataiku・Domino Data Lab・KNIME

AWS Partner Network(APN)企業が提供するサービスでCD4MLプロセスを実現する方法を紹介する章。

ツールについての話がメインなので割愛。

6. AWS reference architecture

MLOpsのトピックと、紹介されてる関連AWSサービスの形式でまとめる。

6.1 Model building

6.1.1 Discoverable and accessible assets

  • データレイクの活用
  • データの拡張と取り込み
    • AWS Data Exchange
  • データラベリング
    • Amazon SageMaker Ground Truth
  • 特徴量の共有と提供
    • Amazon SageMaker Feature Store

Figure 35

6.1.2 Model experimentation

  • 実験のためのプラットフォーム
  • セキュリティとアクセス管理
  • 弾力的なプラットフォームの提供
  • 効率的な実験ワークロードの管理
    • Amazon SageMaker training job
  • バージョン管理と共有
    • AWS CodeCommit
  • 自動化された実験

Figure 36

6.2 Productionize the model

6.2.1 Scale model training

  • 学習ジョブのスケーリングと自動化
  • フルコントロールと柔軟性の提供
  • ハイパーパラメータの最適化と自動化

6.2.2 Automate auditable pipelines

6.3 Testing and quality

6.3.1 AI fairness and explainability

  • バイアス検出と説明可能なAI(XAI)の導入
  • データ内のバイアスの測定と軽減
  • 学習済みモデルの予測バイアスの特定
  • SHAPを使用したモデルの説明

6.4 Deployment

Figure 43

6.5 Monitoring and observability and closing the feedback

6.5.1 Model monitoring

  • ドリフト検知
    • SageMaker Model Monitor
      Figure 44

6.5.2 Traceability and auditing

  • モデルソースの追跡
    • SageMaker Pipeline

6.5.3 Human review and continuous improvement

  • MLに対する人間のレビュー

6.6 High-level AI services

Figure 45

6.6.1 Productionizing AWS AI services

6.7 AWS: Your journey ahead

MLOpsの成熟への道のりは進化的なプロセス。AWSはこのプロセスをサポートする。

GoogleのMLOps実践ホワイトペーパー Practitioners Guide to Machine Learning Operations (MLOps) 要点まとめ

MLOps 論文読み

Googleが公開した、MLOps実践のためのホワイトペーパー

GoogleがMLOps実践のためのホワイトペーパーを公開しています。

Practitioners Guide to Machine Learning Operations (MLOps)

2021年5月に公開されたものですが、2024年現在に読んでも色褪せない内容だったので、各章の要点をまとめました。

TL;DR

  • Googleが2021年5月に公開したMLOpsの実践のためのホワイトペーパー
  • MLOpsライフサイクルの全体像・コア機能を解説
  • MLOpsのコアプロセスの詳細を解説
    • コアプロセス: ML開発、学習の運用化、継続的学習、モデルデプロイ、推論サービス、継続的監視、データ・モデル管理

目次

以下、各章の要点です

1. Executive summary

本書はGoogle Cloudが公開してる AI Adoption Frameworkの中から、スケールと自動化を詳しく掘り下げた内容。

本ドキュメントはコアコンセプトと技術的機能を定義するMLOpsフレームワークを解説。

2部構成

  1. MLOpsのライフサイクルの概要。全ての読者が対象。
  2. MLOpsのプロセスとスキルの詳細。MLOpsの具体的なタスクを知りたい読者が対象。

2. Overview of MLOps lifecycle and core capabilities

様々な企業に対しての調査結果から、機械学習モデルが本番環境にデプロイされずに終わる、またはデプロイされても環境変化に追従できず失敗する事例が数多く見られる。

この要因を考えた研究に共通してることは、MLシステムをDataOpsやDevOpsのようなML以外の技術から分離したアドホックな方法で構築できないからであるということ。

組織にはMLエンジニアリングによって実現できる、自動化されたスムーズなMLプロセスが必要。

MLOpsはMLエンジニアリングのための方法論であり、MLシステムの開発と運用を統合する。

MLOpsの実践による利点

  • 開発サイクルの短縮・市場投入までの時間短縮
  • チーム間の協力の向上
  • MLシステムの信頼性・パフォーマンス・拡張性・セキュリティの向上
  • 運用・ガバナンスプロセスの効率化
  • MLプロジェクトの費用対効果の改善

2.1 Building an ML-enabled system

MLを活用したシステムの構築は、データエンジニアリング・MLエンジニアリング・アプリケーションエンジニアリングを組み合わせた多面的な取り組み。

Figure 1

2.2 The MLOps lifecycle

MLOpsのライフサイクルは、7つの統合された反復プロセスが含まれる。

Figure 2

  • モデル開発
    • 汎用性が高く再現性のあるモデル学習パイプラインの実験と開発
  • モデル学習の運用化
    • 再利用可能で信頼性の高い学習パイプラインのパッケージ化・テスト・デプロイのプロセスを自動化
  • 継続的学習
    • 新しいデータやコードの変更・スケジュールに従って学習パイプラインを実行
  • モデルデプロイ
    • オンライン実験と本番サービングのためにモデルをパッケージ化・テスト・デプロイ
  • 推論サービス
    • 本番環境のモデルを推論のためにデプロイ
  • 継続的監視
    • デプロイされたモデルの効果と効率を監視
  • データ・モデル管理

2.3 MLOps: An end-to-end workflow

MLOpsプロセスの典型的なフロー。

Figure 3

2.4 MLOps capabilities

MLOpsプロセスを効果的に実装するために、組織は一連のコア技術機能を確立する必要がある。

スケーラブルでセキュアなインフラストラクチャ・標準化された構成管理とCI/CD環境が、ITシステムを構築するための基盤機能。

この上にMLOpsの機能である、実験・データ処理・モデルトレーニング・モデル評価・モデルサービング・オンライン実験・モデル監視・MLパイプライン・モデルレジストリがある。

横断的な能力として、MLメタデータ・アーティファクトレポジトリと、データセット・特徴量レポジトリがある。

Figure 4

2.4.1 Experimentation

主要機能

  • バージョン管理ツールと統合されたノートブック環境を提供
  • 再現性と比較のために、データ・ハイパーパラメータ・評価指標の情報を含んだ実験の追跡
  • データ・モデルの分析と可視化
  • データセットの探索、実験の確認、実装レビューをサポート
  • プラットフォームにある他のデータ・機械学習サービスとの統合

2.4.2 Data processing

主要機能

  • 短時間の実験のためのインタラクティブな実行、長時間の本番環境でのジョブ実行に対応
  • 様々なデータソースやサービスとの接続、様々なデータ構造やフォーマットに対するエンコーダとデコーダを提供
  • 構造化・非構造化データに対して、豊富で効率的なデータ変換と特徴エンジニアリングを提供
  • ML学習と推論サービング処理のために、スケーラブルなバッチ・ストリームデータ処理に対応

2.4.3 Model training

主要機能

  • 一般的なMLフレームワーク・カスタムランタイム環境に対応
  • 複数GPUと複数ワーカーに対する、異なる戦略の大規模な分散学習
  • MLアクセラレータのオンデマンド利用
  • スケールする効率的なハイパーパラメータチューニングとターゲット最適化に対応
  • 理想的には、特徴量選択・特徴量エンジニアリング・モデルアーキテクチャ探索と選択の自動化を含む、組み込みのAutoML機能を提供

2.4.4 Model evaluation

主要機能

  • 大規模な評価データセットでモデルのバッチ評価を実行
  • 様々な分割データに対して事前定義 or カスタム評価指標を計算
  • 異なる学習環境の学習済みモデルの予測パフォーマンスを追跡
  • 異なるモデル同士の精度を視覚化・比較
  • 何かの分析やバイアスや公平性の問題を特定するツールを提供
  • Explainable AI技術を使用したモデルの振る舞いの解釈

2.4.5 Model serving

主要機能

  • 低レイテンシーのリアルタイム推論と高スループットのバッチ推論に対応
  • 一般的なMLサービングフレームワークとカスタムランタイム環境の組み込みサポートを提供
  • 結果集約前に複数モデルを階層的に呼び出す合成予測ルーチンと、事前・事後処理ルーチンに対応
  • ワークロードのスパイクに対応し、コストとレイテンシーのバランスを保つためにオートスケーリングする、ML推論アクセラレータの効率的な使用
  • 特徴量重要度などの技術を使用したモデル解釈性を提供
  • 分析のための予測リクエスト・レスポンスのロギング

2.4.6 Online experimentation

主要機能

2.4.7 Model monitoring

主要機能

  • レイテンシやサービングリソース利用率など、モデル効率の指標を測定
  • スキーマの異常、データ・コンセプトのシフト・ドリフトなどの、データ歪みを検出
  • デプロイされたモデルのパフォーマンスを継続的に評価するために、モデル評価機能と監視を統合

2.4.8 ML pipelines

主要機能

  • オンデマンド、スケジューリング、特定イベントに応じてパイプラインをトリガー
  • ML開発中のデバッグのために、ローカルでの対話型実行に対応
  • MLメタデータ追跡機能と統合し、パイプラインの実行パラメータを保持、アーティファクトを生成
  • 一般的なMLタスク向けの組み込みコンポーネントとカスタムコンポーネントを提供
  • ローカルマシンやスケーラブルなクラウドプラットフォームの異なる環境で実行
  • パイプラインの設計および構築のためのGUIツールを提供

2.4.9 Model registry

主要機能

  • 学習済み、デプロイされたMLモデルの登録、整理、追跡、バージョン管理
  • デプロイ可能性のためにモデルメタデータとランタイム依存関係を保持
  • モデルのドキュメントとレポーティングを維持
  • モデル評価およびデプロイ機能を統合し、モデルのオンライン・オフライン評価指標を追跡
  • モデルの起動プロセス(レビュー・承認・リリース・ロールバック)の管理

2.4.10 Dataset and feature repository

主要機能

  • データ資産の共有性・発見性・再利用性・バージョニング
  • イベントストリーミングやオンライン予測ワークロードに対する、リアルタイムデータ取り込みと低レイテンシーサービング
  • ETLプロセスやモデル学習、モデル評価ワークロードに対する、高スループットのバッチ取り込みとサービング
  • 特定時点のクエリ用に対する特徴のバージョニング
  • テーブル、画像、テキストなど、さまざまなデータ形式をサポート

2.4.11 ML metadata and artifact tracking

主要機能

3. Deep dive of MLOps processes

3.1 ML development

実験プロセスはML開発の中心的活動であり、データサイエンティストがデータ準備とモデル学習のためのアイディアを素早く試すことができる。

実験の目的は手元のMLユースケースに対して効果的なプロトタイプモデルを作ること。

データサイエンティストはML学習手順をエンドツーエンドのパイプラインを実装することで形式化する必要がある。

以下はML開発のプロセスの全体像を表した図。

Figure 5

実験プロセスの成功要因は実験の追跡、再現性、協調にある。

実験を再現するためにデータサイエンティストが以下の実験設定を追跡する必要がある。

  • バージョン管理システム内の学習コードのバージョン
  • モデルアーキテクチャと事前学習済みモジュール
  • ハイパーパラメータ
  • 学習・検証・テストデータの分割に関する情報
  • モデル評価指標と検証手順

MLモデルを定期的に再学習する場合、継続的学習パイプラインの実装が本番環境にデプロイされる。

新しい特徴やデータセットはデータエンジニアリングパイプラインに統合される。

3.2 Training operationalization

学習の運用化は、繰り返し可能なML学習パイプラインを開発・テストし、実行環境にデプロイするプロセス。

MLOpsでは、MLエンジニアは設定を使用してMLパイプラインを展開できる必要がある。

通常、パイプラインは本番環境にリリースされる前に、一連のテスト、検証環境を経由する。

コードファースト技術を使用する場合、MLエンジニアは標準のCI/CDプロセスとツールを使用してパイプラインをデプロイできる。

以下は学習パイプラインのデプロイを表した図

Figure 6

3.3 Continuous training

継続的学習プロセスは、学習パイプラインの実行をオーケストレーションおよび自動化すること。モデルの再学習の頻度は、MLのユースケースや再学習のビジネス価値およびコストに依存する。

学習パイプラインのトリガー方法

  • スケジュールされた実行
  • イベント駆動
  • 手動実行

以下は典型的なML学習パイプラインの流れを表した図

Figure 7

以下のワークフローが含まれる

  1. データ取り込み
  2. データ検証
  3. データ変換
  4. モデル学習
  5. モデル評価
  6. モデル検証
  7. モデル登録

継続的学習の重要な側面はデータとモデルが追跡可能であること。

完全なパイプラインをすべての組織で構築するのは実用的ではない場合がある。

3.4 Model deployment

モデルデプロイプロセスでは、モデルがパッケージ化・テストされ、目的のサービング環境にデプロイされる。

ノーコードやローコードのソリューションを使用する場合、モデルデプロイプロセスは簡素化・抽象化される。モデルレジストリ内のモデルエントリを指定すると自動的にデプロイされる。

デプロイに細かな制御が必要な場合、複雑なCI/CDルーチンが必要。ソースコードからモデルを取得し、テスト、ビルド、検証、デプロイを行う。

以下はCI/CDのプロセスを表した図

Figure 9

CIステージでは、モデルのインターフェース、互換性、レイテンシなどがテストされる。

CDステージでは、カナリアデプロイやシャドウデプロイなどの方法を用いて、進行的な配信が行われる。

オンライン実験は特にMLの文脈で重要。A/Bテストや多腕バンディットテストなどの抱負を用いて、新しいモデルの本番環境での効果をテストする。

3.5 Prediction serving

予測サービングプロセスは、モデルがサービング環境にデプロイされた後、予測リクエストを受け付け、予測結果と共にレスポンスを提供する。

予測サービングの要素を表した図

Figure 10

予測値を以下の形式で提供する

  • オンライン推論
  • ストリーミング推論
  • バッチ推論
  • エッジデバイス上での推論

サービングエンジンはリクエストに関する特徴量を必要とする場合、特徴量レポジトリから特徴量を取得しモデルへ入力する。

MLシステムの信頼性の一部は、モデルの解釈と予測に対する説明が可能であること。特徴量寄与度を用いて予測の根拠を明らかにする。

推論ログや他のメトリクスは、継続的な監視と分析のために保存する。

3.6 Continuous monitoring

継続的監視は、本番環境のモデルの有効性と効率を監視するプロセスで。MLOpsの重要な領域。

典型的な継続監視プロセスの手順

Figure 11

  1. リクエスト・レスポンスのペイロードのサンプルをキャプチャ
  2. 推論ログのスキーマ生成・統計計算
  3. 推論ログ統計とベースライン統計の比較から分布のズレを特定
  4. グラウンドトゥルースを利用した予測の評価
  5. 異常時のアラート

効果的なパフォーマンス監視は、モデルの劣化を検出することを目指す。モデルの劣化は、データドリフト・コンセプトドリフトで定義される。

モデルのサービング効率の監視は、リソース利用率、レイテンシ、スループット、エラー率などの指標に注目する。

3.7 Data and model management

3.7.1 Dataset and feature management

データサイエンスと機械学習の主要な課題の1つは、モデル学習用の高品質なデータを作成、維持、再利用すること。

データサイエンティストは、探索的データ分析、データ準備、データ変換に多くの時間を費やす。

予測サービングの一般的な課題は、トレーニングサービングスキューと呼ばれる、推論データと学習データの間の不一致。

データセット・特徴の管理は、このような問題を軽減するために、データセット・特徴の統一されたリポジトリを提供する。

以下はデータセット・特徴のリポジトリを使用して、複数用途にエンティティを提供する図

Figure 12

3.7.1.1 Feature management

特徴量は標準的なビジネスルールに基づいて整理された、ビジネスエンティティの属性。

データエンティティを中央管理レポジトリで管理することで、学習とサービングのためにエンティティの定義、保存、アクセスを標準化できる。

特徴量レポジトリで以下のことが行えるようになる

  • 利用可能な特徴を再利用
  • 特徴量の定義を確立
  • トレーニングサービングスキューの回避
  • 最新の特徴値を取得
  • 新しいエンティティと特徴を定義し、共有する
  • チーム間協力の改善

バッチETLシステムでは、学習タスクのために特徴をバッチとして取得できる。

オンラインサービングでは、サービングエンジンが要求されたエンティティに関連する特徴値を取得できる。

3.7.1.2 Dataset management

データセットは特定のMLタスクやユースケースに使用される。

データセット管理は、以下の点で役立つ

  • 異なる環境でデータセットを作成
  • チーム内で単一のデータセット定義と実現を維持
  • 同じデータセットとタスクに共同作業しているチームメンバーにとって役立つメタデータと注釈を維持する。
  • 再現性と系列追跡を提供

3.7.2 Model management

モデル管理は組織がリスクを管理し、MLモデルを責任を持って実装し、規制を遵守するためのコントロール。

モデル管理は以下の点で役立つ

  • データの品質とプライバシーの保証
  • モデルの品質と公平性の保証
  • モデルの解釈性と説明可能性の保証
  • モデルのパフォーマンスの監視と報告
  • 潜在的な問題の追跡とデバッグ

3.7.2.1 ML metadata tracking

MLメタデータトラッキングは、異なるMLOpsプロセスと統合される。

キャプチャされるMLメタデータには、パイプラインの実行ID、トリガー、プロセスタイプ、ステップ、開始・終了日時、ステータス、環境構成、入力パラメータ値など。

MLメタデータトラッキングにより、再現性と系列追跡のために実験パラメータやパイプライン構成を追跡することができる。

また、ユーザーはMLモデルやアーティファクトを検索、発見、エクスポートできるようになる。

MLメタデータトラッキングは、異なる実験や実行のメタデータとアーティファクトを分析、比較、視覚化するツールを提供し、問題の特定と解決を支援する。

Figure 13

3.7.2.2 Model governance

モデルガバナンスは、モデルの登録、レビュー、検証、承認に関するプロセス。

モデルガバナンスは以下のタスクを実行する

  • 保存: モデルのプロパティを追加・更新し、バージョンや変更を追跡
  • 評価: 新しいモデルをチャンピオンモデルと比較。評価メトリックスとビジネスKPIを使用して、モデルの品質を確認。
  • チェック: リスクを管理するためにモデルをレビュー、リクエスト変更、承認する
  • リリース: モデルデプロイプロセスを呼び出し、本番環境へ移行
  • レポート: 継続的な評価から収集されたモデルのパフォーマンスメトリックスを集計・可視化

4. Putting it all together

MLでビジネス価値を提供することは、ビジネス環境の変化に適応する統合されたMLシステムを構築すること。

以下の要素が含まれる

  • MLデータセットと特徴の収集、処理、管理
  • スケールするモデルの学習と評価
  • 予測のためのモデルのサービング
  • 本番環境のモデルパフォーマンス監視
  • モデルのメタデータとアーティファクト追跡

本ドキュメントでは以下の説明を行った

  • MLシステムの構築および運用のためのコア機能
  • 開発から本番環境へのワークフローを効率化する包括的MLOpsプロセス
    Figure 15

データエンジニアリングの基礎を読みました

書籍紹介


「データエンジニアリングの基礎」を読んだので、感想・各章の内容についてまとめます

www.oreilly.co.jp

全体を通しての感想

原本は Fundamentals of Data Engineering で本書は日本語訳となります。
筆者のJoe Reis氏とMatt Housley氏はデータエンジニアリングのコンサルタントを行っていて、業界経験が長いお二人です。
データエンジニア界隈は急速に変化する業界と本文中で書かれています。
業界変化の中で「変わらないもの」を選択し、今後数年間役に立つコンセプトをまとめたものと本書を説明しています。

上記の狙い通り、本書はツールや特定技術ソリューションの話題は避け、データエンジニアリングの背後にある普遍的な技術概念の説明に徹しています。
SQL実行の内部の処理や、磁気ディスクドライブの物理挙動にまで踏み込んでいて、データエンジニアリングの基礎というタイトルにふさわしい内容でした。
データエンジニアリング領域に関わらず、エンジニアリング一般論として興味深いテーマについてベテランエンジニアの見解を知れる贅沢な内容でした。

日本語訳ですが、英語原本での独特の言い回しを日本語でも伝わるよう丁寧に訳されてるのが伝わってきて、非常に読みやすかったです。
今後、データエンジニアの必読書となるだろう一冊でした。

Ⅰ部データエンジニアリングの基礎と構成要素

1章 データエンジニアリング概説

1.1　データエンジニアリングとは何か
    1.1.1　データエンジニアリングの定義
    1.1.2　データエンジニアリングライフサイクル
    1.1.3　データエンジニアの発展
    1.1.4　データエンジニアリングとデータサイエンス
1.2　データエンジニアリングのスキルと活動
    1.2.1　データ成熟度とデータエンジニア
    1.2.2　データエンジニアに求められる背景知識とスキル
    1.2.3　ビジネス上の責務
    1.2.4　技術的責務
    1.2.5　データエンジニアの役割のスペクトラム：タイプAからタイプBまで
1.3　組織内でのデータエンジニアリング
    1.3.1　内向きデータエンジニアと外向きデータエンジニア
    1.3.2　データエンジニアと他の技術職
    1.3.3　データエンジニアとビジネスリーダーシップ
1.4　結論
1.5　参考資料

データエンジニアリングとデータエンジニアとは？について整理しています。データエンジニアリングの歴史と、データエンジニアと類似職種との関係性の話は個人的に面白かったです。

組織におけるデータエンジニアの非技術的な役割が書かれています。多くの利害関係者をつなぐ役割が求められると述べられていて、非技術部分の業務のウェイトが大きい印象を受けました。

2章 データエンジニアリングライフサイクル

2.1　データエンジニアリングライフサイクルとは何か？
    2.1.1　データライフサイクルとデータエンジニアリングライフサイクル
    2.1.2　生成：ソースシステム
    2.1.3　保存（ストレージ）
    2.1.4　取り込み
    2.1.5　変換
    2.1.6　データの提供
2.2　データエンジニアリングにおける主要な底流
    2.2.1　セキュリティ
    2.2.2　データ管理
    2.2.3　DataOps
    2.2.4　データアーキテクチャ
    2.2.5　オーケストレーション
    2.2.6　ソフトウェアエンジニアリング
2.3　結論
2.4　参考資料

本書ではデータをプロダクト価値に変えていく一連の流れをデータエンジニアリングライフサイクルという言葉で表現しています。

データエンジニアリングライフサイクルは、データの生成・保存・取り込み・変換・提供で構成されます。これらの土台となる要素がセキュリティ・データ管理・DataOps・データアーキテクチャ・オーケストレーション・ソフトウェアエンジニアとしています。

データエンジニアリングの技術範囲が自分は曖昧だったので、体系的に整理してる内容は貴重でした。データ運用のためのOpsに着目したDataOpsという概念を初めて知りました。

3章 適切なデータアーキテクチャの設計

3.1　データアーキテクチャとは何か？
    3.1.1　エンタープライズアーキテクチャとは何か？
    3.1.2　データアーキテクチャの定義
    3.1.3　「良い」データアーキテクチャ
3.2　良いデータアーキテクチャの原則
    原則1：共通コンポーネントを賢く選択する
    原則2：障害に備える
    原則3：スケーラビリティ設計
    原則4：アーキテクチャはリーダーシップだ
    原則5：常に設計し続ける
    原則6：疎結合システムを構築する
    原則7：可逆な決定をする
    原則8：セキュリティを優先する
    原則9：FinOpsを活用する
3.3　主要なアーキテクチャの概念
    3.3.1　ドメインとサービス
    3.3.2　分散システム、スケーラビリティ、障害に備えた設計
    3.3.3　密結合と疎結合：ティア、モノリス、マイクロサービス
    3.3.4　ユーザアクセス：シングルテナントとマルチテナント
    3.3.5　イベント駆動アーキテクチャ
    3.3.6　ブラウンフィールドプロジェクトとグリーンフィールドプロジェクト
3.4　データアーキテクチャの例と種類
    3.4.1　データウェアハウス
    3.4.2　データレイク
    3.4.3　次世代データレイクとデータプラットフォームの収斂
    3.4.4　モダンデータスタック
    3.4.5　Lambdaアーキテクチャ
    3.4.6　Kappaアーキテクチャ
    3.4.7　Dataflowモデル、バッチ、ストリームの統合
    3.4.8　IoTのためのアーキテクチャ
    3.4.9　データメッシュ
    3.4.10　その他のデータアーキテクチャ
3.5　データアーキテクチャの設計にかかわるのは誰か
3.6　結論
3.7　参考資料

本書ではデータアーキテクチャを「データアーキテクチャは、企業の進化するデータへの要求をサポートするシステム設計であり、トレードオフを慎重に評価した上での柔軟で可逆な決定を通じて実現される」と定義してます。

データアーキテクチャの例としてデータウェアハウス、データレイクを取り上げています。

アーキテクチャが抽象度が高い概念で、様々な定義がされてる言葉なので、世の中のアーキテクチャに対する共通見解を丁寧に整理してくれてます。

4章 データエンジニアリングライフサイクルにおけるテクノロジの選択

4.1　チームのサイズと容量
4.2　市場投入までのスピード
4.3　相互運用性
4.4　コスト最適化とビジネス価値
    4.4.1　総所有コスト（TCO）
    4.4.2　所有の総機会費用
    4.4.3　FinOps
4.5　現在vs.未来：不変テクノロジvs.一過性テクノロジ
    4.5.1　アドバイス
4.6　設置場所
    4.6.1　オンプレミス
    4.6.2　クラウド
    4.6.3　ハイブリッドクラウド
    4.6.4　マルチクラウド
    4.6.5　非中央集権型計算：ブロックチェーンとエッジ
    4.6.6　アドバイス
    4.6.7　クラウドからオンプレミスへの本国回帰
4.7　構築vs.購入
    4.7.1　オープンソースソフトウェア
    4.7.2　プロプライエタリなウォールドガーデン
    4.7.3　アドバイス
4.8　モノリスvs.モジュール
    4.8.1　モノリス
    4.8.2　モジュール性
    4.8.3　分散モノリスパターン
    4.8.4　アドバイス
4.9　サーバレスvs.サーバ
    4.9.1　サーバレス
    4.9.2　コンテナ
    4.9.3　サーバとサーバレスの評価方法
    4.9.4　アドバイス
4.10　最適化、性能、ベンチマーク戦争
    4.10.1　1990年代の「ビッグデータ」
    4.10.2　無意味なコスト比較
    4.10.3　非対称な最適化
    4.10.4　購入者責任
4.11　底流とテクノロジ選択への影響
    4.11.1　データ管理
    4.11.2　DataOps
    4.11.3　データ管理
    4.11.4　オーケストレーションの例：Airflow
    4.11.5　ソフトウェアエンジニアリング
4.12　結論
4.13　参考資料

前章のデータアーキテクチャの設計ができたのち、どのテクノロジーで実現するかの章になります。

オンプレvsクラウドや、モノリスvsモジュールといった、データエンジニアにとらわれず一般的にエンジニア界隈で議論に上がるテーマを取り扱っています。

これらのテーマに対するシニアエンジニアからの見解やアドバイスが書かれていて、この章を読むためだけに本書を買う価値があると思えるほどでした。

Ⅱ部 データエンジニアリングライフサイクルの詳細

5章 ソースシステムにおけるデータ生成

5.1　データソース：データはどのように生成されるのか？
5.2　ソースシステム：主要な概念
    5.2.1　ファイルと非構造化データ
    5.2.2　API
    5.2.3　アプリケーションデータベース（OLTPシステム）
    5.2.4　OLAP：オンラインアナリティクス処理システム
    5.2.5　変更データキャプチャ
    5.2.6　ログ
    5.2.7　データベースログ
    5.2.8　CRUD
    5.2.9　インサートオンリー
    5.2.10　メッセージとストリーム
    5.2.11　時間と時刻の種類
5.3　ソースシステムの実践的な詳細
    5.3.1　データベース
    5.3.2　API
    5.3.3　データ共有
    5.3.4　サードパーティデータソース
    5.3.5　メッセージキューとイベントストリーミングパイプライン
5.4　一緒に仕事する人
5.5　底流とそのソースシステムへの影響
    5.5.1　セキュリティ
    5.5.2　データ管理
    5.5.3　DataOps
    5.5.4　データアーキテクチャ
    5.5.5　オーケストレーション
    5.5.6　ソフトウェアエンジニアリング
5.6　結論
5.7　参考資料

データ生成に着目した章です。

データ形式ごとの各データベースの特徴が網羅されていて、贅沢な内容になっています。

ストリームデータの取り扱いについても取り上げられているのはありがたいです。

データ生成元はデータエンジニアの制御の外にあることが多いですが、データエンジニアライフサイクルにおいて重要な部分と指摘してます。

そのため、データエンジニアがアプリケーションチームとうまくコラボレーションできるよう、利害関係を構築する話がなされています。

6章 ストレージへの保存

6.1　データストレージの原材料
    6.1.1　磁気ディスクドライブ
    6.1.2　SSD（ソリッドステートドライブ）
    6.1.3　RAM（ランダムアクセスメモリ）
    6.1.4　ネットワークとCPU
    6.1.5　シリアライズ
    6.1.6　圧縮
    6.1.7　キャッシュ
6.2　データストレージシステム
    6.2.1　単体サーバvs.分散ストレージ
    6.2.2　結果整合性と強い一貫性
    6.2.3　ファイルストレージ
    6.2.4　ブロックストレージ
    6.2.5　オブジェクトストレージ
    6.2.6　キャッシュとメモリベースのストレージシステム
    6.2.7　HDFS（Hadoop分散ファイルシステム）
    6.2.8　ストリーミングストレージ
    6.2.9　インデックス、パーティション分割、クラスタリング
6.3　データエンジニアリングにおけるストレージ抽象
    6.3.1　データウェアハウス
    6.3.2　データレイク
    6.3.3　データレイクハウス
    6.3.4　データプラットフォーム
    6.3.5　ストリーム・トゥ・バッチストレージアーキテクチャ
6.4　ストレージの要点とトレンド
    6.4.1　データカタログ
    6.4.2　データ共有
    6.4.3　スキーマ
    6.4.4　コンピュートとストレージの分離
    6.4.5　データストレージのライフサイクルとデータ保持
    6.4.6　シングルテナントvs.マルチテナント
6.5　一緒に仕事する人
6.6　底流
    6.6.1　セキュリティ
    6.6.2　データ管理
    6.6.3　DataOps
    6.6.4　データアーキテクチャ
    6.6.5　オーケストレーション
    6.6.6　ソフトウェアエンジニアリング
6.7　結論
6.8　参考資料

データの保存に着目した章です。

ストレージがあまりにも一般的で当たり前のものと思いがちなため、ストレージメディアに内在するトレードオフを知らないデータエンジニアが多いと指摘しています。

そのため、磁気ディスクドライブの物理的な挙動にまで踏み込んでいて、ここまで解説するのかと筆者らへ尊敬の念を抱きました。

理解が曖昧だったデータレイクハウスについて具体的な説明があったのはありがたかったです。

7章 データ取り込み

7.1　データ取り込みとは
7.2　取り込みフェーズにおけるエンジニアリング上の重要な検討事項
    7.2.1　区切りありデータvs.区切りなしデータ
    7.2.2　頻度
    7.2.3　同期vs.非同期
    7.2.4　シリアライズとデシリアライズ
    7.2.5　スループットとスケーラビリティ
    7.2.6　信頼性と耐久性
    7.2.7　ペイロード
    7.2.8　プッシュvs.プルvs.ポーリング
7.3　バッチ取り込みに関する検討事項
    7.3.1　スナップショットまたは差分抽出
    7.3.2　ファイルのエクスポートと取り込み
    7.3.3　ETL vs. ELT
    7.3.4　挿入、更新とバッチサイズ
    7.3.5　データの移行
7.4　メッセージ取り込みとストリーム取り込みの検討事項
    7.4.1　スキーマ進化
    7.4.2　遅延到着データ
    7.4.3　順序と多重配送
    7.4.4　リプレイ
    7.4.5　TTL（Time to Live）
    7.4.6　メッセージサイズ
    7.4.7　エラー処理とデッドレターキュー
    7.4.8　消費者によるプルとプッシュ
    7.4.9　場所
7.5　データ取り込みの方法
    7.5.1　直接データベース接続
    7.5.2　CDC：変更データキャプチャ
    7.5.3　API
    7.5.4　 メッセージキューおよびイベントストリーミングプラットフォーム
    7.5.5　マネージドデータコネクタ
    7.5.6　オブジェクトストレージを用いたデータの移動
    7.5.7　EDI
    7.5.8　データベースとファイルのエクスポート
    7.5.9　一般的なファイルフォーマットに関する現実的な問題
    7.5.10　シェル
    7.5.11　SSH
    7.5.12　SFTPとSCP
    7.5.13　Webhook
    7.5.14　Webインタフェース
    7.5.15　Webスクレイピング
    7.5.16　データ移行のための転送アプライアンス
    7.5.17　データ共有
7.6　一緒に仕事する人
    7.6.1　上流の利害関係者
    7.6.2　下流の利害関係者
7.7　底流
    7.7.1　セキュリティ
    7.7.2　データ管理
    7.7.3　DataOps
    7.7.4　オーケストレーション
    7.7.5　ソフトウェアエンジニアリング
7.8　結論
7.9　参考資料

前章のデータ生成とストレージを結びつける、データ取り込みについての章です。

バッチやストリーム取り込みのパターンや、データ取り込みに関する技術テーマを幅広く取り扱っています。

データ品質テストについても触れられています。データソースに暗黙的な変化があることで、データ利用者が気付かぬうちに被害を受ける例をあげています。

データスキーマやニーズは変化するもので、変化する前提でデータアーキテクチャを設計するのが本書の基本姿勢です。

8章 クエリ、データモデリング、変換

8.1　クエリ
    8.1.1　クエリとは何か？
    8.1.2　クエリのライフサイクル
    8.1.3　クエリオプティマイザ
    8.1.4　クエリ性能の向上
    8.1.5　ストリームデータに対するクエリ
8.2　データモデリング
    8.2.1　データモデルとは何か？
    8.2.2　概念データモデル、論理データモデル、物理データモデル
    8.2.3　正規化
    8.2.4　バッチアナリティクスデータのモデリング手法
    8.2.5　ストリームデータモデリング
8.3　変換
    8.3.1　バッチ変換
    8.3.2　マテリアライズドビュー、フェデレーテッドクエリ、データ仮想化
    8.3.3　ストリーミング変換と処理
8.4　一緒に仕事する人
    8.4.1　上流の利害関係者
    8.4.2　下流の利害関係者
8.5　底流
    8.5.1　セキュリティ
    8.5.2　データ管理
    8.5.3　DataOps
    8.5.4　データアーキテクチャ
    8.5.5　オーケストレーション
    8.5.6　ソフトウェアエンジニアリング
8.6　結論
8.7　参考資料

データ変換に着目した章です。

SQLが内部でどのような処理が実行されているかを説明しています。クエリ性能向上のための方法が理屈と共に紹介されているのがありがたいです。

データモデリングの手法としてKimball, Inmon, データボルトを取り上げています。

UDFを使用する危うさを指摘してます。コードがバージョン管理から外れ、組み込みのSQLコマンドより性能が悪化する可能性があると述べられています。

UDFは便利でつい使ってしまいがちだったので反省しました。

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

9.1　データ提供に関する一般的な考慮事項
    9.1.1　信頼
    9.1.2　ユースケースは何か？ ユーザは誰か？
    9.1.3　データプロダクト
    9.1.4　セルフサービスにするべきか？
    9.1.5　データ定義とロジック
    9.1.6　データメッシュ
9.2　アナリティクス
    9.2.1　ビジネスアナリティクス
    9.2.2　オペレーショナルアナリティクス
    9.2.3　組み込みアナリティクス
9.3　機械学習
9.4　データエンジニアがMLについて知っておくべきこと
9.5　アナリティクスやMLに対してデータを提供する方法
    9.5.1　ファイル交換
    9.5.2　データベース
    9.5.3　ストリーミングシステム
    9.5.4　クエリフェデレーション
    9.5.5　データ共有
    9.5.6　セマンティックレイヤとメトリクスレイヤ
    9.5.7　ノートブックによるデータの提供
9.6　リバースETL
9.7　一緒に仕事する人
9.8　底流
    9.8.1　セキュリティ
    9.8.2　データ管理
    9.8.3　DataOps
    9.8.4　データアーキテクチャ
    9.8.5　オーケストレーション
    9.8.6　ソフトウェアエンジニアリング
9.9　結論
9.10　参考資料

データの提供に着目した章です。

データのユースケースとユーザーから考え、データプロジェクトを始める重要性を説いています。ユースケースとして分析やMLをあげ、ユーザーにアナリストやDS、MLエンジニア、そしてビジネス職を取り上げています。

ユーザーが自分でデータプロダクトを構築するセルフサービスにすべきかの議論が興味深かったです。

エンドユーザーを理解してないと、セルフサービス化は難しいと指摘しています。

Ⅲ部 セキュリティとプライバシー、およびデータエンジニアリングの未来

10章 セキュリティとプライバシー

10.1　人材
    10.1.1　ネガティブ思考の力
    10.1.2　常に心配性でいる
10.2　プロセス
    10.2.1　劇場型セキュリティvs.習慣としてのセキュリティ
    10.2.2　アクティブセキュリティ
    10.2.3　最小権限の原則
    10.2.4　クラウドでの責任共有
    10.2.5　常にデータのバックアップを取る
    10.2.6　セキュリティポリシーの例
10.3　テクノロジ
    10.3.1　パッチとシステムアップデート
    10.3.2　暗号化
    10.3.3　ロギング、監視、アラート
    10.3.4　ネットワークアクセス
    10.3.5　低レイヤデータエンジニアリングにおけるセキュリティ
10.4　結論
10.5　参考資料

セキュリティについてデータエンジニアリングライフサイクルの全てのステージで最初に考える必要があると指摘しています。

データエンジニア領域に関わるセキュリティ項目の各概要を取り上げています。

顧客データの漏洩ニュースをよく見かけますが、データエンジニアを務める以上は対岸の火事では済まされないなと感じる内容でした。

11章 データエンジニアリングの未来

11.1　データエンジニアリングライフサイクルは消えない
11.2　複雑さの衰退と使いやすいデータツールの興隆
11.3　クラウドスケールデータOSと相互運用性の改善
11.4　「大企業的」データエンジニアリング
11.5　職種名と担当範囲は変化する
11.6　 モダンデータスタックからの脱却とライブデータスタックへの移行
    11.6.1　ライブデータスタック
    11.6.2　 ストリーミングパイプラインとリアルタイムアナリティクスデータベース
    11.6.3　データとアプリケーションの融合
    11.6.4　アプリケーションとML間での緊密なフィードバック
    11.6.5　ダークマターデータとスプレッドシートの興隆？
11.7　結論

データエンジニアの今後の未来予想の章です。

データエンジニアリングライフサイクルはすぐに消えることはないが、ソフトウェアエンジニア、データエンジニア、データサイエンティスト、MLエンジニアの境界がより曖昧になっていくと指摘しています。

データ界隈の職種で生きるなら、技術領域は広めに持っておいた方がいいと自分は考えていたので、共感できる部分が多かったです。

ワークフローオーケストレーションの歴史

ツール MLOps

Data Engineering Study #23 Data orchestration 特集の発表「ワークフローオーケストレーション入門」から、ワークフローオーケストレーションの歴史について記事にまとめました。

概要

近年データエンジニアリングの周辺技術が話題に上がるようになり、ワークフローオーケストレーションが注目を集めています。

workflow orchestration関連語のGoogle Trend

上図はワークフローオーケストレーションの関連ワードのGoogle Trendです。

データオーケストレーションを中心として、ワークフローオーケストレーション関連語の検索数が上昇傾向にあります。

本記事では最新のワークフローオーケストレーションの動向を知るために、ワークフローオーケストレーションの歴史を深ぼります。

Prefect社のブログ記事 A Brief History of Workflow Orchestration をもとに、ワークフローオーケストレーションの歴史を5つの時代に区分しました。

  • CRON時代
  • リレーショナルデータベース時代
  • データウェアハウス・データ統合時代
  • ビッグデータ時代
  • モダンデータスタック時代

各時代の主要なツールをまとめると以下のように変遷してきています。

ワークフローオーケストレーションツールの変遷

CRON時代

ワークフローオーケストレーションの歴史はCRONから始まりました。

1974年にUNIXにCRONが導入されました。

機能は指定された時刻にコマンドを実行するというものでした。

以下はCRONコマンドを用いて、一連の処理を記述したシェルスクリプトを定期実行する例です。

0 0 0 1 1 * ./workflow.sh

CRONは特定の処理をスケジュール実行したい場合の手段として使い勝手が良く、現在も幅広く使用されている機能です。

リレーショナルデータベース時代

1979年に商用リレーショナルデータベースのOracle v2がリリースされました。

その後、1995年にOracleがジョブキュー(DBMS_JOB)を導入します。

機能はデータベース用コードの定期的な実行をスケジュールするものでした。

以下は新しくDBMS_JOBジョブを作成するPL/SQLコード例です。

PL/SQL(Procedural Language/Structured Query Language)はOracleデータベースで使用されるプログラミング言語です。

DECLARE
  job_number NUMBER;
BEGIN
  DBMS_JOB.SUBMIT(
    job       => job_number,
    what      => 'BEGIN YOUR_PROCEDURE_NAME; END;',
    next_date => SYSDATE,
    interval  => 'SYSDATE + 1'
  );
  COMMIT;
END;

DBMS_JOBのようにリレーショナルデータベースの機能の一部として、ジョブのスケジュール実行を行えるようになりました。

データウェアハウス・データ統合時代

データウェアハウスが登場し、データ統合が行われる以前、複数のデータソースごとデータを処理していました。

例えば、アプリケーションデータはCRONで処理し、リレーショナルデータベースは付属機能のジョブを実行するといった状況です。

データウェアハウス・データ統合以前の状況

複数のデータソースからデータを収集・変換し、データウェアハウスに格納するETL処理が主流となってきました。

データウェアハウス・データ統合

データをソースからターゲットに変換する機能を提供するツールが登場します。

代表的なのは1998年にInformatica社がリリースしたPowerCenterです。

PowerCenterはスケジュールされたジョブの実行・管理を中心としたツールでした。

データ処理のソースとターゲット、2つを繋ぐワークフローの概念が初めて導入されました。

以下はPowerCenterのデータマッピングの設定画面の例です。

PowerCenter

ビッグデータ時代

2006年にGoogleがHadoopをOSS化し、2011年にデータレイクが提唱・流行します。

Hadoopにより分散処理が可能となったことで、大量のデータをデータレイクに格納できるようになりました。

格納したデータを活用方法に応じて処理するELT処理が主流となります。

データ基盤構築はオンプレ環境のHadoopエコシステムで作られるケースが増えてきました。

Hadoopエコシステムのデータ基盤

Hadoopエコシステムを活用するためのワークフローオーケストレーションツールが登場します。

これらのツールはワークフローツール第一世代と呼ばれることが多いです。

代表的なツールだとOozie, Luigi, Azkabanがあります。いずれのツールもHadoopジョブを管理する機能がGitHubのREADMEに記述されています。

現在も使用例が多いAirflowはワークフロー管理のプラットフォームの立ち位置ですが、時代背景的にはHadoopジョブの管理の課題感から生まれたツールになっています。

ワークフローツール第1世代

モダンデータスタック時代

2011年 BigQuery(GCP)がGA、2013年 Redshift(AWS)がGA, Sparkを事業化したDatabricks社が設立、2014年 SnowflakeがGA、Kafkaを事業化したConfluent社が設立されます。

新しい技術の登場により、データ基盤に変化が起きました

  • オンプレから安価で高速なクラウドにデータ基盤がシフト
  • ストリームデータ処理技術が発達

このような新しいデータ基盤の課題を解決するツールに対し、Modern Data Stackという言葉を当てるようになりました。

Data Stackはデータ基盤を構成する製品群を意味します。Modern Data Stackは従来のData Stackの課題を解決しようとする技術トレンドの総称で、特定のアーキテクチャ・技術・ソリューションを指す言葉ではありません。
データ活用領域のトレンド「Modern Data Stack」に関するホワイトペーパーを公開 | NTTデータグループ - NTT DATA GROUP

Emerging Architectures for Modern Data Infrastructure: 2020 | Andreessen Horowitz の記事でデータ基盤技術の変化がまとめられています。技術トレンドの変化に、ワークフローオーケストレーションが含まれています。

Architecture Shifts in Data Infrastructure (Emerging Architectures for Modern Data Infrastructure: 2020より引用)

Modern Data Stackと呼ばれるような新たなワークフローオーケストレーションツールが登場し始めました。

2016年 DigdagがOSS化、StepFunctions(AWS)がGA、2017年 Prefectがリリース、ArgoがOSS化、2018年 Dagsterがリリース、2019年 CloudComposer(GCP)がGA

これらはワークフローツール第二世代と呼ばれ、次世代のワークフローツールとして近年注目を集めています。

まとめ

ワークフローオーケストレーションの歴史を5つの時代に区分し、各時代の主要なツールを以下のようにまとめました。

ワークフローオーケストレーションツールの変遷

データ基盤がオンプレからクラウドへ移り変わり、Modern Data Stackと呼ばれる新しいツールを組み合わせてデータ基盤を構築するのが現代の主流となりました。

この技術トレンドの変化からワークフローオーケストレーションの注目が集まってきていると言えます。

参考

入門 考える技術・書く技術を読みました

書籍紹介


「入門　考える技術・書く技術」の読書メモ
www.diamond.co.jp

全体を通しての感想

バーバラ・ミント氏著のピラミッド原則をまとめた「考える技術・書く技術」に対する、「日本人による日本人のための実践ガイド」とまえがきで述べられています。
全168Pと文量が少ないのと、本書の題材の通り簡潔な文章でまとめられているため、非常に読みやすい内容でした。

自分は業務でデータ分析の結果をまとめたドキュメントを書いています。
同僚のドキュメントを真似て自分なりのルールでドキュメントを作成していました。
質の高い技術文書を書く方法 - As a Futurist...
の記事を読み、文章を書く技術を体系的に学ぼうと思ったのが本書を読み始めた動機です。

本書はビジネス職向けの内容ですが技術文章にも使える汎用的な内容となっていました。
本文が4章のうち3章が考えるプロセスについての内容となっているため、論理的に考える技術がそのまま書く技術に繋がっているのが分かります。

序章. 誤解だらけのライティング

- 誰も教えてくれなかったレポート・ライティング
  - 誤解１　書きたいことを書きなさい
  - 誤解２　起承転結で書きなさい
- グローバル・スタンダードを学ぶ
  - レポートを受ける立場になって読んでみる
  - 考えるプロセスと書くプロセスを分ける

日本の教育がライティングを学ぶ機会がないことを指摘しています。

  • 作文や感想文のような自分の書きたいことを書く教育が行われる
    • 読み手のために書くライティングの基本が欠如してる
  • 起承転結で書く教育から、結論を最後に書く習慣が染み付いてる
    • 結論を冒頭に書くビジネス文書の原則に反する

本文に入る前のウォーミングアップとして、読み手の立場を考えたライティングの流れを紹介しています。
結論が最後に書かれた場合と、結論を冒頭に書き判断根拠を箇条書きで分かりやすく表現した場合を比較しています。
両者の違いは「書くプロセス」ではなく、前段階の「考えるプロセス」にあると指摘しています。
考えるプロセスを行うためにピラミッド原則を取り上げています。
以降の本文でピラミッド原則に則ったライティング方法が書かれています。

1章. 読み手の関心・疑問に向かって書く

- 読み手は何に関心を持ち、どんな疑問を抱くのか
- 読み手の関心を呼び起こすには
- 読み手の疑問を明らかにする「OPQ分析」
- OPQ分析のコツ

ビジネス文書は読み手の疑問に対する答えが伝えるべきメッセージであり、それ以外の関心のないテーマは読まれないと言い切っています。
なので、読み手の理解がビジネス文書を書くための最重要ポイントとしています。

読み手の疑問と伝えるべきメッセージを、問題報告書・販売企画書・セミナーへの案内状・履歴書に添えるレター・クライアントへの提案書を例に書かれています。

読み手を分析する手法としてOPQ分析を取り上げています。

  • Objective (望ましい状況)
    • 読み手が目指している望ましい状況
  • Problem (問題. 現状とObjectiveとのギャップ)
    • 解決すべき問題
  • Question (読み手の疑問)
    • 問題に直面した読み手が、その解決に向けて自然に抱くだろう疑問
  • Answer (答え. 文書の主メッセージ)
    • 読み手の疑問に対する答えが、そのまま文書の主メッセージになる. 疑問(Q)に忠実に答えることが大切
  • レール(トピック)
    • OPQAの内容を同じモノサシで比べる

OPQ分析のコツを3つあげています

  • すべて読み手の視点で表現する
  • 比較のレール(トピック)を外さない
  • 文書の主メッセージはQに直接答える

OPQ分析の練習問題として、売り上げ目標の達成・不良資産の発覚・在庫削減か売り上げ増かを扱う際のOPQAを例示しています。

2章. 考えを形にする

- メッセージの構造を明らかにする
  - 一度に覚えられる数には限界がある
  - メッセージ構造をそのまま文書へ
- グループ化と要約メッセージ
  - メッセージが一般論にならないようにする
- 要約メッセージを文章にするときの「４つの鉄則」
  - 鉄則（１）名詞表現、体言止めは使用禁止とする
  - 鉄則（２）「あいまい言葉」は使用禁止とする
  - 鉄則（３）メッセージはただ1つの文章で表現する
  - 鉄則（４）「しりてが」接続詞は使用禁止とする
- 「So What?」を繰り返す

読み手は内容を理解するために受けとった情報をグループ化し、理解可能な考えの数に収めようとします。そのため書き手が情報をグループ化することで、読み手の負担を減らせると指摘しています。
ピラミッド型に組み立てたメッセージ構造がそのまま文章構造となります。

考えを組み立てるプロセスは2種類の作業があるとし、2つの作業で相互チェックしながら考えを組み立てていきます。

  • グループ化し、要約メッセージを探す
  • メッセージに従って、グループを作る

「グループ化」と「要約メッセージ」がピラミッドの要となる。

要約メッセージ作成の注意点として、一般論にならないようにすると述べられています。
多くの人が全てをカバーできそうな包括的・抽象的な言葉を選んでしまいがちであると指摘しています。
決定的な言い回しを避けて、曖昧さを残した言葉を選ぶ経験が自分にもあったので反省しました。

要約メッセージを作成する際の4つの鉄則が述べられています

  • 名詞表現、体言止めは使用禁止とする
  • 「あいまい言葉」は使用禁止とする
  • メッセージはただ1つの文章で表現する
  • 「しりてが」接続詞は使用禁止とする

1つ目の鉄則の例に

  • 過去5年、ベトナム市場は年率19%で拡大している
  • 過去5年、インドネシア市場は年率18%で拡大している
  • 過去5年、タイ市場は年率18%で拡大している

のメッセージから考えられる要約メッセージの悪い例として「東南アジア市場の推移」という言葉が挙げられていました。
文章ではありませんが、自分がよく行なっている分析データの見出しにも通じるものがあるなと思いました。

4つ目の鉄則の、論理的な関係が明確でない「しりてが」接続詞は、「...し、…」「…であり、…」「…して、…」「…だが、…」「…せず、…」「…なく、…」という言葉です。

3章. ピラミッドを作る

- 帰納法でロジックを展開する
  - 帰納法の仕組み
  - 「同じ種類の考え」を前提とする
  - 帰納法は「つなぎ言葉」でチェックする
  - 結論を先に述べる
- 演繹法でロジックを展開する
  - ビジネスで演繹法を使う際の注意点
  - 演繹法は「前提」をチェックする
- ピラミッド作成のコツ
  - コツ（１） １つの考えを短く明快に
  - コツ（２） 縦と横の「二次元」を意識する
  - １対１の関係に要注意
  - １対１の番外編「イメージによる説得」

ロジックの基本である帰納法と演算法を紹介しています。
帰納法とは複数の特定事象(前提)から、要約(結論)を導くロジック展開です。
帰納法の表現スタイルは「私の言いたいことは、…です。理由は3つあります。第一の理由は…、第二の理由は…、第三の理由は…」となります。

演算法とは絶対に正しいことや、一般的に正しいと判断されること(前提)から、妥当と思われる結論を導くものです。
演算法は一見すると流れがスムーズなので、それが帰ってロジックの誤謬を気付きにくくさせると注意しています。

ピラミッド作成のコツを2つ取り上げています

  • １つの考えを短く明快に
    • 主メッセージとキーラインを早めに決める
    • ピラミッド内で文章を書こうとしない
  • 縦と横の「二次元」を意識する
    • 縦の関係
      • 上が結論で下が根拠・説明の関係
    • 横の関係
      • 結論を導くロジックの流れ
    • ピラミッドの縦横を無視しない

4章. 文章で表現する

- 文書全体の構造はピラミッドに同じ
  - ケース「X事業投資」
  - 主メッセージの位置
  - 目次のつけ方
- 段落表現のビジネス・スタンダード
  - 段落は「改行＋大きめの行間」で
- 文章のわかりやすさは「接続詞」次第
  - ロジカル接続詞
  - 「しりてが」接続詞の使用ルール
  - 曖昧な接続詞は誤訳のモト
- 読み手を引きつける「導入部」
  - OPQ分析を使って導入部を作る
- 「結び」で今後のステップを示唆する

考えるプロセスで作ったピラミッド型のメッセージ構成を崩さず、そのまま構造が見えるような文章で表現するのが書くプロセスでは大切と述べています。
文書表現の基本は以下を挙げています

  • メッセージごとの固まりが一目でわかるようにする
  • 各メッセージ文を固まりの冒頭に配置する
  • ピラミッドのメッセージをそのまま形にする

段落表現の基本は以下を挙げています

  • メッセージごとに段落を作る(1段落1メッセージ)
  • 段落の違い(メッセージの固まり)を明確に表現する
  • 段落のメッセージ文を段落の冒頭に置く(主メッセージ同様、例外的に段落の最後に置くこともある)

ビジネス・ライティングでの段落の作り方を「改行に加えて、通常より大きめの行間を設ける」ことで段落の違いを目立たせると説明しています。
この段落の作り方はあまり意識したことがなかったので、実践してみようと思いました。

文章のわかりやすさは「接続詞」で決まると説明されています。
しりてが接続詞の「and接続詞」は使わず、因果関係を表すロジカル接続詞だけを使うよう推奨しています。

導入部はメッセージを何人もの読み手を対象とする正式な文章やプレゼン資料では不可欠なものと述べています。
導入部はOPQ分析を使って、読み手の関心をひく方法を紹介しています。

終章. メール劇的向上術

- メールが見違えるように変わる「感謝の言葉にPDF」
- 「１日１回ピラミッド」×４カ月

メールの書き方の方法に「感謝の言葉にPDF」という合言葉を使った方法を紹介しています。

  • 感謝の言葉
    • いきなり本文に入らず、簡潔に1, 2行を使って感謝の言葉を述べるようにする
    • 「感謝の言葉」が自分勝手なライティングのブレーキになる
  • P(主メッセージ部分)
    • Purpose Statement (目的文)
  • D(詳細)
    • Detail (詳細)
    • 主メッセージの理由・判断根拠・内容説明・具体案
    • PとDがメール本文になる
  • F(今後のアクション)
    • Follow-Through(フォロースルー)
    • 読み手に求めるアクション・自分のアクションの説明

pyenv-virtualenv initでプロンプト表示速度が低下する問題

Python

問題

~/.zshrcに記述した eval "$(pyenv virtualenv-init -)" によって、zshのプロンプト表示が遅くなってることに気づきました。

原因と解決方法を調べたのでまとめました。

結論

~/.zshrcに記述するのを

eval "$(pyenv virtualenv-init -)"

↓

eval "$(pyenv virtualenv-init - | sed s/precmd/chpwd/g)"

に変更する

pyenv-virtualenv initとは？

GitHub - pyenv/pyenv-virtualenv: a pyenv plugin to manage virtualenv (a.k.a. python-virtualenv).

カレントディレクトリにある.python-versionの設定に基づいて、python仮想環境を自動的にactivate/deactivateします。

.python-version ファイルは、pyenv でローカルのPython バージョンを設定するために、pyenv local コマンドで作成・削除できます。

原因

展開されるシェルスクリプトの内容を確認します。

$ echo $(pyenv virtualenv-init -)

以下のシェルスクリプトが実行されています。処理内容を見ていきます。

export PATH="/Users/satsuki/.pyenv/plugins/pyenv-virtualenv/shims:${PATH}"
export PYENV_VIRTUALENV_INIT=1

_pyenv_virtualenv_hook() {
    local ret=$?
    if [ -n "${VIRTUAL_ENV-}" ]; then
        eval "$(pyenv sh-activate --quiet || pyenv sh-deactivate --quiet || true)" || true
    else
        eval "$(pyenv sh-activate --quiet || true)" || true
    fi
    return $ret
}

typeset -g -a precmd_functions

if [[ -z $precmd_functions[(r)_pyenv_virtualenv_hook] ]]; then
    precmd_functions=(_pyenv_virtualenv_hook $precmd_functions)
fi

_pyenv_virtualenv_hook という関数が定義されています。この関数では以下の処理が実行されます。

  • 仮想環境が存在する場合、環境をactivateし、失敗した場合deactiveを行う
  • 仮想環境が存在しない場合、環境をactivateする

zshでは precmd_functions というグローバルな配列で、プロンプトが変更された時に実行する関数を管理しています。

zsh: 9 Functions

作成した_pyenv_virtualenv_hook 関数を precmd_functions 配列に追加しています。

これにより、プロンプトが変更されるたびにvirtualenvの仮想環境のactivateが実行され、zshの動作が重くなります。

解決方法

pyenv-virtualenvのGitHub Issueでシェル動作が遅くなる現象のDiscussionがあり、回避方法が提案されています。

Slow shell performance after running pyenv virtualenv-init · Issue #259 · pyenv/pyenv-virtualenv · GitHub

eval "$(pyenv virtualenv-init)” の代わりに以下を ~/.zshrcに書き込みます

eval "$(pyenv virtualenv-init - | sed s/precmd/chpwd/g)"

上記のコマンドでは、先ほどのpyenv virtualenv-init で展開されるシェルスクリプト内のprecmdの文字列をchpwdに書き換えています。

chpwd_functions というグローバルな配列で、カレントディレクトリが変更された時に実行する関数を管理しています。

よって、プロンプトを変更する度に仮想環境をactivateしていた処理を、カレントディレクトリを変更する度に実行するよう変更しています。

プロンプト表示速度の変化

zsh-prompt-benchmarkでzshのプロンプトレンダリング速度を測ってみました。

修正前

********************************************************************
                      Prompt Benchmark Results
********************************************************************
Warmup duration      8s
Benchmark duration   2.050s
Benchmarked prompts  7
Time per prompt      292.84ms  <-- prompt latency (lower is better)
********************************************************************

修正前

修正後

********************************************************************
                      Prompt Benchmark Results
********************************************************************
Warmup duration      8s
Benchmark duration   2.015s
Benchmarked prompts  78
Time per prompt      25.84ms  <-- prompt latency (lower is better)
********************************************************************

修正後

プロンプト表示速度が大きく改善しました。

参考