Keep up with the latest announcements from Google Cloud Next '21. Click here.

データ分析

データ処理に関する組織の分類における自組織の位置づけを確認する

#da

※この投稿は米国時間 2021 年 9 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

データにまつわる文化と能力は、組織によって異なります。それでも、他組織と同様のテクノロジーのトレンドとソリューションを、同じようなやり方で利用することが期待されがちです。お客様の組織では何年にもわたってレガシー アプリケーションを活用し、ご自身でも膨大な量の専門技術と知識を身に付けてきたかもしれません。それにもかかわらず、テクノロジーのトレンドに基づいた新たなアプローチを採用するよう指示されることがあるでしょう。一方、それとは対極的な、エンジニアリング原理に基づきゼロから構築された、レガシー システムのないデジタル ネイティブな組織もあります。もしかするとお客様もそのような組織にいるのにもかかわらず、プロセス ドリブン型の確立された組織と同じ原理に従うよう期待されるかもしれません。疑問となるのは、これらの異なる組織のデータ処理は同じ手法で扱われるべきなのだろうか、ということです。このブログとホワイトペーパーのシリーズでは、この、テーマつまり、データ アナリスト、データ エンジニアリング、データ サイエンスそれぞれの観点による原理から組織を整備する方法を探求します。実際には、それらのいずれか 1 つしか使われていない組織はありません。ほとんどの場合、複数の原理が組み合わせて使われます。そして、自分の組織がどのような組織になるかは、それぞれの原理からどれほど影響を受けるかによります。

データ処理テクノロジーでカバーする範囲を検討する際には、一度冷静になり、重要な目標についてよく考えたうえで戦略的決定を下すべきです。これには、パフォーマンス、費用、運用オーバーヘッドの削減、業務遂行における優位性の拡大、新たな分析アプローチと機械学習アプローチの統合などを考慮に入れて最適化するかどうかといったことが含まれるでしょう。あるいは、お客様はデータ ガバナンスと規制要件すべてを満たしつつ、今いる従業員のスキルを活用する方法をお探しかもしれません。このシリーズでは、こうしたさまざまなテーマを探求するとともに、それぞれのテーマがどのように意思決定プロセスに影響するのかを論じます。お客様は今まで、過去の問題を解決してきたテクノロジーを活用されていて、そうしたテクノロジーの用語の方がなじみ深いと感じるかもしれません。しかし、そうしたテクノロジーは、組織の能力を伸ばしてはくれません。また、レガシーによる機会費用や、トランスフォーメーションへの取り組みによって生じる新たな問題もあります。その結果、変化し続けるテクノロジー情勢に追いつこうと新しいイニシアチブに取り組んでいるうちに、中核的な事業での遅れが拡大する可能性もあります。

データ バリュー チェーン

取り込み・変換ツールにとって重要なのは、ソースからデータを抽出すること、そしてそのデータの意思決定への活用を可能にすることです。最終目標は、データの複雑性を減少させ、適時性を改善することです。データがなければ、データドリブンな組織を構築することも、分析情報に基づく行動もできません。ですから、より優れた意思決定のためには、データの変換、拡充、他のデータソースとの結合、集計が必要になります。言い換えると、タイムリーかつ良質なデータに基づく知見を得ることで、優れた意思決定を実現できるのです。

データ取り込みパイプラインについて決定を行う際、最善のアプローチの一つは、到着するデータの量、データの速度、データの種類を検討することです。管理しているデータソースの数や、汎用パイプラインを使用するソースを数千にまで拡大する必要があるか、1 つの汎用パイプラインを作成してデータ品質ルールとガバナンスを適用する予定があるか、なども検討事項に含まれます。このユースケースには ETL ツールが理想的です。汎用パイプラインを記述してパラメータ化できるためです。

一方、データソースについても検討する必要があります。データは変換や形式設定をせずに直接取り込めるでしょうか?データの変換が不要で、マネージド ソリューションとしてデータ ウェアハウスに直接取り込み可能であれば、運用コストを削減できるだけでなく、データの即時提供も可能になります。データが XML などの非構造化形式や EBCDIC などの形式で到着し、変換と形式設定が必要である場合、データの到着速度によっては ETL 機能のあるツールを使用できます。

データの到着速度とタイミングを把握することも重要です。自社のデータ取り込みプランに関連する SLA と期間について考えてみましょう。これにより、取り込みプロファイルだけでなく、使用するフレームワークも決まってきます。上述したように、ベロシティ要件によって意思決定プロセスが決まります。

組織の種類

組織が成功を収めるには、組織が持つ人材に応じた戦略を採用することが大切です。スポーツの世界で、各チームが勝利という究極の目標に向けて異なる戦略でプレーするのと同様です。

組織ではしばしば、データの取り込みと処理に関して何が最善の戦略であるかに関する決定が必要になります。たとえば、「有用なデータの拡充と変換を行うのに、給料の高いデータ エンジニアのグループを雇用するのか、それともデータ ウィザードと社内のアナリストを活用するのとどちらが良いのか」、「一般に理解された利用可能な基礎構築に注力するのと、機能性と価値の高い作業を増やせるよう既存の従業員に対してトレーニングを実施するのでは、どちらのほうが現実的なのか」といったことです。

一方ご存じのとおり、ETL パイプラインの変換処理の部分で、どこで読み込みが行われるかが決定します。これらすべてが、データが拡充され、集計され、結合されるクラウドネイティブな世界で現実になります。強力な最新のデータ ウェアハウスにデータを読み込むことができれば、それはすなわち ELT を利用したデータの結合と拡充を行うことができるということです。結果として、データをデータ ウェアハウスに直接読み込める場合、ETL は厳密な意味では本当に必要というわけではなくなります。

上記のすべては従来のサイロ化された静的データ ウェアハウスとデータ エコシステムでは不可能でした。システムが互いにやり取りすることはなく、コストの高いデータ ウェアハウスへのデータの保存と処理のどちらについても機能に制約があったのです。これは、BigQuery の世界ではもう問題ではありません。ストレージは安価で、仮想アプライアンスによる制約なしに変換が可能になりました。

ご自分の組織ですでに ETL ツールに多大な投資を行ってきた場合の一つのオプションは、そのツールを使用して BigQuery を読み込んで、ETL ツール内で先にデータを変換することです。現状と今後がマッチすることが検証されたら、向上した知識とエキスパティーズを活用して、ワークロードの BigQuery SQL への移行を開始し、効果的に ELT を実施することができます。

さらに、組織でストアド プロシージャとスクリプトに大きく依存した従来のデータ ウェアハウスを利用していた場合に疑問になり得るのは、引き続きこのスキルとエキスパティーズを活用できるのか、BigQuery でも提供されるこれらの機能を使用できるのかといった点です。BigQuery を利用した ELT はより自然で、既存の Teradata BTEQ、Oracle PL/SQL によるものと似ていますが、ETL から ELT への移行には変更が必要です。この変更により、小売店でリアルタイムに行うものなど、ストリーミングのユースケースが実現します。これは、データを読み込んで使用可能にするのに先立つ処理が不要なためです。

組織は、データ アナリスト ドリブン型、データ エンジニアリング ドリブン型、混合型の 3 種類の組織に大きく分類できます。データ サイエンス ドリブン組織は混合型カテゴリで扱います。

データ アナリスト ドリブン型

アナリストはビジネスを理解しており、SQL やスプレッドシートの使用に慣れています。アナリストが慣れたインターフェースを使用して高度なアナリティクスを実施できるようにすると、より大きな規模でのデータ活用が可能になります。結果として、ターゲット システムに迅速にデータを取り込める使いやすい ETL ツールが、重要な推進力になります。ソースまたはステージング エリアからデータを直接取り込むことも重要です。これにより、アナリストが ELT を使用するスキルを活用して、データの即時性を向上させることができるためです。これは従来の EDW では当然のことで、ストアド プロシージャとスクリプトを利用する拡張機能で実現されています。データは SQL を使用して拡充、変換、クレンジングされ、ETL ツールはオーケストレーション ツールとして動作します。

クラウド コンピューティングによって実現したデータとコンピューティングの分離機能は EDW の様相も一変させます。従来のような複雑な取り込みパイプラインを作成することではなく、データをクラウド近くに用意し、ストレージ バケットまたはメッセージング システムにステージングしてから、クラウド EDW に取り込むことが取り込み機能の重点となります。これによりデータ アナリストを単純作業から解放し、使い慣れたツールとインターフェースを使用してデータ インサイトの検討に注力できるようにします。

データ エンジニアリング ドリブン型 / データ サイエンス ドリブン型

複雑なデータ エンジニアリング パイプラインの構築にはコストがかかりますが、向上した機能が利用できます。これにより、繰り返し可能なプロセスを作成し、ソースの数をスケーリングできます。クラウドによって補完されると、アジャイル データ処理手法を利用できるようになります。一方データ サイエンス組織では、実験の実施、あるいは特定のユースケースで役立つものの、製品化や一般化されたりすることがあまりないアプリケーションの制作が可能です。

リアルタイム解析は即時対応を可能にします。また、低レイテンシの異常検出アプリケーションを実行する必要がある特定のユースケースがあります。言い換えると、データ到着時にその場で対処を行う必要があるというようなビジネス要件です。この種のデータまたはアプリケーションの処理には、ターゲット外部で行われる変換が必要です。

上記のどの場合でも通常はカスタム アプリケーションと最新鋭のツールが必要であり、これを実現できるのはエンジニアリング能力が卓越した組織に限られます。実際には、本当の意味でのエンジニアリング組織は非常に少数です。多くの組織は、ここで混合型と呼んでいるタイプです。

混合型組織

上記の分類は各プロジェクトでのツール選択時に活用できます。たとえば、単一のツールを選択するのではなく、適切なワークロードに対して適切なツールを選択します。そうするほうが運用コストとライセンス コストが削減され、利用可能な最高のツールを使用できるからです。決定因子はビジネス要件から導き出されるようにします。各事業部門またはチームは、価値あるビジネス インサイトを取得するために自分たちが接続する必要があるアプリケーションを知っています。このように、組織のデータ成熟度を考慮することは、適切なデータ処理ツールを適切に活用することを確実にするうえで重要です。

実際の組織は、ご自身のものも含め、ある分類にぴったり当てはまることは少なく、連続したスペクトラムのどこかに位置しているものと思われます。デジタル ネイティブな組織はその文化とビジネスのため、エンジニアリング ドリブン型に近いと考えられます。一方、従来型の組織は多数のレガシーなシステムとプロセスを抱えているため、アナリスト ドリブン型に近いと考えられます。このような組織は、Google のようなデータ エンジニアリングまたはソフトウェア エンジニアリングの利用を目指して、デジタル トランスフォーメーションを検討中または取り組み中のどちらかです。

データ エンジニアリングに関連して強力なスキルのあるブレンド型組織では、プラットフォームやフレームワークを構築して再利用可能なパターンを増やし、生産性の向上とコスト削減を行ってきたことでしょう。データ エンジニアは Kubernetes 上での Spark 実行に注力します。一方、インフラストラクチャ エンジニアはコンテナに注力します。これによって非常に優れた能力が得られます。アプリケーション開発者はデータ パイプラインに注力し、基礎となるテクノロジーまたはプラットフォームが変わってもコードは同じままです。結果として、セキュリティ上の問題、レイテンシ要件、コスト要件、ポータビリティへの対応が複数のレイヤで行われます。

結論 - ご自身の組織はどこに位置づけられますか?

組織のインフラストラクチャは、高速に変化するテクノロジー情勢に反応できるほど柔軟ではないことが少なくありません。エンジニアリング ドリブン型の組織であっても、アナリスト ドリブン型の組織であっても、組織は技術要件を頻繁に調べ、どのアーキテクチャを実装するかを検討しています。しかし、本当の意味でのデータドリブン組織になるために欠かせないにもかかわらず、よく見落とされる構成要素があります。それは、アーキテクチャによるデータユーザーに対する影響です。責任、スキルセット、そしてデータユーザーの信頼を考慮するとき、ビジネスのみならず IT 部門の必要も満たす、適切なデータ プラットフォームを作成することができます。

本当の意味でのデータドリブン組織になるための第一歩は、技術的なニーズとビジネスのニーズを満たすアナリティクス データ プラットフォームの設計と実装です。各組織には独自性があり、その文化、スキル、能力もそれぞれ異なります。重要なのは、必要なときに組織に適した新しいテクノロジーを採用しつつ、組織の強みを活用して競争優位性を保つことです。

組織に応じたアナリティクス データ プラットフォームの構築方法については、こちらのホワイトペーパーをお読みください。


-          スマート アナリティクスおよび AI 担当ソリューション マネージャー Susan Pierce

-          データ アナリティクス プラクティス リード Dr. Firat Tekiner