要約
2024年8月時点における、サイボウズの最新のデータ基盤について紹介します。
はじめに
サイボウズ株式会社のデータエンジニア/アナリストチームに所属している喜多です。
昨年8月にサイボウズに入社してから1年が経ちました。
時が経つのは早くてびっくりです。
以前こちらの記事で弊社のデータ基盤を紹介しました。
上記の記事末尾に記載の通り、プロジェクト開始当初（2019年）の時点から各コンポーネントをアップデートしているので、現時点のデータ基盤を紹介したいと思います。
また、後半には今後取り組んでいきたいことも記載しているので、最後まで読んでいただけると幸いです。
データ基盤の役割
初めに、サイボウズのデータ基盤の利用用途について説明します。
データ基盤は社内に公開しており、以下のような用途で活用されています。
- 複数のソースのデータをかけ合わせた分析
- Excelやkintoneで行っていた集計作業の効率化
- BIツールを使ったレポートの作成
直近の月間利用者数は約140人で、多くの人に活用してもらっています(2024年7月分)。
データ基盤システム構成
では、そのデータ基盤がどのような仕組みになっているか紹介します。
システム構成図
Extract
各ソースからのデータ取得方法は、APIやHTTPリクエスト等、ソースにより様々です。
基本的には一旦CSVファイルにデータを出力しています。
kintoneについては、Embulkのプラグインを利用することでCSV出力からBigQueryにテーブルを作成するところまでをまとめて行っています。
Load
CSVに出力したデータはローカル環境からGoogle Cloud Storageにアップロードし、その後BigQueryにデータを連携してテーブルを作成します。
ここで作成したテーブルはrawテーブルというデータが無加工の状態なので、ユーザーがアクセスできないように設定しています。
Transform
実際にユーザーがアクセスできるテーブルには「source」、「summary」、「store」テーブルの3種類があります。
sourceテーブルはrawテーブルを加工したテーブルです。
カラムの型やモードを利用者が使いやすい設定に変更したり、パーティションやクラスタリングを設定したりしています。
また、一部のソースは差分連携を行っているので、その場合、sourceテーブルも差分更新しています。
summaryテーブルは幅広い用途での利用を想定したデータを集計したテーブルです。
一つ、または複数のsourceテーブルを参照して作成しています。
storeテーブルは特定の用途で作成されたテーブルです。
例えば、Power BIのレポート参照元のデータや、リバースETL用に必要なデータをstoreテーブルとして作成しています。
3種類のテーブルを合わせると現時点で約140のテーブルがあります。
また、これらテーブル作成時には、すべてdbtを利用しています。
dbtには以下のようなメリットがあり、テーブル品質向上等につながっています。
- 差分連携のような複雑なデータ連携をdbt側がよしなに処理してくれる
- テストを導入することでデータの違和感にすぐ反応できる
- ephemeralモデルやmacrosを活用することでクエリの再利用が可能
- Data lineageによりテーブルの依存関係を可視化できる
リバースETL
リバースETLとして、BigQueryからkintoneへAPIを使ってデータを戻しています。
用途の一例として、kintoneの通知機能(※)を使って、顧客の売上が一定額を超えたら社内の担当者に通知されるような仕組みを作る際にリバースETLを活用しました。
BigQueryにある社内システムの売上情報より、条件に当てはまる顧客を抽出したあと、リバースETLによってkintone側の顧客レコードを更新し、担当者に通知を飛ばしています。
※ 機能の一つとして、特定のフィールドの値が更新された際に、同レコードにユーザー名のフィールドがある場合、そのユーザーに通知を飛ばすことが可能(参考)
オーケストレーション
データ連携のオーケストレーションツールとしてはApache Airflow(以下、Airflow)を採用しています。
ソースからのデータ連携は日次でDAGが実行されるよう設定しています。
他のDAGと依存関係がある場合はDatasetを設定することで、DAGの実行順序を制御しています。
現在は社内サーバーの仮想環境にDockerでコンテナを作成し、そこでAirflowを稼働させています。
後述の通り、ゆくゆくはクラウドサービスに移行することを検討中です。
Business Intelligence
現在は3つのBIツールを用途別に活用しています。
- Redash: 「クエリ実行環境」「アドホックな集計・分析・可視化」
- Power BI: 「各種指標の定点観測」「継続的な集計・分析」
- Looker Studio: 「アドホックな集計・分析・可視化」
RedashとLooker Studioは用途が似ていますが、Redashのほうがユーザーからの利用頻度は高いです。
その他
データ基盤は基本Google Cloudを活用していますが、AWSも利用しています。
用途としては、BigQueryから一部データをS3に抽出しています。
データ基盤のこれから
以上がサイボウズのデータ基盤の紹介でしたが、今後取り組んでいきたいことを2つ紹介します。
データマスキング
現在は列や行ごとのマスキングは行っておらず、テーブルごとのアクセス権限の設定によってユーザーのデータアクセス管理を行っています。
データ基盤の社内利用が広がっており、今後さらなるセンシティブデータが連携される可能性があります。
そのため、データマスキングを行い、より機密性の高いデータ基盤を目指します。
また、データマスキングが実現されることで、データ基盤利用のための申請フローを簡略化し、より気軽にデータ基盤を活用できる環境を整えたいと考えています。
Airflowのクラウド化
現在Airflowをオンプレ上に立ち上げていることで以下のような手間や課題がいくつかあります。
- メモリや容量等のインフラ管理
- ライブラリのアップデート
- CI/CDを活用しにくい
これらを解消することで運用に割くリソースを軽減する目的から、現在Cloud Composerの導入を検討しています。
おわりに
改めてサイボウズのデータ基盤について紹介しました。
今後もチームのビジョンである「誰もがデータを活かせる会社に」を目指して、データ基盤をより良くしていきたいと思います。
今回の記事が参考になればとても幸いです。
Discussion