データウェアハウス開発の3つの原則

公開: 2022-03-11

ガートナーは、新たに開始されたビジネスインテリジェンスプロジェクトの70〜80パーセント近くが失敗すると推定しています。これは、不適切なツールの選択からITとビジネスの利害関係者間のコミュニケーションの欠如まで、無数の理由によるものです。業界全体でBIプロジェクトの実装に成功したので、このブログ投稿で私の経験を共有し、ビジネスインテリジェンスプロジェクトが失敗する主な理由を強調したいと思います。この記事では、データウェアハウスの構築方法を管理する3つの原則に基づいて、障害への対策を紹介します。これらのデータウェアハウスの概念に従うことは、データウェアハウス開発者として、BI実装の一般的な甌穴や陥没穴を回避して開発の旅をナビゲートするのに役立ちます。

ビジネスインテリジェンスデータウェアハウスの実装

ビジネスインテリジェンスデータウェアハウスを成功させるための基準はプロジェクトによって異なりますが、すべてのプロジェクトで一定の最小値が期待され、必要とされています。成功しているビジネスインテリジェンスデータウェアハウスで通常見られる主な属性のリストは次のとおりです。

価値：ビジネスインテリジェンスプロジェクトは、何ヶ月、あるいは何年にもわたる可能性があります。ただし、継続的な資金調達と関心を確保するために、プロジェクトの非常に早い段階でデータウェアハウスの利点をビジネスの利害関係者に示すことが重要です。理想的には、利害関係者は、プロジェクトの最初の3週間以内に、新しいシステムから意味のあるビジネス価値を示す必要があります。
セルフサービスBI： ITがデータ要求を実行したりデータ分析を実行したりするのを待つ時代は終わりました。現在、BIプロジェクトの成功は、ビジネスユーザーがシステム自体から価値を引き出す力をどれだけ発揮できるかによって評価されます。
コスト： BIプロジェクトは、通常、事前の実装コストが比較的高くなります。高い初期コストを相殺して相殺するには、メンテナンスコストの低い倉庫を設計することが重要です。クライアントがデータ品質の問題を確認/診断したり、データモデルを定期的に変更したり、ETL障害を処理したりするために、本格的なBI開発者のチームを必要とする場合、システムは予算に費用がかかり、しばらくするとオフになるリスクがあります。。
適応性：進化するビジネス需要に適応する能力は非常に重要です。市場で入手可能な無数のBIツールと、それらが追加の機能を含むように進化するペースを覚えておくことが重要です。ビジネスが継続的に進化するという事実と相まって、倉庫の要件は変化します。適応性を確保するには、データウェアハウスを設計して、将来的にさまざまなバックエンドや視覚化ツールなどの代替BIツールを使用できるようにし、予期しない要件の変更に適応できるようにする必要があります。

成功するソリューションを構築した経験、そしておそらくさらに重要なことに、失敗したプロジェクトに関与した経験を通じて、ビジネスインテリジェンスシステムの実装が成功する可能性を高めるには、3つの主要な原則が最も重要であるという結論に達しました。ただし、それらを詳細に説明する前に、いくつかのコンテキストから始めましょう。

データウェアハウスとは何ですか？

さまざまなデータウェアハウスの概念を掘り下げる前に、データウェアハウスが実際に何であるかを理解することが重要です。

データウェアハウスは、多くの場合、ビジネスエンティティの日々のレポートニーズを支援するために作成されたビジネスインテリジェンスシステムと考えられています。 OLTPデータシステムと同じリアルタイムのパフォーマンス要件（標準実装）はありません。OLTPシステムにはビジネスの1つの小さなサブセットに関連するデータのみが含まれますが、データウェアハウスはビジネス。

データウェアハウスモデルは、ウェアハウスが運用レポートを作成するための単なるツールではなく、「すべてのものデータ」の中心的なハブと見なされる場合にのみ、ビジネスにメリットをもたらします。すべての運用システムは、データウェアハウスと双方向で通信して、データをフィードし、運用効率を向上させる方法に関するフィードバックを受け取る必要があります。価格の上昇や供給/在庫の削減などのビジネスの変化は、ビジネスが結果を確実に予測および定量化できるように、最初にデータウェアハウス環境内でプロトタイプ化および予測する必要があります。このコンテキストでは、すべてのデータサイエンスおよびデータ分析機能はデータウェアハウスを中心にしています。

データウェアハウスには多くのコンポーネントがあり、それは単なるデータベースではありません。

データベースは、データを保存するための媒体です。
データウェアハウスはそれを超えて、データからビジネス価値を引き出すために必要なツールとコンポーネントを含み、統合パイプライン、データ品質フレームワーク、視覚化ツール、さらには機械学習プラグインなどのコンポーネントを含めることができます。

これは、データベースとデータベースウェアハウス構造の違いをより視覚的に表したものです。データベースまたはHiveなどの新しい論理データメタストアは、他のすべてのコンポーネントを回転する惑星として、データウェアハウスの恒星系の中心的な星を形成します。ただし、スターシステムとは異なり、データウェアハウスには1つ以上のデータベースを含めることができ、これらのデータベースは、この記事の後半で説明するように、新しいテクノロジーと交換可能である必要があります。

最初のデータウェアハウスの原則：データ品質が最高に君臨する

データウェアハウスは、内部のデータがビジネスの利害関係者によって信頼されている場合にのみ有用で価値があります。これを確実にするには、データ品質の問題を自動的にキャプチャして修正するフレームワークを構築する必要があります（可能な場合）。データクレンジングは、定期的なデータ監査を伴うデータ統合プロセスの一部である必要があります。または、データの問題を特定するためにデータプロファイリングが実行されます。これらの予防的措置が実施されている間、不良データがこれらのゲートをすり抜けてユーザーから報告された場合の事後措置も考慮する必要があります。

データウェアハウスシステムに対するユーザーの信頼を確保するために、ビジネスユーザーによって強調表示された不良データを優先的に調査する必要があります。これらの取り組みを支援するために、データ系統とデータ制御フレームワークをプラットフォームに組み込んで、サポートスタッフがデータの問題を迅速に特定して修正できるようにする必要があります。ほとんどのデータ統合プラットフォームは、MS SQL ServerのDQSやInformaticaのIDQなど、ある程度のデータ品質ソリューションを統合します。

データ統合パイプラインで商用ツールを使用している場合は、これらの組み込みプラットフォームを利用してください。ただし、追加またはその他の方法で、データの品質を維持するのに役立つメカニズムを構築してください。たとえば、ほとんどのデータ統合ツールには、データ系統を追跡するための優れた機能がありません。この制限を克服するために、一連の制御テーブルを使用してカスタムバッチ制御フレームワークを構築し、システム内で発生するすべてのデータフローを追跡できます。

プラットフォーム内で品質の低下に遭遇した場合、ビジネスの利害関係者の信頼を取り戻すことは非常に困難であるため、データ品質フレームワークへの先行投資はコストに見合う価値があります。

2番目のデータウェアハウスの原則：三角形を反転する

この図は、ほとんどのデータウェアハウスの実装と使用における取り組みの分割を示しています。

ほとんどの努力は倉庫の構築と維持に投資されますが、ビジネス分析のための倉庫を持つことの付加価値は努力のはるかに小さな部分です。これが、ビジネスインテリジェンスプロジェクトが失敗することが多いもう1つの理由です。プロジェクトサイクルでクライアントに意味のある価値を示すのに時間がかかりすぎる場合があります。システムが最終的に導入された場合でも、ビジネス価値を引き出すには多くのIT作業が必要になります。冒頭で述べたように、ビジネスインテリジェンスシステムの設計と展開は、費用と時間がかかるプロセスになる可能性があります。したがって、利害関係者は、ビジネスインテリジェンスとデータウェアハウジングの取り組みによって付加価値をすぐに享受し始めることを当然期待します。付加価値が実現しない場合、または結果が実際の価値を得るには遅すぎる場合、プラグを引っ張るのを止めることはあまりありません。

データウェアハウス開発の2番目の原則は、ここに示すように三角形を反転させることです。

ビジネスインテリジェンスツールと導入するフレームワークの選択では、ウェアハウスに投入される作業の大部分が、ビジネス価値を構築および維持することよりも抽出することであることを確認する必要があります。これにより、プロジェクトへの投資の価値がすぐにわかるため、ビジネスの利害関係者からの高いレベルの関与が保証されます。さらに重要なことは、ITに強く依存することなく、ビジネスが価値を引き出すのに自給自足できるようにすることです。

ウェアハウスを構築する際に段階的な開発方法論に従うことで、この原則を順守し、本番機能を可能な限り迅速に提供できるようにすることができます。キンボールのデータマート戦略またはリンステットのデータボールトデータウェアハウス設計手法に従うことで、変化をスムーズに考慮しながら段階的に構築するシステムを開発できます。 MSSSASキューブやBusinessObjectsUniverseなどのプラットフォームでセマンティックレイヤーを使用して、データにわかりやすいビジネスインターフェイスを提供します。前者の場合、ユーザーがExcelからデータをクエリするための簡単なメカニズムも提供します。これは依然として最も人気のあるデータ分析ツールです。

TableauやPowerBIなどのセルフサービスBIを擁護するBIツールを組み込むと、SQLを作成するのではなく、データをクエリするためのインターフェイスが大幅に簡素化されるため、ユーザーエンゲージメントの向上にのみ役立ちます。

データベースにデータを入力する前にソースデータをデータレイクに保存すると、オンボーディングプロセスの非常に早い段階でソースデータをユーザーに公開するのに役立ちます。少なくともビジネスクォンツなどの上級ユーザーは、ファイルの上にHive / Impalaなどのツールを接続することで、ソースデータを（生のファイルを介して）ダイジェストできるようになります。これにより、企業が新しいデータポイントを分析するのに必要な時間を数週間から数日、さらには数時間に短縮できます。

3番目のデータベースウェアハウスの原則：プラグアンドプレイ

データは、石油のデジタル版になりつつあります。近年、データウェアハウスプラットフォームの一部として使用できるツールの数とイノベーションの速度が爆発的に増加しています。現在利用可能な無数の視覚化ツールが主導権を握っており、バックエンドの高度なオプションがすぐ後ろにあります。この環境とビジネス要件が絶えず変化する傾向を考えると、ビジネスとテクノロジーの変化に応じて、テクノロジースタックのコンポーネントを交換したり、時間の経過とともに他のコンポーネントを導入/削除したりする必要があることを覚えておくことが重要です。

個人的な経験に基づくと、プラットフォームがなんらかの大きな変更なしに12か月続くことができれば幸いです。これらの状況では、合理的な量の努力が避けられません。ただし、テクノロジーや設計を変更することは常に可能である必要があり、プラットフォームはこの最終的なニーズに対応するように設計する必要があります。倉庫の移行コストが高すぎる場合、企業は、既存のソリューションを新しいツールに移行することを検討する代わりに、コストが正当化されないと判断し、構築したものを放棄する可能性があります。

考えられるすべての将来のニーズに応えるシステムを構築することは不可能です。したがって、データウェアハウスを構築する際には、現在設計および構築しているものを時間に置き換えることができるというある程度の認識が必要です。この目的のために、プラットフォームを実行中のツールに緊密に結合するのではなく、可能な場合は汎用ツールと設計の使用を推奨します。もちろん、これは慎重な計画と検討の後に行う必要があります。多くのツール、特にデータベースの能力は、それらの個性と密接な補完関係にあるためです。

たとえば、PythonまたはSSISを使用してデータベースの外部でデータを抽出および処理するのではなく、データベース内のストアドプロシージャを使用して新しいビジネス分析データを作成すると、ETLのパフォーマンスが大幅に向上します。レポートレイヤーに関しては、視覚化ツールは他のツールではすぐに利用できない特定の機能を提供します。たとえば、Power BIはカスタムMDXクエリをサポートしますが、Tableauはサポートしません。私のポイントは、ストアドプロシージャの廃止や、システム内のSSASキューブやTableauの回避を提唱することではありません。私の意図は、プラットフォームをツールに緊密に結合するという決定を正当化する際に注意を払うことの重要性を促進することだけです。

もう1つの潜在的な陥没穴は、統合レイヤーにあります。 SSISのようなツールは、デバッグ機能やSQL Serverプラットフォームでの使いやすさから、データ統合に非常に簡単に使用できます。ただし、何百ものSSISパッケージを別のツールに移行すると、非常に費用のかかるプロジェクトになります。主に「EL」を実行している場合は、汎用ツールを使用して処理を実行することを検討してください。 PythonやJavaなどのプログラミング言語を使用して1つの汎用ローダーを記述し、ステージングレイヤーをロードすると、他の方法で必要となる個々のSSISパッケージを削減するのに役立ちます。このアプローチは、メンテナンスと将来の移行コストを削減するだけでなく、新しい個別のパッケージを作成する必要がなく、データオンボーディングプロセスのより多くの側面を自動化するのに役立ちます（原則2に準拠）。

これらすべての場合において、変更を処理できないため、または変更に時間がかかりすぎたために倉庫が廃棄されないようにするために、当面のメリットと将来の移行コストの間の実際的な妥協点を決定する必要があります。努力、または投資。

まとめ

特定のビジネスインテリジェンスシステムが失敗する理由はたくさんあります。また、最終的な失敗につながる可能性のある一般的な見落としもあります。絶え間なく変化するテクノロジー環境、運用システムの二次的な優先順位の誤解によるデータシステムの予算の制限、データの操作の複雑さと困難さは、設計と将来の計画を慎重に検討する必要があることを意味します。データウェアハウスのコンポーネントを構築します。

この記事で概説されているデータウェアハウジングの基本は、これらの重要な考慮事項を作成する際のガイドとして役立つことを目的としています。もちろん、これらの原則を考慮に入れることは成功を保証するものではありませんが、失敗を回避するのに役立つことは確かです。