bowang0911/databricks-qa-ja huggingface dataset:
MLOpsのモデルデプロイというアプローチ欠点：
開発環境からプロダクションデータにアクセスできない場合(セキュリティ上の理由からあり得ることです)、このアーキテクチャは実現できません。
このパターンではモデルの再トレーニングの自動化はトリッキーです。開発環境で再トレーニングを自動化することはできますが、プロダクションにモデルをデプロイする責任を持つチームは、結果得られるモデルをプロダクションレディとして受け入れられないかもしれません。
特徴量生成、推論、モニタリングで使用するパイプラインのようなコードは、別にプロダクションにデプロイする必要があります。
Databricks機械学習ランタイム11.3以降では、分類、回帰問題における入力データセットを拡張するために、Feature Storeの既存の特徴量テーブルを使用することができます。

既存の特徴量テーブルを使うには、AutoMLのUIで特徴量テーブルを選択するか、AutoMLランの設定でfeature_store_lookupsを設定します。
モデルの評価はMLライフサイクルの重要なパートです。これによって、データサイエンティストは自身のモデルのパフォーマンスの計測、解釈、説明が可能となります。モデルがなぜそのように動作しているのかに関して洞察を提供することで、モデル開発のタイムフレームを加速します。特にMLモデルの複雑性が増加するにつれて、MLモデルのパフォーマンスを迅速に観測、理解できる能力は、ML開発ジャーニーを成功させるためには重要となってきます。
ユーザーは分類モデルと回帰モデルの両方の評価をサポートするmlflow.evaluate APIを通じてpython_function (pyfunc)モデルフレーバーのMLflowモデルのパフォーマンスを評価することができます。これは、ビルトインのタスク固有のパフォーマンスメトリクス、パフォーマンスのプロット、モデルの説明を計算してMLflowトラッキングサーバーに記録します。
カスタムメトリクスでモデルを評価するには、シンプルにカスタムメトリックの関数のリストをmlflow.evaluate APIに渡します。カスタムメトリックの関数は、以下の順序で2つの必須のパラメーター、1つのオプションのパラメーターを受け取る必要があります:

eval_df: predictionとtargetカラムを持つPandasあるいはSparkデータフレーム。

例：モデルの出力が3つの値のベクトルである場合、データフレームeval_dfは以下の様になります。

builtin_metrics: ビルトインメトリクスを含むディクショナリー。

例：回帰モデルにおいては、builtin_metricsは以下の様になります。

(オプション)artifacts_dir: カスタムメトリック関数が生成されたアーティファクトをMLflowに記録する前に一時的に保存するために使用する一時ディレクトリのパス。

例：環境に応じて見え方が異なることに注意してください。
MLflowでは、分類、回帰モデルの両方に対して一般的に使われるパフォーマンスやモデル説明可能性に関するメトリクスのセットを同梱していまうs。これらのメトリクスによるモデルの評価はわかりやすいものです。必要なのは、テストデータとターゲットを含む評価データセットを作成し、mlflow.evaluateを呼び出すことです。

モデルのタイプによって、異なるメトリクスが計算されます。ビルトインメトリクスに関する最新の情報については、mlflow.evaluateのAPIドキュメントのDefault Evaluator behavior sectionをご覧下さい。
Fivetranはレイクハウスへの自動データ取り込みことに活用できます。SalesforceやMySQLからのデータ取り込みにFivetranを使い、高信頼、メンテナンス可能、テスト可能なデータパイプラインを構築するための宣言型ETLフレームワークであるDelta Live Tables(DLT)を用いてデータを変換します。
Fivetranのマネージドコネクターによって、ユーザーは200以上のソースからDatabricksレイクハウスプラットフォームへのデータ取り込みを完全に自動化できます。

コネクターを設定、テストするためのユーザーフレンドリーなUI。
スキーマドリフト対応を含む自動スキーマ管理。
API障害、レートリミットなどへの対応。
完全、インクリメンタルなロード。
テーブルのクローンにディープクローンとシャロークローンの二種類があります。
ディープクローンは、既存テーブルのメタデータに加えて、ソーステーブルのデータをクローンのターゲットにコピーします。さらに、ソーステーブルに対してDeltaテーブルに書き込みを行うストリームを停止し、クローンのターゲットでコピーした地点から再開できる様に、ストリームのメタデータもクローンされます。
シャロークローンは、クローンターゲットにデータファイルをコピーしないクローンです。テーブルメタデータはソースと同じものになります。これらのクローンは低コストで作成できます。
ディープクローン、シャロークローンに対するすべての変更はクローン自身に反映され、ソーステーブルには影響を与えません。
ディープクローンは、既存テーブルのメタデータに加えて、ソーステーブルのデータをクローンのターゲットにコピーします。さらに、ソーステーブルに対してDeltaテーブルに書き込みを行うストリームを停止し、クローンのターゲットでコピーした地点から再開できる様に、ストリームのメタデータもクローンされます。
シャロークローンは、テーブルメタデータをクローンします。クローンされるメタデータには、スキーマ、パーティション情報、不変性、NULL可能性が含まれます。クローンターゲットにデータファイルをコピーしないので、シャロークローンはソースディレクトリのデータファイルを参照します。テーブルメタデータはソースと同じものになります。これらのクローンは低コストで作成できます。
クローンされるメタデータには、スキーマ、パーティション情報、不変性、NULL可能性が含まれます。ディープクローンにおいてのみ、ストリームとCOPY INTOのメタデータもクローンされます。クローンされないメタデータは、テーブルの説明文とユーザー定義のコミットメタデータです。
構造化ストリーミングは、ストリーミングクエリーにおける耐障害性とデータの一貫性を提供します。Databricksワークフローを用いることで、構造化ストリーミングの障害時に再起動する様に容易に設定することができます。ストリーミングクエリーのチェックポイント作成を有効化することで、障害の後にクエリーを再起動することができます。再起動されたクエリーは障害時点から処理を継続します。
クラウドオブジェクトストアは、他のクラウドデータベースやオンプレミスの代替案よりも、通常は安価に様々な種類のデータを格納できるので、レイクハウスアーキテクチャにおけるキーコンポーネントとなっています。AWS DatabricksのAmazon Simple Storage (S3)、Azure DatabricksのAzure Data Lake Storage、Databricks on Google CloudのGoogle Cloud Storage (GCS)はクラウドオブジェクトストアです。
特徴量ストアが解決する課題は、複数人のデータサイエンティストが同じデータを基点として機械学習を行う際に、それぞれが別個に特徴量エンジニアリングを行なって、各自で特徴量のデータ(テーブルやデータフレーム)を作ってしまい、特徴量の用途は同じながらも微妙にロジックや結果が異なり、しかも、作りっぱなしで再利用されないということです。

さらに、モデルをトレーニングする際にモデルに入力する特徴量と、推論の際にモデルに入力する特徴量は同じロジックで計算されるべきですが、各自でロジックを作っていると、トレーニングで用いる特徴量と、推論で用いられる特徴量が異なるロジックで計算されてしまうということが起こってしまいます。これによって、期待した精度が出ないということも起こり得ます。これを「オフライン(トレーニング)とオンライン(推論)の偏り」と呼びます。
Databricksが提供する特徴量ストアであるDatabricks Feature Storeは、他のDatabricksのコンポーネントと完全にインテグレーションされています。

発見可能性。DatabricksワークスペースからアクセスできるFeature Store UIを用いることで、既存の特徴量をブラウズ、検索することができます。
リネージュ。Feature Storeを用いて特徴量テーブルを作成すると、特徴量テーブルを作成するために使用されたデータソースが保存され、アクセス可能になります。特徴量テーブルのそれぞれの特徴量に対して、特徴量を使用しているモデル、ノートブック、ジョブ、エンドポイントにもアクセスすることができます。
モデルスコアリング、モデルサービングとのインテグレーション。モデルをトレーニングするためにFeature Storeからの特徴量を使う際、モデルは特徴量メタデータと一緒にモデルがパッケージングされます。バッチスコアリングやオンライン推論にモデルを使う際、Feature Storeから自動で特徴量を取得します。呼び出し元は、これらに関して知る必要や、新規データをスコアリングするために特徴量を検索、joinするロジックを含める必要はありません。これによって、モデルのデプロイメントと更新をより簡単なものにします。
ポイントインタイムの検索。Feature Storeでは、ポイントインタイムの正確性を必要とする時系列、イベントベースのユースケースをサポートしています。
トレーニングデータセットは以下から構成されます:

生の入力データ
特徴量ストアの特徴量
生の入力データは以下を含んでいるので必要になります:

特徴量とjoinするために使用される主キー。
特徴量ストアにないtrip_distanceのような生の特徴量。
モデルトレーニングに必要なfareのような予測ターゲット。
必要な特徴量それぞれにFeatureLookupを作成することで、モデルをトレーニングするための特徴量をFeature Storeからロードします。
オフラインの特徴量ストアは特徴量の検索、モデルのトレーニング、バッチ推論に使用されます。これにはDeltaテーブルの特徴量テーブルが含まれます。
オンライン特徴量ストアは、リアルタイム推論に用いられる低レーテンシーのデータベースです。Databricks Feature Storeがサポートしているオンラインストアについては、Work with online storesをご覧ください。
はい、バッチ書き込みに加えて、Databricks Feature Storeはストリーミングをサポートします。ストリーミングのソースから特徴量を特徴量テーブルに書き込むことができ、特徴量の計算には生データのストリーミングを特徴量に変換するために構造化ストリーミングを活用できます。

オフラインストアの特徴量テーブルからオンラインストアにストリーミングすることも可能です。
Databricks Feature Storeの特徴量を用いてトレーニングした機械学習モデルは、特徴量との紐付けを維持します。推論を行う際にモデルが特徴量ストアから特徴量を取得することも可能です。モデルの呼び出し下は、モデルに使われた特徴量の主キー(例えば、user_id)を指定するだけで、モデルが特徴量ストアから必要な特徴量を取得します。

バッチ推論においては、オフラインストアから特徴量が取得され、スコアリングの前にデータと結合されます。リアルタイム推論においては、特徴量はオンラインストアから取得されます。
トレーニングセットのカラム名のFeatureLookupで引数lookup_keyを使います。FeatureStoreClient.create_training_setは、特徴量テーブルが作成された際に指定された主キーの順序を用いて、lookup_key引数で指定されたトレーニングセットのカラム間の順序ありjoinを行います。
実行環境は、モデルやデータが作成され、コードによって活用される場所となります。それぞれの実行環境は、計算インスタンス、ランタイム、ライブラリ、自動化されたジョブから構成されます。

MLコードとモデル開発に対して、ステージ間の移行が明確に定義された別々のステージを設けることをお勧めします。例えば、ステージに対する一般的な名称を用いてこのプロセスに従います。

開発
ステージング
プロダクション
Gitバージョンコントロールを使いましょう。 パイプラインやコードバージョン管理のためにGitに格納されるべきです。MLロジックのステージ間の移行を、コードの開発ブランチから、ステージングブランチ、リリースブランチへの移動と解釈することができます。お使いのGitプロバイダーをインテグレーションし、Databricksワークスペースでノートブックやソースコードを同期するために、Databricks Reposをお使いください。また、DatabricksではGit連携、バージョン管理のためにその他のツールも提供しています。Developer tools and guidanceをご覧下さい。
Deltaテーブルを用いたレイクハウスアーキテクチャにデータを格納しましょう。 お使いのクラウドアカウント内のレイクハウスアーキテクチャにデータを格納すべきです。生のデータと特徴量テーブルの両方が、誰が読み込みでき、誰が編集できるのかを決定するためのアクセスコントロールがなされたDeltaテーブルに格納されるべきです。
CIプロセスは主にユニットテストとインテグレーションテスト(CI)を実行します。
ユニットテスト
CIプロセスは自動でソースコードをビルドし、ユニットテストを起動します。テストが失敗するとマージリクエストは却下されます。ユニットテストはデータや他のサービスとはやり取りしません。

3. インテグレーションテスト(CI)
そして、CIプロセスはインテグレーションテストを実行します。インテグレーションテストは全体的に機能が適切に動作することを確実にするために、(特徴量生成、モデルトレーニング、推論、モニタリングを含む)すべてのパイプラインを実行します。ステージング環境は、合理性があるといえるくらいプロダクション環境と類似したものである必要があります。
CDプロセスが、新たなモデル(モデルレジストリ上ではstage=None)を取り込んでテストし、テストに成功したらデプロイ(stage=Productionにプロモート)します。CDはモデルレジストリのwebhookあるいはお使いのCDシステムで実装することができます。

このパイプラインには3つのタスクがあります:

コンプライアンスチェック。 これらのテストは、モデルレジストリからモデルをロードし、あなたの組織が必要とするコンプライアンスチェック(タグやドキュメントなど)を行い、テスト結果に基づいてリクエストを承認あるいは却下します。コンプライアンスに人間の専門性が必要である場合、この自動化ステップは手動によるレビューのために統計情報やビジュアライゼーションを生成します。結果の如何を問わず、タグのメタデータや説明文のコメントを用いて、モデルバージョンの結果をモデルレジストリに記録します。

手動でステージ移行や移行リクエストを管理するためにMLflowのUIを使うことができます。あるいは、自動化するためにMLflow APIやwebhookを使うことができます。モデルがコンプライアンスチェックを通過したら、移行リクエストは承認され、モデルはstage=Stagingにプロモートされます。モデルが失敗すると、移行リクエストは却下されモデルはモデルレジストリでstage=Archivedに移行されます。

ステージングとプロダクションの比較。 パフォーマンスの劣化を防ぐために、現行のプロダクションバージョンとステージングにプロモートされたモデルのパフォーマンスを比較すべきです。比較のメトリクスや方法はユースケースに依存し、カナリアデプロイメントやA/Bテストや他の手法を含めることもできます。テストの比較結果はレイクハウスのメトリクステーブルに保存されるべきです。

これが最初のデプロイメントであり、まだプロダクションバージョンがない場合には、ステージングバージョンをベースラインとしてのビジネス経験則や他の閾値と比較することができます。

モデルのプロダクションへの移行のリクエスト。 候補モデルが比較テストを通過したら、モデルレジストリでstage=Productionへの移行をリクエストすることができます。MLflowを用いて手動、あるいはMLflow APIやwebhookを用いて自動でこれを行うことができます。また、この時点で人間による承認を行うことは良いアイデアです。これが、モデルがプロダクションにリリースされ、既存のビジネスプロセスに組み込まれる前の最後のステップです。コンプライアンスチェック、パフォーマンスの比較、自動化が難しいその他のチェックを検証するための人間によるレビューを含めることもできます。
最新データを用いてモデルの再トレーニングを行うスケジュールジョブを作成するか、データやモデルにドリフトを検知した際に再トレーニングを起動するためのモニターをセットアップすることができます。モデルモニタリングメトリクスがパフォーマンスの問題を示した際には、データサイエンティストは開発環境に戻って新たなモデルバージョンを開発する必要があるかもしれません。
Databricksマーケットプレイスで欲しいデータ製品を探すには、シンプルに提供者のリスティングをブラウズ、検索し、欲しいデータ製品へのアクセスをリクエストします。いくつかのデータ製品はリクエストを行い、利用条件に同意すればすぐに利用できます。他のものにおいては、提供者の承認と提供者のインタフェースを用いたトランザクションの完了が必要となることがあります。いずれの場合でも、マーケットプレイスを支援するDelta Sharingプロトコルはセキュアに共有データにアクセスできることを保証します。
Databricksマーケットプレイスは、データ提供者に対してデータサイエンティストやアナリストが自分達の組織の成功のために活用できるデータ製品を共有するためのセキュアなプラットフォームを提供します。Databricksマーケットプレイスでは、共有データに対するセキュリティとコントロールを提供するためにDelta Sharingを活用しています。公開データ、無料のサンプルデータ、有償のデータオファリングを共有することができます。データセットに加えて、ユースケースやお客様がデータ製品の利点を完全に活用できるようにする方法を示すために、Databricksノートブックやその他のコンテンツを共有することもできます。
CREATE TABLE LIKEを使ってDeltaテーブルからDeltaテーブルを作成する際には、以下がコピーされます。

コメント
カラム
パーティションカラム
設定
テーブル制約
Deltaプロトコル
。テーブル定義やメタデータのみがコピーされるので、テーブル自体は空です。
近年のいかなる量の顧客データの管理においては間違いなくPIIの保護が求められます。これは、シンプルな設定ミスによって数百万の機微な顧客レコードが盗まれることになったCapital Oneのデータ漏洩のようにいかなる規模の企業にとって大きなリスクです。ストレージデバイスの暗号化やテーブルレベルのカラムマスキングは効果的なセキュリティ対策ですが、この機微なデータに対する内部の許可されないアクセスは、依然として大きな脅威となります。このため、Databricksにおいて通常のユーザーがテーブルやファイルから機微情報を取得することを制限するソリューションを必要としました。

しかし、機微情報を読み込むビジネスニーズを持つ人たちが読み込めるようにする必要もありました。我々は、それぞれのユーザーのテーブルの読み込み方法に違いを生じさせたくはありませんでした。データ分析やレポート作成におけるクエリーの作成をシンプルにするために、通常の読み込みと復号化された読み込みの両方は、同じDelta Lakeオブジェクトに対して行われる必要がありました。
Fernetは、いくつかの標準的な暗号化プリミティブを用いて構築されている対称性の暗号化を使用します。このライブラリは、データフレームの任意のカラムを暗号化できるようにする暗号化UDFで使用されます。暗号化キーを格納するために、我々のデータ取り込みプロセスのみがアクセスできるようにする設定がなされたDatabricksシークレットを使用します。データがDelta Lakeテーブルに格納されると、社会セキュリティ番号、電話番号、クレジットカード番号、その他のIDのような値を保持するPIIカラムは許可されないユーザーによる読み込みができなくなります。
最初に行う必要があるのは、Databricksで稼働しているHiveインスタンスに追加するUDFを作成することです。このUDFは復号化を実行するために、暗号化書き込みに用いられたのと同じシークレットにアクセスし、このケースでは、クラスターのSpark設定に追加されます。これによって、権限のあるユーザー、権限のないユーザーにこのキーに対するアクセスをコントロールための、クラスターのアクセスコントロールが必要となります。UDFが作成されると、権限のあるユーザーが復号化されたデータを参照するために、ビュー定義でUDFを使えるようになります。
単一のデータセットに対して2つのビューオブジェクトを作成しており、それぞれが権限のあるユーザー、権限のないユーザー向けのものとなっています。権限のないユーザー向けのビューにはUDFがないので、暗号化された値としてPIIの値を参照します。権限のあるユーザー向けのもう一方のビューにはUDFがあるので、彼らは自身のビジネスニーズのために復号化された値を参照することができます。
Databricks Sparkコネクターを用いることで、別のDatabricksワークうsペースに設定されている計算リソースに接続し、現在のDatabricksワークスペースに結果を返却することができます。クエリーが成功するには、両方のワークスペースでアクティブな計算資源にアクセスできる必要があります。
Databricksレイクハウスプラットフォームは、エンタープライズレベルの大規模データソリューションの構築、デプロイ、共有、維持のための統合されたツールセットを提供します。Databricksは、お使いのクラウドアカウントのクラウドストレージとセキュリティと連携し、あなたに代わってクラウドインフラストラクチャの管理、デプロイを行います。
Databricksプラットフォームのアーキテクチャは2つの主要なパーツから構成されています: Databricksがプラットフォームとサービスをデプロイ、設定、管理するために使うインフラストラクチャと、Databricksとお客さまとで共同管理するお客さま所有のインフラストラクチャです。

数多くのエンタープライズデータベース企業と異なり、Databricksではプラットフォームを使うためにデータをプロプライエタリなストレージシステム移行することを強制しません。そうではなく、Databricksプラットフォームとお使いのクラウドアカウントの間でセキュアなインテグレーションを設定することでDatabricksワークスペースを構築すると、Databricksはオブジェクトストレージやあなたがコントロールしている連携済みサービスのデータを処理、格納するために、あなたのアカウントのクラウドリソースを用いて、一時的な計算クラスターをデプロイします。
Unity Catalogはこのリレーションシップをさらに拡張し、Databricks内から馴染み深いSQL構文を用いて、データアクセス権限を管理できるようになります。

Databricksは、世界最大かつ最もセキュリティ意識の高いいくつかの企業のセキュリティとネットワーク要件に応えるワークスペースをデプロイしてきています。Databricksは新規ユーザーが使い始めやすいものとなっており、エンドユーザーがクラウドインフラストラクチャを操作する際の負荷や懸念点を排除しますが、経験豊富なデータ、オペレーション、セキュリティチームが必要とするカスタマイズやコントロールを制限しません。
BIから機械学習に至るソリューションを用いて、自分のデータセットを処理、格納、クレンジング、共有、分析、モデリング、マネタイズするためにDatabricksを活用しています。様々なデータペルソナによる数多くのアプリケーションを構築するためにDatabricksプラットフォームを活用することができます。レイクハウスを完全に導入しているお客様は、企業におけるイノベーションと洞察を強化するデータエンジアリングのワークフロー、機械学習モデル、分析ダッシュボードの開発、デプロイに我々の統合プラットフォームを活用しています。
Databricksワークスペースは、以下の様なツールを含む、コアとなる多数のデータタスクのためのユーザーインタフェースを提供しています。

インタラクティブなノートブック
ワークフロースケジューラーとマネージャ
SQLエディタとダッシュボード
データ取り込みとガバナンス
データ検索、注釈、探索
計算資源管理
機械学習(ML)エクスペリメントのトラッキング
MLモデルのサービング
特徴量ストア
Gitによるソースコントロール
Databricksは、比類なきETL(抽出、変換、ロード)体験を提供するために、Apache SparkとDelta Lakeとカスタムツールのパワーを組み合わせます。ETLロジックを組み立てるためにSQL、Python、Scalaを活用することができ、数クリックでスケジューリングされたジョブのデプロイメントをオーケストレーションすることができます。
Delta Live Tablesは、インテリジェントにデータセット間の依存関係を管理し、あなたの仕様に応じてデータをタイムリーかつ正確にデリバリーできる様に、プロダクションのインフラストラクチャをデプロイ、スケールさせることでさらにETLをシンプルなものにします。

Databricksでは、クラウドオブジェクトストレージやデータレイクからデータレイクハウスにインクリメンタルかつ冪等性をもってデータをロードするための効率的かつスケーラブルなツールであるオートローダーを含む数多くのカスタムツールとのデータ取り込み手段を提供しています。
ディメンションモデルを実装する際に推奨されるベストプラクティスをいくつかを示します。

ディメンションテーブルを非正規化すべきです。モデルの第三正規形あるいはスノーフレーク型ではなく、通常ディメンションテーブルは単一のディメンションテーブルの中で多対1リレーションシップによってflattenすることで、高度に非正規化されます。

異なるディメンションテーブルの属性が同じカラム名やドメインコンテンツを持つ際には、準拠したディメンションを使用してください。この利点は、異なるファクトテーブルからのデータを、それぞれのファクトテーブルと関連づけられた準拠ディメンション属性を用いて、単一のレポートで結合することができるということです。

ディメンションテーブルにおける通常のトレンドは、as-isあるいはas-wasレポートをサポートするために、ディメンションの経年変化を追跡します。異なる要件に基づいてディメンションをハンドリングするために以下の基本的なテクニックを容易に適用することができます。

タイプ1のテクニックでは、ディメンション属性の初期値を上書きします。
最も人気のあるSCDテクニックであるタイプ2のテクニックでは、時間経過と共に追跡される正確な変更点を使用します。
これらは、Delta Live Tables(DLT)実装を用いることで容易に達成することができます。

APPLY CHANGES INTOを用いたDelta Live Tablesによって、容易にSCDタイプ1やSCDタイプ2を実行することができます。
主キーと外部キー制約によって、ユーザーはテーブル間のリレーションシップを理解することができます。

アイデンティティカラムを用いることで、新規行が追加された際にユニークな整数値が自動で生成されます。アイデンティティカラムはサロゲートキーの一形態です。詳細はこちらのブログ記事をご覧ください。

CHECK制約の強制によって、あなたに這い寄るデータ品質や正確性の問題に心配する必要が無くなります。
Feature Storeを用いた典型的な機械学習ワークフローは以下のパスを踏みます。

生のデータを特徴量に変換するコードを記述し、必要な特徴量を格納するSparkデータフレームを作成します。
Feature Storeで特徴量テーブルとしてデータフレームを書き込みます。
特徴量ストアからの特徴量を用いてモデルをトレーニングします。これを行う際、モデルはトレーニングで使われた特徴量の仕様を格納します。モデルを推論に使う際、自動で適切な特徴量テーブルから特徴量を結合します。
モデルをモデルレジストリに登録します。
これで、新規データに対する予測を行う際にモデルを使うことができる様になります。
リアルタイムサービングのユースケースでは、特徴量をオンラインストアに公開します。

推論時には、モデルはオンラインの特徴量ストアから事前計算済みの特徴量を読み込み、モデルサービングエンドポイントにクライアントからリクエストされたデータと結合します。
バンドルしてサブミットできるコードの単一のユニットです。Databricksジョブは単一のSparkContextのSparkアプリケーションと同じものとなります。エントリーポイントはライブラリ(JAR、egg、wheelなど)やノートブックとなります。洗練されたリトライ、アラート機構を用いてDatabricksジョブをスケジュール実行することができます。ジョブ実行の主要なインタフェースはJobs APIとUIとなります。
Databricksによって管理されるあなたのアカウント上のインスタンスのセットですが、アイドル状態の際にはDatabricksの課金は発生しません。プールで複数のジョブをサブミットすることで、ジョブがクイックに起動します。プールのインスタンスにガードレール(インスタンスタイプ、インスタンス制限など)とオートスケーリングのポリシーを設定することができます。プールは、他のSparkプラットフォームにおけるオートスケーリングクラスターと同じものです。
Jobs APIあるいはUIを用いてプールでジョブを実行することができます。それぞれのジョブに対してクラスターのスペックを指定する必要があります。ジョブが起動しようとすると、Databricksは自動でプールから新規クラスターを作成します。ジョブが完了するとクラスターは自動で停止します。ジョブが実行された時間分だけ課金されることになります。
Jobs APIあるいはUIを用いてプールでジョブを実行することができます。それぞれのジョブに対してクラスターのスペックを指定する必要があります。ジョブが起動しようとすると、Databricksは自動でプールから新規クラスターを作成します。ジョブが完了するとクラスターは自動で停止します。ジョブが実行された時間分だけ課金されることになります。これは、Databricksでジョブを実行する際のコスト効率が最も高い方法となります。
DatabricksでジョブをサブミットするためにAirflowを使いたい場合、DatabricksではAirflow operatorを提供しています。DatabricksのAirflowオペレーターは、DatabricksにジョブをサブミットするためにJobs APIのTrigger a new job runオペレーション(POST /jobs/run-now)をコールします。Orchestrate Databricks jobs with Apache Airflowをご覧ください。
サーバレスリアルタイム推論は、お使いのMLflow機械学習モデルをスケーラブルなREST APIエンドポイントとして公開します。この機能ではサーバレスコンピュートを使用しており、このエンドポイントと関連する計算リソースはDatabricksクラウドアカウントで管理、実行されることを意味します。生じる利用料とストレージコストは無料ですが、課金を開始する際にはDatabricksから連絡を行います。
クラシックのMLflowモデルサービングでは、現在ではクラシックデータプレーンと呼ばれるお客様自身のアカウントの元で稼働するシングルノードクラスターを使用します。データプレーンには仮想ネットワークと、ノートブックやジョブで使用するクラスター、proおよびクラシックSQLウェアハウス、クラシックモデルサービングエンドポイントの様な関連づけられた計算資源が含まれます。
サーバレスリアルタイム推論は以下を提供します。

1クリックでエンドポイントを起動できます: Databricksがあなたのモデルのためにプロダクションレディの環境を準備し、計算処理のためのサーバレス設定オプションを提供します。
高可用性とスケーラビリティ: サーバレスリアルタイム推論は、プロダクション用途を意図しており、秒間3000クエリー(QPS)までをサポートすることができます。サーバレスリアルタイム推論エンドポイントは、自動でスケールアップ・ダウンするので、エンドポイントはスコアリングのリクエストのボリュームに応じて自動で調整することを意味します。
ダッシュボード: QPS、レーテンシー、エラー率のようなメトリクスを用いて、モデルエンドポイントの健康状態をモニターするために、ビルトインのサーバレス推論ダッシュボードを活用します。
特徴量ストアのインテグレーション: お使いのモデルが、Databricks Feature Storeの特徴量を用いてトレーニングした場合、モデルは特徴量のメタデータとともにパッケージされます。オンラインストアを設定した際、スコアリングのリクエストを受け取ると、これらの特徴量がリアルタイムで組み込まれます。
はい、特徴量ストアとののインテグレーションをサポートしています。お使いのモデルが、Databricks Feature Storeの特徴量を用いてトレーニングした場合、モデルは特徴量のメタデータとともにパッケージされます。オンラインストアを設定した際、スコアリングのリクエストを受け取ると、これらの特徴量がリアルタイムで組み込まれます。
Databricksノートブックにおけるpdbの使い方を説明します。

最後の例外からデバッグするには%debugを使います。これは、予期しないエラーに遭遇し、原因をデバッグする際に役立ちます(pdb.pm()と似ています)。
例外後(しかし、プログラム終了前)にインタラクティブなデバッガーを自動で起動するには%pdb onを使います。これらのコマンドを使う際には、他のセルを実行する前にデバッガーの使用を停止する必要があることに注意してください。
Databricksノートブックで%debugを使うには:

例外が起きるまでノートブックのコマンドを実行します。
新規セルで %debug を実行します。セルの出力エリアでデバッガーが動作を始めます。
変数を調査するには、入力フィールドに変数名を入力し Enter を押します。
以下のコマンドを用いることで、変数の調査の様に、コンテキストを切り替えたり他のデバッガータスクを行うことができます。デバッガーの完全なコマンドの一覧に関しては、pdb documentationをご覧ください。文字列を入力し、 Enter を押します。
n: 次の行
u: 現在のスタックフレームを抜けて1レベル上に移動
d: 現在のスタックフレームを抜けて1レベル下に移動
このノートブックの最初のセルで説明した方法のいずれかでデバッガーを抜けます。
Databricksノートブックで%pdb onを使うには:

ノートブックの最初のセルで%pdb onを実行して自動pdbをオンにします。
例外が起きるまでノートブックでコマンドを実行します。インタラクティブなデバッガーが起動します。
変数を調査するには、入力フィールドに変数名を入力し Enter を押します。
以下のコマンドを用いることで、変数の調査の様に、コンテキストを切り替えたり他のデバッガータスクを行うことができます。デバッガーの完全なコマンドの一覧に関しては、pdb documentationをご覧ください。文字列を入力し、 Enter を押します。
n: 次の行
u: 現在のスタックフレームを抜けて1レベル上に移動
d: 現在のスタックフレームを抜けて1レベル下に移動
このノートブックの最初のセルで説明した方法のいずれかでデバッガーを抜けます。
Databricksは、シングルマシンと分散Pythonワークロードの両方で実行することができます。シングルマシンの処理においては、通常通りPython APIとライブラリを使用することができます。例えば、pandasやscikit-learnは「普通に動作します」。分散Pythonワークロードに関しては、Databricksはすぐに利用できる2つの人気のあるAPIを提供します。Pandas API on SparkとPySparkです。
ノートブックはJupyterと同じ様な機能を提供しますが、ビッグデータを用いたビルトインのビジュアライゼーション、デバッグやパフォーマンス監視のためのApache Sparkインテグレーション、機械学習エクスペリメントのトラッキングのためのMLflowインテグレーションのような機能が追加されています。
Databricks Reposを用いることで、ユーザーはノートブックや他のファイルをGitリポジトリと同期できる様になります。Databricks Reposはコードのバージョン管理やコラボレーションの役に立ち、コードのすべてのリポジトリのDatabricksへのインポート、過去のノートブックのバージョンの参照、IDE開発とのインテグレーションをシンプルにします。
PyPIや他のリポジトリにあるライブラリを用いてノートブックやジョブの環境を変更することができる、ノートブックスコープPythonライブラリを用いて環境をカスタマイズします。%pip install my_libraryマジックコマンドは、あなたが現在アタッチしているクラスターのすべてのノードにmy_libraryをインストールしますが、共有クラスターの他のワークロードには干渉しません。
はい、DatabricksのPythonノートブックには様々なタイプのビジュアライゼーションのビルトインサポートがあります。また、レガシーなビジュアライゼーションを使うこともできます。
また、サードバーティライブラリを使ってデータを可視化することができます。いくつかはDatabricksランタイムに事前インストールされていますが、カスタムライブラリをインストールすることもできます。有名な選択肢には以下の様なものがあります。

Bokeh
matplotlib
Plotly
Databricksで利用するMLアルゴリズムに関しては、scikit-learn、TensorFlow、Keras、PyTorch、Apache Spark MLlib、XGBoostのような人気のあるPythonツールを含むDatabricks機械学習ランタイムに事前インストールされているライブラリを使うことができます。カスタムライブラリをインストールすることもできます。
MLflowトラッキングを用いることで、モデルの開発を記録し、再利用なフォーマットでモデルを保存することができます。MLflowモデルレジストリを用いることで、モデルのプロダクションへのプロモートを管理、自動化することができます。そして、ジョブとサーバレスリアルタイム推論によるモデルサービングや、クラシックMLflowモデルサービングを用いることで、バッチやストリーミングジョブ、RESTエンドポイントとしてモデルをホストすることができます。
外部の開発環境とDatabrikcsの間で成果物を同期するにはいくつかの選択肢があります。

コード: Gitを用いてコードを同期することができます。Databricks ReposによるGit連携をご覧ください。
ライブラリとジョブ: 外部で(wheelsのような)ライブラリを作成し、Databricksにアップロードすることができます。これらのライブラリは、Databricksノートブックでインポートすることができ、ジョブ作成に使用することもできます。Databricksにおけるライブラリ管理やDatabricksにおけるジョブ管理をご覧ください。
リモードマシンでの実行: インタラクティブな開発やテストのためにローカルのIDEからコードを実行することができます。IDEはDatabricksクラスターで大規模な計算処理を実行するために、Databricksとコミュニケーションすることができます。この接続を生成するためにどの様にDatabricks Connectを使うのかを学ぶには、Use IDEs with Databricksをご覧ください。
はい、Databricksでは、自動化と外部のツールとの連携をサポートするREST APIの完全なセットを提供しています。クラスター、ライブラリ、コードや他のワークスペースオブジェクト、ワークロードやジョブの様なリソースを管理するためにAPIを活用することができます。
方法は二人あります。Databricks SQL Connector for Pythonを用いることで、Databricksリソース上でSQLコマンドを実行するためにPythonコードを使用することができます。
pyodbcを用いることで、ローカルのPythonコードからODBCを通じて、Databricksレイクハウスに格納されているデータに接続することができます。
シングルノードでの動作を前提としたライブラリを使用しており、Databricksに移行しても、これらは分散処理されません。Apache SparkのPython APIであるPySparkを使ってご自身のコードを書き直す必要があります。

あるいは、Apache Sparkデータフレームのデータにアクセスするために、pandasデータフレームAPIを使用できるPandas API on Sparkを活用することができます。
ベストなデプロイメントの選択肢はアプリケーションのレーテンシーの要件に依存します。

バッチ予測に関しては、推論、予測のためにモデルをデプロイするを参照ください。
ストリーミングアプリケーションに関しては、構造化ストリーミングを参照ください。
低レーテンシーのモデル推論に関しては、MLflowモデルサービング、あるいはAmazon SageMakerのようなクラウドプロバイダーのソリューションの活用を検討ください。
ライブラリをインストール、アップデートする方法はいくつか存在します。

クラスターを利用する全てのユーザーが使用するライブラリをインストール、アップデートするにはクラスターライブラリを使います。
特定のノートブックでのみPythonライブラリやライブラリのバージョンを使えるようにするには、ノートブックスコープライブラリを使います。
いくつの方法があります。マウントします。DBFSへのオブジェクトストレージのマウントをご覧ください。

データタブを使います。データのインポート、読み込み、変更をご覧下さい。

%sh wgetを使います。

データファイルのURLを参照できるのであれば、Sparkドライバーノードにデータをインポートするために%sh wget <url>/<filename>を使用することができます。
「split-apply-combine」パターンを実装するために'groupBy().applyInPandas()'を通じて、グループ分けされたデータの変換を行います。split-apply-combineは3つのステップから構成されます。

DataFrame.groupByを用いてデータをグループに分割します。
それぞれのグループに関数を適用します。関数の入力、出力は両方ともpandas.DataFrameです。入力データにはそれぞれのグループの全ての行と列が含まれます。
新たなDataFrameに結果を統合します。
groupBy().applyInPandas()を使用するには、以下を定義する必要があります。

それぞれのグループに対する処理を定義するPython関数
出力DataFrameのスキーマを定義するStructTypeオブジェクトあるいは文字列 
 返却されるpandas.DataFrameのカラムのラベルは、出力スキーマが文字列として定義された場合はフィールド名が一致する必要があり、文字列でない場合には、integerのインデックスなどフィールのデータ型がマッチする必要があります。
'pandas function API'の'groupBy().applyInPandas()'関数を適用する前に、グループの全データがメモリーにロードされます。特にグループのサイズに偏りがある場合、アウトオブメモリー例外を引き起こすことがあります。設定maxRecordsPerBatchはグループには適用されないので、ご自身の手で、グループ分けされたデータがメモリーに収まるようにする必要があります。
DataFrame.mapInPandas()を用いることでpandasのインスタンスを用いたmapオペレーションを実行し、pandas.DataFrameのイテレータを現在のPySparkデータフレームを表現するpandas.DataFrameの別のイテレータに変換し、結果をPySparkデータフレームとして返却します。
pandasインスタンスを用いたCogrouped mapオペレーションには、共通のキーでグループ結合される2つのPySparkDataframeに対してDataFrame.groupby().cogroup().applyInPandas()を使用し、それぞれの共通グループにPython関数が適用されます。以下のステップから構成されます。

それぞれのデータフレームでキーを同じくするグループのデータがシャッフルされ、同じ共通グループにまとめられます。
それぞれの共通グループに関数を適用します。関数の入力はpandas.DataFrameです(オプションとしてキーを表現するタプル)。関数の出力はpandas.DataFrameです。
全てのグループのpandas.DataFrameを新たなPySpark DataFrameで結合します。
groupBy().cogroup().applyInPandas()を使用するには、以下を定義する必要があります。

それぞれの共通グループに対する計算処理を定義するPython関数
出力DataFrameのスキーマを定義するStructTypeオブジェクトあるいは文字列
返却されるpandas.DataFrameのカラムのラベルは、出力スキーマが文字列として定義された場合はフィールド名が一致する必要があり、文字列でない場合には、integerのインデックスなどフィールのデータ型がマッチする必要があります。
関数を適用する前に、グループの全データがメモリーにロードされます。特にグループのサイズに偏りがある場合、アウトオブメモリー例外を引き起こすことがあります。設定maxRecordsPerBatchはグループには適用されないので、ご自身の手で、グループ分けされたデータがメモリーに収まるようにする必要があります。
Python関数はpandasのSeriesを入力として受け取り、同じ長さのpandas Seriesを返却する必要があり、これらをPythonの型ヒントで指定する必要があります。Sparkはカラムをバッチに分割し、データのサブセットとしてそれぞれのバッチに対して関数を呼び出し、結果を結合することでpandas UDFを実行します。
イテレーターUDFは以下の点を除いてスカラーのpandas UDFと同じです。

Python関数
入力として単一のバッチを受け取るのではなく、バッチのイテレーターを受け取ります。
単一のアウトプットバッチを返却するのではなく、アウトプットバッチのイテレーターを返却します。
イテレーターにおけるアウトプット全体の長さは、インプット全体の長さと同じである必要があります。
ラップされたpandas UDFは、入力として単一のSparkカラムを受け取ります。
Pythonの型ヒントとしてIterator[pandas.Series] -> Iterator[pandas.Series]を指定する必要があります。
複数シリーズイテレーター to シリーズイテレーターUDFはシリーズイテレーター to シリーズイテレーターUDFと同様の特定、制限を持っています。指定された関数は、バッチのイテレーターを受け取り、バッチのイテレーターを出力します。この関数も、UDFの実行で何かしらの状態初期化が必要な場合に有用です。
Sparkにおけるデータのパーティションは、Arrowのレコードバッチに変換され、JVMにおけるメモリー使用量の増大を引き起こします。アウトオブメモリー例外を回避するために、spark.sql.execution.arrow.maxRecordsPerBatch設定を、それぞれのバッチにおける最大レコード数を決定する整数値に設定することで、Arrowのレコードバッチのサイズを調整することができます。デフォルト値はバッチあたり10,000レコードとなっています。カラム数が大きい場合には、それに応じて値を調整する必要があります。この制限を用いることで、データのパーティションは、処理を行うための1つ以上のレコードバッチに分割されます。
オールパーパス(all-purpose)クラスターは複数のユーザーで共有でき、アドホック分析、データ探索、開発においてはベストな選択肢と言えます。処理の実装が完了して本格運用の準備が整ったら、その処理をジョブクラスターで実行するように切り替えます。ジョブクラスターはジョブが終了した際に削除されるので、リソースの利用料とコストを削減することができます。
クラスターのコストの主要要素は、クラスターによって消費されるDatabricksユニット(DBU)と、クラスターと実行するのに必要となるインフラリソースのコストとなります。目立たない副次的なコストには、SLAを満たせないことによるビジネスコストや、貧弱なコントロールによって失わられるリソース、従業員の生産性が挙げられます。
High Concurrency cluster(ハイコンカレンシークラスター)は、複数のユーザーがリソースを共有したい場合やアドホックなジョブを実行する際に最適です。通常、管理者がハイコンカレンシークラスターを作成します。ハイコンカレンシークラスターではオートスケーリングを活用することをお勧めします。
Databricksにおいては、オンデマンドインスタンスと(カスタムスポットプライスを指定した)スポットインスタンスを組み合わせてクラスターを構成することができ、ユースケースに合わせてクラスターを構築することができます。例えば、下の設定においては、ドライバーノードと4台のワーカーノードはオンデマンドインスタンス、残りの4台のワーカーノードはスポットインスタンス(最大のスポットインスタンスプライスはオンデマンドの100%)として起動すべきと設定しています。
オートスケーリングを活用することで、リソース利用量を最適化するためにワークロードに応じて、ワーカーノードの数を自動で増減することができます。オートスケーリングを有効化することで、DatabricksはSparkジョブを実行するのに最適なワーカーの数を自動的に決定します。オートスケーリングを用いることで、ワークロードに適した数のクラスターを気にすることなしに、クラスターの高い利用率を実現できます。これにより二つのメリットを享受することができます：

固定サイズのクラスターと比較して多くのケースでコストを削減できます。
固定サイズのクラスターで能力不足が生じた場合と比較して、オートスケーリングのワークロードは高速に動作します。
spark-submitジョブやいくつかのpythonパッケージなど、いくつかのワークロードはオートスケーリングクラスターとの互換性がありません。
シングルユーザーのオールパーパスクラスターにおいて、最小ワーカー数が少なく設定されている場合、オートスケーリングによって開発や分析がスローダウンするケースがあります。これは実行しているコマンドやクエリーが数分に渡ることがあり、クラスターがアイドル状態になった際にコストを節約するためにスケールダウンが発生するためです。次のコマンドが実行された際には、クラスターマネージャーはスケールアップしようとしますが、クラウドプロバイダーからインスタンスを取得するのに数分を要することがあります。この際、ジョブは不十分なリソースで実行しなくてはならず、結果を主とkするのに時間を要することになります。ワーカーの最小数を引き上げることで改善はできますが、このことはコストも引き上げることになります。これは、コストと性能のバランスを取るべきもう一つの例となります。
Delta Cachingを使用している際には、ノードが削除された際にはノードにキャッシュされたいかなるデータも削除されることに留意してください。ワークロードにおいてキャッシュデータの維持が重要な場合には、固定サイズのクラスターを利用することを検討してください。
ETLワークロードでジョブクラスターを利用している場合、ジョブが当面変更されない場合には適切にクラスターをチューニングすることでサイジングすることができます。しかし、データサイズが増加する際にはオートスケーリングによって柔軟性を手にすることができます。また、最適化されたオートスケーリングによって、長い期間実行されるジョブのクラスターが想定されるより利用されない、他のプロセスの結果を待つ必要がある場合において、コストを削減することができます。繰り返しになりますが、クラスターが適切にスケールアップする際にも微小な遅れが生じる場合が相rます。ジョブに対して厳しいSLAが求められる場合には、固定サイズのクラスターが優れた選択肢かもしれませんし、Databricksのプールを活用してクラスター起動時間を削減した方が良いかもしれません。
はい、Databricksではローカルストレージのオートスケーリングもサポートしています。ローカルストレージのオートスケーリングによって、クラスターのSparkワーカーのディスク空き容量を監視します。ワーカーのディスクの空きが減ってきた際、Databricksは自動的にディスク容量が枯渇する前にマネージドのボリュームを追加します。
オールパーパスクラスターにおいては、最新のDatabricksランタイムを活用することをお勧めします。最新のバージョンを利用することで、最新の最適化、コードとロード済みパッケージの互換性を活用できます。

運用のワークロードを実行するジョブクラスターに関しては、長期サポート(LTS)Databricksランタイムの利用をご検討ください。LTSバージョンを利用することで、互換性に関する問題を回避し、ワークロードをアップグレードする前に包括的なテストが行えます。機械学習やゲノミクスの最新ユースケースを活用する際には、特定のDatabricksランタイムのバージョンの利用を検討ください。
特定期間(デフォルトは120分)が経過した後にクラスターは自動で停止します。

管理者はクラスターポリシーを作成する際にデフォルトの設定を変更することができます。設定値を引き下げることで、クラスターのアイドル時間を減らしコストを削減できます。クラスターが停止しされた際には、すべての変数、一時テーブル、キャッシュ、関数、オブジェクトなどすべての状態が失われることに注意してください。クラスターが再起動した際に、これらの状態が復元される必要があるかもしれません。開発者が30分の昼食に席を外した場合、同じ状態に戻すまでに同じ時間を無駄にすることになるかもしれません。