こんにちは。
前回 は、バッチ処理とレガシーモダナイゼーションというテーマでブログを書きましたが、今回はバッチ処理とデータ統合処理という別の切り口から書いていきます。
特に、データ統合処理の文脈で語られることの多い、データウェアハウスやラムダアーキテクチャについて本記事で簡単に確認し、次回の考察にもつなげていこうと思います。

データウェアハウスとデータレイク

まずは情報系システムでよく使われる、データウェアハウス（DWH）とデータレイクについてです。蓄積されるデータの構造という観点で両者の違いを見ていくと、DWHはその後のデータ活用などの目的に応じて構造化されており、データレイクでは構造/非構造は問わないといった違いがあります。

以前は「社内で発生したデータは貯められるだけ貯めた方がいい」「データを貯めないと数年後に分析するためのデータが無くなってしまう」という考えのもと、データレイクに様々なデータをとにかく格納する、という動きがありました。構造/非構造を問わず、多種多様で巨大なデータ群を一か所にまとめて、その後の活用に活かしていこうという、ビッグデータ活用に向けた活動です。

しかし、こうした動きにはすぐに見直しが入りました。活用の見立てがないデータを蓄積しても価値につながりにくい、つまり「品質の悪いデータを使って分析しても、品質の悪い結果しか生み出さない」というガベージインガベージアウト（GIGO）という概念が、データ活用・データ分析の文脈でも語られるようになったのです。そのため、現在では下記のような構想で情報系システムを構築する方がより効果的である、という見方が主流です。

• 活用の仮説がある程度定まっているデータをDWHに貯める
• 仮説がまだ緩いデータは一旦コストの低いデータレイクに貯めておき、データ活用の見立てがついたらDWHに移す

こちらは、DWHとデータレイクのそれぞれの特性に合わせ、よりコストも抑えつつ適切なデータの蓄積場所を決める、という考え方になります。

ラムダアーキテクチャにおけるバッチ処理

ビッグデータを処理するアーキテクチャとしては、「ラムダアーキテクチャ」という設計概念があります。

ラムダアーキテクチャでは、ビッグデータの処理領域を「バッチレイヤー」「スピードレイヤー」「サービスレイヤー」の3層に分けます。バッチレイヤーでは生データをどんどん貯めていき、BI等で分析に活用できるデータをサービスレイヤーにバッチ処理で流します。一方でスピードレイヤーでは、随時発生するストリーミングデータを素早く集計に回すための仕組み作りを行います。

上図の中でも特に、バッチレイヤーとサービスレイヤーを提供する上半分の領域については、どのような業種の企業でも必ず必要な仕組みであり、情報系システムをバックエンドで支える重要なものです。前章の情報系システムについての内容を踏まえると、バッチレイヤーでデータレイクに生データを格納していき、活用の仮説が固まったデータを加工・変換した上でサービスレイヤーのDWHに格納していく、というイメージです。

データ活用に向けたデータ統合処理

ここまで、データ統合処理の文脈で語られることの多い、DWHやラムダアーキテクチャについて簡単に触れてきました。

効果的なデータ活用、ひいてはDXを実現していくにあたり、活用に必要なデータをDWHに蓄積していくためのデータ統合処理が非常に重要な役割を果たします。また、昨今クラウドサービスがその活用領域を広げており、ストレージやDBといったデータの源泉のみならず、DWHもクラウド上に構築するというケースも増えてきています。

データの蓄積場所がどこに存在するにせよ、DXのサイクルを継続的に回していくためには、新しいビジネス要件に対して柔軟に対応できるアジリティが、データ統合処理の基盤には求められます。そのため、データ統合処理の仕組みを属人化させないような形で人財を活用していくことも大事です。

次回の考察に向けて

今回の記事で述べてきたようなデータ統合処理に関わる課題については、前回の連載記事のまとめと同様、すべて運用性、性能、生産性の3つにつながっていきます。

この3要素についてどのように解決していけばよいのか、については次回記事で述べていこうと思います。次回記事では、前回のレガシーモダナイゼーションと今回のデータ統合処理の内容を踏まえて、最適なバッチ処理基盤、統合処理基盤とはどのようなものかを考察していく予定です。

本ブログのスライドは、前回 の連載記事と同様、2022年11月16日開催「DX Insight Winter」講演内容を再構成した資料から抜粋しています。資料は、こちらからダウンロードください。