[リレー連載]DX推進を支えるバッチ処理（2）-データ統合処理-

こんにちは。アシストでデータ連携製品の技術を担当している島尻です。

バッチ処理にフォーカスした連載ブログを通して、宮本とリレー形式で情報発信させていただきます。

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

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

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

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

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

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

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

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

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

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

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

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

執筆者情報：

島尻 龍一 　(しまじり りゅういち)
株式会社アシスト DX推進技術本部 デジタル推進技術統括部 DI技術部

2019年株式会社アシストに入社。
入社以来、ETL/EAI製品の担当部署で 「Precisely Connect」「DataSpider」「HULFT」のフィールドエンジニアとして活動中。
趣味は「かな書道」。