DatabricksへのZeppelinノートブックの大規模移行に対応する生成AIツールをDeutsche Börseが構築した方法

Deutsche Börse Groupでは、StatistiXプラットフォームがグループ全体のクリアリングおよびトレーディングデータの約95%を提供し、数百のビジネスユーザーのセルフサービス分析を可能にしています。そのデータにアクセス可能で実用的な状態に保つことが、私たちのすべての活動の中心です。

長年、それはHDFSおよびOracleデータシステムにアクセスできるClouderaで実行されるZeppelinノートブックを意味していました。プラットフォームは私たちに役立ちましたが、状況は変化しました。Clouderaは2027年にZeppelinのサポートを完全に終了し、分析ワークロードはクラウドに移行し、Databricksが新しい統合分析プラットフォームとして選ばれました。この組み合わせにより、ほとんどの組織が見くびっている移行の課題が生じました。2,000人以上のユーザーと大量のノートブック（多くは日常のビジネスワークフローに深く組み込まれています）すべてを移行する必要がありました。

すべてを手動で書き直すには何年もかかります。そこで、Databricks上でより良いパスを構築することにしました。

ノートブック移行の問題

インフラストラクチャの移行は多くの注目を集めます。ノートブックの移行はそうではありませんが、それがチームの進捗を遅らせる大きな理由の1つです。

私たちのZeppelinノートブックは単純なスクリプトではありませんでした。それらは、カスタムインタープリタ、OracleおよびHDFS参照、視覚化、ウィジェット、そして長年にわたって構築されたスケジューリングロジックを含む、複雑なSQLおよびPythonロジックを含んでいました。それぞれが、それに依存していたビジネスチームからの組織的な知識を反映していました。ノートブック全体にわたる多様性により、ロジックが異種混在しすぎて自動ルールでは信頼性を持って処理できないため、ルールベースの書き換えエンジンは実用的ではありませんでした。

その制約により、よりクリーンな設計の洞察が得られました。構造とロジックを分離し、それぞれに適切なツールを適用します。構造変換（Zeppelinの段落形式をDatabricksセルにマッピングし、インタープリタ構文を翻訳し、メタデータを再フォーマットする）は決定的であり自動化可能ですが、ロジックの再構築はそうではありません。幸いなことに、LLMはこの構造変換の部分に優れています。

Databricks Appsでのコンバーターの構築

その設計原則を念頭に置いて、私たちはZeppelinからDatabricksノートブックコンバーターを構築しました。これは、私たちの移行ワークフロー専用に設計されたDatabricks Appです。

このアプリは変換の構造的な側面を処理します。Zeppelinの段落はDatabricksセルになり、インタープリタのマッピングが適用され（%python、%sql、%pysparkなどがDatabricksの同等物に翻訳され）、ノートブックメタデータは有効な.ipynb JSONに再フォーマットされます。元のコンテンツはそのまま保持されます。この段階ではロジックを書き換えているのではなく、次のステップの準備をしているだけです。

次のステップはGenieです。アップロードされた各ノートブックに対して、アプリはカスタムインタープリタ、データソース、設定パターンなど、Zeppelin環境に関する特定の詳細を含む、コンテキスト認識型のプロンプトを自動的に生成します。このプロンプトは、GenieがDatabricksネイティブの方法でロジックを正確に再構築するために必要なコンテキストを提供します。

ビジネスユーザーのワークフローは簡単です。

1. ZeppelinノートブックをJSONとしてエクスポートします
2. Databricks Appにアップロードします
3. 変換をクリックします
4. 変換された.ipynbをダウンロードします
5. Databricksを開き、ノートブックをアップロードし、Genieを起動して生成されたプロンプトを貼り付けます
6. Genieが明確化の質問をし、ノートブックを再構築します

アプリ自体はshadcn UIフロントエンドで構築されました。当初はStreamlitプロトタイプを構築しましたが、shadcnの方がよりプロフェッショナルでスケーラブルなインターフェースを提供してくれると感じました。Databricks Appsの開発体験により、個別のインフラストラクチャをセットアップせずに迅速に出荷することが容易になりました。

自動化しないことを選択したこと

最も重要な設計上の決定の1つは、ツールが意図的にそのままにしておくべきものを決定することでした。

コンバーターは、SQLロジック、Pythonロジック、視覚化、ウィジェット、OracleおよびHDFS参照、スケジューリングロジック、またはビジネス固有のカスタムコードを書き換えません。それらのすべてのコンテンツは、変換されたノートブックにそのまま残されます。なぜなら、それらを自動的に書き換えるとエラーが発生し、出力への信頼が損なわれるからです。これらはまさにノートブック間で最も変化し、ビジネスにとって最も重要なロジックを担う要素です。それらは、コンテキストを解釈し、明確化の質問をし、ルールではできない判断を下すことができるGenieに属します。

決定論的な部分を自動化し、可変的な部分を委任するこのハイブリッドアプローチにより、ルールベースシステムの脆弱性を回避し、AIが実際にパフォーマンスを発揮する場所で活用することができます。

結果：数時間から数分へ

構造変換とAI支援のロジック再構築を組み合わせることで、ノートブックの再開発にかかる手動作業時間を、複雑さによってはノートブックあたり15〜20分に短縮しました。このような大規模な移行で、複数のビジネスドメインにまたがる場合、このアプローチは、リソース集約的で時間のかかる作業を、はるかに少ない時間で完了できるスケーラブルで反復可能なワークフローに変えます。

速度の向上は、作業の性質も変えます。ビジネスユーザーは、自分のノートブックを移行するために深いDatabricksの専門知識を必要としません。彼らは短い手順に従い、プロンプトを取得し、Genieに再構築を任せます。このツールは十分にアクセスしやすいため、移行には専用のエンジニアリングチームは必要ありません。

学んだこと

このプロジェクトから、同様の取り組みに持ち込めるいくつかの原則が生まれました。

• 過剰なエンジニアリングを避ける。最初の試みでは、より複雑なエージェンティックアーキテクチャを使用しましたが、コアの問題を解決せずにオーバーヘッドを追加しました。シンプルなUIとクリーンなバックエンドがまさに十分であることが判明しました。
• 異種混在コンテンツにはルールベースの書き換えはスケーリングしない。ノートブック全体にわたるロジックの多様性により、ルールは非現実的でした。LLMは、その変動性に対処するために不可欠であり、鍵は自動化とAI間のハンドオフを慎重に設計することです。
• コンテキストは、良いプロンプトと素晴らしいプロンプトの違いです。一般的なGenieプロンプトは、一般的な結果を生み出します。私たちの特定の環境（インタープリタ、データソース、設定パターン）の知識をエンコードしたプロンプトに投資することが、実際に出力を利用可能にしたものです。
• プラットフォームチームを早期に巻き込む。構築プロセス全体を通じてDatabricksチームと協力したことで、連携を維持し、手戻りを回避することができました。

次は何をするか

コンバーターツールの初期開発は完了しましたが、現在、大規模な実世界テストを進めています。当面の優先事項は、精度を向上させるためのプロンプト定義の最終決定、複数のビジネスエンティティおよびITにわたるノートブックでのツールの検証、ユーザーオンボーディングの準備です。

より広範な意味合いが、私たちを最も興奮させていることです。このプロジェクトは、AI支援移行は将来の機能ではなく、今利用可能であることを実証しました！Databricks Appsと生成AIを組み合わせることで、クラウドトランスフォーメーションの最も困難な問題の1つを、高速でスケーラブルなプロセスに変える反復可能なワークフローを構築しました。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事