この記事では、既存のデータ アプリケーションを Azure Databricks に移行する方法の概要を示します。 Azure Databricks では、単一のプラットフォーム上の多くのソース システムからのデータを操作できる統一アプローチが提供されます。
プラットフォーム機能の概要については、「Azure Databricks とは」を参照してください。
ETL ジョブを Azure Databricks に移行する
オンプレミスまたはクラウドネイティブの実装からデータを抽出、変換、読み込むのに使用される Apache Spark ジョブを、わずかな手順で Azure Databricks に移行できます。 「Azure Databricks 用に既存の Apache Spark コードを調整する」を参照してください。
Azure Databricks では、事前に構成されたオープンソース統合、パートナー統合、エンタープライズ製品オファリングを使用して Spark SQL の機能を拡張します。 ETL ワークロードが SQL または Hive で記述されている場合は、最小限のリファクタリングで Azure Databricks に移行できます。 Azure Databricks SQL オファリングの詳細については、以下を参照してください。
さまざまなソース システムから Azure Databricks への移行に関する具体的な手順については、「ETL パイプラインを Azure Databricks に移行する」を参照してください。
エンタープライズ データ ウェアハウスをレイクハウスに置き換える
Azure Databricks では、ワークロードがレイクハウスに格納されているデータに合わせて調整されるときに、最適な値とパフォーマンスが提供されます。 多くのエンタープライズ データ スタックには、データ レイクとエンタープライズ データ ウェアハウスの両方が含まれており、組織は複雑な ETL ワークフローを作成して、これらのシステムとデータの同期を維持しようとします。Lakehouse を使用すると、通常は個別のデータ ウェアハウスに依存するクエリとシステム全体で、データ レイクに格納されているのと同じデータを使用できます。 レイクハウスについて詳しくは、「データ レイクハウスとは」を参照してください。 Databricks でのデータ ウェアハウスの詳細については、「 データ ウェアハウス アーキテクチャ」を参照してください。
エンタープライズ データ ウェアハウスからレイクハウスへの移行では、通常、データ アーキテクチャとワークフローの複雑さを軽減する必要がありますが、この作業を完了するときに留意すべき注意事項とベスト プラクティスがいくつかあります。 データウェアハウスを Databricks レイクハウスに移行するを見てください。
ML、データ サイエンス、分析のワークロードを統合する
Lakehouse では、テーブル クエリまたはファイル パスを使用してクラウドベースのデータ ファイルへのアクセスを最適化できるため、データの 1 つのコピーに対して ML、データ サイエンス、分析を実行できます。 Azure Databricks を使用すると、ワークロードをオープン ソースと独自のツールの両方から簡単に移動でき、アナリストやデータ サイエンティストが使用する多くのオープンソース ライブラリの更新バージョンが維持されます。
Jupyter ノートブックの Pandas ワークロードは、Databricks Git フォルダーを使用して同期および実行できます。 Azure Databricks では、すべての Databricks Runtime バージョンで Pandas のネイティブ サポートが提供され、Machine Learning 用の Databricks Runtime で多くの一般的な ML およびディープ ラーニング ライブラリが構成されます。 Gitでローカルのワークロードを同期し、Gitフォルダーにあるのワークスペースファイルを使用する場合、ローカル環境に存在するデータやカスタムライブラリに同じ相対パスを利用できます。
メモ
既定では、Azure Databricks により Databricks Git フォルダーと同期された Jupyter ノートブックの .ipynb 拡張子が維持されますが、UI を使用してインポートした場合は、Jupyter ノートブックが Databricks ノートブックに自動的に変換されます。 Databricks ノートブックは .py 拡張子付きで保存されるため、Git リポジトリに Jupyter ノートブックと並行して存在できます。