これは「弁護士ドットコム Advent Calendar 2021」の 15 日目の記事です。
はじめに
データ分析基盤の構成は多種多様なものがありますが、当社ではデータレイクをはじめとして、データウェアハウス、データマートの3層構造をとっています。概念としてのデータレイクは良いものだと思いますが、実際に利用してみると問題もつきものです。今回は当社での実際のデータレイク運用や、運用してみた結果見えてきた問題点等について記載します。
1. 当社の運用
1.1 構成
分析基盤の構成は次の通りです。
- GCPでは権限分けのため、各層をプロジェクト単位で分割
- trocco転送用DB(各種サービス用DBのコピー)を作成し、troccoサービスを用いてBigQueryにデータ転送
- 一旦データレイク層に集約し、集計やマスキング処理の結果をデータウェアハウス、データマートに転送
- BIツールredashからデータウェアハウス、データマートを参照
1.1.1 データレイク
1.1構成図の通り、各層はGCPのPJ単位で分たれたBigQueryサービスで構成されています。その中でデータレイク層は一旦全ての必要なデータを投入しています。また、GCPへのデータ転送のためにtroccoを利用しており、当社で利用している他のサービスも、分析で活用するもの、かつtroccoが対応しているものは同様にデータレイク層に投入しています。サービス毎にPJを分けた中ではデータソース毎にデータセットを分けて運用しています。なお、集計やマスキング処理等は行わず生データを保管しています。
1.1.2 データウェアハウス
データウェアハウス層はデータレイク層のデータを一次加工したデータを保管しています。機密データへのマスキング処理やある程度使いやすい粒度での集計等を行なっています。データマートを作成、利用していく上で必要になるであろうものを事前準備し、まとめておく層のような認識です。
1.1.3 データマート
データマート層は最終成果物のようなイメージです。redashからの利用を念頭に置き、データウェアハウス層で準備したデータを基に実際に利用したいデータ、分析したいデータをアウトプットする層として活用しています。データウェアハウス層で準備したテーブルを複数利用する、最終アウトプットがredashから参照される等の場合はデータマート層にテーブルを作成することが多いようです。
下図はこれら各層の利用イメージを表したもので、データレイク層に存在する各種テーブルからデータマートを作成するまでの大まかな流れを示しています。なお、データレイク層のテーブルに集計クエリをかけた結果をデータウェアハウス層に転送する、等の一連の処理は全てtrocco上で管理しています。
1.2 権限
以下は各層毎の権限対応表です。基本方針としては生データが保管されているデータレイクは限られたメンバーのみが編集権限を持つというものです。これをベースにサービス単位のPJ毎に権限を振り分けたグループを作成、運用しています。
| Admin | Creator | Viewer | |
|---|---|---|---|
| DataLake | CRUD | R | |
| DataWarehouse | CRUD | CRUD | (R) |
| DataMart | CRUD | CRUD | R |
*CRUD(Create、Read、Update、Delete)
データレイクを参照する必要があるデータウェアハウスのViewは承認済みビュー機能等を活用しています。
2. 問題点
2.1 権限問題
1.2権限にて権限表を掲載しましたが、では誰がどの権限を持つべきなのかというのは当然の疑問のように思われます。現状は、データ分析業務、基盤運用業務に携わっており作業上必要な方に必要な権限を付与しています。場当たり的な対応ですが、一方で実情としてこれといった基準を決めかねているのも事実で、どうにかしなければと思いつつもこのような運用に落ち着いてしまっています。
3. まとめ
今回は弁護士ドットコム社におけるデータ分析基盤を紹介しました。データレイク、データウェアハウス、データマートといった3層の大掛かりな構成としましたが、運用してみて初めて見えてきた問題もありました。データレイクをベースとした分析基盤は適切に利用しなければデータスワンプ(沼)となって使い物にならなくなると言われており、そうならないように運用していきたいと考えております。