最高のデータウェアハウスはオープンなレイクハウスです
によって Serge Rielau, Kent Marten, デビッド・ミリセビッチ, Milan Dankovic, Dušan Tišma 、 Dejan Krakovic による投稿
Archived. This article has not been updated since the publish date above. The dynamic nature of information means that previously accurate content can become outdated or even obsolete over time. Readers are advised to exercise due diligence and cross-check any information found in this blog post before making decisions or adopting any practices based on said information.
SQLの定型的なタスク、例えばデータクリーニング、ビジネスルールの更新、バッチ処理などは、コードをコピー＆ペーストしていると、手間がかかり、間違いも起こりやすくなります。
Databricks の SQL ストアド プロシージャ（一般提供開始）を使えば、そのロジックを一度保存し、必要な時にいつでも実行でき、Unity Catalog で管理できます。
分析前のデータクリーニング、ビジネス基準に基づいたテーブルの更新、レガシーなエンタープライズ データウェアハウスからのワークロード移行など、どのような場合でも、ストアド プロシージャはプロセスをよりシンプルに、一貫性があり、保守しやすくします。
Databricks は、プロプライエタリまたはベンダー固有の実装を避け、オープンスタンダードと相互運用性をサポートしています。SQL ストアド プロシージャは ANSI/PSM SQL 標準に準拠しており、オープンソースの Apache Spark™ に貢献される予定です。
プロシージャは、管理タスク、データ管理、ETL ワークフローで広く使用されており、特にエンタープライズ データウェアハウス（EDW）で利用されています。EDW から Databricks に移行するお客様は、既存のストアド プロシージャを書き直すことなく移行できるため、移行が容易になります。そして、いつものように、最高のデータウェアハウ スはレイクハウスです。
顧客セグメンテーションに関する重要なユースケースの 1 つで、DBSQL とともに SQL ストアド プロシージャを活用し、パフォーマンス、スケーラビリティ、コスト効率を向上させました。SQL に慣れていたため、非常に短時間でソリューションを実装し、本番環境にデプロイすることができました。ストアド プロシージャを使用することで、複雑なロジックをより効果的に管理しながら、全体的なアーキテクチャを合理化し、保守可能にすることができました。—SambaSiva Rao, Sr. Data Engineer/Architect, ClicTechnologies
SQL ストアド プロシージャが一般提供開始されました。
データ処理ワークフロー全体で、お客様は定型的なタスクや複雑なロジックの一貫性とパフォーマンスの維持に苦労することがあります。このような場合、ストアド プロシージャは、データが一貫した標準化された方法で処理され、パフォーマンスが最適化されることを保証する優れたアプローチです。
データクリーニングタスクの場合、プロシージャは、不整合な日付フォーマットを標準化された構造に変換する、テキストフィールドの先頭および末尾の空白をトリミングする、エラーのある値を置き換えるまたは修正するといった変換を適用できます。これにより、データが下流の分析のために準備され ます。詳細な ETL の例を以下に示します。
データ管理の側面では、ストアド プロシージャは、無効なレコードにフラグを付ける、フィールドを再計算する、関連テーブル間でデータを同期するといった定義済みのビジネスルールに基づいて、テーブル値を効率的に更新できます。これらの操作をプロシージャにカプセル化することで、チームは一貫した実行を保証し、手動介入を減らし、大規模なデータ品質を向上させることができます。以下に、ロイヤルティ/メンバーシッププログラムを更新するためにストアド プロシージャを使用した詳細なデータ管理の例を示します。
では、プロシージャとは何でしょうか？プロシージャは、SQL ステートメントの事前コンパイルされたコレクションであり、ユーザーが SQL ロジックを単一の再利用可能なユニットにまとめることができます。プロシージャは Unity Catalog に格納されるため、管理され、権限が完全にカプセル化されます。ストアド プロシージャが呼び出されると、データベースはこれらの事前定義された操作を実行し、セキュリティの強化、複雑なワークロードの保守の簡素化、パフォーマンスの向上の可能性といったメリットを提供します。
プロシージャをサポートする 5 つのコア コマンドは、CREATE、CALL、DESCRIBE、SHOW、DROP です。
プロシージャを作成する際には、入力と出力を制御するためにいくつかのパラメータタイプを使用できます。
これらのパラメータは、以下に割り当てることができます。
SQL ストアド プロシージャ内にカプセル化されたロジックは、SQL スクリプティングの上に構築されています。ストアド プロシージャは、パラメータを持つ再利用可能なスクリプトと見なすことができ、Unity Catalog によって管理されます。スクリプティングについては、これらの 2 つの入門ブログで詳しく説明しています。
ネストされたプロシージャ呼び出しと再帰的なプロシージャ呼び出しがサポートされています。これは、お客様が作業単位またはビジネスロジックを個別のプロシージャに便利に整理できることを意味し、SQL 実行フロー全体をよりモジュール化できます。これにより、可読性と保守性が向上します。
プロシージャは、UI では Unity Catalog の 関数とともにグループ化されています。しかし、プロシージャと関数は、SQL ロジックを再利用できるという点で似ていますが、目的が異なります。
関数は、値またはテーブルを返すために使用されます。SQL クエリ内で使用する必要があり、動的 SQL や手続き型ロジックを含めることはできません。対照的に、プロシージャは、一連の SQL ステートメントを実行するために使用されます。制御フロー、変数、ループ、および IDENTIFIER と EXECUTE IMMEDIATE を使用した動的 SQL を含めることができます。プロシージャは、通常、タスクまたはワークフローを実行するために、スタンドアロン コマンドとして呼び出されます。
SQL ストアド プロシージャの機能について説明したので、次にその価値と解決に役立つ問題を示す例を見てみましょう。
この ノートブックを使用して、この投稿のすべての例とデータ準備コマンドが含まれているため、フォローアップできます。
典型的な メダリオンアーキテクチャに従っている場合、ブロンズからシルバー（またはシルバーからゴールド）へのデータの移動には、データのクリーニング、変換、集計、フォーマットが必要になることをご存知でしょう。ストアドプロシージャは、ETLワークフロー内でこれらの繰り返しプロセスを管理するのに役立ちます。
このETLシナリオでは、プロシージャを使用して以下を行います。
このようにプロシージャを使用すると、データプロダクトを標準化できます。このプロシージャのユーザーは、日付範囲やPOSに関係なく 、同じ構造でデータを作成できます。これはコードを再利用する主な利点です。同じロジックが毎回実行されるため、コードの再利用は自然にエラーが発生しにくくなります。
データ管理とは、データが正確で、一貫性があり、効率的にアクセスできることを保証するプラクティスであり、データ主導の意思決定を目指すあらゆる組織にとって不可欠な品質です。強力なデータ管理がなければ、最も高度な分析やレポート作成の取り組みでさえ、信頼性の低い、または一貫性のない情報によって損なわれる可能性があります。
商業業界で一般的に見られる例を見てみましょう。ビジネスでは、顧客にティアに基づいた特典を提供するためにロイヤルティプログラムを確立することがよくあります。航空会社にはマイレージプログラムがあり、ほとんどの小売フランチャイズにはリワードプログラムなどがあります。顧客が同じ航空会社をより多く利用したり、同じフランチャイズからより多くの商品を購入したりすると、顧客はより多くの特典を獲得できます。
ここでは、ストアドプロシージャを使用して標準的な小売ロイヤルティプログラムを管理および更新する方法の例を示します。顧客のロイヤルティティアを管理するために2つのプロシージャが使用されます。1つは指定されたcustomerIDの特定の顧客ロイヤルティティアを更新するためのもので、もう1つは指定された国からのすべての顧客の顧客ロイヤルティティアを更新するためのものです。
それでは、作成したプロシージャを使用してセルビア、ドイツ、カナダの顧客のロイヤルティティアを更新し、更新されたレコードを確認しましょう。
前のクエリは次の結果を生成します。
更新ロジックをそれぞれのプロシージャにカプセル化することにより、コードの重複を回避し、呼び出し元から複雑さを排除します。呼び出し元は、適切なプロシージャパラメータを使用してプロシージャを呼び出すだけで済みます。
DBSQLにSQLストアドプロシージャが追加されたことで、顧客はレガシーエンタープライズデータウェアハウスワークロードをレイクハウスに移行し続けることができます。顧客からのフィードバックに基づき、GAに向けて進むにあたり、いくつかの主要な機能を対処したいと考えています。
SQLスクリプティングおよびプロシージャに関連するフィードバックやリクエストを共有したい顧客は、この フォーム から行うことができます。
レガシーシステムからストアドプ ロシージャを移行するために必要な他の2つの重要なSQLコンストラクトは、 一時テーブル とトランザクションです。一時テーブルは現在DBSQLで一般提供されており、トランザクション（複数ステートメントおよび複数テーブル）のサポートはまもなく提供されます。
既存のDatabricksユーザーの方も、他のデータウェアハウスから移行する方も、SQLストアドプロシージャは複雑なSQLワークフローの管理を簡素化するために活用すべき機能です。SQLストアドプロシージャの利用を開始するには、Databricksのドキュメントをお読みください。
Databricks SQLの詳細については、当社のウェブサイトをご覧になるか、ドキュメントをお読みください。Databricks SQLの製品ツアーもご覧いただけます。既存のウェアハウスを、優れたユーザーエクスペリエンスと低い総所有コストを備えた、高性能なサーバーレスデータウェアハウスに移行したい場合は、Databricks SQLがそのソリューションです。無料でお試しください。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。