bowang0911/databricks-qa-ja huggingface dataset:
Feature Storeとはデータサイエンスチームが特徴量を共有するためのリポジトリです。DatabricksにおけるFeature Storeの説明はこちらをご参照ください。日次のバッチ推論のようなジョブであれば単純にDatabricksのメタストアからテーブルを呼び出せば良いのですが、REST APIによるリアルタイム推論のように高速なレスポンスが求められるケースがあります。Databricks on AWSではFeature Storeに登録したテーブルをAmazon DynamoDB、Amazon Aurora(MySQL互換), Amazon RDS(MySQL)のテーブルとして発行することができ、これををOnline Feature Storeと呼んでいます。Online Feature Storeによって、低レイテンシで推論用の特徴量を供給することが可能になります。
PySparkでサポートされているUDFには大きく2つのカテゴリーが存在します: Python UDFとPandas UDFです。Python UDFは、Pickleによってシリアライズ/デシリアライズされるPythonオブジェクトを受け取り/返却するユーザー定義スカラー関数であり、一度に一行を処理します。Pandas UDF(ベクトライズドUDF)は、Apache Arrowによってシリアライズ/デシリアライズされるシリーズ、データフレームを受け取り/返却するUDFであり、ブロックごとに処理します。Pandas UDFは用途や入出力のタイプに応じてカテゴリ分けされるバリエーションが存在します: Series to Series, Series to Scalar, Iterator to Iteratorです。Pandas UDF実装をベースとしたPandas Functions APIが存在します: Map (mapInPandasなど)、(Co)Grouped Map (applyInPandasなど)、そして、Arrow Function APIのmapInArrowもあります。関数が入出力のイテレーターを受け取らない限り、上述のすべてのUDFタイプにメモリープロファイラーは適用されます。
Python UDFは、Pickleによってシリアライズ/デシリアライズされるPythonオブジェクトを受け取り/返却するユーザー定義スカラー関数であり、一度に一行を処理します。Pandas UDF(ベクトライズドUDF)は、Apache Arrowによってシリアライズ/デシリアライズされるシリーズ、データフレームを受け取り/返却するUDFであり、ブロックごとに処理します。Pandas UDFは用途や入出力のタイプに応じてカテゴリ分けされるバリエーションが存在します: Series to Series, Series to Scalar, Iterator to Iteratorです。
小売、金融、サイバーセキュリティなどいかなる業界においても、不正な挙動が発生したらすぐに検知することは間違いなく優先度が高いと言えます。この様な能力の欠如は、利益の損失、規制機関からの罰金、顧客プライバシーの侵害、サイバーセキュリティの場合にはセキュリティ侵害によって信頼が損なわれます。このため、このような比較的不自然な大量のクレジットカードのトランザクションの発見、怪しいユーザーの行動の特定、Webサービスにおける不自然なリクエストボリュームのパターンの識別によって、日々の業務を素晴らしいものにするのか、あるいはひどい災害になるのかを二分します。
不正検知はいくつかの課題を突きつけます。1つ目は、「不正」とはどの様なものかというデータサイエンスの課題です。幸運なことに、機械学習がデータから正常なものから不正なパターンをどの様に区別するのかを学習するパワフルなツールを備えています。不正検知の場合、全ての不正がどの様なものであるのかを知ることは不可能なので、このためのリソースが利用できる場合でも機械学習モデルのトレーニングのためのデータセットをラベル付けすることは不可能です。このため、不正を検知するには、ラベル無しのデータからパターンを学習する教師無し学習が用いられてきました。完璧な教師なし不正検知機械学習モデルが分かったとしても、多くの場合、現実的な問題がスタートします。ソースシステムからデータが到着するとすぐに新たな観測事項が投入され、変換処理を経てモデルによって最終的なスコアが計算される様なプロダクション環境にモデルを投入するベストな方法とはどのようなものでしょうか？そして、5-10分のように短い周期あるいはニアリアルタイムで処理を行うにはどうしたらいいのでしょうか？これには、洗練されたETLパイプラインの構築、不正レコードを適切に識別することができる教師無し機械学習モデルのインテグレーションが含まれます。また、このエンドツーエンドのパイプラインは、プロダクションレベルである必要があり、データ取り込みからモデル推論に至るデータ品質を保証し、背後のインフラストラクチャを維持管理しなくてはなりません。
Databricksで機械学習に関わることを行う際には、機械学習(ML)ランタイムのクラスターが必須となります。MLランタイムでは、データサイエンスや機械学習に関連するタスクで一般的に使用される数多くのオープンソースライブラリがデフォルトで利用できます。scikit-learnはこれらのライブラリの一つであり、アイソレーションフォレストアルゴリズムの素晴らしい実装を提供しています。このランタイムによって、機械学習エクスペリメントのトラッキング、モデルのステージング、デプロイメントのためのノートブック環境とMLflowの密なインテグレーションが実現されます。MLクラスターにアタッチされたノートブック環境で行われる全てのモデルトレーニンやハイパーパラメーターの最適化処理は、デフォルトで有効化されているMLflowのオートロギングによって自動で記録されます。モデルが記録されると、さまざまな方法でMLflowのモデルを登録、デプロイすることが可能になります。特に、Apache Spark™による分散ストリーム、バッチ推論におけるベクトル化ユーザー定義関数(UDF)としてこのモデルをデプロイするために、以下の画像のように、MLflowはUDFを作成、登録するためのコードをユーザーインタフェース(UI)上に生成します。
AI FunctionsはビルトインのDB SQLの関数であり、SQLから直接の大規模言語モデル(LLM)へのアクセスを提供します。このローンチによって、馴染みのあるSQLインタフェースから皆様の企業のデータに対するLLMの実験をクイックに行えるようになります。適切なLLMプロンプトを開発したら、Delta Live Tablesやスケジュールされたジョブのような既存のDatabricksツールを活用したプロダクションパイプラインにクイックに転用することができます。これによって、LLMの開発、本格運用のワークフローの両方をシンプルにします。AI FunctionsはLLM呼び出しにおける技術的な複雑性を抽象化し、アナリストやデータサイエンティストは、背後のインフラストラクチャを気にすることなしに、これらのモデルを使い始めることができるようになります。
はい。大規模言語モデル(LLM)を管理、デプロイできる能力を拡張する革新的な機能が搭載された、このオープンソース機械学習プラットフォームの最新のアップデートであるMLflow 2.3が公開されました。この強化されたLLMサポートは以下を通じて提供されます:1. 3つの新たなモデルフレーバー: Hugging Face Transformers、OpenAI関数、LangChain, 2. モデルファイルのマルチパートのダウンロード、アップロードを通じたクラウドサービスとのモデルのダウンロード、アップロード速度の劇的な改善
はい、MLflow2.3で関数ベースのフレーバーによるOpenAI APIがサポートされるようになりました。OpenAI Pythonライブラリによって、Pythong言語で記述されたアプリケーションからOpenAI APIに簡単にアクセスできるようになります。これには、OpenAI APIリソースへのマッピングを行う一連の事前定義積みクラスが含まれています。これら提供されるクラスを用いることで、さまざまなバージョンのモデルやOpenAI APIエンドポイントに対して、動的に接続を初期化し、データを引き渡し、レスポンスを取得します。MLflow OpenAIフレーバーは以下をサポートしています: 1. 自動シグネチャスキーマ検知 2. 推論を加速するための並列APIリクエスト 3. レートリミットエラーのような一時的なエラーにおける自動APIリクエストリトライ
はい、MLflow2.3でサポートしています。MLflowのLangChainフレーバーは、質問応答システムやチャットボットのようなLLMベースのアプリケーションの構築やデプロイのプロセスをシンプルにします。LangChainの高度な機能と、MLflowの効率化された開発、デプロイサポートを活用することができます。
はい、Apache Spark 3.4では、SparkクラスターでのPyTorchの分散トレーニングを行えるように、TorchDistributorモジュールが追加されます。内部では、環境とワーカー間のコミュニケーションチャネルを初期化し、ワーカーノード横断で分散トレーニングを実行するために、CLIコマンドtorch.distributed.runを活用します。このモジュールは、シングルノードマルチGPUとマルチノードGPUクラスターの両方における分散トレーニングジョブをサポートしています。
databricks-dolly-15kは、ChatGPTの魔法のようなインタラクティブ性を大規模言語モデルが示せるようにするために、数千人のDatabricks従業員によって生成された15,000以上のレコードを含むコーパスです。Databricks従業員は、InstructGPTの論文で説明されている7つのカテゴリー、オープンエンドの自由記述カテゴリーを含む、8つの異なる指示カテゴリーのそれぞれでプロンプト/レスポンスを作成する取り組みに招待されました。コントリビューターは、Wikipedia以外のウェブのソースからの情報を使わないように指示され、指示やレスポンスを構成する際に生成型AIを使わないように明示的に指示されました。それぞれのカテゴリーに適切な質問と指示のタイプの動機づけを行うために、それぞれの挙動のサンプルが提供されました。データ生成プロセスの過程で、コントリビューターは他のコントリビューターによる質問に回答するオプションが提供されました。オリジナルの質問を言い換え、適切に回答できるだろうと予測できる質問のみを選択することが求められました。特定のカテゴリーでは、コントリビューターはWikipediaからコピーされた参照テキストを提供することが求められました。参照テキスト(実際のデータセットではcontextフィールドに示されています)には、括弧付きのWikipediaの引用番号(例 [42])が含まれることがあり、後段のアプリケーションではユーザーが削除することが推奨されます。
人間生成データ: Databricks従業員は8つの異なる指示カテゴリーのそれぞれでプロンプト/レスポンスのペアを作成する取り組みに容態されました。Wikipedia: アノテーターが参照テキストを必要とする指示カテゴリー(情報抽出、クローズドのQA、要約)においては、コントリビューターは特定の指示カテゴリーのサブセットにおいて、Wikipediaの文を選択しました。どのようにターゲットの文を選択するのかに関するガイドはアノテーターには与えられませんでした。
Dolly 2.0はEleutherAIのpythiaモデルファミリーをベースとした12Bのパラメーターを持つ言語モデルであり、Databricks従業員によってクラウドソースされた人間の手で生成された新たな高品質な指示追従データセットのみを用いてファインチューニングされています。我々は、すべて商用利用できるトレーニングコード、データセット、モデルの重みを含むDolly 2.0のすべてをオープンソース化します。これは、すべての組織がサードパーティにデータを共有したり、APIアクセスに支払いをすることなしに、人々と会話できるLLMを作成、所有、カスタマイズできることを意味します。
Dolly 1.0をリリースするやいなや、試したい方々からのリクエストが殺到しました。ナンバーワンの質問は「これを商用利用できますか？」でした。Dolly 1.0やその他の指示追従LLMを作成する重要なステップは、指示とレスポンスのペアを用いてモデルをトレーニングすることです。Dolly 1.0はスタンフォードのAlpacaチームがOpenAI APIを用いて作成したデータセットを用いて$30でトレーニングされました。このデータセットにはChatGPTのアウトプットが含まれており、スタンフォードチームが指摘しているように、利用条項はOpenAIと競合するモデルの作成を許可していません。このため、残念ですが、共通した質問に対する回答は「おそらくダメです！」でした。我々の知る限り、既存のよく知られた指示追従モデル(Alpaca、Koala、GPT4All、Vicuna)は、商用利用を禁ずるこの制限に苦しんでいます。この難問に対処するために、我々は商用利用できるような、まだ「トレーニング」されていない新たなデータセットを作成する方法を模索し始めました。
我々は、OpenAIの研究論文から、InstructGPTモデルは13,000個の指示追従の挙動を示す内容から構成されるデータセットでトレーニングされたことを理解しています。これからインスピレーションを得て、Databricks従業員が先頭に立つことで同様の成果を達成できないかを検討することにしました。結果として、13kの質問と回答を生成することは見かけよりも困難であることがわかりました。すべての回答はオリジナルではなくてはなりません。ChatGPTやウェブのどこかからコピーしてはならず、そうでないと我々のデータセットが汚染されることになります。うんざりするような話でしたが、DatabricksにはLLMに非常に興味を持っている5,000人以上の従業員がいます。そして、OpenAIの40人のラベル付け担当者よりも、さらに高品質なデータセットを作成するために、彼らの間でクラウドソースすることを検討しました。しかし、彼らはすべて多忙であり、山盛りの仕事を抱えていることを知っていましたので、これを行うためのインセンティブの方法が必要でした。我々は、トップ20のラベラーがすごい賞を受け取れるコンテストをセットアップしました。また、7つの固有のタスクを説明したました: 1. オープンなQ&A: 例えば、「なぜ人々はコメディ映画を好むのか？」や「フランスの首都は？」あるケースにおいては、これには明確な回答はなく、他のケースにおいては、図示や広範な世界に対する知識を必要とします。2. クローズドなQ&A: これは参照テキストの文に含まれる情報のみを用いて回答できる質問です。例えば、原子に関するWikipediaの段落に関して、「原子核における陽子と中性子の比率は？」と尋ねるというものです。3. Wikipediaからの情報抽出: ここでは、アノテーターはWikipediaから段落をコピーし、文からエンティティやその他の重みや測定結果のような事実情報を抽出します。4. Wikipediaからの情報の要約: ここでは、アノテーターにWikipediaの文が渡され、短い要約にまとめることが求められます。5. ブレーンストーミング: このタスクでは、終わりのないアイディエーションと可能性のあるオプションとの関連付けが求められます。例えば、「今週末に友達とできる面白いアクティビティは？」と言ったものです。6. 分類: このタスクでは、アノテーターはクラスのメンバーシップ(例: このアイテムは動物リスト、鉱物リスト、野菜リストに含まれますか)や、感情や映画レビューのような短い文のプロパティに対する判断を求められます。7. クリエイティブな記述: このタスクには、詩やラブレターの記述のようなものが含まれます。
Dolly 2.0の重みをダウンロードするには、シンプルにDatabricks Hugging Faceのページを訪れ、databricks-dolly-15k datasetをダウンロードするにはDolly repo on databricks-labsにアクセスしてください。そして、ご自身の組織でLLMを活用する方法を知るには、我々のウェビナーにご参加ください。
Databricksクラスターポリシーを用いることで、管理者は: 1. エンドユーザーのクラスター設定を制御することでコストを抑えることができます。2. エンドユーザーがクラスターを作成しやすくなります。3. コスト管理のためにワークスペース横断でタグを強制できます。また、3つの主要なユースケース向けに事前定義されたクラスターポリシーを提供します: パーソナルユース、共有利用、ジョブです。また、管理者は自分のポリシーをカスタマイズしたり、事前定義済みのポリシーを編集することができます。
一般的に、リアルタイムのストリーミングデータを取り扱う際、データの取り込み方法やアプリケーション全体がダウンタイムのような問題を体験するかどうかによって、イベント時間と処理時間の間には遅れが生じます。これらの潜在的に変動する遅延によって、このデータの処理に使用するエンジンには、いつ集計ウィンドウをクローズし、集計結果を生成するのかを決定するメカニズムが必要となります。生成したい集計結果を適切なものにするために、Sparkが集計ウィンドウをいつクローズし、適切な集計結果を生成するのかを理解できるようにウォーターマークを定義する必要があります。構造化ストリーミングアプリケーションにおいては、ウォーターマーキングと呼ばれる機能を用いることで、計算したい集計結果に適したすべてのデータが収集されるようにすることができます。基本的には、ウォーターマークを定義することで、Spark構造化ストリーミングは(一連の予想遅延期間に基づく)ある時点Tまでのすべてデータがいつ取り込まれたのかを認識することができるので、タイムスタンプTまでのウィンドウ集計をクローズし、結果を生成することができます。
Databricksが提供するプラットフォームの名称です。Databricksが作った造語であり、由来は従来型データプラットフォームであるデータウェアハウスとデータレイクであり、両者の長所を兼ね備えたプラットフォームであるという意味を込めてレイクハウスとしています。
データエンジニア、データサイエンティスト、SQLアナリスト、MLエンジニアなど機械学習/AIプロジェクトに関わる方すべてです。なお、SQL/Python/Rの知識を有している方を主たるユーザーとしていますが、最近ではシチズンデータサイエンティストの方向けの機能を提供するように機能を拡張しています。
Databricksはコントロールプレーンとデータプレーンから構成されています。コントロールプレーンには、DatabricksのAWSアカウント上でDatabricksが管理するバックエンドサービスが含まれます。あなたが実行する全てのコマンド(ノートブックのセル)は、完全に暗号化された状態でコントロールプレーンに存在することになります。保存されたコマンドはデータプレーンに格納されます。
 データプレーンはあなたのAWSアカウントで管理され、あなたのデータが格納される場所になります。また、ここでデータが処理されます。この図では、既にデータがDatabricksに登録されていることを仮定していますが、イベントデータ、ストリーミングデータ、IoTデータなど外部のデータソースからデータを取り込むことが可能です。Databricksコネクターを用いることで、あなたのAWSアカウント外の外部データソースにも接続することができます。
 あなたのデータは常に、データプレーンのあなたのAWSアカウントに存在します。このため、あなたのデータがロックインされることなく、常にフルコントロール、オーナーシップを維持することができます。
レイクハウスの根幹とも呼べるコンポーネントがDelta Lakeです。Delta Lakeはデータレイクの抱える課題を解決するために、データウェアハウスで培われた技術をデータレイクに提供します。
 データウェアハウスでは当たり前のACIDトランザクションをデータレイクで実現することで、データが不完全な状態になることを回避します。
 データベースで当たり前のスキーマ適用を行うことで、スキーマに合致しないデータの流入を防ぎます。
 データベースで培われたインデックス、パーティショニングをデータレイク上で実現することで、大規模データに対する高速な処理を実現します。
Databricksで取り扱うファイルは、Databricksのワークスペースを構築する際に指定した(1)S3バケット(DBFSルートバケットと呼ばれます)に格納されます。加えて、稼働しているクラスターの(2)ローカルストレージにファイルを保存することができますが、こちらはクラスターが停止すると全て失われます。
SaaSで提供されるDatabricksでは、インフラ管理の工数を劇的に引き下げることができます。1名の管理者で複数部門にサービスを提供した事例もあります。また、分析者はコラボレーション機能、プロジェクト管理機能を活用することで、少ない分析者リソースであっても複数のAIプロジェクトを回すことができます。
Jupyter notebookと比較したデータブリックスのメリットをご説明します。
 1. Jupyter notebookは主にEDAと機械学習モデル構築に焦点を置いていますが、データブリックスでは分析の前段のデータ加工からデータパイプラインの構築、モデルの構築からデプロイ、ひいては経営層向けに提示するBIレポート作成までもカバーしています。
 2. クリックだけの操作でSparkクラスターを起動することができます。フルバージョンのデータブリックスでは、任意のスペックのクラスターを構成でき、オートスケーリングを活用することができます。
 3. データベースのインストールが不要です。データブリックスでは最初からデータベースとしてHiveメタストアを利用できます。以下ではSQLを用いてデータベースを操作してみます。%sqlに関しては後ほどご説明します。
 4. リモートワークでのコラボレーションが簡単です。遠隔地であってもリアルタイム、時間差でのコミュニケーションを容易に行うことができます。
 5. データブリックスはノートブックに対する基本的なバージョン管理機能を提供します。画面右上のRevision historyから過去のノートブックを参照できます。それぞれのバージョンに対して、コメントの追加、復旧、バージョンの削除、バージョン履歴の削除を行うことができます。Githubのリポジトリと連携することもできます。
 6. プログラミング言語を柔軟に切り替えることができます。
 7. データを簡単に可視化できます。
 7. 大量データを高速に処理できます。
フルバージョンのデータブリックスと比較してコミュニティエディションには以下の制限があります。1. 作成できるクラスターは15GB RAM、2 Core CPUのシングルノードのみ, 2. ワークスペースに追加できるユーザー数は最大3名まで, 3. クラスターのリージョンはus-westのみ, 4. 使用できない機能, 5. ジョブのスケジュール機能, 6. クラスターのオートスケーリング機能, 7. Git連携, 8. MLflowの一部モデル管理機能(レジストリ、RESTサービング), 9. REST APIによるワークスペースの制御, 10. セキュリティ、ロールベースのアクセス制御、監査、シングルサインオン, 11. BIツール連携のサポート
Delta Lakeの他のトランザクションストレージレイヤーソフトウェアも類似の課題を解決するためのものですが、Delta Lakeはデータエコシステムにおけるより広いユースケースをカバーしています。データレイクに、信頼性だけでなく、高性能、セキュリティを追加し、バッチ処理、ストリーミング処理を統合するフレームワークを提供します。また、データ変換パイプラインの効率を改善するだけではなく、BI、データサイエンス、機械学習と言った下流のアクティビティの効率も改善できます。DatabricksのDelta Lakeを活用することで、Deltaエンジンによるよる良いパフォーマンス、きめ細かいアクセスコントロールによる高セキュリティ・ガバナンス、多くのBIツールに対する高性能ネイティブコネクターによるエコシステムの拡大と言った様々な恩恵を享受することができます。最後に、Delta Lakeは世界中の数千のお客様によって、3年以上の実運用に耐え続けている実績を持っています。毎日、少なくとも3ペタバイトのデータがDelta Lakeに投入されています。
Delta Lakeへのデータ追加は非常に簡単です。DatabricksオートローダーあるいはSQLのCOPY INTOコマンドを使って、既存のデータレイク(S3やADLS)にデータを追加するたびに自動でDelta Lakeにデータが追加されます。また、Apache Spark™を用いて、バッチでデータを読み取り、変換処理を行い、結果をDeltaフォーマットで書き込むということも可能です。
はい、Delta LakeはBIやレポート作成にも活用できます。特にこのデータ分析ユースケースに対応するために、我々は最近SQL Analytics(現在パブリックプレビュー)のリリースを発表しました。SQL Analyticsはデータレイクに直接アクセスして分析を行うBIユースケースに特化して設計されています。もし、データレイクに対してクエリを実行する多くのユーザーをお持ちなのであれば、SQL Analyticsに目を通して見ることをお勧めします。ビルトインされているクエリ、ダッシュボード機能を利用することもできますし、最適化されたネイティブコネクターを介して、既にお使いのBIツールを利用することも可能です。
はい、Delta Lakeは、あなたがお使いのデータセットに対するバージョン管理機能を提供します。これは、再現性の観点から非常に重要な機能です。あなたのモデルを特定のバージョンのデータセットに紐付けできることは非常に重要です。これによって、他のメンバーが検証目的でトレーニングを再現し、同じ結果が得られることを確認できます。つまり、全く同一のデータ、あなたがトレーニングに使用したのと全く同じバージョンのデータでトレーニングを再現できるようになります。Databricksにおけるデータサイエンス、機械学習に関してはこちらを参照ください。
Delta Lakeはデータレイクにあるファイルにおける特定のレコードを削除する機能を持っており、これはCCPAやGDPRのような規制に対して大きな意味を持ちます。対象を削除する際、ビジネスサイドは多くのケースでクラウドのオブジェクトストレージ上のデータまでも削除することを要求します。Databricksによってデータが管理されるDelta Lake管理テーブルを活用することで、削除処理はあなたのクラウドオブジェクトストレージまで伝播します。
はい、DatabricksのDelta Lakeに加えて、ワークスペースオブジェクト(フォルダー、ノートブック、エクスペリメント、モデル)、クラスター、プール、ジョブ、データスキーマ、テーブル、ビューなどに対して、アクセス権限を管理するアクセスコントロールリスト(ACL)を活用できます。管理者、あるいは権限が移譲されたユーザーがアクセスコントロールを制御できます。Databricksにおけるデータガバナンスのベストプラクティスに関しては、こちらを参照ください。https://docs.databricks.com/data-governance/best-practices.html
Delta Lakeにおいては、バッチ、ストリーミング処理の両方を実行することができ、複雑性、冗長性、運用の課題を回避してアーキテクチャをシンプルにできます。Delta Lakeのテーブルはバッチ処理におけるテーブル、ストリーミング処理のソースとシンクになることができます。ストリーミングによるデータの投入、バッチによる履歴データの補完、インタラクティブなクエリ全てがDeltaテーブルで動作し、直接Sparkの構造化ストリーミングと統合できます。
 以上がイベントにおいてお客様からいただいた質問のほんの一部です。ライブイベントに参加された方には、スケーラブルかつコスト効率の高いレイクハウスの基盤であるDelta Lakeを学ぶ時間を割いていただいたことを感謝します。参加されなかった皆様においては、レコーディングを参照いただければと思います。
Delta Lakeは、お使いのデータレイクに信頼性、セキュリティ、パフォーマンスをもたらすオープンフォーマットのストレージレイヤーであり、ストリーミング処理、バッチ処理の両方に対応しています。Delta Lakeは、分析をシンプルにし、企業全体でデータにアクセスできるようにするために、構造化、準構造化、非構造化データに対する単一の場所を提供することでデータのサイロ化を排除します。最終的には、Delta Lakeはコスト効率の良い、高度にスケーラブルなレイクハウスアーキテクチャの基盤かつイネーブラとなります。
Delta Lakeと名付けた理由は二つあります。最初の理由は、Delta Lakeはデータに対する、変更あるいはdelta(差分)を追跡し続けます。第二の理由は、Delta Lakeはお使いのデータレイクに流れ込むデータをフィルタリングする「デルタ(三角州)」として動作するからです。
はい、それを行うためには、オープンソースのSparkとDelta Lakeをインストールします。DatabricksのDelta Lakeは、Databricksでのみ利用できるDeltaエンジンによって、オープンソースのDelta Lakeより高速なものとなっています。詳細はこちらの記事を参照ください。
Delta Lakeで使用されるファイルフォーマットは、parquetとJSONの組み合わせであるdeltaと呼ばれるものです。Delta Lakeのテーブルは、テーブルのコンテンツとトランザクションログ(およびチェックポイント)のデータオブジェクトを保持するクラウドオブジェクトストア、あるいはファイルシステム上のディレクトリです。
Databricks SQLは、データレイク上のDelta Lakeテーブルにクエリーを実行できる、馴染みのあるSQLベースの環境を使用する、データアナリスト専用の新たなワークスペースです。Databricks SQLは完全に独立したワークスペースなので、データアナリストはノートブックベースのデータサイエンスツール(実際、データサイエンティストはSQLエディタで作業することも好みますが)に悩まされることなしに、Databricksのプラットフォームで直接作業することができます。しかし、データアナリストとデータサイエンティストは同じデータソースで作業をするので、全体的なインフラストラクチャは非常に簡素化され、信頼できる唯一の情報源を維持することができます。
 Databricks SQLで以下のことが可能となります。
 1. データレイク上の完全かつ最新なデータに対してクエリーが行えるように、お使いのTableau、Microsoft Power BIのようなBIツールとの統合。
 2. Databricksでデータアナリスト、データサイエンティストが直接データレイクにクエリーできるようにするための、既存のBIツールを補完するSQLネイティブのインタフェース。
 3. データにおける重要な変化に関するアラート、豊富なビジュアライゼーションとドラッグ&ドロップによるダッシュボードを通じたクエリーの共有。
 4. 最新かつ完全なデータを用いた従来の分析ワークロードをサポートするために、お使いのデータレイクに高信頼、高品質、スケーラビリティ、セキュリティ、パフォーマンスを提供
Databricks SQL、Delta、そして(パフォーマンスを含む)レイクハウスアーキテクチャを学ぶためには、こちらの無料のトレーニングをチェックしてください。トレーニングでは、データ管理の進化とレイクハウスを学びます。このモデルを用いることで、どのようにして、信頼できる唯一の情報源に支えられた、高性能のストリーミング、データサイエンス、機械学習、BIが統合されたシステムをデータチームが活用できるのかを説明します。
 このセッションのハンズオンでは、統合されたSQLエディタ、ダッシュボードツールであるDatabricks SQLを活用できるのかを学びます。お客様の会社のデータに対してどれだけ容易にクエリーを実行できるのか、ダッシュボードを構築できるのかを探索します。そして、Databricks SQLが、レイクハウスインフラストラクチャにおいて、どのようにデータが使用され、アクセスされたのかに関して、きめ細かい可視性を提供するのかを理解することができます。
クラウドベースのHadoopプラットフォームをDatabricksレイクハウスプラットフォームに移行する理由は７つあります。

以下に、

レイクハウスプラットフォームでご自身のアーキテクチャをシンプルに
集中管理されるデータガバナンスとセキュリティ
すべてのデータワークロードにおける最高のパフォーマンス
生産性の改善とビジネス価値の向上
データとAIによるイノベーションの促進
クラウドに依存しないプラットフォーム
Databricksパートナーエコシステムのメリット
DatabricksのWebターミナルは、Sparkドライバーノードでシェルコマンドを実行したり、VimやEmacsのようなエディタを使用できる便利で高度にインタラクティブな手段を提供します。SSHの使用とは異なり、Webターミナルは、一つのクラスターで多数のユーザーによって使用でき、キーのセットアップは不要です。Webターミナルの使用例には、リソース使用量の監視やLinuxパッケージのインストールが含まれます。
Databricksでは、Sparkジョブを阻害することなしに不正なレコードやファイルを取り扱うための統合インタフェースを提供しています。データソースのオプションbadRecordsPathを指定することで、例外のログから例外レコード/ファイルや理由を取得することができます。badRecordsPathでは、CSVやJSONソースにおける不正レコードに関する情報やすべてのファイルベースのビルトインソース(Parquetなど)の不正ファイルを記録する例外ファイルのパスを指定します。

さらに、ファイルを読み込む際、ネットワーク接続例外、IO例外などの一時的なエラーが起きる場合があります。これらのエラーは無視されますが、badRecordsPathで記録され、Sparkはタスクの実行を継続します。

注意
ファイルベースのデータソースにおけるbadRecordsPathオプションの使用においては、いくつか重要な制限が存在します。

非トランザクションであり、一貫性の無い結果につながる場合があります。
一時的なエラーは失敗として取り扱われます。
ノートブック上でmlflow.start_run()コマンドを実行した場合、ランはアクティブなエクスペリメントにメトリクスやパラメーターを記録します。アクティブなエクスペリメントが存在しない場合、Databricksはノートブックエクスペリメントを作成します。ノートブックエクスペリメントは対応するノートブックと同じ名前とIDを持ちます。ノートブックのURL(英語)の最後にある数字のIDがノートブックIDです。
エクスペリメントには2種類あります。ワークスペースエクスペリメントとノートブックエクスペリメントです。

MLflow APIかワークスペースUIからワークスペースエクスペリメントを作成できます。ワークスペースエクスペリメントはノートブックに紐付けられておらず、いかなるノートブックでもエクスペリメントIDかエクスペリメント名を指定することでランをこれらのエクスペリメントに記録することができます。
ノートブックエクスペリメントは特定のノートブックに紐付けられています。mlflow.start_run()を実行した際にアクティブなエクスペリメントが存在しない場合には、Databricksは自動でノートブックエクスペリメントを作成します。
データベースにあるデータに対するすべての操作が行えると言っても過言ではありません。できることが多岐に渡るため、ある程度の分類がされています。

DDL(Data Definition Language)
データベース、テーブルなどを作成、削除します
CREATE/DROP/ALTER
DML(Data Manipulation Language)
テーブルを検索したり、変更します
SELECT/INSERT/UPDATE/DELETE
DCL(Data Control Language)
テーブルに対する権限設定などを行います
GRANT/REVOKE
SQLでの更新処理には以下の注意事項があります。
誤ってデータを消してしまった、上書きしてしまったということを避けることは正直困難です。
そんな場合に頼りになる機能があります。Delta Lakeのタイムトラベルです。
ここまで操作してきたテーブルの実態はDelta Lakeというソフトウェアによって実装されているものです。
Delta Lakeはトランザクション保証、インデックスなどの機能がサポートされていますが、上の様なケースで役立つのがデータのバージョン管理であるタイムトラベルです。
Delta Lakeのテーブルに実行される更新処理はすべて記録され、任意のタイミングにロールバックすることができます。
英語の文法としてSQLを読むと理解しやすいです。

SQLの柔軟性は素晴らしいものですが、その代償としていくらでも複雑になり得ます。
複雑なSQLを理解するには、
フォーマットして可読性を上げ、
英語の文を読む語順 (SELECT -> FROM -> WHERE -> GROUP BY -> HAVING -> ORDER BY) でブロックを把握し、
FROMに記述されているテーブルから、
WHEREに記述されている抽出条件に基づいてレコードを抽出し、
GROUP BYに指定されている集約キーでグルーピングし、
HAVINGに記述されている条件に基づいてグループを絞り込み、
ORDER BYに指定されているソートキーで並び替えて、
SELECTに指定されている列
を取得する。
Databricksでは、以下のメリットを享受いただきながらSQLを活用いただくことができます。
Databricks SQL
ノートブックでのSQLサポート
SQLの結果をダッシュボード、機械学習などとシームレスに連携
並列分散処理による高速化
高度な要件に答えるSQL拡張
MLflowは機械学習モデルのライフサイクル管理のためのフレームワークを提供するソフトウェアです。機械学習のトラッキング、集中管理のためのモデルレジストリといった機能を提供します。Databricksでは、マネージドサービスとしてMLflowを利用できる様になっていますので、Databricksノートブック上でトレーニングした機械学習は自動でトラッキングされます。
Apache Sparkは、大規模なデータの高速リアルタイム処理を実現するオープンソースのクラスタコンピューティングフレームワークです。大量なデータを並列で処理することで、非常に高いパフォーマンスを発揮することができます。データ加工だけでなく、機械学習モデルのトレーニングやハイパーパラメーターチューニングを並列処理することが可能です。
Delta Lakeはデータレイクに格納されているデータに対して高速なデータ処理、強力なデータガバナンスを提供するストレージレイヤーソフトウェアです。ACIDトランザクションやデータのバージョン管理、インデックス作成機能などを提供します。機械学習の文脈ではデータのバージョン管理が重要な意味を持つことになります。
SQLコマンド「CONVERT TO DELTA」を利用して、ParquetやIcebergテーブルのDelta Lakeテーブルへの変換処理を実行します。ParquetやIcebergテーブルのDelta Lakeへのインクリメンタルな変換に関しては、ParquetやIcebergからDelta Lakeへのインクリメンタルなクローンをご覧ください。https://qiita.com/taka_yayoi/items/bc3edb691c6f1fc7c79a
以下のシチュエーションにおいてParquetやIcebergを取り込む際にクローンを使用することをお勧めします。
ParquetやIcebergからDelta Lakeへのマイグレーションを実施しているが、ソーステーブルを使い続ける必要がある。
追加、更新、削除がなされるプロダクションソーステーブルとターゲットテーブル間の取り込みのみ動機を維持する必要がある。
レポーティング、機械学習、バッチETLにおけるソースデータのACID準拠のスナップショットを作成したいと考えている。
注意
ソーステーブルという用語は、クローンされるテーブルとデータファイルを指し、ターゲットテーブルはオペレーションによって作成、更新されるDeltaテーブルを指します。
ParquetやIcebergに対するクローンは、Deltaテーブルのクローンに使うものと同じ基本構文を使用し、シャロークローンとディープクローンをサポートしています。
 多くのワークロードにおいてインクリメンタルなクローンを用いることをお勧めします。ParquetやIcebergに対するクローンではSQL構文を使用します。
注意
ParquetやIcebergに対するクローンでは、Deltaのクローンや変換とは異なる要件、保証となります。ParquetやIcebergテーブルのクローンの要件と制限をご覧ください。
ディープクローンにしてもシャロークローンにしても、クローンが実行された後にターゲットテーブルに適用された変更は、ソーステーブルに同期されません。クローンによるインクリメンタルな同期は一方向であり、ソーステーブルに対する変更は自動でターゲットのDeltaテーブルに適用されます。

ParquetやIcebergテーブルに対するクローンを使用する際には、以下の制限も適用されます。

このオペレーションでは、ファイルレベルの統計情報は収集しません。このため、ターゲットテーブルではDelta Lakeのデータスキッピングのメリットを享受することができません。
クローンする前に、パーティションを持つParquetテーブルをHiveメタストアのようなカタログに登録し、ソーステーブルと同じテーブル名を使用しなくてはなりません。パーティションを持つParquetテーブルに対してパスベースのクローン構文を使用することはできません。
パーティション進化をおこなったIcebergテーブルをクローンすることはできません。
Icebergテーブルにはパスのみを用いてアクセスすることができます。テーブル名はサポートされていません。
Unity Catalogではシャロークローンをサポートしていません。
Unity Catalogでは、外部テーブルで多くのフォーマットをサポートしていますが、マネージドテーブルではDelta Lakeのみをサポートしています。マネージドのParquetテーブルを直接Unity CatalogのマネージドDelta Lakeテーブルに変換するには、テーブルをUnity Catalogにアップグレードするをご覧ください。

外部ParquetテーブルをUnity Catalogにアップグレードするには、外部テーブルをUnity Catalogにアップグレードするをご覧ください。

外部ParquetテーブルをUnity Catalogに登録すると、それを外部Delta Lakeテーブルに変換することができます。Parquetテーブルがパーティショニングされている場合には、パーティショニング情報を指定しなくてはならないことに注意してください。
Databricksではデフォルトですべての読み書きにDelta Lakeを使用しており、オープンソースのDelta Lakeプロトコルによって提供されるACID保証の上に成り立っています。

原子性(Atomicity)とは、すべてのトランザクションが完全に成功するか、完全に失敗するかのいずれかになることを意味します。
一貫性(Consistency)は、同時のオペレーションにおいて、ある状態のデータがどの様に観測されるのかに関して保証します。
分離性(Isolation)は同時のオペレーションが違いにどの様に競合するのかに関するものです。
耐久性(Durability)はコミットされた変更が永続的であることを意味します。
多くのデータ処理、ウェアハウジングの技術ではACIDトランサクションがあると言及されていますが、特定の保証内容はシステムによって異なり、Databricksにおけるトランザクションは皆様が使われている他のシステムとは異なる場合があります。
Databricksではテーブルレベルでトランザクションを管理します。トランザクションは常に一度に一つのテーブルに対して適用されます。同時実行されるトランザクションを管理するために、Databricksでは楽観的コンカレンシー制御を使用します。これは、テーブルの読み書きにおいてロックを行わず、デッドロックが発生しないことを意味します。

デフォルトでは、Databricksでは読み込みにおいてはスナップショットのアイソレーション、書き込みにおいてはwrite serializableのアイソレーションを提供します。Write serializableアイソレーションは、スナップショットのアイソレーションよりも強力な保証を行いますが、書き込み時にのみこの強力なアイソレーションを適用します。

複数のテーブルを参照する読み込みオペレーションは、アクセス時の現行テーブルバージョンを返却しますが、参照しているテーブルを変更する可能性がある同時実行されているトランザクションに干渉しません。

Databricksでは複数のオペレーションを一つのトランザクションにグループ化できるBEGIN/END構文は提供していません。複数のテーブルを変更するアプリケーションは、直列化された形でそれぞれのテーブルにトランザクションをコミットします。MERGE INTOを用いることで、テーブルに対するインサート、アップデート、デリートを一つの書き込みトランザクションにまとめることができます。
トランザクションログがコミットの原子性を制御します。トランザクション中は、テーブルを構成するファイルディレクトリにデータファイルが書き込まれます。トランザクションが完了すると、トランザクション中に書き込まれたすべてのファイルへのパスを含む新規エントリーがトランザクションログにコミットされます。それぞれのコミットはテーブルバージョンを増加させ、読み込みオペレーションで新たなデータファイルが参照できる様になります。テーブルの現在の状態は、トランザクションログにおいて適正とマークされたすべてのファイルから構成されます。

トランザクションログが新規バージョンを記録しない限り、データファイルは追跡されません。テーブルにデータファイルを書き込んだ後にトランザクションが失敗すると、これらのデータファイルがテーブルの状態を破損させることはありませんが、このファイルはテーブルの一部とはなりません。VACUUMオペレーションは、失敗したトランザクションによる未コミットのファイルを含む未追跡のデータファイルの全てを削除します。
Databricksでは、すべてのデータファイルとトランザクションログを格納するためにクラウドオブジェクトストレージを使用します。クラウドオブジェクトストレージは高い可用性と耐久性を提供します。トランザクションは完全に成功するか完全に失敗するかのいずれかであり、クラウドオブジェクトストレージに格納されるデータファイルとともにトランザクションログが存在し、Databricksのテーブルは格納されているクラウドオブジェクトストレージの耐久性保証を受け継ぎます。
Delta Lakeは書き込みにおけるトランザクション保証を提供するために、楽観的コンカレンシー制御を使用します。この機構のもとで、書き込みは3つのステージでオペレーションされます

読み込み: どのファイルを修正(再書き込み)する必要があるのかを特定するために、利用できる最新バージョンのテーブルを(必要であれば)読み込みます。
追加のみを行う書き込みは、書き込み前にテーブルの現在の状態を読み込みません。スキーマの検証ではトランザクションログのメタデータを活用します。
書き込み: テーブルの定義で使用されているディレクトリにデータファイルを書き込みます。
検証とコミット:
スナップショットを読み込んだ以降、同時処理でコミットされた他の変更と提案された変更が競合しないかどうかをチェックします。
競合しない場合、ステージングされたすべての変更は新規バージョンのスナップショットとしてコミットされ、書き込みのオペレーションが成功します。
競合する場合、同時実行更新の例外で書き込みオペレーションが失敗します。失敗することによってデータの破損を防ぎます。
楽観的コンカレンシーは、皆様のデータに対する同時実行トランザクションの多くが他のトランザクションと競合しないが、競合は起こりうるものであるという前提に立っています。Databricksにおけるアイソレーションレベルと書き込みの競合をご覧ください。
Databricksでは、デフォルトですべてのテーブルへの書き込み、更新でwrite serializableアイソレーションを使用します。すべてのテーブル読み込みでは、スナップショットアイソレーションが使用されます。

書き込みの高スループットを実現するために、書き込みのシリアライズ可能性と楽観的コンカレンシー制御が連携して動作します。現行の適正なテーブルの状態が常に利用でき、任意のタイミングでテーブルの書き込みをスタートすることができます。同時実行される読み込み処理は、メタストアとクラウドリソースのスループットによってのみ制限を受けます。
取り込み時間クラスタリングは、データ取り込みを行う時間に基づいた自然なクラスタリングを可能にするDatabricksの書き込みの最適化機能です。取り込み時間クラスタリングによって、テーブルのクラスタリングは取り込み時間によってメンテナンスされ、日付や時間でフィルタリングするクエリーにおけるデータスキッピングによって、劇的なクエリーパフォーマンスの改善を実現し、クエリーに回答するために読み込む必要があるファイルの数を劇的に削減します。これを行うことで、時系列ファクトテーブルのレイアウトを最適化するためにお客様は作業することなしに、すぐに素晴らしいデータスキッピングを活用できる様になります。
現時点では、お客様は優れたパフォーマンスのためにデータレイアウトを最適化するために2つのパワフルなテクニックを利用することができます。パーティショニングとz-orderingです。データレイアウトに対するこれらの最適化技術によって、クエリーが読み込む必要があるデータ量を劇的に削減し、オペレーションごとにテーブルのスキャンに必要な時間を削減することができます。

パーティショニングやz-orderingから得られるクエリーパフォーマンスは大きなものではありますが、いくつかのお客様においては、これらの最適化技術を実装、メンテナンスすることが困難となっていました。多くのお客様は、どのカラムを使用するのか、自分達のテーブルに対してz-orderを実行するかどうか、どの程度の頻度で実行するのか、パーティショニングが有用なのか、害を及ぼすのがいつなのかに関する質問を持っています。これらのお客さまの懸念を解決するために、我々はユーザーのアクション無しにこれらの最適化技術を提供することを目指しました。
ベンチマークを行うために、大規模オンライン小売業者と取り組みを行い、彼らの分析データを表現するベンチマークを作成しました。このお客様のシナリオにおいては、売上が発生するたびに売上レコードが生成され、ファクトテーブルに取り込まれます。このテーブルに対するクエリーの多くは、多くの時間ベースの分析ワークロードでは共通のパターンにあるように、特定の時間ウィンドウで集計された売上レコードを返却します。このベンチマークでは、新規データ取り込みの時間、DELETEオペレーションの実行時間、さまざまなSELECTクエリーを計測し、取り込み時間クラスタリングにおけるクラスタリング保持機能を検証するために、全てを逐次実行しました。

クラスタリングの保持に追加の処理があるにもかかわらず、取り込み時間クラスタリングによる性能劣化は認められませんでした。一方、DELETEとSELECTクエリーでは劇的なパフォーマンス改善が認められました。取り込み時間クラスタリングなしでは、DELETE文は意図したクラスタリングを解体することで、データスキッピングの効果を削減し、ベンチマークにおける以降のSELECT文のパフォーマンスをスローダウンさせました。取り込み時間クラスタリングが保持されることで、SELECTクエリーは平均19倍パフォーマンスが改善され、オリジナルの取り込み順で意図されたクラスタリングを保持することで、テーブルのクエリーに必要な時間を劇的に削減しました。
サーバレスリアルタイム推論エンドポイントは、プロダクション用途を意図しており、秒間3000クエリー(QPS)までをサポートすることができます。サーバレスリアルタイム推論エンドポイントは、自動でスケールアップ・ダウンするので、エンドポイントはスコアリングのリクエストのボリュームに応じて自動で調整することを意味します。リクエストがない際にはノード数を0にまでスケールダウンすることも可能です。
いくつのパターンがあります。2つの一般的なパターンを説明します。一つ目はコード・デプロイです。このパターンにおいては、モデルをトレーニングするコードは開発環境で開発でされます。同じコードがステージング、プロダクションに移行します。モデルはそれぞれの環境でトレーニングされます: 最初はモデル開発の一部として開発環境でトレーニングされ、インテグレーションテストの一部としてステージングで(限定的なデータのサブセットに対して)トレーニングされ、プロダクション環境では最終モデルを生成するために(完全なプロダクションデータに対して)トレーニングされます。二つ目はモデルのデプロイです。このパターンでは、モデルアーティファクトは開発環境のトレーニングコードによって生成されます。アーティファクトはプロダクションにデプロイされる前に、ステージング環境でテストされます。
MLOpsのコードデプロイというアプローチの利点:

プロダクションデータへのアクセスが制限されている企業においては、このパターンを用いることでプロダクション環境のプロダクションデータを用いてトレーニングを行うことができます。
トレーニングコードはプロダクションに向けてレビュー、テスト、承認されるので、自動モデル再トレーニングはより安全になります。
サポートするコードはモデルトレーニングコードと同じパターンに従います。両方ともステージングのインテグレーションテストを通ることになります。
MLOpsのコードデプロイというアプローチの欠点：関係者にコードを受け渡すためのデータサイエンティストの学習曲線は急峻なものになります。事前定義済みのテンプレートやワークフローが役立ちます。また、このパターンにおいては、データサイエンティストはML固有の問題を特定、修正できる知識を持っているので、プロダクション環境からトレーニング結果をレビューできる様になっている必要があります。
以下の条件が一つ以上当てはまる場合には、モデルデプロイのアプローチを検討すべきです。

モデルのトレーニングが非常に効果、あるいは再現が困難。
単一のDatabricksワークスペースで全ての作業が行われた。
外部のリポジトリやCI/CDプロセスを使っていない。