注：本記事は(2022年2月10日)に公開された(Mass Data Fragmentation: Reducing ‘Data Puddles’)を翻訳して公開したものです。
数年前、Kent Grazianoは、ある大企業に入社し、データに関する業務を担当することになりました。最初に遭遇した問題は、すべてのデータがどこにあるのかを誰も把握していないということでした。同氏は入社後3か月かけてデータのソースとターゲットを調査し、最終的にすべての流れを示す企業のデータマップを作成しましたが、それは決して見栄えの良いものではありませんでした。
Graziano氏は、「結局、同じデータが3つも4つも送られていることが分かりました」と語りました。未加工データが変換されてデータウェアハウスに保存され、そこから別のウェアハウスに移され、しかもその移動先でも元の未加工データが取り込まれているというケースもありました。
先日Snowflakeのチーフテクニカルエバンジェリストを退任したGraziano氏は、このシナリオは実によくあることだと述べます。データは、レイク、ウェアハウス、データマート、SaaSプラットフォーム、スプレッドシート、テストシステムなどに散在し、コピーされています。これは大量のデータの断片化であり、いわゆるデータスプロール、あるいはデータパドルと呼ばれる状態です。
2021年12月のIDCの「State of the CDO」調査によると、組織の実に75%には、統合、アクセス、ガバナンス、保護を含む一連のデータ活動をエンドツーエンドで管理するための十分なアーキテクチャが整備されていないとのことです。このようなガバナンスの欠如とレガシーシステム、シャドーIT、そして人の善意とが結びつくことで、大幅な断片化が進むことになります。
シングル・ソース・オブ・トゥルース（信頼できる唯一の情報源）の実現はすぐにできるものではありませんが、組織のアナリティクス作業の効率、正確さ、一貫性、価値を高めるためには、散在するデータパドルの数を減らすことがこれまで以上に重要になってきます。
データスプロールがビジネスに与える影響
このような状況を正しく理解するためには、断片化された現状の原因と影響について、さらに詳しく調べる必要があります。
Graziano氏は、数百テラバイトの同一のデータを3か所で保存していた別の企業の例を挙げました。「その会社には正規化されたOracleデータウェアハウスがありましたが、サーバーがパワー不足であったため、別のサーバーにディメンションモデルを置き、さらにデータサイエンティストのためのHadoopインフラを設置して、同じ情報を分析できるようにしていました」と同氏は述べます。
M&Aは確かに問題の原因の1つです。
Acceleration Economyのアナリストであり、30年にわたりCIO、CTO、CDOの職を歴任してきたWayne Sadin氏は、「問題は技術的負債とシャドーITだ」と述べています。「12社を買収して、172のデータベースができます。14はもう使われておらず、所有者がいないものも6つあります。さらにスプレッドシートの数は500、といったことが考えられます。」ある大企業では、同社の最大のデータベースが、誰かの机の下にあるPCに接続されていたというエピソードもあります。この事実は、IT部門が場所を移したときに偶然発見されたということです。
Sadin氏は、IT部門がM&Aの議論の最後の段階になって関わるのでは、統合計画を十分に検討して構築する機会すらないと述べています。「George Shultz将軍はかつて、「着陸に私が必要なら、離陸もさせてくれ」と言っています。」
Graziano氏は、データサイロの増殖がよく発生するのは、合併以外にも、包括的な将来的アーキテクチャを構築するのではなく、単発のアプローチで性能問題を解決しようとすることに原因があると指摘しています。このようなソリューションは、その時々のニーズに対応するのには役立ちますが、コスト、性能、データの断片化に対する全体的な規模や影響については計算するのが困難です。
「ベンダーの説明に疑問を持ち、検証可能な参考資料をあたり、同等の業務に携わる人物を探して、「うちの設計者と御社の設計者で話ができますか？」と尋ねる以外に、本当に良い評価方法はありません」とGraziano氏は語ります。
「クエリアクセラレーションソフトウェア、データ仮想化、インメモリアナリティクスソフトウェアなど、これらはすべて、アーキテクチャの根本的な性能問題を解決するために生み出されたものです。SQLレイヤーでクエリを書いても、そのクエリをプッシュダウンしてソースシステムで実行する場合には、どうしても性能に影響が出ます。」
Sadin氏は、シャドーITの問題も本質的には同じだと指摘しています。また、事業部門の従業員がパブリッククラウドストレージや未承認のアプリケーションにアクセスすることが根本的な問題でもありません。むしろ問題は、IT予算の管理方法に起因していることが多いと言えます。
同氏は次のように語っています。「ビジネス部門に解決すべき問題があると、投資委員会で、「Xドル必要だ」と言います。すると、IT部門からは判で押したように「要求額の80%ならOK」という回答があります。
しかし、ビジネス部門には解決しなければならない部分がまだ20%残っています。そこでソリューションを求めることになります。最近では、非常に安くデータソリューションを利用できるようになりました。アプリのスプロールがあったように、今度はデータのスプロールが生じることになります。」
このような断片化がもたらす最も明白な影響は、データストレージの重複に多額の費用がかかるという点ですが、Graziano氏とSadin氏は、これは実際には問題の一部に過ぎないと口を揃えます。
さらに良くないのは、「経営陣の会議では、悪名高い「結果の競合」が発生することだ」とGraziano氏は語ります。異なるデータセットで同じような分析を行った複数のグループが、数時間異なるデータで作業することによって、異なる結果を主張し、異なる決定を訴えることになります。
矛盾する報告書、古いデータに基づくビジネス上の意思決定、不完全なデータに基づく予測モデルなど、悪影響は数えきれません。
統一されたデータへの道
では、大量のデータの断片化を解決するにはどうすればよいのでしょうか？最終的には、統一されたアーキテクチャとガバナンスにその答えがあると言えます。
Graziano氏は、次の3つのレイヤーで校正されるデータアーキテクチャを提唱しています。
- 未加工データ
- 変換、クレンジング、標準化されたデータ
- プレゼンテーションレイヤー
最初のレイヤーは、組織がトレーサビリティと監査性を維持する必要がある場所に永続的に置いておくべきだとGraziano氏は言います。「昔ならば永続的ステージングエリアと呼んでいたものに該当します。」
第2のレイヤーは、マスターデータ管理の用語を借用し、「キュレーション」または「ゴールデン」レイヤーと呼ばれるものです。これは実際に、事実の唯一の情報源となる履歴のタイムスタンプ付きのレポジトリです。
最後に、「企業にとって意味のある絵となる」利用レイヤーがあります。一方でデータサイエンティストは、半分未加工のステージ2のデータを扱うことになるかもしれません。
「しかし、ビジネスにはそれらは不要であり、多次元ビューや、理解できる形式でのデータを見つける機能が必要とされています。」
このアプローチは、従来のETL（抽出、変換、ロード）プロセスをELTに効果的に作り変えるものです。「目標は、データを一度移動してから何度も使うこと」であるとGraziano氏は述べています。
もちろん、ローマは一日にして成らずという諺にもあるように、新しいエンドツーエンドのアーキテクチャは一朝一夕にできるものではありません。
Sadin氏は実用的な観点から、3つの異なるステージで展開されるプロセスを説明し、それは順次または同時に起こる可能性があると説明しました。「私はこれを「パッチ、磨き、完成」と呼んでいます。」
パッチは、明らかに急を要する配信上の問題に対して行うものです。システムの故障やコンプライアンス違反により、すぐに修正しなければならない場合の正しい手順は、単にローカルのスプレッドシートやデータベースを修正することである場合もあります。恒久的な解決策ではありませんが、このようなケースでは恒久的な解決策を待っているわけにはいきません。
Sadin氏が言う「磨き」の手順には、ロボティックプロセスオートメーションやその他の大規模な作業が含まれる場合もあります。Sadin氏は、「これは、根本的な解決策ではなく、ビジネスの性能と価値を高めるための追加的な場所を見つけるためのもの」だと述べています。
第3の「完成」ステージで、「私は一息ついて、データのスプロールを設計あるいは統合します」と同氏は語ります。しかし、CIOやデータプロフェッショナルの現実では厄介なことにほとんどの場合、3つのモードを同時にこなす必要があります。
成功のカギは、データからではなく、ビジネスのニーズから始めることです。「CEOと話す時間があれば、「クレヨンと紙を渡すから、欲しいレポートを絵に描いてください」と言いたい」と、同氏は笑いました。「それぞれの事業部門で、まず「必要なものは何か」を聞くところから始めるのです。」
ガバナンスとサンドボックスで断片化を抑制
Graziano氏によれば、統合され設計されたビジョンが具体化され始めても、「自分のデスクトップで変換できるようにデータのコピーをくれ」と主張する人やグループがいるのが普通であり、場合によっては組織的な影響力のある人がそのように要求してくることもあるということです。
その要求に対して無条件に「はい」と応じる組織は、再び断片化への道を歩むことになります。「ガバナンスのルールがその抑止力にならないといけない」とGraziano氏は語ります。ただし、正当なビジネスニーズがある場合には、サンドボックスは適切だと言えるでしょう。「（コピーした）データを継続的に更新するのではなく、サンドボックスを作り、そこに一旦収納しておいて、必要なものの内容が分かってから、本番環境に投入します。」そうすることでサンドボックスを永続的に使うのではなく、削除できるようになります。
大量データの断片化を抑制する上で、自社でどのようなフェーズやプロジェクトおよび意思決定が必要であったとしても、その判断と規律よりも重要なことはありません。結局のところ、これはビジネスの問題であり、技術的な問題ではありません。
「同業他社および外部から参入してくる誰よりも、データを上手に活用する必要があります」とSadin氏は述べています。「データを思慮深く管理することの価値が、かつてないほど高まっています。」