第8章 8-4 / データエンジニアリング

データ蓄積とクラウド

このページで学ぶこと

整理したデータは、次に「どこに蓄積するか」を決める必要があります。このページでは、DWHアプライアンスへの接続とテーブル結合、HadoopやSparkによる分散処理の基本、NoSQLデータストアへのAPIアクセス、クラウドのオブジェクトストレージ、そして集中型データ基盤と分散型データ基盤の設計思想の違いという、データを貯める場所の選び方を整理します。

「DWH」「NoSQL」「データレイク」といった言葉が次々出てきますが、どれも突き詰めれば「大量のデータをどんな倉庫に、どんなルールで保管するか」という話です。倉庫の種類と使い分けをイメージしながら読み進めましょう。

1. データウェアハウス(DWH)とアプライアンス

企業が持つ大量のデータを分析用に整理して蓄積する仕組みをDWH※1(データウェアハウス)と呼びます。日々の業務で使う基幹システムのデータベースとは別に、分析専用にデータを集約・整理しておく「倉庫」のような場所です。

DWHを構築する方法の一つに、専用のハードウェアとソフトウェアがセットになったDWHアプライアンスがあります。Oracle Exadata Database MachineやIBM Integrated Analytics Systemといった製品が代表例です。これらは大量データの集計・結合処理に特化した設計になっており、SQLなどを使って複数テーブルを結合したデータを抽出し、分析に活用します。

EXAMPLE
  • DWHに接続し、「顧客テーブル」「注文テーブル」「商品テーブル」を結合して、顧客ごとの購買傾向データを抽出する
  • 複数店舗のPOSデータをDWHに集約し、全社横断で売上を分析できるようにする
  • 基幹システムには影響を与えず、DWH側だけで重い集計処理を行い、業務システムの動作を邪魔しない
POINT

DWHは「日々の業務データベース」とは別の場所に、分析用にデータを整理して集めるという発想が肝心です。業務システムに直接重い分析クエリを投げると、通常業務に支障が出かねません。

さえちゃん
さえ

DWHは「分析専用の倉庫」ってイメージすると覚えやすいよ。お店の在庫(業務データ)と、分析用にまとめた資料室(DWH)は別々に持っておく、という感じだね。

2. HadoopとSparkによる分散処理

データの量が非常に大きくなると、1台のコンピュータでは処理しきれなくなります。そこで登場するのが分散処理※2です。1つの大きな仕事を複数のコンピュータ(ノード)に分担させ、それぞれが同時並行で処理することで、全体の処理時間を短縮する仕組みです。

分散処理の代表的な技術がHadoop※3とSpark※4です。Hadoopは、大量のデータを複数のサーバーに分散して保存する仕組み(HDFS)と、分散したデータを並列に処理する仕組み(MapReduce)を組み合わせた基盤です。Sparkは、Hadoopの後継として登場した処理エンジンで、データをできるだけメモリ上で処理することで、Hadoopより高速に分散処理を行えるのが特徴です。

EXAMPLE ― 分散処理のイメージ
  • 1人で1000冊の本を数えるのは大変だが、10人で100冊ずつ数えれば10分の1の時間で終わる ― これが分散処理の基本発想
  • 数テラバイトのアクセスログを、複数サーバーに分けて同時並行で集計する
  • Sparkを使い、大量の取引データをメモリ上で高速に集計し、リアルタイムに近い分析結果を得る
技術 特徴
Hadoop 大量データの分散保存(HDFS)と分散処理(MapReduce)の基盤。ディスクを介した処理が中心
Spark データをメモリ上で処理することで高速化した分散処理エンジン。Hadoopと組み合わせて使われることも多い
POINT

分散処理の本質は「1台の高性能コンピュータ」ではなく「多数の普通のコンピュータの力を合わせる」という発想です。この基本構成(複数ノードでの分担処理)を理解しておけば、Hadoop・Sparkの細かい仕様を丸暗記しなくても試験に対応できます。

3. NoSQLデータストアへのアクセス

DWHや通常のデータベースの多くは、行と列が整った表形式(リレーショナルデータベース)を前提にしています。しかし、SNSの投稿データやセンサーの時系列データなど、必ずしも表形式にきれいに収まらないデータも増えてきました。そうしたデータを柔軟に扱うために使われるのがNoSQL※5データストアです。

NoSQLの代表例には、Cassandra、MongoDB、CouchDB、Amazon DynamoDB、Azure Cosmos DB、Google Cloud Firestoreなどがあります。これらは表形式に縛られず、キーと値のペアや、文書(ドキュメント)単位でデータを柔軟に保存できるのが特徴です。多くのNoSQLサービスはAPIを介してアクセスする形をとっており、プログラムからAPIを呼び出すことで新規データの登録や取得を行います。

EXAMPLE
  • スマートフォンアプリのユーザー設定情報を、項目数がユーザーごとに異なる形でMongoDBに保存する
  • IoTセンサーから送られてくる時系列データを、DynamoDBにAPI経由で逐次登録する
  • チャットアプリのメッセージ履歴を、Firestoreにドキュメント単位で保存・取得する
さえちゃん
さえ

「No」がついてるから「SQLを使わない」って意味に思われがちだけど、正しくは「Not only SQL」。表形式だけに縛られない、という柔軟さがポイントだよ。

4. クラウドのオブジェクトストレージ

画像・動画・ログファイルなど、さまざまな種類のデータを、容量を気にせず低コストで保存できる仕組みとして広く使われているのがオブジェクトストレージ※6です。代表例に、Amazon S3、Azure Blob Storage、Google Cloud Storage、IBM Cloud Object Storageがあります。

オブジェクトストレージは、フォルダ階層で管理する従来型のファイルサーバーとは異なり、データを「オブジェクト」という単位で保存し、それぞれに一意の識別子(URLのようなもの)を割り振って管理します。プログラムやツールから接続してデータを格納・取得する操作は、DS検定リテラシーレベルでも必須級のスキルとされています。

EXAMPLE ― オブジェクトストレージの活用
  • Amazon S3に、日次で出力されるログファイルをバケット(保存領域)単位で自動アップロードする
  • Google Cloud Storageに、機械学習の学習用画像データセットをまとめて保存する
  • Azure Blob Storageから、分析用にダウンロードしたCSVファイルをPythonで読み込んで処理する
POINT

オブジェクトストレージは、安価・大容量・耐障害性に優れる一方、細かい検索や更新には不向きです。「とりあえず大量のファイルを安全に置いておく場所」というイメージで捉えると使い分けがしやすくなります。

5. 集中型データ基盤と分散型データ基盤の違い

企業全体でデータ基盤を設計するとき、大きく分けて2つの設計思想があります。ひとつは、DWHやデータマートのように、データを一箇所に集約して管理する集中型の考え方です。もうひとつは、データファブリック※7やデータメッシュ※8のように、各部門がそれぞれ自分たちのデータに責任を持ちながら、必要なときに横断的につなげる分散型の考え方です。

集中型は、データを一箇所にまとめるため統制がとりやすい一方、組織が大きくなるほど「すべてのデータを1つのチームで管理しきれない」というボトルネックが生まれやすくなります。分散型(データメッシュなど)は、各事業部門がそれぞれ自分たちのデータを「製品」として責任を持って提供し合う発想で、大規模で事業部門が多い組織に向いています。どちらが優れているというものではなく、組織構造やユースケースに応じて適切な設計思想を選ぶことが重要です。

設計思想 考え方 向いている組織・場面
集中型(データマート/DWH) データを一箇所に集約し、専門チームが統制・管理する 規模が中程度で統制を重視する組織
分散型(データファブリック/データメッシュ) 各部門がそれぞれのデータに責任を持ち、横断的に連携する 事業部門が多く大規模・多様なニーズを持つ組織
さえちゃん
さえ

集中型は「1つの図書館にすべての本を集める」、分散型は「各部署の本棚をネットワークでつなげる」イメージ。どっちが正解というより、組織の規模と目的で選ぶ話なんだよね。

まとめ

このレッスンでは、データをどこに、どう蓄積するかという選択肢を見てきました。最後に振り返っておきましょう。

  1. DWHアプライアンス ― Oracle ExadataやIBM Integrated Analytics Systemなどに接続し、複数テーブルを結合したデータを抽出できる
  2. Hadoop/Sparkの分散処理 ― 複数のコンピュータで処理を分担する分散処理の基本的な仕組みと構成を理解する
  3. NoSQLデータストア ― Cassandra、MongoDB、DynamoDBなどにAPIを介してアクセスし、新規データを登録できる
  4. クラウドのオブジェクトストレージ ― Amazon S3などのオブジェクトストレージサービスに接続し、データを格納できる(必須項目)
  5. 集中型/分散型データ基盤 ― データマート・DWHとデータファブリック・データメッシュの設計思想の違いを理解し、適切に選択する

次のレッスンでは、蓄積したデータをフィルタリングや結合、変換によって使える形に整える「データ加工の技術」を扱います。

脚注 ─ 用語解説
  1. DWH(データウェアハウス) … 分析用にデータを整理・集約して蓄積する、業務データベースとは別の「分析専用の倉庫」にあたる仕組みのこと。↩
  2. 分散処理 … 1つの大きな処理を複数のコンピュータに分担させ、同時並行で実行することで処理時間を短縮する仕組みのこと。↩
  3. Hadoop … 大量データを複数サーバーに分散して保存・処理するためのオープンソースの分散処理基盤のこと。↩
  4. Spark … データをメモリ上で処理することでHadoopより高速化した、分散処理エンジンのこと。↩
  5. NoSQL … 表形式(リレーショナル)に縛られず、キーと値やドキュメント単位などで柔軟にデータを保存できるデータベースの総称。「Not only SQL」の略とされる。↩
  6. オブジェクトストレージ … データを「オブジェクト」という単位で保存し、一意の識別子で管理する、大容量・低コストなクラウドストレージのこと。↩
  7. データファブリック … 組織内に散らばったデータを、物理的に一箇所へ集約せずに、仮想的に統合してアクセスできるようにする設計思想のこと。↩
  8. データメッシュ … 各事業部門がそれぞれのデータに責任を持ち、データを「製品」として提供し合う分散型のデータ基盤の設計思想のこと。↩