データ活用基盤の全社公開における問題：データの定義をどう管理するか？

お疲れ様です。ふるさと納税で届いた国産の鶏肉が、まさかのブラジル産で産地偽装されていたらしいShinです。舌が肥えてないので疑いもしませんでした。普通に美味しかったです。

さて、データ活用基盤の検討にあたり「セマンティックレイヤ」と呼ばれる機能層の分離に関する考え方が度々話題に上がります。

本日はデータ活用基盤における蓄積構造の考え方と、データの民主化を実現する上での構造的考え方（つまりセマンティックレイヤの話）について触れていきたいと思います。

データ蓄積における三層構造

さて、企業が社内外のデータを収集してBI（Business Intelligence）やAI/MLを使って分析をするためには、データを集めて保管しておくためのデータ蓄積の仕組みが求められます。

一般的にはデータ蓄積の仕組みは三つの層から構成されます。①データレイク、②データウェアハウス、③データマート、です。私のこのデータ蓄積の仕組みに対する考え方はBI製品を提供するTableauの考え方に基づいていますので、詳しくは以下をご参照ください。

データマートは特定部門に絞ったデータ分析に役立つデータベース

端的に説明すると、データレイクでは収集した生のデータをそのまま保管します。したがってデータベースというより、何でもかんでも放り込むことができるファイルストレージで構成することが一般的です。

データウェアハウスには標準化されたデータを格納します。標準化とは、例えばコード体系であったり、日付のフォーマットであったり、カラムの桁数であったり、複数の異なるデータソースであってもデータの形式が統一されるようにすることを意味します。

データマートは分析のためのデータです。例えばBIでダッシュボードを構築する場合、複数のデータを結合して掛け合わせることでより深い分析が可能になります。特に複数のダッシュボードで同様のデータを使う場合、データマートに分析用のテーブルを用意して共有して使うような方式が考えられます。

データの民主化におけるビジネスサイドの課題

さて、先に上げたデータ蓄積の仕組みを整備し、セルフサービス型BIをビジネスサイド（＝現場部門、ITサイド（情報システム部門やDX部門）ではないことを意味する）に開放したとします。

つまりITサイドがデータ分析を行うのではなく、ビジネスサイドが自分たちでデータを拾ってきてBIツールを使って分析する状況を期待します。

ビジネスサイドは現場のニーズに応じ、分析に必要なデータをデータウェアハウスやデータマートから探してきて、時に必要なデータマートを構築し、BIツールでダッシュボードを作って分析します。

ここで問題となるのが「ビジネスサイドはデータウェアハウスやデータマートにあるデータの意味が分かるのか？」ということです。結局、データの意味が分からなければどのデータを使えばよいのか分からず、データの民主化が進まなくなります。

データの意味を定義するセマンティックレイヤ

こうしたビジネスサイドの課題を解消するための概念が「セマンティックレイヤ」です。セマンティック（Semantic）という言葉がそもそも聞き慣れないところではありますが、セマンティックは「意味的な」を意味する形容詞です。

すなわち、セマンティックレイヤとは、分析の対象となるデータが何なのか、どのように定義されているのか、という「データの意味の定義」を管理するための層を意味します。

例えば、分析対象のデータに「全社売上」というメジャー（定量的に測定可能な分析データ）があったとしましょう。しかし「全社売上」というデータはデータウェアハウスには存在しないので、いくつかのデータを基に算出しなければならないとします。

この企業は東京本社以外に3つの支社（仮に大阪支社・札幌支社・福岡支社）があり、それぞれの会計システムで販売情報が管理されているとします。この場合、「全社売上」の定義は、「東京本社の売上」＋「大阪支社の売上」＋「札幌支社の売上」＋「福岡支社の売上」になります。

この定義を明確にしなければ、人によっては「東京本社の売上」を「全社売上」かのように分析してしまうかもしれません。人によっては「全社売上」の中に「福岡支社の売上」を入れ忘れてしまうかもしれません。

セマンティックレイヤでは、こうした分析対象のデータの定義を一元的に管理します。したがって、このセマンティックレイヤという概念を、先に見たデータ蓄積の仕組みのどこの部分に設けるかを考える必要があります。

次回、セマンティックレイヤを実現する方法として、Google Cloudの「Looker」をご紹介します。