bowang0911/databricks-qa-ja huggingface dataset:
TensorFlow には、多くのメリットがあります。オープンソースの機械学習フレームワークは、優れたアーキテクチャをサポートしており、さまざまなプラットフォームで計算フレームワークを容易にデプロイできます。Google の評判の良さもあり、いくつかの大手企業が TensorFlow を採用して人工知能のタスクを実行しています。
 一方、TensorFlow の実装の詳細によっては、完全に決定論的なモデル学習結果を得ることが困難な場合もあります。しかし、開発チームは、ワークフローにおける決定論に影響を与える制御を増やすことを検討しています。
 TensorFlow の導入はシンプルです。特に、TensorFlow by Databricks は、Databricks Runtime for Machine Learning を介してすぐに統合できるため、簡単に始めることができます。クラスタを数秒で立ち上げることができ、低レベルおよび高レベルの API を幅広く利用できます。
アノマリー検知とは、定常状態とは統計的に異なる不審なイベントや観測値を特定する手法です。異常検知とも呼ばれます。このような「異常」な挙動は、多くの場合に、クレジットカードの不正使用、マシンの故障、サイバー攻撃といった問題の存在を意味します。例えば、膨大な数のトランザクションの監視が必要な金融業界では、アノマリー検知がエラーの発生場所の特定や原因の分析を支援し、問題への迅速な対応を可能にします。また、検知した異常値をもとにしたアラートの発行にも活用され、担当者の行動を促します。そこから得られる情報は、カオスエンジニアリングにも利用されます。最近では、詐欺行為の検知やマネーロンダリング対策（AML）に機械学習や AI が活用されるケースが増えています。
オルタナティブデータ（代替データとも呼ばれる）とは、従来のソースではなく、他のユーザーによって使用されていない代替データソースから収集されたデータ情報です。オルタナティブデータを分析に活用することで、業界標準のデータソースでは得ることができない洞察を取得することが可能です。ただし、正確には何をオルタナティブデータとみなすかは業界によって異なり、自社や競合他社で既に使用されている従来のデータソースに依存されています。
オーケストレーションとは、複数のコンピュータシステム、アプリケーション、サービスを調整および管理し、大規模なワークフローやプロセスを実行するために複数タスクをつなぎ合わせることです。これらのプロセスは、自動化された複数タスクで構成され、複数のシステムをまたぐこともあります。
 オーケストレーションは、頻繁に繰り返されるプロセスの実行を効率化および最適化し、データチームが複雑なタスクやワークフローを容易に管理できるようにします。プロセスはいつでも繰り返しが可能で、タスクは自動化できるため、オーケストレーションは時間の節約、効率性の向上、重複の排除を実現します。例えば、Databricks のジョブオーケストレーションは、データや機械学習をシンプルにします。
自動化とオーケストレーションは、極めて補完的な関係にあります。しかし、それぞれの意味は異なります。自動化とは、人の手を介することなく実行されるタスクをプログラミングすることです。オーケストレーションとは、複数のタスク（一部は自動化されている場合もある）を 1 つの完全なエンドツーエンドのプロセスまたはジョブに設定することです。オーケストレーションソフトウェアは、プロセス全体のイベントまたはアクティビティに反応し、1 つの自動化タスクからの出力に基づいて意思決定を行い、次のタスクを決定し調整する必要があります。
オープンバンキングとは、消費者の事前同意のもとに、消費者の金融データへのアクセスをセキュアに共有する方法です²。規制や技術革新、競合の勢いに後押しされ、オープンバンキングは、銀行以外の第三者や消費者などが顧客データをさらに活用できるよう、顧客データの民主化を呼びかけています。この技術革新は、銀行業界を他業界との高い連携性を持つプラットフォーム提供者へと進化させると同時に、銀行にエコシステムを拡大し、新規市場への参入機会を与えています。
データブリックスでは、Apache Sparkの最適化されたバージョンを、Spark-as-a-Service（サービスとしてのSpark）として複数のクラウドでホストしています。サービスとしての Spark には、データアクセスおよびデータ分析を迅速に行うアプリケーションが組み込まれており、ストリーミングデータの処理、グラフ計算の実行、Hadoop で SQL の提供、機械学習機能など、ビッグデータ上で動作する Spark の多くの機能を活用しています。
スタースキーマとは、データベース内のデータを整理することで理解・分析しやすくなった多次元データモデルで、データウェアハウスやデータベース、データマート、その他のツールに適用できます。スタースキーマの設計は、大規模なデータセットへのクエリを実行するために最適化されています。
3NF（第 3 正規形）とは、正規化によってデータの冗長性を減らす手法であり、完全に正規化されたとみなされるデータベースの標準規格です。データの正規化により、スタースキーマと比べて多くのテーブルを持つのが一般的です。一方で、大規模なテーブル間の結合が増えるため、クエリが複雑になる傾向があります。
スノーフレークスキーマは、スタースキーマを拡張した多次元データモデルで、ディメンションテーブルがサブディメンションテーブルに細分化されたものです。スノーフレークスキーマは、データウェアハウスやデータマート、リレーショナルデータベースの多次元分析を使用した BI（ビジネスインテリジェンス）やレポーティングによく使用されています。
スタースキーマと同様に、スノーフレークスキーマの中央にもファクトテーブルがあり、外部キーを介して複数のディメンションテーブルに接続されています。しかし、スタースキーマと異なり、スノーフレークスキーマはより正規化が進んでいます。
 スノーフレークスキーマは、高い正規化基準に厳密に準拠しており、ストレージ効率性は高いのですが、非正規化データモデルと比べるとクエリ時のパフォーマンスは劣ります。一方で、スタースキーマのような非正規化データモデルでは、データの冗長性（データの重複）が高く、データの重複を許容する代わりにクエリのパフォーマンスを高速化することができます。
データウェアハウス（DWH）は、複数のソースから得られた最新データや履歴データをビジネスに適した形で蓄積し、知見の取得やレポート作成を容易にするデータ管理システムです。主に、ビジネスインテリジェンス（BI）、レポート作成、データ分析に使用されます。
 データウェアハウスでは、POS システム、インベントリ管理システム、マーケティングや販売データベースなどの業務システムに蓄積されたデータを、迅速かつ容易に分析可能です。データは、オペレーショナルデータストアを中継する場合があり、データウェアハウスでレポート作成のために使用する前にデータクレンジングを行い、データ品質を確保する必要があります。
データの変換には、ETL（抽出、変換、ロード）と ELT（抽出、ロード、変換）の 2つの方法があります。データエンジニアは通常、ETL（抽出・変換・ロード）を使用し、さまざまなデータソースから抽出したデータをデータウェアハウスに移動させて、データクレンジングやデータの構造化を行います。一方、ELT では、まず元の形式のデータをデータウェアハウスにロードし、処理する際にデータクレンジングと構造化を行います。
 ETL は通常、全社的なデータクレンジングと準拠規則を適用するために、企業のデータエンジニアリングチームによって一元的に行われます。一方、ELT は、プロジェクトやビジネスチームに特化した変換が後の段階で行われ、セルフサービス分析を可能にします。
オンライントランザクション処理（OLTP）システムは、データベース内のトランザクションデータの取得および管理を行います。トランザクションには、複数のフィールドやカラムで構成される独立したデータベースレコードが含まれます。OLTP データベースは、オンラインバンキング、ERP システム、インベントリ管理などのアプリケーションで頻繁に使用され、瞬時に処理される行レベルのデータを迅速に更新します。
 オンライン分析処理（OLAP）システムは、データマイニング、分析、ビジネスインテリジェンスのプロジェクトに使用され、OLTP データベースやその他のソースから集約された膨大な履歴データに複雑なクエリを適用します。データウェアハウスは OLAP システムです。OLAP データベースとデータウェアハウスにより、アナリストや意思決定者は、カスタムレポートツールを使用して、データドリブンな情報の収集と意思決定ができるようになります。OLAP データベースでクエリに失敗しても、顧客のトランザクション処理が中断したり遅延したりすることはありませんが、ビジネスインテリジェンスに関する分析結果の取得が遅れたり、精度に影響を及ぼしたりする可能性があります。
データガバナンスとは、データがビジネス戦略に沿った価値をもたらすよう、組織内のデータを統制することを意味します。単なるツールやプロセスにとどまらず、人、プロセス、技術、データを包括するフレームワークを用いてデータを統制し、ビジネスの目標達成を支援するものです。
データ管理は、信頼性のあるデータを提供するために、データガバナンスのポリシーや原則、基準に準拠することを重要視した実務です。データ管理は通常、プロジェクト中心の短期的なものです。一方、データガバナンスは、長期的なメリットの実現を目指すプログラムとして扱われます。ガバナンスの実施には、一元化されたガバナンスツールが重要な役割を果たします。
データレイクハウスとは、データレイクの柔軟性、経済性、スケーラビリティとデータウェアハウスのデータ管理や ACID トランザクションの機能を取り入れたオープンで新たなデータ管理アーキテクチャで、あらゆるデータにおけるビジネスインテリジェンス（BI）と機械学習（ML）を可能にします。
データ分析プラットフォームとは、膨大で複雑な動的データの分析に必要なサービスとテクノロジーのエコシステムです。企業が所有する各種ソースからのデータの取得、結合、連動、検索、視覚化を可能にします。包括的なデータ分析プラットフォームには、予測分析、データ視覚化、ロケーションインテリジェンス、自然言語、コンテンツ分析など、さまざまな機能を搭載した複数のツールが組み込まれています。その主な目的は、あらゆる種類のデータを実用的な洞察に変換し、真のビジネス成果につなげることです。
ニューラルネットワークとは、層状構造が人間の脳内にあるニューロンのネットワーク構造に類似した数理モデルです。ニューロンと呼ばれる相互に結合する処理要素を特徴としており、出力機能を生成します。ニューラルネットワークは、入力層と出力層で構成されており、その多くには隠れ層があります。この隠れ層は、入力を出力層で使用できるものに変換するユニットで構成されています。
コンピューティングにおけるハッシュテーブル [ハッシュマップ] とは、キー [一意の文字列または整数] に基づいてオブジェクトに事実上直接アクセスできるデータ構造です。ハッシュテーブルは、バケットやスロットの配列にインデックス計算を行うために、ハッシュ関数を使用し、そこから目的の値をみつけます。使用されるキーの主な特徴は次のとおりです。1. 社会保障番号、電話番号、口座番号などのキーを使用します。2. キーは一意である必要があります。3. 各キーは、値に関連付け（マッピング）されます。
ベイジアンニューラルネットワーク（BNN）とは、過学習の制御を目的として、事後確率推定により標準ネットワークを拡張することを指します。広い視点からみると、ベイジアン手法は統計的方法論を使用して、モデルパラメータ（ニューラルネットワークの重みとバイアス）を含む、あらゆるものがそれに付随する確率分布を持つようにすることです。
マネージド Spark は、バッチ処理、クエリ、ストリーミング、機械学習などのオープンソースのデータツールを利用できるマネージドサービスです。ユーザーは、このような自動化を使用することで、オンデマンドでクラスタの迅速な作成や管理を容易し、タスクが完了したときにクラスタをオフにすることができます。ワークロード、パフォーマンス要件、または既存のリソースに基づいてクラスタのサイズを設定することも可能です。さらに、ほんの数秒で動的にスケールアップおよびスケールダウンできる、完全に管理された Spark クラスタへのアクセス権が付与されます。これは、ジョブの処理中でも実行できます。さらに、ユーザーは不要になったらクラスタをオフにすることで、コストを節約できます。マネージド Spark プロバイダーは、プロビジョニングを行い、全てのジョブのクラスタを保持する代わりに、一時クラスタを作成します。通常、マスターノードとワーカーノードを持つマシンのクラスタを使用します。マネージド Spark のサービスを採用することで、組織は貴重なリソースを運用ではなく分析に活用することができ、データから価値を引き出す作業に集中できるようになります。
モデルリスク管理とは、モデルの誤りまたは誤用に基づく意思決定によって生じる潜在的な悪影響がもたらすリスクを管理することです。モデルリスク管理は、モデルリスク、すなわちモデルの誤りや誤用の可能性を特定、測定、軽減する技術や手法を取り入れることを目的にしています。金融サービスにおけるモデルリスクとは、精度が低いモデルを使用して意思決定を行うことで生じる損失リスクを意味します。多くの場合は金融証券の評価に使用され、消費者信用スコアの付与、クレジットカードの不正取引のリアルタイムな確率予測、マネーロンダリングといった範囲にも広がっています。金融機関では信用や市場への依存度が高く、モデルリスクに対する行動モデルは、リスク管理や業務効率化において重要な要素となっています。このような金融機関は、主にリスクを負うことで利益を得ています。そのため、リスクの評価や顧客行動の把握、コンプライアンス対応の自己資本の評価、投資の意思決定、データ分析の管理にモデルを最大限に活用しています。効果的なモデルリスク管理のフレームワークの導入は、業務や意思決定において定量モデルに大きく依存している組織には不可欠です。
ラムダアーキテクチャとは、膨大なデータ「ビッグデータ」を処理するアプローチです。ハイブリッドアプローチを使用してバッチ処理やストリーム処理メソッドへのアクセスを提供し、任意の関数を計算する問題を解決するために使用されます。ラムダアーキテクチャは3つのレイヤーから構成されています。
予測型メンテナンスとは、一言でいうと、予め定められたスケジュールだけでなく、設備の実際の状態や状況に基づき、いつ頃、具体的にどのようなメンテナンスを行うべきかを判断し、設備の稼働時間と生産性を最大化するためのものです。故障を予測や予防し、適切な定期メンテナンスを実施することで、コストのかかる機器のダウンタイムを削減できます。
 IoT とセンサーデータが機器からストリーミングされることで、予測型メンテナンスは、製造業者が効率的に機械が停止するタイミングを予測することを可能にします。データは、ばらつきを検知し警告信号を把握することで、故障の可能性を示すあらゆるパターンを特定します。製造業者は、分析と機械学習を使用し機械が停止する確率を正確に予測できます。これにより、早期修正対策の計画（スペアパーツの発注や修理のスケジューリングなど）と最も効果的な方法での導入が可能になり、予想外のダウンタイムとコストがかかってしまうスタッフやリソースを回避できます。
構造化ストリーミングとは、ストリーミングデータを処理するための高レベル API です。Spark 2.2 で実運用が可能になりました。構造化ストリーミングでは、Spark の構造化 API を使用してバッチモードで実行するのと同じ操作が、ストリーミング形式で実行可能です。これにより、レイテンシの短縮、インクリメンタル処理が可能になります。構造化ストリーミングの最大のメリットは、事実上コードを変更することなく、ストリーミングシステムから迅速に価値を引き出すことができることです。また、バッチジョブをプロトタイプとして記述し、それをストリーミングジョブに変換できるため、推論も容易になります。これはデータを段階的に処理することで可能になります。
機械学習パイプラインとは、'spark.ml' パッケージ下にあるMLlibのための高レベルAPIです。パイプラインには、一連のステージがあり、基本的なパイプラインのステージタイプは、トランスフォーマーとエスティメーターの2つです。トランスフォーマーは、データセットを入力として受け取り、出力として拡張データセットを生成します。例えば、トークナイザは、テキストのデータセットをトークン化した単語のデータセットに変換するトランスフォーマーです。エスティメーターは、入力データセットを変換するトランスフォーマーであるモデルを生成するために、最初に入力データセットに適合させる必要があります。例えば、ロジスティック回帰は、ラベルと特徴量でデータセットをトレーニングし、ロジスティック回帰モデルを生成するエスティメーターです。
機械学習モデルとは、未知のデータセットからパターンを発見したり、判断を導き出すプログラムのことです。例えば、自然言語処理では、機械学習モデルにより、これまで聞き取れなかった文章や単語の組み合わせの背後にある意図を解析し、正しく認識できます。また、画像認識では、機械学習モデルを学習させることで、車や犬などのオブジェクトを認識できます。機械学習モデルは、大規模なデータセットを用いて「トレーニング」することで、上述のようなタスクの実行が可能になります。トレーニングでは、機械学習アルゴリズムはデータセットから特定のパターンやアウトプットを発見するように最適化されます。このプロセスによるアウトプットは、多くの場合、特定のルールとデータ構造を持つコンピュータプログラムであり、機械学習モデルと呼ばれます。
機械学習アルゴリズムとは、データセットからパターンを見つけるための数学的手法です。機械学習アルゴリズムは、統計学、微積分学、線形代数学の知識が用いられていることが多く、代表的な例には、線形回帰、決定木、ランダムフォレスト、XGBoost があります。
トレーニングデータと呼ばれるデータセット上で機械学習アルゴリズムを実行し、特定のパターンやアウトプットを発見するためにアルゴリズムを最適化するプロセスを、モデルのトレーニングと呼びます。また、その結果として得られるルールとデータ構造を持つ関数を、トレーニング済み機械学習モデルと呼びます。
教師あり学習では、アルゴリズムは提供されたインプットデータセットに対して特定のアウトプットのセットを満たすように正解を与えられ、最適化されます。例えば、画像認識には、教師あり学習の分類と呼ばれる手法が広く用いられています。また、人口増加や健康状態などの人口統計の予測には、教師あり学習の回帰と呼ばれる手法が利用されています。
教師なし学習では、アルゴリズムは入力データセットを提供されますが、特定のアウトプットに対する正解は与えられず、共通の特性によってデータセット内のオブジェクトをグループ化するようにトレーニングされます。例えば、オンラインショップの推薦エンジンには、教師なし学習のクラスタリングと呼ばれる手法が用いられています。
強化学習では、アルゴリズムは多くの試行錯誤を繰り返しながら、自らトレーニングを行います。強化学習は、アルゴリズムがトレーニングデータに依存するのではなく、環境と継続的に相互作用することで実現されます。強化学習の代表的な例として、自律走行が挙げられます。
Apache Spark の機械学習ライブラリ（MLlib）とは、シンプルでスケーラビリティが高く、他のツールと容易に統合できるように設計された、機械学習を実装するためのツールです。Sparkのスケーラビリティ、言語の互換性、高速性により、データサイエンティストは、分散データを取り巻く複雑さ（インフラストラクチャ、構成など）の解決ではなく、データの問題とモデルに集中できます。Spark 上に構築されたMLlibは、分類、回帰、クラスタリング、協調フィルタリング、次元削減、基になる最適化プリミティブなど、一般的な学習アルゴリズムとユーティリティで構成されるスケーラブルな機械学習ライブラリです。
深層学習とは、人間の脳の構造と機能にインスパイアされたアルゴリズムを用いて膨大なデータを扱う機械学習のサブセットです。そのため、深層学習モデルはディープニューラルネットワークと呼ばれます。深層学習は、データ表現の学習に基づく機械学習手法の1つで、従来のタスク固有のアルゴリズムとは異なります。
基本的に三種類があります。1. 入力層：情報を受け取り、下層のノードに伝達します。ここで、ネットワークはローカルコントラストのパターンを重要なものとして、固定化します。2. 隠れ層：計算が表示される層で、ローカルコントラストのパターンを使用して類似のものに固定化します。3. 出力層：計算結果が表示されます。この層では、特徴量がテンプレートに適用されます。
総合人工知能（ UAI ）は、開発者カンファレンス「F8 」で Facebook によって発表されました。UAI は Facebook 主導で開発された、PyTorch と Caffe の 2 つの深層学習フレームワークを統合したもので、PyTorch は大規模なコンピューティングリソースへのアクセスを想定したリサーチに焦点を当て、Caffeは、Android や Raspberry Pi デバイスのモデル展開に焦点を当てています。
統合データウェアハウス（エンタープライズデータウェアハウスとも呼ばれる）は、業務に関わるあらゆるデータを保持し、エンタープライズ全体でのアクセスが可能な統合データベースです。今日、多くの企業においてデータはサイロ化されています。データの品質、統合、ガバナンスの保守や、メタやマスターデータ、B2B データ交換、データベース、アーキテクチャの管理など、同じ組織内の異なるそれぞれの部門で、多様なデータをさまざまなツールで管理しています。大企業におけるデータウェアハウス（ DW）の採用は、さまざまな異種オペレーショナルソースから抽出した統合および一元化されたデータを格納するためのベストプラクティスとなっています。DW を採用することで、運用システムのトランザクション処理と競合することなく、複雑なクエリを実行することができます。
複合イベント処理（CEP）とは、イベント処理、ストリーム処理、あるいはイベントストリーム処理とも呼ばれ、データベースにデータを格納する前か、場合によっては格納せずに、データを照会する技術を使用した処理です。複合イベント処理は、多くの異なる情報を集約するのに有用で、イベント間の因果関係をリアルタイムで特定、分析する整理ツールです。CEPでは連続的に収集されるイベントをパターンと照合し、イベント内容についての洞察の提供、効果的なアクションの積極的な実行を可能にします。
Databricks Community Edition は、 クラウドベースのビッグ データ プラットフォームの無料バージョンです。そのユーザーは、クラスター マネージャーとノートブック環境だけでなく、マイクロ クラスターにもアクセスできます。すべてのユーザーは、ノートブックを共有し、Databricks を使用して無料でホストできます。これにより、Apache Spark™ コミュニティ全体に利益をもたらす新しいエキサイティングなコンテンツを誰もが作成できるようになることを願っています。

Databricks Community Edition には、受賞歴のあるトレーニング リソースの豊富なポートフォリオも付属しており、開発者、データ サイエンティスト、データ エンジニア、およびその他の IT プロフェッショナルが Apache Spark を学習するのに理想的です。
Databricks Community Edition ユーザーは、サブスクリプションを完全な Databricks プラットフォームにアップグレードすることで、より多くの容量を取得し、運用グレードの機能を得ることができます 。アップグレードするには、  14 日間の無料試用版にサインアップする か、 お問い合わせください。
Databricks Community Edition を使用すると、ユーザーは 15 GB のクラスター、クラスター マネージャー、および単純なアプリケーションのプロトタイプを作成するためのノートブック環境、および BI 分析のための JDBC / ODBC 統合にアクセスできます。Databricks Community Edition へのアクセスは時間制限がなく、ユーザーはクラスターの使用に対して AWS のコストを負担しません。

完全な Databricks プラットフォームは 、簡単にスケールアップまたはスケールダウンできる無制限の数のクラスター、ジョブ ランチャー、コラボレーション、高度なセキュリティ コントロール、専門家によるサポートなど、運用レベルの機能を提供します。ユーザーがデータを大規模に処理したり、チーム設定で Apache Spark アプリケーションを構築したりするのに役立ちます。
Databricks のインストラクター主導のトレーニングは、有料で誰でも利用できます。

公開研修はスケジュールがあらかじめ決まっており、多くの団体の方が参加されます。クラスへの登録に関心のある出席者が数人しかいない場合に最適です。

プライベート トレーニングは、よりパーソナライズされたトレーニング体験を希望し、コースのスケジュールと提供を管理したいグループ (組織内など) に利用できます。パブリック クラスまたはプライベート クラス用に新しいカスタム トレーニング コンテンツを作成することはありませんが、プライベート配信の場合は、既存のコースウェアをカスタムで組み合わせて作成できます。
残念ながら、内部目的であろうとお客様のためにであろうと、インストラクターによるトレーニング クラスの記録は許可されていません。

録音を禁止することで、コースを受講するインストラクターと受講生のプライバシーを保護することができます。また、トレーニング セッションを記録すると、学生が率直な質問をする可能性が低くなり、コースの教材に積極的に関与する気がなくなるため、効果的な教育体験が得られない可能性があることもわかりました。

記録されたトレーニング資料にアクセスしたい場合は、Databricks Academy にログインすると、トレーニング資料の多くが事前に記録されており、自分のペースで進められる無料のコンテンツとして利用できます。
はい、コースの資料をエクスポートして、後で参照するために独自の Databricks ワークスペースにインポートすることができます。独自の Databricks ワークスペースがない場合は、  無料の Databricks Community Edition アカウントにサインアップできます (注: Community Edition ですべての機能が有効になっているわけではありません)。
はい！他の言語で提供される今後の公開クラスを確認できます (英語以外の場合は言語を示します)。また、これをプライベートでリクエストすることもできます。対応するリソースがあるかどうかを確認します.

注: 私たちのカリキュラムは、英語と日本語で利用できます。他のすべての言語については、インストラクターはその要求された言語で教えますが (空き状況に応じて)、コースウェア (ノートとスライド) は英語のままです。
プライベート トレーニング リクエストを送信してください 。Databricks は、通常、5 営業日以内にスケジュール リクエストに対応します。リクエストされた日付をサポートできる場合、Databricks はメールで確認し、リクエストされたトレーニングの実施日を一時的に「ロック」します。インストラクターの利用可能性を確認したら、最終確認で速やかにフォローアップします (「コミット セッション」)。それ以外の場合は、お客様と協力して、コミット セッションの代替日について合意します。なんらかの理由でインストラクターがコミット セッションに参加できなくなった場合、当社は速やかに電子メールで顧客に通知し、支払った関連料金、またはオーダー フォームで指定された有効期限内に予定されている他の将来のプライベート クラス セッションで使用するために引き換えたサクセス クレジットを返金します。
インストラクター主導のプライベートクラスのキャンセルと返金のポリシーは以下です。
予定された開始日の 14 日以上前にキャンセルされた場合: お客様は、再スケジュールされたクラスが注文フォームに示されている有効期限内にある限り、違約金なしで (1 回) スケジュールを変更することができます。そのようなクラスのそれ以上の再スケジュールには、30 日前の通知が必要であり、有効期限内の日付で行われるようにスケジュールする必要があります。
開始予定日の 14 日以内にキャンセルされた場合: お客様は、支払った料金を放棄し、サクセス クレジットを引き換えます。ただし、お客様が有効期限内にキャンセルしたプライベート クラスの配信を再スケジュールする場合、お客様は、再スケジュールされたクラスに対して支払った料金または引き換えた成功クレジットの 50% を適用することができます。
インストラクター主導の公開クラスのキャンセルと返金のポリシーはこちらです。
Databricks は、クラスの開始日の 14 日前に公開クラスを実行またはキャンセルすることを確認します。クラスの 14 日前まで、学習者は登録をキャンセルして全額返金するか、別の日にスケジュールを変更する権利を留保します。クラス開始まで14日未満の場合、キャンセルは認められませんが、代わりに代理を送ることができます。こちらからリクエストを送信してください 。 すべてのリクエストは、ケースバイケースで審査されます。
参加者がクラスをキャンセルまたは欠席しない場合の返金または振替はありません。学習管理システムでは、セッションから登録を解除しても、コースに登録されたままになります。返金を受けるには、コースへの登録も解除する必要があります。
Databricks は、公開クラスをいつでもキャンセルまたは変更する権利を留保します。これには、参加者の不足、教室またはインストラクターの空き状況が含まれますが、これらに限定されません。クラスがキャンセルされた場合、学習者はメールで通知されます。学習者は、返金またはクラスの振替のいずれかを選択できます。通知から 2 営業日以内に応答がない場合、学習者は自動的に次のクラスに転送されます。
cloudFiles.allowOverwritesが有効になっていない限り、ファイルは一度だけ処理されます。ファイルが追加または上書きされた場合、Databricks は、ファイルのどのバージョンが処理されるかを保証しません。Databricks では、Auto Loader を使用して不変ファイルのみを取り込むことをお勧めします。これが要件を満たしていない場合は、Databricks の担当者にお問い合わせください。
この場合は 構造化ストリーミング ジョブにTrigger.AvailableNow(Databricks Runtime 10.2 以降で使用できる)を設定し、予想されるファイルの到着時間の後に実行するようにスケジュールできます。Auto Loader は、更新頻度が低い場合でも頻繁な場合でもうまく機能します。最終的な更新が非常に大きい場合でも、Auto Loader は入力サイズに合わせて適切にスケーリングします。Auto Loader の効率的なファイル検出技術とスキーマ進化機能により、Auto Loader は増分データの取り込みに推奨される方法になっています。
DataFrame が最初に定義されると、Auto Loader はソース ディレクトリを一覧表示し、最新の (ファイル変更時間による) 50 GB のデータまたは 1000 ファイルを選択し、それらを使用してデータ スキーマを推測します。

Auto Loader は、ソース ディレクトリ構造を調べてパーティション列を推測し、その/key=value/構造を含むファイル パスを探します。ソース ディレクトリの構造に一貫性がない場合、Auto Loader は、パーティション列が空であると推測します。cloudFiles.partitionColumnsディレクトリ構造から列を明示的に解析するために使用します。
スキーマは、DataFrame がコードで最初に定義されたときに推測されます。各マイクロバッチ中に、スキーマの変更がオンザフライで評価されます。したがって、パフォーマンス ヒットについて心配する必要はありません。ストリームが再開すると、スキーマの場所から展開されたスキーマが取得され、推論によるオーバーヘッドなしで実行が開始されます。
非常に大きなソース ディレクトリの場合、最初のスキーマ推定時にスキーマ推定に数分かかることが予想されます。それ以外の場合は、ストリームの実行中に重大なパフォーマンス ヒットが発生することはありません。Databricks ノートブックでコードを実行すると、Auto Loader がデータ スキーマのサンプリングと推測のためにディレクトリを一覧表示するタイミングを指定するステータスの更新を確認できます。
Databricks は、リポジトリのサイズに制限を適用しません。しかし：

作業ブランチは 200 MB に制限されています。

個々のファイルは 200 MB に制限されています。

10 MB を超えるファイルは、Databricks UI で表示できません。

Databricks は、レポで次のことをお勧めします。

すべてのファイルの合計数が 10,000 を超えないこと。

ノートブックの総数は 5,000 を超えません。

リポジトリがこれらの制限を超えると、エラー メッセージが表示される場合があります。リポジトリのクローンを作成するときにタイムアウト エラーが発生することもありますが、操作はバックグラウンドで完了する可能性があります。
リポジトリのコンテンツは、コントロール プレーンのディスクに一時的に複製されます。Databricks ノートブック ファイルは、メイン ワークスペースのノートブックと同様に、コントロール プレーン データベースに格納されます。ノートブック以外のファイルは、最大 30 日間ディスクに保存できます。
サーバーがインターネットにアクセスできる場合、Databricks Repos は Bitbucket Server との統合をサポートします。

Bitbucket Server、GitHub Enterprise Server、またはインターネットにアクセスできない GitLab セルフマネージド サブスクリプション インスタンスと統合するには、Databricks の担当者にお問い合わせください。
はい。リポジトリにファイルを追加し、それを Git で追跡したくない場合は、.gitignoreファイルを作成するか、リモート リポジトリから複製したファイルを使用して、拡張子を含むファイル名を追加します。

.gitignoreはGit によってまだ追跡されていないファイルに対してのみ機能します。Git によって既に追跡されているファイルを.gitignoreファイルに追加しても、そのファイルは引き続き Git によって追跡されます。
ワークスペースで Repos for Git を無効にするには、次の手順に従います。

管理設定ページに移動します。

[ワークスペース設定]タブをクリックします。

[詳細]セクションで、[リポジトリ]トグルをクリックします。

[確認]をクリックします。

ブラウザを更新します。
はい。Jupyter ノートブック (.ipynb ファイル) のサポートは Repos で利用できます。.ipynb ノートブックを使用してリポジトリを複製し、Databricks UI で作業してから、.ipynb ノートブックとしてコミットおよびプッシュできます。ノートブック ダッシュボードなどのメタデータは保持されます。管理者は、出力をコミットできるかどうかを制御できます。以下もできます。
新しい .ipynb ノートブックを作成します。

ノートブックを .ipynb ファイル形式に変換します。

コード差分(セル内のコードの変更) または生の差分(JSON 内のコード変更、メタデータとしてのノートブック出力を含む)として差分を表示します。
はい、ノートブック、フォルダー、またはリポジトリ全体をエクスポートできます。ノートブック以外のファイルをエクスポートすることはできません。リポジトリ全体をエクスポートすると、ノートブック以外のファイルは含まれません。エクスポートするには、Workspace CLIまたはWorkspace API 2.0を使用します。
認証トークンは Databricks コントロール プレーンに格納され、Databricks の従業員は、監査された一時的な資格情報を介してのみアクセスできます。

Databricks は、これらのトークンの作成と削除をログに記録しますが、使用状況はログに記録しません。Databricks には、Databricks アプリケーションによるトークンの使用状況を監査するために使用できる Git 操作を追跡するログがあります。

GitHub エンタープライズは、トークンの使用状況を監査します。他の Git サービスにも Git サーバー監査がある場合があります。
はい、ノートブックのソース コードを変更する Git 操作により、セル出力、コメント、リビジョン履歴、ウィジェットなどのノートブックの状態が失われます。たとえば、Git プルはノートブックのソース コードを変更できます。この場合、Databricks Repos は既存のノートブックを上書きして変更をインポートする必要があります。Git のコミットとプッシュ、または新しいブランチの作成は、ノートブックのソース コードには影響しないため、これらの操作ではノートブックの状態が保持されます。
No. ワークスペースでのみ MLflow 実験を作成できます。3.72 プラットフォーム リリースより前にリポジトリで作成された実験は サポートされなくなりましたが、保証なしで引き続き動作する可能性があります。Databricks では、 MLflow エクスポート ツールを使用して、リポジトリ内の既存の実験をワークスペースの実験にエクスポートすることをお勧めします。
Git 操作の進行中の任意の時点で、リポジトリ内の一部のノートブックが更新され、他のノートブックは更新されていない可能性があります。これにより、予期しない動作が発生する可能性があります。

たとえば、ノートブック A が%runコマンドを使用してノートブック Z を呼び出すとします。Git 操作中に実行されているジョブがノートブック A の最新バージョンを開始するが、ノートブック Z がまだ更新されていない場合、ノートブック A のコマンドはノートブック%runZ の古いバージョンを開始する可能性があります。予測可能であり、ジョブが失敗するか、異なるコミットからノートブック A とノートブック Z を実行する可能性があります。
次のいずれかを使用できます。

クラスタにライブラリとしてバンドルしてデプロイします。

Git リポジトリを直接 pip インストールします。これには、 secrets managerの資格情報が必要です。

%runノートブックのインライン コードで使用します。

カスタム コンテナー イメージを使用します。Databricks Container Services を使用してコンテナーをカスタマイズする を参照してください。
AQE は初期パーティション数を変更しません。シャッフル パーティション数に適度に高い値を設定し、クエリの各段階での出力データ サイズに基づいて、AQE が小さなパーティションを結合できるようにすることをお勧めします。

ジョブにスピルが見られる場合は、次のことを試すことができます。

シャッフル パーティション数を増やす:spark.sql.shuffle.partitions

spark.databricks.adaptive.autoOptimizeShuffle.enabledをtrueに設定して自動最適化シャッフルを有効にする。
ブロードキャストされると予想されるリレーションのサイズがこのしきい値を下回っているにもかかわらず、ブロードキャストされない場合:

結合タイプを確認してください。ブロードキャストは、特定の結合タイプではサポートされていません。たとえば、 LEFT OUTER JOINはブロードキャストできません。

リレーションに多くの空のパーティションが含まれている可能性もあります。この場合、タスクの大部分はsort merge joinで迅速に終了するか、skew join handlingで最適化できる可能性があります。AQE は、空でないパーティションのパーセンテージがspark.sql.adaptive.nonEmptyPartitionRatioForBroadcastJoin よりも低い場合、そのようなsort merge joinsをbroadcast hash joinsに変更することを回避します。
はい。通常、静的に計画されたブロードキャスト結合(broadcast join)は、AQE によって動的に計画されたブロードキャスト結合よりもパフォーマンスが高くなります。AQE は、結合の両側でシャッフルを実行するまでブロードキャスト結合に切り替わらない可能性があるためです (それまでに、実際のリレーション サイズが取得されます)。そのため、クエリをよく知っている場合は、ブロードキャスト ヒントを使用することをお勧めします。AQE は、静的最適化と同じ方法でクエリ ヒントを尊重しますが、ヒントの影響を受けない動的最適化を適用することもできます。
AQE がパーティションをスキュー パーティションとして検出するには、次の 2 つのサイズ条件を満たさなければなりません。

パーティション サイズがspark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes (デフォルトの 256MB)より大きい

パーティション サイズが、すべてのパーティションの中央サイズにspark.sql.adaptive.skewJoin.skewedPartitionFactor(既定値は 5)を掛けた値よりも大きい

さらに、スキュー処理のサポートは、特定の結合タイプに対して制限されています。たとえば、 LEFT OUTER JOINでは、左側のスキューのみを最適化できます。
エラーのデバッグに役立つように、Azure Synapse コネクタに固有のコードによってスローされた例外は、SqlDWException特性を拡張する例外にラップされます。例外は、次の区別もあります。
SqlDWConnectorExceptionはAzure Synapse コネクタによってスローされたエラーです。
SqlDWSideExceptionは接続された Azure Synapse インスタンスによってスローされたエラーです。
これは、「.option("dbTable", tableName) 」がデータベース(つまり、Azure Synapse) テーブルを指し、「.saveAsTable(tableName)」がSpark テーブルを指すという区別を明確にしたいためです。実際には、この 2 つを組み合わせることもできます「df.write. ... .option("dbTable", tableNameDW).saveAsTable(tableNameSpark)」。これにより、呼び出された Azure Synapse 内に「tableNameDW」テーブルが作成され、 Azure Synapse テーブルによってサポートされる呼び出された Spark 内に「tableNameSpark」外部テーブルが作成されます。
Databricks クラスターと同様に、クラシック SQL エンドポイントはAWS アカウントで作成および管理されます。クラシック SQL エンドポイントは、アカウント内の SQL 最適化クラスターを自動的に管理し、エンドユーザーの需要に合わせてスケーリングします。

一方、サーバーレス SQL エンドポイント(パブリック プレビュー) は、Databricks クラウド アカウントのコンピューティング リソースを使用します。サーバーレス SQL ウェアハウスは、SQL エンドポイントの構成と使用を簡素化し、起動時間を短縮します。サーバーレス オプションは、ワークスペースで有効になっている場合にのみ使用できます。詳細については、「サーバーレス コンピューティング」を参照してください。
Databricks は、予測可能な方法で CI/CD パイプラインを管理するために、Databricks Terraform プロバイダーを引き続き推奨しています。今後、IDE を使用して展開を管理する方法について、Databricks の担当者にお知らせください。Databricks は、お客様の意見を将来の計画に組み込みます。
Databricks Labs による dbxの主な機能は次のとおりです。
プロジェクトのscaffolding。
dbx executeコマンドによる限定的なローカル開発。
Databricks ジョブの CI/CD。

Visual Studio Code の Databricks 拡張機能を使用すると、Databricks クラスターでローカル開発とリモートで Python コード ファイルを実行し、Databricks ジョブで Python コード ファイルとノートブックをリモートで実行できます。dbxプロジェクトのscaffoldingと Databricks ジョブの CI/CD に引き続き使用できます。
Visual Studio Code の Databricks 拡張機能を構成するときに、既存の構成プロファイルを選択できます。拡張機能とコード プロジェクトを開いた状態で、次の操作を行います。

[構成]ペインで、歯車 ( [ワークスペースの構成] ) アイコンをクリックします。
たとえば、ワークスペース インスタンスの URLを入力しますhttps://dbc-a1b2345c-d6e7.cloud.databricks.com。

コマンド パレットで、既存の構成プロファイルを選択します。
Snowflake はすべてのINTEGER型はNUMBER として表します。これにより、Snowflake にデータを書き込んだり、Snowflake からデータを読み取ったりするときに、データ型が変更される可能性があります。たとえば、 Snowflake ではDECIMALとINTEGER が意味的に同等であるため、Snowflake への書き込み時にINTEGERデータをDECIMAL に変換する場合があります( Snowflake Numeric Data Typesを参照)。
ソリューションアクセラレータを使用することで、発見、設計、開発、テストにかかる時間を短縮できます。Notebook や実証済みのパターン、ベストプラクティスといったリソースを活用し、データと AI のユースケースをすぐに展開できるように設計されています。発案から PoC までを最短 2 週間で完了できます。
Databricks ソリューションアクセラレータは、さまざまな業界・業種に共通の主要なユースケースに対応する、フル機能の Notebook やベストプラクティスを含む目的に特化したガイドです。ソリューションアクセラレータを使用することで、発見、設計、開発、テストにかかる時間を短縮できます。発案から PoC までを 2 週間以内に完了できるよう設計されています。
 

ソリューションアクセラレータは、Databricks の無料トライアルへのご登録、または既存のアカウントで使用できます。
14日間無料トライアル に含まれるもの：

ソリューションの共同構築を可能にするプラットフォーム
Apache SparkTM、SQL、Python、Scala、Delta Lake、MLflow、TensorFlow、Keras、Scikit-learn など、多言語のサポートを備えた対話型 Notebook
※ 無料トライアル期間中にアカウント内で使用されたリソース （コンピュートインスタンスなど） については、クラウドプロバイダの料金が適用されます。
Databricks ユニット（DBU）とは、Databricks レイクハウスプラットフォームの処理能力を規格化した単位であり、測定と課金の目的で使用されます。ワークロードが消費する DBU の数は、使用するコンピューティングリソースや処理するデータの量などの処理指標によって決まります。
Databricks の製品は、お客様のワークロードの TCO（Total Cost of Ownership）を考慮した価格設定になっています。Databricks によるコスト削減を見積もる際には、 ジョブの完了率、期間、ジョブをサポートするために必要な手作業やリソースなど、代替ソリューションの主要な側面を考慮することが重要です。正確な節約額を見積もるには、PoC の展開の一環として、結果を並べて比較することをお勧めします。 Databricks の導入による高速化の達成事例と お客様によるベンチマーク結果もご参照ください。詳しくはお問い合わせください。
Jobs Light クラスタは、Databricks のオープンソース Apache Spark に相当します。Jobs Light クラスタは、Databricks のテクノロジーによる高性能、高信頼性、自動スケーリングを必要としないケース、すなわち、シンプルで重要性の低いワークロードを対象としています。一方、Jobs クラスタでは、Databricks のメリットが全て提供され、生産性向上、総所有コストの削減を実現します。
Jobs Compute のワークロードは、Jobs クラスタで実行するワークロードです。Jobs クラスタは、同一のジョブによって開始・終了します。分離を目的として、1 つの Jobs クラスタでは 1 つのジョブのみを実行します。All-Purpose Compute のワークロードは、All-Purpose クラスタで実行されます。All-Purpose クラスタは、Jobs クラスタに分類されないクラスタです。Databricks Notebook 内でのコマンドの実行、BI ワークロードのための JDBC/ODBC を介した接続、Databricks での MLflow の実験など、さまざまな用途に使用できます。複数のユーザーで All-Purpose クラスタを共有し、インタラクティブな分析を行うことができます。
パイプラインに選択された DLT Product Edition に含まれていない機能を含むパイプラインを実行しようとすると、エラーの理由を含むエラーメッセージが表示されます。その後、パイプラインの Product Edition を変更して、必要な機能を含むエディションを選択し、パイプラインの再実行を試みることができます。
SQL Classic および Pro の場合、Databricks はお客様のクラウドプロバイダ環境にクラスタリソースをデプロイし、お客様は対応するコンピューティングインフラ料金を支払う責任を負います。サーバーレスコンピュートの場合、Databricks は Databricks のクラウドプロバイダのアカウントにクラスタリソースをデプロイするためお客様はコンピュートインフラ料金を別途お支払いいただく必要はございません。詳しくはこちらをご覧ください。
ソースデータが Databricks サーバーレス環境と異なるクラウド領域にある場合、クラウド事業者からネットワークエグレスチャージを請求される場合があります。Databricks は現在、サーバーレス環境からお客様の目的地までの移動にかかる費用を無料としていますが、将来的には市場競争力のある料金でその移動にかかる費用を請求する可能性があります。
モデル実行時間とは、モデルサービングで機械学習モデルを実行するのに必要な時間のことです。実行時間を見積もるには、エンドポイントページのレイテンシチャートを確認するか、負荷テストを実施できます。負荷テストに関するガイダンスについては、Databricks チームまでお気軽にお問い合わせください。
Databricks ML は、オープンなレイクハウスアーキテクチャを基盤として構築されており、Delta Lake が組み込まれています。機械学習チームによる、あらゆる規模、種類のデータのアクセス、探索、準備を可能にします。データエンジニアリングのサポートなしで、特徴量をセルフサービスで本稼働パイプラインに組み込めます。
マネージド MLflow により、実験を自動的に追跡し、トレーニング実行ごとのパラメータ、メトリクス、データとコードのバージョン、モデルの成果物を記録できます。実行履歴をすぐに確認でき、結果を比較したり、必要に応じて過去の結果を再現したりすることも可能です。本番環境に最適なモデルのバージョンを特定した後は、モデルレジストリに登録し、展開ライフサイクル全体のハンドオフを簡素化できます。
トレーニングされたモデルを登録すると、モデルレジストリを使用してモデルのライフサイクルを共同管理できます。モデルのバージョン管理や移動は、実験、ステージング、本番環境、アーカイブなどさまざまな段階で可能です。ライフサイクル管理は、ロールベースのアクセス制御に従って、承認やガバナンスのワークフローと統合されています。また、コメントやメールの通知機能により、データチームのコラボレーション環境が充実します。
ML フレームワークが急激な進化を遂げており、ユーザーは平均 8 つのライブラリを管理する必要があります。ML ランタイムは、特に一般的な ML フレームワークの高性能かつ信頼性のある分散処理、および事前構築されたコンテナを介したカスタム ML 環境へのワンクリックアクセスを提供します。
本番モデルは、Apache Spark™ でバッチ推論を実行するために、または Docker コンテナ、Azure ML、Amazon SageMaker に統合されている組み込み機能を使用する REST API として、迅速にデプロイできます。Databricks 上のマネージド型の MLflow では、Databricks Jobs Scheduler や自動管理クラスターを利用して本番モデルを運用および監視し、ビジネスニーズに応じてスケーリングすることができます。
一元的な場所を使用して、機械学習モデルの検出と共有、実験からオンラインでのテストと実稼働への移行に関する共同作業、承認とガバナンスのワークフローと CI/CD パイプラインとの統合、機械学習のデプロイとそのパフォーマンスを監視します。MLflowモデルレジストリを使用することで、専門知識と知識の共有を容易にし、管理を維持できます。
本番環境で使用可能な ML モデルを開発するための標準化されたフレームワークにより、機械学習のライフサイクル管理を加速および簡素化します。管理された MLflow Recipes を使用すると、ML プロジェクトのブートストラップ、迅速なイテレーションを容易に実行し、高品質のモデルを大規模に本番環境に出荷することができます。
'MLflow Recipes'を使うメリットは以下３点あります。プロジェクトの開始を簡素化：MLflow Recipes は、ML モデルの構築とデプロイメントのために、すぐに使用できる接続コンポーネントを提供します。

モデル反復の迅速化：MLflow Recipes は、モデル反復のための標準化された再利用可能な手順を作成し、プロセスの迅速化とコスト削減を実現します。

チームのハンドオフを自動化：独自の構造により、モジュール化された本番環境に対応したコードが提供され、実験から本番環境への自動ハンドオフが可能になります。