Achieving High Data Quality with Databricks SQL: T... - Databricks Community - 98777の翻訳です。
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
企業では、自分たちの意思決定を強化し、競争優位性を得るために、さらにデータに頼るようになっています。しかし、データのボリュームと複雑性が増加することで、品質確保に関係する課題に直面しています。貧弱なデータ品質は不便なだけではありません。誤ったガイドに基づく戦略、収益の損失、規制に関係する罰金、評判の毀損につながる信頼性の問題となります。
データ品質システムは、単なるツールやプロセスのセットではありません。あなたのビジネスオペレーションに対するすべての側面を下支えする戦略的な資産です。頼りにするデータが正確で、一貫性があり、合目的性があることを保証し、自信を持って情報に基づく意思決定を行えるようにします。これまでは、データ品質モニタリングフレームワークは主にETLプロセスやパイプラインにフォーカスしており、データの処理を強調していました。しかし、データ品質の監視は、Databricks SQLのようなツールが活用される分析サイドでも同じように重要なものです。多くの場合、アナリストはデータ洞察の最終的な門番であり、このステージにおけるデータ品質の保証はビジネス上の意思決定における一貫性を維持するためには重要です。
この記事では、アナリストの観点を含めるために従来の境界を超えて拡張することで、堅牢で効果的なデータ品質システムを構築するために、Databricksの機能をどのように活用できるのかを探ります。
Databricks SQLにおけるデータ品質の管理
Databricksでは、データ品質管理における幾つかのキーとなる機能を提供しています:
- スキーマ強制
- 制約
- レイクハウスモニタリング
- Databricks SQLアラート
- データリネージ
架空の小売業者の視点から、上述のそれぞれのテクニックを見ていきましょう。
頻繁に利用するお客様に賞を与えるための、多方面にわたるロイヤルティプログラムを管理する、多国籍小売業者を考えてみます。この小売業者は、店舗内取引、オンライン購買、サードパーティのマーケティングプログラムのような様々なソースから、購買履歴、嗜好、デモグラフィック情報を含む顧客データを収集します。
この小売業者は、新たなサードパーティマーケティングプラットフォームから顧客データを連携する際に課題に直面します。このプラットフォームは、小売業者の既存のスキーマに含まれていない、"Social Media Handles(ソーシャルメディアのハンドル名)"や"Influencer Status(インフルエンサーのステータス)"のような追加フィールドを持つ顧客データを提供しています。さらに、"Date of Birth(誕生日)"のようないくつかのフィールドは期待したフォーマットではありません。
スキーマ強制
スキーマ検証としても知られるスキーマ強制は、テーブルのスキーマにマッチしないテーブルへの書き込みを拒否することでデータ品質を保証します。Delta Lakeにおけるスキーマ矯正の動作原理を以下に示します:
- 書き込み時のスキーマ検証: 書き込みオペレーションの際、Delta Lakeはターゲットのテーブルスキーマと新規データの互換性をチェックします。ミスマッチがある場合、トランザクションはキャンセルされ、データは書き込まれず、ユーザーに通知するために例外がスローされます。
-
カラムの互換性:
- 書き込まれるデータフレームは、ターゲットテーブルのスキーマにない追加のカラムを保持してはならず、カラムのデータ型がマッチしなくてはなりません。
- 大文字小文字の区別に関しては、Deltaは大文字小文字を保持します、スキーマは大文字小文字を区別しないものとして取り扱います。これによって、'Order_Number'や'order_number'のようなバリエーションを用いたクエリーが可能となり、Delta Lakeは同じものとして取り扱います。しかし、'Order_Number'や'order_number'のように、大文字小文字のみが異なる名前の2つのカラムを格納することはできません。Delta Lakeはこれを防ぐために例外を発生させます。
例えば、ミスマッチするスキーマでデータフレームが既存のテーブルに書き込まれた際に何が起きるのかをみてみましょう。
Databricksはターゲットテーブルにマッチするように、安全にカラムをキャストしようとすることに注意してください。
スキーマ制御を強制することで、あなたは自信のデータに対して意図を持てるようになり、高い標準を維持し、データ品質を保証することができます。これは、あなたのテーブルをクリーンで合目的性があるものとし、それらの機能を効果的に提供することができます。
しかし、注意深い検討の後に新たなカラムが必要であると決断した場合、スキーマ進化の機能を用いることで、容易にこれを達成することができます。
あなたのSparkコマンドの.writeや.writeStreamに.option('mergeSchema', 'true')を追加することで、スキーマ進化を有効化することができます。
Databricksでスキーマ強制を使うことで小売業者の例においては、すべての到着する顧客データが事前定義されたスキーマに準拠することを確実にすることができます。これは、予測されないカラムや不適切なフォーマットを持つすべてのデータが、書き込まれる前に自動でフラグがつけられるか拒否されることを意味します。
それでは、今度は同じ小売業者が顧客データのエントリー、特にメールアドレスの欠如や不適切なメールアドレスに基づく問題に直面していることを考えましょう。いくつかのエントリーはnullあるいは不適切なフォーマットであり、コミュニケーションの失敗や効果的ではないマーケティングキャンペーンに繋がります。
制約
Databricksでは、標準SQLのcontraint管理句をサポートしています。制約が強制されると、それらはテーブルに追加されるデータの品質や完全性を自動で検証するようになります。Deltaテーブルでは2つのタイプの制約をサポートしています:
- NOT NULL: カラムにNULL値が挿入されることを防ぎます
- CHECK: それぞれの入力行において、指定されたブーリアン表現が適切であることを要求します
いずれかの行で制約が違反すると、トランザクション全体が失敗し、エラーを発生させ、ロールバックを行います。
以下の例では、どのように制約を追加、削除、表示できるのかを示しています。
--Add Constraint
ALTER TABLE customer ALTER COLUMN Cust_id SET NOT NULL;
ALTER TABLE customer ADD CONSTRAINT validIds CHECK (Cust_id > 1 and Cust_id < 99999999);
--Drop Constraint
ALTER TABLE customer ALTER COLUMN Cust_id DROP NOT NULL;
ALTER TABLE customer DROP CONSTRAINT valid
--Display Constraint
DESCRIBE DETAIL customer;
SHOW TBLPROPERTIES customer (Displays the results in a relatively easier-to-read format)
Databricksで制約を実装することで、小売業者はすべての顧客レコードにメールアドレスが含まれることを確実にするために、"Email"カラムにNOT NULL制約を設定することができます。さらに、正規表現をもちいてメールアドレスのフォーマットを検証するために、CHECK制約を適用することができます。これによって、システムに適切で完全なメールアドレスのみが追加されることを確実にすることができ、マーケティングの取り組みの効果を高め、顧客エンゲージメントを強化することができます。
小売業者は今度は、顧客トランザクションデータの一貫性と精度に関するデータ品質の経年劣化の課題に直面しています。複数のチャネルからデータが収集されるので、記録されるトランザクションの数の矛盾や、レコードの欠如や重複のようなデータ品質問題を示す可能性のある購入パターンの異常値が含まれることがあります。
レイクハウスモニタリング
レイクハウスモニタリングによって、UCに登録されているすべてのテーブルの品汁を監視することができます。レイクハウスモニタリングを使うには、ワークスペースでUCが有効化され、Databricks SQLにアクセスできる必要があります。
ユーザーは、DatabricksのUI、あるいはAPIを用いてテーブルのモニタリングを設定することができます。レイクハウスモニタリングは以下のタイプの分析を提供しています:
- 時系列プロファイル: タイムスタンプカラムに基づいた時系列データセットを含むテーブルに使用します。時系列に対する時間ベースのウィンドウに対するデータ品質メトリクスを計算します。
- スナップショットプロファイル: 任意のDeltaマネージドテーブル、外部テーブルを監視します。
- 推論プロファイル: 機械学習分類モデル、回帰モデルによって予測された値を格納するテーブルで使用します。このテーブルには、タイムスタンプ、モデルID、モデル入力(特徴量)、モデルの予測結果を格納するカラム、ユニークな観測値IDと正解ラベルを含むオプションのカラムが含まれます。このテーブルには、モデルの入力としては使用されませんが、公正性やバイアスの調査やその他の監視の助けとなるであろうデモグラフィック情報のようなメタデータを含めることができます。
テーブルのモニターは自動で2つのテーブルとダッシュボードを作成します。
- プロファイルメトリクステーブルにはサマリー統計情報が含まれます。
- ドリフトメトリクステーブルには、データドリフトの時間変化に関する統計情報が含まれます。
レイクハウスモニタリングの使い方を学ぶには、公式のドキュメント(AWS | Azure)をご覧ください。
ビジネスロジックの側面をキャプチャする特定の計測値を作成する必要がある場合に、特に有用なカスタムメトリクスを設定することも可能です。様々なタイプのカスタムメトリクスを活用することができます。
- 集計メトリクス: プライマリテーブルのカラムに基づいて計算され、プロファイルメトリクステーブルに格納されます。
- 導出メトリクス: 事前に計算された集計メトリクスに基づいて計算され、プライマリーテーブルを直接使用しません。これらもプロファイルメトリクステーブルに格納されます。
- ドリフトメトリクス: 事前に計算された集計、導出メトリクスを2つの異なる時間ウィンドウ、あるいはプライマリーテーブル、ベースラインテーブルとで比較します。これらはドリフトメトリクステーブルに格納されます。
例えば、あなたの注文テーブルの注文の平均価格を追跡したいものとします。
別の例を見てみましょう。遅延のあった注文(注文の作成日から30日経過後もオープン状態の注文)を追跡したいものとします。
メトリクスが保存されると、以下のようにレイクハウスモニタリングのタブに表示されます。
様々なその他のメトリクスに加え、カスタムメトリクスはプロファイルメトリクステーブルに保存されます。
注意: 監視するテーブルの数が多い場合、プログラムから複数テーブルのモニタリングを効率的に有効化するためにAPIを活用することができます。
Databricksでレイクハウスモニタリングを実装することで、小売業者は自分の顧客トランザクションデータの品質を継続的に追跡することができます。レイクハウスモニタリングによって、小売業者は自動化されたプロファイリングと、トランザクションテーブルに対するドリフト分析をセットアップすることができます。このセットアップによって、トランザクションのボリュームにおける予期しないスパイクや減少、購入パターンの一貫性の欠如のようなデータ分布の変化を検知する助けとなります。
小売業者は、前段のシステムのエラーやデータ取り込みの失敗によって、自分のゴールドレイヤーのテーブルに記録されるトランザクション数が予想するよりも少ないと言った断続的なデータ品質問題にも直面しています。これらの問題は、不完全な顧客プロファイルや不正確な報奨の計算に繋がり、顧客の信頼やエンゲージメントに影響を及ぼします。
アラートをセットアップ
メトリクステーブルの準備ができたので、潜在的なエラーをあなたに通知するアラートを設定することができ、これによって後段のリスクを低減する助けとなります。例えば、null値やゼロのパーセンテージが定義済みの閾値を超えたり、時間と共に変化を示す場合に通知を受け取れるようにアラートを設定することができます。
avg_priceやdelayed_ordersのようなカスタムメトリクスに対するアラートを設定する例を見ていきましょう。
-
SQLクエリーを作成し
delayed_order_countという名前にします。Select COUNT(delayed_orders) FROM malay_demo.tpch.orders_profile_metrics; -
以下の設定でアラートをセットアップします。
同じようにして、あなたのデータの全体的な健康状態や信頼性を維持するために、プロアクティブなステップを踏めるように、キーとなるメトリクスに対するアラートを設定することができます。これらのメトリクスを可視化するために、レイクハウスモニタリングはカスタマイズ可能で、すぐに利用できるダッシュボードを提供しています。
Databricks SQLのアラートを活用することで、小売業者はトランザクションデータの品質に関係するキーとなるメトリクスを監視するために、自動化された通知をセットアップすることができます。
残念なことですが、小売業者は間違った報奨の計算と顧客の不満足につながる、顧客購買データにおける矛盾を発見しました。これらの矛盾は複数のソースからのデータ連携におけるエラーから発生しており、どこで問題が発生しているのを特定することが困難です。
データリネージ
データガバナンスにおいてデータリネージは重要なものであり、データ品質管理を間接的にサポートする価値のある洞察を提供します。Unity Catalogを通じて、Databricksはクエリー、ノートブック、ジョブ、ダッシュボードを横断するデータフローをキャプチャする詳細なデータリネージのトラッキングを提供します。この包括的なビューはカラムレベルまで展開され、ユーザーはデータが組織全体のプロセスでどのように変換、活用されているのかを確認することができます。
- データリネージは、データの誕生から最終目的地に至るジャーニーを、変換処理、通過するシステム、サポートするビジネスプロセスを詳細にカバーする透明なビューを提供します。このトレーサビリティは、どこでデータにエラーが混入したのかを特定する助けとなります。
- 品質問題によって影響を受ける後段のオブジェクトを特定することができます。
データリネージは直接データ品質を監視、保証はしませんが、影響のある問題を特定、意解決する際には重要なものとなります。誕生から最終の目的地に至るデータのパスを追跡することで、リネージはエラーや非一貫性が導入されたであろう場所の特定に役立ちます。この機能によってデータチームは、クイックに問題を診断し、修正アクションを実装することができ、データの完全性と信頼性を維持することができます。
さらに、データリネージを理解することで、データソースや処理ワークフローに対して変更が行われた際のインパクト分析の助けとなります。変更が後段のアプリケーションや分析にネガティブな影響を与えないことを保証し、データ品質を維持します。さらに、リネージは規制の要件や内部標準に対するコンプライアンスで重要となる、透明性や説明責任を提供します。
DatabricksのUnity Catalogを通じたデータリネージを活用することで、小売業者は顧客データのソースから最終的な目的地に至る全体的なジャーニーを追跡することができます。この機能によって、データ変換処理や連携の過程のどこでエラーや非一貫性が導入されたのかを容易かつ正確に特定することができます。
まとめ
まとめると、あなたのデータエコシステムの完全性、信頼性、精度を維持するためには、頑健なデータ品質を保証することは重要なことです。制約、レイクハウスモニタリング、カスタマイズ可能なダッシュボード、アラート、データリネージ機能のようなツールを活用することで、企業はデータ問題が後段のプロセスに影響を与える前に、プロアクティブにデータ問題を検知、対応、防御することができます。データ品質管理に対する包括的なアプローチを導入することであなたのデータを信頼することができ、意思決定を改善し、全体的なビジネス成果を強化します。