クラウド型のDWH（データウェアハウス）サービスや、ETLツールの普及によってデータ分析基盤の構築は容易になりました。
また扱いやすいツールの誕生によって、現在では非エンジニアでもデータを分析・活用できるようになりつつあります。
しかしこれらのツールを活用してデータの活用を浸透させるには、データエンジニア主導でデータ分析基盤全体を管理していく、データマネジメントが欠かせません。
データマネジメントは、アメリカのデータエンジニアによって17の領域にカテゴリー化されています。（データマネジメント知識体系ガイド 第二版）
そのなかのひとつ、データ分析基盤全体の設計に関わる項目が本記事のテーマ「データアーキテクチャ」です。
本記事ではデータアーキテクチャの構築方法、その際に押さえておきたいポイントを解説します。
データアーキテクチャとは
データアーキテクチャとは、データに対するビジネスサイドのニーズから必要なデータ要件を洗い出し、それを満たすシステムやデータの流れを設計することです。
データアーキテクチャを主導する役割をデータアーキテクトといいます。
データアーキテクチャなしに、ユーザーの求めるままにデータ分析基盤を導入してしまうと、
- 同じデータを複数のデータベースで管理してしまい無駄が生じる
- データの管理者が明確でないためデータの品質が低下する
- データの増加によるシステムの拡張を管理しきれない
など、長期に渡って安定的にデータを運用するのが困難になります。
しかしデータアーキテクチャを実施すれば、データの量や質が変化しても安定して運用でき、データ品質の低下にも強くなります。
データアーキテクチャの役割
データアーキテクチャの役割は、データに対するビジネスサイドのニーズと、自社のデータが結びついたデータ分析基盤の設計図となることです。
「ビジネスサイドのニーズと、自社のデータが結びついている」とは、「データの変化（削除・編集）がどのビジネスに影響するのか」が適切に管理できていることを指します。
データが収集され、ビジネスサイドで活用されるまでのデータの流れ（データフロー）を明確に設計し、それに沿った最適なデータベース・システムの配置が可能です。
データアーキテクチャとデータメッシュとの関係性
データアーキテクチャに関連し、近年データエンジニアの分野で「データメッシュ」のワードが注目されています。
従来のデータ分析基盤は、データベースをエンジニアが管理する中央集権型のデータアーキテクチャが主流でした。
データメッシュとは、データアーキテクチャのパターンのひとつで、中央集権型アーキテクチャの課題に対応するために考えられた分散管理型のデータアーキテクチャです。
くわしくは以下の記事で解説しているため、この機会にぜひご覧ください。
データアーキテクチャの設計に必要な要素と成果物
データアーキテクチャの設計は下記の4つの要素に分けて考える必要があります。
- ビジネス
- データ
- アプリケーション
- テクノロジー
このうち、「アプリケーション」「テクノロジー」の2つは、「データ」の要件を満たす具体的な技術要件と言い換えられます。そのため大きく「ビジネス」と「データ」の2つに分けて考えられます。
この2つの観点からデータの要件を洗い出し、データモデルとデータフロー図という成果物にまとめるのが、データアーキテクチャの最終的なゴールです。
エンタープライズ・データモデル
具体的なデータの流れをデータフロー図にまとめる前段階として、データベース全体を大まかに設計してエンタープライズ・データモデルを作成します。
エンタープライズ・データモデルは、実際にシステムを実装する際のことはあまり意識しません。データベース全体の構造が、ひと目でわかるようなモデルであることが理想的です。
まずはデータを必要とするビジネスサイドの部署・部門を書き並べ、彼らがアクセスしているデータベースを線でつないでみる簡単なモデルから始めるのが有効でしょう。
複雑化した現状のモデルをなるべく管理しやすく、シンプルなモデルに再構築していく作業を通じてエンタープライズ・データモデルが作成できます。
データフロー図
大まかに策定したエンタープライズ・データモデルを具体化したデータフロー図を作成します。データアーキテクチャの実装とは、正確にはデータフロー図の実装を指します。
データのフロー（流れ）のとおり、
- データがどこで収集され
- どのデータベースに格納され
- どこへ運ばれていくのか
を詳細に書き出していきます。
データフロー図の書き方に決まりはありませんが、一般的にはER図を利用するのがよいでしょう。
ER図を例にしますが、各エンティティの横に追記するような形で、ビジネス要件・データ要件を書き入れていきます。
たとえば法的観点では、「個人情報は利用終了後ただちに削除する必要がある」というビジネス要件があります。しかしそのデータを引き続き参照したいセールス部署にとっては、データが削除されてしまうと必要なデータ要件を満たせません。
そこで個人情報の一次データは法務の要件に従って削除しつつ、氏名などのデータをカットした二次データを作ります。セールス部署には二次データを参照してもらうなど、各部署の要件を満たせる具体的なデータフローを設計していきます。
データアーキテクチャを構築する前に社内データの全体像を把握しよう
データアーキテクチャの構築は、理想的なデータベース全体を概観できるモデルがあること、そのモデルを具体化したデータフロー図という成果物がゴールです。
しかし現実には、ゼロからデータアーキテクチャに基づいてデータベースを実装することはありません。大なり小なり、すでにデータを利用している現状の改善からスタートするのが一般的になります。
先述のデータメッシュのように、パターン化されたアーキテクチャは存在しますが、それを無理やり自社に当てはめようとすると既存アーキテクチャとのズレが大きく、既存業務が混乱し、実装に失敗してしまう可能性があります。
現状のデータ基盤を効果的に改善するには、ビジネスサイドのニーズを吸い上げるとともに、社内のデータベースの全体像を把握し、既存のアーキテクチャを活かすような改善を目指すことが有効です。
データアーキテクチャを構築するまでの手順
先述のエンタープライズ・データモデルとデータフロー図に基づき、データアーキテクチャを実装していく具体的な手順を確認します。
以下の手順に沿ってアーキテクチャを構築し、データマネジメントが行き届いた理想的なデータ分析基盤の土台を構築していきましょう。
またデータアーキテクチャの構築・改善は、データエンジニアチームのみの取り組みではなく、組織体制にも変化を求める取り組みになります。
どのようなステップでデータアーキテクチャを改善していくかは、経営層や各部門のトップにも共有しておく必要があるでしょう。
現状のデータベース設計に関するドキュメントの収集
先述のとおり、まずは現状のデータベースの全体像を把握します。
ただし闇雲にデータベースの構造を書き出すのは、効率的な進め方とはいえません。データベースの構造や、データベース内の依存関係をドキュメントにまとめるのが有効です。
一度データフロー図を作成していれば、それを参考に変化した部分を追記するだけで済みます。
しかしデータアーキテクチャを初めて構築する際は、各データベースを開いてどのようなデータが存在して、どのようなフローになっているかを地道に調べていく必要があります。
場合によっては、ビジネスサイドの各部門でのデータの扱いもヒアリングし、漏れなくデータの全体像を把握していきましょう。
業務上で必要なデータ要件の抽出
データベースの全体像が把握できたら、ビジネスサイドのデータユーザーにヒアリングを行い、必要なデータ要件を洗い出します。
ヒアリングして得られたデータ要件は、前の工程で作成した現状の全体像に書き込みます。各データベースに格納されている、それぞれのデータに求められる要件を明確にします。
またデータ要件を書き込み明確にしていく過程で、「収集はされているが実際は誰も活用していないデータ」の存在も明らかになるかもしれません。
誰も活用していないデータは「結局何のためのデータかわからず、後になると消すに消せない」「データベースの運用コストを上げてしまう」などの不便を発生させます。
タイミングを見極めてデータを整理すると良いでしょう。
データベースの全体像に、ユーザーが求めるデータ要件が加わることで、現状の保有データとビジネスサイドのニーズとの結びつきに対する理解が深まります。
データアーキテクチャの設計
次は明確になった現状のデータアーキテクチャをふまえ、改善されたアーキテクチャを設計するステップです。
先述のエンタープライズ・データモデルとデータフロー図の作成が、本章の工程に該当します。
具体的な手順はすでに解説したとおり、まずは改善後のアーキテクチャを大まかにまとめ、エンタープライズ・データモデルを作成。
作成したモデルに基づいて、データ要件を漏らさずデータフロー図に落とし込んでいきます。
組織体制の構築と実行
スケールアップが前提のデータ基盤を少数のデータエンジニアのみで、管理・運用していくのは有効ではありません。
ビジネスサイドの責任者にも協力を仰ぎつつ、各データの責任者を決めるなど、設計したデータアーキテクチャを運用する組織体制の構築が必要です。
このとき参考にしたいのが先述のデータメッシュの4原則のひとつ、「プロダクトとしてのデータ」です。
単にデータを収集されたまま基盤に取り込めばデータに対する責任が果たされるのではなく、そのデータが活用されていくことを意識して使いやすいデータを提供する「プロダクトとしてのデータ」を実現する組織体制を作ることでアーキテクチャの円滑な運用にも役立ちます。
組織体制にも関わるデータマネジメントはこちらの記事でも触れています。
ぜひこの機会にご覧ください。
データマネジメントとは？必要性や成功に欠かせない前提条件、参考事例を解説
データアーキテクチャを構築する際のチェック項目
高度なデータアーキテクチャを構築するには、「変化に強いアーキテクチャか」という観点をもつことが重要です。
データニーズが変化するなか、現状の改善に主眼をおいた場当たり的な改修を実施すると、いずれデータアーキテクチャの改善が必要になってしまうからです。
企業が取り扱うデータ量は増加の一途を辿っており、取り巻く環境の変化に応じて社内のデータニーズは絶えず変化します。その変化に対応していくためにも、本章で紹介する項目を確認してください。
膨大なデータを扱う場合は分散型アーキテクチャを活用する
増え続けるデータ量にも対応できる高いスケーラビリティを備えたデータアーキテクチャを構築するひとつの手は分散型のアーキテクチャを取り入れることです。
代表的な分散型アーキテクチャのデータメッシュでは、データの管理責任をエンジニアから各部署・部門に移管することで、データ品質を落とさず膨大なデータを扱えるように設計されています。
今後、より多くのデータを取り扱いたいと考えている企業は、部分的にでも分散型のアーキテクチャを取り入れてみてはいかがでしょうか。
非エンジニアでも使えるツールの導入を検討する
ユーザーのニーズの変化に対するボトルネックは、ユーザーの欲しいデータに対して準備を担うデータエンジニアが絶対的に不足してしまうことです。
しかし冒頭の導入分で述べたように、近年は非エンジニアでも扱いやすいツールが登場しています。ツールをアーキテクチャに組み込むことで、データエンジニア不足のボトルネックを解消できます。
たとえば、非エンジニアでも利用できるツールのひとつにETLツールがあります。
従来ETLはエンジニアが膨大な工数をかけて構築していましたが、現在はETLツールにより画面上の設定のみで誰でも構築可能になりました。
ツールを活用してエンジニアに依存しないデータ活用ができるようになると、ビジネスサイドはアイデアを思いついたらすぐデータを分析・活用できるようになります。時代の変化に素早く対応するためにも、非エンジニアでも使えるツールの導入を検討してみてください。
まとめ
最適なデータ分析基盤に欠かせないデータの設計図、「データアーキテクチャ」の役割や作り方の手順を解説しました。
データアーキテクチャの構築は地道な作業が多く、中長期に渡る取り組みになります。しかしデータ運用の効率を大きく高める効果があるため、ビジネスにデータを活用していきたい企業にとっては欠かせないステップです。
自社のデータ運用に課題を感じている企業の担当者の方は、ぜひデータアーキテクチャの構築を検討してはいかがでしょうか。
弊社はデータ分析基盤の総合支援サービスtrocco®を提供しています。分散型アーキテクチャに欠かせない各部署・部門主導の「セルフサービス型データ基盤」を強力にサポートするツールです。
データの連携・整備・運用を効率的に進めていきたいとお考えの方や、プロダクトにご興味のある方はぜひ資料をご覧ください。
