bowang0911/databricks-qa-ja huggingface dataset:
タイムトラベルを使って指定した過去のバージョン（またはタイムスタンプ）まで遡るというのは、指定された過去バージョンで参照されていたParquetファイルがどれなのかをトランザクションログから判断し、それらのParquetファイルを読み取って過去の状態を再現するということです。
きっかりデルタログの保持期間が経過した時点で即座に削除されるかというと、そうでもありません。Deltaテーブルの実体はログも含めてクラウドストレージ上にあるただのファイルなので、そもそも該当のDeltaテーブルに対して何もトランザクションを行っていなければ、ログが勝手に消えることもありません。また保持期間経過後に新たなトランザクションが行われたとしても、古いログが実際に削除されるためには内部で様々な条件があり、チェックポイントファイルが作成されていることや、そのチェックポイントの保持期間等も条件に含まれます。このようにデルタログが実際に削除されるタイミングは複雑な条件によって決まります。ただし、delta.logRetentionDurationで設定した保持期間内のデルタログは必ず保持されます。
過去のParquetファイルはVACUUMコマンドで明示的に削除処理を行わない限り、勝手に消えることはありません。 したがって乱暴に考えれば、VACUUMコマンドを一切実行しなければ過去全てのParquetファイルを保持しておくことができます。ただしそうするとストレージの容量が青天井で膨らんでいってしまいます。そのため実際には定期的にVACUUMを行って、意図した保持期間を超えた不要なParquetファイルは削除するのがベストプラクティスです。
delta.deletedFileRetentionDurationは、VACUUMのRETAINオプションによって指定できる最短の保持期間を制限する設定です。
デフォルトは 7日間 に設定されています。
設定は基本的にテーブル単位に行います。　
デフォルトの7日間だと、たとえVACUUMのRETAINで7日間より短い保持期間した際にエラーとなります。従ってこの設定を必要な保持期間に変更しておけば、保持期間内であるべき過去Parquetファイルの誤削除を防止できます。
テーブルのサイズやトランザクション頻度に依存はするのですが、特に過去Parquetファイルの方は保持期間を長くするほどクラウドストレージの容量も膨らんでしまいます。そのため、基本的には最小限の保持期間（多くの場合はデフォルト設定）での運用を意識しつつ、どうしても必要な場合だけ上記のように保持期間を延ばすことを検討するのが良いと思います。
OkeraはデータやAIの領域におけるデータプライバシーやガバナンスの課題を解決します。データの可視性や透明性をシンプルにすることで、企業がLLMの時代において重要であるデータの理解の助けとなり、それらのバイアスに関する懸念に対応することが可能となります。
これまでは、洗練度合いに関係なくデータガバナンスの技術は、いくつかの絞られたレイヤーにおけるコントロールの強制に依存しており、ワークロードをこのレイヤーにおける「壁で囲われた庭(walled garden)」にフィットさせる必要がありました。例えば、クラウドデータウェアハウスはアクセスコントロールにSQLを必要としますが、これはすべてのワークロードがSQLにフィットする限りにおいては効率的なものです。これは、データの主要なアプリケーションがSQLクエリーを生成するBIレポートのようにSQLセントリックであったこの数十年間はうまくいっていました。

AI、特に機械学習モデルやLLMの勃興によって、このアプローチだけでは不十分になりました。第一に、AIで使用されるデータは人間が生成したものではなく機械が生成するものとなるため、企業が管理すべきデータ資産の数は指数関数的となります。第二に、AIの領域における高速な開発スピードのため、最先端の技術を補足するのに十分な表現能力を持つ壁で囲われた庭を単一の企業で作成することはできません。あるベンダーは自身のSQLベースのデータウェアハウスのアクセスコントロールを強制することはできますが、全てのオープンソースライブラリをこの庭における特定のコントロールに準拠するように変更することはできないでしょう。これは、起源やバイアスのようなAI固有のガバナンスの懸念事項は、従来型のデータガバナンスプラットフォームの範疇外になってしまうことを意味します。
Okeraのデータガバナンスプラットフォームは、この新世界におけるデータガバナンスの課題に対応できる2つのユニークなテクノロジーを提供します。

最初に、Okeraは個人情報(PII)のような機微データを自動で発見、分類、タグ付けできる直感的でAI支援のインタフェースを提供します。これらのタグによって、データガバナンスのステークホルダーは、容易にコンプライアンスを評価し、データに対する可視性やコントロールを改善するノーコードのアクセスポリシーを作成することができるようになります。また、Okeraは機微データの使用をクイックに監査、分析できるセルフサービスのポータルも提供し、企業は信頼性を持ってデータの利用パターンを監視、追跡できるようになります。これによって、多くがAIによって生成されるデータ資産の爆発の中でも、ガバナンスポリシーが一貫性を持って適用されていることを保証できるようになります。

次に、Oktaにはパフォーマンスを犠牲にすることなしに、ガバナンスコントロールを強制しつつも、任意のワークロードをサポートできる新たなアイソレーションテクノロジーを開発し続けています。このテクノロジーはプライベートプレビューであり、数多くの連携しているお客様のAIワークロードでテストされている状況です。これは、新世界におけるアプリケーション領域の全体をカバーしていることを効率的に保証するキーとなる技術です。間も無く、我々はこの新技術のギジュ的証左を共有する予定です。
レイクハウスは、データとAIアプリケーションを開発し、LLMを構築するにはベストな場所と言えます。我々のレイクハウスのビジョンは、一つのプラットフォームでこれらのワークロードを統合することを中心としています。我々のレイクハウスビジョンの基盤には、すべてのデータ、AIワークロードのデータがバンスレイヤーであるUnity Catalogがあります。我々は、OkuraのAIセントリックガバナンステクノロジーをUnity Catalogにインテグレーションするつもりです。

我々のお客様は、属性ベース、意図ベースのアクセスポリシーを用いて、すべてのデータ、分析、(MLモデルやモデルの特徴量を含む)AI資産を発見、分類、管理するためにAIを活用できるようになります。さらに、レイクハウスにおけるエンドツーエンドのデータの可視性のメリットを享受することができ、分析、AIアプリケーションにおける機微データの利用を監査、レポートできるようになり、カラムレベルまでデータリネージを自動で追跡できるようになります。

これらの機能強化によって、我々のお客様はクラウド横断のデータ領域における包括的なビューを手に入れることができ、アクセスポリシーを定義するために単一の権限モデルを活用し、レイクハウスにおけるAIユースケースを加速し、一貫性のあるガバナンスを実現します。また、間も無くの買収によって、他のデータガバナンスパートナーが活用できるよりリッチなポリシーのためのAPIを公開し、お客様にシームレスなソリューションを提供することになります。
Deltaテーブルは内部ではParquetファイルを使ってデータを保持していますが、Deltaテーブルに対してINSERT, UPDATE, DELETE等のトランザクションを加えても、既存のParquetファイルが直接上書きされたり削除されたりはしません。その代わり、挿入、変更、削除後の新しい状態を保持したParquetファイルが新たに作成され、読み取り対象のParquetファイルがそちらに切り替わるという動作をします。
ファイル到着トリガー」というパワフルな新機能を導入します。この機能を用いることで、クラウドストレージにファイルが到着した際にジョブを起動するように設定することができます。これらの新たなトリガーを用いることで、ワークフローはファイルが到着した際に、データを取り込み、機械学習推論や任意のタイプの分析を即座に実行することができます。この機能の活用をシンプルにするために、クラウドストレージへのアクセスを管理するUnity Catalogの外部ロケーションを活用できます。現状はファイル到着トリガーはAzureとAWSでパブリックプレビューとなっています。
左外部結合 (LEFT OUTER JOIN)は、結合の基準となる左側のデータフレームの行に、キーとなる列の値がマッチする右側のデータフレームの行を連結することで2つのデータフレームを結合します。左側のデータフレームのキーとなる列の値が右側のデータフレームに存在しない場合でも、左側のデータフレームの該当行は出力されます（右側のデータフレームの該当の情報はnullとして出力されます）。
2つのデータフレームを縦方向に結合(Union結合)します。SQLのUNION ALLとは異なり重複行がある場合でも許容されます。そのため、結合結果から重複を削除したい場合はUnion結合したデータフレームに対してさらにdistinct()を実行する必要があります。また、列の結合は、列の順番のみが考慮されます。列名が同じもの同士をUnion結合したい場合はunionByName()を使う必要があります。
2つのデータフレームを縦方向に結合(Union結合)します。SQLのUNION ALLとは異なり重複行がある場合でも許容されます。そのため、結合結果から重複を削除したい場合はUnion結合したデータフレームに対してさらにdistinct()を実行する必要があります。また、列の結合は、列の順番のみが考慮されます。列名が同じもの同士をUnion結合したい場合はunionByName()を使う必要があります。
データフレームのunion()メソッドを使い、最初の引数としてUnion結合をしたい相手のデータフレームを指定します。
２つのやり方があります。まず手動で移行手順は以下となります。レガシーグローバルinitスクリプトを新たなグローバルinitスクリプトに移行するには:　
既存のレガシーグローバルinitスクリプトをコピーし、UIあるいはREST APIを用いて新たなグローバルinitスクリプトフレームワークに追加します。
すべてのレガシーグローバルinitスクリプトを無効化します。
新たなグローバルinitスクリプトを有効化します。
すべてのクラスターを再起動します。
はい、サポートしています。Databricks Runtime 11.2 ML以降において、AutoMLがデータセットの不均衡を検知すると主要なクラスをダウンサンプルし、クラスの重みを追加することで、トレーニングデータセットの不均衡を削減しようとします。AutoMLはトレーニングデータセットのバランスのみを取り、テストデータセットや検証用データセットのバランスは取りません。このようにすることで、補強されておらず真のクラス分布を持つデータセットを用いて常にモデルのパフォーマンスが評価される様になります。
はい。Databricks Runtime 11.3 LTS ML以降では、分類問題あるいは回帰問題で使用するオリジナルのデータセットを拡張するために、Feature Storeにある既存の特徴量テーブルを活用することができます。
Databricks Runtime 12.2 LTS ML以降では、AutoMLのすべての問題: 分類、回帰、予測において、オリジナルの入力データセットを拡張するために、Feature Storeにある既存の特徴量テーブルを活用することができます。
特徴量テーブルを作成するには、Databricks Feature Store(https://qiita.com/taka_yayoi/items/88ddec323537febf7784)をご覧ください。
企業がAPIの先にあるプロプライエタリモデルを提供する集中管理されたLLMにデータ送信するのではなく、自身のモデルを構築することを好む理由は多数存在します。多くの企業において、AIによるメリットを享受できる問題やデータセットは、自分たちにとって最もセンシティブでプロプライエタリな知的財産であり、サードバーティにそれを引き渡すことは受け入れ難いことかもしれません。さらに、企業においては、モデルの品質、コスト、望まれる挙動に関してそれぞれのトレードオフを持っているかもしれません。多くのMLユーザーは、自分たちのモデルを直接所有することが長期的にベストであると我々は信じています。
 Databricks上でDollyを構築するために活用できるシンプルなDatabricksノートブックをオープンソース化します。学習された重み情報にアクセスしたいのであれば hello-dolly@databricks.com にコンタクトしてください。
いくつかの課題があります。1. 特殊なAPIと言語スキル: 新たな言語、API、ツールを学ぶ必要があるため、データ実践者はストリーミングのスキルセットを学ぶ際に障壁に遭遇します。
 2.オペレーションの複雑性: 大規模なデータストリーミングを実装するには、データチームはストリーミング固有のツールとクラウドサービスをインテグレーションし、管理しなくてはなりません。また、彼らはこれらのシステムを手動で障害から復旧させ、処理の重複なしにワークロードを再起動し、パフォーマンスを最適化し、背後のインフラストラクチャをスケールさせる必要があります。
 3.互換性のないガバナンスモデル: リアルタイムデータと履歴データに対して異なるガバナンス、セキュリティモデルは、適切なユーザーに適切なアクセスを提供することや、エンドツーエンドのリネージを参照することや、コンプライアンス要件を満たすことを困難にします。
Databricksレイクハウスプラットフォームは、データストリーミングをシンプルにする能力は３つあります。
 1. ストリーミングパイプラインとアプリケーションを迅速に構築する能力
 2. 自動化ツールによって簡素化されるオペレーション
 3. リアルタイムデータ、履歴データに対して統合されたガバナンス
DatabricksからBigqueryへの接続。Databricks(spark)ではさまざまなConnectorを用意しており、sparkで生成したDataFrameを簡単にBigQueryに書き込む OR BigQueryからtableの読み込みを行うことができます。
手順としては簡単で 
 BigQuery Storage APIの有効化 
 Service Accountの作成 
 temporary gcs bucketの作成 
 ということで簡単に行うことができます。
Databricksモデルサービングは、統合データ & AIプラットフォームで開発された初のサーバレスリアルタイムサービングソリューションです。このユニークなサービングソリューションは、デプロイメントをシンプルにし、インテグレーションされたツールにおける間違いを削減することで、データサイエンスチームのプロダクションに至るパスを加速します。
Databricks SQL Statement Execution APIは、Databricksレイクハウスプラットフォームで管理されているでエータにアクセス、操作するためにREST API経由でDatabricks SQLのウェアハウスに接続することができるようになる機能です。
 Databricks SQL Statement Execution APIは、データへのアクセスをシンプルにし、皆様の要件に合わせたデータアプリケーションの構築を容易にします。このAPIは非同期型であり、JDBCやODBCの際に必要な接続の管理は不要です。さらに、ドライバーをインストールすることなしにSQLウェアハウスに接続できます。従来型のアプリケーションやクラウドベースのアプリケーション、サービス、デバイスをDatabricks SQLに接続するためにStatement Execution APIを活用することができます。また、お好きなプログラミング言語でカスタムクライアントライブラリを作成することができます。
Databricksレイクハウスプラットフォームは、完全なエンドツーエンドのデータウェアハウスソリューションを提供します。Databricksレイクハウスプラットフォームはオープンな標準とAPI上に構築されています。Databricksレイクハウスは、エンタープライズデータウェアハウスのACIDトランザクションとデータガバナンスと、データレイクの柔軟性とコスト効率性を組み合わせます。Databricks SQLとは、Databricksレイクハウスプラットフォームに組み込まれている、ビジネスアナリティクスのための一般的な計算資源を提供するエンタープライズデータウェアハウスのことを指します。Databricks SQLが提供するコア機能はSQLウェアハウスとなります。
Databricksは、データベースのスキーマ、テーブル、ビューのような馴染みのあるリレーションを用いて、クラウドオブジェクトストレージに各王されているDelta Lakeのデータを整理します。Databricksでは、分析データの検証、クレンジング、変換にマルチレイヤーのアプローチを取ることを推奨しています。詳細は、メダリオンアーキテクチャ(https://qiita.com/taka_yayoi/items/f3d9028cf533e2c78b9d)をご覧ください。
Databricks SQLは、レイクハウスのテーブルに対するSQLクエリー、ビジュアライゼーション、ダッシュボードのための一般的な計算資源を提供します。Databricks SQLでは、これらのクエリー、ビジュアライゼーション、ダッシュボードはSQLエディタを用いて開発、実行されます。
スキーマを探索し、馴染み深いSQL構文を用いてクエリーを記述、共有、再利用するためにビルトインのSQLエディタを活用します。定常的に使用されるSQLコードは、クイックに再利用するためにスニペットとして保存でき、実行時間を短縮するためにクエリーの結果はキャッシュされます。さらに、自動更新やデータに意味のある変化が生じた際にアラートを発呼するために、クエリーの更新をスケジュールすることができます。また、Databricks SQLによって、アナリストはクイックにアドホックな探索分析を行うために、ビジュアライゼーションやドラッグ&ドロップのダッシュボードを通じて、データから意味を抽出できるようになります。
Databricks SQLは、異なるレベルのパフォーマンスと機能サポートを持つ3つのウェアハウスのタイプをサポートしています。
 1. サーバレス: pro SQLウェアハウスタイプのすべての機能、高度なDatabricks SQLパフォーマンス機能をサポートしています。サーバレスSQLウェアハウスタイプはデフォルトでは有効化されていません。サーバレスSQLウェアハウスタイプを有効化するには、Databricks SQL release notesをご覧ください。
 Pro: (Classicと比較して)高パフォーマンスなDatabricks SQLの追加機能をサポートしており、すべてのDatabricks SQLの機能をサポートしています。pro SQLウェアハウスタイプはデフォルトで有効化されています。
 Classic: エントリーレベルのパフォーマンス機能をサポートしており、限定的なDatabricks SQLの機能をサポートしています。Classic SQLウェアハウスタイプはデフォルトでは有効化されていません。
サーバレスが有効化されている: UIあるいはAPIを用いてワークスペースでSQLウェアハウスを作成する際、サーバレスが有効化されていれば、デフォルトのSQLウェアハウスタイプはサーバレスとなります。
 サーバレスが有効化されておらずUIを使用している: UIを用いてワークスペースでSQLウェアハウスを作成する際、サーバレスが有効化されていない場合には、デフォルトのSQLウェアハウスタイプはproとなります。
 サーバレスが有効化されておらずAPIを使用している: APIを用いてワークスペースでSQLウェアハウスを作成する際、サーバレスが有効化されていない場合には、デフォルトのSQLウェアハウスタイプはclassicとなります。
Databricks SQLは、Databricksにおけるデータウェアハウスソリューションとして数多くのサードパーティBI、ビジュアライゼーションツール（https://docs.databricks.com/integrations/index.html#bi）をサポートしています。DatabricksとPowerBIやDatabricksとTableauもご覧ください。
様々な方法があります。例えば、display()関数を使って、カラムごとの欠損率を求めます。カラムごとの統計情報を表示する表のmissingに欠損率が表示されます。欠損率以外にも、データ数、平均、標準偏差、最小最大やデータ分布の可視化等なども表示されるため便利です。
PyGWalkerはJupyter Notebookのデータ解析とデータ可視化のワークフローを簡素化し、pandasデータフレームをTableauスタイルのユーザーインターフェースに変えて、視覚的に探索することができます。とのことです。
 残念ながら Sparkデータフレームには対応していない模様です。Databricksにある bamboolibに近い製品かなと思いました。
Azure Consoleから Databricksサービス費用を確認する方法です。Azureサービスのコスト分析をする方法として、コスト分析 というサービスメニューがあります。
 クイック スタート:コスト分析を使用してコストを調査および分析する 
 コスト分析でコストを確認するには、Azure portal でスコープを開き、メニューで [コスト分析] を選択します。 たとえば、 [サブスクリプション] に移動し、一覧からサブスクリプションを選択して、メニューから [コスト分析] を選択します。
 コスト分析で別のスコープに切り替えるには、 [スコープ] ピルを使用します。
Lookerに接続するには以下を実行します。
 LookerでAdmin > Connections > Add Connectionをクリックします。
 ユニークな接続Nameを入力します。DialectではDatabricksを選択します。
 Remote Hostには、要件にあったServer Hostnameを入力します。
 Portには、要件にあったPortを入力します。
 Databaseには、接続を通じてアクセスしたいワークスペースのデータベース名を入力します(defaultなど)。
 Usernameにはtokenと入力します。
 Passwordには、要件にあったパーソナルアクセストークンを入力します。
 Additional Paramsには、transportMode=http;ssl=1;httpPath=<http-path>を入力し、<http-path>を要件にあったHTTP Pathを入力します。
 PDT And Datagroup Maintenance Scheduleには、PDTの再生成のデフォルト頻度を変更するために適切なcronエクスプレッションを入力します。デフォルトの頻度は5分ごとです。
 クエリーを別のタイムゾーンに変換したい場合には、Query Time Zoneを調整します。
 残りのフィールドはデフォルトのままにします。特に:
 Max ConnectionsやConnection Pool Timeoutはデフォルトのままにします。
 (あなたがすべてをUTCで格納していることを前提として)Database Time Zoneはブランクのままとします。Test These Settingsをクリックします。
 テストが成功したらAdd Connectionをクリックします。
RayのワークロードがDatabricksとSparkスタンドアローンクラスターでサポートされ、両方のプラットフォームでのモデル開発を劇的にシンプルにできるようになります。サポートしている機能は以下となります。
 1: Databricks、SparkにおけるRayクラスターの作成 
 2: Ray TrainとRay RLlibによるモデルのトレーニング 
 3: Ray Tuneによる最適モデルの発見 
 4: Rayダッシュボードの参照
Databricksでは選択的上書き処理で2つの異なるオプションをサポートしているDelta Lakeの機能を活用しています。
 replaceWhereは指定された述語にマッチするすべてのレコードを原子性を持って置き換えるオプションです。
 動的パーティション上書きを用いることで、テーブルがどのようにパーティショニングされているのかに基づいてデータディレクトリを置き換えることができます。
DatabricksやDelta Lakeは、Apache SparkやParquet、Hive、Hadoopのようなオープンソーステクノロジーの上に構築されていますが、これらのテクノロジーで有用なパーティショニングの動機づけと戦略は、一般的にDatabricksで有用とは限りません。テーブルをパーティションする決定をしたのであれば、戦略を選択する前位に以下の事実を検討してください。
 パーティションの境界によってトランザクションは定義されません。Delta Lakeはトランザクションログを通じてACIDを保証するので、原子性を持つ検索を保証するために、パーティションごとにデータバッチを分割する必要はありません。
 Databricksの計算クラスターは物理的メディアに束縛されたデータ局所性を持ちません。レイクハウスに取り込まれたデータはクラウドオブジェクトストレージに格納されます。データ処理の際、データはローカルディスクストレージにキャッシュされますが、Databricksでは、並列のロードにおいて最低限のデータを特定するためにファイルベースの統計情報を使用します。
大規模データセットに対するクエリーをスピードアップするために、パーティションとともにZ-orderインデックスを活用することができます。
 パーティションの境界とZ-orderに基づいたクエリー最適化戦略を計画する際、以下のルールを意識することが重要となります。
 Z-orderはOPTIMIZEコマンドと連携して動作します。パーティション教会をまたがるファイルを結合することはできないので、Z-orderクラスタリングはパーティション内でのみ発生します。パーティションが作成されていないテーブルでは、テーブル全体でファイルを結合することが可能です。
 パーティションはカーディナリティの低い、あるいは既知のフィールド(日付のフィールドや物理的位置など)でのみうまく動作しますが、タイムスタンプのようにカーディナリティの高いフィールドではうまく動作しません。Z-orderは、カーディナリティの高いフィールド、無限に成長するフィールド(たとえば、トランザクション、注文テーブルにおけるタイムスタンプや顧客ID)を含むすべてのフィールドで動作します。
 パーティショニングで使用したフィールドにZ-orderを行うことはできません。
パーティションは特に非常に大きなテーブルにおいては有効です。パーティショニングに関する数多くのパフォーマンス強化は、非常に大きなテーブル(数百TB以上)にフォーカスしています。
 多くのお客様は、ParquetベースのデータレイクからDelta Lakeに移行しています。CONVERT TO DELTA文によって、既存のデータを再度書き込むことなしに、ParquetベースのテーブルをDeltaテーブルに変換することができます。このようにして、多くのお客様は以前のパーティション戦略を継承する大規模なテーブルを手にすることができます。Databricksによって開発されるいくつかの最適化処理は、可能な限りこれらのパーティションを活用しようとし、Delta Lake向けに最適化されていないパーティション戦略のいくかの副作用を軽減します。
 Delta LakeとApache Sparkはオープンソーステクノロジーです。Databricksでは、パーティションへの依存度を削減する機能の導入を進めますが、オープンソースコミュニティでは、複雑性を増加させるような新機能を構築し続けるかもしれません。
Apache SparkやDelta Lakeの経験が豊富である何人かのユーザーは、取り込み時間クラスタリングよりも優れたパフォーマンスを提供するパターンを設計、実装することができるかもしれません。まずいパーティショニング戦略の実装は、後段におけるパフォーマンスに対する非常にネガティブな反動を引き起こす可能性があり、修正するためにはデータの完全な再書き込みが必要になるかもしれません。コストのかかる非効率性を招くことがないように、多くのユーザーにはデフォルト設定を使用することをお勧めします。
Databricks SQLは、Databricksレイクハウスプラットフォームにビルトインされているエンタープライズデータウェアハウスです。Databricks SQLのコアの提供機能はSQLウェアハウスと呼ばれる最適化計算リソースです。
 Databricks SQLは、Databricksレイクハウスプラットフォームにビルトインされているエンタープライズデータウェアハウスです。Databricks SQLのコアの提供機能はSQLウェアハウスと呼ばれる最適化計算リソースです。
 Databricksは、SQLクエリー、ビジュアライゼーション、ダッシュボードを構成、実行するためにSQLペルソナとして知られるUIツールのコレクションを提供します。
 SQLウェアハウスは、サードパーティのBI、可視化ツールを含む様々な環境で実行されるSQLクエリーに対する一般的な計算資源を提供します。また、Databricks SQLは堅牢なAPIを提供しています。
 Databricks SQLの最新機能に関しては、Databricks SQL release notesをご覧ください。
Spark SQLという用語は、技術的にはSparkデータフレームを使用するすべてのオペレーションすべてに適用されます。Spark SQLはSQLクエリーのサポートとPython、Scala、R、Java用のDataFrame APIを導入したSpark 2.xにおけるSpark RDD APIを置き換えました。
 DatabricksのドキュメントではSQLのクエリーや機能を説明する際には、多くの場合Spark SQLを使用しています。Databricksランタイムの計算資源に対して実行されたSQLクエリーは、Delta Lakeに対するビルトインの拡張プロトコルと、プロプライエタリのDatabricksの機能と、オープンソースのApache Sparkの機能に密接にマッピングされます。SQL referenceで、利用可能なすべての機能と実行コンテキスト間での違いを学ぶことができます。
Databricks SQLは最適化された計算環境ですが、Spark SQLはApache Spark APIのコレクションを表現しています。DatabricksではSQL開発者がETLや分析のような作業を行い、ダッシュボードを作成するための様々なツールやテクノロジーを提供しています。エンタープライズデータウェアハウスに関しては、Databricks SQLをお勧めします。
実行環境に関わらず、DatabricksにおけるSQLは他の場所で実行されるApache Spark SQLと大きな違いはありません。3つの異なる計算資源に対して、一般的なクエリーやステートメントを実行するために、DatabricksでSQLを使用することができます。これらの環境のすべては、オープンソースApache Sparkで利用できない数多くのコマンドを追加しており、Delta Lakeに関連するすべてのSQLクエリーを実行できるように事前設定されています。
 Unity Catalogが有効化されたワークスペースでは、数多くの追加キーワードやコマンドを利用できます。ビルトインのHiveメタストアではなく、Unity Catalogに対して実行する際、いくつかのSQLコマンドは異なる挙動をすることに注意してください。
 これらの計算資源の選択肢のそれぞれでは、若干異なるセマンティックスと文法を持っています。一般的にいうと: 
 DatabricksランタイムコンピュートにおけるSQLは、オープンソースApache Sparkの処理と最も近いものになっています。
 Delta Live Tablesで実行されるSQLは、一般的にDatabricksランタイムの文法とセマンティクスを継承していますが、Delta Live Tables固有のキーワードや関数が追加されています。
 SQLウェアハウスで実行されるSQLは最もANSI標準に近いものとなっています。HiveQL、変数宣言、変数参照、DButilsウィジェットを含むDatabricksランタイムコンピュートに対してDatabricksノートブックで実行されるSQLでサポートされている多くの機能は、SQLウェアハウスでは動作しません。
Databricksは完全に自動化された機械学習機能と言われているAutoMLを提供しています。Databricks AutoMLはシチズンデータサイエンティストに対してガラスボックスアプローチを提供し、データの前処理、特徴量エンジニアリング、モデルトレーニング、チューニングのヘビーリフティングを自動化することで、チームはクイックに機械学習モデルを構築、トレーニング、デプロイすることができます。
 Databricksにおける機械学習に固有のものですが、UIで実行されたすべてのステップは、内部でプロダクションレベルのコードとして生成されます。
 エキスパートのデータサイエンティスト、機械学習エンジニアはコードを調査し、自身のカスタマイゼーションを追加することができ、規制に対応する部署は再現性や透明性が重要になるケースで、これらを参照することができます。Databricks Machine LearningはネイティブでMLflowとインテグレーションされており、前処理から特徴量エンジニアリング、トレーニング、デプロイメントに至るまで、きめ細かいエクスペリメント追跡やバージョン管理を実現します。
 完全なリネージトラッキングや自動生成コードの登録に関するDatabricksのサポートは、皆様のデータサイエンスプロジェクトがセキュアで、法令に準拠しており、追跡可能であることを保証します。特徴量の説明可能性は、生成されたモデルにおいてどの入力が最も重要であるのかに関する洞察を提供します。これによって、ユーザー、データサイエンティスト、機械学習エンジニア、IT、リーガル、コンプライアンス部門などさまざまなチームがコラボレーションする基盤を構築することができます。
チューニングを分散するには、fmin()の引数にSparkTrialsと呼ばれるTrialsクラスを追加します。
 1: SparkTrialsは2つのオプションの引数を受け取ります: 
 parallelism: 同時にフィット、評価するモデルの数。デフォルトは利用可能なSparkタスクのスロット数です。
 2: timeout: fmin()を実行できる最大時間(秒数)です。デフォルトは時間制限はありません。
Hyperoptのワークフローにおけるステップは以下の通りです: 
 1: 最小化する関数を定義 
 2:ハイパーパラメーターに対する探索空間を定義 
 3: 探索アルゴリズムを選択 
 4: Hyperoptのfmin()を用いてチューニングアルゴリズムを実行 
 詳細はHyperopt documentationをご覧ください。
トランスフォーマーモデルは、これまでの手法よりも効果的かつ効率的にテキストのセマンティックを捕捉するセルフアテンションというニューラルネットワークアーキテクチャを活用しています。また、これらは、モデルの開発者によってmasked language modelingやnext sentence predictionのようなテクニックを用いて大規模テキストコーパスによってトレーニングされたことを意味する転送学習という形態を取ります。
Hugging Faceはトランスフォーマーモデルを発見・アクセスしやすくすることにフォーカスしている企業です。多様なモデルやデータセットへのアクセスを提供しています。Hugging Faceによってメンテナンスされているtransformersライブラリを用いることで、お使いのDatabricksワークスペースでアーティファクトをダウンロードし、使用することができます。このライブラリはDatabricks機械学習ランタイムバージョン10.4以降に含まれており、それより新しいバージョンではpipでインストールすることができます。
トークナイザーはいくつかの前処理ステップを実行します。最初に、テキストをトークンに分割し、トークンをモデルのボキャブラリーにマッピングします。BERTのボキャブラリは、単語、単語の断片、数字、句読点や記号の30,522エントリーから構成されています。また、モデルには観測の開始地点([CLS])や文の区切り([SEP])のような情報を捕捉する特殊なトークンが含まれています。
 また、トークナイザーは入力シーケンスの切り取りとパディングを行います。それぞれのモデルには、許容できるトークン化シーケンスの最大長を持っています。BERTや多くの他のモデルでは、その長さは512トークンです。入力テキストをトークン化する際、最初の512トークン以降に生成されたすべてのトークンは削除、あるいは「切り取られ」ます。
 さらに、トークンのシーケンスは「パディング」されます。トランスフォーマーモデルは、一度のすべてのトレーニングデータセットに対してトレーニングするのではなく、データのバッチに対してトレーニングされます。それぞれのバッチは同じ長さである必要がありますが、観測されるテキストの長さは大きく異なります。トークン化されたあるシーケンスは512要素よりもはるかに長いかも知れませんし、他のものははるかに短いかもしれません。均一な長さにする必要がある際、パディングによってトークン化されたシーケンスにゼロが追加されます。ゼロの値はBERTのボキャブラリの特殊トークンである[PAD]を表します。
 トークナイザーの切り取りとパディングの挙動は設定可能であり、テストし比較することができる様々な戦略が存在します。トレーニング時間を短縮するために切り取りを行いますが、より長いシーケンスが一般的である場合、情報の損失によって予測パフォーマンスの妨げになることがあります。優れた汎用的な戦略としてdynamic paddingを検討してください。このテクニックはトークン化ではなくモデルトレーニングの際にシーケンスをパディングします。ダイナミックパディングは、バッチで最長の長さにそれぞれのバッチをパディングし、パディングされるトークンの数が最小になるように維持します。
モデルのトレーニング時間を削減し、推論をスピードアップする方法があります。
 モデルのファミリーにdistilled models(蒸留モデル)というものがあり、これは大規模なモデルである「教師」を小規模なバージョンである「生徒」に圧縮することで、モデルのサイズと計算処理の複雑度を削減します。Hugging Faceモデルハブにおいては、通常これらのモデルの名前にはdistilが含まれており、distilbert-base-uncasedといったものとなります。蒸留モデルはよりクイックにファインチューンし、大規模な教師よりも高速に推論を行うことができます。以下のエクスペリメントでは、映画のレビューと感情を含むIMDB datasetに対するモデルを比較しています。モデルサイズ、GPUメモリー消費、トレーニング時間、すべての評価用データセットのスコアリングに要した時間の大きな違いに注意してください。興味深いことに、予測パフォーマンスはモデル全体で大きな違いはありません。
 蒸留の他に、トレーニングの設定とGPUタイプは大きなインパクトをもたらします。ファインチューニングのプロセスを管理するトランスフォーマーのTrainerクラスの設定を調整することで、トレーニングと推論の時間を劇的に削減することができます。IMDBデータセットに対してモデルのファインチューニングを行う際、バッチサイズやトレーニングにおける数値精度、勾配集積ステップに関係する設定の調整は、単一のトレーニングエポックにおけるトレーニングと推論の時間の大きな削減につながりました。
 さらに、GPUタイプの選択はトレーニングと推論の時間にインパクトを与えます。
 GPUインスタンスはトレーニングに必要で、推論も劇的に高速化しますが、GPUの推論はオプションです。CPUによる推論を加速するには量子化と蒸留モデルの使用を検討してください。量子化は、推論のレーテンシーを削減するために、高速でより精度の低い数値表現を使用します。これは、ファインチューンされたトランスフォーマーモデルに容易に適用することができます。
正当なワークフローにおいて制限に到達した場合は、以下のことを行うことを推奨しています。
 ・数分後にリクエストをリトライします。
 ・計画された時間フレームで繰り返されるワークフローを均等に分散します。例えば、1時間ごとに全てのジョブをスケジュールするのではなく、1時間で異なる間隔にジョブを分散します。
 ・クラスターをより大きなノードタイプにし、ノード数を削減することを検討します。オートスケーリングクラスターを使用します。
 これらの選択肢がうまく行かない場合、コア数に対する制限増加をリクエストするためにDatabricksサポートにコンタクトしてください。
 Databricksによる他の停止理由に関しては、Termination Codeをご覧ください。
原因はいくつあります。
 1: クラスターのタイムアウト。外部のHiveメタストアに接続しており、MavenリポジトリからすべてのHiveメタストアライブラリをダウンロードしようとする際、起動に失敗することがあります。クラスターは依存関係を含む約200個のJARファイルをダウンロードします。Databricksのクラスターマネージャがドライバーノードが5分以内に準備できたことを確認できない場合、起動に失敗します。これは、JARのダウンロードに時間がかかりすぎることによって発生します。
 2: グローバルあるいはクラスターのinitスクリプト。クラスターの起動ステージにおいて実行されるinitスクリプトは、スクリプトをワーカーのローカルで実行するためにそれぞれのワーカーマシンにRPC(リモートプロシージャコール)を送信します。すべてのRPCはプロセスを継続する前に自分のステータスを返信しなくてはなりません。(ネットワークの問題などによって)いずれかのRPCに問題が生じて返信せず、1時間のタイムアウトになる場合があり、結果としてセットアップのジョブが失敗します。
 3: クラスターUIでインストールしたライブラリが多すぎる。通常このエラーはクラウドプロバイダーによって引き起こされます。
 4: クラウドプロバイダーによるシャットダウン。通常このエラーはクラウドプロバイダーによって引き起こされます。
 5: インスタンスに到達できない(Azure)。通常このエラーはクラウドプロバイダーによって引き起こされます。特に、(新規のAzure Databricksワークスペースを起動する際に作成されるデフォルトのVNetではなく)自分のバーチャルネットワーク(VNet)にAzure Databricksワークスペースをデプロイした際に発生します。ワークスペースがデプロイされているバーチャルネットワークがすでにオンプレミスのリソースに対するExpressRoute接続とピアリングしてるあるいは接続を有している場合、Azure Databricksがクラスターを作成しようとした際、バーチャルネットワークはクラスターノードにssh接続を行うことができません。
ワークフローにおけるdbtサポートによって、お使いのdbtプロジェクトがGitリポジトリから取得され、dbt-coreとプロジェクトの依存関係がインストールされたシングルノードクラスターが起動されます。dbtによって生成されたSQLはサーバレスSQLウェアハウスで実行され、容易なデバッグと優れたパフォーマンスを提供します。また、失敗したジョブの復旧や、dbtタスクが失敗した際にSlackやwebhookを通じたアラートの送信のような堅牢かつ運用向けの機能、Jobs APIを通じたログのようなdbtアーティファクトの取得やジョブの管理機能もあります。
GPUクラスターの作成は他のSparkクラスターの作成と同様です(Databricksクラスターをご覧ください)。以下に注意する必要があります。
 Databricks Runtime Versionは、**Runtime 9.1 LTS ML (GPU, Scala 2.12, Spark 3.1.2)**のようにGPU有効化バージョンである必要があります。
 Worker TypeとDriver TypeはGPUインスタンスタイプである必要があります。
 Sparkを必要としないシングルマシンのワークフローにおいては、ワーカー数をゼロに設定することができます。
Databricksでは以下のGPU高速化インスタンスタイプをサポートしています。
 ・P2 instance type series: p2.xlarge, p2.8xlarge, p2.16xlarge。P2インスタンスは特定のAWSリージョンでのみ使用できます。詳細については、Amazon EC2 Pricingをご覧ください。GPU有効化クラスターを起動するために、ご自身のDatabricksデプロイメントがサポートされているリージョンに存在している必要があります。P2インスタンスのオンデマンドのデフォルト制限数は1です。P2インスタンスではストレージのためのEBSが必要です。
 ・P3 instance type series: p3.2xlarge, p3.8xlarge, p3.16xlarge。P3インスタンスは特定のAWSリージョンでのみ使用できます。詳細については、Amazon EC2 Pricingをご覧ください。GPU有効化クラスターを起動するために、ご自身のDatabricksデプロイメントがサポートされているリージョンに存在している必要があります。
 ・P4d instance type series: p4d.24xlarge。P4dインスタンスではDatabricksランタイム9.1 LTS ML以降が必要です。
 ・プロダクションに機械学習モデルをデプロイすることに最適化されているG4 instance type series　
 ・画像を大量に使用する様々なユースケースや機械学習ユースケースで使用できるG5 instance type series。G5インスタンスではDatabricksランタイム9.1 LTS ML以降が必要です。
 すべてのGPU高速化インスタンスタイプでは、以下のことに留意してください。
 ・Amazonのスポットインスタンス価格の高騰によって、GPUスポットインスタンスを保持することは困難です。必要であればオンデマンドを使用してください。
 ・GPU有効化クラスターを作成するためには、制限の増加をリクエストする必要があるかもしれません。
 ・サポートされているGPUインスタンスタイプとそれらの特性の一覧については、Supported Instance Typesをご覧ください。
Wikipediaで調べると次のように書かれています。
 名称は Digital Imaging and Communications in Medicine（医療におけるディジタル画像と通信） の略である。米国放射線学会（英語版）とアメリカ電機工業会が制定した規格で、異なる製造業者の医用画像機器間で画像転送を可能とすることを目的としている。
 要するに、医療用の画像データのようです。拡張子は「dcm」。
 ダブルクリックして開けるようなものではなく、「DICOMビューア」というツールを使って画像を表示する必要があるようです。
VScodeをサポートしています。VS Code Extension for Databricksという機能によって、開発者はローカルでコードを記述し、IDEのパワフルなオーサリング機能を活用しつつも、リモートのDatabricksクラスターに接続することができます。IDEによって、開発者は大規模なコードベースにおいて必要となるソースコード管理、モジュール化されたコードのレイアウト、リファクタリングのサポート、インテグレーションされたユニットテストのようなベストプラクティスを活用することができます。
 これは開発プロセスでIDEを活用しているチーム向けに計画されている数多くのリリースの最初の一つとなります。Databricksでは、開発者のエコシステムに多大なる投資をしており、今後は他のIDEのサポートや追加のツールがロールアウトされます。
様々なインテグレーションを提供しています。Partner Connect: Partner Connectは、お使いのDatabricksクラスターやSQLウェアハウスとよりクイックかつ簡単にインテグレーションするための検証済みソリューションに対するユーザーインタフェースです。
 データソース: DatabricksはCSV、Delta Lake、JSON、Parquet、XMLなどの様々なデータフォーマットや、Amazon S3、Google BigQueryやCloud Storage、Snowflakeなどのデータストレージプロバイダーのデータを読み書きすることができます。
 BIツール: Databricksでは、Power BI、Tableauなどを含むお使いのBIツールとのインテグレーションを検証しており、多くの場合、ローコードやノーコードの体験でDatabricksクラスターやSQLウェアハウスを通じてデータを操作することができます。
 その他のETLツール: すべてのタイプのデータソースに対するアクセスに加えて、Databricksではdbt、Prophecy、Azure Data FactoryのようなETL/ELTツール、Airflowのようなデータパイプラインオーケストレーションツール、DataGrip、DBeaver、SQL Workbench/JのようなSQLデータベースツールとのインテグレーションを提供しています。
 IDEとその他の開発ツール: Databricksでは、DataGrip、IntelliJ、PyCharm、Visual Studio Codeのような開発ツールをサポートしており、コードを記述することでDatabricksクラスターやSQLウェアハウスを通じてデータを操作することができます。
 Git: Databricks Reposは、お使いのGitプロバイダーとのリポジトリレベルのインテグレーションを提供するので、Databricksノートブックでコードを開発し、リモートのGitリポジトリと同期することができます。Databricks ReposによるGit連携をご覧ください。
Databricks外部からDatabricksにアクセスする際に必要になるトークンです。トークン作成権限がない場合には、Databricks管理者にこちらの手順に従って機能を有効化するよう依頼してください。
 1: Databricksワークスペースにログインします。
 2: サイドバーのペルソナスイッチャーからSQLを選択して、Databricks SQLにアクセスします。
 3: トップバーのご自身のユーザー名をクリックし、ユーザー設定を選択します。
 4: Personal access tokensタブをクリックします。
 5: 新規トークンを生成ボタンをクリックします。
ワークスペースでパーソナルアクセストークンを作成する機能が有効化されている場合、ワークスペース管理者は、トークンを監視し、どの非管理者ユーザーがトークンを作成、使用できるのかを管理し、新規トークンにおける最大有効期限を設定することもできます。
 ワークスペースでパーソナルアクセストークンを生成する機能が有効化されると、デフォルトではDatabricksワークスペースのすべてのユーザーがDatabricks REST APIにアクセスするためにパーソナルアクセストークンを生成することができ、無期限のトークンを含み好きな有効期限でトークンを生成することができます。
 Databricks管理者としては、よりきめ細かいレベルでトークン使用をコントロールするために、Token Management API 2.0やPermissions API 2.0を活用することができます。これらのAPIはそれぞれのワークスペースインスタンスで公開されています。どのようにAPIにアクセスし、認証を受けるのかに関しては、Databricksパーソナルアクセストークンを用いた認証をご覧ください。Databricks管理者としてAPIにアクセスする必要があります。
 いくつかのタスクに関しては、管理コンソールを活用することもできます。
Delta Lakeでは、Deltaテーブルの他のカラムに対するユーザー定義関数に基づいて自動的に生成される値を持つ特殊なタイプのカラムをサポートしています。自動生成されたカラムはgenerated columnと言います。generated columnを有するテーブルに書き込みを行う際、それらのカラムに対して明示的に値を指定する必要はなく、Delta Lakeは自動で値を計算します。例えば、(日付でテーブルをパーティショニングするために)タイムスタンプのカラムから自動で日付のカラムを生成することができます。テーブルに書き込みを行う際に必要なのはタイムスタンプのカラムのデータを指定することだけです。しかし、明示的に値を指定する際には、値は制約(<value> <=> <generation expression>) IS TRUEを満足する必要があり、そうでない場合には書き込みはエラーとなり失敗します。generated columnを持つテーブルでは、デフォルトよりも新しいテーブルライタープロトコルが必要となります。テーブルプロトコルのバージョンが何で、新しいテーブルプロトコルのバージョンを設定することが何を意味するのかを理解するためには、Delta Lakeのテーブルプロトコルのバージョン管理をご覧ください。