Data Engineering Meetup #1 持続可能なデータ基盤のためのデータの多様性に対する取り組み

持続可能なデータ基盤のための
データの多様性に対する取り組み
20190319
CyberAgent, Inc. All Rights Reserved

善明晃由
●2011年3月中途入社
●所属：技術本部秋葉原ラボ
●データ解析基盤や関連システムの開発運用を担当
●前職はメーカの研究所で分散コンピューティングなどの研究開
発を担当

「データを活用」してサービスと会社の発展に寄与する
秋葉原ラボについて

● データエンジニアリングの領域は技術的負債が生まれや
すい
○ 専門性が高く採用が難しい
○ 規模が比較的大きく各種アップデートもコストが大きい
○ 技術の進歩が早く、専門性を磨いて最新の動向をキャッチアップ
する必要がある
● 秋葉原ラボにおける技術的負債を減らし持続的な発展を
目指す取り組みの事例
○ 共通部分と可変部分を分析しシステム統合を促進
○ ドメインモデリングなどの活用
概要

● 問題意識と方針
● 事例
○ レポーティングツールの整理統合
○ 非構造化データ参照のAPIのプロダクト化
● まとめ
本日の流れ

● 縦割り組織の弊害
○ 各サービスが独立 + マーケティングなどの横軸
○ 様々な案件が独立して進む
■ 似た案件があっても気づきづらい
問題意識
システムのサイロ化

● サイロ化が加速
○ それぞれに十分なリソースをさけない
○ 各担当にフルスタックのスキルが求められる
問題意識
● 開発から運用
● アプリケーション、ミドル
ウェア、CI/CD、監視

● フルスタック化の結果
○ 開発から運用まで幅広く担当する必要があり、専門性が深められない
○ 変化が早い分野なので容易に技術的負債につながる
問題意識
アップデートのための
時間がとれない
（調査・検証など）

● フルスタック化の結果
○ 採用が進まない + 属人化の加速
○ 退職等による技術的負債化
問題意識
再起動くらいしかでき
ない
● 開発から運用
● アプリケーション、ミドル
ウェア、CI/CD、監視
そんなにいない
大規模データ処理や機械
学習まで含めるとほとんど
いない

● 各システムのプロダクト化を促進
○ 何が同じで何が違うかを分析
■ ドメインモデリングなど
○ 共通部分をプロダクト化
● 役割の分離
○ 専門性を高め機能・品質強化に貢献
○ システムとして統合し活用できる状態にする
方針

● 問題意識と方針
● 事例
○ WebUIの整理統合
○ 非構造化データ参照のAPIのプロダクト化
● まとめ
本日の流れ

ログ解析基盤の全体像
パブリッククラウドレコメンデーションシステム
Patriot
データ転送管理
ストリーム処理エンジン
HTTP API
/ WebUIMySQL
etc..
Logs
{
“date”:”20190319”,
“pv”: 12345
}

● Hiveでログを集計した結果をHBaseに書き込み
● HBaseから結果を取得し可視化
WebUI 概要
Hive HBase

● HBaseの各フィールドにどの属性値を置くか
● キーの値が先頭からうまるクエリほど効率的に処理できる
○ アクセスパターンに応じたスキーマ設計が重要
→　用途によってデータの表現が異なる
HBaseにおけるスキーマ設計
問い合わせの際にserviceを
指定することが必須

● 行動ログベースのレポーティング
○ PVやユニークユーザ数を可視化
○ Rowkeyにはサービス名や指標名など
WebUIのサイロ化
data warehouse
Hive Table
Hive Table
Hive Table
data mart
HBase Tablewrite client read client web app
指標名を指定して一定期間
のデータを取得
行動ログレポーティング
(UU, 課金額など)

● アクセス解析
○ ページごとのPVやレスポンスタイム
○ RowkeyにはドメインやURLのパスなど
data warehouse
Hive Table
Hive Table
Hive Table
data mart
HBase Tablewrite client read client web app指標名固定、URLを指定して
特定日のデータを取得
HBase Table web appwrite client read client
アクセス解析
（PV、レスポンスタイム）

● 広告の効果測定
○ インプレッション、コンバージョン数
○ Rowkeyは広告枠や広告の識別子
data warehouse
Hive Table
Hive Table
Hive Table
data mart
広告効果解析
（IMP、CV）
様々な分析軸
（広告枠、広告ID, etc）

● 可変部分
○ フィールド中の属性リストと区切り方
● 共通部分
○ byte[] の結合と分割 (ByteBufferの利用など)
HBaseクライアントの分析
public byte[] toRowKey(Map appRecord){
ByteBuffer buf = ByteBuffer.allocate(capacity)
buf.writeInt(service.length)
buf.write(service)
buf.writeInt(indicator.length)
buf.write(indicator)
…
return buf.array()
}
属性ごとに繰り返す内容は
パターン化できる
パターンの
組み合わせ方が異なる

● 設計モデル
○ フィールドはフォーマッタのリスト
○ フォーマッタにはDecoratorパターンを適用
● 各エンティティにbyte[]の直列化に対するロールを割り当て
汎用的なツールの設計
FieldLayout RecordFormatter
AttributeFormatter FormatDecorator
SizePrefixDecorator SuffixDecorator

汎用的なツールの実装
Hive Table
Hive Table
Hive Table
HBase Table web app
HBase Table web app
● 標準的なインタフェースでKeyValueとの変換処理を提供
○ Hive Storage Handler, JDBCドライバ
○ 集計バッチやWebアプリではHBaseを意識しなくてよい
● 各アプリケーションと独立にHBaseに特化した拡張が可能
○ 対応スキーマの拡張
○ 問い合わせ処理の最適化
Hive Storage
Handler
JDBCドライバ

汎用的なツールの実装
Hive Table
Hive Table
Hive Table
HBase Table web app
HBase Table web app
● 標準的なインタフェースでKeyValueとの変換処理を提供
○ Hive Storage Handler, JDBCドライバ
○ 集計バッチやWebアプリではHBaseを意識しなくてよい
● 各アプリケーションと独立にHBaseに特化した拡張が可能
○ 対応スキーマの拡張
○ 問い合わせ処理の最適化サイロ化されたまま

● 似たようなデータでも表示形式が異なる
○ 時系列データの例
レポート形式の違い
value
time
20190318
20190319
0時 1時 2時 3時 4時
時系列の変化をみるグラフ
時間帯ごとの比較グラフ

● 元となるデータは表形式
○ 表のフォーマットが異なる
○ 表にどう整形するかを体系立てればよい
○ 描画ロジックが再利用可能になる
レポート形式の多様性
Time Value
2019-03-18 23 150
2019-03-19 00 200
Data 0時 1時 2時 ...
20190318 100 110 120 ...
20190319 200 210 220 ...

表と値のモデリング
date service action uu sum
20170306 game login 9500 N/A
20170306 game spend 2300 5200
:
● 表
○ 2種類の軸から構成
■ 絞りこみに使う軸（キー軸）
■ 取得した値を表示する
● 値
○ 一つ以上のタグで識別される
■ 既存の時系列データベースと同じ

Grafanaを一般化したイメージ
時系列以外の軸にも対
応できるように

現在の構成
Hive Table
Hive Table
Hive Table
HBase Table
HBase Table
データストア担当
フロント担当
リアルタイム集計
システム
フロントエンドのスキルのみで
可視化やUIの改善が可能
タグ付けメトリクスと
みなせれば他のシステムとの
連携も容易
データストア関連の
改善に集中できる

● "スキーマ定義に基づくSQLライクなKey-Valueストアクラ
イアント", 第8回データ工学と情報マネジメントに関する
フォーラム (DEIM2016), 2016.
● "可視化のための非構造データの表化手法", 第9回データ
工学と情報マネジメントに関するフォーラム (DEIM2017),
2017.
これまでの内容

● HBaseはその他用途以外にも存在
○ エンドユーザ向けアクセス解析システム
○ 機械学習のオフライン推論
■ など
データ参照のAPIのプロダクト化
● 前述の技術を活用しシステムの整理統合を促進したい

● 特定のパスにスキーマを定義
するのみでデータ参照APIが構
成可能
FROM zumwalt:latest
ARG VERSION
COPY config/source/* /opt/zumwalt/source/
COPY config/table/* /opt/zumwalt/table/
COPY config/record/* /opt/zumwalt/record/
COPY target/zumwalt-owned-${VERSION}.jar
/opt/zumwalt/lib/
Dockerコンテナ化
{
"attributes": [
{"name": "site_id", "isKey": true, "type": "string"}, ...
],
"schemas": [
{ "type":”hbase”, "conf": { "hbase.zookeeper.quorum": "xxx.yyyy:2181"}},
"fields": [
{"name": "table", "format": [{"type": "const", "props": {"value":
"owned_media"}}]},
{"name": "rowkey","format": [
{
"type": "suffix", "props": {"suffix": "u0000"},
"decoratee": {"type": "const", "props": {"value": "u0001"}}
},...
]
},...
}

FROM zumwalt:latest
ARG VERSION
COPY config/source/* /opt/zumwalt/source/
COPY config/table/* /opt/zumwalt/table/
COPY config/record/* /opt/zumwalt/record/
COPY target/zumwalt-owned-${VERSION}.jar
/opt/zumwalt/lib/
Dockerコンテナ化
private TableRowSet getBatchDaily(String siteId, String indicator, String
fromDate, String toDate, String type) throws IOException {
List<ZumwaltPredicate> conditions = Arrays.asList(
new EqualPredicate<>(ATTR_SITE_ID, siteId),
new EqualPredicate<>(ATTR_INDICATOR, indicator),
new EqualPredicate<>(ATTR_TYPE, type),
new BetweenPredicate<>(ATTR_DATE, fromDate, toDate)
);
return metricsService.readTableContent(OWNED_MEDIA_DAILY_TABLE,
conditions);
}
● カスタムコード
○ 単純なデータの取得であれば不要
○ 後方互換性のためのリクエスト・レスポンス形式の変換など
■ 述語オブジェクトを作成し、データ取得メソッドを呼ぶのみ

● アノテーション管理ツール
● データ転送管理システム
● 機械学習モデル管理システム
上流工程・ドメインエンジニアリングを重視
多様性を管理し持続可能性を高める
その他の取り組み

● 多様性を管理し技術的負債をうまないための取り組み
● HBase関連システムの統合における事例を紹介
まとめ

Data Engineering Meetup #1 持続可能なデータ基盤のためのデータの多様性に対する取り組み

More Related Content

What's hot

Similar to Data Engineering Meetup #1 持続可能なデータ基盤のためのデータの多様性に対する取り組み

More from cyberagent

Data Engineering Meetup #1 持続可能なデータ基盤のためのデータの多様性に対する取り組み