Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
[輪読会]実践的データ基盤への処方箋
Search
Toshiki Tsuchikawa
February 03, 2022
0
290
[輪読会]実践的データ基盤への処方箋
2-1〜2-4章のまとめになります。
Toshiki Tsuchikawa
February 03, 2022
Tweet
Share
More Decks by Toshiki Tsuchikawa
See All by Toshiki Tsuchikawa
タイミーのデータ活用を支えるdbt Cloud導入とこれから
ttccddtoki
2
690
タイミーにおけるデータ活用の未来
ttccddtoki
0
120
急成長する組織を支えるデータ基盤のこれまで、これから
ttccddtoki
6
750
アジリティの高いデータ基盤を目指して
ttccddtoki
4
1.6k
DMBOKを参考にしたデータマネジメントの取り組み
ttccddtoki
6
2.7k
dbt_Cloudとdbt_Core併用の試み
ttccddtoki
3
1.4k
データ品質を重視したデータ基盤プロダクト開発
ttccddtoki
8
2.4k
タイミーの未来を支えるデータ基盤プロダクト
ttccddtoki
1
860
datatech-jp Casual Talks #3
ttccddtoki
0
1.1k
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
230
18k
What's in a price? How to price your products and services
michaelherold
245
12k
VelocityConf: Rendering Performance Case Studies
addyosmani
329
24k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Site-Speed That Sticks
csswizardry
5
500
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.2k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
How to Ace a Technical Interview
jacobian
276
23k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Unsuck your backbone
ammeep
670
57k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Transcript
2022/02/03 土川 稔生 [輪読会]実践的データ基盤への処方箋 @tvtg_24 1 2-1 〜 2-4章
土川 稔生 (Tsuchikawa Toshiki) • 愛知県名古屋市出身 • 2020年 東工大情報理工学院卒 •
株式会社タイミー ◦ DRE (Data Reliability Engineering) チーム ◦ データ基盤の開発・保守・運用 ◦ 分析基盤の開発・保守・運用 • Twitter @tvtg_24 2 自己紹介
目次 • 一般的なデータ基盤の全体像と分散処理の必要性を理解する • データソースごとに収集方法が違うこと、その難しさを理解する • ファイルを収集する場合は最適なデータフォーマットを選択する • APIのデータ収集では有効期限や回数制限に気をつける 3
4 一般的なデータ基盤の全体像と分散処理の必要性を理解する データ基盤のつくり方は一般化されてきた • 2010年頃は、多くの企業にとって聞き慣れないものだった • 2021年時点では、多くの企業がデータ分析を行っており、データ基盤も一般的に • 背景には、ハードウェアとソフトウェアの発展が要因にあると考えられる ◦
ハードウェア: パブリッククラウド ◦ ソフトウェア: Apache Hadoop など
5 一般的なデータ基盤の全体像と分散処理の必要性を理解する データ基盤を構成するシステムコンポーネント
6 一般的なデータ基盤の全体像と分散処理の必要性を理解する データ基盤を構成するシステムコンポーネント • データウェアハウス生成処理の例 ◦ JSON データをテーブルデータに変換する ◦ 数値や日付の表現方法をそろえる
◦ 個人情報を除去する ◦ 同じ意味でも異なった表現方法になっている データを紐付ける など • データウェアハウスのデータはデータ分析において最 も利用される中心的なデータとなる ◦ 適切なアクセスコントロール、ユーザインター フェースを整備する必要がある
7 一般的なデータ基盤の全体像と分散処理の必要性を理解する 大量のデータには分散処理が必要 • 各コンポーネントの作り方はデータのサイズに依 存する • 右側の図の例は集計に関する分散処理につい てだが、収集や蓄積においても分散処理が必要 となる
• データ活用が進むと大量のデータを処理する必 要があるため、あらかじめ分散処理を前提にし ておくことは重要
8 データソースごとに収集方法が違うこと、 その難しさを理解する データ収集は難しい • データ収集はデータ基盤の中で最も取り扱いの難しいコンポーネントである ◦ データソースの種類 (ストレージ、データベースなど) によって使う技術、ツールが異なる
◦ 企業の業務遂行上、データベースに負荷がかけられないなどの問題もある ◦ データ量、データの性質によっても収集方法が変わる • 安定した収集システムの構築のための技術、ノウハウをこれから紹介していく
9 データソースごとに収集方法が違うこと、 その難しさを理解する データソースの種類ごとの収集方法
10 データソースごとに収集方法が違うこと、 その難しさを理解する フェデレーション • データソースにあるデータを直接分析に利用する 技術 • データを収集せずに分析に利用できる •
データソースとデータウェアハウスにあるデータを 掛け合わせることができる • データソースに意図せず負荷を与えてしまう可能 性がある • 製品例としては、Amazon Redshiftの横串検索や BigQueryのCloud SQL連携クエリがある
11 ファイルを収集する場合は最適なデータフォーマットを選択する ファイルデータの収集方法 • ファイルデータの例としては、もともとファイルでしか提供されていない音声、画像、動画、csvファイルなどがある • ファイルシステムとは別に配置の完了を通知するしくみをつくることがポイント ◦ データ基盤側が書き込んでいる途中のファイルを間違って収集してしまうのを防ぐ ◦
通知機能の製品例としてはAmazon S3のイベント通知や、Google Cloud Storageトリガーなど • キューが準備できない時は「トリガファイル」をファイルシステムに配置する方法もある
12 ファイルを収集する場合は最適なデータフォーマットを選択する ファイルの中身を厳格に管理したい場合はデータ構造も一緒に収集する • ファイル収集でファイルの中身が想定と変わってしまうことがよく問題になる ◦ これを回避するためには、データの中身だけでなくデータの構造も一緒に収集する • 収集対象のデータがJSON の場合はJSON
Schema、XMLの場合はXML Schemaでデータ構造を定義できる
13 ファイルを収集する場合は最適なデータフォーマットを選択する ファイルの中身を厳格に管理したい場合はデータ構造も一緒に収集する • よりデータ構造を厳格に管理したいと場合は Apache AVROを用いる • AVROはデータ構造定義ファイルがないとデータの生成 すらできないため、データを生成する時点でデータ構造
の不正に気づくことができる • デメリットとして、バイナリフォーマットなのでデータの中 身を確認することが困難である点がある
14 ファイルを収集する場合は最適なデータフォーマットを選択する データの量を減らしたい場合は Parquet を検討する • ファイルデータを収集するなかでよく問題になるのがデータ量である • そこで、Apache Parquet
(パーケット) の出番である ◦ データをバイナリで表現するため、すべてをテキストで表現するCSVやJSONと比べて、データサイズが小さ い ◦ 「列指向圧縮」である → 詳細は2-15節で ◦ データレイクに収集したParquetファイルをデータウェアハウスに取り込む場合に、CSVやJSONのファイルを 取り込むよりも早く取り込める ◦ デメリットはAVROと同様、バイナリフォーマットなのでデータの中身の確認が困難なこと
15 APIのデータ収集では有効期限や回数制限に気をつける API によるデータ収集とは • API(Application Programming Interface)は、一般的にはアプリケーションとアプリケーションをプログラムでつなぐ 際の取り決めを意味する ◦
API エンドポイントとデータフォーマットのことを意味することが多い • API エンドポイントとは、「https://example.com/xxx_data」といった URL のような文字列で表し、データを取り出す 場所とその方法を示す • データフォーマットとは、文字通りこのAPIから取得できるデータの形式を意味する
16 APIのデータ収集では有効期限や回数制限に気をつける API からデータを収集する方法 • この収集処理ではAPIキーを指定して受け取ったJSONをデータレイクにそのままファイルとして格納する • APIキーは、APIの利用者ごとに発行されるのようなもので、APIキーがないとAPIを利用できないことが多い
17 APIのデータ収集では有効期限や回数制限に気をつける API 実行回数制限や API キーの有効期限に注意 • APIを利用する際にはAPIの実行回数制限に注意する ◦ 実行回数制限とは、一定時間にリクエストできる回数を制限するしくみ
◦ リクエスト数を制限し、APIのシステムにかかる負荷を一定に抑えている ◦ 事前にAPI実行回数を見積もり、利用回数制限以内で実施できるように設計する ◦ APIの運用会社が実行回数制限の緩和について相談に乗ってくれることが多い • APIキーの有効期限にも注意する ◦ ある日突然APIキーの有効期限が切れてデータ取得が失敗することになる