データアーキテクチャ特集　データ利活用を推進する8社の技術選定

株式会社朝日新聞社

アーキテクチャ選択の背景や意図

これまでは、朝日新聞デジタル（朝デジ）のサービス開発・運用において、データを収集する基盤が存在せず業務ごとに Adobe Analytics や AWS QuickSight、 内製のツールなど様々なBIツールが乱立している状態でした。そこで、複数のシステムのデータソースを統合的に可視化・分析を可能にするために、分析基盤の構築に着手しました。

まず、データを集積・加工するETLとしては以下の点で TROCCO を選択しました。
　1. データエンジニアが不足しているため、データアナリストでもデータソース連携やワークフローの構築が容易であること
　2. 既存および今後増加する可能性のある多様なデータソースに対応していること

データウェアハウスとしては、データエンジニアのリソースが限られていることを考慮し、インフラ管理の負荷が少なくスケーラビリティが高い GCP BigQuery を選択しました。
BIツールとしては、ダッシュボードの階層管理の要件や社内セキュリティ要件などを満たしていた Tableau を選択しました。ただし、アカウントコストなどを考慮して一部のダッシュボードについては LookerStudio を併用しています。

現在の課題と今後の改善予定

BigQuery に蓄積されたデータは、朝デジの様々な分析やサービス提供にも活用されています。
ただし、現状では TROCCO のワークフローをスケジュールで実行しているため、加工後のデータが利用可能になるまでにタイムラグがあります。すべてのデータをリアルタイムで同期する必要はありませんが、たとえば、パーソナライズされたオンボーディング施策を、契約直後にリアルタイムに実施していくために、リアルタイムでデータを同期する仕組みを整えたいと考えています。
また、現在のアーキテクチャではデータの加工や集計はすべて BigQuery で行っており、複雑なビジネスロジックを組み込むのが難しい状況です。分析やダッシュボードの用途においては現行のアーキテクチャで十分ですが、サービス利用を考えた場合の拡張性は限定的です。データをサービスで利用するにあたり、データ基盤がどこまでの責務を持つべきか（ビジネスロジックを持つべきか）を含めて設計を再検討していきます。

◆執筆：朝デジ事業センター開発部　前田隼輔　@duck8823

【サービス公式サイト】
https://www.asahi.com/

【株式会社朝日新聞社のエンジニア求人】
⽉間1.4億PVの朝⽇新聞デジタルで分析基盤をリード！データエンジニア 等
https://findy-code.io/companies/540/jobs

株式会社CARTA MARKETING FIRM

アーキテクチャ選択の背景や意図

CARTA MARKETING FIRM（当時Zucks）は、アドテク企業として以下の課題に直面していました。

• 大規模データ処理
  
  • 日々生成される膨大な量の広告イベントデータ（主にJSON形式）の効率的な処理と活用。
    
• パフォーマンスとコストの最適化
  
  • 多様なワークロードに応じた効率的なクエリの高速実行と、増大しやすいストレージ・クエリコストの抑制の両立。
    
• 運用負荷
  
  • 既存のデータ基盤では、上記の要件を満たすための運用負荷が無視できないレベルに達しており、データエンジニアリングリソースの多くが日々の運用管理に費やされていました。
    

これらの問題を解決するには、既存のものをうまく使い回すより作り直す方が早いと判断し、新たに構築することにしました。

新しいデータ基盤のゴール

Single Source of Truth（SSOT）を実現する低コストで拡張性の高いデータ基盤を目指しました。
当時は2名体制だったこともあり、1年間この体制が続いたとしても、様々なユースケースに耐えられるような仕組みの構築を徹底しました。
参考：ぼくのかんがえる最高のデータ分析基盤

Snowflakeをメインのデータウェアハウスに採用した理由

このゴールを達成するために、メインのデータウェアハウスにSnowflakeを採用しました。主な採用理由は以下の通りです。

• 大規模データ処理に対する高いパフォーマンス
  
• ストレージとコンピューティングの分離による効率的なリソース利用
  
• マルチクラウド対応によるデータ転送コストの削減
  
• 高品質なサポートと活発な日本コミュニティ
  

参考：

• アドテクのビッグデータを制するSnowflakeの力
  
• 膨大なデータを扱うアドテク企業が直面するサイロ化の解消にSnowflakeを採用　データ利活用の効率化と基盤運用の大幅な省力化を実現
  
• Snowflakeと共に過ごした一年間。その進化過程と未来へのVision
  

このSnowflakeをベースとしたデータ基盤には、様々な技術を採用しています。
以下、私たちが選択した主要な技術とその役割を紹介します。

1. Snowpipe（マイクロバッチロード）
データロードの90%をSnowpipeで処理。
ログファイル要件の見直しにより、広範囲のワークロードに適用可能となっています。

2. External Table（データレイククエリ）
アドホックな分析や低頻度クエリに活用。
大規模データにはパフォーマンス上の問題が起きるケースがあり、その場合はSnowpipeでのロードを推奨しています。

3. Fivetran（ELサービス）
複数のデータソースへの迅速な接続。
これらが高い安定性でフルマネージドとして提供されるため、運用負荷が実質ゼロ。
参考：データロードの苦しみから解放。FivetranでAmazon Auroraデータ連携を数週間で実現した株式会社Zucks

4. dbt（データ変換ツール）
SQLのみでのデータパイプライン実装を可能にし、保守・学習コストを低減してくれます。
本来注力すべきデータモデリングに集中でき、品質向上に貢献。
参考：Snowflakeの力を引き出すためのdbtを活用したデータ基盤開発の全貌

5. Elementary Cloud（データオブザーバビリティツール）
dbtとネイティブに統合されたデータオブザーバビリティツール。
自動モニタリング、データリネージ等の機能、Slackへの通知機能を提供。
dbtを使っていて、本番環境で何が起きているかの把握に困っているなら、まず検討したいツール。
参考：中央集権体制からDataOpsへの転換

6. SELECT（Snowflakeコスト最適化ツール）
Snowflakeの使用状況の可視化と効果的なコスト管理。
自動化された節約機能によるコスト削減が行われ、何もしなくても費用が抑えられる優れもの。
コスト最適化にかかる高いコストのジレンマから開放されます。
参考：SELECTを使った手間なしSnowflakeコスト最適化

これらを統合的に活用することで、CARTA MARKETING FIRMは効率的なデータ基盤を構築し、データ活用の加速とビジネス価値の創出に注力できるようになりました。

現在の課題と今後の改善予定

特筆すべきデータ基盤に関する技術的課題は現在なく、目下取り組んでいる課題は、データに関する業務のデジタル最適化です。

具体的には、扱いやすいデータになっていないデータ（営業活動や法人、顧客などのマスターデータなど）を整備することや、各所に散らばっている外部の広告プラットフォームデータ（X, Meta, Google Adsなど）の統合などです。
最近のデータ系のツールは非常に便利で、多くの技術的課題を解決してくれます。
データ系業務で難しくなるケースのほとんどは、データの複雑性に起因しています。入ってくるデータを鵜呑みにするのではなく、データ自体の改善を始め、データ基盤に乗せやすい形に整備することで、多くの技術的課題は解決されます。
もちろんこれから扱うデータが増えて活用され始めると、また新たな技術的課題が見えてくるはずなので、それを楽しみに日々データ改善を継続して行っています。

◆執筆：近森 淳平（pei）　Vice President of Data　X：@pei0804 , GitHub：pei0804

【公式サイト】
https://carta-marketing-firm.co.jp/

【株式会社CARTA MARKETING FIRMのエンジニア求人】
機械学習エンジニア 等
https://carta-marketing-firm.co.jp/recruit/

ドクターメイト株式会社

ドクターメイト株式会社はデジタルの力を活用することで、介護の現場から医療に関わるリスクや負担を軽減し、介護事業者が安心して日々のケアに集中できる体制づくりをサポートしています。今回は、「日中医療相談」「夜間オンコール代行」「医療教育支援」などのプロダクトにとどまらずドクターメイトの全社事業も支えるデータ基盤についてご説明します。

アーキテクチャ選択の背景や意図

ドクターメイトのデータ基盤はデータ活用に注力するためにできるだけ基盤自体の保守・運用コストを下げた構成にすることを意識しています。
具体的には全体インフラをGoogle Cloud・BigQueryに統一しています。一般的な3層（Lake・Warehouse・Mart）+SandBoxの構成を採用しています。Warehouse・MartのみDataformで管理するようにしてSandBoxで活用イメージが定まったクエリを順次Dataform管理にしていく運用を可能にするなど保守性と利便性の両立を図っています。
また権限管理についてはGoogleグループを活用するなど社内インフラに沿った自然な運用ができるようにする工夫もしています。

TROCCO導入背景や成果に関しては、レビューで詳しく記載しておりますので、ぜひ下記ページもご参考ください。
TROCCOレビュー：これで全社データ集約を実現できました。お手軽で運用コストをかけないETLのファーストチョイスに！まずはFreeプランで試してみよう！

現在の課題と今後の改善予定

データ基盤自体についてはようやく社内データのSSOTとなり得る仕組みを整えられた状態だと思っています。
一方でプロダクトやCS向けのKPIの可視化やSalesforceとkintoneのデータ連携など活用事例は増えてきているものの全社規模で考えるとまだまだ活用については伸び代があり課題に感じています。
データ基盤の仕組みが整ったことも後押しの1つとなり社内でBizOpsグループという部門が立ち上がり事業グロースに向けた分析・活用を進めるプロジェクトも立ち上がったので、まずは社内での活用を促進するとともに活用に対してハードルとなるデータ基盤のアーキテクチャ上の問題を発見・改善していくサイクルを回していきたいと考えています。

◆執筆：エンジニア・BizOpsグループ グロースユニット 二瓶 良　@nihemak

【サービス公式サイト】
https://doctormate.co.jp/

【ドクターメイト株式会社のエンジニア求人】
【自社開発/フレックス/リモート】介護施設の夜間帯の医療体制をバックアップ！自社サービスの開発エンジニア募集 等
https://findy-code.io/companies/1293/jobs

株式会社i-plug

株式会社i-plugは、「つながりで、人の可能性があふれる社会をつくる」をグループミッションに掲げ、新卒ダイレクトリクルーティングサービス「OfferBox」を主力事業としながら、一人ひとりが自分らしいキャリアを育てられるプラットフォームの実現を目指しています。今回は「OfferBox」のデータ基盤について解説します。

アーキテクチャ選択の背景や意図

従来のデータ分析環境はイベントログを記録するMySQLのテーブルやファイルログが散在しており、ユーザー行動の包括的な分析が困難でした。また、データベースに蓄積されるイベントログテーブルがストレージ全体の圧迫要因のひとつとなっており、ファイルベースによる蓄積に変えていく必要がありました。 通常のアクセスログは既にfluentdを経由して長期保存用のAmazon S3と短期間のモニタリング用としてDatadogに転送する仕組みがあります。 そこで、以下の方針で新たにログ集積に基づいたデータ分析環境を構築することにしました。

1. バックエンドサーバーへのリクエストに、分析しやすい付加情報を追加したフォーマットに修正する
   
2. 集積されたログに対して障害調査用のAmazon Athena環境と、データ分析用のETL処理を新設し、データ分析の基礎データをログベースのものに変更していく
   

まだ導入したてですが、調査タスクでの利用で既存環境と同等以上の精度で結果が得られることがわかりました。分析データはこれから蓄積されていくことになりますが、よりよい精度で結果を得られると期待しています。

現在の課題と今後の改善予定

現在の環境はバックエンドリクエストが発生する箇所のログ集積を達成していますが、アプリやフロントエンドにおける画面操作の分析データは集積できていません。現状はサードパーティ製品の分析を利用しておりますが、サードパーティデータの自社の分析環境への取り込みを進めるか、イベントログデータ自体を自社集積するように変更するかを検討予定です。

◆執筆：
小椋 隆史 プロダクト開発部技術基盤グループ
手﨑 隆介 プロダクト開発部技術基盤グループ

【サービス公式サイト】
https://offerbox.jp/

【株式会社i-plugのエンジニア求人】
【リモートOK/スーパーフレックス】800億円規模の新卒市場を変える『OfferBox』のテックリード＜リモート・スーパーフレックス＞ 等
https://findy-code.io/companies/912/jobs

株式会社くふう AI スタジオ

アーキテクチャ選択の背景や意図

くふうカンパニーグループでは、家計簿アプリ 「Zaim」 やチラシ・買い物サービス「トクバイ」など、毎日の暮らしに関わるサービスを運営しています。開発効率の向上やデータ連携を通じて、より良いユーザー体験を提供していくために、サービスを通じて蓄積されるデータをBigQuery に集約しています。

集約先としてBigQuery を選んだ理由は、「Zaim」がBigQueryをデータ基盤として積極的に活用しており、「Zaim」 に合わせることで、他のサービスもスピード感を持ってデータ集約できると考えたためです。「Zaim」 では、家計簿という機密性の高いデータを扱うため、厳格なアクセス権限管理を行っています。また、これらのデータを特定の個人を識別することができないかたちで集計・加工して企業向けに価値ある分析ソリューションとして提供しています。このような高度なデータ管理や分析の仕組みを、他のサービスにも展開することで、より多くの価値を提供できると思っています。

さらに、ロードしてきたデータを利用者が直接見ることなく、分析時の負担を軽減する仕組みを取り入れています。また、長年サービスを提供してきたことで、現在使われていないデータのカラムが存在していますが、これらを整理・削除することで、認知負荷の低減ができると考えています。

現在の課題と今後の改善予定

BigQuery へのデータ集約を開始してから日が浅いため、現在「トクバイ」ではその基盤の利用が限定的です。今後、「トクバイ」のサービスに関わるメンバーがスムーズに既存のデータ基盤から移行できるように、従来のデータ基盤で利用されていた機能やレポートを再現しつつ、より使い勝手の良いデータ基盤へと改善を進めていきます。
例えば、既存のデータ基盤では、ロードしたデータを活用するために、秘伝のタレ的に多くの WITH 句が使われています。この部分を基盤側で吸収し、さらに業務内容に応じた適切な権限管理などを行う予定です。

◆執筆：
AX 推進部 佐藤晃矢　@koya3to
技術研究部 深谷淳

【サービス公式サイト】
1,100万 DL 家計簿サービス　Zaim
消費者分析の新・スタンダード　Zaim トレンド
月間利用者数 1,600万人以上※ チラシ・買い物情報サイト　トクバイ ※2024年1月時点

【株式会社くふう AI スタジオのエンジニア求人】
【AI for User First】リードデータサイエンティスト候補募集/『Zaim』『トクバイ』暮らしに関わるサービスのデータ利活用をリード 等
https://findy-code.io/companies/816/jobs

ピクシブ株式会社

アーキテクチャ選択の背景や意図

Google Cloudを中心にデータ基盤を構築しています。プロダクト間の親和性が高く相互の運用がしやすい、また、処理データ量が多いにもかかわらず性能面で問題がないというのが理由です。
BigQueryをデータウェアハウスとして、主に下記のデータを格納しています。

• プロダクトのバックエンドDBのスナップショット
  
• Google Analytics（GA）などのログ
  
• バックオフィス向けのデータ
  

BigQueryへのデータ集約は、EmbulkとAirflowを組み合わせて処理しています。実装はテンプレートを用意しエンジニアが容易に実装できるしくみを準備しています。
さらに、整備したデータをdbtを使ってデータマートに変換しています。データの整合性、リネージ、メタデータのドキュメンテーションなど品質の担保ができ運用保守の効率化のためdbtを利用しています。生成したマートはプロダクトの改善やサービス施策の効果測定、経営指標や予実の管理、各種分析向けにLookerで可視化し利活用しています。また、分析以外にも各種プロダクトのレコメンデーションやランキングの計算などの用途にBigQueryを活用しています。

現在の課題と今後の改善予定

ETL/ELTにてSaaSからデータを取り込む実装が保守コスト増につながっており、Fivetranなどの利用を検討しています。
また、Kubernetes上で運用中のAirflowの構成が複雑なため運用に高度なスキルが要求される懸念、データのトランスフォーム過程でdbtでのビルドが効率的に行われていないなどの問題を抱えています。

GAにおいてはデータ量が多く、ストレージやクエリのコストが嵩むため、データを分析に利用しやすいようサマリテーブルを作成し解決しているものの、GAで発生する仕様変更の追従に保守コストがかかる問題があります。

データ可視化ではデータウェアハウスやマートにメタデータが整っておらず「用途や使用状況がわからない」ものが多くそれらの適切な管理ができていないという問題があり、アセット属性をタグテンプレート等で管理する必要があるという課題、また、Lookerに関してはユーザーの認証・認可にGoogle OAuthを使用してクエリを実行するなどよりセキュアな環境の構築、今後Gemini in LookerなどAIを活用していきたいがLooker（origin）を利用しておりそれらが利用できないという問題があり、Looker (Google Cloud core)に移行するといった課題があります。

◆執筆：
CTO室プラットフォーム開発部
　データ基盤チーム エンジニア 新田大樹 @kashira202111
　データ基盤チーム エンジニア 西平翔一
　データ基盤/データ駆動推進チーム マネージャー 佐川重徳

【サービス公式サイト】
https://www.pixiv.net/

【ピクシブ株式会社のエンジニア求人】
データエンジニア／アドプラットフォーム事業部　等
https://www.pixiv.co.jp/mid-career/

株式会社SalesNow

SalesNowは「誰もが活躍できる仕組みをつくる。」をミッションに掲げ、セールスチームの武器となるデータベース「SalesNow」を開発している企業です。本記事ではこの「SalesNow」のデータ基盤について解説します。

アーキテクチャ選択の背景や意図

SalesNowでは、スケラーラブルかつ、半構造化・非構造化データの加工をシンプルに行えることからDatabricksを中心に据えたデータ基盤となっています。
背景としては、SalesNowでは"企業に関する様々な情報"を扱っていることから、サービスの成長に伴いデータ量・種類が増えることが予測されたので、スケーラブルなデータ基盤をつくることが一番の目的でした。
また、扱うデータの中には、法的・技術的に認められる範囲でWebクローリングし取得したデータ、つまりHTMLなど半構造化・非構造化データが含まれています。このような半構造化・非構造化データを加工し、価値のある構造化データとして扱うためには、Databricks社が提唱している "メダリオンアーキテクチャ"がマッチしていました。 "メダリオンアーキテクチャ"を最もシンプルに実現できるのがDatabricksだったため、Databricksをメインに据えたデータ基盤となっています。

現在の課題と今後の改善予定

Databricksの真価を引き出すために、以下のような改善を実施していきます。

• コンピュートコスト削減、開発効率向上のための、各コンピュートのサーバレス化
  
• コンピュートコスト削減を目的とした、Liquid Clustering導入
  
• データ関連の意思決定をより加速させるための、Unity Catalog（データカタログ）の整備/拡充
  
• ガバナンス強化を目的とした、Unity Catalog（アクセスコントロール）の適正化
  

加えて、蓄積しているデータ自体の価値を高めるために、AI/MLも不可欠と考えているので、それら機能も活用していく予定です。

◆執筆：星野 玲央奈　 @reonah6

【サービス公式サイト】
https://top.salesnow.jp/

【株式会社SalesNowのエンジニア求人】
【フルリモ/フレックス/SaaS+Database】データベース技術で働き方を変革する！データエンジニア！（437億データ有） 等
https://findy-code.io/companies/1584/jobs

ファインディ株式会社

ファインディでは、エンジニアと組織の転職マッチングプラットフォームやエンジニア組織支援SaaS事業を開発しています。その中でも今回は、エンジニア向けの転職サービス「Findy」、フリーランスエンジニア向けのエージェントサービス「Findy Freelance」のデータ基盤についてご説明します。

アーキテクチャ選択の背景や意図

アーキテクチャとしてはプロダクトごとにデータ基盤を構築するデータメッシュを採用しています。以前は中央集権的に BigQuery へデータを集約していましたが、メンバーやデータ活用の用途が増えるにつれ、影響範囲の見積もりづらさや複雑な IAM 管理が問題になりました。事業部ごとに IAM やデータリネージを管理すべく Google Cloud のプロジェクトを分けてそれぞれの BigQuery へデータを集約するように変更しました。
また以前は BigQuery のデータセットも役割ごとに整理できていませんでした。現在は source/staging/intermediate/mart とそれぞれに役割を設けてテーブルを管理しています。
データインテグレーションやリバース ETL ツールには TROCCO を使っており、事業部からの様々な依頼に対応できるようにしています。

弊社のデータ基盤の変遷と詳細な技術スタックについてはテックブログでも紹介していますので、ぜひご参考ください。
Findyデータ基盤のアーキテクチャと技術スタック

現在の課題と今後の改善予定

Transform ツール（dbt, Dataform）が事業部間で違っており、ノウハウが蓄積できないことが課題と感じています。現状はデータ利活用の機会を増やすことに重きを置いているため事業部と相談しながら柔軟にツール選定しています。
またアーキテクチャ上、事業部ごとにプロジェクトを分けたことによりデータ連携のハードルが上がったことも課題です。この点に関しては Google Cloud の Analytics Hub などを使って組織内でシームレスにデータ連携ができるように調整していく想定です。

◆執筆：CTO 室/データソリューションチーム　アシスタントチームリーダー/データエンジニア　開 功昂　 @hiracky16

【サービス公式サイト】
IT/Webエンジニアの転職・求人サイトFindy
Findy フリーランス

【ファインディ株式会社のエンジニア求人】
Findyのデータ基盤設計・構築や組織作りを牽引するデータエンジニア（マネージャー候補）を募集！ 等
https://findy-code.io/companies/164/jobs