AWSと製紙工場で世界中のJupyterノートをスケーリング
9006 ワード
データ科学者として、faethmについて私に最も刺激的なことの一つは、データサイエンスは私たちの製品の中心部にあることです.
我々のデータ・エンジニアリング・チームのトップとして、我々のデータサイエンスが我々の急速に成長している世界的な顧客ベースのニーズを満たすためにスケールすることができるのは、私の責任です.
この記事では、私たちのアプローチの最も興味深い部分のいくつかを共有してデータ科学製品のスケーリングと、我々が取り組むべきユニークな課題のいくつかを共有します.
我々のアプローチを掘る前に、faethmと我々がすることについてのいくつかのことを理解することは重要です.
私たちの顧客は私たちに仕事の将来を理解するために依存し、その技術と仕事パターンのシフトは、その最も重要な資産にしている影響:その人々.
我々のデータサイエンスチームは、我々の職業オントロジーを設計して、構築することに責任があります.私たちの分析は、適切な機械学習モデルのスイートから派生しています.
私たちのプラットフォームは、人々の指導者、戦略のリーダーと技術のリーダーを助けるために一緒にそれをすべて一緒に関係しています.
私たちのデータの科学者は、主にPython、Jupyterノートブックとデータ変換、分析、モデリングのためのPythonパッケージの成長の範囲を使用すると、任意のデータの科学者のツールキット(おそらくいくつかはあなたがそうでない)を見て期待するだろう.
幸いにも、クラウドでインタラクティブJupyter Workbenchを実行してかなり簡単です.
AWS Sagemakerは私たちのチームのための管理プラットフォームの要件を設定し、オンデマンドでオンとオフを有効にするためのノートブックプラットフォームを提供します.可変的な強力なモデリング環境へのセルフサービスアクセスは、AWSコンソールでいくつかのIAM役割方針といくつかのクリックを管理することを必要とします.
これは、データ科学者がAWSコンソールにssoすることができて、彼らのアクセスプロフィールによって許されるどんなS 3データへのアクセスでも彼らの次のプロジェクトを始めることを意味します.結果は、S 3に書かれ、ノートブックは適切なGitリポジトリにプッシュされました.
どのように、我々は我々のデータ科学者がこれまでに操作のワークフローを走らせることについて考えなければならないように、これを製品に変えますか?
我々のアプローチのコア設計目標の一つは、可能な限りデータサイエンスワークフローを再工学することなくスケールすることである.
我々のモデルの複雑さのために、データ科学者が彼らのモデルが生産で機能している方法の完全な透明性を持つことは、重要です.それで、我々はJupyterノートブックを書き直さないでください.実行可能なPythonスクリプトにコードを複製していません.私たちはちょうどそれらを実行し、正確に書かれた、変更は必要ありません.
私たちはペーパーミルでこれを行います.
papermillは、パラメータをパラメータ化し、実行するためのPythonパッケージです.ノートブックがダイナミックな機能(通常、最初のノートブック・セルの賢明なデフォルトで)のためにパラメタで書かれる限り、papermillはノートを実行することができます
単純なペーパーミルコマンドライン操作は次のようになります.
ペーパークラフトは、私たちのノートブックを実行するために素晴らしいですが、我々は、彼らが作成されたSageMakerインスタンスの外で実行されるノートPCが必要です.我々は我々のノートと一緒にいくつかの余分な工芸品をキャプチャすることによってこれを達成することができます.
まず、プロジェクトのGitリポジトリにパッケージ依存関係の一覧を格納します.これはJupyter端末で簡単に生成されます
他のいかなる依存関係も倉庫に格納されます.これらはスクリプト、pickle化されたオブジェクト(訓練されたモデルなど)と一般的なメタデータを含むことができます.
また、YAML設定ファイルでメタデータを取得します.
最後に、簡単な
ノートブック、依存関係およびその他のリポジトリの項目への変更は、他のソフトウェアプロジェクトと同様に、生産と非生産のGit分岐の組み合わせで管理されます.プル要求は、ステージングと生産環境の間のコード促進のためのプロセスを提供し、手動コードレビューを容易にし、コード変更に自信を作成する一連のマージチェックを自動化します.
データサイエンスチームをデータサイエンスワークフローの作成に集中し、パイプラインを構築しないようにするために、コンテナビルドと展開プロセスは個々のJupyterプロジェクトから抽象化されます.
WebHooksは各gitリポジトリに設定されます.ノートブックプロジェクトの分岐にプッシュすると、ビルドプロセスがトリガされます.ステージングと生産ブランチはすべての変更のためにプル要求を必要とすることによって悪いコミットから保護されます.
規格
AWS CodeBuildはリポジトリブランチからターゲット環境を決定し、コンテナをビルドし、AWS ECRにプッシュします.
faethmの顧客は世界中の多くの異なる地域にまたがると、データは、各顧客のローカル管轄のデータ規則を対象としています.我々のデータサイエンスワークフローは、我々の顧客が格納される彼らのデータのために指定する地域で実行することができなければなりません.我々のアプローチによって、データは処理のために領域の間で転送する必要はありません.
我々は、アジア太平洋、米国とヨーロッパ全体で、世界中の顧客地域の増加した数の雲環境を操作します.faethmが拡大し続けるので、我々は新しい地域を支えることができる必要があります.
私たちのJupyterノートブックコンテナを実行するには、サポートされている各領域には、必要に応じてノートブックタスクを実行するように構成されたECS Fargateクラスタを持つVPCがあります.
それぞれのJupyterプロジェクトはECSタスク定義に関連付けられており、ECSタスク定義テンプレートはビルドパイプラインによって構成され、CloudFormationで展開されます.
タスク実行を単純化するために、各々のノート・リポジトリは一つのイベント・トリガーを有する.代表的に、ノートブック・タスクは、S 3のデータオブジェクト着陸に応答して実行される.例は、ユーザーポータルからアップロードされているCSVです.
プロジェクトリポジトリでは、YAML設定ファイルはS 3バケットとプレフィックスを捕捉し、EventBridgeに送られるCloudTrailログが一致するときにECSタスク定義をトリガーします.
EventBridge規則テンプレートは、ビルドパイプラインによって構成され、CloudFormationを介して展開され、Jupyterノートブックの自動実行の基本要件を完了します.
この記事では、マルチ領域環境におけるデータサイエンスワークフローのスケーリングと自動化への挑戦のいくつかを見ました.我々はまた、Jupyter生態系の中でそれらを扱う方法を見てきたし、どのように我々は様々なAWSの無制限の提供を活用するソリューションを実装している.
これらのすべてを一緒に置くと、その結果は、コードデータサイエンスのワークフロー実行パイプラインアーキテクチャとして、エンドツーエンドのServerless Git Osのコンテナ化されたイベント駆動Jupyterノートブックです.
私たちはそれを呼び出す
あなたは、faethm ai工学ブログからポストを読んでいました.また、私たちは雇用している!仕事の将来のために我々の情熱を共有して、パイオニアの世界データサイエンスとエンジニアリングプロジェクトをリードしたいならば、我々はあなたから連絡をもらいたいです.現在の開始位置を参照してください.https://faethm.ai/careers
我々のデータ・エンジニアリング・チームのトップとして、我々のデータサイエンスが我々の急速に成長している世界的な顧客ベースのニーズを満たすためにスケールすることができるのは、私の責任です.
この記事では、私たちのアプローチの最も興味深い部分のいくつかを共有してデータ科学製品のスケーリングと、我々が取り組むべきユニークな課題のいくつかを共有します.
Faethmは、仕事の進化のためのデータサイエンスです
我々のアプローチを掘る前に、faethmと我々がすることについてのいくつかのことを理解することは重要です.
私たちの顧客は私たちに仕事の将来を理解するために依存し、その技術と仕事パターンのシフトは、その最も重要な資産にしている影響:その人々.
我々のデータサイエンスチームは、我々の職業オントロジーを設計して、構築することに責任があります.私たちの分析は、適切な機械学習モデルのスイートから派生しています.
私たちのプラットフォームは、人々の指導者、戦略のリーダーと技術のリーダーを助けるために一緒にそれをすべて一緒に関係しています.
我々は、データサイエンスのPythonとJupyterノートブックを使用して
私たちのデータの科学者は、主にPython、Jupyterノートブックとデータ変換、分析、モデリングのためのPythonパッケージの成長の範囲を使用すると、任意のデータの科学者のツールキット(おそらくいくつかはあなたがそうでない)を見て期待するだろう.
幸いにも、クラウドでインタラクティブJupyter Workbenchを実行してかなり簡単です.
AWS Sagemakerは私たちのチームのための管理プラットフォームの要件を設定し、オンデマンドでオンとオフを有効にするためのノートブックプラットフォームを提供します.可変的な強力なモデリング環境へのセルフサービスアクセスは、AWSコンソールでいくつかのIAM役割方針といくつかのクリックを管理することを必要とします.
これは、データ科学者がAWSコンソールにssoすることができて、彼らのアクセスプロフィールによって許されるどんなS 3データへのアクセスでも彼らの次のプロジェクトを始めることを意味します.結果は、S 3に書かれ、ノートブックは適切なGitリポジトリにプッシュされました.
どのように、我々は我々のデータ科学者がこれまでに操作のワークフローを走らせることについて考えなければならないように、これを製品に変えますか?
エンジニアリングのデータサイエンス
我々のアプローチのコア設計目標の一つは、可能な限りデータサイエンスワークフローを再工学することなくスケールすることである.
我々のモデルの複雑さのために、データ科学者が彼らのモデルが生産で機能している方法の完全な透明性を持つことは、重要です.それで、我々はJupyterノートブックを書き直さないでください.実行可能なPythonスクリプトにコードを複製していません.私たちはちょうどそれらを実行し、正確に書かれた、変更は必要ありません.
私たちはペーパーミルでこれを行います.
papermillは、パラメータをパラメータ化し、実行するためのPythonパッケージです.ノートブックがダイナミックな機能(通常、最初のノートブック・セルの賢明なデフォルトで)のためにパラメタで書かれる限り、papermillはノートを実行することができます
$NOTEBOOK
) コマンドを1行で指定します.任意のパラメータ-r
生か-p
実行時に上書きすることができ、Papermillは新しいパラメータ値を割り当てる新しいノートブックセルを注入することでこれを行うことができます.単純なペーパーミルコマンドライン操作は次のようになります.
pip install papermill
papermill "$NOTEBOOK" "$OUTPUT_NOTEBOOK" \
-r A_RAW_PARAMETER "this is always a Python string" \
-p A_PARAMETER "True" # this is converted to a Python data type
ペーパーミルはノートブックを実行するので、コードだけでなく、印刷文、エラーメッセージ、テーブル、およびプロットを含むセル出力は、結果として生じる出力ノートにすべて表示される$OUTPUT_NOTEBOOK
). これは、ノートブック自体が実行されたものの豊富なログになることを意味し、モデルの性能を評価し、すべてのプロセスの異常を検出するためにデータ科学者のための友好的な診断ツールとして機能します.再生可能なノートワークフロー
ペーパークラフトは、私たちのノートブックを実行するために素晴らしいですが、我々は、彼らが作成されたSageMakerインスタンスの外で実行されるノートPCが必要です.我々は我々のノートと一緒にいくつかの余分な工芸品をキャプチャすることによってこれを達成することができます.
まず、プロジェクトのGitリポジトリにパッケージ依存関係の一覧を格納します.これはJupyter端末で簡単に生成されます
pip freeze > requirements.txt
, しかし、しばしば最高の手は必需品に依存関係を維持するために作ら.他のいかなる依存関係も倉庫に格納されます.これらはスクリプト、pickle化されたオブジェクト(訓練されたモデルなど)と一般的なメタデータを含むことができます.
また、YAML設定ファイルでメタデータを取得します.
...
Notebooks:
- my-notebook.ipynb
- my-second-notebook.ipynb
...
このファイルは実行順序でノートブックをリストするので、ワークフローは読みやすさを維持するために複数の独立したノートブックで構成することができます.最後に、簡単な
buildspec.yml
ビルドプロセスを開始する設定ファイルが含まれます.これはビルドパイプラインとして使用するAWS CodeBuildの標準です.ノートブック、依存関係およびその他のリポジトリの項目への変更は、他のソフトウェアプロジェクトと同様に、生産と非生産のGit分岐の組み合わせで管理されます.プル要求は、ステージングと生産環境の間のコード促進のためのプロセスを提供し、手動コードレビューを容易にし、コード変更に自信を作成する一連のマージチェックを自動化します.
生産展開用に構築したノートブックコンテナ
データサイエンスチームをデータサイエンスワークフローの作成に集中し、パイプラインを構築しないようにするために、コンテナビルドと展開プロセスは個々のJupyterプロジェクトから抽象化されます.
WebHooksは各gitリポジトリに設定されます.ノートブックプロジェクトの分岐にプッシュすると、ビルドプロセスがトリガされます.ステージングと生産ブランチはすべての変更のためにプル要求を必要とすることによって悪いコミットから保護されます.
規格
Dockerfile
ビルド時にプロジェクトリポジトリに格納されているアーティファクトを消費します.FROM python:3.7
RUN pip install papermill
# package dependencies
COPY requirements.txt
RUN pip install -r requirements.txt
# notebook execution order from YAML config
ARG NOTEBOOKS
ENV NOTEBOOKS=${NOTEBOOKS}
# prepare entrypoint script
COPY entrypoint.sh
# catch-all for other dependencies in the repository
COPY .
# these parameters will be injected at run-time
ENV PARAM1=
ENV PARAM2=
CMD ./entrypoint.sh
entrypointは反復bashスクリプトです.#!/bin/bash
for NOTEBOOK in ${NOTEBOOKS//,/ }
do
papermill "$NOTEBOOK" "s3://notebook-output-bucket/$NOTEBOOK" \
-r PARAM1 "$PARAM1" \
-p PARAM2 "$PARAM2"
done
このentrypoint.sh
スクリプトは、この設定ファイルに従って実行時に各ノートを実行し、結果のノート出力をS 3に格納します.AWS CodeBuildはリポジトリブランチからターゲット環境を決定し、コンテナをビルドし、AWS ECRにプッシュします.
JupyterノートブックのためのServerlessタスク実行
faethmの顧客は世界中の多くの異なる地域にまたがると、データは、各顧客のローカル管轄のデータ規則を対象としています.我々のデータサイエンスワークフローは、我々の顧客が格納される彼らのデータのために指定する地域で実行することができなければなりません.我々のアプローチによって、データは処理のために領域の間で転送する必要はありません.
我々は、アジア太平洋、米国とヨーロッパ全体で、世界中の顧客地域の増加した数の雲環境を操作します.faethmが拡大し続けるので、我々は新しい地域を支えることができる必要があります.
私たちのJupyterノートブックコンテナを実行するには、サポートされている各領域には、必要に応じてノートブックタスクを実行するように構成されたECS Fargateクラスタを持つVPCがあります.
それぞれのJupyterプロジェクトはECSタスク定義に関連付けられており、ECSタスク定義テンプレートはビルドパイプラインによって構成され、CloudFormationで展開されます.
イベント駆動Jupyterノートブックのタスク
タスク実行を単純化するために、各々のノート・リポジトリは一つのイベント・トリガーを有する.代表的に、ノートブック・タスクは、S 3のデータオブジェクト着陸に応答して実行される.例は、ユーザーポータルからアップロードされているCSVです.
プロジェクトリポジトリでは、YAML設定ファイルはS 3バケットとプレフィックスを捕捉し、EventBridgeに送られるCloudTrailログが一致するときにECSタスク定義をトリガーします.
...
S3TriggerBucket: notebook-trigger-bucket
S3TriggerKeyPrefix: path/to/data/
...
EventBridge規則テンプレートは、ビルドパイプラインによって構成され、CloudFormationを介して展開され、Jupyterノートブックの自動実行の基本要件を完了します.
すべてをまとめる
この記事では、マルチ領域環境におけるデータサイエンスワークフローのスケーリングと自動化への挑戦のいくつかを見ました.我々はまた、Jupyter生態系の中でそれらを扱う方法を見てきたし、どのように我々は様々なAWSの無制限の提供を活用するソリューションを実装している.
これらのすべてを一緒に置くと、その結果は、コードデータサイエンスのワークフロー実行パイプラインアーキテクチャとして、エンドツーエンドのServerless Git Osのコンテナ化されたイベント駆動Jupyterノートブックです.
私たちはそれを呼び出す
notebook-pipeline
.あなたは、faethm ai工学ブログからポストを読んでいました.また、私たちは雇用している!仕事の将来のために我々の情熱を共有して、パイオニアの世界データサイエンスとエンジニアリングプロジェクトをリードしたいならば、我々はあなたから連絡をもらいたいです.現在の開始位置を参照してください.https://faethm.ai/careers
Reference
この問題について(AWSと製紙工場で世界中のJupyterノートをスケーリング), 我々は、より多くの情報をここで見つけました https://dev.to/faethm/scaling-jupyter-notebooks-across-the-world-with-aws-and-papermill-41icテキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol