Qlik のロードスクリプトごとに同じデータクレンジングを繰り返していませんか？

1 つのアプリが生データをその場しのぎでクレンジングするのは、一時的なワークアラウンドです。しかし、10 個のアプリが同じ生データをそれぞれ微妙に異なる方法でクレンジングしている状態は、誰も全体設計していない「第 2 の影のデータウェアハウス」が社内に乱立しているのと同じです。

同じクレンジング処理がどこで重複しているのか

• すべてのアプリがマッピングをコピーしている： 国コード、製品コード、顧客コードのための MAPPING LOAD と ApplyMap が、そのフィールドを必要とするすべてのスクリプトにコピペされています。
• すべてのコピーが静かに乖離していく： あるスクリプトは文字列を Trim して大文字化し、別のスクリプトはそのまま放置し、3 つ目のスクリプトは先月新しいコードを追加した……同じフィールドなのに値が一致しなくなります。
• あらゆる QVD レイヤーで重複する： 抽出（Extract）アプリ、変換（Transform）アプリ、QVD ジェネレーターアプリがそれぞれデータをクレンジングし、後続の分析アプリが「念のため」と称してもう一度同じクレンジングを実行します。
• コード変更のたびに全スクリプトの捜索が必要： ソース側で新しいコード体系が導入されると、該当する全スクリプトを探し出して修正しなければならず、見落とされた 1 つが静かに不整合を起こします。

$(Include) ファイルを使えばスクリプトの文字列自体は共通化できますが、各アプリがそれをいつ、どの順番で、本当に適用しているかまでは統制できません。

なぜその負担がアナリストに押し付けられるのか

• 各アプリはビジネスの緊急要請に応じて個別に構築され、前回のスクリプトから修正箇所をコピペするのが最も早いリリース方法でした。
• ルールの明確なオーナーが不在のため、2 つのスクリプトで処理結果が乖離し始めても誰も気づきません。
• 自分が担当するスクリプトを揃えることはできても、ソースシステムが生データを各アプリに直接流し込む構造そのものを止めることはできません。

本来その処理が行われるべき場所

• ソースデータのクレンジングはウェアハウスの責務： Qlik 側でそれをやらせると、そのフィールドを触るすべてのロードスクリプトで同じ処理が何重にも書かれます。
• 1 箇所の中央基盤に集約すべき： データウェアハウスやデータハブ側で 1 度だけ標準化・クレンジングを行い、すべてのアプリが完成したディメンションを参照すべきです。
• 「DWH の改修は高額で時間がかかる」と思われるかもしれませんが： その見積もりは手作業でパイプラインを構築することを前提としています。専用の自動化プラットフォームを活用すれば、モデルからパイプラインが自動生成されるため、必要なコストと期間は劇的に圧縮されます。

完成したモデルが届いたときに変わること

Datavault Builder は、SQL Server、Azure SQL、Snowflake、BigQuery など既存のデータベース上で、統合・履歴管理されたデータボルトおよびディメンショナルレイヤーをネイティブに自動生成します。

• 各クレンジングルールは 1 度だけ定義： コード体系のマッピング変更も 1 箇所で行われ、全アプリに自動反映されます。
• 統合時に重複を根本解決： アプリごとの個別フィルターではなく、ビジネスキーに基づいて一元的に重複が排除されます。
• サテライトによる履歴管理： 過去の状態を保存するために QVD ファイル側で苦心する必要がなくなります。
• ロードスクリプトが短くシンプルに： クレンジング済みの完成テーブルから単純に LOAD するだけになり、誰でも読めるスクリプトになります。
• データリネージにより各変換処理が追跡可能になり、ルール変更の影響範囲をリリース前に把握できます。

上流チームに何を要求すべきか

単に「スクリプトがスパゲッティ化している」と嘆くのではなく、以下のように依頼してください：

「複数の QVD 作成アプリで同じ元データ項目のクレンジングやコード変換を行っており、ロジックの不整合が発生しています。各アプリが生データの抽出ではなくクレンジング済みのディメンションを直接読み込めるよう、データ統合レイヤーをウェアハウス側で整備してもらえませんか？」

もし上流から「統合レイヤーの構築には 1 年かかる」と言われたなら、それは手作業でのパイプライン開発を前提としているからです。Datavault Builder は、まさにそのプロセス全体を自動化するために作られました。