当記事は、ライオン株式会社様と株式会社G-genの技術情報発信コラボレーション企画『SAPと連携するデータ分析基盤の実践とTips』で執筆されたものです。

はじめに

当企画について

当記事は株式会社 G-gen 様とライオン株式会社の技術ブログ相互寄稿企画で執筆されたものです。

ライオン側からは、 G-gen 様のご協力のもと、Google Cloud 環境に構築を進めているデータ基盤に関連した以下3つの記事をシリーズでお届けします。

ライオンのデータ基盤構築とSAPデータ活用体制
ライオンのデータマネジメント 👈当記事
ライオンのデータ基盤における分析環境

G-gen Tech Blog の記事一覧

blog.g-gen.co.jp

LION Digital Inside の記事一覧

zenn.dev

自己紹介

データサイエンスグループのハマノです。

もともとデータサイエンティストとしてライオンに入社し、データ分析を行っていましたが、データ基盤の必要性を感じ、入社後はガッツリとデータマネジメントに携わるようになりました。とりあえずデータを準備するだけに留まらず、継続的に全社的な業務が回るように、設計・構築・運用を踏まえたエンジニアリングを行うところが面白いなと思っています。

当記事では、ライオンで行っているデータマネジメントについて紹介したいと思います。

当記事について

ライオンでは2022年5月より基幹システムとして SAP S/4HANA（以下、SAP）を利用していますが、SAP に蓄積されたデータにまとめてアクセスする手段は、各部門の業務で用いるいくつかの帳票ツール（BO やアドオン）に限られており、部門ごとにサイロ化している傾向がありました。そのため、様々なデータの取得・解析が必要なデータサイエンティストや、自部門の業務の改善をしようとする業務担当者が必要なデータにスムーズにアクセスすることが困難な状態でした。

当記事は、データ基盤を構築することで、データの取得に関するボトルネックを解消し意思決定までのプロセスをスムーズにすることを目的とした活動について記載しています。

当企画の1つ前の記事であるフクヤマからの投稿で共有いたしましたが、我々は当初、SAP その他の業務システム由来のデータをインポートする複数のテンプレート群を持つデータ分析基盤構築向けのリファレンスアーキテクチャである Google Cloud Cortex Framework の利用を検討しました。しかし、アドオンテーブルなどを含む当社での SAP の実装においては、必要なデータを含むテーブルに対するテンプレートのカバー率が低く、Cortex Framework を効果的に使えないことが判明しました。

我々はこの事実を受け、Cortex Framework のテンプレートに依存しないデータモデルの設計と実装を行うことを選択しました。ここからは、我々がデータマネジメントをどう定義し、どんなツールを使って実現するかを検討した話を簡単にご紹介します。

概要

データマネジメントのプロセス

データマネジメントについては、一般的には DMBOK などで詳細に定義されていますが、少しシンプルにすると、以下の3つのプロセスに分解される活動です。

アジリティの確保
ガバナンスの確保
利活用の促進

まずアジリティは、すぐにデータを利用出来る状態にすることです。データ基盤は、基幹システムとの依存関係を切り離し、独自システムとして構築します。リスクやサービスレベルを変えることで、開発スピードを上げます。また、クラウドサービスを使って、スケーラブルな設計をします。

次にガバナンスは、品質の担保やセキュリティ面の考慮です。ユーザーが懸念なくデータを利活用できるよう準備します。

利活用の促進は、BI や AI などの分析ツールを提供し、データを使いやすくするプロセスです。ユーザーが、データを利活用できるために、業務プロセスでどのように意思決定を行うかを理解した上で、データを活用する機能やデータそのものを適切に提供することが重要となります。

アジリティ、ガバナンス、利活用促進のバランス

上に挙げたアジリティ、ガバナンス、利活用の促進はどれも重要な要素ですが、実のところこれらは本質的にトレードオフの関係にあり、バランスを取りながら進める必要があります。

ユーザー部門主導でのデータ利活用を優先して、既存の Excel ファイルなどをかき集めてアウトプットをする仕組みを作ったものの、運用に関する考慮をしておらず、担当者の異動や業務の見直しなどによりファイルが作成されなくなることや、人材リソースの不足でプロジェクトを中断するケースなどは、コンサルティング会社が主導した場合でも発生するといった話を耳にすることがあります。

逆に、外部の会社にデータ基盤の構築を委託し、その会社がつくったカッチリと決めた設計書、運用プロセスでは、ビジネスの変化に柔軟に対応できず、担当者のスピード感と合わず、上手く回ってないというケースもよく耳にします。

他にも、データの移動と保管、整合性維持にかかるコストを節約することを目論み、データカタログを整備しデータ仮想化技術によって各システムから動的にデータを取得するソリューションを導入すれば、労せずにデータ基盤が手に入るという構想のもと始めたプロジェクトが、主要システムのスキーマ取得すら試行錯誤続きで満足にできず、接続ができたとしても必要なパフォーマンスが出ず使い物にならなかった、といったような話も聞いたりします。

これらの望まざる状況を避けるためには、トレードオフを見極め、自社をよく知る担当者が、目指すべきデータマネジメントを定める必要がありますし、同時に状況に合わせて見直していく必要もあります。これらのプロセスは、メンバーのモチベーションを高めるためにも重要な要素であると考えられます。

とはいえ初期の状態では、何を可視化するか、誰がどういう意思決定を行うか、等が決まっていない、あるいは分かっていないケースも多いので、BI で出来ることのイメージを膨らませてもらうために、仮に設計したダッシュボードにより「可視化で何が出来るか」についての共有することも必要です。

当社でも、まずはイメージを持ってもらうために、汎用的なデータ基盤を目指し、アジリティ（データ準備）に重きを置いたデータマネジメントを目指すことにしました。

SAP のデータを整備から着手することになりましたが、ABAP が読めないことに加えて、生成 AI でも効率的に変換できなかったため、SAP の定義書を見ながら、SQL で再現しました。不明点は、社内の担当者・導入ベンダーに確認したり、Cortex Framework の SQL を参考にしたりしながら進めています。

設計

3つのレイヤ

まずは、データベース設計部分の話です。ライオンのデータ基盤では、アジリティを高めるために、データベースの階層を以下の3レイヤに分けて考えています。

DataLake
DWH
Datamart

DataLake

DataLake は、SAP のデータを同期したテーブルとしています。Fivetran の連携機能により、最新断面でのデータや履歴データを連携しています。

Fivetran の機能により、履歴データでは、Slowly changing dimension Type2 でのフォーマットで連携することを設定できるので、データの性質に合わせて連携しています。

DWH

DWH は、BI の可視化軸に合わせて、スタースキーマの設計をするべきところですが、たいていの場合は、BI のユースケースが定まっていないので、設計できません。

今回は、SAP のデータが厳密な第3正規化で設計された ER モデルであることから、スタースキーマに近づくことを見据えて、Datamart 作成のための中間テーブルを DWH レイヤで作成していて、マスタテーブルの整備を中心に行いました。ファクトテーブルでは、あまりフィルタ条件などは入れずに、変化の少ないビジネスロジックだけを実装しています。

将来的には、BIに合わせたスタースキーマの設計など、このレイヤの設計に重点を置く予定です。

正直、今は、そこまでキレイなものではなく、現段階では「後悔の塊」のようなレイヤになっています。

Datamart

Datamart には、DWH に対して、変化する可能性もあるロジックを実装しています。また、Datamart では、とりあえず利用しそうな列名を詰め込んだ大福帳形式（OBT: One Big Table）を採用し、汎用的に利用できるデータを準備しています。こうすることで、依頼者からの依頼に対して、素早く対応できるようにしています。

OBT は、BI や集計の目的に合わせたテーブルとして、様々なテーブルを結合して作成しています。

例えば、会計用 OBT だと、様々なテーブルを結合することで、会計年月/勘定を計上した組織 / 勘定を計上した組織 / 勘定種別（総売上、売上原価、販促費など）/ 金額のようなカラム名を持つ1つのテーブルにすることです。1つのテーブルにすることで、パフォーマンスのリスク、テーブル結合ミスなどのリスクを減らし、スムーズに利用することが出来ます。

とはいえ、OBT は良いことばかりでなく、依頼に合わせて様々なカラムを追加することが往々にして発生するため、大なり小なりデータ品質や保管効率は劣化することになりますし、BigQuery をもってしても（クラシックな RDBMS ほどではないにせよ）パフォーマンス・運用の問題が出ることはあります。

これらの設計も BI や仕様に合わせて、今後、チームで協力して細かく見直していきたいところです。

データカタログとメタデータ

データマネジメントといえば、データカタログなどのメタデータ管理が先行してしまうことも多いと思います。設計書などにも言えることですが、作成するドキュメントは「誰がどういう時に利用するものか？」「本当に必要か？」を問うことで、やらないコトを決めて開発の加速にリソースを集中することが望ましいと考えています。

まず、データ基盤導入では、以下の2段階のフェーズに分けて実際の行動を整理します。

Phase1: まだ利用用途が固まってない導入 PoC フェーズ
Phase2: 利用用途が固まり、データ活用を民主化し、ユーザーでの利用を加速するフェーズ

Phase1 では、利用者の大半は「BI 画面を見るだけの人」で、データカタログを必要とする人は、一部のデータサイエンティストやデータエンジニアです。

データベースに直接アクセスする人は少人数で、基礎知識のあるユーザーがほとんどです。また、このフェーズでデータサイエンティストが使うデータの種類はそれほど多くはないものの、外部システムからデータ基盤にデータを連携・蓄積する工程はまとめて行う方が効率が良いため、実際には使われないテーブルやカラムが数多く存在するという状況が発生します。加えて、この時点ではユースケースが定まっておらず、データモデルを決め切れていないため、テーブル構成も流動的で、大きな変更が発生する可能性も高いと言えます。このような状態で厳格に様式を定めた詳細なデータカタログを作ったとしても、大きな変更が発生して手戻りにつながることから、データカタログやメタデータの整備に過剰に注力することなく、口頭レベル・簡易ドキュメントでデータの仕様を共有する方が効率的と考えます。

さらに、このフェーズで、多くの「BI 画面を見るだけの人」は、データ分析をすることが目的ではなく、ダッシュボード上の可視化されたグラフを見て意思決定するためにデータ基盤を利用する人です。このようなユーザーはデータカタログを必要としていませんので、この時点で慌ててデータカタログを整備する必要はありませんし、将来に向けてデータカタログの整備を始める場合でも、スタート時は Looker などの BI ツールを使って、最低限のデータカタログ・アクセス権を大まかに管理するくらいで十分と感じています。

Phase2 では、利用用途が固まり、データモデルを設計する段階になります。データモデルが固まることで、DWH や Datamart をどのように定義するべきかを定めることができます。例えば、スタースキーマなどの設計に従って、データモデルが整備されていると、このフェーズからデータベースを使い始めるユーザーが扱いやすいものになりますし、DWH や Datamart のデータカタログの整備を積極的に行うことで、利用者が自主的にデータを活用することを促進できます。

もちろん、フェーズが進んでいくごとに、ユーザーのポートフォリオも変わっていくので、データカタログの必要性と費用対効果を意識しながら徐々に整備を進めて行くのが良いと考えています。

実現するためのプロダクト

Dataform、BigQuery

今後、DWH、Datamart の設計を見直すと、たくさんのテーブルが作成されることが予想され、これらのテーブル管理、処理のオーケストレーションの管理が必要になります。つまり、テーブルがたくさんできることで、それらの依存関係も複雑になるので、依存関係を可視化して、変更の影響が自動で整理できるようになっていることが求められます。

また、増分更新や差分更新は、初回実行時と差分実行時の処理を分ける必要がありますが、複数のメンバーでそれぞれのテーブル・処理に対して都度コードを書くようになっていると、効率が悪いだけでなく、コードの書き方が人に依存してしまいがちでメンテナンスができなくなります。Dataform では、when 関数、pre_operations ブロックがついているので、テーブルや処理の違いを吸収し汎用的なコードでの実装をサポートしてくれます。JavaScript で拡張することも出来るので、共通して使いたい変数の実装など、痒い所に手が届きますし、これが無料で使えるのが驚きです。 GitHub と連携したスケジュール実行も可能です。

我々は、このような利点を踏まえ、新データ基盤内の ELT ツールとして Dataform を採用しました。

BigQuery のスケーラブルなリソースに加え、内部のデータ操作は基本的に SQL を中心に完結しますので、この処理を効率的に管理する ELT ツールの Dataform を活用することで安価で効率的な仕組み作りを実現できています。

整理すると、Dataform は

オーケストレーション機能
依存関係の可視化
when 関数、pre_operations ブロックなどの拡張機能
GitHub 連携
スケジュール実行

などの機能があり、DWH、Datamart の管理を効率化するツールになっています。

Looker

Google Cloud で利用できる各種 BI ツールの中でも、Looker は特に使いやすいプロダクトです。

ユーザーは、合計の操作が必要な利益などの指標、割り算の操作が必要な利益率などの指標の可視化の要望があり、可視化する粒度が変わる度に計算が必要な指標は BI 側にロジックを実装する必要があります。

管理者や高度な分析を行うデータサイエンティストにとっては、それらの指標を LookML でコードとして定義し、extends 機能により再利用できるようにすることで、DRY（Don't Repeat Yourself）の原則に従った設計が可能になります。また一般ユーザーは、GUI で一般的なエンタープライズ向けの BI と同じような操作で分析が可能です。

さらに、いわゆるデータセットはセマンティックレイヤという形でコードの形で管理されることで、差分管理も可能になります。ツールによっては画面ごとに手作業で GUI を使って作る必要があるダッシュボードも、コードとして定義・管理できるので、新しい画面の迅速な実装が可能となりますし、担当者間での知見の共有や業務の分担も進めやすいです。昨今の技術トレンドを考えると、セマンティックレイヤをコードとして定義できていることで、生成AIとの相性も良いです。

整理すると、Looker は

ディメンジョン、ファクトの概念に合った設計
LookML によるコードでの指標定義、指標の説明などメタデータ管理、ダッシュボード管理
DRY の原則を実現できる extends 機能
セマンティックレイヤによるデータセット管理

などの機能があり、長期的な目線で考えた時に有用なツールと考えました。

以上はエンジニア観点での Looker の利点ですが、ユーザーにとっても、可視化機能に加えて、ディメンション（集計軸）、ファクト（数値）が明確に分かれていることで、迷うことなく、直感的にグラフ作成や集計を行うことができ、LookML でメタデータをコードで管理できます。また、セマンティックレイヤがコードにより可視化とは独立して管理されることで、生成 AI モデルを自由に検証できるので、自然言語での問い合わせや動的なグラフ作成など、将来の可能性が広がると考えています。