bowang0911/databricks-qa-ja huggingface dataset:
Auto Loaderは新規ファイルを検知するための2つのモードがあります。ファイル通知とディレクトリ一覧です。

ファイル通知: Auto Loaderは入力ディレクトリからのイベントをサブスクライブする通知、キューサービスを自動でセットアップすることができます。ファイル通知モードは高性能であり、大量のファイルを格納する入力ディレクトリにスケールすることもできますが、追加のクラウドのアクセス権が必要となります。このオプションは、ファイルが語順に到着しない場合には好適なものとなり、キューや通知の明示的なセットアップを不要のものにします。このモードを有効化するには、オプションcloudFiles.useNotificationsをtrueに設定し、クラウドリソースを作成するのに必要なアクセス権を指定します。ファイル通知の詳細についてはこちらを参照ください。

ディレクトリ一覧: 新規ファイルを特定する別の方法は、Auto Loaderで設定された入力ディレクトリを一覧するというものです。ディレクトリ一覧モードを用いることで、データへのアクセス権以外の権限なしにAuto Loaderのストリームを起動することができます。Databricksランタイム9.1以降では、Auto Loaderはクラウドストレージにファイルが語順に到着しているかどうかを自動で検知し、新規ファイルを検知するのに必要なAPI呼び出しの総数を劇的に削減します。デフォルトモードでは、7回の連続したインクリメンタルなディレクトリ一覧の後に完全なディレクトリの一覧を行います。しかし、設定cloudFiles.backfillIntervalを用いることで、完全なディレクトリ一覧の頻度を調整することができます。設定cloudFiles.useIncrementalListingを用いることで、インクリメンタルな一覧を明示的にオンオフすることができます。明示的にこの設定が有効化されると、Auto Loaderは完全な一覧をトリガーしません。ディレクトリ一覧の詳細に関しては、こちらをご覧ください。

新規ファイルが発見されると、それらのメタデータはAuto Loaderパイプラインのチェックポイントの格納場所にあるスケーラブルなキーバリューストア(RocksDB)に永続化されます。これは、これまでに処理したファイルの履歴を保持する状態情報として動作します。このパイプラインは、既存ファイルを格納するディレクトリに対するバックフィルとファイル通知を通じて発見される新規ファイルの同時処理の両方を実行します。
Databricksのローシャッフルマージは、修正されていない行と修正された行を一緒に処理するのではなく、より整流化された別の処理モードで変更されていない行を処理することで優れたパフォーマンスを提供します。これによって、シャッフルされるデータの量が劇的に削減され、パフォーマンスの改善につながります。また、ローシャッフルマージはMERGEオペレーションを実行した後にユーザーがOPTIMIZE ZORDER BYコマンドを再実行する必要性も削減します。
ソースデータセットのディープコピー、シャローコピーを作成するために、Databricksでテーブルをクローンすることができます。
コストベースのオプティマイザは、テーブルの統計情報を活用することで、クエリーパフォーマンスを高速にします。
最適化書き込みと自動ファイルコンパクションを用いることでDeltaテーブルを自動で最適化することができます。これは特に長時間処理を行う構造化ストリーミングジョブでは有用です。
高階関数は、一般的なSparkオペレーターを持たない多くのオペレーションに対して、ビルトインかつ最適化されたパフォーマンスを提供します。高階関数はユーザー定義関数よりも高いパフォーマンスのメリットを提供します。
Databricksでは、配列、struct、JSON文字列を含む複雑なデータ型を操作するためのビルトインのオペレーターと特殊な構文を数多く提供しています。
レンジを含む、あるいは、大きな偏りを持つjoinの設定を手動でチューニングすることができます。
PythonでMLflowトラッキングを使い始める最も簡単な方法は、MLflowのautolog() APIを使うことです。それぞれのトレーニングランにおいて記録するメトリクスを制御したい、あるいは、テーブルやプロットの様な追加のアーティファクトを記録したい場合には、このノートブックで説明されている様にmlflow.log_metric()やmlflow.log_artifact() APIを使うことができます。
機械学習モデルを作成する際に、mlflow.log_param()、mlflow.log_metric()、mlflow.log_model()、mlflow.log_artifact()を用いて、モデル、モデルのパラメーター、評価メトリクス、その他のアーティファクトを記録します。これらの機能によって、どのパラメーター、メトリクスを記録するのかを正確に制御することができ、テーブルやプロットの様なランの他のアーティファクトを記録することもできます。
H3は同名のグローバルインデクシングシステムとライブラリとなります。もともとは、空間データパターンを可視化、探索する目的においてUberによって開発されました。グリッドシステムは、表面(この場合は地球の表面)のモザイクを形成するために長方形や三角形の様なシェイプをしようします。階層型グリッドシステムは、異なる解像度でモザイクを形成します(基本的なシェイプは異なるサイズで提供されます)。H3システムは、六角形(一部五角形)を使用する様に設計され、そして階層型システムとして異なる16の解像度を操作することができます。特定の解像度でデータをインデクシングすると、分析に使用する1つ以上のH3のセルIDが生成されます。例えば、解像度15のH3セルは約1m2
�
2
(異なるH3の解像度の詳細についてはこちらをご覧ください)をカバーします。
H3システムを用いることで、膨大な量のデータを理解できる様になります。例えば、大規模なNYCのタクシー乗降データセットを用いることで、空間的なパターンをより理解するためにデータを空間的に集計することができます。10億以上のオーバーラップするデータを見たとしても、パターンを特定することはできませんが、H3を活用することで即座にパターンが明らかになり、さらならる探索に取り組める様になります。
エントリーポイントは時系列データフレーム(TSDF)のオブジェクトとなります。タイムスタンプのカラムは必須となります。パーティション、シーケンスカラムはオプションですが、自動特徴量生成を含むさまざまなユースケースで役立ちます。TSDFを用いることで、いくつかのネイティブな機能を活用できる様になります。

Asof join - ソーステーブルの最新のレコードをselectし、ベースのファクトテーブルにマージするためにウィンドウを使用します。
移動平均 - Approximate Exponential Moving AverageとSimple Moving Averageを利用できます。
再サンプリング - 頻度に基づくアップサンプリングと集計関数
データフレームとタイムスタンプのカラム、オプションで1つ以上のパーティションカラム、シーケンスカラムを指定する必要があることがわかります。タイムスタンプカラムはソートに使用されます。オプションのパーティションカラムやシーケンスカラムは特徴量生成に使用されます。タイムスタンプカラムは文字列である必要がありますが、パーティションカラムは文字列あるいは文字列のリストである必要があります。

TSDFをDeltaテーブルに書き込む際には、write関数を呼び出してTDSFとSparkのコンテキスト、Deltaテーブル名と最適化のためのカラム(あれば)を指定します。これによって内部でDeltaテーブルに書き込みが行われます。
Databricksにおけるルートパスは、実行されるコードによって異なります。

DBFSルートはSparkとDBFSコマンドのルートパスとなります。これには以下が含まれます。

Spark SQL
Sparkデータフレーム
dbutils.fs
%fs
ドライバーにアタッチされるブロックストレージボリュームは、ローカルで実行されるコードのルートパスとなります。
以下では、DatabricksランタイムのFUSEにおけるローカルファイルAPI使用時の制限を列挙します。

クライアントサイド暗号化が有効化されたAmazon S3マウントをサポートしていません。
ランダムの書き込みはサポートしていません。ランダムの書き込みが必要となるワークロードにおいては、以下のようにローカルディスクでオペレーションを行い、/dbfsに結果をコピーするようにしてください。
DBFSは、クラウドオブジェクトストレージのURIを相対パスにマッピングすることで以下のようなメリットを提供します。

クラウド固有のAPIコマンドではなく、ディレクトリとファイルのセマンティクスを用いてオブジェクトストレージを操作できるようになります。
ストレージの資格情報をDatabricksワークスペースのパスにマッピングできるように、クラウドオブジェクトストレージのロケーションをマウントできるようになります。
オブジェクトストレージにファイルを永続化するプロセスをシンプルにし、クラスター停止時に、安全に仮想マシンとアタッチされたボリュームを削除できるようになります。
クラスター初期化のためのinitスクリプト、JAR、ライブラリ、設定情報を格納する便利なロケーションを提供します。
OSSのディープラーニングライブラリを用いたモデルトレーニングの過程で、チェックポイントファイルを保存する便利なロケーションを提供します。
HorovodRunnerを用いた分散トレーニングプログラムを開発する一般的なアプローチは以下の通りとなります。

ノードの数を用いて初期化されたHorovodRunnerインスタンスを作成します。
Horovod usageで説明されている方法に従って、Horovodのトレーニングメソッドを定義し、メソッド内にimport文を追加するようにします。
HorovodRunnerインスタンスにトレーニングメソッドを引き渡します。
ダウンロードサイトからライセンス条項に基づいて無料でダウンロード、使用することができます。Hugging Faceは、AIコミュニティがセマンティックサーチと呼ぶもので理想的な(大規模あるいはそれ以外の)言語モデルを見つけ出すのに人気の場所です。
エンベディングとは文章、段落、文書の数値表現です。これらがどのよう精製されるのかに関するメカニズムはモデルの中に埋め込まれていますが、理解すべき重要なことはモデルが2つの文書をエンベディングに変換する際、数値間の数学的な距離(違い)はそれらの類似度を伝えてくれることになります。
オープンソースのlangchainのようなツールは、このためのビルディングブロックを提供します。理解すべきことは、検索したいと考えている商品カタログの詳細を形成するエンベディングは、従来型のリレーショナルデータベースやNoSQLデータストアからは検索できないということです。代わりに特殊なベクトルストアを活用する必要があります。
マイクロサービスは検索フレーズのようなリクエストを受け取り、レスポンスを返す軽量アプリケーションです。モデルとマイクロサービス内で検索するエンベディングをパッケージすることで、提供する検索機能を多くのアプリケーションからアクセスできるようにするだけではなく、多くのマイクロサービスインフラストラクチャソリューションは弾力性のあるスケーラビリティを提供しているので、需要の増減に追従できるようにサービスにリソースを割り当てることができます。
Anaconda の利用規約を確認し、商用ライセンスが必要かどうかを判断してください。
有効なライセンスがあることを確認したら、Conda でパッケージをインストールまたは更新するためのチャネルを指定する必要があります。-c <name-of-channel>で Conda チャネルを指定できます。
たとえば、%conda install matplotlib ではエラーを返しますが、%conda install -c defaults matplotlib はmatplotlibをインストールできます。
通常、SparkML のモデルは、パイプラインの最終ステージとして適合します。ツリー モデルを使用してパイプラインから関連する特徴量情報を抽出するには、正しいパイプライン ステージを抽出する必要があります。VectorAssemblerオブジェクトから特徴量の名前を抽出できます。
パイプラインの最終ステージでクロス バリデーターを使用して、ツリーベースのモデルをチューニングすることもできます。CrossValidatorオブジェクトからbestModelを抽出し、デシジョン ツリーを視覚化し、特徴量の重要度レベルを出力することができます。
Display機能は、決定木モデルのみを視覚化することができます。
多くの場合、SparkML モデルまたはパイプラインをフィッティングする際のエラーは、トレーニング データの問題が原因です。
以下を確認して問題を解決します。
データセット内の NULL 値を識別して対処します。Spark は、データセット内の欠損値に対処する方法を知る必要があります。
dropna() を使用して値が欠落している行を破棄します。
ゼロまたは列の平均値などの値を代入します。この解決策は、データ セットにとって何が意味を持つかによって異なります。
すべてのトレーニング データが適切に数値形式に変換されていることを確認します。Spark は、カテゴリ変数と文字列変数の処理方法を知る必要があります。データ固有のケースに対処するために、さまざまな特徴量トランスフォーマーを使用できます。
共線性をチェックします。相関性が高い、または重複している機能は、モデルのフィッティングで問題を引き起こす可能性があります。これはまれに発生しますが、必ず除外する必要があります。
このエラーは、Databricks クラスターで使用されている Apache Spark のバージョンと互換性のない Sparkling Water パッケージのバージョンを使用しようとすると発生します。
Sparkling Water のダウンロードページから正しいバージョンの Sparkling Water をダウンロードしていることを確認してください。
デフォルトでは、ダウンロード ページは Sparkling Water の最新バージョンを提供します。それでも問題が解決しない場合は、Spark のバージョンと互換性のある以前のバージョンの Sparkling Water にロールバックしてみてください。
それでも Sparkling Water の設定に問題がある場合は、 H20.ai サポートでケースを開いてください。
scikit-learn はグループK フォールド交差検証をサポートし、フォールドが明確で重複していないことを確保します。
Spark では、scikit-learn モデルのチューニングを並列チューニングするspark-sklearnライブラリを使用して、この方法を利用できます。この例では、scikit-learnランダム フォレスト モデルを、Spark でgrp変数を使用してグループ k 分割法でチューニングします。
Generative AIとは、文章や画像、音楽など、一見独創的で新しい創造物を生み出すことができる技術です。これらのAIは、すでに行われたことを繰り返すだけではありません。大量の事例をもとに学習させたモデルは、人間がどのようにコンテンツを作り上げるかという基本的なパターンを学習し、これまで人間の創造性の表現として理解されてきたような、見たこともない、観察したこともないような構成に到達します。しかし、どの単語が次に続くかを判断したり、画像に様式化されたフィルタを適用したりするような過去の単純なAIとは異なり、これらのAIは、生成されている作品群の幅広い文脈を理解する能力を備えているため、形成されたコンテンツは人間の解釈者にとってはるかに一貫性があり説得力のあるものとなっています。
生成AIは非常に有望であり、企業はこれを試験的に導入する必要があります。一般的な知識の検索、視点の開発、ある種の情報の分析など、さまざまな能力を備えています。しかし、生成モデルには、商用利用が可能になる前に解決しなければならないいくつかの弱点があります。
 正確でなくても、権威あるように聞こえます。同じトピックについて対照的な意見を述べるようLLMに求めると、LLMはそれを実行し、どちらにも自信を持っているように聞こえるでしょう。LLMは首尾一貫した文章を作成することができますが、より広い文脈を理解し、それを考慮した文章を作成することにはまだ苦労しています。LLMは訓練された情報に基づいてしか回答を生成できないため、訓練データ以外のトピックに関する知識や理解が限定的となる可能性があります。
 知的財産権。多くの場合、LLMは、そのデータに対して法的権利を持つ個人または組織が所有するテキストデータでトレーニングされます。これらのデータ所有者は、データに対して所有権や著作権を有している場合があり、大規模な言語モデルの学習にデータを使用する際には、その権利を尊重することを要求される場合があります。また、生成型AIモデルによって生成されるコンテンツの所有権は不透明です。米国の最高裁は最近、AIが生成した画像には知的財産権保護がないとの判断を示しました。
 コストとエネルギー消費： LLMの最大の限界の1つは、モデルをトレーニングするためのコスト（主にコンピューティング）であった。1回のトレーニングに数百万ドル。これは多くの企業にとって経済的に実現不可能であるだけでなく、規模が大きくなれば、経済に大きな悪影響を与えることになります。(これが、私たちがDollyを開発した主な理由の1つです。）
 偏見を助長する可能性がある。LLMは、学習データに存在するバイアスを再現することが知られています。これは、偏った言語生成や偏った入力に基づく意思決定につながる可能性があります。
ChatGPTの知識ベースと同様にリストは無限大ですが、ここでは、小売業者がGenerative AIに投資すると聞いている、または期待している主要なカテゴリをいくつか紹介します：
 1. パーソナライズされたマーケティング： すべての顧客はユニークです。生成AIを活用することで、顧客体験を向上させ、買い物客に関連する商品をメールやオンラインで消費者に個別メッセージとして提供することができます。
 2. バーチャル試着室。Generative AIは、買い物客の興味と利用可能な商品にマッチしたカスタム画像を生成するために使用することができます。買い物客は、自分の写真に、カタログから利用可能な商品を生成モデルでレンダリングすることができます。
 3. チャットボット/カスタマーサービスの自動化。コールセンターでのやり取りから得られたトランスクリプト、商品情報、リアルタイムの注文情報を使ってLLMをチューニングしコールセンターのエージェントの負担を軽減することができる。
 4. お客様の配送・設置のスケジュール管理。 新しいホームシアターを注文し、配送と設置が必要ですか？LLMは、モバイルアプリケーション、ウェブサイト、あるいは店内のキオスク端末と統合することで、小売業者が顧客と配送や設置のオプションを簡単に調整することができます。LLMは、構成要件、必要部品、リソース要件などにアクセスし、1回の訪問で配送と設置が完了するようにすることができます。
 5. セキュリティ脅威やアカウント乗っ取りの試みをキャッチする。 生成AIを使用して、顧客のメッセージやその他の通信を分析し、フィッシングの試みやソーシャルエンジニアリングなど、不正行為の兆候を見つけることができます。
 6. 店舗内アシスタント。ホームセンターを訪れたことのある人ならわかるように、「X製品はどの通路にありますか」と尋ねても、間違った答えが返ってくることが多い。LLMはウェブやモバイルのアプリケーションと統合し、店舗のレイアウトや現在の在庫情報などのデータを活用することで、このようなリクエストに正確に応えることができるようになります。
 7. 在庫と需要の計画。 小売業にとって最大のペインポイントの一つである需要予測と在庫計画を、生成的AIによって最適化できる可能性は非常に高く、小売業者が過剰在庫や過小在庫を回避するのに役立ちます。Generative AIは、販売データを分析し、どのストーリーにどのレベルの在庫を置くべきかを提案したり、過去のデータ、消費者感情、競合データを分析することで小売業者のトレンド予測を支援することができます。
 8.商品開発： 飽和状態の市場で際立つユニークで革新的な商品を作るために、小売業者はGenerative AIを活用して、顧客の好み、市場動向、その他のデータに基づいて新しい商品デザインを作ることができます。ここでは、プロダクトレビュー、ドキュメントディスカバリー、契約書レビューなどを活用して、プロダクツロードマップや開発を推進するために、ドキュメントレビューが大きな役割を果たすと予想されます。
 9. 実用的なインサイトを生み出す。小売業者は、もはや従業員のレポート解釈能力に依存する必要はありません。LLMは、構造化された情報を解釈し、分析し、関連する洞察を平易な言葉で返す訓練を受けることができます。また、LLMを予測モデルと連携させることで、在庫状況、労働力配置、顧客対応など、さまざまな状況の分析を自動化することができます。
 10. コード開発。Generative AIは、コードの開発に使用することができます！開発者は、ジェネレーティブモデルと連携してベースコードを開発し、それを強化することで、生産性を大幅に向上させることができます。
Dollyの目的は、オープンソースの大規模言語モデル（LLM）を使って、高品質の学習データを使ってChatGPTのような命令追跡機能を持たせることができるという、生成AIの親しみやすさを示すことにあります。
 Dollyでは、数年前からあるオープンソースのLLMを、比較的小さなDatabricksクラスタで、比較的小さな（そして確実にアクセスできる）量のデータでトレーニングできることを証明することができたのです。このデモのポイントは、組織がこの技術にどのようにアプローチするかという選択肢があること、そしてこの機能を得るために外部に依存する必要がないことを示すことでした。
 しかし、Dollyの基盤となっているテクノロジーは、独自の命令追従モデルを安価に構築し、ビジネスに生成的AIを活用したいと考える小売業者にとって、エキサイティングな新しい機会を提供するものだと信じています。
LLMやGenerative AIテクノロジーは、ビジネスの運営や価値創造のあり方を大きく変える可能性を秘めています。しかし、まだ道半ばです。小売業にとって重要なのは、この新しいテクノロジーの波に対して、今すぐビジネスを準備することです。小売業は、次のようにしてそれを行うことができます：
 1. AI戦略の策定 - ビジネス全体と整合性のある明確なAI戦略を持つことが重要になります。小売企業は、顧客体験の向上、サプライチェーンと在庫管理の改善、製品イノベーションの推進にAIをどのように活用できるかを概説し、自動化と意思決定のための新しいユースケースを模索する必要があります。
 2. データインフラへの投資 - 今後、生成型AIを利用する場合、効果的に運用するためのモデルを訓練するための膨大な量のデータが必要になります。小売業者は、あらゆる種類のデータ（構造化、半構造化、非構造化）を収集、保存、管理でき、この技術が活用するBIとAIのユースケースをサポートするデータレイクハウスの構築に投資する必要があります。
 3. レイクハウスにデータを取り込む - 生成AIモデルは一般化されています。それらを強力で適切なものにするのは、企業に特有のデータです。企業は、こうした生成モデルを想定してデータのキャプチャとアノテーションに投資する必要があります。
 4. パイロット - 生成AIはまだ商業的に使用する準備ができていないかもしれませんが、実験をサポートするのに十分な性能を持っています。今、これらのツールを試験的に導入することで、成熟したときに採用するための準備が整うことになります。
まず、誰もがより多くのデータを求めています。それは、より良い機械学習モデルを意味する（こともあるからです）。機械学習は現実の世界をモデル化するので、より多くのデータがあれば、その世界の全体像を把握することができます。角のあるケースで何が起こるのか、何が異常なのか、何が繰り返し観察されるのか。本物のデータは入手困難ですが、本物そっくりのデータを無限に入手するのは簡単です。
 しかし、合成データは、実際に存在するデータを模倣することしかできない。合成データは、実際のデータを模倣するだけであり、実際のデータセットにはない新たな機微を明らかにすることはできない。しかし、実際のデータが意味することを外挿することは可能であり、場合によっては有益であることもあります。
 第二に、データは自由に共有できない場合があります。個人を特定できる機密情報（PII）が含まれている可能性があります。新しいチームとデータを共有し、探査や分析作業を迅速に行うことが望ましいかもしれませんが、共有するためには、長時間の再編集、特別な取り扱い、フォームへの記入など、官僚的な作業が必要になる可能性があります。
 合成データは、機密データのようでありながら、実際のデータではないデータを共有することで、その中間的な役割を果たします。場合によっては、この方法にも問題があるかもしれません。合成データが実際のデータポイントに少し似ているとしたら、どうでしょうか。また、不十分な場合もあります。
 しかし、合成データを共有することで十分なデータセキュリティを確保しつつ、コラボレーションを加速させることができるユースケースはたくさんある。例えば、新しい問題を解決する信頼性の高い機械学習パイプラインを開発するために、請負業者のチームに協力してもらいたいと考えています。しかし、機密性の高いデータセットを彼らと共有することはできません。合成データを共有すれば、彼らが実際のデータで実行してもうまく機能するパイプラインを構築するのに十分すぎるほど役立つでしょう。
その理由はいくつかあります：1. レガシーテクノロジー（オンプレミスやクラウドのデータウェアハウス）は、接続された製品やオペレーションから得られる大量のデータに対して、あまりにも複雑でコストが高い。2. 散発的なバッチ駆動のデータとアナリティクスは、リアルタイムの洞察とアクションを妨げ、重要なオペレーションの意思決定に大きな影響を及ぼしています。3. 構造化データと非構造化データのフォーマットとアーキテクチャが分かれており、顧客、業務、資産に関する見解がバラバラである。4. イノベーションをよりコストと時間のかかるものにする、断片的なツーリング
はい、Lakehouse for Manufacturingの上に構築されたDatabricksとパートナーのエコシステムは、業界で最も一般的で価値の高いユースケースに取り組む組織を支援するパッケージソリューションアクセラレータを提供しています。人気のアクセラレータは以下の通りです。1. デジタルツインズ： 実世界のデータをリアルタイムで処理し、大規模に洞察を計算し、データ駆動型の意思決定のために複数の下流アプリケーションに配信します。2. 部品レベルの予測： 在庫切れを防ぎ、リードタイムを短縮し、売上を最大化するために、総量レベルではなく、部品レベルで需要予測を行う。3. 設備全体の有効性： さまざまな形式のセンサー/IoTデバイスからのデータをインクリメンタルに取り込んで処理し、グローバルな製造ネットワークでKPIレポートへの一貫したアプローチを提供します。4. コンピューター・ビジョン :  重要な製造プロセスを自動化するためのコンピュータビジョンアプリケーションの開発と実装、品質の向上、無駄の削減、再加工コストの削減、フローの最適化。 5. プレディクティブ・メンテナンス（IoT）： フィールドデバイスからリアルタイムにIIoTデータを取り込み、複雑な時系列処理を行うことで、稼働率を最大化し、メンテナンスコストを最小化する。
MLOps Stacksとはコードデプロイパターンを活用しており、モデルのアーティファクトではなくトレーニングのコードをstagingやproductionへ昇格させます。（デプロイコードとデプロイモデルの比較についてはBig Book of MLOpsで詳しく知ることができます。）これは、機械学習モデルの本番移行のためのInfrastructure-as-Code (IaC)やCI/CDを構築するためのcookiecutterテンプレートを提供しています。cookiecutterのプロンプトを介して、DatabricksワークスペースURL、Azureストレージアカウント名などのAzure Databricksの環境値についてテンプレートを設定しました。Stacksはデフォルトでstagingとproductionで異なるDatabricksワークスペースを仮定します。そのため、Azureサービスプリンシパルの生成についてカスタマイズして、同じワークスペースにstaging-sp and prod-spという２つのサービスプリンシパルを持つことにしました。これでCI/CDパイプラインが備わったので、cookiecuterテンプレートに従っての機械学習コードの採り入れへと進みました。下図は私たちが実装した機械学習の開発と自動的な本番移行のための全体的なアーキテクチャです。*注釈：StacksはDatabricksのプライベートプレビュー中の製品であり、将来のモデル開発をさらに簡単にすべく継続的に改良中です。今後のリリースにご期待ください！
Dollyは、EleutherAIの既存のオープンソース 60 億パラメータモデルを、Alpaca のデータを用いて、元のモデルにはないブレインストーミングやテキスト生成などの指示に従う機能を引き出すために、ほんの少し修正することで動作します。
 Dolly の基礎となるモデルは、GPT-3 の1750 億個のパラメータに対して60 億個しかなく、しかも 2 年前のものであるため、これほどうまく機能するのは特に驚くべきことです。このことは、ChatGPT のような最先端のモデルの質的向上の多くが、より大きく、よりよくチューニングされた基本モデルではなく、指導に従ったトレーニングデータの集中コーパスのおかげである可能性を示唆しています。このモデルは、LLaMA にインスパイアされた Alpaca のオープンソースクローンであることから、最初のクローン哺乳類である「Dolly the sheep」（羊のドリー）にちなんで 「Dolly」と呼んでいます。企業向け AI の民主化の初期段階であり、まだ多くの課題が残っていますが、Dolly の基盤技術は、独自の命令追従型モデルを安価に構築したい企業にとって、エキサイティングな新しい機会であると信じています。
 ChatGPT のベースとなっている InstructGPT 論文に記載されている命令追従機能について Dolly を評価したところ、テキスト生成、ブレインストーミング、オープン Q&A など、多くの質的機能を発揮していることがわかりました。これらのサンプルで特に注目すべきは、生成されたテキストの品質ではなく、数年前のオープンソースモデルを小規模で高品質なデータセットでファインチューニングした結果、命令追従能力が大幅に向上したことです。
企業が、API の背後にある独自のモデルを提供する集中型 LLM プロバイダにデータを送るのではなく、独自のモデルを構築することを好む理由はたくさんあります。多くの企業にとって、AI から恩恵を受ける可能性が最も高い問題やデータセットは、最も秘密性の高い独自の知的財産であり、それを第三者に渡すことは好ましくないかもしれません。さらに、モデルの品質、コスト、望ましい動作など、組織によってトレードオフが異なる場合もあります。私たちは、ほとんどの ML ユーザーがモデルを直接所有することが、長期的に最も良い結果をもたらすと信じています。
 Databricks で Dolly を自作するために使用できる簡単な Databricksノートブックをオープンソース化しています。モデルをダウンロードして実験するには、Databricks Hugging Face Page をご覧ください！
T5 (Text-to-Text Transfer Transformer)は、Googleが提供する汎用LLMのファミリーです。要約、分類、翻訳など多くのタスクに役立ち、「小さい」（～60Mパラメータ）からかなり大きい（～11Bパラメータ）ものまで、いくつかのサイズが用意されている。これらのサイズは、ますます強力になる一方で、扱うにはますます高価になっています。これらのLLMを扱う際の重要なテーマは、「シンプルに保つ」ことです。小さいモデルで十分であれば、それを使用し、可能であれば既製のリソースで始める。大きなモデルを使った推論には時間とコストがかかるので、レイテンシーや予算の制約から、最初から大きなモデルは使えないかもしれません。
ファインチューニングとは、あらかじめ訓練されたモデルを新しいデータでさらに訓練し、ある特定のタスクの性能を向上させることを意味します。T5のようなモデルは、ある単語列を別の単語に変換するような多くのことを行うように訓練されています。ここで、T5が得意とするのは、多くの商品レビューをレビュー要約に変換することです。これはT5が得意とする要約作業のようなもので、手元にある実際のレビューデータによりよく合うように要約を調整することを望んでいるだけです。これは、T5アーキテクチャをゼロからトレーニングするのとは違います。時間がかかるだけでなく、事前に訓練されたT5モデルが持っている言語に関する学習がすべて失われてしまうからです。
 上記の例は、既存のモデルと、その作成に費やした研究、データ、計算能力を再利用しているため、起こっていることの複雑さに比べれば、非常にシンプルです。しかし、fine-Tuningはモデルのトレーニングであり、経験豊富な実務家であっても、トレーニングプロセスを継続するために必要なPyTorchやTensorflowのコードを書くことは簡単ではありません。
MicrosoftのDeepSpeedは、洗練された最適化を多数実装することで、既存の深層学習トレーニングや推論ジョブをほとんど変更することなく高速化することができます。特に興味深いのは、メモリ使用量を減らそうとする最適化セットであるZeROです。詳細や論文については、DeepSpeedのサイトを参照してください。DeepSpeedは、Hugging FaceのTrainer APIを使用するFine-Tuningジョブを自動的に最適化することができ、既存のFine-Tuningスクリプトを実行するためのドロップイン代替スクリプトを提供しています。これは、既製のトレーニングスクリプトを再利用することが有利である理由の1つです。
レイクハウスはこれまでのデータプラットフォームの課題を解決するために、データウェアハウスとデータレイクの長所を組み合わせた新たなデータプラットフォームである。以下の図に示しているように、レイクハウスではテーブルなどの構造化データ、ログやJSONのような半構造化データ、さらには、画像・音声・テキストのような非構造化データすべてを格納することができ、データウェアハウスを活用して行われていたBIや、データレイクの主なユースケースであるデータサイエンスや機械学習の取り組みなどをすべて一つのプラットフォームで実施することできる。
 レイクハウスにおいては、データをオープンなデータレイクに格納することでデータの種類やサイズを問わずそのままの状態で保持することが可能である。これによってベンダーロックインを回避できることに加え、将来的に取り組むであろうユースケースに備えて柔軟にデータを蓄積することが可能となる。
 しかし、データレイクには上述の長所がある一方で、以前の記事でも触れたようにデータ品質やパフォーマンスの課題がある。どのようなデータを格納できたとしても、そのままではゴミだらけになってしまう。このため、従来のデータレイクはデータスワンプ(沼)と揶揄されることもあった。
これまでは、購買履歴、CRMデータなどの構造化データをデータウェアハウスで集計、加工し、BIダッシュボードに表示することでビジネスの意思決定に役立てるというのが、データ活用の主なユースケースであった。しかし、競争優位性を高めるために、過去にのみ目を向けるのではなく、データとAIを活用することで将来を見通そうというニーズが高まっている。
 このため、購買履歴やCRMのような構造化データだけではなく、Webサイトの利用履歴、ソーシャルメディアへの投稿、電話の通話記録などの半構造化データ、非構造化データにも着目し、これらのデータに機械学習・人工知能を適用することで、これまでとは比較にならないビジネス価値を生み出すことをゴールとして多くの企業でデータ×AIプロジェクトが推進されている。このような取り組みに関してはこちらのウェビナーでも説明しているので参照願いたい。そして、このような取り組みでは、多くの場合、データウェアハウスやデータレイクのようなデータ管理プラットフォームが活用されている。
メーカーによる運用技術のサイバーセキュリティへの投資は、従来情報技術への投資に比べ遅れていました。しかし ITとOTの融合を考えるとそんな事を言ってられません。つまりメーカーはサイバーセキュリティを総合的に考える必要があるのです。
 技術面では、OTのサイバーセキュリティはITのサイバーセキュリティとは異なり、ICSやSCADA機器にEDR（Endpoint Detection and Response）エージェントをインストールすることは、なかなか難しいか実現不可能です。そのため、ICSやSCADAシステムのセキュリティは、通常これらのシステムを行き来するネットワークトラフィックの監視のみに依存しています。膨大なネットワークデータの取得、保存、監視は技術面でもコスト面でも課題となっています。
 また、製造業は資本集約型であるため、製造装置の寿命は数十年に及び、ソフトウェアやファームウェアの更新が制限されることが多いという課題もあります。技術のライフサイクルが長く、更新が限られているため、機器のソフトウェアやファームウェアにパッチが適用されていない脆弱性が存在するリスクが高まります。パッチが適用されていない脆弱性は、通常、脅威者が環境に侵入する足がかりとなる。そのため、OTのセキュリティ対策では、レガシーな機器やインフラからのリスクを軽減するためにロギングや監視を追加する必要があり、データインフラにさらなる負担を強いることになる場合が多いのです。
 投資の不足と産業機器の性質、さらに本質的にビッグデータの問題が相まって、今日直面している製造業向けのサイバーセキュリティツールの少なさを生み出しています。
UDFのパフォーマンスチューニングには、2つのポイントがあります。1つ目は、各GPUを効率よく使いたいということで、これはTransformersパイプラインによってGPUに送られるアイテムのバッチサイズを変更することで調整することができます。もう1つは、データフレームをうまく分割してクラスタ全体を活用することです。
Prophetは、時系列予測のためのオープンソースライブラリです。Facebook 社の Core Data Science チームが開発・リリースしており、年毎、週毎、日毎の周期性に加え、休日の影響などを考慮して非線形な傾向を持つ時系列データをシンプルにモデル化できるという特長があります。さらに、異常値や欠損データの扱いにも強く、また、人間が理解しやすいパラメタやドメイン知識などを加えることで、モデルの精度を向上させる機能も備えています。
Community Editionでは、Databricksのフルバージョンの機能に対して以下の制限があります。
 1. 作成できるクラスターは15GB RAM, 2 Core CPUのシングルノードのみ 
 2. ワークスペースに追加できるユーザー数は最大3名まで 
 3. クラスターのリージョンはus-westのみ 
 使用できない機能 
 1. ジョブのスケジュール機能 
 2. クラスターのオートスケーリング機能 
 3. Git連携 
 4. MLflowの一部モデル管理機能(レジストリ、RESTサービング) 
 5. REST APIによるワークスペースの制御 
 5. セキュリティ、ロールベースのアクセス制御、監査、シングルサインオン 
 6. BIツール連携のサポート
使用期間の制限はありません。そのため、Databricks機能の使用感の確認や、Databricksのトレーニング教材を実行していただく環境として広くご利用いただけます。例えば、以下の機能・環境がCommunity Edition上で利用することができます。
 1. Databricks Workspace/Notebook環境(共同編集・コラボレーション機能) 
 2. Spark (Databricks Runtime版) 
 3. Delta Lake (Databricks版) 
 4. MLflow(モデルトラッキング機能) 
 5. Koalas(SparkのPandas API) 
 6. MLlib(Sparkネイティブの機械学習ライブラリ) 
 7. 一般的な機械学習ライブラリ環境(TensorFlow, Keras,  Pytorch, Scikit Learn, XGBoostなど) 
 8. 一般的なデータサイエンス環境(Scipy, Numpy, Pandas, Matplotlibなど)
1. 自動化されたリアルタイムのリネージ：Unity Catalog は、あらゆる言語（Python、SQL、R、Scala）、実行モード（バッチ、ストリーミング）で実行されたクエリのデータフロー図を自動的に取得し、リアルタイムに表示します。リアルタイムのリネージにより、データフローの証跡を手動で作成する運用上のオーバーヘッドを削減します。Unity Catalog メタストアに接続されたすべてのワークスペースにおいて、データリネージは自動的に集約されます。これは、あるワークスペースで取得したリネージを、同じメタストアを共有する他のワークスペースで見ることができることを意味します。
 2. 統一されたカラムとテーブルの系統グラフ：Unity Catalog では、1 つの系統グラフで列と表の両方の系統を確認できるようになり、特定の表や列が何で構成され、データがどこから来るのかをよりよく理解できるようになりました。ユーザーは、数回のクリックで、上流または下流の系統グラフを移動し、完全なデータフロー図を見ることができます。
 3. テーブルやカラムの枠を超える：Unity Catalog は、ノートブック、ワークフロー、およびダッシュボードの系統も追跡します。これにより、組織内でのデータの使用方法に関するエンドツーエンドの可視性が向上し、データの変更が下流の消費者に与える影響を把握することができます。
 4. ビルトインセキュリティ：系統グラフはデフォルトで安全であり、Unity Catalog の共通権限モデルを使用しています。ユーザーは、系統データフロー図を表示するために正しい権限を持っている必要があり、セキュリティのレイヤーを追加して、意図しないデータ侵害のリスクを低減します。たとえば、ユーザーがテーブルの SELECT 権限を持っていない場合、そのテーブルの血統を調べることはできません。同様に、ノートブック、ワークフロー、ダッシュボードの系統情報も、閲覧権限を持っているユーザーだけが見ることができます。
 5. パートナーとの連携：Unity Catalog は、Unity Catalog REST API を通じて、さまざまなデータガバナンスパートナーとの豊富な連携を実現しており、系統情報を容易にエクスポートすることが可能です。
Data Vault は、Kimball や Inmon の手法に比べ、企業規模の分析用データウェアハウスを構築するために用いられる、より新しいデータモデリングのデザインパターンです。
 Data Vault は、データをハブ、リンク、サテライトの 3 つのタイプに整理しています。ハブはコアのビジネスエンティティを表し、リンクはハブ間の関係を表し、サテライトはハブやリンクに関する属性を格納します。
 Data Vault は、拡張性、データ統合/ETL、開発スピードが重要視されるアジャイルデータウェアハウス開発に重点を置いています。ほとんどのお客様は、ランディングゾーン、Vaultゾーン、データマートゾーンを、Databricks の組織パラダイムのブロンズ、シルバー、ゴールドレイヤーに対応させています。Data Vault のハブ、リンク、サテライトテーブルのモデリングスタイルは、通常 Databricks レイクハウスのシルバーレイヤーによく合います。
次元モデリングは、データウェアハウスを分析用に最適化するために設計するボトムアップのアプローチです。次元モデルは、ビジネスデータを次元（時間や商品など）とファクト（金額や数量の取引など）に非正規化し、異なる対象領域を適合した次元で接続して、異なるファクトテーブルにナビゲートするために使用されます。
 次元モデリングの最も一般的な形式は、スタースキーマです。スタースキーマは多次元データモデルで、データを整理して理解しやすく、分析しやすく、またレポートの実行が非常に簡単で直感的にできるようにするために使用されます。Kimballスタイルのスタースキーマや次元モデルは、データウェアハウスやデータマートのプレゼンテーション層、さらにはセマンティック層やレポート層におけるゴールドスタンダードと言えます。スタースキーマの設計は、大規模なデータセットに対するクエリに最適化されています。
Delta Lake は、データレイクのテーブルに対して挿入、更新、削除、ACID トランザクションの追加を容易にし、メンテナンスと履歴管理を簡素化するオープンなストレージ形式レイヤーです。Delta Lake は、動的ファイルプルーニングを実行して、より高速な SQL クエリに最適化する機能も提供しています。
DLT は、既に世界中の大手企業において本番運用でのユースケースを支援しています。スタートアップからエンタープライズまで、ADP、シェル、H&R Block、Jumbo、Bread Finance、JLL を含む 400 社以上の企業が、DLT を使用して次世代のセルフサービス分析とデータアプリケーションを強化しています。
 Delta Live Tables を用いることで、アナリストとデータエンジニアは、SQL や Python を使用して本番環境に対応したストリーミング、またはバッチ ETL パイプラインを簡単に構築できます。完全なデータパイプラインの宣言型記述を一位にキャプチャして依存関係をライブで理解し、内在する運用の複雑性を自動化することで ETL 開発をシンプルにします。DLT を使用すると、エンジニアはパイプラインの運用や保守ではなくデータの配信に集中することができ、次の主要なメリットを活用できます。
 DLT のプレビューをリリースして以来、Databricks はいくつかのエンタープライズ向け機能と UX の改善を行ってきました。UI を拡張することで、DLT パイプラインのスケジュール設定、エラーの参照、ACL（アクセス制御リスト）の管理、テーブルリネージュの可視化の改善、データ品質の可観測性 UI とメトリクスの追加をシンプルにしました。さらに、継続的に到着するデータを効率的かつ簡単にキャプチャするためにの変更データキャプチャ（CDC）のサポートと、ストリーミングワークロード向けに優れた性能を提供する拡張オートスケーリングのプレビューをリリースしました。
Databricks SQL は、 Databricks のレイクハウスプラットフォームにおける SQL のデータウェアハウス機能とファーストクラスのサポートを提供します。これにより、アナリストは従来のクラウドデータウェアハウスよりもわずかなコストで新たな知見を迅速に発見し、共有できるようになります。
クエリプロファイルには、次の主要な機能が含まれています。

クエリの実行と関連するメトリクスにおける主なコンポーネントの詳細化：タスクに費やされた時間、処理された行、メモリ消費量
複数のグラフィック表現：最も遅い処理を一目で確認できる要約されたツリービュー、クエリ演算子間のデータフローを理解するためのグラフビュー
結合の展開や全表スキャンといったクエリのよくある間違いを簡単に検出する機能
クエリプロファイルをダウンロードして共有する機能でコラボレーションを向上
TPC-DS は、トランザクション処理性能評議会（TPC）によって定義されるデータウェアハウスのベンチマークです。TPC は、1980 年代後半にデータベースコミュニティによって設立された非営利団体で、リアルワールドのシナリオを模倣したベンチマークの作成に注力しています。そのため、TPC は、データベースシステムの性能を客観的に測定する目的で使用されています。また、TPC はデータベースの領域にも大きな影響を与え、Oracle、Microsoft、IBM などの確立されたベンダーによる 10 年に及ぶ「ベンチマーク戦争」が、この領域の発展を推進してきました。

TPC-DS の “DS” は、意思決定支援（Decision Support）を意味します。極めてシンプルな集計から複雑なパターンマイニングまで、さまざまな複雑さを持つ 99 のクエリが含まれています。これは、複雑さが増す分析を反映した 2000 年代半ばからスタートした比較的新たな取り組みのベンチマークです。TPC-DS は、この 10 年間でデータウェアハウスのベンチマークの事実上の標準となり、ほぼ全てのベンダーで採用されています。
Databricks Repos は、データチームが常に抱えている課題を解決するために開発されました。データエンジニア、データサイエンティストが使用しているツールの多くは、Git のバージョン管理システムとの連携が不十分、あるいは全くありません。コードをレビュー、コミットするだけでも、数多くのファイル、ステップ、UIをナビゲートする必要がありました。これでは時間がかかるだけでなく、エラーを発生しやすくします。
Databricks Repos は、Databricks と一般的な Git プロバイダーを直接リポジトリレベルで統合することで、データの実践者は新規の Git リポジトリや既存リポジトリをクローンの作成、Git オペレーションの実行、開発のベストプラクティスに従うことを容易にします。

Databricks Repos によって、ブランチの管理、リモートの変更のプル、コミット前の変更点の確認など、使い慣れた Git の機能にアクセスができるため、Git ベースの開発ワークフローを容易に活用できるようになります。さらに、Repos は Github、Bitbucket、Gitlab、Microsoft Azure DevOps のような幅広い Git プロバイダをサポートしており、CI/CDシステムと統合を可能にする一連の　API も提供しています。
「Files in Repos」と呼ばれるこの機能は、Databricks 上で Python ソースコード、ライブラリファイル、設定ファイル、環境設定ファイル、小規模のデータファイルなど、ノートブックファイル以外のファイルを扱うことができる Repos の新機能です。この機能は、コードの再利用、環境管理、デプロイメントの自動化を容易にします。ユーザーはローカルファイルシステムと同じように、Databricks Repos のファイルに対して、インポート（クローン）、読み込み、編集が可能です。
bamboolib は、Python コード（Excel のマクロを想像してみてください）をエクスポートする、拡張可能な GUI を提供します。ユーザーによるコーディングなしで、高速かつシンプルなデータ探索と変換を可能にします。UI ベースのワークフローにより、市民データサイエンティストとエキスパートの両方が容易に Databricks にアクセスできるようになり、社員のオンボーディングやトレーニングのコストを削減できます。ノーコードのユースケースには次のようなものがあります。
Databricks MarketplaceはオープンソースのDelta Sharing規格を利用した、あらゆるデータ、アナリティクス、AIのためのオープンマーケットプレイスです。データ消費者とデータ提供者の広大なエコシステムを結集し、データセット、ノートブック、MLモデルなど、さまざまなデータ資産を、プラットフォームの依存関係や複雑なETL、高価なレプリケーションなしに共有・共同利用できます。データコンシューマーは、組織のAI、ML、アナリティクスイニシアチブを革新・推進し、ベンダーロックインすることなく、より迅速なインサイトを提供することができます。データプロバイダーは、ビジネスを拡大し、新しいユーザーを獲得し、収益を上げることができます。
オープンスタンダードに基づき構築されたDatabricks Marketplaceは、データプロバイダーとあらゆるクラウド上の最も豊富なデータツールを接続し、データプロバイダーがプラットフォーム依存、ETL、レプリケーションなしに、データセットとモデル、ノートブック、ダッシュボードなどのデータ資産の両方を収益化し、データ消費者が最速かつ最もシンプルに洞察を得ることができるよう独自に提供します。
Databricks Marketplaceは、データコンシューマーがイノベーションを実現し、すべてのアナリティクスとAIイニシアチブを前進させる機会を劇的に拡大するものです。データコンシューマーは、独自のプラットフォームの依存関係や複雑なETL、高価なレプリケーションなしに、データセットだけでなく、MLモデル、ノートブック、アプリケーション、ダッシュボードなどのAIや分析資産も独自に入手できます。このオープンなアプローチにより、あらゆるクラウドで、お好みのツールを使って、より迅速にデータを活用することができます。
最新のHugging Faceリリースでは、Datasetsの新しい "from_spark "関数を呼び出すだけで、ユーザーが同じタスクを達成するのをより簡単にできるようにしました。これにより、ユーザーはSparkを使用して、モデルのトレーニングやファインチューニングのためにデータを効率的にロードして変換し、SparkデータフレームをHugging Faceデータセットに簡単にマッピングして、トレーニングパイプラインに超シンプルに統合することができます。
私たちはモデルのトレーニング、チューニング、デプロイを成功させるための最高のツールを提供するために努力しています。Hugging Faceへの貢献を続けるだけでなく、他のオープンソースプロジェクトへの改善もリリースしはじめました。最近のMLflowのリリースでは、transformersライブラリのサポート、OpenAIの統合、Langchainのサポートが追加されました。また、Databricks SQLのAI Functionsも発表し、OpenAI（あるいは将来的には独自のデプロイメントモデル）をクエリに簡単に統合できるようにしました。さらに、Databricks上での分散PyTorchトレーニングを簡素化するために、Spark用のPyTorch distributorもリリースしました。
通常、データレイクに取り込まれたデータは、取り込み層からキュレーション層へと移動する際にクレンジングされます。データを意味的に一貫したものにするためには、ビジネスコンテキストの観点からも整合性をとる必要があります。例えば、異なるシステムからの顧客データや収益データは、両方のレイヤーで同じ意味を持たせる必要があります。そして、適切なレベルで、データの重複を排除する必要があります。

この追加ステップにより、キュレーション層の意味的に一貫したデータをインテグレーション層のデータと安全に結合し、ゴールド層のビジネス対応テーブルを提供できるようになります。