No content

概要 1. ABEMAにおけるデータマネジメント ○ サービス成長に伴うデータ活用の変遷 ○ データ利活用における課題 2. DMBOKの活用 ○ DMBOKとは ○ データガバナンスとデータマネジメント ○ 現状評価と方向性 3. 活用事例の紹介 ○ データガバナンスの定義 ○ BigQuery ETLの標準化 ○ BIツールの再整備 ○ 実施内容による評価レベルの変化 4. まとめと今後の取り組み

1.ABEMAにおけるデータマネジメント

サービス成長に伴うデータ活用の変遷 1.ABEMAにおけるデータマネジメント ● 立ち上げ期 ○ データ要件 ■ BIツールによるユーザ数など指標のレポート出力 ■ コンテンツ利用料やプレミアム課金など決済に関わるデータ管理 ○ データ利用状況 ■ レポートはGoogle Analyticsで実施 ■ 視聴ログをBigQueryで取得してコンテンツ利用料の算出 ○ システムの状況 ■ 基本的に行動ログはGoogle Analyticsに通知 ■ データ基盤にはアプリ起動、視聴の必要最低限のログを取得

サービス成長に伴うデータ活用の変遷 1.ABEMAにおけるデータマネジメント ● ビデオなど機能増強期 ○ データ要件 ■ ABEMA全体の指標を定義したレポート（日次、週次） ■ SNSからの流入状況の確認 ○ データ利用状況 ■ ABEMAの基本レポートを作成 ■ 各コンテンツの視聴状況やSNSからの流入元などを確認 ○ システムの状況 ■ データ基盤に行動ログ全般を格納 ■ データベースはGCPのBigQueryを利用 ■ BIツールはTableauへ切り替え

サービス成長に伴うデータ活用の変遷 1.ABEMAにおけるデータマネジメント ● レコメンドなどデータ活用期 ○ データ要件 ■ さまざまな観点からABEMAの利用状況の分析要望 ■ レコメンドの精度向上 ○ データ利用状況 ■ ユーザクラスタやセグメント、レポートの乱立 ■ 関係各所からデータ抽出依頼の増加 ○ システムの状況 ■ 集計遅延解消の為、データパイプラインの刷新 ■ データを整形した、中間テーブルの増加

データ利活用における課題 1.ABEMAにおけるデータマネジメント ● 品質 ○ 利用リテラリーやログデータの複雑性により、同 一指標の値が異なる ○ デバイス毎に異なるタイミングで記録され、一貫 したデータ収集ができていない ○ 遅延や障害時に根本対策ではなく、場当たり的 な対応となり再発を防止できない ● 設計 ○ 多様なログ収集経路があり、データレイクやデー タウェアハウスが混在してしまっている ○ 汎用性を担保できず、レポートベースの実装、設 計が行われ最適化がされない ● 運用 ○ ラムダアーキテクチャではなく、高速化への対応 が見込めない ○ ログの実装におわれ、データの最適化ができて いない ○ サービスのKPIツリーへの変更が多発し、曖昧 になっている ○ どのデータがどこにあるか利用者が分からず問 い合わせが膨大になる 体系的なデータ領域の整備が必要 具体的にどういう課題に直面するのか

2.DMBOKの活用

DMBOKとは 2.DMBOKの活用 ● 抽象化レベルで開発されたフレームワーク で、総 合的な理解と構想要素がわかり、様々な組織に 適用できる ● ITとビジネス領域の整合性という課題に対し、 戦 略的な取り組みの推進手法をまとめている ● 最善でない状況から 改善に取り組むことが考慮 さ れている Data Governance Data Architecture Data Modeling & Design Data Storage & Operations Data Security Data Integration & Interoperability Document & Content Management Reference & Master Data Data Warehousing & Business Interlligence Metadata Data Quality データマネジメント知識体系ガイド 第二版より

DMBOKの利用 2.DMBOKの活用 ● データガバナンスの定義 ● 現状の可視化 ● 現状の評価 ● 改善方針の検討 データガバナンス
 データ品質
 データ設計
 データ運用
 システム
 マスターデータ
 データウェアハウス ビジネスインテリジェンス/分析 
 依 存 関 係
 ・
 ア ウ ト プ ッ ト
 データマネジメント知識体系ガイド 第二版より

データガバナンスとデータマネジメント 2.DMBOKの活用 データガバナンス (データを適切にマネ ジメントさせる) データマネジメント (ゴールに到達するために データを管理する) データと インフォメーションと コンテンツの ライフサイクル 監督 実行 データマネジメント知識体系ガイド 第二版より ・監督と実行を分ける事で、組織がデータを資産として管理できる状態にする ・データ中心の管理にすることで、適切なライフサイクルの管理を行う

現状評価と方向性 2.DMBOKの活用 各能力ごとに成熟度を評価 能力レベルが一番低いものに注目 ● メタデータ ● モデリング ● ドキュメントとコンテンツ管理 データ利用者が増加したことによる課題とリンクしている ことがわかる。

データ活用の方向性 データモデリング ● 全てのデータモデルが存在していない。 ● 行動ログ設計がデータモデルに沿った形になっていない ドキュメント管理、メタデータ ● 情報が散乱しており、どこにあるか分からない ● チャットで決定した内容が設計書に反映されていない ● 中間テーブルの指標の定義が曖昧 データアーキテクチャ ● 集計遅延が稀に発生して、レポート更新が遅延する ● データフローが複雑でどこでデータが利用されているか把握できてない ● どのデータを使うべきか統制が取れていない データアーキテクチャとしては、以下の3点の 解決を目指す： 1. データフローとしては簡潔にして耐障害性 を高め運用しやすくする 2. アーキテクチャ図の理想状態を作成するこ とでデータ利用者がどこからどんなデータ を利用したらよいか分かりやすくする 3. 適時性が高いデータレイヤを確保し、様々 なデータ要件に答えられるようにする 2.DMBOKの活用

3.活用事例の紹介

データガバナンスの定義として、データの処理、集計処理を組織的に管理し、再現性を担保 し維持するという事で考えています データガバナンスの定義 行動ログ テーブル レポート 共通ETL チーム管理ク エリ 野良ETL 属人化 クエリ

3.2. BigQuery ETL処理の標準化 スケジュールクエリなどに散らばっていたBigQuery ETL処理を、標準呼び出し規則を整備 することにより、データパイプライン側から統一的に呼び出せるように整備しました。 #standardSQL CREATE OR REPLACE PROCEDURE `procedure`(start_dt DATE, end_dt DATE, dry_run BOOL) BEGIN -- 依存テーブル利用可能アサーション -- 出力先テーブルの作成 -- MERGEステートメントで更新処理 END

3.2. BigQuery ETL処理の標準化 具体的には以下の手順で実現しています 1. 依存テーブルの完成を待つ a. 管理対象テーブルではタスクの完了 b. 管理対象外テーブルはパーティーション（日次、週次、月次）の作成完了 2. テーブル更新処理を、呼び出し規約の通り呼び出す 3. グループごとに完了状態を後段ジョブに渡す

BIツールの再整備（クエリ外部化） BIツール側にカスタムSQLが設定されていて、版管理、検索がしにくい状態になっていたた め、GitHubにリポジトリを作成、カスタムSQLの内容をビューに移し、ビュー定義SQLを自動 反映する仕組みを構築しました。 自動反映 GitHub BigQuery

BIツールの再整備（クエリ外部化） 自動反映は以下のような処理で実現されています 1. Cloud Buildのプッシュトリガーで処理を起動 2. リポジトリ内のSQLスクリプトを、bq query --dry_run=true でテストする 3. もし開発用ブランチであればこのステップで終了(Pull Requestなどの場合) 4. bq query で反映する 5. 完了後、Slackでビルド結果を通知する

BIツールの再整備（データパイプライン編入） スケジュール更新されていたTableauワークブックを、依存テーブルが更新完了するまで待 ち、Airflowから更新するように修正しました。Tableau側で特定のタグを付与する事で、更 新対象を自動認識するようになっています。 ●

BIツールの再整備（データパイプライン編入） Tableauの設定をAirflowに動的に反映するため、Airflow側は以下のように実現していま す。 1. 定期的にTableau Serverのワークブックをタグで検索し、Variableに保存する 2. Variableに従ってタスクを定義する a. 依存するテーブルの完成を待つように設定する b. Slackのスレッド化のため、親メッセージのIDは、XCOMで格納

実施内容による評価レベルの変化 データの利用方法や処理方法が属人化した CMMI® レベル1 (Initial) から、基礎的なシス テム化が完了し、部署内での分析方法の共有が行われているレベル2 (Managed) に改善

4.まとめ

まとめ 1. ABEMAにおけるデータマネジメント ○ サービス変遷により乱立する課題の対応 ○ 改善フレームの必要性 2. DMBOKの活用 ○ 抽象的で推進手法までが含まれるフレームワーク ○ 途中から適用することを視野に入れた適用しやすさ 3. 活用事例 ○ ABEMAでの活用事例の紹介とそれによる評価の変化

今後の取り組み ● データモデリングとデザイン ○ 行動ログ、中間テーブルの設計運用フローの 定義 ● データアーキテクチャ ○ データウェアハウスとデータマートの定義 ● データ品質 ○ デバイス、機能ごとのログ定義最適化 ○ 中間テーブルの用途言語化

No content