- 目次
1.データ分析基盤構築における検討事項
データ分析基盤構築における検討事項を、要件定義、環境構築の2つのフェーズに分け、解説します。
1-1.要件定義
データ分析基盤を効果的に運用するには、適切な要件定義が不可欠です。ビジネス要件を明確にし、必要なデータとシステム要件を整理することで、活用される基盤を構築できます。ここでは、そのポイントを解説します。
1-1-1.ビジネス要件の明確化
まず、データ分析基盤によって実現したいビジネス要件を明確化してから、データ要件・システム要件を整理します。これにより「基盤を構築したのは良いけれど、データ分析者に利用されない」といった事態を回避できます。
ビジネス要件の明確化のためには、データ分析基盤を用いて分析する目的の明確化と、そのデータ分析基盤がどの程度利用されているかを評価するためのKPI設計が求められます(図1)。そうすることで、データ分析基盤の構築・運用・改善を効果的にすすめることができます。
例えば、小売業のECサイトにおいて売上増大を目標とする場合、ユーザーの離脱率減少を分析目的の一つとして、離脱率削減率や顧客生涯価値向上率、ウェブサイトのコンバージョン率などを分析できる環境が必要です。また、データ分析者が利用していく上で、分析者の満足度を測定するためのアンケート調査やデータ参照量・クエリ実行数などの利用状況を把握する仕組みも検討する必要があります。

図1:データ分析基盤の要件定義時にまず検討するべきこと
1-1-2.データ要件の明確化
ビジネス要件が明確化されたら、分析に必要なデータ発生源、データの量、種類、形式、更新頻度などデータソースの明確化を行います。データ量が多い場合は、システム要件を整理する際に、ストレージ容量や処理能力・データ処理方式やデータ分析時の制約として考慮する必要があります。
ECサイトの場合、CRMデータ、取引履歴などの構造化データが多いですが、近年ではソーシャルデータなどの非構造化データを分析するニーズも高まっています。そのため、この段階で非構造化データも収集・蓄積可能な「レイクハウスアーキテクチャ」などの全体アーキテクチャを検討することが重要です。
私が担当した実案件で、レイクハウスアーキテクチャを採用し、DWH層に多量・大容量の構造化データをロードした際に、大量I/O負荷によってETL(Extract, Transform, Load)の性能が十分に発揮できない問題が発生しました。その対策として、データ分析に不要なカラムを削減し、I/O負荷の軽減を試みました。
もし、データ要件を決める段階でデータ処理を意識したデータ整理ができていれば、環境構築の早い段階で性能要件を満たすことができていたはずです。この経験から、データ設計の初期段階での処理性能を考慮する重要性を認識しました。
1-1-3.システム要件の明確化
予想されるデータ量や分析規模に基づき、データ分析基盤に必要な処理能力、ストレージ容量、セキュリティレベルなどのシステム要件を明確にし、サービス選定を通じてアーキテクチャを設計します。近年ではクラウド上にデータ分析基盤を構築するケースが増えており、必要に応じてリソースをスケールアップ/ダウンできるクラウドの特性を生かすスケーラビリティ検討も重要です。
ただし、ベンダーで提供されるマネージド・サービスは導入が容易である一方で、料金が割高に設定に設定される場合が多く、データ処理能力などの性能要件と費用を比較し、長期的な運用を見据えたサービス選定を行うことが求められます。
1-2.環境構築
要件定義に基づき、適切なデータ処理を実現するためには、システム間でデータをやりとりするためのIF(インターフェース)設計や、データの抽出・変換・蓄積を行うETL処理の設計を検討する必要があります。これらの設計ポイントを説明します。
1-2-1.IF設計
IF設計におけるデータの取り込み方式として、バッチ処理、リアルタイム処理、マイクロバッチ処理などがあり、それらを組み合わせてデータの加工・蓄積・分析を自動化するデータパイプラインを設計します。
私が携わった案件ではデータソースからデータ分析基盤にデータ連携する方式をリアルタイム処理で実装していました。しかし、データが発生してからデータソースへ格納されるまでにリードタイムがあったため、実際にはデータ鮮度が十分に高くなく、リアルタイム処理に不要なリソースを割いている状況もありました。
リアルタイムデータは処理コストが高く、データ分析基盤全体の費用増に大きな影響を与える可能性があります。そのため、データ要件に応じて適切なストレージ、データベース、データ処理エンジン、分析ツールを組み合わせる必要があります。
1-2-2.ETL処理設計
近年では、ETLを分散処理として高速に実行できるサービスが台頭していますが、フレームワークを利用したからといって必ずしもETLワークロード全体の処理速度が速くなるとは限りません。設計時には処理性能を慎重に考慮する必要があります。
私が携わったETL機能の性能向上案件では、性能要件を満たすためにApache Sparkを用いて実装されていました。ところが、ワークロード内でデータベース参照時にクエリを1件ずつ発行してデータ取得する処理、いわゆる「ぐるぐるSQL」が実装されていました(図2)。そのためデータ件数が少ないときは問題ありませんでしたが、データ量が増加すると、クエリ発行件数が増大して性能が急激に低下していたのです。
そこで、DBからデータ取得する処理を改修し、データを一括取得する処理に変更したところ、ワークロード全体の性能に大幅な改善が見られました。
このように、ETL処理設計する際には、分散処理を過信せずに、データ処理高速化を意識することが重要です。
ETL処理設計する際には、分散処理を過信せずに、データ処理高速化を意識することが重要です。データ形式の特徴を理解した上で、クエリパフォーマンスの向上を目的としたパーティショニング、インデックス作成、キャッシングなどのパフォーマンス・チューニングを考慮する必要があります。

図2:ETL処理性能が出ない時にありがちな原因
2.まとめ
本稿では、データ分析基盤の構築において特に重要な要件定義と環境構築の工程について、私自身の実案件での経験をもとに解説しました。
クラウドベースのデータレイクハウスは、スケーラビリティやコスト効率、可用性などの面で優れており、オンプレミスと比較して容易にデータ分析基盤を構築できる利点があります。しかしその反面、ビジネス要件が曖昧なまま設計を進めると、利便性の低下や不要なリソース・費用の発生につながるリスクもあります。そのため、ビジネス要件とデータ要件を明らかにし、それに基づいたデータ分析基盤の設計が重要です。
NTTデータは、データ分析基盤のグランドデザインから構築・運用まで一環した支援を提供するとともに、データサイエンスの幅広い領域でお客様をサポートします。