bowang0911/databricks-qa-ja huggingface dataset:
はい、ガーベージコレクションに注意を払うことで、クラスターのジョブ実行性能を最適化できる可能性があります。大容量のRAMによって、ジョブの性能を改善できるかもしれませんが、ガーベージコレークションの際に遅延を生じる可能性があります。

長期間のガーベージコレクションの影響を最小化するために、それぞれのインスタンスに大容量のRAMを割り当てることを避けてください。ワーカーに対して大容量のメモリーを割り当てることは、長期間のガーベージコレクションを引き起こします。代わりに、小規模のRAMをインスタンスに割り当て、ジョブが大量のメモリを必要とするのであれば、より大量のインスタンスをデプロイするようにしてください。しかし、クラスターのサイジングの検討で議論しているような、多くのシャッフルを必要とするようなワークロードのように、大容量メモリの少数のノードが適しているケースがあります。
クラスターのアクセスコントロールに２種類のクラスター権限を設定できます。

ユーザーがクラスターを作成できるかどうかを制御できるAllow Cluster Creation権限
特定のクラスターを利用、編集できるかを設定するクラスターレベルの権限
クラスターの権限設定に関しては、cluster access controlを参照ください。

クラスター作成(Allow Cluster Creation)権限がある、あるいはポリシーの設定に基づいたクラスター作成を許可するクラスターポリシーにアクセスできる場合にはクラスターを作成することができます。クラスターの作成者はオーナーとなり、Can Manage権限を有することになります。これによって、クラスターに対するデータアクセス権限の制約の中で、他のユーザーにクラスターを共有することができます。

一般的なシナリオにおいては、クラスター設定を決定するためにクラスター権限とクラスターポリシーを理解することが重要になります。
Databricksにおいては、一つのワーカーノードあたり一つのエグゼキューターが稼働します。このため、Databricksアーキテクチャーの文脈においてはワーカーとエグゼキューターが同じ意味で用いられます。クラスターサイズはワーカーの数で決定されると考えるかもしれませんが、他に考慮すべき要因があります。

トータルのエグゼキューターのコア(コンピュート): 全エグゼキューターのトータルのコア数。この値がクラスターの最大並列実行数を決定します。
トータルのエグゼキューターのメモリー： 全エグゼキューターのトータルのRAM。ディスクに溢れる前にメモリに蓄積できるデータ量を決定します。
エグゼキューターのローカルストレージ: ローカルディスクストレージのタイプと総量。主にシャッフルとキャッシュの際のメモリ溢れ(スピル)が発生した場合に使用されます。
追加で検討すべきことには、上記の要因に影響を与えるワーカーのインスタンスタイプとサイズがあります。クラスターのサイジングをする際には以下を検討してください。

ワークロードはどれだけのデータを消費するのか？
ワークロードの計算の複雑性はどの程度か？
どこからデータを読み込むのか？
外部ストレージにおいてデータはどのようにパーティショニングされているのか？
どれだけの並列性を必要とするのか？
これらの疑問に答えることは、ワークロードに最適なクラスター設定を決定するのに役立ちます。狭い変換(入力パーティションが一つの出力パーティションに影響を及ぼす)のみを行うシンプルなETLワークロードにおいては、計算最適化設定に注力します。大量のシャッフルが予想され、メモリーおよびデータ溢れのためのディスクサイズが重要になります。シャッフルが大量に発生するワークロードにおいて、少数の大規模インスタンスはマシン間のデータ転送のネットワークI/Oを削減します。

ワーカーの数とワーカーインスタンスタイプのサイズにはトレードオフの関係があります。40コア、100GBメモリーを持つ2つのワーカーのクラスターは、10コア、25GBメモリーを持つ8台のワーカーと同程度の計算性能、メモリーを有することになります。

同じデータを何度も読み込む場合には、キャッシュの恩恵を受けることができます。Delta Cacheとストレージ最適化設定を検討してください。
初回の機械学習モデルのトレーニングは実験的なものであるため、クラスターAのような小規模クラスターがお勧めです。小規模クラスターはシャッフルの影響も軽減します。

ステージが進むなどして、安定性が課題になるのであれば、より規模の大きいクラスターBやクラスターCがお勧めです。
同じデータを繰り返し読み込むため、Delta Cachingを有効化したストレージ最適化インスタンスの活用、トレーニングデータのキャッシュがお勧めです。ストレージ最適化インスタンスの計算能力、ストレージサイズが不十分である場合には、GPU最適化ノードの利用を検討ください。この場合、Delta Cachingを利用できないというデメリットがあります。
同じデータを繰り返し読み込むため、Delta Cachingを有効化したストレージ最適化インスタンスの活用、トレーニングデータのキャッシュがお勧めです。ストレージ最適化インスタンスの計算能力、ストレージサイズが不十分である場合には、GPU最適化ノードの利用を検討ください。この場合、Delta Cachingを利用できないというデメリットがあります。

分析のワークロードで推奨する他の機能には以下のものがあります。

利用されない時間が続いた後に、クラスターが停止されるように自動停止を有効化してください。
分析者特有のワークロードに応じてオートスケーリングの活用を検討ください。
事前に定義されたインスタンスタイプ、一貫性のある設定にクラスターを統一できるようにプールの活用を検討ください。
unionや複数テーブルのjoinなどの処理を必要とするより複雑なETLジョブにおいては、シャッフルされるデータ量を最小化することが重要となります。クラスターのワーカー数を削減することでシャッフルを最小化できますので、ハイスペックのクラスターではなく、少数のクラスターを検討すべきです。
複雑な変換処理は計算資源を多く必要としますので、ワークロードに最適なコアを割り当てるためには、クラスターにノードを追加する必要があるかもしれません。

シンプルなETLジョブと同様、計算最適化のインスタンスタイプをお勧めします。これらは比較的安価であり、このタイプのワークロードは大量のメモリー、ストレージを必要としません。また、シンプルなETLジョブ同様に、クラスターの起動時間を削減し、ジョブパイプライン実行に要するトータルの時間を削減するためにプールの活用を検討ください。
クラスター提供の推奨アプローチは、オートスケーリングを伴うクラスターを提供するというハイブリッドのアプローチです。ハイブリッドアプローチでは、オンデマンドインスタンスの数とスポットインスタンスの数を定義し、インスタンスの際少数、再代数を指定してオートスケーリングを有効化します。このクラスターは常時稼働であり、グループのユーザーが利用することができ、負荷に応じてスケールアップ・ダウンします。

ユーザーにはクラスターを開始・停止する権限はありませんが、初期状態から設定されているオンデマンドインスタンスはユーザーからのクエリに即座に反応します。ユーザーのクエリがより多くのキャパシティを必要とした際には、ワークロードに対応できるようにオートスケーリングがより多くのノード(多くはスポットインスタンス)を配置します。
ベストなアプローチは、デフォルト値、固定値、設定のレンジを事前定義した設定のクラスターポリシーを作成するというものです。これにはインスタンスの数、インスタンスタイプ、スポットとオンデマンドインスタンスの比率、ロール、インストールすべきライブラリなどが含まれます。クラスターポリシーを活用することでユーザーは高度な要件に対しても、ユースケースに応じた設定を行い迅速にクラスターを起動でき、ポリシーによってコスト、コンプライアンスを制御することができます。
このアプローチは、ユーザーに対してクラスターを起動することのできるより強い権限を与えるものですが、依然として事前に定義した設定の制限をかけることでコストをコントロールすることが可能です。また、このアプローチにおいては、異なるグループのユーザーに対して、異なるデータへのアクセスが許された異なるクラスターを割り当てることも可能です。

このアプローチにおける欠点は、クラスターにおけるあらゆる変更、設定、ライブラリなど全てにおいて管理者の関与が必要となることです。
ベストプラクティスはそれぞれのジョブ実行で新規にクラスターを起動するというものです。新規クラスターによるジョブ実行によって、共有クラスターで他の作業と競合することによるSLA違反や処理失敗を避けることができます。ジョブの重要度レベルに応じて、SLAを満足するためにオンデマンドインスタンを使用できますし、コスト低減のためにスポットインスタンスとオンデマンドインスタンスを組み合わせることも可能です。
クラスタポリシーを用いることで以下のことが可能となります。

ユーザーによるクラスターの作成を事前に定義された設定に限定する。
(いくつかの値を固定値にし非表示にすることで)ユーザーインタフェースをシンプルにし、より多くのユーザーが自身のクラスターを作成できるようにする。
(時間あたりの価格に影響する属性値に制限をかけることで)クラスターあたりの最大コストを制限することによるコストコントロール
クラスターポリシーのアクセス権によって、ユーザーがクラスターを作成する際のポリシードロップダウンで、どのポリシーを選択できるのかを制限することができます。

クラスターの作成権限を持つユーザーは、制限なしポリシーを選択でき、完全に設定可能なクラスターを作成することができます。
クラスター作成権限を持ちクラスターポリシーにアクセスできるユーザーは制限なしポリシーとアクセス権があるポリシーを選択することができます。
クラスターポリシーにのみアクセスできるユーザーは、アクセス権があるポリシーを選択することができます。
ポリシールールでは以下のタイプの制約を表現することができます。

無効化された制御要素に対する固定値
UIで非表示にされた制御要素に対する固定値(JSONビューでは値は見えます)
値のセットに限定された属性値(許可リストあるいはブロックリスト)
指定された正規表現に合致する属性値
特定のレンジに限定された数値属性
有効化された制御要素においてUIで使用されるデフォルト値
クラスターポリシーはClusters API 2.0で制御される全てのクラスター属性をサポートしています。(タイプとクラスターのフォームのUI要素との関係に基づいて)サポートされる特定のタイプの制約は、フィールドごとに異なる場合があります。

さらに、クラスターポリシーでは以下の合成属性をサポートしています。

時間単位でクラスターが使用できる最大DBUである"max DBU-hour"メトリック。このメトリックは個々のクラスターレベルでのコストを直接コントロールする方法となります。
クラスターを作成するソースの制限: ジョブサービス(jobクラスター)、クラスターUI、クラスターREST API(all-purposeクラスター)。
以下のクラスター属性をクラスターポリシーで制限することはできません。

Libraries API 2.0で管理されるライブラリ。ワークアラウンドはカスタムコンテナかinitスクリプトを使うというものです。
ユーザーあたり作成できるクラスターの数(合計も同時に存在する数も)。ポリシーのスコープは単一のクラスターであり、ユーザーによって作成されたクラスターを知ることができません。
別のAPIで管理されるクラスターのアクセス権(ACL)
データフレームは、異なるタイプを持つことがあるカラムを持つ2次元のラベル付きデータ構造です。データフレームをスプレッドシート、SQLテーブル、シリーズオブジェクトのディクショナリーのようなものと考えることができます。Apache Sparkデータフレームは、一般的なデータ分析問題を効率的に解決できる様に、豊富な機能セット(カラムの選択、フィルター、join、集計)を提供します。

Apache Sparkデータフレームは、耐障害性分散データセット(RDD)の上に構築された抽象化レイヤーです。SparkデータフレームとSpark SQLは統合されたプランニングと最適化エンジンを使用するので、Databricksでサポートされているすべての言語(Python、SQL、Scala、R)でほぼ同じパフォーマンスを得ることができます。
パーソナルコンピュートは、すべてのDatabricksワークスペースで利用できるDatabricks管理のデフォルトクラスターポリシーです。このポリシーを用いることで、ユーザーは個人で利用するためのシングルマシンの計算資源を簡単に作成することができ、すぐにワークロード実行を開始し、計算資源管理のオーバーヘッドを最小化することができます。
Databricksではワークスペースには2つの意味があります。

Databricksのすべての資産にアクセスするためにチームが使用する統合環境として機能するクラウド上のDatabricksデプロイメントです。皆様の組織においては、必要に応じて単一のワークスペースか複数のワークスペースを持つことができます。
Databricksのペルソナベースの環境のためのUIです。
カラムやカラムタイプ情報、データの読み書きに必要なシリアライザ、デシアライザを含むデータウェアハウスの様々なテーブルやパーティションに関するすべての構造情報と、データが格納される対応ファイルのすべてを格納するコンポーネントです。すべてのDatabricksデプロイメントにはテーブルメタデータを永続化するために、すべてのクラスターからアクセスできる中央Hiveメタストアが含まれています。また、外部Hiveメタストアを選択することもできます。
ノートブックやジョブを実行する一連の計算資源と構成です。クラスターにはall-purpose(汎用)とjobの2つのタイプがあります。

UI、CLI、REST APIを用いてall-purposeクラスターを作成します。手動でall-purposeクラスターを停止、再起動することができます。コラボレーティブかつインタラクティブ分析を行うために、この様なクラスターを複数ユーザーで共有することができます。
新規ジョブクラスターでジョブを実行する際に、Databricksジョブスケジューラーがジョブクラスターを作成し、ジョブが完了するとクラスターを停止します。ジョブクラスターを再起動することはできません。
クラスターで実行されるDatabricksによって管理される一連のコアコンポーネントです。Databricksではいくつかのタイプのランタイムを提供しています。

Databricksランタイムには、Apache Sparkだけではなく、ビッグデータ分析における使いやすさ、性能、セキュリティを劇的に改善する多数のコンポーネントとアップデートが含まれています。
Databricks機械学習ランタイムはDatabricksランタイムをベースとしており、機械学習やデータサイエンスですぐに利用できる環境を提供します。TensorFlow、Keras、PyTorch、XGBoostの様な様々な人気のあるライブラリが含まれています。
Databricks Lightは、オープンソース版のApache SparkランタイムのDatabricksパッケージです。Databricksランタイムによって提供される高度なパフォーマンス、信頼性、オートスケーリングのメリットが不要な場合にジョブに対するランタイムの選択肢を提供します。JAR、Python、spark-submitジョブを実行するためにクラスターを作成する際にのみDatabricks Lightを選択することができます。インタラクティブやノートブックジョブのワークロードを実行するクラスターではこれを選択することはできません。
クラスターの起動時間とオートスケーリングの時間を削減するアイドル状態で利用可能なインスタンスのセットです。プールにアタッチされると、クラスターはプールからドライバーノードとワーカーノードを割り当てます。プールにクラスターのリクエストに答えるための十分なアイドルリソースがない場合には、プールはインスタンスプロバイダーから新規インスタンスを割り当てることて拡張します。アタッチされたクラスターが停止されると、使用されたインスタンスはプールに返却され、別のクラスターで再利用できる様になります。
データ処理パイプラインを開発、実行するためのフレームワークです。

Create, run, and manage Databricks Jobs: ノートブックやライブラリを即時あるいはスケジュールベースで実行する非インタラクティブなメカニズムです。
Delta Live Tables introduction: 高信頼、維持可能、テスト可能なデータ処理パイプラインを構築するためのフレームワークです。
Databricksでは異なる課金スキームに対応する2つのタイプのワークロードを認識します。データエンジニアリング(job)とデータアナリティクス(all-purpose)です。

データエンジニアリング: Databricksジョブスケジューラーがワークロードごとに作成するジョブクラスターで実行される(自動化)ワークロードです。
データアナリティクス: all-purposeクラスターで実行される(インタラクティブな)ワークロードです。インタラクティブなワークロードは、通常Databricksノートブックのコマンドによって実行されます。しかし、既存のall-purposeクラスターでのジョブ実行もインタラクティブワークロードと見做されます。
Databricks SQLは、SQLクエリーとBIツールを主に用いて作業するデータアナリスト向けのものです。お使いのデータレイクに格納されているデータに対してアドホックのクエリーを実行し、ダッシュボードを作成するための直感的な環境を提供します。このUIはデータサイエンス & データエンジニアリングやDatabricksマシンラーニング環境とは大きく異なります。
Apache Airflowは、Pythonを用いてプログラム的に、データと機械学習パイプライン(Airflowの用語ではDAGと呼ばれます)を作成、スケジュール、モニタリングすることができる人気かつ拡張可能なプラットフォームです。Airflowには、データベースからクラウドストレージに至る全てとのやりとりを容易にするビルトインのオペレーターが多数含まれています。
モデルレジストリは以下の機能を提供します。

時系列順のモデルのリネージュ(どの時点でどのMLflowエクスペリメントとランがモデルを生成したのか)。
サーバレスリアルタイム推論、あるいはクラシックMLflowモデルサービングによるモデルサービング。
モデルのバージョン管理。
ステージの移行(ステージングからプロダクション、アーカイブへなど)。
レジストリのイベントに基づいて自動でアクションを起動するWebhook。
モデルのイベントに対するメールの通知。
また、モデルの説明文を作成、参照したり、コメントすることができます。
プログラムからモデルレジストリにモデルを登録する方法は3つあります。すべての方法はMLflowモデルレジストリによって管理されるセキュアな場所にモデルをコピーします。
MLflowエクスペリメントの過程でモデルを記録し、指定された他名前で登録するには、mlflow.<model-flavor>.log_model(...)メソッドを使います。指定された名前の登録モデルが存在しない場合には、このメソッドは新規モデルを登録してバージョン1を作成し、ModelVersion MLflowオブジェクトを返却します。指定された名前の登録モデルがすでに存在しているのであれば、このメソッドは新規モデルバージョンを作成し、バージョンオブジェクトを返却します。
すべてのエクスペリメントのランが完了した後に、指定した名前でモデルを登録し、どのモデルをレジストリに追加するのが最も適切であるのかを決定したのであれば、mlflow.register_model()メソッドを使います。このメソッドには、引数mlruns:URIにランIDを指定する必要があります。指定された名前の登録モデルが存在しない場合、このメソッドは新規モデルを登録してバージョン1を作成し、ModelVersionMLflowオブジェクトを返却します。すでに指定された名前のモデルが登録されているのであれば、このメソッドは新規モデルバージョンを作成し、新規バージョンオブジェクトを返却します。
指定された名前で新たに登録モデルを作成するには、MLflow Client APIのcreate_registered_model()メソッドを使います。モデル名が存在する場合には、このメソッドはMLflowExceptionをスローします。
また、Databricks Terraformプロバイダーやdatabricks_mlflow_modelを用いてモデルを登録することができます。
モデルバージョンは以下のステージのいずれかに存在することになります：None、Staging、Production、Archivedです。Stagingステージは、モデルのテストや検証を意味しますが、Productionステージはテストやレビュープロセスが完了したモデルバージョン向けのためのものであり、ライブなスコアリングのためのアプリケーションにデプロイされます。削除できると考えた時点でアーカイブされたモデルバージョンは、不活性状態と見なされます。バージョンが異なるモデルは異なるステージになることができます。
モデルレジストリにモデルを登録した後に、バッチ推論やストリーミング推論のためのモデルを使用するノートブックを自動で生成することができます。あるいは、Databricksのサーバレスリアルタイム推論、あるいはクラシックMLflowモデルサービングを用いて、リアルタイムサービングにモデルを使用するエンドポイントを作成することができます。
モデル名のフォルダーの配下のフォルダーDLT-Inference配下にノートブックが保存されます。

Streaming (Delta Live Tables) タブをクリックします。

Model versionドロップダウンから、使用するモデルバージョンを選択します。ドロップダウンの最初の2つの項目は、(存在する場合には)モデルの現在のプロダクションとステージングバージョンになります。これらの選択肢のいずれかを選択すると、ノートブックは自動でランの実行時のプロダクションとステージングバージョンを使用します。モデルの開発を進めている際にはこのノートブックをアップデートする必要はありません。

Input tableの隣のBrowseボタンをクリックします。Select input dataダイアログが表示されます。必要に応じて、Computeドロップダウンでクラスターを変更することができます。
モデルに対する入力データを含むテーブルを選択し、Selectをクリックします。生成されたノートブックは、ソースとしての入力テーブルを使用するデータ変換処理を作成し、モデル予測を実行するためにMLflowのPySpark推論UDFとインテグレーションします。モデルを適用する前後で追加の変換処理が必要であれば、生成されたノートブックを編集することができます。
出力のDelta Live Table名を指定します。ノートブックは指定された名前でライブテーブルを作成し、モデル予測結果を格納するために使用します。必要に応じてターゲットデータセットをカスタマイズするために、生成されたノートブックを編集することができます。例えば、出力としてストリーミングライブテーブルを定義し、スキーマ情報やデータ品質制約を追加します。
このノートブックを用いて新たなDelta Live Tablesパイプラインを作成するか、追加のノートブックライブラリとして既存のライブラリに追加します。
モデルレジストリでモデルバージョンを比較することができます。

登録モデルページで、モデルバージョンの左のチェックボックスをクリックすることで2つ以上のモデルバージョンを選択します。
Compareをクリックします。
<N>バージョンを比較する画面が表示され、選択されたモデルバージョンのパラメーター、スキーマ、メトリクスを比較するテーブルが表示されます。画面の下には、プロットのタイプ(scatter、contour、parallel coordinates)とプロットするパラメーターやメトリクスを選択することができます。
はい、指定した登録モデルとモデルバージョンにおけるアクティビティに関して、メール通知を行う様にモデルレジストリを設定することができます。

登録モデルページで、Notify me aboutメニューに3つのオプションが表示されます。
All new activity: このモデルのすべてのモデルバージョンのすべてのアクティビティについてメールの通知を送信します。登録モデルを作成した際、この設定がデフォルトになります。
Activity on versions I follow: フォローしているモデルバージョン位関してのみメール通知を行います。この選択によって、フォローしているすべてのモデルバージョンの通知を受け取ります。特定のモデルバージョンの通知をオフにすることはできません。
Mute notifications: この登録モデルのアクティビティについてメール通知を送信しません。
以下のイベントによって通知が行われます。

新規モデルバージョンの作成
ステージ移行のリクエスト
ステージ移行
新規コメント
以下のいずれかを行った際にはモデルの通知を自動で購読します。

モデルバージョンへのコメント
モデルバージョンのステージの移行
モデルのステージの移行をリクエスト
モデルレジストリは、アクティビティごとの日毎のユーザーに通知するメールの数に制限を設けています。例えば、ある登録モデルにおいて新規モデルバージョンに関するメールを1日に20回受け取った場合、モデルレジストリは1日の制限に達したことを告げるメールを送信し、次の日までイベントに関するメールを送信しません。

許可するメールの数の制限を増やすには、Databricks担当者にお問い合わせください。
Webhookを用いることで、お使いのインテグレーションが自動でアクションを起動できる様に、モデルレジストリのイベントをリッスンできるようになります。自動化や既存のCI/CDツールやワークフローとお使いの機械学習パイプライン解いて具レーションするためにwebhookを使うことができます。例えば、新規モデルバージョンが作成された際にCIのビルドを起動したり、モデルのプロダクションへの移行がリクエストされるたびにSlackを通じてチームメンバーに通知を行うことができます。
Databricksでは、複数ワークスペースでのモデル共有をサポートしています。例えば、お使いのワークスペースでモデルを開発・記録し、中央管理されているモデルレジストリに登録することができます。これは、複数のチームがモデルにアクセスする際に有用です。複数のワークスペースを作成し、これらの環境横断でモデルを利用、管理することができます。
お使いのDatabricksワークスペース間でMLflowオブジェクトをインポート、エクスポートするために、ワークスペース間でMLflowエクスペリメント、モデル、ランを移行するためのコミュニティ主導のオープンソースプロジェクトであるMLflow Export-Importを活用することができます。
'MLflow Export-Import' ツールを使うことで、以下のことが可能となります。

同一あるいは異なるトラッキングサーバーにいる他のデータサイエンティストとの共有、コラボレーション。例えば、他のユーザーからのエクスペリメントを、あなたのワークスペースにコピーすることができます。
開発ワークスペースからプロダクションワークスペースの様に、別のワークスペースへのモデルのコピー。
お使いのローカルトラッキングサーバーからMLflowエクスペリメントやランを、Databricksワークスペースにコピー。
ミッションクリティカルなエクスペリメントやモデルを別のDatabricksワークスペースにバックアップ。
AWS上でDatabricksのワークスペースをデプロイするには、以下の2つの方法があります。

AWSリソースを自動生成(背後ではCloudFormationを使用)し、ワークスペースを自動でデプロイする(メニューではCreate Workpace > Quickstart)
AWSリソースをユーザー側でマニュアルで準備して、それらを用いてワークスペースをデプロイする(メニューではCreate Workpace > Custom AWS configuration)
Delta Live Tablesは高信頼、維持可能、テスト可能なデータ処理パイプラインを構築するためのフレームワークです。お手元のデータに対して実行する変換処理を定義すると、Delta Live Tablesはタスクー消すとレーション、クラスター管理、モニタリング、データ品質、エラーハンドリングを管理します。Delta Live Tablesを用いてすべてのデータ処理ワークフローを構築することもできますし、複雑なデータ処理ワークフローをオーケストレーションするために、Databricksジョブのワークフローの中にパイプラインをインテグレーションすることもできます。
Apache Sparkは、Databricksレイクハウスプラットフォームの心臓であり、プラットフォームの計算クラスターとSQLウェアハウスを強化するテクノロジーです。DatabricksはApache Sparkに最適化されたプラットフォームであり、Apache Sparkのワークロードを実行するための効率的かつシンプルなプラットフォームを提供します。
Databricksという会社はApache Sparkのオリジナルクリエイターによって創業されました。Apache SparkはオープンソースソフトウェアプロジェクトとしてDatabricksを含む数多くのトップカンパニーからのコミッターを有しています。

Databricksでは、Apache Sparkの開発と機能のリリースを継続しています。Databricksランタイムには、更なる最適化とApache Sparkをベースとした専用の機能や、C++で再構築された最適化バージョンのApache SparkであるPhotonを含む拡張版Apache Sparkが含まれています。
Databricksでは数多くのワークロードをサポートしており、Databricksランタイム内には多数のオープンソースライブラリが含まれています。Databrikcs SQLは内部ではApache Sparkを使用していますが、エンドユーザーはデータベースオブジェクトにクエリーするために標準的なSQL構文を使用します。

Databricks機械学習ランタイムはMLのワークロードに最適化されており、多くのデータサイエンティストがDatabricksで作業する際に、TensorFlow やSciKit Learnのような主要なオープンソースライブラリを使用しています。Databricksによってデプロイ、管理されている計算リソースに対して任意のワークロードをスケジュールするためにワークフローを活用することができます。
Databricksレイクハウスプラットフォームは、皆さまのビジネスをスケールさせるエンタープライズソリューションを開発、デプロイするためのセキュアかつコラボレーティブな環境を提供します。Databricksの従業員の多くは、Apache Sparkについて最も知識を持っているメンテナーであり、世界中のユーザーでもあります。我々はユーザーの皆様がApache Sparkが稼働する最速の環境を利用できる様に、継続的に新たな最適化を開発し、リリースし続けています。
データモデルはデータウェアハウス構築におけるフロントと中心を担っています。通常、このプロセスはセマンティックなビジネス情報モデルからスタートし、論理データモデル、そして最後には物理データモデル(PDM)となります。すべては、ビジネス情報モデルとプロセスフローが最初に作成され、企業内のビジネスプロセスと同じ様に、キーとなるビジネスエンティティ、属性、それらのインタラクションがキャプチャされる適切なシステム分析と設計フェーズからスタートします。そして、エンティティが互いにどの様に関係するのかを示す論理データモデルが作成されますが、これは特定の技術に依存しないモデルとなります。最後に、背後の技術プラットフォームに基づいて、データの読み書きが効率的に行われることを保証するために、PDMが作成されます。我々はみんな知っていますが、データウェアハウスにおいては、スタースキーマやデータボルトのような分析フレンドリーなモデリングスタイルが非常に人気があります。
定義されたビジネス問題に基づき、データモデル設計の狙いは再利用可能性、柔軟性、スケーラビリティにおいて容易な方法でデータを表現することとなります。以下に、それぞれのトランザクションを保持するSalesファクトテーブルと、データをスライスアンドダイスするための顧客、商品、店舗、日付のような様々なディメンションテーブルを示す典型的なスタースキーマデータモデルを示します。特定の月において最も人気のある商品は何か、ある四半期で最もパフォーマンスが優れている店舗はどれかと言う様な特定のビジネス上の質問に答えるために、ディメンションがファクトテーブルとjoinすることができます。これらがDatabricksでどの様で実装されているのかを見ていきましょう。
PK/FK定義をサポートする能力を持つことで、Databricksにおけるデータモデルの定義が非常に簡単になります。また、アナリストが効率的にクエリーを記述するために、Databricks SQLウェアハウスでjoinの関係をクイックに明らかにする役にも立ちます。多くの他のMassively Parallel Processing (MPP)、EDW、クラウドデータウェアハウスのように、PK/FK製薬は情報を提供するためだけのものです。Databricksでは、PK/FKリレーションシップの矯正をサポートしていませんが、セマンティックデータモデルの設計を容易にするために定義することが可能です。
アイデンティティカラムは、データの新規の行のそれぞれにユニークなID番号を自動で生成するデータセット内のカラムです。通常これらはデータウェアハウスでサロゲートキーとして使用されます。サロゲートキーは、行のユニーク性を特定するために、自然な主キーや複数フィールドを結合したものに頼ることがない様に、システムが生成する無意味なキーです。通常、これらのサロゲートキーは、データウェアハウスで主キーや外部キーとして使用されます。
主キーや外部キーの情報提供を目的とした制約に加え、Databricksではテーブルに追加されるデータの品質や統一性を保証するために強制される、カラムレベルのデータ品質チェック制約もサポートしています。これらの制約は自動で検証されます。これらの良い例はNOT NULL制約とカラム値の制約です。他のクラウドデータウェアハウスと異なり、特定のカラムのデータ品質を保証するために、カラム値チェックよりも先に進んだ機能を提供しています。以下に示している様に、valid_sales_amountチェック制約は、テーブルにデータを追加する前にすべての既存の行が制約(例: sales amount > 0)を満たしていることを検証します。詳細な情報はこちらから確認できます。
Delta Live Tablesはパイプラインにおける依存関係をサポートしています。例えば、%pip installコマンドを用いて任意のPythonパッケージをインストールすることができます。また、Delta Live Tablesはグローバルあるいはクラスタースコープのinit scriptをサポートしています。しかし、これらのパイプラインにおける外部依存関係、特にinit scriptはランタイムアップグレード時のリスクを増加させます。これらのリスクを軽減するために、パイプラインにおけるinit scriptの使用は最小限に留めてください。処理でinit scriptが必要な場合には、早い段階で問題を検知するためにパイプラインのテストを自動化してください。次のランタイムバージョンを用いたパイプラインのテストを自動化するをご覧下さい。init scriptを使う際には、テストの頻度を高めることをお勧めします。
レイクハウスでは、データの冗長性や分断を削減するためにデータを集中して格納することを強調していますが、多くの企業においてはプロダクションのデータシステムを多数持っています。多くの理由から接続されたシステムのデータをクエリーしたいと考えるかもしれません。

アドホックのレポート。
POCの作業。
新たなETLパイプラインやレポートの開発。
インクリメンタルな移行におけるワークロードのサポート。
Databricksにいくつかのデータセットを移行したり、取り込んだりしないという選択をしつつも、隔離されたユースケースにおいて何人かのユーザーにアクセスを与える必要がある場合があります。
Apache Sparkは、さまざまなシステムやデータソースから得られるさまざまなフォーマットのデータに接続するサポートを常に提供しています。数多くの外部データソースとインテグレーションするためにDatabricksランタイムはこれらのオープンソースコネクター上に構築されており、追加のライブラリをバンドルしています。

多くのデータベースへの接続ではApache SparkのJDBCコネクターを使用しています。これらの接続の並列性をチューニングするために数多くのオプションを指定することができ、必要に応じてクエリーをソースシステムにプッシュダウンすることができます。

Databricksランタイム11.3以降では、PythonやR、Scalaに加えてSQLでもシークレットがサポートされ、検閲された文字列を用いることでユーザースコープの認証情報を設定することができます。
Databricksでは数多くのBIツールと互換性のあるJDBCやODBCドライバーを提供しています。
Delta Sharingは数多くのクライアントから接続するユーザーにDelta Lakeテーブルを共有するためのオープンソースプロトコルを提供しています。
Delta Lakeは数多くのインテグレーションを提供する完全にオープンソースなストレージプロトコルです。
Databricksは、レイクハウスのデータのクエリーをサポートするために数多くのBIとビジュアライゼーションツールとパートナーシップを結んでいます。
DLTがデータエンジニアの負荷を削減し、洞察をより迅速に得られる様にする特定の方法として3つのポイントをハイライトしたいと思います。

自動化されたインフラストラクチャの管理: タスクオーケストレーション、エラーハンドリング、パフォーマンス最適化のような複雑かつ時間がかかるアクティビティを自動化することでオーバーヘッドを除去。
ストリーミングとバッチをシンプルに: 別々のパイプラインを構築する必要なしに、ストリーミングとバッチを統合し、順序を守らないデータを取り扱うためにAuto Loaderとインテグレーションし、データが到着するとすぐに利用可能に。
データ構造変更の自動ハンドリング: レコードの変更と部分的アップデートを組み合わせ、単一かつ完全、そして最新のレコードに。
インクリメンタルなデータ取り込みには、Delta Live TablesでAuto Loaderを使用することをお勧めします。Delta Live TablesはApache Sparkの構造化ストリーミングを拡張し、数行の宣言型PythonあるいはSQLを記述することで、以下の機能を持つプロダクション品質のデータパイプラインをデプロイすることができます。

コスト削減のためにオートスケーリングする計算インフラストラクチャ
エクスペクテーションによるデータ品質チェック
スキーマ進化の自動ハンドリング
イベントログのメトリクスを通じたモニタリング
Auto Loaderは、ストリームの状態を調査するためのSQL APIを提供しています。cloud_files_state関数を用いることで、Auto Loaderのストリームによって検知されたファイルに関するメタデータを取得することができます。Auto Loaderのストリームに関連づけられたチェックポイントのロケーションを指定して、シンプルにcloud_files_stateにクエリーを行います。
Apache SparkのStreaming Query Listenerインタフェースを使うことをお勧めします。

Auto Loaderはそれぞれのバッチにおいて、Streaming Query Listenerにメトリクスをレポートします。ストリーミングクエリーの進捗ダッシュボードのRaw Dataタブの下のnumFilesOutstandingとnumBytesOutstandingメトリクスでバックログにどれだけのファイルが存在するのか、バックログがどれだけ大きいのかを確認することができます。
計算コストを削減するためには、低レーテンシーの要件がない限り、連続的に稼働させるのではなく、Trigger.AvailableNow(Databricksランタイム10.1以降)やTrigger.Onceを用いたバッチジョブとしてAuto LoaderをスケジュールするためにDatabricksジョブを使用することをお勧めします。

ファイル検知は、ディレクトリ一覧モードでお使いのストレージアカウントに対するLISTオペレーションの実行、サブスクリプションサービスに対するAPIリクエスト、ファイル通知モードのキューサービスによってコストを発生させることがあります。以下のことをお勧めします。

ディレクトリ一覧モードでAuto Loaderを継続的に実行する際にはProcessingTimeトリガーを指定します。
可能であればインクリメンタルな一覧を活用できる様に、語順でファイルをストレージアカウントにアップロードする様に設計します。
特に深くネストされたディレクトリに対しては、Databricksランタイム9.0やディレクトリ一覧モードを使用します。
インクリメンタル一覧が利用できない場合には、ファイル通知を利用します。
コストを追跡するために、Auto Loaderによって作成されたリソースをタグ付けするためにリソースタグを使用します。
Trigger.AvailableNowを用いることで、バッチジョブとしてDatabricksジョブの中でAuto Loaderを実行する様にスケジュールすることができます。AvailableNowトリガーは、クエリー開始時間の前に到着したすべてのファイルを処理する様にAuto Loaderに指示します。ストリームが起動した後にアップロードされた新規ファイルは次のトリガーまで無視されます。
Trigger.AvailableNowを用いることで、データ処理とは非同期にファイル検知が行われ、レート制限を用いた複数のマイクロバッチでデータを処理することができます。デフォルトではAuto Loaderはマイクロバッチごとに最大1000ファイルを処理します。マイクロバッチでどれだけのファイル数やバイト数を処理すべきかを設定するために、cloudFiles.maxFilesPerTriggerやcloudFiles.maxBytesPerTriggerを設定することができます。ファイルの制限はハードリミットですが、バイトの制限はソフトリミットであり、指定されたmaxBytesPerTriggerよりも多いバイト数が処理される場合があることを意味します。両方のオプションが指定された場合には、Auto Loaderはいずれかの制限に達するまでに可能な限り多くのファイルを処理します。
Auto Loaderは確実に一度(exactly-once)の取り込みの保証をするために、RocksDBを用いたチェックポイントの場所に検知したファイルの履歴を保持します。ボリュームの大きいデータセットにおいては、ストレージコストとAuto Loader起動時間を削減するために、チェックポイントの場所からイベントを廃棄するためにcloudFiles.maxFileAgeオプションを使用することができます。cloudFiles.maxFileAgeに設定できる最小値は"14 days"です。RocksDBにおける削除はトゥームストーンのエントリーとして表示されるので、安定する前にイベントが廃棄されるので、一時的にストレージの利用量が一時的に増加する場合があります。
コードをフォーマットするにはノートブックのCan Edit権限が必要となります。

以下の方法で、フォーマッターを起動することができます。

単一セルのフォーマット

キーボードショートカット：Cmd+Shift+Fを押します。
コマンドコンテキストメニュー
SQLセルのフォーマット：SQLセルのコマンドコンテキストドロップダウンメニューのFormat SQLを選択します。このメニュー項目はSQLノートブックセルか%sql言語マジックを持つセルでのみ表示されます。
Pythonセルのフォーマット：PythonセルのコマンドコンテキストドロップダウンメニューのFormat Pythonを選択します。このメニュー項目はPythonノートブックセルか%python言語マジックを持つセルでのみ表示されます。
複数セルのフォーマット

複数のセルを選択し、Edit > Format Cell(s) を選択します。1つ以上の言語のセルを選択した場合には、PythonとSQLのセルがフォーマットされます。これには%sqlや%pythonを使用しているものも含まれます。

ノートブック内のすべてのPythonとSQLセルのフォーマット

Edit > Format Notebookを選択します。1つ以上の言語のセルが含まれている場合には、PythonとSQLのセルがフォーマットされます。これには%sqlや%pythonを使用しているものも含まれます。
ノートブック内のコードをフォーマットするためにBlackを使用します。
Blackは4スペースのインデントに対してPEP 8を強制します。インデントの設定はできません。
SQL UDFの中に埋め込まれたPython文字列のフォーマットはサポートされていません。同様に、Python UDF内のSQL文字列のフォーマットもサポートされていません。
Databricksユニット(DBU)はプラットフォームにおけるコンサンプションの内部単位です。SQLウェアハウスを除き(SQLウェアハウスは基本的にクラスターのグループであり、DBUのレートはウェアハウスを構成するクラスターのDBUレートの合計となります)、消費されるDBUの量は、それぞれのクラスターのノードの数と内部のVMのインスタンスタイプの計算能力に基づくものとなります。
クラスターポリシーを用いることで、管理者は新規クラスターを作成する際に利用できる設定をコントロールすることができ、これらのポリシーを個別のユーザーやユーザーグループに割り当てることができます。デフォルトでは、すべてのユーザーにはワークスペースにおける「制限なしのクラスター作成」権限が付与されています。これは、割り当てられたポリシーの範囲外で制限なしにクラスターを作成できてしまい、管理されないままコストを垂れ流すことになるので滅多なことで使うべきではありません。
Bloomフィルターは、偽陽性の確率を用いてセットにキーがあるかどうか、セットにアイテムが あるかもしれない ことを教えてくれます。インデックスで使用すると、Bloomフィルターは他のテクニックでは高速化できない様なフィールドに対して「藁山から針を探す」ようなクエリーの高速化に役立ちます。
Bloomフィルターは、定義された偽陽性の確率(FPP)を用いて、確実にファイルにデータが無い、あるいは、おそらくファイルにあるということを宣言することでオペレーションを行います。

DatabricksではファイルレベルのBloomフィルター、それぞれのデータファイルには、関連づけられた単一のBloomフィルターインデックスファイルが割り当てられます。ファイルを読み込む前に、Databricksはインデックスファイルをチェックし、インデックスによってファイルがデータフィルターにマッチするかもしれないということが示された場合にのみファイルが読み込まれます。インデックスが存在しない、あるいはクエリーされたカラムにBloomフィルターが定義されていない場合、Databricksは常にデータファイルを読み込みます。

Bloomフィルターのサイズは、Bloomフィルターを作成したセット内のエレメント数と必要となるFPPに依存します。FPPが低いほど、エレメントごとに使用されるビットの数は高くなり精度は高まりますが、ディスク容量を多く消費し、ダウンロードが遅くなります。例えば、FPP10%にはエレメントあたり5ビットが必要となります。
データフローパイプラインにおいては、Delta Live Tablesとそれらの依存関係は標準的なSQLのCreate Table As Select (CTAS)文とDLTのキーワードliveで宣言することができます。

PythonでDLTを開発する際には、Delta Liveテーブルを作成するために@dlt.tableデコレーターを使用します。パイプラインのデータ品質を保証するために、DLTは不正なレコードを持つパイプラインの挙動を定義するシンプルなSQLの制約であるエクスペクテーションを使用します。

ストリーミングワークロードは、多くの場合予期できないデータボリュームを伴うので、Databricksでは、不要なインフラストラクチャをシャットダウンすることでコストを削減しつつも、全体的なエンドツーエンドのレーテンシーを最小化するために、データフローに対して強化オートスケーリングを適用します。
はい、Pythonで記述されたDelta Live Tableは、Spark構造化ストリーミングを用いることでKafkaのようなイベントバスから直接データを取り込むことができます。コンプライアンスの問題を回避し、コストを削減するためにKafkaのトピックの保持期間を短くすることで、Deltaが提供する安価かつ弾力性のあるガバナンスの効いたストレージのメリットを享受することができます。
複数のノートブックからDLTパイプラインを構成することができますが、一つのDLTノートブックは、全体がSQLかPythonで記述される必要があります(単一のノートブックでセルごとに異なる言語を記述できるDatabricksノートブックとは異なります)。

このため、SQLが好みであるならば、PythonのノートブックでApache Kafkaからデータ取り込みのコーディングを行い、別のSQLノートブックでデータパイプラインの変換ロジックを記述することになります。
Databricksワークスペースでは、クラウドベンダー固有のオブジェクトストアは、クラウドに依存しないフォルダーとしてDatabricksファイルシステム(DBFS)にマッピングされます。データがオフロードされたら、Databricksのオートローダーでファイルを取り込むことができます。
Databricks on Google Cloudは、皆様の分析、AIワークロードの全てを統合するためにデータウェアハウスとデータレイクの良いところを組み合わせたシンプルかつオープンなレイクハウスプラットフォームに皆様のすべてのデータを格納することができる共同開発のサービスです。Google Kubernetes Engine (GKE)で動作し、Google Cloud Platform (GCP)上でホストされており、Google CloudのID、Google Cloud Storage、BigQuery、その他のGoogle Cloudのテクノロジーとのビルトインのインテグレーションを提供します。このプラットフォームによって、データエンジニア、データサイエンティスト、データアナリスト、SecOps、クラウドエンジニアリングを含む企業のいかなるペルソナ間のコラボレーションを実現します。Google Kubernetes Engine (GKE)で動作し、Google Cloud Platform (GCP)上でホストされており、Google CloudのID、Google Cloud Storage、BigQuery、その他のGoogle Cloudのテクノロジーとのビルトインのインテグレーションを提供します。このプラットフォームによって、データエンジニア、データサイエンティスト、データアナリスト、SecOps、クラウドエンジニアリングを含む企業のいかなるペルソナ間のコラボレーションを実現します。
企業のお客様は、GCP環境に自分のデプロイメントを行える機能である顧客管理仮想プライベートクラウド(VPC)を使い始めるべきです。顧客管理VPCを用いることで、マネージドプラットフォームの使いやすさとデフォルトでセキュアなデプロイメントを組み合わせるデータとAIに対するPlatform-as-a-Serviceアプローチを提供しながらも、数多くの社内外のセキュリティポリシーとフレームワークに準拠することができます。
様々なデータソースからのストリーミングデータは、レイクハウスに取り込まれる前にメッセージバスやオブジェクトストレージにステージングされます。ステージングエリアからのデータは、レイクハウスにデータを書き込むApache Sparkの構造化ストリーミング(SS)によって処理されます。
Auto Loaderを使えます。Auto Loaderはクラウドオブジェクトストレージに新規ファイルが到着するとインクリメンタルに処理を行い、ユーザーはカスタムアプリケーションを開発する必要がないので、ストリーミングデータの取り込みをシンプルなものにします。内部状態を保持することで、これまでに処理したファイルを追跡します。処理に失敗した場合には、最後に処理したファイルからスタートするためにこの状態情報を使用します。さらに、データを再実行、再処理する必要がある場合には、ディレクトリ内の既存ファイルを処理するオプションを提供します。
Auto Loaderのメリットには以下の様なものがあります。

数十億のファイルを処理できる能力
計算リソースの最適利用を用いた非同期バックフィル
パフォーマンスを改善するための最適化ディレクトリ一覧
スキーマの推定とスキーマドリフトへの対応
自動ファイル通知サービスを活用することによるコスト効率の高いファイル通知