bowang0911/databricks-qa-ja huggingface dataset:
DatabricksジョブのUIで失敗したタスクを特定するには: 1. サイドバーのワークフローをクリックします。2. 名前の列でジョブ名をクリックします。ジョブの実行タブにはアクティブなジョブ実行、失敗したものを含む完了したジョブ実行が表示されます。3. マトリックススビューに切り替えるには、マトリックスをクリックします。魔トリックビューには、それzれおのジョブタスクの成功、失敗を含むジョブの実行履歴が表示されます。マトリックスビューを用いることで、ジョブ実行で失敗したタスクをクイックに特定することができます。4. 関連メタデータを確認するために失敗したタスクの上にマウスカーソルを移動します。メタデータには、開始日、終了日、期間、クラスター詳細、エラーメッセージが含まれています。5. 失敗の原因の特定を行うために、失敗したタスクをクリックします。タスク実行の詳細ページが開き、タスクの出力、エラーメッセージ、メタデータが表示されます。
マネージドテーブル は、ユーザーがテーブル名だけを使ってデータ(Sparkデータフレーム)を永続化する方法で、データの保存先(ストレージとパス)はSparkシステム側で自動的にアサインされます。つまり、ユーザーは保存先などストレージ側を意識する必要がありません。データを削除する場合も、DROP TABLE文を実行するだけで済み、テーブルのメタデータの削除と、データ実体の削除が同時に実行されます。データの保存先が自動管理されるので 「マネージド」テーブル と呼びます。一方、アンマネージドテーブルは、ユーザーがデータの保存先パスを指定して永続化し、後からテーブル名とデータ保存先をリンクします。この場合、データの削除には、DROP TABLE文でのテーブル(のメタデータ)削除に加えて、データ保存先のデータ実体を削除する必要があります。つまり、ユーザーはテーブル(メタデータ)とデータ実体の保存先の両方を意識する必要があり、よって、「アンマネージド」テーブルと呼ばれています。この方法だと、Sparkシステム管理のストレージ外上に置かれているデータに対してもテーブル名とリンクができるため、この意味で、アンマネージドテーブルは「外部テーブル(External Table)」 とも呼ばれます。
ユーザー定義関数(user-defined-function:UDF)はユーザーによって定義される関数であり、ユーザー環境でカスタムロジックを再利用できるようになります。拡張可能なロジックを分散処理できるようにするために、Databricksでは様々な種類のUDFをサポートしています。
厳密にはすべてのカスタム関数がUDFという訳ではありません。SQLやSparkデータフレームを用いて一連のSparkビルトインメソッドを安全に定義することができ、完全に最適された挙動をさせることができます。例えば、以下のSQL、Python関数は再利用可能な関数として単位変換を定義するためにSparkのビルトインメソッドを組み合わせています。
UDFはコード実行において多大なる処理ボトルネックを持ち込む場合があります。Databricksでは、Apache Spark、SQL、Delta Lakeの構文を用いて記述されたコードに対して自動で様々なオプティマイザを適用します。UDFによってカスタムロジックが導入されると、これらのオプティマイザはこのカスタムロジックに対してタスクを効率的に計画する能力を発揮することができません。さらに、JVM外で実行されるロジックにおいては、データのシリアライズにおける追加のコストが発生します。いくつかのUDFは他のものより効率的です。パフォーマンスの観点では:　1. Databricksのオプティマイザのおかげでビルトイン関数が最も高速です。2. JVMで実行されるコード(Scala、Java、Hive UDF)はPythonのUDFよりも高速です。3. Pandas UDFはPython UDFに関連づけられるシリアライズ残すとを削減するためにArrowを活用します。4. 通常はPython UDFは避けるべきですが、パフォーマンス劣化なしに、コードを結びつけるためにPythonを活用することができます。
UDFの主要なメリットは、慣れ親しんだ言語でロジックを表現し、コードのリファクタリングに伴う人間のコストを削減できるというものです。アドホックなクエリー、主導のデータクレンジング、探索的データ分析、小中規模のデータセットに対する大部分のオペレーションにおいては、UDFによるレーテンシーのオーバーヘッドがコードのリファクタリングに関連するコストを上回ることはほとんどありません。ETLジョブ、ストリーミングオペレーション、超大規模なデータセットに対するオペレーション、その他の定常的、連続的に実行されるワークロードにおいては、ネイティブなApache Sparkのメソッドを用いるためにロジックをリファクタリングするコストはすぐに取り戻すことができます。
コンピューティングにおいて、データベースは、電子的に保存され、アクセスできる組織化されたデータの集合である。この定義に沿って考えれば、答えはYESです。しかし、OracleやSQL Server、MySQL、Snowflakeのようなデータベース管理システム(DBMS)がインストールされているのか？と聞かれると答えはNOとなります。これらのDBMSやデータウェアハウスとDatabricksにおけるデータベースは実装が異なります。
まず、データ管理プラットフォームとしてデータウェアハウス(個人的にはデータベースと同義だと思っています)が1990年台に台頭し、多くの企業で導入されました。ビジネス上の意思決定を行うためにデータを蓄積し、BIなどを通じて意思決定にデータが活用されるようになりました。データウェアハウスの特徴をざっくり列挙します。1. 行と列で構成される構造化データを蓄積, 2. SQLによる問い合わせ、加工が可能 3. (比較的)大量のデータを管理可能。これらの特徴は現在においても多くの企業のデータ活用に役立っており、ある意味成熟したテクノロジーと言えます。しかし、ここ数年、このデータウェアハウスでは応えられない要件が出現しています。そう、機械学習やAIの活用です。データレイクの台頭。BIやSQLを用いた分析など、過去の構造化データを蓄積し、活用するというシーンにおいてはデータウェアハウスは非常に有用です。一方、機械学習モデルをトレーニングし、将来の予測に活用する、画像やテキストを分析するという要件にデータウェアハウスは応えることができませんでした。そのため、機械学習・AIのニーズに応えることのできる新たなデータ管理プラットフォームが求められました。これによって、2010年頃にデータレイク誕生しました。データレイクの特徴をざっくり列挙します。1. クラウドサービスのオブジェクトストレージにデータを格納, 2. 構造化データ、非構造化データに対応 3. 理論上、容量は無制限 4. 機械学習のワークロードとの親和性が高い。これによって、データレイクを活用し始めた人々は機械学習・AIによる明るい未来を夢想しました。しかし、世の中はそんなに甘くありません。上述の特徴は確かに機械学習の取り組みにおいては非常に有用なものでありましたが、企業の取り組みにおける重要な観点が欠落していました。パフォーマンスとガバナンスです。オブジェクトストレージに無尽蔵にデータを格納できたとしても、検索・更新に非常に時間を要してしまい、さらには、管理がなされないためゴミだらけでのデータレイクになってしまうということが頻発しました。結果として、データレイク(湖)ならぬデータスワンプ(沼)とまで揶揄されるようになってしまいました。レイクハウスの誕生。今の機械学習・AIのニーズに応えきれないから(データ)レイクハウスが開発されたということです。レイクハウスではデータはオープンなフォーマットでクラウドストレージに格納します。これによって、ベンダーロックインの回避、無限のストレージ、機械学習ワークロードとの親和性といったことを実現します。さらに、データウェアハウスで培われたパフォーマンスやガバナンスをも実現しているのです。
SparkでExcelファイルを扱うためにspark-excelライブラリを利用します。ExcelファイルをSparkデータフレームとして読み込んだり、また逆に出力したり、さらには既存のExcelファイルの特定の部分にSparkデータフレームのデータを上書きして保存するということもできます。Spark自体がビッグデータを扱うものなので、可視化という意味ではBIツールを使うことがほとんどで、Excelを使うことは多くはないと思いますが、どうしても使わなければいけない場合はこのライブラリを使うことで簡単に実現できます。
データフレームを以下のようにして、save()で指定したファイルパスにExcelファイルを出力します。format()で com.crealytics.spark.excelを指定します。( df_output.write.format( 'com.crealytics.spark.excel' ).option( 'header', 'true' ).mode( 'overwrite' ).save( xlsx_file_path ) )
Bamboolibは、皆さんが知っていて大好きな標準的Pythonデータサイエンスライブラリであるpandasの機能に対してグラフィカルユーザーインタフェースを提供するローコードツールです。Bamboolibを用いることで、コード自身を記述することなしに簡単にコードファーストのデータサイエンスのすべてのパワーを手に入れることができます。これは、以下のことが可能になることを意味します:　1. データベースのテーブルやCSVファイルにアクセスしてデータをロードし、2. 生データから調査に適したクリーンかつ整理されたデータに加工、変換し、3. 皆様のビジネスに多大なインパクトをもたらすキーとなる洞察を明らかにするためにデータを探索、可視化、分析することができます。
 Bamboolibはローコード分析にガラスボックスアプローチを用いることでこれを実現しています: これらの分析オペレーションに対するpandasコードを生成し、UIを用いて実施したすべての分析結果を再現できるようにしています。そして、活用したいテクニックがネイティブでBamboolibで利用できない場合には、Bamboolibのプラグインフレームワークを用いることで容易に機能を拡張することができます。
Bamboolibはすべてのバックグラウンドを持つDatabricksユーザーに対して、コードファーストのデータサイエンスで利用できるすべてのディープな機能と柔軟性へのゲートウェイを提供します。実践者は以下のことをこなえるようになります。1. 生産性が向上します: 通常の定型文を記述することなしにpandasデータフレームを準備、分析、可視化できるので、手元の作業にフォーカスできます。2. すぐにpandasに慣れることができます: Excel、MATLAB、SASのような他のツールをよく使っていた場合には、何をしたいのかを知っていたとしても、pandasやPythonでそれをどのように行うのかがわからないかと思います。Bamboolibは、行いたいオペレーションの自然言語の記述をPythonコードに変換することを助けてくれます。3. 分析とコードの結果に自信を持てるようになります: 作業の過程でBamboolibが生成するコードを容易に確認、評価、エクスポートできるので、行っているすべての作業が自分自身、あるいは分析結果を共有する同僚によって再現が可能です。
Bamboolibのメリットは、自分達の実践者のスキルセットを拡大し、彼らのインパクトを向上させたいと考えているデータ分析のリーダーや組織にも適用されます。1. オンボーディングをシンプルにしセルフサービス分析を実現します: シチズンデータサイエンティスト、ドメイン専門家、その他の従業員が、最小限の技術的オーバーヘッドでDatabricksノートブックでインパクトがあり再現可能な結果を達成することを可能にします。2. 学習とスキル開発の機会を提供します: BamboolibはPythonのデータサイエンスの世界のシンプルなエントリーポイントとなります。ガラスボックスアプローチによって、ユーザーは分析を実現するコードにアクセスでき、このコードを用いることで彼らはpandasライブラリとモダンなデータサイエンスのコアな手法を学ぶことができます。
DatabricksクラスターとSQLウェアハウスの違いをクイックにまとめます。SQLウェアハウスは、クエリー、ダッシュボード、ビジュアライゼーションのようなDatabricks SQLのワークロードの実行に使用されます。お使いのワークスペースがUnity Catalogのメタストアにアタッチされているのであれば、SQLウェアハウスを用いることで、デフォルトでUnity Catalogのデータにアクセスでき、Unity Catalog固有のコマンドを実行することができます。クラスターは、Data Science & EngineeringやDatabricks Machine Learningのペルソナベースの環境におけるワークロードの実行に使用されます。Unity Catalogにアクセスできるクラスターを作成するためには、クラスターを作成するワークスペースがUnity Catalogメタストアにアタッチされ、Unity Catalogを使用できるアクセスモード(共有あるいはシングルユーザー)を使用しなくてはなりません。利用している環境に応じて、これらの計算資源を用いてUnity Catalogのデータを操作することができます: Databricks SQLではSQLウェアハウス、Data Science & EngineeringやDatabricks Machine Learning環境ではクラスターとなります。さらに、1. SQLウェアハウス(エンドポイント)はSQLコマンドを実行するために開発されており、Scala/R/PythonやSQLコマンドを実行するために開発されています。2. SQLウェアハウス(エンドポイント)ではJAR、PIP、WHLのようなライブラリのオーバヘッドがなく、クラスターではライブラリによるオーバヘッドが生じることがあります。3. SQLウェアハウス(エンドポイント)はSQLウェアハウスの管理を簡素化しており、起動時間を加速します。クラスターの設定は初めての方にとっては複雑なものになる場合があります。4. SQLウェアハウス(エンドポイント)はクラスターとしてスケールアップ/スケールダウンします。クラスターはノードごとにスケーリングし、最大範囲までスケールアップします。5. SQLウェアハウス(エンドポイント)には、起動時間を劇的に削減するサーバレスの機能(プライベートプレビュー)がありますが、クラスターではその機能はまだありません。ただし、SQLウェアハウス(エンドポイント)とクラスターの両方はTableauのようなBIツールからの接続に使用でき、自動起動の機能を有しています。
Databricksでクラスターを作成する際、クラスターを使用しようとしているワークロードのタイプ固有のアクセスモードを選択しなくてはなりません。Unity Catalogは特定のクラスターアクセスモードを用いたセキュリティを強制します。クラスターがUnity Catalogを使用できるアクセスモード(共有あるいはシングルユーザー)のいずれかを設定されていない場合、クラスターはUnity Catalogのデータにアクセスすることはできません。クラスターアクセスモードをシングルユーザーや共有に設定することで、Unity Catalogの要件を満たすように既存クラスターをアップグレードすることができます。
Databricksのアイデンティティには3つのタイプが存在します。1. ユーザー: Databricksによって識別されるユーザーアイデンティティでありメールアドレスで表現されます。2. サービスプリンシパル: ジョブ、自動化ツール、そして、スクリプト、アプリ、CI/CDプラットフォームのようなシステムで使用するアイデンティティです。3. グループ: ワークスペース、データ、そのほかのセキュリティ保護可能オブジェクトへのグループのアクセスを管理するために、管理者によって使用されるアイデンティティのコレクションです。
Databricksで定義されるロールが5つ存在します。1. アカウント管理者は、ワークスペース、Unity Catalogメタストアの作成、課金、クラウドリソースを含むDatabricksのアカウントレベルの設定を管理することができます。アカウント管理者はアカウントにユーザーを追加し、管理者ロールを割り当てることができます。また、ワークスペースでアイデンティティフェデレーションを使用している場合、ユーザーにワークスペースへのアクセス権を与えることができます。2. ワークスペース管理者は、Databricksワークスペースにユーザーを追加し、ワークスペース管理者ロールや、クラスターの作成や特定のペルソナベースの環境へのアクセス権などの能力を割り当てることができます。3. メタストア管理者は誰がカタログを作成でき、テーブルをクエリーできるのかと言ったUnity Catalogメタストアの全てのセキュリティ保護可能オブジェクトの権限を管理することができます。4. アカウントユーザーはワークスペースを参照し、ワークスペースに接続するためにアカウントコンソールを使用することができます。アカウント管理者とワークスペース管理者はアカウントにユーザーを追加することができます。5. ワークスペースユーザーはワークスペースでデータサイエンス、データエンジニアリング、データ分析タスクを実行します。アカウント管理者とワークスペース管理者は、ワークスペースでアイデンティティフェデレーションを使用している場合、アカウントユーザーにワークスペースへのアクセス権を与えることができます。
Databricksでアイデンティティを管理するには、アカウント管理者かワークスペース管理者である必要があります。以下の表では、ユーザー管理のアクションに必要な特定のアクセス権の詳細を示しています。アカウントには合わせて最大10,000ユーザーとサービスプリンシパルを持つことができ、最大5000グループを持つことができます。それぞれのワークスペースでは、最大10,000ユーザーとサービスプリンシパル、最大5000グループを持つことができます。
Databricksワークスペースで作業するために、ユーザー、サービスプリンシパル、グループを有効化するには、アカウント管理者あるいはワークスペース管理者がそれらをワークスペースに割り当てる必要があります。アカウント管理者は、ワークスペースでアイデンティティフェデレーションが有効化されている場合、ワークスペースに対してアカウントに存在するユーザー、サービスプリンシパル、グループにアクセスを割り当てることができます。また、ワークスペース管理者はアイデンティティフェデレーションが有効化されている自分のワークスペースにユーザー、サービスプリンシパル、グループを割り当てることができます。逆に、新規ユーザーや新規サービスプリンシパルをワークスペースに直接追加すると、それらのユーザー、サービスプリンシパルは自動でアカウントに追加され、ワークスペースに割り当てられます。この上流のフローはお勧めしません。アカウントにユーザーを追加し、ワークスペースに割り当てる方が分かりやすいです。Databricksはどのようにワークスペースとアカウント間でアイデンティティを同期するのか？をご覧ください。ワークスペースローカルグループとして知られる、ワークスペースで直接作成されたグループは自動でアカウントに追加されません。アカウントのグループとして手動でワークスペースローカルグループを再作成することができます。グループに対する特別な検討をご覧ください。
2022年8月にすべての既存のワークスペースユーザーとサービスプリンシパルは自動でアカウントレベルのユーザー、アカウントレベルのサービスプリンシパルに同期されました。Databricksはワークスペースにユーザーが追加された際には、常にユーザーとサービスプリンシパルをアカウントに同期し続けます。ワークスペースユーザーがアカウントレベルのユーザーや既に存在している管理者とユーザー名(メールアドレス)を共有している場合にはマージされます。ワークスペースローカルグループはアカウントレベルに同期されません。ワークスペースローカルグループは、ワークスペース管理者のコンソールと(当該ワークスペースでアイデンティティフェデレーションが有効化されている場合)アカウントコンソールのワークスペースアクセス権タブでワークスペースローカルと識別されます。詳細はグループに対する特別な検討をご覧ください。
今回、どのくらいの精度がでるかというところで、SIGNATE様が出されているTest用のCompetitionデータを使ってAutoMLを回した結果です。最終的に最もよい精度(accuracy)は0.934を記録しているので、精度としてはいい値かと思います。コンペの上位の方達も9.7近くの値をだされているので、baselineの作成としてはAutoMLを活用いただけるのでは！
ユーザー設定に移動するか、をクリックするか、展開されたアドバイスボックス内の歯車アイコンをクリックすることでノートブックの設定ページに移動します。Turn on Databricks Advisorを切り替えることで、アドバイスを有効化・無効化できます。ある種のアドバイスを非表示にした場合、Reset hidden adviceリンクが表示されます。これらのアドバイスを再度表示させたい場合にはこのリンクをクリックします。
データレイクにおける新規レコードを特定し、データへの変更を補足するために、どのようにDelta Live Tablesパイプラインのチェンジデータキャプチャを活用できます。CDCデータが外部システムから到着する一般的なCDCユースケースにおけるDelta Live TablesパイプラインにおけるAPPLY CHANGES INTOコマンドを使用します。
チェンジデータキャプチャ(CDC)はデータベースやデータウェハウスのようなデータストレージにおけるレコードの変更をキャプチャするプロセスです。これらの変更は通常、データの削除、追加、更新のようなオペレーションとみなされます。データベースをエクスポートするデータベースのダンプを取得し、レイクハウス/データウェアハウス/データレイクにインポートするデータレプリケーションはシンプルな方法ですが、これはスケーラブルなアプローチとは言えません。データベースでなされた変更のみをキャプチャし、これらの変更をターゲットデータベースに適用するのがチェンジデータキャプチャです。CDCはオーバーヘッドを削減し、リアルタイム分析をサポートします。バルクロードによる更新をすることなしに、インクリメンタルなロードを実現します。
CDCツール、Auto Loader、DLTパイプラインを用いたCDCフロー: 1. CDCツールがデータベースログを読み込み、変更を含むJSONメッセージを生成し、Kafkaに対して変更説明を伴うレコードをストリーミング, 2. KafkaがINSERT, UPDATE, DELETEオペレーションを含むメッセージをストリーミングし、クラウドオブジェクトストレージ(S3、ADLSなど)に格納, 3. Auto Loaderを用いてクラウドオブジェクトストレージからメッセージをインクリメンタルにロードし、生のメッセージとして保存するためにブロンズテーブルに格納, 4. 次に、クレンジングされたブロンズレイヤーテーブルに APPLY CHANGES INTO を実行し、後段のシルバーテーブルに最新の更新データを伝搬。外部データベースからCDCデータを処理するための実装を以下に示します。入力はKafkaのようなメッセージキューを含む任意のフォーマットになり得ることに注意してください。
変更データを表現するJSONメッセージは、以下の一覧と同じような興味深いフィールドを持っています。operation: オペレーションのコード(DELETE, APPEND, UPDATE, CREATE)。operation_date: それぞれのオペレーションのアクションがあった日付、タイムスタンプ Debeziumの出力には以下のようなフィールドが含まれます(このデモには含めていません)。before: 変更前の行。after: 変更後の行
Nixtlaは、一貫性があり使いやすい方法で広範な予測の能力を活用できるようにすることを目的とした一連のライブラリです。散在しているソフトウェアパッケージから必要な機能を探し出すことにフラストレーションを感じている実践者によって開発されており、Nixtlaでは標準化とパフォーマンスに重きを置いており、企業は断続的需要の予測を含む現実世界の予測の問題を比較的簡単に解くことが可能となります。多くの企業がクラウドを活用してタイムリーな方法で膨大な数の予測を生成しようとしていることを知り、NixtlaはFugueエンジンとして知られる高性能、自動スケールアウトエンジンをライブラリに組み込みました。Databricksと組み合わせることで、企業は高速かつコスト効率が高い方法で膨大なボリュームの予測結果を生成できるようになります。
Databricksで実行されたクエリーに対する実行時データリネージをキャプチャするためにUnity Catalogを活用することができます。リネージはすべての言語でサポートされており、カラムレベルまで捕捉されます。リネージデータには、クエリーに関連するノートブック、ワークフロー、ダッシュボードが含まれます。リネージは、ニアリアルタイムでData Explorerに表示され、Databricks REST APIで取得することができます。リネージはUnity Catalogメタストアにアタッチされているすべてのワークスペースから集約されます。これは、あるワークスペースでキャプチャされたリネージは、メタストアを共有する他のワークスペースで参照できることを意味します。リネージデータを参照するには、ユーザーは適切なアクセス権を持っている必要があります。リネージデータは30日間保持されます。
Delta Live Tablesは、信頼性が高く、維持が容易でテスト可能なデータ処理パイプラインを構築するためのフレームワークです。データに対する変換処理を定義すると、Delta Live Tablesはタスクのオーケストレーション、クラスター管理、モニタリング、データ品質、エラー処理を行います。そして、Delta Live Tablesはそれぞれの処理ステップであなたが定義したターゲットスキーマに基づき、どのようにデータが変換されるのかを管理します。また、Delta Live Tablesのエクスペクテーションを活用してデータ品質を維持することもできます。エクスペクテーションによって、期待されるデータ品質を定義し、エクスペクテーションに沿わないデータをどのように取り扱うのかを定義することができます。
機械学習 (ML) システムでは、モデル、コード、データはすべて時間の経過とともに進化し、更新スケジュールと MLパイプラインに摩擦が生じる可能性があります。一方、モデルの再トレーニングが必要になるデータドリフトにより、モデルのパフォーマンスは時間の経過とともに低下する可能性があります。さらに、データ サイエンティストがデータセットを調査し続け、モデルを改善するためにさまざまなアプローチを適用すると、より適切に機能する新しい特徴量や他のモデルファミリーが見つかる可能性があります。そして、コードを更新して再デプロイします。MLOps のベストプラクティスにより、データ サイエンティストは、特徴量エンジニアリング、モデル アーキテクチャ、ハイパーパラメータに関する新しいアイデアを迅速に調査して実装し、新しいパイプラインを自動的に構築、テストして、運用環境にデプロイできます。堅牢で自動化された MLOps システムは、アイデアからビジネス価値の向上まで、組織の AI イニシアチブを強化し、データと ML への投資収益を生み出します。
チェンジデータキャプチャ(CDC)は、ニアリアルタイムのデータアプリケーションにおける顧客の追跡、注文・商品のステータスの追跡の様に、データベースにおけるインクリメンタルな変更(データの削除、追加、更新)を特定、補足するプロセスです。CDCでは、新規イベントが生じるのに合わせて継続的かつインクリメンタルな方法でデータを処理することで、リアルタイムのデータ進化を実現しています。2025年までには企業の80%がマルチクラウドの戦略を実施しようとしていることから、複数の環境におけるETLパイプラインにおけるすべてのデータの変更をリアルタイムかつシームレスに集中管理することが重要となります。
大きく分けて、分散ファイルシステム向けコマンドとローカルファイルシステム向けコマンドに分けて考えるといいかと思います。名前の通り、それぞれのファイルシステムがデフォルトになります。そして、Databricksでは上述のコマンドのいずれにおいても、DBFS、ローカルファイルシステムにアクセスすることができるのですが、明示的に指示をしない場合、デフォルトのファイルシステムにアクセスします。指示する方法は以下の通りです。1. 分散ファイルシステム向けコマンドでローカルファイルシステムにアクセスする場合: パスの先頭にfile:/を追加2. ローカルファイルシステム向けコマンドでDBFSにアクセスする場合: パスの先頭に/dbfsを追加
ファイルシステムが2種類あります。一つ目はDatabricksファイルシステム。Databricksでファイルの永続化に使用するDBFS(Databricksファイルシステム)が存在します。これは、お客さまのクラウドアカウントに構築されるデータプレーン上のオブジェクトストレージ(S3やADLS)を用いて構成される、仮想的なファイルシステムです。２つ目はSparkクラスターのドライバーノードのローカルストレージ。Databricksで計算資源を利用する際は、お客さまクラウドアカウント上に構築されるデータプレーン上にDatabricksクラスター(Apache Sparkクラスター)を構成し、これにノートブックをアタッチして処理を実行します。クラスターの実態はAWSであればEC2、AzureであればVMになります。当然これらにはローカルのストレージがアタッチされています。また、Sparkクラスターはドライバーノードとワーカーノードから構成されていますが、ユーザーは通常ドライバーノードにSparkジョブを投入して結果を受け取るというように、ドライバーノードとやり取りを行います。これは、Databricksでも同様です。ノートブックをDatabricksにアタッチして処理を実行する際はドライバーノードとやり取りを行い、Sparkの並列分散処理はドライバーノードからワーカーノードに指示を行うことで実行され、結果がドライバーノードに戻され、その結果がノートブックに表示されます。この処理の過程でローカルストレージにファイルを保存することが可能です。
ファイルの永続化に使えるのは①のDBFSだけです。クラスターのドライバーノードのローカルストレージは揮発性であり、クラスターを停止すると全てが失われます。このことを理解しておかないと、せっかく準備したデータがなくなってしまった！ということになりかねません。ですので、計算処理過程での中間ファイルなどはローカルストレージに保存し、処理結果のファイルの永続化はDBFSで行うということを意識することが重要となります。もう一つ重要な違いとして、DBFSはオブジェクトストレージで動作しているので、ランダムアクセスはサポートされていません。DBFSにおいてランダムアクセスが発生するような書き込み(例：zip)を行おうとするとエラーになります。この場合、こちらで説明している様にローカルファイルシステム上でzipファイルを作成してから、DBFSにコピーしてください。
過度なクラウドデータストレージのコストを削減するために、すべてのテーブルに対してVACUUMを定期的に実行することをお勧めします。vacuumのデフォルト保持期間は7日間です。閾値を高く設定すると、より長いテーブル履歴にアクセスすることができますが、格納されるデータファイルの数が増加し、クラウドプロバイダーのストレージコストを増加させることになります。
Delta Lakeには、危険なVACUUMコマンドの実行を防ぐ安全チェック機能があります。指定しようとしている保持期間よりも長い時間実行されるオペレーションが存在しないことが確実である場合には、Spark設定spark.databricks.delta.retentionDurationCheck.enabledをfalseに設定することで、安全チェック機能をオフにすることができます。警告！テーブルに対するリーダー、ライターの同時実行によって、古いスナップショットやコミットされていないファイルが使用されている場合があるので、保持期間の最小値は7日間にすることをお勧めします。VACUUMがアクティブなファイルをクリーンアップすると、同時実行されているリーダーが失敗することがあり、さらに悪いケースでは、VACUUMがコミットされていないファイルを削除するとテーブルが破損する場合があります。最長の同時実行トランザクション期間や、テーブルに対する最新の更新に対してすべてのストリームが遅延する最長期間よりも長い期間を選択すべきです。
お使いのアイデンティティプロバイダーからご自身のDatabricksアカウントにユーザーやグループが自動で同期される様に、SCIMプロビジョニングを使用することをお勧めします。SCIMはDatabricksにユーザーやグループを作成するためにアイデンティティプロバイダーを使用するので、新たな従業員やチームのオンボーディングを容易にし、適切なアクセスレベルを付与します。ユーザーが組織を去ったり、Databricksにアクセスする必要がなくなった場合には、管理者はアイデンティティプロバイダーでユーザーを無効化すると、そのユーザーアカウントはDatabricksからも削除されます。これによって、一貫性のあるオフボーディングを確実なものにし、許可されないユーザーがセンシティブなデータにアクセスすることを防ぐことができます。Databricksを使用しようとしているすべてのユーザーとグループのすべてを、個々のワークスペースではなくアカウントコンソールに同期する様にすべきです。これによって、アカウント内にあるすべてのワークスペースにおいて、すべてのアイデンティティの一貫性のある状態を保つために、一つのSCIMプロビジョニングアプリケーションを設定するだけで済む様になります。ワークスペースですでにワークスペースレベルのSCIMプロビジョニングをセットアップしているのであれば、アカウントレベルのSCIMプロビジョニングを有効化し、ワークスペースレベルのSCIMプロビジョンをオフにすべきです。アイデンティティフェデレーションへのアップグレードをご覧ください。
シングルサインオン(SSO)を用いることで、組織のアイデンティティプロバイダーを用いてユーザーを認証できる様になります。セキュリティ強化とユーザビリティの改善のためにSSOを設定することをお勧めします。アカウントとそれぞれのワークスペースでSSOを設定する必要があります。アカウントにおいて、アカウントとすべてのワークスペースで同じアイデンティティプロバイダーのSSOを設定する必要があります。望ましくは、アカウントレベルのSSO設定にOICDを用いて、認証機能のサポートを確実なものとします。ワークスペースでSSOを設定したら、パスワードアクセスコントロールを設定すべきです。パスワードアクセスコントロールによって、REST APIの認証でユーザー名、パスワードを使用できなくすることができます。代わりに、ユーザーはパーソナルアクセストークンを用いてREST APIの認証を行うべきです。すべてのワークスペースユーザーに対してパスワードに対するCan Use権限を許可しないことをお勧めします。パーソナルアクセストークンの詳細については、Manage personal access tokensをご覧ください。
アイデンティティフェデレーションによって、アカウントコンソールでユーザー、サービスプリンシパル、グループを設定することができ、これらのアイデンティティを特定のワークスペースに割り当てることができる様になります。これによって、Databricksにおける管理とデータガバナンスをシンプルなものにします。アイデンティティフェデレーションを用いることで、それぞれのワークスペースで設定を繰り返すことなしに、アカウントコンソールでユーザー、サービスプリンシパル、グループを設定できます。これによって、新たなチームのDatabricksへのオンボーディングにおける摩擦を削減し、ワークスペースごとのSCIMプロビジョニングアプリケーションを別々に管理するのではなく、Databricksアカウントに対してアイデンティティプロバイダーを用いた一つのSCIMプロビジョニングアプリケーションを管理するだけで済む様になります。アカウントにユーザー、サービスプリンシパル、グループが追加されると、それらの権限をワークスペースに割り当てることができます。アイデンティティフェデレーションが有効化されたワークスペースに対してのみ、アカウントレベルのアイデンティティのアクセスを割り当てることができます。ワークスペースでアイデンティティフェデレーションを有効化するには、管理者はどのようにワークスペースのアイデンティティフェデレーションを有効化するのか？をご覧ください。
ワークスペースでアイデンティティフェデレーションが有効化されたので、当該ワークスペースでアカウントアクセス権限をユーザー、サービスプリンシパル、グループを割り当てることができます。ワークスペースの権限をユーザー個人ではなく、ワークスペースにはグループの権限を割り当てることをお勧めします。すべてのDatabricksアイデンティティはグループのメンバーとして割り当てることができ、メンバーはグループに割り当てら得れた権限を継承します。
パイプラインが効率的かつメンテナンスしやすくなる様に、パイプラインのクエリーを実装する際に、テーブルかビューかベストなデータセットタイプを選択する様にしましょう。以下のケースではビューの使用を検討してください: 1. 管理しやすいクエリーに分割したいと考える大規模かつ複雑なクエリーである場合。2. エクスペクテーションを用いて中間結果を検証したい場合。3. ストレージコスト、計算コストを削減したいと考えており、クエリー結果のマテリアライゼーションが不要な場合。テーブルはマテリアライゼーションされるので、計算コストとストレージリソースを必要とします。以下のケースではテーブルの使用を検討してください: 1. 複数の後段のクエリーがテーブルを使用する場合。ビューはオンデマンドで計算されるので、クエリーされるたびにビューは再計算されます。2. 開発中にクエリーの結果を参照したい場合。テーブルはマテリアライズされるので、パイプラインの外で参照、クエリーすることができ、開発中にテーブルを用いることは、計算処理の適切性の検証の役に立ちます。検証後に、マテリアライゼーションが不要なクエリーをビューに変換します。
パイプラインをどの様に分割するのかを決定する際、以下の点を検討してください。以下のケースでは大規模パイプラインにしてください:　1. クラスターリソースをより効率的に活用したい。2. ワークスペースのパイプライン数を削減したい。3. ワークフローのオーケストレーションの複雑性を削減したい。以下のケースでは複数のパイプラインにしてください。1. チーム境界で機能を分割したい場合。例えば、あなたのデータチームではデータを変換するためのパイプラインを維持管理し、データアナリストは変換データを分析するパイプラインを維持管理する場合。2. 結合度を削減し、共通機能の再利用を促進するために、アプリケーション固有の境界で機能を分割する場合。
パイプラインにおけるクラスターの使用率を最適化するために、強化オートスケーリングを使いましょう。強化オートスケーリングは、リソースの追加によってパイプラインの処理スピードを改善するとシステムが判断した時のみリソースを追加します。不要になるとすぐにこれらのリソースは解放され、すべてのパイプラインのアップデートが完了するとクラスターはシャットダウンします。プロダクションパイプラインで強化オートスケーリングを設定する際には、以下のガイドラインを使用してください。1. Min workersの設定はデフォルトのままにしてください。2. 予算とパイプラインの優先度に基づいて、Max workersを設定してください。3. Delta Live Tablesランタイムが、ワークロードにベストなインスタンスタイプを選択できる様に、インスタンスタイプは未設定の状態にしてください。
Delta Sharingを利用するとDatabricks to Databricksもしくは Databricks to Open(DeltaSharing Client)間でデータ共有が行えるようになります。共有といってもReadOnlyなので一方通行ですが、他のデータブリックス環境で作成されたデータを、どのデータブリックス環境（もちろん許可された）からアクセス出来るようになったら、データ活用の幅が広がる気がします。
Databricksランタイムには、標準的なPythonパッケージの一つとしてpandasが含まれており、Databricksのノートブックやジョブでpandasデータフレームを作成、活用することができます。Databricksランタイム10.0以降では、Pandas API on SparkがPySparkデータフレーム上における馴染み深いpandasコマンドを提供しています。また、pandasデータフレームとPySparkデータフレームの間で変換を行うことができます。Apache Sparkには、PySparkデータフレームに直接pandasの変換処理を適用できるpandas function APIの形でPythonロジックを実行するArrow最適化処理が含まれています。また、Apache Sparkでは、Pythonで定義された任意のユーザー関数に対して同様のArrow最適化を活用するpandas UDFもサポートしています。
Databricksのさまざまな場所にデータを格納するためにpandasを使用することができます。どこにデータを格納し、どこからデータをロードできるのかは、ワークスペース管理者による設定に依存します。注意！クラウドオブジェクトストレージにプロダクションのデータを格納することをお勧めします。Working with data in Amazon S3をご覧ください。Unity Catalogが有効化されたワークスペースをお使いの際には、外部ロケーションのクラウドストレージにアクセスすることができます。Unity Catalogにおける外部ロケーションとストレージ認証情報の管理をご覧ください。
Databricksでは、探索のためにワークスペースにデータをアップロードするために、数多くの選択肢を提供しています。pandaによるデータロードで望ましい方法は、データをどのようにワークスペースにロードするのかによって変化します。ローカルマシン上にノートブックと一緒に小規模なデータファイルを格納していたのであれば、データとコードを一緒にReposにアップロードすることができます。データファイルをロードするために相対パスを使うことができます。Databricksではデータロードに対する数多くのUIベースのオプションを提供しています。これらのオプションの多くは、あなたのデータをDetlaテーブルとして保存します。そして、SparkデータフレームにDeltaテーブルを読み込み、それをpandasデータフレームに変換することができます。DBFSや相対パスを用いてデータファイルを保存している場合には、これらのデータファイルを再ロードするためにDBFSや相対パスを使用することができます。以下のコードではサンプルを示しています。
Unity Catalogは、DatabricksレイクハウスにおけるデータとAIに対するきめ細かいガバナンスソリューションです。データアクセスを集中的に管理、監査できる場所を提供することで、データに対するセキュリティ、ガバナンスをシンプルにする助けとなります。以下の図では、Unity Catalogにおける主要なセキュリティ保護可能オブジェクトを示しています。メタストアはUnity Catalogにおけるトップレベルのコンテナです。データ資産(テーブルやビュー)とそれらに対するアクセスを管理する権限を格納します。Databricksのアカウント管理者はメタストアを作成し、どのワークロードがどのメタストアを使用するのかをコントロールするためにDatabricksワークスペースに割り当てることができます。オペレーションを行うそれぞれのリージョンに一つのメタストアを作成し、当該リージョンのすべてのワークスペースにリンクさせます。このため、Databricksが複数のリージョンで稼働している場合、複数のメタストアを持つことになります。メタストア間でデータを共有するには、Delta Sharingを使用します。それぞれのメタストアには、マネージドテーブルで使用されるルートストレージロケーションが設定されます。このストレージロケーションにいかなるユーザーも直接のアクセス権を持たない様にする必要があります。ストレージロケーションへのアクセスを許可すると、ユーザーはUnity Catalogメタストアによるアクセスコントロールを迂回し、監査可能性を阻害することになります。これらの理由から、現在DBFSのルートファイルシステムに使用しているバケットや、Unity Catalogメタストアのルートストレージロケーションとして使用していたDBFSルートファイルシステムのバケットを再利用すべきではありません。
皆様の組織の情報アーキテクチャにおける区域を提供するためにカタログを使用することをお勧めします。多くの場合、これはカタログがソフトウェア開発環境のスコープ、チーム、ビジネスユニットに対応することを意味します。スキーマ(データベースよも呼ばれます)は、Unity Catalogの3レベル名前空間の2番目のレイヤーであり、テーブルやビューを整理します。テーブルはマネージドあるいは外部テーブルとなります。Unity Catalogにおいてテーブルを作成する際、マネージドテーブルがデフォルトとなります。これらのテーブルはメタストアを作成した際に指定したUnity Catalogのルートストレージロケーションに格納されます。Unity Catalogの機能サポートを確実にするために、可能な限りマネージドテーブルを使用することをお勧めします。すべてのマネージドテーブルはDelta Lakeを使用します。外部テーブルは、マネージドのストレージロケーションの外のストレージロケーションにデータが格納されるテーブルです。これらはUnity Catalogによって完全には管理されません。外部テーブルでは、Delta Lakeや、Parquet、JSON、CSVを含む数多くのデータフォーマットをサポートしています。生のデータに対する直接アクセスを提供する際、外部テーブルは好適なオプションと言えます。
4つの外部ロケーションが作成され、それらすべてによって使用される1つのストレージ認証情報があります。ユーザーやグループには、Unity Catalogメタストア内の別々のストレージロケーションに対してアクセスを許可することができます。これによって、特定のグループに対してクラウドストレージバケットの別の部分へのアクセスを許可することができます。Unity Catalogメタストアのストレージロケーションを用いて外部テーブルをs買う制することができます。これらの外部テーブルは独立にセキュリティ保護することができます。1つのスキーマ内の1つのストレージロケーションから外部テーブルを作成することをお勧めします。一貫性に関する問題のリスクから、1つ以上のメタストアの外部テーブルとして共通のテーブルを登録することは強くお勧めしません。例えば、1つのメタストアにおけるスキーマへの変更は、2番目のメタストアに登録されません。メタストア間でデータを共有するには、Delta Sharingを使用してください。
Unity Catalogにおける個々のセキュリティ保護可能オブジェクトにはオーナーが存在します。オブジェクトを作成したプリンシパルが最初のオーナーとなります。オブジェクトのオーナーは、テーブルのSELECTやMODIFY、他のプリンシパルにセキュリティ保護可能オブジェクトの権限を付与する権利など、オブジェクトに対するすべての権限を有します。このため、オブジェクトに対する権限付与に責任を持つグループに、すべてのオブジェクトに対するオーナーシップを設定することがベストプラクティスとなります。オーナーとメタストア管理者の両方が、セキュリティ保護可能オブジェクトのオーナーをグループに移譲することができます。さらに、(テーブルやビューなど)オブジェクトがカタログに含まれている場合、カタログとスキーマのオーナーがオブジェクトのオーナーシップを変更することができます。Unity Catalogにおけるセキュリティ保護可能オブジェクトは階層的であり、権限は下方に継承されます。これは、カタログやスキーマに対して付与した権限が、カタログやスキーマに存在する、あるいは今後作成されるオブジェクトすべてに自動で権限が付与されることを意味します。詳細に関しては、Inheritance modelをご覧ください。テーブルやビューからデータを読み込むには、ユーザーは以下の権限を有している必要があります:　
 1. テーブルやビューに対するSELECT 
 2. テーブルを保持するスキーマに対するUSE SCHEMA 
 3. スキーマを保持するカタログに対するUSE CATALOG 
 4. USE CATALOGによって、許可されたユーザーが子供のオブジェクトにアクセするためにカタログを移動でき、USE SCHEMAによって、許可されたユーザーが子供のオブジェクトにアクセスするためにスキーマを移動できます。例えば、テーブルからデータを取得するには、ユーザーはテーブルに対するSELECT権限を有している必要があり、親のカタログに対するUSE CATALOG権限と、親のスキーマに対するUSE SCHEMA権限が必要となります。このため、特定のグループに対してご自身のデータ名前空間のセクションへのアクセスを制限するために、この権限を活用することができます。一般的なシナリオは、チームごとにスキーマをセットアップし、当該チームのみがそのスキーマに対するUSE SCHEMAとCREATE権限を持つというものです。これは、チームメンバーによって作成されたすべてのテーブルはチーム内でのみ共有されるということを意味します。
一連のルールに基づいてクラスターを設定する能力を制限するために、クラスターポリシーを用いることをお勧めします。クラスターポリシーによって、Unity Catalogが有効化されたクラスターのみを作成できる様に制限をかけることができます。クラスターポリシーを用いることで選択肢を削減し、ユーザーのクラスター作成プロセスをシンプルにし、シームレスにデータにアクセスできる様になります。また、クラスターポリシーで、クラスタあたりの最大コストを制限することでコストをコントロールすることができます。アクセスコントロールの一貫性を保証し、強力なアイソレーション保証を強制するために、Unity Catalogは計算資源に対するセキュリティ要件を課します。このため、Unity Catalogではクラスターのアクセスモードというコンセプトを導入しています。Unity Catalogはデフォルトで保護されています。クラスターに適切なアクセスモードが設定されていない場合、クラスターはUnity Catalogのデータにアクセスすることができません。Unity Catalogにおけるクラスターアクセスモードをご覧ください。クラスターを共有する際にはユーザー分離アクセスモードを使用し、自動化ジョブや機械学習ワークロードにはシングルユーザーアクセスモードを使うことをお勧めします。
完全なデータガバナンスソリューションには、アラート、モニタリング能力を提供するデータアクセスの監査が必要となります。Unity Catalogはメタストアに対するアクションの監査ログを取得し、Databricks監査ログの一部としてデリバリーされます。監査ログの設定を確認してください。これには、あなたが指定するS3バケットにDatabricksが監査ログをデリバリーできる様にするための適切なアクセスポリシーの設定が含まれています。通常、監査ログは15分以内に記録されます。アカウント内のすべてのワークスペースで同じ監査ログ設定を使用する様にしてください。お使いのDatabricksレイクハウスプラットフォームに関連する重要なイベントに対する完全なる可視性をどの様に得るのかに関しては、監査ログによるDatabricksレイクハウスプラットフォームのモニタリングをご覧ください。
Delta Sharingは、使用している計算プラットフォームに関係なく企業内の別部門、あるいは別組織とセキュアにデータを共有するためにDatabricksによって開発されたオープンプロトコルです。メタストアでDelta Sharingが有効化されると、Unity CatalogはDelta Sharingサーバーを稼働させます。メタストア間でデータを共有するには、Databricks-to-Databricks Delta Sharingを活用することができます。これによって、別のリージョンのメタストアからテーブルを登録することができます。これらのテーブルは利用するメタストアで読み取り専用オブジェクトとして表示されます。これらのテーブルは他のUnity Catalogのオブジェクトと同じようにアクセス権を設定することができます。メタストア間でDatabricks-to-Databricks Delta Sharingを用いる際、アクセスコントロールは一つのメタストアに限定されることに注意してください。テーブルの様なセキュリティ保護可能オブジェクトにアクセス権が設定されており、そのリソースがイントラアカウントのメタストアに共有された場合、ソースからの権限が対象の共有には適用されません。対象の共有においては自身で権限を付与する必要があります。
地理空間情報分析とは「特定エリアに関する位置情報とそれに紐づく事象のデータから有益な知見や発見を得ること」を指します。代表的なデータには衛星画像や船舶・飛行機・車載機器・携帯電話などから取得できる位置情報データが存在し、それらを使ってデータを可視化・分析して地球上で何が起きているのか理解できます。また世界で大きなポテンシャルを秘めている領域と考えられており、米国の市場調査会社のひとつは、世界の高精度な地理空間情報ビジネスの市場規模は、2020 年時点で 568.8 億ドル（約 7兆 6,788 億円）、その後 2020 年から年 12.8％のペースで成長し、2028 年には 1,475.8 億ドル（約 19 兆 9,233 億円）に達すると予測しています。日本でも衛星画像分析用のプラットフォーム Tellus や位置情報を使った人口の統計情報 モバイル空間統計 をNTTドコモ社が運営されていたりと、多くの企業・団体がサービスを展開して盛り上がっている市場です。
従来はUnity CatalogのManaged Tableとして利用する場合、DeltaLakeの保存先はUnity Catalogセットアップ時に作成するメタストアのストレージのみでした。そのため複数のワークスペースでUnity Catalogを共有してもストレージは同じになってしまうため、管理や課金を分割出来ないという問題がありました。（従来は外部テーブルしか利用できなかった）今回の機能によって、カタログやスキーマ単位でストレージロケーションを分けられるため上記のような問題が解消されます。これは管理者からするとかなり嬉しい機能なのです。