スキーマレスカラムナフォーマット「Yosegi」で実現するスキーマの柔軟性と処理性能を両立したログ収集システム / Hadoop / Spark Conference Japan 2019 #hcj2019

Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.
2019年03月14日
井島洸二 / ヤフー株式会社
Hadoop / Spark Conference Japan 2019
スキーマレスカラムナフォーマット「Yosegi」で実現する
スキーマの柔軟性と処理性能を両立したログ収集システム

自己紹介
2
井島洸二
ヤフー株式会社データ&サイエンスソリューション統括本部
データプラットフォーム本部データデリバリー部所属
Data Source Storage
Processing
Ingestion Analysis
ヤフーのログを収集する領域を担当する部門
に所属
主に HDFS にログを収集し、ログを処理す
るための環境を整える仕組みを担当

アジェンダ
3
• ヤフーにおけるログ収集システム
• ログ収集システムとデータフォーマット
• Yosegi と他のデータフォーマットの違い
• ネストスキーマの課題とアプローチ
• まとめ

ヤフーにおけるログ収集システム
4
• まとめ

ヤフーのログ収集システム
5
Server
Web/App
ヤフーでは日々発生する膨大なログを HDFS に保存し利
用するための「ログ収集システム」を構築している
HDFS

ログの提供部門と利用部門
6
サービス部門データサイエンス部門
ログの仕様についての業務調整
ヤフーではデータサイエンス部門が試行錯誤を繰り返すた
め、ログの仕様変更は日々行われる

ログ収集のアプローチ
7
Schema-on-read
利用時にスキーマ定義する
収集時に制約が少ない
保存時の効率化が難しい
Schema-on-write
保存時にスキーマを定義する
収集時に制約が多い
保存時の効率化が容易
ヤフーではサービスから多種多様なログを収集するため
に、 schema-on-read のアプローチが向いている

ログ収集システムが扱っている種類と量
8
Hive のテーブル数
約900テーブル
発生するログの件数
約600億件/day
※ヤフー全体ではなく、担当システムで扱っているデータ量となります。

HDFS とデータフォーマット
9
HDFS
アクセスログ
検索ログ
購買ログ
予約・決済
etc…
定型レポート
アドホック分析
機械学習
etc…
HDFS に保存するデータフォーマットは多様なスキーマ
と膨大なログ量を考慮して選択する
多様なスキーマ膨大なログ量の処理

従来のヤフーでのログ仕様変更の対応
10
Map 本来の使い方ではなく、JSON のように任意の
key, value を入れられる設計が採用された
ログ
共通フィールド(約40項目)
Map<String,String>
Array<Map<String,>String>
サービス共通のログフィール
ドとサービスが任意に拡張で
きるフィールドを用意。
サービスA{
検索に関する情報
}
サービスB{
商品に関する情報
}
サービスC{
コンテンツに関する情報
}
拡張フィールドには Map を
使って任意の key, value を
付与できる

ログ収集システムとデータフォーマット
11
• まとめ

保存時のデータフォーマットの要件
12
保存時のフォーマットに求められる事
複雑なスキーマを扱える
スキーマの変更に強い
読み込みの処理性能が良い

データフォーマットの選択肢
13
多様なスキーマを扱え、変更に強い
JSON
処理性能が良い
カラムナフォーマット（ORC, Parquet）

JSON
14
ルールベースで記述されているテキスト
→ スキーマを必要としない
複雑なデータ構造も表現可能

JSON の Hive テーブルの定義
15
読みたいデータ構造でテーブルを定義テーブル定義にあわせて JSON から読み込まれる
JSON ではフィールドの順序を持たないため、Key 名で
データが参照される。

JSON のスキーマの更新業務
16
サービス担当データ利用担当
1.ログ仕様の変更依頼
2-1.ログ仕様の更新 2-2.テーブル定義の更新
ログ仕様の更新とテーブル定義の更新は同時に行わなくても良い

Hive における JSON テーブルの更新
17
Replace Columns には対応していない
カラム単体で追加や更新をしなければならない
FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Replace
columns is not supported for table json_table_1. SerDe may be incompatible.
カラムの更新は制約が多いので、テーブルを作成しなおすか、
別にテーブルを作成してしまった方が早い
This can be done only for tables with a native SerDe (DynamicSerDe, MetadataTypedColumnsetSerDe,
LazySimpleSerDe and ColumnarSerDe).
引用： https://cwiki.apache.org/confluence/display/Hive/SerDe

JSON を利用したログ収集システム
18
API
Request JSON
message
ETL
HDFS
JSON
message
Processing
・HDFS へのアップロード
・パーティショニング
JSON をそのまま HDFS に保存するシンプルな構成が可能
JSON
File

JSON を利用した場合の課題
19
CPUリソースが枯渇
圧縮の展開
テキストのパース
スキーマの柔軟性はあるが処理数を増やすことができない

カラムナフォーマット
20
カラム方向でデータを格納、利用する
Apache Parquet , Apache ORC など
JSON などカラムナフォーマット

カラムナフォーマットの特徴
21
Pushdown による列、行のスキップ
圧縮の展開やパースの CPU リソースの
削減
カラム毎のエンコーディングと圧縮
データサイズが小さくなる

0
100
200
300
400
500
600
700
JSON Parquet
Hive クエリの CPU TIME(min)
自社データでの JSON との比較
22
※1：圧縮は gzip を利用
※2：root 直下のカラム数30あるうちの2カラムを処理
かなりのCPU リソース
が削減される ※2
0
20
40
60
80
100
JSON Parquet
データサイズ(GB) ※1
今回のデータではそこ
まで差はなかった

読み込まれたデータ量とプロファイル
23
必要なカラムのみが読み出されている
JSON Parquet
圧縮のCPUリソースが削減されていることが分かる
JSON Parquet

カラムナフォーマットとスキーマ
24
パーサーログ
{
col1: val1,
col2: val2,
clo3: val3
}
スキーマからデータ
を格納するカラムを
事前に作成する必要
がある。
スキーマ

Hive でのカラムの参照の方法
25
カラムのインデクス（順序）でデータにアクセス
カラム名を変更できる
カラムの名前でデータにアクセス
柔軟なテーブルスキーマの更新が可能
カラム名は変更できない
参考：https://docs.aws.amazon.com/ja_jp/athena/latest/ug/handling-schema-updates-chapter.html#index-access

カラムナフォーマットの Hive テーブルの更新
26
読み込むカラムを指定するテーブル定義にあわせてデータが読み込まれる
カラム名で読み込まれるが、データの型は実データとあわ
せる必要がある

カラムナフォーマットのテーブルの更新
27
Replace column が使えるため、簡単なコマンドでテーブルを更新でき
る。

スキーマ更新の業務
28
2-1-1. 変換用のスキーマの登録/更新
2-1-2.ログ仕様の更新
2-2.テーブル定義の更新
2-1,2-2の作業は個別に実施してもシステムに影響はない

カラムナフォーマットを利用したログ収集システム
29
・カラムナフォーマットへの変換
API
Request JSON
message
ETL HDFS
JSON
message
Processing
事前に最終出力のスキーマ情報を登録・更新しなければならな
い。システムは同期して ETL に反映する仕組みが必要。
Schema registryサービス担当
・データの設計
・スキーマの管理

カラムナフォーマットでの変化
30
Schema-on-read Schema-on-write
Hadoop 初期カラムナフォーマット登場以降
カラムナフォーマットの登場により、ログ収集システムは
Schema-on-write のアーキテクチャとなった

カラムナフォーマットを利用した場合の課題
31
カラムナフォーマットはスキーマが必要
事前のログ設計
変換スキーマ管理の仕組
スキーマの管理とシステム内でスキーマの同期が必要となり、
多様なログを収集する弊害となる

スキーマの柔軟性と保存、処理性能の整理
32
大項目小項目概要
スキーマ変更の強さ
ルールベースでの書き込み
(スキーマレス)
スキーマを使わずにルールベースでデータの
保持と復元ができる
要素名でのアクセスフィールドをカラム名でアクセスできる
要素の存在の有無に関わらないアクセス
要素の有無に関わらずフィールドにアクセス
できる
複雑なデータ構造の定義ネストスキーマの定義ネストを含む複雑なデータ構造を定義できる
保存、処理性能
データサイズ保存時のデータサイズ
書き込み性能書き込みの性能
読み込み性能
読み込みの性能

フォーマットの比較
33
大項目小項目 JSON ORC Parquet
(スキーマレス)
○ × ×
要素名でのアクセス ○ ○ ○
要素の存在の有無に関わらないアクセス ○
△
データ参照側
で実装
△
データ参照側
で実装
複雑なデータ構造の定義ネストスキーマの定義 ○ ○ ○
データサイズ △ △ ○
書き込み性能 △ ○ △
読み込み性能 × ○ ○

Yosegi と他のデータフォーマットの違い
34
• まとめ

ヤフーのログ収集システムに求められる事
35
Hadoop 導入初期カラムナフォーマット登場以降
Schema-on-read
書き込みのスキーマレス +
高処理効率
schema-on-read を実現するために書き込みのスキーマ
レスと、高い処理効率が求められる。

スキーマレスカラムナーフォーマットの開発
36
これまでの背景を課題感に「Yosegi」を
開発し OSS として公開。

「Yosegi」とは
37
ヤフーがOSSとして公開しているスキーマレスカラムナフォーマット
• スキーマレスな読み書き
• カラムナフォーマットの高い圧縮率と高い処理性能

カラムナフォーマットの特徴
38
• カラム単位の書き込み・読み込み
• Pushdown のサポート
• カラム単位のエンコーディング、圧縮
• etc…

データサイズと書き込み性能の比較
39
0
500
1000
1500
2000
part customer partsupp orders lineitem
TPC-H 1000 書き込みの CPU TIME(min)
Yosegi ORC Parquet
ORC が書き込みにおいては早い。今回は gzip で比較を行っているが、ORC はバイナリのタイ
プによって圧縮レベルを低くしている。そのため、データサイズが少し大きくなっている。
0
50
100
150
200
250
300
Yosegi ORC Parquet
TPC-H 1000 データサイズ(GB)

処理性能の比較
40
0
200
400
600
800
1000
1200
1400
1600
1800
q6 q16 q14 q1 q15 q11 q22 q2 q12 q20 q13 q10 q4 q3 q7 q8 q5 q9 q17 q18 q21
TPC-H 1000 CPU TIME(min)
Yosegi Apache ORC Apache parquet
処理性能は他のカラムナフォーマットと同等

スキーマレスなカラム構築
41
{“col3”: “val”}
{“col1”: “val”, “col5”: “val”}
{“col2”: “val”, “col4”: “val”, “col5”:
“val”} 入力データ
内部データ
col2,col4 を
動的に追加
col1,col5 を
動的に追加

ルールベースのカラムデータ書きこみ
42
col1[0] col1[1] col1[2]
col2[0] col2[2]
col3[0] col3[1] col3[2]
Root
col1 col2 col3
[0]
[1]
[2]
[0]
[2]
[0]
[1]
[2]
カラム名で木構造を作成。
各ノードには同じカラム名
のカラムを配列で保持する
書き込み処理
木構造のデータを各ノード毎にバイト
配列として書き出す。
メタと実データは分離し、読み込みの
際はメタを読み込みデータ構造を復元
する。
実データ領域

Map 型の扱い
43
Yosegi では Map 型は存在せず、データ構造は Struct となる
Map 型で参照した場合には以下の制約がある
１．Key の存在の有無が判定できない
２．Key が無くて NULL か、value が NULL か区別できない
３．カラム名で構成されるため Key は String 型のみ

フォーマットの比較
44
大項目小項目 JSON ORC Parquet Yosegi
（スキーマレス）
○ × × ○
要素名でのアクセス ○ ○ ○ ○
要素の存在の有無に関わらないアクセ
ス
○
△
データ参照側
で実装
△
データ参照側
で実装
○
複雑なデータ構造の定義ネストスキーマの定義 ○ ○ ○ ○
データサイズ △ △ ○ ○
書き込み性能 △ ○ △ △
読み込み性能 × ○ ○ ○

Yosegi の Hive テーブル更新
45
JSON と同様に Replace Columns は使えない。
Hive の「DDLTask」で許可されている SerDe
のクラス名がハードコードされている。
現時点では JSON 同様にテーブルの再作成をし
た方が早い

スキーマの更新業務
46
2-1.ログ仕様の更新 2-2.テーブル定義の更新
ログ仕様の更新とテーブル定義の更新は同時に行わなくても良
い。

Yosegi を利用したログ収集システム
47
API
Request JSON
message
ETL
HDFS
JSON
message
Processing
・Yosegi への変換
JSON と同様にシンプルなログ収集システムが構築可能
Yosegi
File
Schema registry

実現したこと
48
Schema-on-read
Yosegi
「Yosegi」により Schema-on-read のアーキテクチャと
高い処理性能の両立を実現

ネストスキーマの課題とアプローチ
49
• まとめ

従来のヤフーでのログ仕様変更の対応
50
Map 本来の使い方ではなく、JSON のように任意の
key, value を入れられる設計が採用された
ログ
共通フィールド(約40項目)
Map<String,String>
Array<Map<String,>String>
サービス共通のログフィール
ドとサービスが任意に拡張で
きるフィールドを用意。
サービスA{
検索に関する情報
}
サービスB{
商品に関する情報
}
サービスC{
コンテンツに関する情報
}
拡張フィールドには Map を
使って任意の key, value を
付与できる

Map型の項目追加と参照
51
Map 型で便利フィールドを作り、入力データのスキーマとテーブ
ル更新を不要にしてしまう方法
データを入れる側、使う側でスキーマの変更をしなくてよいので
業務への負担が少ない
CREATE TABLE t_1(
option MAP<STRING,STRING>
)
SELECT option[“opt1”] …
SELECT option[“opt2”] …
参照したい Key を指定するだけ
“option” : {
“opt1” : “value” ,
“opt2” : “value” ,
…
}
任意の key, value を
セットするだけ
このフィールドへの項目追加は
テーブルを変更しなくて良い

肥大化する Map フィールド
52
この便利フィールドを使うことにより、日々
のログ仕様の変更の業務負荷を軽減している
(任意のフィールドについては管理していないとも言える)
Map に含まれるユニーク key 数
約3500Key

Map型のデメリット
53
カラムナフォーマットのメリットである必要なカラムを処
理するというメリットが無くなってしまう
Array
Index
Key
Array
Value
Array
0 KEY-A v
1 KEY-B v
2 KEY-D v
3 KEY-B v
4 KEY-C v
5 KEY-A v
6 KEY-D v
MAP{ KEY-A :v , KEY-B:v , KEY-D:v }
MAP{ KEY-B:v , KEY-C:v }
MAP{ KEY-A :v , KEY-D:v }
全ての Key, Value が読み込まれ、
特定の Key のみを読み込むのが困難
Key, Value の配列から Map
のデータ構造を個別に生成

ヤフーでの Map 多用の影響
54
Map を多用したせいで以下の二点に影響を
与えている
・カラムナフォーマットを採用しても CPU
リソース削減がいまいちだった
・Map を前提にしたログ設計が慣習的に
なってしまった

クエリエンジンとネストスキーマ
55
クエリエンジンはネストスキーマの Pushdown が対応していない事が多い
（各 OSS の ISSUE で見かけるので対応は進んでいると思われる）
timestamp
(BIGINT)
Items
(Struct)
item_id
(STRING)
price
(BIGINT)
number
(INT)
15167737
62
I_005 350 2
SELECT
items.price
WHERE
…
処理に必要なカラムは items.price でも親の items 以下全てのカラムが読み込まれる

処理効率が良いスキーマ
56
timestamp
(BIGINT)
Items_item_id
(STRING)
Items_price
(BIGINT)
Items_number
(INT)
1516773762 I_005 350 2
timestamp
(BIGINT)
Items
(Struct)
item_id
(STRING)
price
(BIGINT)
number
(INT)
1516773762 I_005 350 2
SELECT
items_price
WHERE
…
フラットなスキーマに変更
SELECT
items.price
WHERE
…
ネストスキーマではなくフラットなスキーマでログを設計する

フラットなスキーマは困難
57
フラットなスキーマにするためには、正
規化が必要となるが、ロギング時に正規
化するのは現実的でない
結果ネストスキーマでの実装が自然とな
る

ヤフーでの課題
58
Map型の運用軽減を目的にした利用
クエリエンジンはネストスキーマが苦手
フラットスキーマのロギングが困難

Yosegi でのアプローチ
59
ファイルを読み込むときに、ネストスキーマをフラットスキーマとして読
み込めれば、クエリエンジンで pushdown が有効になる
timestamp
(BIGINT)
total_price
(BIGINT)
Items
(ARRAY)
Items
(Struct)
item_id
(STRING)
price
(BIGINT)
number
(INT)
1516773762 1000
I_001 300 1
I_005 350 2
timestamp
(BIGINT)
total_price
(BIGINT)
item_id
(STRING)
price
(BIGINT)
number
(INT)
1516773762 1000 I_001 300 1
1516773762 1000 I_005 350 2
Array
展開のSQL
SQL
Yosegi File

Expand & Flatten
60
timestamp
(BIGINT)
total_price
(BIGINT)
Items
(STRUCT)
item_id
(STRING)
price
(BIGINT)
number
(INT)
1516773762 1000 I_001 300 1
1516773762 1000 I_005 350 2
1516773765 200 I_002 50 4
読み込み処理
クエリエンジンtimestamp
(BIGINT)
total_price
(BIGINT)
Items
(ARRAY)
Items
(Struct)
item_id
(STRING)
price
(BIGINT)
number
(INT)
1516773762 1000
I_001 300 1
I_005 350 2
1516773765 200 I_002 50 4
Expand , Flatten を設定
timestamp
(BIGINT)
total_price
(BIGINT)
item_id
(STRING)
price
(BIGINT)
number
(INT)
1516773762 1000 I_001 300 1
1516773762 1000 I_005 350 2
1516773765 200 I_002 50 4
Expand : ‘items’
Flatten :
items.item_id -> item_id
items.price -> price
items.number -> number
Expand
Flatten

読み込みの処理性能
61
0
500
1000
1500
2000
2500
3000
Nest schema Expand & Flatten
CPU TIME(min)
90% down
※自社内のログでの性能比較

ユースケース
62
HDFS
Processing
データ利用担当
Map を含むネストス
キーマのテーブル
フラットスキーマの
テーブル
低頻度な試験的を行うために運用
コストが低いテーブル定義
定常的な処理や高頻度に実行され
る処理性能優先のテーブル定義
ネストスキーマのデータ設計でも運用負荷と処理性能のバ
ランスを取ることができる

まとめ
63
• まとめ

schema-on-read と処理性能の両立
64
Schema-on-read
Yosegi
「Yosegi」によりスキーマの柔軟性と高い処理性能を両立
しつつ、スキーマ管理が不要なログ収集システムを実現

ネストスキーマへの対応
65
ネストスキーマをフラットスキーマとして読み込むことによ
り、クエリエンジンの Pushdown を有効にする
timestamp
(BIGINT)
total_price
(BIGINT)
Items
(ARRAY)
Items
(Struct)
item_id
(STRING)
price
(BIGINT)
number
(INT)
1516773762 1000
I_001 300 1
I_005 350 2
timestamp
(BIGINT)
total_price
(BIGINT)
item_id
(STRING)
price
(BIGINT)
number
(INT)
1516773762 1000 I_001 300 1
1516773762 1000 I_005 350 2
Array
展開のSQL
SQL
Yosegi File

さいごに
66
Yosegi はたくさんの人に使ってもらい改善
をしていきたいと考えています。
メーリングリストもありますので、なんでも
気軽に連絡ください。
■ 参考資料
- GitHub:
https://github.com/yahoojapan/yosegi
- Tech Blog:
https://techblog.yahoo.co.jp/oss/introduction_of_datalake_and_mds/
※Multiple Dimension Spread(MDS)は Yosegi の旧プロダクト名となります。

スキーマレスカラムナフォーマット「Yosegi」で実現するスキーマの柔軟性と処理性能を両立したログ収集システム / Hadoop / Spark Conference Japan 2019 #hcj2019

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to スキーマレスカラムナフォーマット「Yosegi」で実現するスキーマの柔軟性と処理性能を両立したログ収集システム / Hadoop / Spark Conference Japan 2019 #hcj2019

Similar to スキーマレスカラムナフォーマット「Yosegi」で実現するスキーマの柔軟性と処理性能を両立したログ収集システム / Hadoop / Spark Conference Japan 2019 #hcj2019 (20)

More from Yahoo!デベロッパーネットワーク

More from Yahoo!デベロッパーネットワーク (20)

Recently uploaded

Recently uploaded (12)