本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
Databricksノートブック
ノートブックは、複雑な環境設定なしにクイックにデータを操作し始める方法としては人気のあるものです。ノートブックの作成者は、コードと説明のテキスト組み合わせることで、インタラクティブな分析からコラボレーティブなワークフローにクイックに移行できます。多くの場合、探索としてスタートしたノートブックはプロダクションのアーティファクトに進化します。例えば、
- 新規のデータと進化するビジネスロジックに基づき定期的に実行されるレポート
- 定期的なスケジュールあるいは継続的に実行される必要があるETLパイプライン
- 新たなデータが到着した際に再トレーニングが必要な機械学習モデル
驚くかもしれませんが、多くのDatabricksのお客様は、少々の調整でノートブックをプロダクションの資産にパッケージングできることを知っており、コードレビュー、テスト、モジュール性、継続的インテグレーション、バージョン管理されたデプロイメントのようなベストプラクティスと組み合わせています。
書き直すか、プロダクション化するか？
探索的分析を完了した後、従来からある知恵に基づくと、伝統的なIDEを用いて別の構造化されたコードベースでノートブックのコードを書き直すことになります。最終的には、プロダクションのコードベースはCIシステム、ビルドツール、ユニットテストのインフラストラクチャに組み込まれることになります。これはデータがほぼ静的であり、以降も大きな変更がない場合にはベストなアプローチとなります。しかし、多くの一般的なケースにおいては、データの変更に応じてプロダクションの資産を頻繁に変更、デバッグ、拡張しなくてはなりません。多くの場合、これはノートブックの探索を伴うことになります。それならばいっそ、行ったり来たりをスキップできたらと思います。
書き換えるのと比べて、ノートブックを直接プロダクション化することにはいくつかのメリットがあります。特に、
- データとコードを一緒にテストできます。ユニットテストではビジネスロジックを検証しますが、データにおけるエラーはどうでしょうか？ノートブックで直接テストすることで、データフォーマットや分布に関する実行時チェックを含む、プロダクションを表現するデータを伴うビジネスロジックのチェックをシンプルにします。
- 何か問題が起きた際に、より密連携したデバッグループを提供します。昨夜ETLジョブが失敗しましたか？よくある原因としては、破損レコードのように予期していない入力データ、予期しないデータの偏り、データの欠如などがあります。プロダクションのジョブのデバッグには、多くの場合プロダクションのデータが必要となります。プロダクションのジョブがノートブックなのであれば、お手元のETLのジョブの一部あるいは全部を再実行でき、問題を引き起こしているプロダクションデータに対して直接インタラクティブな分析を行うことができます。
- あなたのビジネスロジックを高速に進化させます。ML問題に対して新たなアルゴリズムや統計的アプローチを試したいですか？探索とデプロイメントが別のコードベースに分離されている場合、いかなる小さな変更も一方でのプロトタイピングが必要で、もう一方でのプロダクション化が必要となり、ロジックが適切に複製されていることを保証するために注意が必要となります。MLジョブがノートブックであるなら、シンプルにアルゴリズムを調整し、トレーニングジョブの並列のコピーを実行し、同じノートブックをプロダクションに移行することができます。
「でも、ノートブックはテストやモジュール性、CIに適していないよ！」 とあなたは言うかもしれません。急がないでください！本書では、Databricksノートブックとそのようなソフトウェアエンジニアリングのベストプラクティスをどのように組み合わせるのかを説明します。どのようにバージョン管理、コードのモジュール化、ユニットテストとインテグレーションテストの適用、継続的インテグレーション/継続的デリバリー(CI/CD)の実装を行うのかを説明します。また、サンプルのリポジトリとウォークスルーを通じてデモを提供します。そこそこの工数で、書き直すことなしに探索用のノートブックをプロダクションのアーティファクトにし、データドリブンソフトウェアのデバッグとデプロイメントを加速します。
バージョン管理とコラボレーション
プロダクションエンジニアリングの基礎は、堅牢なバージョン管理とコードレビュープロセスを持つことです。時間経過と共に行われるコードへの変更の更新、リリース、ロールバックを行うために、Databricks Reposは人気のある多くのGitプロバイダーとのインテグレーションをシンプルにします。また、コミット、プル、マージのような典型的なGitオペレーションを実行するためのわかりやすいUIを提供します。既存のノートブック、(pythonユーティリティのような)その他のヘルパーコードを、ソース管理のために簡単にDatabricksのリポジトリに追加することができます。
Databricks Reposにおけるバージョン管理
バージョン管理と連携することで、Databricksワークスペース内で、Gitを通じた他の開発者とのコラボレーションができるようになります。プログラムからアクセスするために、Databricks Repos APIを用いることで皆様の自動化パイプラインとReposと連携できるようになり、決してUIでの利用のみに限定されません。
モジュール性
プロジェクトが初期のプロトタイプのステージを通過すると、より容易に共有、テスト、維持できるように、コードをモジュールにリファクタリングすることになります。任意のファイルのサポートと新たなファイルエディタによって、Databricks Reposはモジュール化され、テスト可能なコードを伴うノートブックを実現します。Pythonプロジェクトでは、.pyファイルで定義されたモジュールをDatabricksノートブックで直接インポートすることができます。
DatabricksノートブックでカスタムPythonモジュールをインポート
また、開発者は.pyファイルにおけるモジュールに対するいかなる変更も即座にDatabricksノートブックに反映されるように、%autoreloadマジックコマンドを使用することができ、Databricksにおいてさらに密な開発ループを実現することができます。Databricks ReposにおけるRスクリプトにおいては、source()関数を用いることで最新の変更をノートブックにロードすることができます。
また、別のPython、Rモジュールに分割されたコードはお好きなIDEを使ってオフラインで編集することができます。コードベースが大きくなると、このことは特に有用になります。
Databricks Reposは、ノートブック間のコードのコピーを含む不安定なプロセスではなく、共有されたモジュール、ライブラリの開発を通じたコラボレーションを支援します。
ユニットテスト、インテグレーションテスト
他の開発者とコラボレーションする際、コードに対する変更が期待通りに動作することをどのように保証しますか？これは、コード上で独立したそれぞれのロジックのユニットのテスト(ユニットテスト)と、依存関係のチェーンを伴うワークフロー全体のテスト(インテグレーションテスト)によって達成されます。テストスイートにおけるこの種のエラーは、別の開発者やプロダクションで実行されているジョブに影響を及ぼす前にコードの問題をキャッチするために活用されます。
Databricksを用いてノートブックのユニットテストを行うためには、Pythonファイルにテストを記述するpytestのような典型的なPythonテストフレームワークを活用します。以下に基本的なETLワークフローにおけるダミーデータセットを用いたユニットテストのシンプルな例を示します。
pytestのfixtureとassertionを伴うPythonファイル
Databricksノートブック(あるいはDatabricks webターミナル)からインタラクティブにこれらのテストを呼び出したり、エラーをチェックすることができます。
Databricksノートブックからのpytestの呼び出し
ノートブック全体をテストする際、プロダクションデータや他の資産に影響を与えたくはありません。言い換えると、ドライランを行いたいと考えます。このような挙動を制御するシンプルな方法は、特定のパラメーターが引き渡された際にのみプロダクションとして動作するようにノートブックを構成するというものです。Databricksでは、Databricksウィジェットを用いて、ノートブックのパラメーター化を行うことができます。
# get parameter
is_prod = dbutils.widgets.get("is_prod")
# only write table in production mode
if is_prod == "true":
df.write.mode("overwrite").saveAsTable("production_table")
プロダクションの資産にアクセスできないワークスペースでインテグレーションテストを実行しても同じ結果を得ることができます。どちらの方法でも、Databricksはユニットテストとインテグレーションテストの両方をサポートしており、ノートブックが進化し、変更の影響を手動でチェックすることが苦痛になったとしても、プロジェクトを成功に近づけます。
継続的インテグレーション / 継続的デプロイメント
早期かつ頻繁にエラーを捕捉するためのベストプラクティスは、自身のリポジトリのメインブランチに頻繁にコードをコミットすることです、ここでは、GitHub ActionsやAzure DevOps Pipelinesのような著名なCI/CDプラットフォームが、プルリクエストがマージされる前のこれらの変更に対するテストの実行を容易にします。この標準的なプラクティスをさらにサポートするために、Databricksでは新たな2つのGithub Actionsとして、Databricksノートブックの実行を起動するrun-notebookと、Python .whlファイルのようなビルドアーティファクトをクラスターにインストールできるようにDBFSに移動するためのupload-dbfs-tempをリリースしました。これらのアクションは、皆様の組織のCI/CD戦略に適合するために、フレキシブルなマルチステップのプロセスに組み込むことができます。
さらに、今ではDatabricksワークフローからGitのブランチ、タグ、コミットを参照できるようになっています。
メインブランチに対して実行するように設定されたジョブ
これによって、最新のプルリクエストに対してテストを実行できるので、継続的インテグレーションをシンプルなものにします。また、継続的デプロイメントもシンプルにします。Databricksに最新のコード変更をプッシュするための追加のステップを踏むのではなく、ジョブがバージョン管理システムの最新のリリースをプルするように設定することができます。
まとめ
この記事では、ソフトウェアエンジニアリングのベストプラクティスを適用することでDatabricksノートブックを昇華するコンセプトを紹介しました。Databricksレイクハウスにおけるバージョン管理、コードのモジュール化、テスト、CI/CDをカバーしました。これらのトピックの詳細に関しては、サンプルリポジトリや関連のウォークスルーをチェックしてください。
詳細はこちら
- Githubリポジトリ: https://github.com/databricks/notebook-best-practices/blob/main/README.md
- ドキュメント: https://qiita.com/taka_yayoi/items/740d94463bbf08c63dbb
- CI/CDのためのサービスプリンシパル: https://docs.databricks.com/dev-tools/ci-cd/ci-cd-sp.html