bowang0911/databricks-qa-ja huggingface dataset:
generated columnは通常のカラムと同じように格納されます。すなわち、ストレージを消費します。
 generated columnには以下の制約があります。
 ・生成のエクスプレッションには、以下のタイプの関数を除いて同じ引数を与えた際に同じ結果を常に返却するSparkにおけるSQL関数を使用することができます。
 ・ユーザー定義関数
 ・集計関数
 ・ウィンドウ関数
 ・複数の行を返す関数
 ・Databricksランタイム8.4以降でのPythonサポートでは、Delta Lakeはパーティションカラムが以下のエクスプレッションのいずれかで定義された際には常に、クエリーに対するパーティションフィルターを生成することができます。
 ・CAST(col AS DATE)およびcolの型がTIMESTAMP
 ・YEAR(col)およびcolの型がTIMESTAMP YEAR(col), MONTH(col)によって2つのパーティションカラムが定義され、colの型がTIMESTAMP
 ・YEAR(col), MONTH(col), DAY(col)によって3つのパーティションカラムが定義され、colの型がTIMESTAMP
 ・YEAR(col), MONTH(col), DAY(col), HOUR(col)によって4つのパーティションカラムが定義され、colの型がTIMESTAMP
 ・SUBSTRING(col, pos, len)であり、colの型がSTRING
 ・DATE_FORMAT(col, format)であり、colの型がTIMESTAMP
 ・上述のエクスプレッションのいずれかでパーティションカラムが定義され、生成エクスプレッションのベースとなるカラムを用いてクエリーがデータをフィルタリングする際、Delta Lakeはベースのカラムと生成されたカラムの関係性を参照し、可能であれば生成されたパーティションカラムに基づいてパーティションフィルターを生成します。例えば、以下のテーブルを考えます。
様々な改善方法があります。ここでは2つの方法を紹介します。1. カラムによるZ-order。Z-Orderingによって関連する情報を同じファイルセットに共存させることができます。この局所性は読み込むべきデータの量を劇的に削減するために、Delta Lakeによるデータスキッピングアルゴリズムによって自動的に活用されます。データをZ-Orderするには、ZORDER BY句に並び替えるカラムを指定します。genderでZ-Orderするには以下を実行します。
 2: VACUUMによるスナップショットのクリーンアップ。Delta Lakeは読み込みにおいてスナップショットのアイソレーションを提供し、これはユーザーやジョブがテーブルにクエリーを行っている際においてもOPTIMIZEを安全に実行できることを意味します。しかし、最終的には古いスナップショットを削除しなくてはならなくなります。VACUUMコマンドを実行することでこれを実現することができます。
Databricks Labsのdbxを活用することで、ご自身のローカル開発マシンにあるファイルの変更をDatabricksワークスペースで対応するファイルにリアルタイムで同期することができます。これらのワークスペースファイルはDBFSあるいはDatabricks Reposに格納することができます。
 dbxによるリアルタイムファイル同期(dbx sync)は、迅速なコード開発シナリオで有用です。例えば、シンタックスのハイライト、スマートなコードコンプリーション、コードリンティング、テスト、デバッグのような生産性を高める機能のためにローカルの統合開発環境(IDE)を活用することができます。そして、更新したコードをワークスペースですぐに実行することができます。
 自動化ジョブやIDEでdbx syncを活用することができます。
dbx syncの開発ワークフローには2つあり、DBFSを用いるものとDatabricks Reposを用いるものです。
 dbx syncとDBFSによる典型的な開発ワークフローは:
 1. DBFSに同期したいファイルを格納するローカルディレクトリを特定します。
 2. ローカルディレクトリを同期するDBFSのパスを特定します。
 3. ローカルディレクトリをDBFSパスに同期するためにdbx sync dbfsを実行します。dbx syncがローカルディレクトリにおけるファイルの変更の監視をスタートします。
 4. 必要に応じてローカルディレクトリのファイルを変更します。dbx syncがこれらの変更をリアルタイムでDBFSで対応するファイルに適用します。
 dbx syncとDatabricks Reposによる典型的な開発ワークフローは: 
 1. 使用できるリポジトリが無い場合には、Databricks ReposをサポートするGitプロバイダーのリポジトリを作成します。
 2.Databricksワークスペースにリポジトリをクローンします。
 3. ローカル開発マシンにリポジトリをクローンします。
 4. ローカルにクローンされたリポジトリとワークスペースにクローンされたリポジトリを関連づけるためにdbx sync repoを実行します。dbx syncがローカルディレクトリにおけるファイルの変更の監視をスタートします。
 5. 必要に応じてローカルにクローンしたリポジトリのファイルを変更します。dbx syncがこれらの変更をリアルタイムでDatabricks Reposで対応するファイルに適用します。
 6. リポジトリがお使いのGitプロバイダーと同期されるように、ワークスペースにクローンしたリポジトリから定期的にGitプロバイダーにプッシュします。
はい、サポートしています。画面右のメニューにが{x},表示されるようになります。
コードを実行し、変数が生成された状態で{x},をクリックして、変数エクスプローラを展開することで、変数の中身を確認することができるようになります。
 値、データ型、形状が表示されます。なお、PySparkデータフレームに関しては、形状の計算に計算リソースを必要とするので、行数は?と表示されます。
サブネットのサイズはお客様によって異なります。しかし、あなたのレイクハウスアーキテクチャで必要となるであろうApache Spark (™)ノード数を計算することで推定することは可能です。それぞれのノードでは2つのプライベートIPアドレスが必要となり、一つはトラフィックの管理、もう一つはApache Spark (™)アプリケーション用です。ワークスペースでネットマスク/26のサブネットを二つ作成すると、単一のサブネットで合計64個のIPアドレスを作成できることになり、AWSが最初の4つのIPアドレスと最後のIPアドレスを使用するので、59個が利用できることになります。これは、最大約32ノードを使用できることを意味します。最終的には、サブネットをのサイズを適切に設定するために、より小さい大量のサブネット(US-EAST-1での6サブネットなど)やより大きい少数のサブネットを経由するのかなど、皆様のユースケースから逆算することが可能です。
アドレス空間11.34.88.0/21のVPCを5つのワークスペースにブレークダウンしてみましょう。その後では、使用法に基づいて適切なワークスペースにユーザーを割り当てなくてはいけません。もし、ユーザーが数百Gバイトのデータを処理するために非常に大きいクラスターを必要としているのであれば、彼らをX-Largeに割り当ててください。もし、小規模なデータのサブセットに対してインタラクティブな分析を行うのであれば、smallワークスペースに割り当ててください。
クラスターをデプロイやリサイズする際に、IP枯渇によってエンドユーザーがインパクトを受けないように、アカウントレベルでサブネットが重複しないことを強制しています。これが、企業のデプロイメントにおいて、同じサブネットに他のリソースを配置しないよう警告している理由です。単一のワークスペースでIPの利用を最適化するために、すべてのクラスターで自動アベイラビリティゾーン(auto-AZ)のオプションを使用することをお勧めしています。
 そして、顧客管理VPCではVPCやサブネットを移動するなど、必要に応じていつでもネットワーク設定を切り替えることができることを覚えておいてください。
我々はサブネットに対してデフォルトのNACLルールが使用される多層セキュリティモデルを使用していますが、EC2インスタンスに対して厳しいセキュリティグループルールによってさらにリスクを軽減することができます。さらに、多くのお客様は公衆インターネット向けのすべてのアウトバウンドアクセスを制限するために、ネットワークファイアウォールを追加しています。こちらに、不正あるいは意図しない攻撃者からデータを防御する方法を説明している、データ漏洩防御に関する記事があります。
はい。PrivateLinkが有効化されたワークスペースを作成する際、プライベートアクセスオブジェクト、PASを作成する必要があります。PASには公衆回線によるアクセスを有効にするか、無効にするかのオプションがあります。ワークスペースのURLはインターネット上で有効ですが、PASの公衆回線アクセスがfalseに設定されており、ユーザーがVPCエンドポイント経由でルーティングされていない場合、不正なネットワークからワークスペースにアクセスしたと判断されサインインすることはできません。エンタープライズのお客様がフロントエンドPrivateLink接続の代わりに用いているのは、IPアクセスリストです。
はい、可能です。しかし、依然としてS3ゲートウェイエンドポイント、Kinesisインタフェースエンドポイント、STSインタフェースエンドポイントは必要です。あと、DatabricksのデフォルトHiveメタストアや、PyPI、Mavenのようなリポジトリにアクセスできないことに注意してください。デフォルトHiveメタストアにアクセスできないので、自身のRDSインスタンスあるいはAWS Glue Catalogを使用する必要があります。そして、パッケージに関しては、ご自身の環境でリポジトリをホストする必要があります。これらの理由から、代わりにユーザーのクラスターが公衆インターネットのどの領域にアクセスできるのかを制限するために、外向け通信のファイアウォールをお勧めしています。
S3エンドポイントはEC2がルートバケットに到達するために必要なだけではなく、あなたのデータを格納しているS3にアクセスするために必要となります。これによって、費用を削減し、S3へのトラフィックをAWSバックボーンに保持することで、さらなるセキュリティ層を追加することになります。Kinesisは、重要なセキュリティ情報、監査情報などを含むクラスターから収集される内部ログのためのものです。STSはEC2インスタンスに引き渡される一時的な資格情報のためのものです。
はい、必要なリソースに対してのみクロスアカウントを制限することをお勧めしています。ドキュメント(https://docs.databricks.com/administration-guide/cloud-configurations/aws/iam-role.html#customer-managed-vpc-with-custom-policy-restrictions)でポリシーを参照することができます。他の適用できる制限として、同じページで説明されていますがソースとなるEC2 AMIを制限するということです。あと、ドキュメントでUnity Catalog(https://qiita.com/taka_yayoi/items/3f2df6ddea81521ee786#aws%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%83%90%E3%82%B1%E3%83%83%E3%83%88%E3%81%A8iam%E3%83%AD%E3%83%BC%E3%83%AB%E3%81%AE%E8%A8%AD%E5%AE%9A)とサーバレス向けの適切なIAMロールを参照することができます。
はい、可能です。言っていただいて助かりました。デプロイメントの一部として、あるいは後で追加する設定として、マネージドストレージやワークスペースストレージに対して顧客管理キーを追加することができます。
 ・ワークスペースストレージ: 上述したルートバケット、EBSボリューム、ジョブの実行結果、Delta Live Tablesなどを格納します。
 ・マネージドストレージ: ノートブックソースやメタデータ、パーソナルアクセストークン、Databricks SQLのクエリーを格納します。
Unity Catalogを使用するためにどのようにDatabricksアカウントをセットアップするのか、どの様に最初のテーブルを作成するのかに関して、ハイレベルの概要を説明します。Unity Catalogを使えるようにDatabricksアカウントを有効化するには、以下の手順を踏んでください。
 1. Unity CatalogがあなたのAWSアカウントにデータを格納、アクセスできるようにS3バケットとIAMロールを設定します。
 2. 皆様の企業が利用しているリージョンのそれぞれにメタストアを作成します。このメタストアは、Unity Catalogのすべてのデータに対するトップレベルのコンテナとして動作します。メタストアの作成者として、あなたはオーナーでありメタストアの管理者となります。
 3. メタストアにワークスペースをアタッチします。それぞれのワークスペースでは、Unity Catalogで管理するデータに対して同じビューを持つことになります。
 4. Databricksアカウントにユーザー、グループ、サービスプリンシパルを追加します。既存のDatabricksアカウントにおいては、これらのIDは既に表示されます。
 5. (オプション)メタストア管理者のロールをグループに移譲します。
 ユーザーに対するデータアクセスをセットアップするには、以下の手順を踏みます。
 1.ワークスペースで少なくとも1つの計算資源、クラスターかSQLウェアハウスを作成します。Unity Catalogによって保護されるデータオブジェクトに対するgrant文を含み、クエリーやコマンドの実行にこの計算資源を使用します。
  2. 少なくとも1つのカタログを作成します。カタログはあなたが操作するテーブルを保持するスキーマ(データベース)を保持します。
 3. 少なくとも1つのスキーマを作成します。
 4. テーブルを作成します。
 データ階層のそれぞれのレベル(カタログ、スキーマ、テーブル)において、ユーザー、グループ、サービスプリンシパルに対して権限を付与します。また、dynamic viewsを用いて行・列レベルのアクセス権を付与することができます。
はい、あります。Databricksでは、それぞれが異なるタイプのワークロードに適した5つのコンピュートタイプを提供しています。
 ・ジョブコンピュート: スケーラブルかつ高信頼性の計算資源でデータエンジニアリングやMLワークロードを実行します。プロダクションワークロードで使用することを強くお勧めします。
 ・汎用コンピュート: インタラクティブなデータサイエンス、分析ワークロード向けに設計されています。
 ・SQL Pro: 高い同時実行性、低レーテンシーワークロード向けに設計された計算資源でBIや分析ワークロードを実行します。
 ・サーバレスSQL: SQL Proの全機能に加え、Databricksによって管理される最適化計算資源フリートを通じて提供される高速な起動時間とオートスケールを実現します。
 ・SQL Classic: お使いのデータレイクからタイムリーに洞察を得るために、BIレポート、分析、ビジュアライゼーションのためにSQLクエリーを実行します。
データガバナンスはデータが確実に価値をもたらし、皆様のビジネス戦略をサポートするための監視機能です。データガバナンスは、組織内のデータ資産をセキュアに管理するために実装されるポリシーとプラクティスをカプセル化します。データの量と複雑性は増加し続けており、コアとなるビジネス成果を確実なものとするために、より多くの企業がデータガバナンスを必要としています。
 分析や機械学習の基礎としての一貫性があり高いデータ品質。
 洞察に至る時間の短縮。
 組織の誰もがデータドリブンの意思決定を行えるようにするデータの民主化。
 HIPAA、FedRAMP、GDPR、CCPAのような業界規制に対するリスクとコンプライアンスのサポート。
ユーザーが大規模なクラスターを起動することを防ぎ、高価なGPUインスタンスを使用する際のガードレールを作成すること等によるコストの最適化。
データドリブンの企業は多くの場合、レイクハウス上に分析のためのデータアーキテクチャを構築しています。データレイクハウスは、データレイクに格納されている膨大な量のデータに対して直接、効率的かつセキュアなデータエンジニアリング、機械学習、データウェアハウス、ビジネスインテリジェンスを可能とするアーキテクチャです。データレイクハスのデータガバナンスは、以下のような主要な機能を提供します: 
 統合されたカタログ: 統合されたカタログは、それぞれのデータオブジェクトのメタデータに加えて、すべてのデータ、MLモデル、分析のアーティファクトを格納します。また、統合されたカタログは既存のHiveメタストアのような他のカタログのデータも組み合わせます。
 統合されたデータアクセスコントロール: すべてのデータ資産、すべてのクラウドに対して単一かつ統合された権限モデル。これには、個人識別情報(PII)に対する属性ベースのアクセスコントロール(ABAC)も含まれます。
 データ監査: 説明可能性を高めるために、アラートとモニタリング機能を用いて集中的にデータアクセスが監査されます。
 データ品質管理: 後段のBI、分析、機械学習ワークロードで高精度かつ有用なデータが活用されるように、ビルトインの品質管理、テスト、モニタリング、強制を用いた堅牢なデータ品質管理。
 データリネージ: ソースから利用に至るレイクハウスにおけるデータフローに対するエンドツーエンドの可視性を提供するデータリネージ。
 データディスカバリー: データサイエンティスト、データアナリスト、データエンジニアが適切なデータをクイックに発見、参照し、価値創出に至る時間を短縮できるようにする簡単なデータ発見。
 データ共有: クラウド、プラットフォーム横断でデータを共有。
Databricksでは、Unity CatalogとDelta Sharingを用いて、データとIAに対する集中管理されたガバナンスを提供します。
 Unity Catalogは、DatabricksレイクハウスにおけるデータとAIに対する高精細なガバナンスソリューションです。データアクセスを管理し、監査する集中管理の場所を提供すすることで、データに対するセキュリティとガバナンスをシンプルにする役に立ちます。
 Delta Sharingは、使用している計算プラットフォームに関係なく、別の組織や組織内の別チームとセキュアにデータ共有するために、Databricksによって開発されたオープンプロトコルです。Unity CatalogとDelta Sharingを導入する際のベストプラクティスに関しては、Databricks Unity Catalogのベストプラクティスをご覧ください。
 すべての優れたデータガバナンスの物語は、強力なアイデンティティ基盤からスタートします。Databricksにおけるアイデンティティ設定のベストプラクティスについては、Databricksにおけるアイデンティティ管理のベストプラクティスをご覧ください。
Unity Catalogには3レベルの名前空間記述を採用しています。
Unity Catalogにおいて、テーブルやビューは親のカタログやスキーマに格納されます。2つの異なる記述スタイルでテーブルやビューを参照することができます。カタログやスキーマを指定するためにUSE CATALOG文とUSE文を使用することができます。
 あるいは、3レベル名前空間記述を使うことができます。
 3レベルの名前空間記述を用いることで、複数のカタログやスキーマのデータに対するクエリーをシンプルなものにします。
 また、<catalog_name>をhive_metastoreに設定することで、Hiveメタストアのデータに対する3レベル名前空間記述を使用することができます。
DatabricksワークスペースとGitリポジトリを同期できるDatabricks Repos(Repositoryの複数形を略してReposです)という機能があるのですが、このRepo(リポジトリ)配下にはノートブック以外にもPythonスクリプトやCSVファイルを格納することができます。これらのファイルをワークスペースファイル(Workspace File)と呼びます。リポジトリに格納されているノートブックからこれらのファイルを操作することができます。
Databricks Reposに格納されている任意のファイルをプログラムで操作することができます。これによって、以下のようなタスクを行えるようになります。
 ノートブックやコードと一緒に小規模なデータファイルを格納する。
 Gitと同期されるディレクトリにログファイルを書き込む。
 相対パスを用いてモジュールをインポートする。
 環境設定ファイルを作成、修正する。
 ノートブックから出力を書き込む。
 Tensorboardのようなライブラリの実行結果を書き込む。
クラウドコンピューティングにおいて、オブジェクトストレージやblobストレージはデータをオブジェクトとして保持するストレージコンテナのことを指し、それぞれのオブジェクトはデータ、メタデータ、グローバルにユニークな識別子(URI)から構成されます。オブジェクトストレージにおけるデータ操作のオペレーションは多くの場合、REST APIインタフェースを通じた作成、読み込み、更新、削除(CRUD)に限定されます。いくつかのオブジェクトストレージは、バージョン管理やライフサイクル管理のような機能を提供しています。オブジェクトストレージには以下のメリットがあります: 
 1. 高い可用性、堅牢性、信頼性。
 2. 他の多くのストレージオプションと比較して低いストレージコスト。
 3. 無限にスケール(クラウドの特定のリージョンで利用できるストレージの総量に制限されます)。
 多くのクラウドベースのデータレイクは、クラウドオブジェクトストレージにおけるオー文ソースデータフォーマットを基盤として構築されます。
オブジェクトストレージは、Databricksのほとんどのオペレーションで使用される主要なストレージとなります。Databricksファイルシステム(DBFS)によって、Databricksユーザーは他のファイルシステムと同じように、オブジェクトストレージのオブジェクトのファイルを操作することができます。外部のデータシステムに対するテーブルを設定しない限り、Databricksで作成されるすべてのテーブルのデータはクラウドオブジェクトストレージに格納されます。
 クラウドオブジェクトストレージに格納されるDelta Lakeのファイルは、Databricksレイクハウスのデータ基盤となります。
Databricksでは、データファイルとテーブルを格納するためにクラウドオブジェクトストレージを活用します。ワークスペースをデプロイする際、DatabricksはDBFSルートと呼ばれるクラウドオブジェクトストレージロケーションを設定します。お使いのアカウントの他のクラウドオブジェクトストレージロケーションへの接続を設定することができます。
 ほぼすべてのケースにおいて、DatabricksでApache Sparkを用いて操作するデータファイルはクラウドオブジェクトストレージに格納されます。
クラウドコンピューティングにおいて、ブロックストレージやディスクストレージは、単に「ハードドライブ」とも呼ばれる従来型のハードディスクドライブ(HDD)やソリッドステートドライブ(SSD)を指します。クラウドコンピューティング環境にブロックストレージをデプロイする際、通常は1つ以上の物理ドライブの論理的なパーティションがデプロイさmれます。製品やクラウドベンダーによって実装が若干異なりますが、多くの場合、以下のような特性が共通しています。
 すべての仮想マシン(VM)はアタッチされたブロックストレージボリュームを必要とします。
 ブロックストレージボリュームが永続化されている限り、ブロックストレージボリュームにインストールされたファイルやプログラムは永続化されます。
 ブロックストレージボリュームは多くの場合、一時的なデータストレージとして使用されます。
 VMにアタッチされたブロックストレージボリュームは通常VMとともに削除されます。
計算リソースを起動する際、DatabricksはVMをデプロイし、ブロックストレージボリュームをアタッチします。このブロックストレージは、計算資源の寿命における一時的データファイルの格納に用いられます。これらのファイルには、オペレーティングシステム、インストールされたライブラリ、ディスクキャッシュで用いられるデータが含まれます。Apache Sparkは効率的な並列処理やデータロードのためにバックグラウンドでブロックストレージを使用しますが、Databricksで実行されるコードのほとんどはブロックストレージに対して直接データの読み書きをしません。
 お使いのドライバーノードにアタッチされたブロックストレージを使用するPythonやBashコマンドのような任意のコードを実行することができます。ドライバーのファイルシステムのファイルにアクセスするをご覧ください。
 ワークスペースファイルが有効化されたワークスペースでは、Pythonユーザーはドライバーのブロックストレージを操作することなしに、ノートブックと一緒に格納されているファイルやデータを読み書きすることができますプログラムでDatabricksワークスペースのファイルを操作するをご覧ください。
ビューはメタストアにある1つい上のテーブルやビューから構成される読み取り専用オブジェクトです。Unity Catalogの3レベル名前空間の3層目に存在します。ビューは複数のスキーマ、カタログに存在するテーブルやビューから作成することができます。
 ダイナミックビューは、行列のアクセス制御、データマスキングを提供するために使用されます。
 ビュー作成構文のサンプルは以下のようになります。
 '''CREATE VIEW main.default.experienced_employee　
 (id COMMENT 'Unique identification number', Name) 
 COMMENT 'View for experienced employees' 
 AS SELECT id, name 
  FROM all_employee 
  WHERE working_years > 5;'''
Visual Studio Codeで開発したローカルコードをリモートワークスペースのコードと同期させることができます。
 Visual Studio Codeで開発したローカルのPythonコードファイルを、リモートワークスペースのDatabricksクラスタ上で実行します。
 Visual Studio Code からローカルの Python コードファイル (.py) および Python ノートブック (.py と .ipynb) を、リモートワークスペース内の自動化されたDatabricks ジョブとして実行します。
Feature Store(特徴量ストア)は、データサイエンティストが特徴量を格納、検索、共有できるようにする集中管理されたデータリポジトリです。Feature Storeは、モデルトレーニングと推論で特徴量を計算するために同じコードが使用されることを確実にします。これによって、モデル作成者がアクセスできる整理されたデータセットが生成され、彼らはトレーニングの際にも、モデルデプロイの際にも活用できることを知りながらそのデータセットを活用できるようになります。多くの企業は、Feature Storeを活用することで、実験やデプロイメントを劇的に加速したことを報告しています。例えば、AnheuserのDirector of Data EngineeringであるBusch InBevは「特徴量エンジニアリングやデータ変換の共通ソースを用いることで、我々のデータサイエンスの能力をクイックにスケールさせ、データエンジニアやアナリストたちを統合する際に、Feature Storeは大きな助けとなっています」と述べています。
 Feature Storeを使い始めるのは簡単で、主キーとタイムスタンプを持つすべてのDeltaテーブルは簡単にFeature Storeで活用することができます。Databricks Feature Storeの詳細に関してはドキュメントをご覧ください。
はい、モデルの成果を改善するために、クイックかつ容易にFeature Storeのデータを活用するAutoMLの新機能が発表されました。AutoMLのユーザーはモデル品質を改善するために、シンプルにAutoMLデータセットとFeature Storeテーブルをjoinできるようになります。機械学習(ML)がより高速、より簡単になると、お客様は増加する様々なユースケースに対してこの変換技術を適用できるようになります。これによって、お客様はMLを用いて収益を増やし、コストを削減するさらに多くの手段を発見できるようになります。すでに我々は、多くのお客様が重要な問題を解決するためにAutoMLを活用しているのを目撃しています。いくつかのお客様は、自身の成果を加速するためにAutoMLを活用しつつも、自身のML専門性を拡張するためにAutoMLを活用しています。AutoMLはDatabricks Feature Storeと完全にインテグレーションされます。
Databricks AutoML(AWS、Azure、GCP)は、すべてのレベルの技術専門家によるMLモデルを構築、トレーニングをサポートするために開発されました。AutoMLは高品質の候補モデルを提供するだけではなく、お客様にすべてのモデルコードをノートブックで提供しますので、お客様はモデルのパフォーマンスをさらにチューニングすることができます。
 これまでは、トレーニングセットとしてテーブルを用いてモデルをトレーニングすることができました。今では、お客様は自身のFeature Storeのデータを用いて、AutoMLトレーニングデータを拡張することで、モデルの品質を改善することができます。これによって、さらに正確なモデルを簡単にトレーニングできるようになります。Feature Storeインテグレーションを用いたAutoMLモデルは自動で特徴量のリネージをキャプチャし、新規モデルをエンドツーエンドのリネージトラッキングに追加します。このリネージによって、開発を加速し、あなたのMLOpsとコンプライアンスの要件を満たすサポートを行うツールを提供します。
AutoMLエクスペリメントページで、Databricksランタイム11.3 LTS ML以降を選択します。問題タイプ、データセット、予測ターゲットを選択した後、画面の左下にボタンが表示されます。このボタンを選択することで、お使いのデータセットとjoinする特徴量テーブルを選択し、joinに使用する検索キーを選択する画面が表示されます。joinしたいテーブルと検索キーが指定したら、シンプルにStart AutoMLボタンをクリックし、入力したデータと特徴量テーブルから追加されたデータの両方を用いてモデル生成がスタートされます。このサンプルでは、NYCイエロータクシー料金データを特徴量テーブルで拡張することで、モデルのフィットが21%改善されています(RMSEが3.991から3.142に減少)。AutoMLのUIにおけるこのインテグレーションだけではなく、AutoML APIでもプログラムから特徴量テーブルによるトレーニングデータの拡張がサポートされています。APIに関してはこちらを参照ください(AWS、Azure、GCP)。MLをより高速かつシンプルにすることに対する投資を継続しているので、お客様が自身のワークフローを改善している様子を見ることができて嬉しく思っていますし、チームの皆様が自身のML目標を達成するためのより多くの手段を発見することを楽しみにしています。
外部ロケーションとはUnity Catalogでクラウドストレージにアクセスする際に使用するオブジェクトです。Databricksワークスペースとアクセス先のS3が同じAWSアカウントであればhttps://qiita.com/taka_yayoi/items/18fee92365eee58e0b94の手順でOKなのですが、クロスアカウントの際は以下の流れです。
 1. S3があるAWSアカウントでS3にアクセスするためのIAMロールの信頼ポリシーにUnity Catalogの信頼関係を追加。
 2. 上記S3にアクセスするためのIAMロールのARNをコピー。
 3. Databricksワークスペースで上記ARNを用いてストレージ資格情報を作成。上記ストレージ資格情報を用いて外部ロケーションを作成。
 という流れでした。すなわち、DatabricksがデプロイされているAWSアカウントではAWSの設定変更は不要ということです。
マネージドテーブルは、Unity Catalogでテーブルを作成するデフォルトの手法となります。これらは、Deltaテーブルフォーマットを使用します。デフォルトでは、メタストアを作成する際に設定したルートストレージロケーションにマネージドテーブルは格納されます。しかし、カタログやスキーマレベルで別のストレージロケーションを指定することができます。マネージドテーブルのデータは、ロケーションが指定された階層構造の最下層のレベルに格納されます。例えば、スキーマのロケーションが指定されるとそれが使用されます。もし、スキーマロケーションが指定され無い場合、カタログのロケーションが使用され、カタログのロケーションが指定されない場合には、デフォルトメタストアのルートロケーションが使用されます。
外部テーブルは、データがルートストレージロケーションの外に格納されるテーブルです。DatabricksクラスターやDatabricks SQLウェアハウスの外のデータに直接アクセスする必要がある場合にのみ外部テーブルを使用してください。外部テーブルにDROP TABLEを実行すると、Unity Catalogは背後のデータは削除しません。マネージドテーブルと同じように、外部テーブルの権限を管理し、クエリーでこれらを使用することができます。SQLで外部テーブルを作成するには、CREATE TABLE文でLOCATIONパスを指定します。外部テーブルでは、以下のファイルフォーマットを使用することができます: DELTA, CSV, JSON, AVRO, PARQUET, ORC, TEXT。外部テーブルの背後にあるクラウドストレージへのアクセスを管理するには、ストレージ資格情報と外部ロケーションをセットアップしなくてはなりません。
マネージドテーブルは、Sparkがメタデータとデータの両方を管理するSpark SQLテーブルです。マネージドテーブルの場合、DatabricksはメタデータとデータをあなたのアカウントのDBFSに格納します。Spark SQLがテーブルを管理するので、DROP TABLE example_dataはメタデータとデータ両方を削除します。外部テーブルは、データがルートストレージロケーションの外に格納されるテーブルです。Spark SQLはメタデータを管理しますので、DROP TABLE example_dataを実行した際には、Sparkはメタデータのみを削除します。データ自身は削除しません。このため、あなたが指定した場所にデータは残り続けます。
グローバルテーブルは全てのクラスターからアクセスすることができます。DatabricksはグローバルテーブルをDatabricksのHiveメタストア、あるいは外部のHiveメタストア(英語)に登録します。Hiveサポートの詳細はApache Hive compatibility(英語)を参照ください。ローカルテーブルはHiveメタストアに登録されず、他のクラスターからはアクセスできません。これは一時ビューとも呼ばれます。
Unity Catalogをセットアップすればいいのですが、もう一つの方法として「Unity Catalogを参照しに行かないクラスター」を作成するというものがあります。これは現時点ではレガシーとなりますが、上述のアクセスモードを設定しないクラスターを作成することになります。
 1. コンピューティングを作成をクリックします。
 2. 画面上のUIプレビューにマウスカーソルを移動します。トグルスイッチが表示されるので、これをオフにします。レガシーなクラスター作成画面に変更されます。
 3. クラスターモードをシングルノードなどにして、クラスターを作成します。必要に応じて、インスタンスプロファイルやSpark設定を行い、S3やGlueにアクセスできるようにしておきます。
 これでMETASTORE_DOES_NOT_EXISTエラーを解消できるはずです。
Abnormal Security、People.ai、YipitDataのように成功している数多くのスタートアップは、Databricksレイクハウスで製品を開発することで偉大な成功を収めています。自身のデータプラットフォームの意思決定をドライブしたいくつかの要因があります。
 1. 妥協なしのデータ: お使いのすべてのデータ、分析、AI要件の実行. 
 2. 製品化のスピード: 皆様のチームがコアアプリケーションにフォーカスさせましょう. 
 3. 成長に備える: いかなる規模でもコスト効率の高いパフォーマンス. 
 4. オープンソースとマルチクラウドでインフラストラクチャの柔軟性を維持する. 皆様のスタートアップ製品をDatabricksレイクハウスで開発しましょう.
COPY INTOでサポートされているソースやファイルフォーマットからUnity Catalogのマネージドテーブル、外部テーブルにデータを取り込む際にCOPY INTOを使用することができます。3レベルの識別子(<catalog_name>.<database_name>.<table_name>)を用いてUnity Catalogのテーブルを指定することができます。現在のクエリーやノートブックにおけるデフォルトのカタログやデータベースを設定するために、USE CATALOG <catalog_name>やUSE <database_name>を使うことができます。既存のテーブルにCOPY INTOを行いたい場合には、テーブルを格納するカタログとデータベースに対するUSAGE権限と、当該テーブルに対するMODIFY権限が必要になります。一時資格情報が設定されたクラウドオブジェクトストレージロケーションを含む、あなたがアクセスできるソースロケーションからCOPY INTOを実行することができます。
Databricksでは、数多くのデータロードとデータ取り込みの最適化を提供しています。また、DatabricksではSQLとデータフレームユーザーに対してクエリーフェデレーションをサポートしています。Databricksのクエリーフェデレーションとは？をご覧ください。これまでにDatabricksデータの読み書きを行ったことがないのであれば、PythonやScalaのデータフレームチュートリアルを試すことを検討ください。Apache Sparkに慣れ親しんでいるユーザーにとっても、このチュートリアルはクラウドにあるデータへのアクセスに関する新た課題に取り組むことができます。Partner Connectは数多くのエンタープライズソリューションに対して、最適化され設定が容易なインテグレーションを提供します。What is Databricks Partner Connect?をご覧ください。
Databricksには、Apache Sparkによってネイティブにサポートされているすべてのデータフォーマットに対してビルトインのキーワードバインディングがあります。Apache SparkがParquetを使うのと同じように、Databricksはデータとテーブルの読み書きにおけるデフォルトのプロトコルとしてDelta Lakeを使います。以下のデータフォーマットのすべては、Apache SparkのデータフレームとSQLにおいてビルトインのキーワード設定を有しています：Delta Lake、Parquet、ORC、JSON、CSV、Avro、Text、Binary。また、DatabricksではMLflowエクスペリメントをロードするカスタムキーワードを提供しています。
Databricksでは、データファイルとテーブルを格納するためにクラウドオブジェクトストレージを使用します。ワークスペースをデプロイメントする際、DatabricksはDBFSルートと呼ばれるクラウドオブジェクトストレージロケーションを設定します。アカウントの他のクラウドオブジェクトストレージロケーションとの接続を設定することもできます。ほぼ全てのケースにおいて、DatabricksでApache Sparkを用いて操作するデータファイルはクラウドオブジェクトストレージに格納されます。接続を設定する際のガイドとして、以下のドキュメントをご覧ください。
数多くのデータソースに接続するためにJDBCを使うことができます。Databricksランタイムには数多くのJDBCデータベースのドライバーが含まれていますが、お使いのデータベースに接続するためにはドライバーや別バージョンのドライバーをインストールする必要があるかもしれません。サポートされているデータベースには以下のものが含まれます:　Query PostgreSQL with Databricks、Query MySQL with Databricks、Query MariaDB with Databricks、Query SQL Server with Databricks
以下のデータサービスでは、接続設定、セキュリティ資格情報、ネットワーク設定が必要となります。AWSアカウントやDatabricksにおける管理者、パワーユーザー権限が必要になるかもしれません。また、いくつかにおいてはDatabricksライブラリを作成し、クラスターにインストールする必要があります。Query Amazon Redshift with Databricks、Google BigQuery、MongoDB、Cassandra、Couchbase、ElasticSearch、Neo4j、Redis、Read and write data from Snowflake、Azure Cosmos DB、Query data in Azure Synapse Analytics
データ追加UIを用いたデータのロードには複数の方法が存在ます。1. CSVファイルからDelta Lakeテーブルにロードするには、Upload dataを選択し、データアップロードUIにアクセスします。2. レガシーDBFSファイルアップロードを使うにはDBFSを選択します。3. 様々なデータソースへの接続を設定するためのサンプルノートブックを起動するためにその他のアイコンをクリックします。データソースの完全な一覧に関しては、Databricksにおける外部データの取り扱いをご覧ください。
Auto LoaderとDelta Live Tablesを用いることで、スケーラブル、インクリメンタルなデータ取り込みのインフラストラクチャのデプロイメントをシンプルにすることができます。Delta Live Tablesではノートブックのような標準的なインタラクティブな処理の実行ではなく、プロダクションに使えるインフラストラクチャのデプロイメントにフォーカスしています。
以下にAuto LoaderとCOPY INTOを選択する際に検討すべきいくつかの事柄を示します:　数千規模のファイルを取り込もうとしているのであればCOPY INTOを使うことができます。一定期間で数百万以上のファイルを予想しているのであれば、Auto Loaderを使ってください。Auto Loaderは、COPY INTOと比較してファイルを検知するオペレーションの総数が少なくて済み、処理を複数のバッチに分割することができ、Auto Loaderは低コストで規模に対して効率的であることを意味します。データスキーマが頻繁に進化するのであれば、Auto Loaderはスキーマ推定、進化に関するより良いプリミティブを提供しています。Auto Loaderにおけるスキーマ推定とスキーマ進化の設定をご覧ください。再度アップロードされたファイルのサブセットのロードにおいては、COPY INTOの方が管理が若干簡単です。Auto Loaderを用いる場合、ファイルのサブセットのSELECTを再処理することがより困難となります。しかし、Auto Loaderストリームを同時に実行しながらも、ファイルのサブセットを再ロードするためにCOPY INTOを使うことができます。
アプリケーションのモニタリングは以下の点に応じて異なるレベルで実行されることになります: 1. お使いのアプリケーションで収集されるメトリクス(バッチの処理時間/レーテンシー/スループットなど), 2. どこからアプリケーションをモニタリングしたいのか。最もシンプルなレベルでは、様々なシチュエーションで活用できるSpark UIに直接ビルトインされているストリーミングダッシュボード(新しい構造化ストリーミングUI)があります。ストリーミングワークロードを実行するジョブの失敗時にアラートを発生させることもできます。より詳細なメトリクスが必要、あるいは、お使いのコードベースの一部としてこれらのメトリクスに基づくカスタムアクションを作成したい場合には、StreamingQueryListenerがあなたが探しているものに適しています。(ドライバーやワーカーのマシンレベルのトレースを含む)Sparkのメトリクスをレポートさせたいのであれば、プラットフォームのメトリクスシンクを使うべきです。検討すべきもう一つの事柄は、観測のためにこれらのメトリクスをどこに表示させたいのかということです。クラスターレベルでのGangliaダッシュボード、ストリーミングワークロードのモニタリングのためのDatadogのようなパートナーアプリケーションのインテグレーション、PrometheusやGrafanaのようなツールを用いたよりオープンソースなオプションがあります。それぞれには、コスト、パフォーマンス、メンテナンス要件に関する利点、欠点があります。UIによるインタラクションで十分な低ボリュームのストリーミングワークロードを使用していようが、より堅牢なモニタリングプラットフォームに投資することを決断しようが、皆様のプロダクションストリーミングワークロードの観測方法を理解する必要があります。このシリーズで今後ポストされる「モニタリングとアラート」では、より詳細な議論が含まれることになります。特に、ストリーミングアプリケーションをモニタリングするための様々な計測方法や観測性を活用するためのいくつかのツールを詳細に見ていきます。
開発者として、我々は作業中のコードと適切に記述されたコードの違いを理解しています(あるいはすぐに学びます)。コードの実行形態を改善することは非常に楽しいものですが、最終的に問題になるのは全体的な実行コストです。構造化ストリーミングアプリケーションにおけるコストの検討は、他のSparkアプリケーションと概ね同じようなものとなります。特筆すべき違いは、これらのワークロードは多くの場合「常時稼働」のアプリケーションなので、プロダクションワークロードの最適化に失敗すると、非常に高コストになり、無駄な出費がすぐに累積していくという点です。コスト最適化の支援は頻繁にリクエストされるので、これに関する別の記事をポストする予定です。フォーカスするキーポイントは使用の効率性とサイジングです。クラスターサイズを適切に設定することは、ストリーミングアプリケーションにおいて効率性と無駄の違いを生み出す最も重要な違いとなります。時にはプロダクションにおけるアプリケーションの完全な負荷条件をデプロイする前に推定することが困難であるため、これは特にトリッキーになります。別のケースでは、日、週、月を通じて取り扱われるボリュームの変動性によって困難となる場合があります。最初にデプロイする際は、パフォーマンスのボトルネックを避けるために追加の費用を投じて若干サイズを大きめにすることをお勧めします。適切なクラスター使用率を確認するために数週間クラスターが稼働した後に、お使いのモニタリングを活用してください。例えば、負荷のピークの際にCPUやメモリーの使用率は高いレベルにあるのか、あるいは、定常的に負荷が低くてクラスターのサイズを引き下げて良いのか？これに対する定期的なモニタリングを継続し、データボリュームの時系列変化を注視します。いずれかが発生している場合、コスト効率の高いオペレーションを維持するためにクラスターのサイズ変更が必要になるかもしれません。一般的なガイドラインとして、過度なシャッフルオペレーションやjoin、極端なウォーターマークの閾値(ご自身の要件を超えないでください)はアプリケーションを実行するために必要なリソースを増加させるので、これらを避けるべきです。大きなウォーターマークの閾値は、構造化ストリーミングにバッチ間の状態ストアに多くのデータを保持させることになり、クラスターのメモリー要件を引き上げることになります。また、設定するVMのタイプにも注意してください - メモリーを大量に必要とするストリームにメモリー最適化VMを使っていますか？計算が膨大に発生するストリームに計算最適化VMを使っていますか？そうで無い場合には、それぞれの使用率を確認し、より適したマシンタイプを試すことを検討してください。クラウドプロバイダーから提供される新たなサーバーファミリーでは、より最適化されたCPUが搭載されており、多くの場合において処理実行の高速化につながり、これはSLAを達成するために少ない台数で済むことを意味します。
コスト最適化と同じように、Sparkにおけるストリーミングアプリケーションのトラブルシュートは内部の機構はほとんど変わらないので、他のSparkアプリケーションと多く変わりません。ストリーミングアプリケーションにおいては、問題は通常、障害シナリオとレーテンシーシナリオという2つのカテゴリーに属することになります。
理由が３つあります。1. 複雑な変換処理による柔軟性を提供します。ネイティブSQLはユーザーに対して、特定の変換に対して理想的なツールを選択する柔軟性を提供します。DAXは表現豊富でパワフルですが、より複雑なSQLクエリーやミサポートのオペレーションに対しては、ネイティブなSQLクエリーによってよりシンプルなワークフローを実現することができます。また、これはカスタムカラム定義を折りたたんだり、プッシュダウンでいないケースにおいては、単にネイティブSQLを構築することで大きなメリットを得ることができます。2. Databricks SQLの計算資源のさらなる活用が可能になります。3. 他のPower Queryソースからの移行をシンプルにできます。Power BIで他のデータソースとカスタム/ネイティブSQLを使用しているお客様においては、Databricks SQLへの移行は面倒なものでした。これまでのソリューションは、これをDatabricksのビューやDAXのロジックにマッピングしようとしていました。今では、これはDatabricks Power BIコネクターで適切なネイティブSQLを指定するだけで済むシンプルなものとなっています。
Z-orderingは、関連する情報を同じファイルセットに配置するテクニックです。この局所性は、自動でDatabricksのDelta Lakeによるデータスキッピングアルゴリズムによって使用されます。この挙動によって、DatabricksのDelta Lakeの読み込むデータ量を劇的に削減します。データをZ-orderするには、ZORDER BY句で並び替えるカラムを指定します。あるカラムが頻繁にクエリー条件に指定され、そのカラムが高いカーディナリティを持っている(すなわち、大量の固有値を持つ)のであればZORDER BYを使いましょう。カンマ区切りで複数のカラムをZORDER BYに指定することができます。しかし、カラムを追加するごとに局所性の効果は失われます。統計情報が収集されていないカラムに対するZ-orderingは効果がなく、リソースの無駄となります。これは、データスキッピングでは、min、max、countのようなカラムローカルの統計情報が必要となるためです。スキーマでカラムを再度並び替える、あるいは統計情報を収集するカラムの数を増やすことで、特定のカラムに対して統計情報を収集するように設定することができます。
Z-orderingの注意事項に2点あります。1. Z-orderingは冪等性がありませんが、インクリメントなオペレーションで使用することができます。複数回実行してもZ-orderingに要する時間が削減することは保証されません。しかし、Z-orderされたばかりのパーティションに新規データが追加されない場合、そのパーティションを再度Z-orderingしても効果はありません。2. Z-orderingはタプルの数が均等にバランスされたデータファイルを生成しようとしますが、ディスク上のデータサイズが均等になるとは限りません。これら2つの指標は多くの場合相関しますが、そうではない場合もあり最適化タスクの処理時間に偏りが生じることがあります。例えば、ZORDER BY dateを行い、最新のレコードがすべて前回のZORDERのものよりも幅が広い(長い配列や文字列など)場合、OPTIMIZEジョブのタスク時間や結果ファイルのサイズに偏りが生じることになります。しかし、これはOPTIMIZEコマンド自身のみの問題です。以降のクエリーにネガティブなインパクトを起こすことはありません。
1. Scalable Machine Learning with Apache Spark Japaneseのノートブック(日本語)を読み込むことをやりました. Scalable Machine Learning with Apache Spark Japaneseには解説のスライドが付属しています。スライドではデータサイエンスの基礎から解説されているので、初学者でも学び始めることができます。2. ML in production JapaneseのDatabricksにおける機械学習モデルの運用に焦点を当てて解説されているNotebookで練習しました。実験管理やモデル管理はScalable Machine Learning with Apache Spark Japaneseとオーバーラップする内容が多いです。新しい内容としてはRESTエンドポイントへのデプロイ、テスト自動化、モニタリングなどが解説されています。
Databricksでは、ノートブック間でコードを共有するための方法をいくつかサポートしています。それぞれの方法においては、コードのモジュール化を実現し、ライブラリのようにノートブックでコードを共有することができます。また、Databricksでは依存関係を持つパイプラインや戻り値に基づくif-then-elseワークフローのような複雑なワークフローにノートブックを組み込むこともできます。方法１：ノートブックをインポートするために%runを使う。方法２：ソースコードファイルを参照するためにDatabricks Reposを使用する。
1. 多くのユニットテストのライブラリはノートブック内で直接動作します。例えば、ノートブックのコードをテストするためにビルトインのPythonの`unittest`パッケージを使用することができます。セルの出力エリアにテスト失敗が表示されます。単一のノートブックにおいてテスト用の呼び出しなのか、通常の呼び出しなのかを区別するためにウィジェットを使うことができます。2. ノートブックからテストコードを分離する。%runを使った例です。