データアーキテクティングについて
データ基盤ひとりAdventCalendarの5日目の記事になります。
データ基盤に関連した内容について学んだことを@takegue がまとめていきます。

内容については随時加筆/修正等を行なっていく予定です。
修正等の指摘ありましたらご連絡いただけると幸いです。


データ活用を行っていく際の主な関心ごとは
整合性や信頼性、可用性が高くデータを提供しつづける仕組みをいかに実現することにある。
またその仕組みについて、データはサービス横断的な取り扱いを行う性質を行うことから
保守運用も高いことが望ましであろう。
このような要件に対して、種々の技術選択や開発の実施を行うことがデータアーキテクティングの関心ごとである。

データウェアハウシングを進めるにあたって、次のような大きな関心ごとがある

  • データウェアハウジングのアーキテクチャ
  • データ転送のワークフロー管理および開発
  • データモデリングの整備

この記事ではデータウェアハウジングのアーキテクチャについて説明する。

データウェアハウジングのアーキテクチャ


データウェアハウシングとデータレイク

伝統的なデータウェアハウシングにおいては
データウェアハウスデータレイクは独立したコンセプトである。

データレイクは、未加工のデータを保持しておくデータの溜め場である。
非構造化および構造化データに関わらずデータを一元的に集約する目的で利用する。
このような場所を設けることで次の利点が得られる。

  • サービスごとに異なるデータへのアクセス方法の一元化
  • データ提供を行うサービスとの独立し、処理を行うこと
  • 別のサービスへのデータ接続を行う際のハブに利用できる

データレイクでは、非構造化されたデータや構造化されたデータが混合する。
またスキーマの統一を求めないスキーマオンリード(Schema on Read)が根底にあるため
適切なドキュメントによりデータ利用ガイドが不可欠である。

データウェアハウシングにおけるデータウェアハウスでは
データは集計や検索する前提で構造化された形で配置されることが望まれる。
データレイクとの対応するコンセプトとしてステージングエリア(Staging Area)が存在する。
これらはデータレイクと同様にその役割はデータの置き場である。

データレイクとの相違はステージングエリアではスキーマが固定化された状態で
配置するスキーマオンライト(Schema on Write)であることである。
データに対し型などのスキーマ情報が付与されることで利用しやすくなる。