Recruit データ基盤刷新事例 — 数十サービスの統合

リクルートグループは、SUUMO、ホットペッパー、タウンワーク、ゼクシィ、リクナビなど数十のサービスを展開しています。それぞれが長年にわたって独自のデータ基盤を構築してきた結果、データの重複や整合性の問題が顕在化していました。本記事では、リクルートが数年掛けて実施した全社データ基盤刷新の概要を紹介します。
Recruit Group operates dozens of services — SUUMO, Hot Pepper, Townwork, Zexy, Rikunabi, and more. Each had built its own data platform over many years, and as a result, data duplication and consistency problems became apparent. This article introduces the company-wide data platform renewal that Recruit implemented over several years.
従来基盤の課題
従来は各サービスがHadoop、Redshift、Snowflakeなどを個別に採用しており、同じ「会員ID」が異なるカラム名で管理されているケースも多々ありました。マーケティング部門が複数サービスを横断して分析する際、毎回データの正規化に時間を要することが大きな課題でした。
Previously, each service individually adopted Hadoop, Redshift, Snowflake, and so on, and there were numerous cases where the same "member ID" was managed under different column names. When the marketing department tried to analyze across multiple services, the time required for data normalization each time was a major problem.
BigQueryへの一本化
リクルートは全社の中央データ倉庫としてGoogle BigQueryを採用しました。選定理由には、ストレージとコンピュートが分離されておりコスト管理がしやすいこと、列指向ストレージにより大規模集計が高速であること、そしてGoogle Cloudの他サービスとの統合が容易であることが挙げられます。
Recruit adopted Google BigQuery as the central data warehouse for the entire company. Reasons for selection include separated storage and compute making cost management easier, columnar storage enabling fast large-scale aggregation, and easy integration with other Google Cloud services.
dbtによる変換層
データ変換にはdbt(data build tool)を全社標準として採用しています。dbtのモデルはGitで管理され、プルリクエスト経由で変更が行われます。これにより、SQLが属人化せず、誰がいつ何を変更したかが追跡できる体制になりました。さらに、dbtの機能を活用してテーブル間の依存関係を自動で可視化し、データ系譜を全社で共有しています。
For data transformations, dbt (data build tool) is adopted as a company-wide standard. dbt models are managed in Git and changes go through pull requests. As a result, SQL is no longer siloed in individuals, and it is now possible to track who changed what and when. Furthermore, dbt's features automatically visualize dependencies between tables, and data lineage is shared across the company.
データメッシュの原則
組織規模が大きくなると、中央データ基盤チームが全サービスのデータを管理するのは困難になります。リクルートは各サービス領域に「データプロダクトオーナー」を配置し、その領域のデータの品質と公開に責任を持たせています。これがいわゆるデータメッシュの考え方です。中央基盤チームは共通インフラと標準を提供し、各領域が自律的に運営します。
As organizational scale grows, it becomes difficult for a central data platform team to manage data for all services. Recruit places a "Data Product Owner" in each service domain, who is responsible for the quality and publication of that domain's data. This is the so-called data mesh way of thinking. The central platform team provides common infrastructure and standards, while each domain operates autonomously.
個人情報保護法への対応
日本の改正個人情報保護法では、利用目的の特定や第三者提供の同意取得が厳格に求められます。リクルートは共通の同意管理基盤を構築し、ユーザーが許可した範囲の利用しか行えないよう技術的に制御しています。BigQuery側でもrow-level securityとcolumn-level securityを活用し、必要最小限のアクセス制御を実現しています。
Japan's revised Personal Information Protection Act strictly requires specification of usage purposes and acquisition of consent for third-party provision. Recruit built a common consent management platform and technically controls so that data can only be used within the scope users have permitted. On the BigQuery side as well, row-level security and column-level security are utilized to realize least-privilege access control.
系譜追跡の重要性
全社で数万のテーブルが存在する環境では、「このダッシュボードの数値は最終的にどの元データから計算されているのか」を追跡することが極めて重要です。dbtの系譜情報と、Dataplexなどメタデータ管理サービスを組み合わせることで、影響範囲分析や障害対応が迅速に行えます。
In an environment with tens of thousands of tables company-wide, it is extremely important to be able to trace "from which source data is the number on this dashboard ultimately calculated." By combining dbt's lineage information with metadata management services like Dataplex, impact analysis and incident response can be performed quickly.
今後の展望
リクルートは今後、生成AIを活用した自然言語でのデータ検索、データ品質の自動診断、そして国際展開を見据えたマルチリージョン対応に投資していく方針を掲げています。
Recruit has put forward a policy to invest going forward in natural-language data search using generative AI, automated data quality diagnosis, and multi-region support envisioning international expansion.