移行が無事成功して嬉しいですね。終わりが近づいてきました。24日目の本日はデータ基盤について紹介しますdata-platform-meetup.connpass.com今回の記事は、先日登壇した以下のイベントで発表を行いました。コミュニティの盛り上がりを感じる良いミートアップだったと思います。その背景となる考え方について紹介したいと思います。プロダクト開発に従事する人々すべてにとって大事なものです。データ基盤開発は、まさに計測のためのシステム開発と言い換えて良いでしょう。関心が寄るのは自然の流れといえます。「誰のためのものか?」を考えることはよい洞察を得るためのヒントとなります。データの民主化と基盤開発データ基盤開発におけるトピックは、構成要素の技術的実現難易度が高いものであることからほんの数年前で取り上げられる対象は技術的トピックが取り扱われることがほとんどだったように思います。トピックも取り扱われることも多くなりました。その代表的なテーマにデータの民主化があります。民主化という言葉は「自由に触れられるデータや人を増やす」ことを目的においているように聞こえますが、その主旨はデータにより多様な観点を取り入れることにあります。データ自身はある時点の事実を示すのみで、効果的なデータ利用のため最も大事になるのはそのデータへの問いかけ方です。よい問いかけを見つけるための手段は様々なコンテキストに基づく考え方を取り入れる他になく、そのためにはより様々なバックグラウンドを持つ人がデータを通して観察を行えるとより良いというわけです。これがより組織内で広範囲に展開できるとレバレッジが効くようになります。この「プロダクトをよくする」という共通の目的をもとに、バックグラウンドやコンテキストが異なる複数の観点をいかに統合できるかにあるように見えます。ヒトを中心とした有機的な枠組みをシステムに落とし込むことで図られます。これはまさにアーキテクチャ(デザイン)に対する問いかけです。データ基盤開発をすすめるにあたり、その中心にはデータエンジニアではなくデータアナリストを据えるようにしています。ドメイン実践者が担っていけることが最も効果的ですがその実践者はデータアナリストだからです。アナリストが中心的にデータ基盤上の開発を担っていくためには、コアとなるコンセプトやアーキテクチャの整備、最低限のデータの整備、標準化に向けたツール整備と普及活動がメインになります。データ基盤開発の標準化データアナリストが主体的なデータ基盤開発を担えるようになると同期コストは低くなり、個々で動ける範囲が広くなる傾向にあります。データ基盤開発全体としての一貫性や整合性が失われカオスを生み出すことになります。データ基盤の開発は元々依存関係が多層かつ複雑になりやすいものですがこういった形でもたらされるカオスは開発可能性の著しい低下を招きます。カオスによりもたらされる悩みのタネにはいとまがありません。標準化は個々の不規則とも言える動きに一定の制約をあたえ、全体としての秩序を生み出すための動きです。標準の上に乗っかることで恩恵が受けられる、創造性をもたらす不自由さが理想的です。簡潔な枠組みを提供することができれば、学習コストを低くする効果もあるため短期的効果も期待ができます。Rettyで導入している標準化としては次のような動きを標準化のために取り入れています。別記事としてまとめてあるので参照してください。促していく動きも必要になります。テストの考え方は、アプリケーション開発とは異なるテスト戦略を考える必要がありました。アナリストたちが主体的に取り組むことを目指して、モブプロといった開発形態をとることも効果的な手立てでした。データ基盤の持続的開発に取り組んでいます。ご覧くださいしてください。データウェアハウシングを進めるにあたってのアーキテクチャを紹介したいと思います。Rettyでは、データウェアハウシングの次の図のようなレイヤ構成をとっています。これらのレイヤがデータウェアハウシングにおいてどのような役割を持つかについて紹介していきます。その基本コンセプトとしてETLではなく、加工処理(Transform)を遅延させるELTを採用しています。Area)はそのための場所です。似た役割を持つデータレイクとの違いは、データ置き場のデータBigQueryに格納できるだけの構造化がされていること。BigQueryで利用可能なソースとして公開されるため多少不便ではあるが誰でも利用可能といった点にあり想定するユースケースが異なります。これらはBigQuery上の単一のデータセットに様々なテーブルを格納する形で実現しています。イベントデータではl_といったようにデータソースごとに接頭辞を分けて整理しています。プロジェクトそれぞれのユースケースに応じて利用されるデータセットです。ひとつBigQueryのデータセットを割り当て、データアプリケーションの実データやチームのダッシュボードを含めて、利用方法は各プロジェクトの担当者に一任しています。)を設置してもらっています。これはデータ基盤全体での依存の管理と上流側の影響により下流であるプロジェトに問題する場合の開発可能性を保持するためです。Area)に置かれたデータはBigQueryへ格納のための最低限の構造化はされていますが、データ利用の観点では使いやすくはない状態で配置されます。データ置き場にあるイベントデータの変形を行い、より利用がしやすい構造化された状態で保持するのが、イベント層の役割です。整形の仕方によっては個々のテーブルの独立性を維持しつつ、ひとつのデータソースが複数データソースで利用されることもあれば、複数のソースがひとつにまとまることもあります。クロスプラットフォームな分析利用がしやすいように、構造を共通化するのもイベント層の役割です。データソースの異常にも気付く仕組みを簡単ながら作ることができます。主要な実態となるエンティティを取り扱うためのレイヤです。スノーフレークスキーマ*1におけるディメンジョンテーブル群に相当します。ひとつのエンティティにひとつのデータセットを割り当てるように配置しています。データセットをひとつ割り振ることでアクセス制御等が行いやすくなります。関する情報を取り扱うためのデータセットent__userは次のようなテーブル群から構成されます。RDSのテーブルは通常アプリケーションのための正規化がされています。エンティティそうではこれらの非正規化を行い、エンティティに対する属性情報がひとつのテーブルにまとまるようにします。(ent__user.core)非正規化された情報とは別に、分析観点で提供するセグメントの提供することはよくあるユースケースです。ユーザに対するセグメントであれば、サービスの利用頻度などを基準として分析を行うことは珍しくないでしょう。エンティティ層の各データセットには、それぞれのエンティティに対するセグメントを取り扱うためのテーブルもまとめるようにしています。このようにすることで、対象のエンティティに関する分析がどのように行われるか?といった知識の把握に努めやすくなります。エンティティのデータセットごとに、自動的に履歴テーブル(図中のent__user.history)が用意されます。通常アプリケーションのデータベース上のテーブルは、as-was分析用途に耐えうるものではありません。いった観点をデータウェアハウス上のでエンティティで保証するようにしています。自動的に縦持ちに変換するクエリを生成し、定期ジョブとして履歴を自動的に保持するようにしています。個々のエンティティの関係の取り扱いは、プロダクト開発のデータモデリングと密接に紐づけられます。次の図は、Rettyにおける概念モデリングの資料の一部を切り出したものです。モデリングと実装を結びつけて管理していますデータの分析利用の際には、このような知識が必要となることも多くあります。工夫を凝らしています。最後に指標層は、分析を目的とした集計作業を取り扱うためのレイヤです。スノーフレークスキーマでいうところのファクトテーブルに相当します。指標データセットの役割を持ちます。指標層では1つ以上の指標を指標グループにまとめデータセットを割り当てます。指標データセット中の全てのテーブルは同じ指標グループをスキーマにいれる取り決めとしています。アプリケーションに関する分析でもっとも基礎的な集計であるページビューの集計を具体例に挙げ説明していきます。用意しようと考えたとき、次のようなテーブルから構成されます。(自動生成)データセット内の指標に関する集計レコードの最小粒度(グレイン)の定義および指標の集計方法は、__coreが慣習的に担っています。metric_pageivew._core.は例えば次のようなスキーマを持ちます。ページビューという指標では、単純な数え上げのイベント数だけでなく、ユニークユーザ数やユニークセッション数も一緒に計算しています。これらは別々で管理されるよりも集約されていることの方が望ましいためです。最小粒度の定義することができれば、任意のディメンジョンに対する集計はエンティティに対する周辺化により再集計を行うことで導くことができます。timesearchをはじめとするユースケースに応じたテーブルは、__coreから不要なエンティティの周辺化を行い列削除することで得ることができます。as-was分析のため指標に対する履歴テーブルも自動で生成されるようにしています。プロジェクトのコンテキストにより更新変更されることがとりわけ多く発生します。指標定義の一元化と指標定義のコードを変更した場合には、変更履歴テーブルを利用し自動的に数値比較を可能にするような仕組みを提供することで開発をしやすくしています。目指してRettyにおけるデータ基盤についてのレイヤ構成について紹介しました。」を持続可能な状態にすることにあると考えています。知識のコード化とは、実践的なドメイン知識を再利用可能な実装の形で提供可能にすることを指します。データ基盤に継続的に反映することが最も好ましいでしょう。今回紹介したレイヤ構成ではエンティティをどの単位で区切るか?どのような指標層のデータセットを用意するか?といった点において、まだまだ設計をつめていく余地があります。データ基盤の洗練も行っていきたい所存です。本日紹介した内容が、データ基盤開発に取り組まれているみなさまの参考になれば幸いです。~新卒6ヶ月振り返り~こんにちは、Rettyのデータアナリストの二見大揮です。#DPMこんにちはRettyの二見です。こんにちは、エンジニアの櫻井です。採用についてRettyでは、一緒にサービスを作るエンジニアを募集しています。ご興味のある方はぜひ下記よりご応募ください。検索はてなブログをはじめよう!rettydevさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。