はじめに
データ活用が一定規模まで進んだ組織においては「データがあるか」よりも「データが正しい状態か」に関心が移っていくことは一般的なように思います。
直近、TROCCOのデータマート機能に追加された データ品質チェック は、そうした運用フェーズの課題に対応するための機能です。
本記事では開発の背景、既存機能との関係、具体的な使い方、そして実務における使い分けまでを解説します。
データ活用の拡大期に直面する品質の課題
データ活用が拡大すると、データ活用に対する要求や期待が増大する中でデータマートの数は増え、またデータを使うステークホルダーも増加します。
事業環境や上流システムの変化に伴いデータマートは継続的に修正され、これまでごく少数のデータ活用立ち上げメンバーで共有されていた暗黙知で成立していた設計は壊れやすくなります。
その結果、「いつの間にかダッシュボードに表示される数字がおかしい」という状態が発生し、調査やリカバリーに想定外の工数が発生します。
TROCCOを普段お使いの皆さんも「ダッシュボードの数字がおかしい」という問い合わせがあり、ダッシュボードが参照しているデータマート自身はもちろん、そのソーステーブルの中身や、それらを作成しているジョブの実行状況などを確認していたら、思いの外時間がかかった経験がある方も多いのではないでしょうか。
また、データ活用が進むにつれ、データ基盤に求められるサービスレベルも高くなっていきます。その象徴的な例が、社外提供データや社内レポーティングです。
ケース1：社外提供データに求められる品質保証
クライアント向けKPIダッシュボードやアライアンスに伴うデータ連携など、社外にデータを提供する局面では、品質が担保されていない状態での納品は信用毀損につながります。生成処理とは別に検証プロセスを実施するのが一般的ですが、体系だったプロセス構築にはノウハウが必要です。
ケース2：社内レポーティングにおける品質要件の高まり
月次KPIや会議資料など、データが意思決定に使われるシーンが増えるほど、データには正確性と安定性が求められます。データマートの作成が正常終了していても、主キー重複や必須カラムのNULL混入があればいつの間にかデータがおかしくなってしまうかもしれませんし、そうしたことが頻発しデータに対する信頼性が損なわれてしまっては本末転倒です。
そこで、これらの課題に対する対応をTROCCOで行うためのプロセスを次章以降で解説します。
TROCCOにおけるデータマートとこれまでのデータ品質担保の支援機能
TROCCOには、転送されたデータをビジネス用途に加工する「データマート機能」と、それらを順序立てて実行する「ワークフロー機能」があります。
これまでも品質担保の手段がなかったわけではありません。ワークフロー内のタスクとして「ワークフローデータチェック」を利用することで、任意のSQLを実行し、その結果に応じて後続処理を制御することが可能でした。
この機能でできることは「SQLを書くことで、特定のテーブルの品質をチェックする」というシンプルなものです。条件分岐タスクと組み合わせることで
- ワークフローのデータチェックが成功したときだけ後続の処理を実行する
- ワークフローのデータチェックが失敗したときだけSlackに通知し、リカバリ処理を実行する
といった、データの品質に応じた柔軟な処理を実行することができます。
しかし、データマートが増え続ける運用フェーズにおいて、すべてをワークフローデータチェックで網羅的に管理するのは現実的とは言えません。
チェック内容のばらつきや設定漏れも発生しやすく、組織として標準化するには課題があったことも事実です。
データマート品質チェック機能とは
こうした背景から開発されたのが、「データマート機能のデータ品質チェック」です。
データマート定義単位で、GUIベースのシンプルな操作で標準化されたチェックを設定できます。
現在提供しているチェックは以下の3種類です。
-
単一カラムによる一意性チェック: 指定カラムに重複している値が含まれていないか
- 結合に使われるキーなど、重複が発生してほしくない項目のチェックに利用することを想定しています
-
複数カラムによる一意性チェック: 指定カラムしたカラム複数に重複している値が含まれていないか
- 例えば、GROUP BYとJOINを組み合わせたデータマート作成を行った際に、「複数カラム(日付カラムと、IDカラムなど)によるキーの組み合わせ」に重複がないことを保証したいケースにおいて、役立つかと思います。
-
NOT NULLチェック: 指定カラムにNULLが含まれていないか
- CASE文を使って処理をしたカラムやデータ結合を行ったカラムなど、NULLが混入しがち、ないしNULLであるべきでないカラムに対してのチェックに利用することを想定しています。
これにより、データマートが満たすべきデータの受け入れ条件を明示し、実行時に検証するための仕組みです。
データ品質をチェックした結果に応じて、ジョブを失敗とし、ワークフローの後続の処理を止めるか、あるいは一旦品質チェック結果を記録としてだけ残し、後から調査するようなワークアラウンドも構築可能です。
また、データ品質チェックを行うメリットは、ジョブ実行時に安全性を確保するのももちろんですが、自身が作成したデータマートの設計やデータが満たすべき前提をチームメンバーに伝える、ドキュメントに近い役割を担ってくれることを期待しています。
UIウォークスルー
さて、機能のユースケースについてはある程度ご理解いただけたと思うので、実際のUIを見ながら、設定方法からデータ品質チェック結果の活用方法まで見ていきましょう。
以下の画面表示についてはすべてデータマート品質チェックが有効になっているアカウントの画面表示です。
1. データマート定義の編集画面から品質チェック設定画面への導線
対象のデータマート定義を開き、「STEP3: 品質チェック設定」をクリックすることで既存のデータマート定義に品質チェックを追加することができます。
新規作成時にも「STEP2: データ取得設定」の後に設定が可能です。
2. データ品質チェックを設定する
単一カラムにもとづく品質チェック設定
カラムごとに以下のチェックが設定できます
- 一意性チェック
- NOT NULLチェック
複数カラムによる品質チェック設定
複数カラムによる一意性チェックが追加できます
- 設定前の画面
- ここから、「チェックを追加」を押下し、カラムの組み合わせを選択できます
3. チェックについての設定
失敗時の挙動
品質チェックで失敗となった場合の挙動を設定します。
-
記録のみ
- データ品質をまずは試しにモニタリングしたいケースや、後続のジョブを実行しても切り戻しが容易なケースなどはこちらを選択するのが良いでしょう。
-
ジョブ失敗として扱う
- 先述の例でいう社外向けの共有データなど、データ品質チェックが失敗した場合にただちに問題になるようなケースにおいてはこちらが適しています。ぜひ通知も合わせて設定しましょう。
品質チェック対象データ設定
品質チェックの対象とするデータの範囲を設定します。
-
範囲を指定してチェックする
- 指定したカラムを基準に、任意の期間で品質チェックを行います。増分更新やSCD type2など、差分のみ更新している場合は、チェック対象を絞ることでDWHにかかる金銭的コストを抑えながらデータ品質の担保が可能です。
-
全データを対象にチェックする
- チェック対象を全データとします。洗い替えの場合や、データ全体で特定のキーが一意になるようにチェックを設定している場合は原則こちらを選択する形が良いでしょう。
4. 品質チェックでエラーを検出したことに素早く気づく
さて、「ジョブは成功したけど品質チェックでエラーが検出された」状態において「ジョブ自体は成功だから失敗時通知が飛ばない」というのは「ジョブ失敗時通知」の仕様としては正しいものの、実運用上は困りますよね。
そんなときに役立つのが「ジョブ成功、かつ品質チェックエラー検出時」の通知です。
これにより「SQLは正常に実行されテーブルは更新・作成されたけど品質チェックによって設定された条件を満たしていない」ことに素早く気づくことができます。
通知設定の新規作成画面から、通知タイプを「ジョブ成功、かつ品質チェックエラー検出時」にすることで、そんな状況のジョブが発生した際に通知を送ることができます。
実際に届く通知のサンプルです(Slackの場合)
こうした設定を行うことで、品質チェックにてエラーが検出された際、素早く気づき対処することができます。
5. 品質チェック結果の参照
品質チェックの実行結果はデータマートジョブ画面で参照できます。
この画像の例では「失敗時の挙動」を「記録のみ」に設定しています。
ジョブ自体は成功になっているものの、作成されたテーブルの品質に問題があることがわかりやすくなっています。
また、このジョブに紐づくデータマート定義画面にも、最新のジョブで品質チェックでエラーになっている場合、画面上部に警告とその内容が表示されます。
さいごに: 実務における使い分け
直近リリースしたデータマート品質チェックについて、解説しましたが、ワークフローデータチェックはもう使わなくて良いのでしょうか。そんなことはありません。
データマート品質チェックとワークフローデータチェック、この両者は置き換えではなく、補完関係にあります。
データマート品質チェックが適しているケース
- 各マート単体で完結するデータについての基本制約の検証
- 主キーの一意性保証
- 必須カラムのNULL禁止
- データ品質チェックを組織として標準化し、網羅的に展開したい場合
ワークフローデータチェックが適しているケース
- 任意SQLによる自由な検証
- 複数テーブルを横断した整合性チェック
- 実行タイミングを細かく制御したい場合
- 複雑な業務ロジックを含む条件判定
標準化して広く適用するチェックはデータマート品質チェックで担保し、高度で個別性の高い検証はワークフローデータチェックで補完する、という住み分けを想定しています。
まとめ
データ活用が拡大するほど、データの品質管理は個人の努力や工夫に依存できなくなり、いずれ仕組み化が求められます。
そのような状況において、データマート品質チェックは、
- データマートが満たすべき条件・設計前提を明文化し、
- 毎回の実行時に検証し、データの状態の変化や障害復旧時のヒントとなる情報を提供し、
- 安心・安全なデータ基盤運用を組織として標準化する
ことを目指して開発した機能です。
ワークフローデータチェックと組み合わせることで、自由度と標準化を両立しながら、持続可能なデータ品質運用を実現できます。
既存のデータマートにもぜひ設定し、品質を“暗黙知”から“明示的な受け入れ条件”へ移行してみてください。
Discussion