〈開発者ブログ 連載〉Vol.8
～ データの可視化・分析について ～

データ分析・可視化に関する記事の第8回目になります。

前回に引き続き「データ」についての話になります。
構成上は続きになるのですが、こちらが本当に書きたかった記事なので文章量がだいぶ違います。

予告した通り、データエンジニアリングの側面からデータのレイヤーについての話をします。あわせてデータ利活用の内製化が進まない理由についても考察していますので、目を通していただけましたら幸いです。

データは発生した時点の姿から加工を経てBIやMLなどで使われる姿まで、何回か姿を変えていきます。
姿を変える理由は、データがデータとして扱いやすい形でなかったり、何かと掛け合わせて初めて意味が生まれるデータだったりするために、段階的に加工していくからです。
この姿をレイヤーとして定義して、レイヤーごとに物事を考えていきましょうというのがデータレイヤーの考え方になります。

まずは一般的なレイヤーの定義を以下に示します。

一般的と言いながら、各レイヤーの呼び方は誰が言っているかによってバラバラです。
また、レイヤリングの論点も概念の言語化であったりデータ保管の整理のためだったりと様々です。
ただ、結果として整理されたレイヤーはどの場合でも似たり寄ったりですのでまとめて記載をします。

これが一般的な定義になりますが、実務上はRaw Data Layerでは定義が少し粗いように感じますので、Rawのみさらに以下に細分化するのが良いかなと思います。

基幹システムなどから収集したデータはデータ分析基盤から見るとRawデータという扱いになるものの、何かしらの集計や加工を経ていますので本質的にはRawデータではありません。
一方でIoTなどから収集したデータというのは本質的にもRawデータになります。

アーキテクチャとの分離

データレイヤーの話をすると、「Datalake / DWH / Datamartの話ね」という反応を示される方もいますが、
これはアーキテクチャの話ではないので、そこは分離して考えた方が良いかと思います。

たとえば、AggregatedデータをDatalakeのみで保持しているという企業はあまり見たことがありません。
一方でAtomicデータはDatalakeのみに保持するパターン（クエリサービスで直接クエリを投げる）も多いです。

アーキテクチャとデータレイヤーの関係についてマトリクスで表現すると、以下のようなパターンが多いかなと思います。

*1 両方で重複して保持する *2 場合によってどちらで保持するかが異なる

Curated data layerは多くの場合Data-warehouseに配置されますが、整備が進んでくると部署単位などでData-martに配置されることもあります。

少し趣旨がずれますが、アーキテクチャと利用サービスも分離して考えてください。
Data-martをDWHサービスで実現することもありますので、DWHサービスを使っているからといってアーキテクチャとしてのData-warehouseとは限らないことに注意が必要です。

Data-martに何を使うかというのは、どれがベストプラクティスであるか断定できない状態にあります。

• （旧世代のDWHサービスなど）コンカレンシーの問題からRDBを使う
• BIツールなどからの一括データ取得処理のスループットの問題からDWHサービスを使う

どちらも非常によく見かけます。
Snowflakeなど新世代のDWHサービスはウェアハウスを分離できる設計にしたことで、この問題をクリアしています。

世の中の内製化の流れの中でも、とりわけBIという領域は内製化を進めようと考えているお客様が多いです。
IT部門による内製だけではなく、事業部門の内製に踏み込もうとしている話も耳に入ってきます。

こういったときにまず何をするかというと、BIツールのトレーニングを受講します。
BIツールはよくできていますので、基本的な操作自体は難しくはありません。
ところが、実際に現場でデータを扱おうとすると壁にぶつかってしまうんですね。

なぜなら、実業務で扱うデータはトレーニングデータみたいに綺麗なデータではないからです。

実業務で扱うデータ

たとえばAggregatedデータを想像してみてください。
システムで保持しているデータというのは、ユーザーが見やすいようにワイド（横持ち）でデータを持っていたりします。
ところが、BIツールから扱いやすいデータはロング(縦持ち)なので変換(unpivot)が必要になったりします。
これは最も単純な例ですが、このようなデータの持ち方の変換は常に発生します。

重複の排除、データの一意での特定なども頻繁に発生します。
SQLの分析関数(row_number()など)と同様に、ある項目で並び替えたのち最新のものだけを採用する、みたいな判定をいれるパターンですね。
逆にSQLでいうCROSS JOINをわざと発生させてレコードを増幅させないと表現できないような状況もあります。

「事業部門による内製」でこれらをクリアするにはとてもハードルが高いですよね。
従って、内製化を進めるためにはこういった下準備をしておいてあげる必要があります。

つまり、Curated data layer、もしくは、Application data layerのデータ準備が必要です。

Curated data layer/Application data layerの事前整備

ではCurated data layer/Application data layerを最初に整備しておけばいいのかというと、そうではありません。

Curated data layer/Application data layerというのはある程度ニーズがわかってからでないと整備できません。
なぜなら、データ分析基盤の基本的な考え方はSchema on readだからです。
Schema on readというのは、「データを使う側がデータの形を決める」という原則のことです。

そのため、Curated data layer/Application data layer整備のスタートはボトムアップアプローチになります。
ある程度サンプルが揃ってきたタイミングでトップダウンに変えていくことがスピードアップの秘訣になるかなと考えています。

タイミングを考慮をしていないと、使われないCurated data layerの発生や、内製化の停滞などが発生してしまいます。

この連載の中でも何度が言及していますが、DXには成熟度の段階があり、成熟度にあわせてステップを踏むことが必要だと思っています。

どこでボトムアップ/トップダウンを切り替えるか、あるいは、どこまでは自由に進めてどこから統制をとるか。
お客様がDX成熟度のどの段階にいるかによって、私たちからの提案内容も変わってくるはずです。

たとえばデータ利活用においては、モダンデータスタックという概念が急速に台頭してきています。
現時点のモダンデータスタックはDX成熟度が低い企業の初速をあげるには非常に効果的ですが、成熟度が高い企業の要求にすべて答えられるかというと微妙なところです。
機能が不足しているというよりは、隙間に落ちるポイントなんかが発生します。

その隙間を埋めるにはどういうアプローチが考えられるかというと、そこを担うのはiPaaSであることもあればETLツールであることもあるでしょう。
もちろん、ご存知の通りDX成熟度が低い段階でiPaaSやETLが初速をあげるのに有効なパターンも多々あります。
前者と後者では論点が違ってくるので、そこを類型化できないかと考えています。

前回、そして今回とでデータについて整理をしてきました。
過去に書いたデータの品質やデータセキュリティ要件の整理なども併せて、多角的にお客様の状況を整理して最適な提案をするために勉強する日々です。

最後まで読んでいただきありがとうございました。

TOPへ