[輪読会]実践的データ基盤への処方箋

2-1〜2-4章のまとめになります。

Transcript

1. 2022/02/03　土川 稔生 [輪読会]実践的データ基盤への処方箋 @tvtg_24 1 2-1 〜 2-4章
2. 土川 稔生 (Tsuchikawa Toshiki) • 愛知県名古屋市出身 • 2020年 東工大情報理工学院卒 • 株式会社タイミー ◦ DRE (Data Reliability Engineering) チーム ◦ データ基盤の開発・保守・運用 ◦ 分析基盤の開発・保守・運用 • Twitter @tvtg_24 2 自己紹介
3. 目次 • 一般的なデータ基盤の全体像と分散処理の必要性を理解する • データソースごとに収集方法が違うこと、その難しさを理解する • ファイルを収集する場合は最適なデータフォーマットを選択する • APIのデータ収集では有効期限や回数制限に気をつける 3
4. 4 一般的なデータ基盤の全体像と分散処理の必要性を理解する データ基盤のつくり方は一般化されてきた • 2010年頃は、多くの企業にとって聞き慣れないものだった • 2021年時点では、多くの企業がデータ分析を行っており、データ基盤も一般的に • 背景には、ハードウェアとソフトウェアの発展が要因にあると考えられる ◦ ハードウェア: パブリッククラウド ◦ ソフトウェア: Apache Hadoop など
5. 5 一般的なデータ基盤の全体像と分散処理の必要性を理解する データ基盤を構成するシステムコンポーネント
6. 6 一般的なデータ基盤の全体像と分散処理の必要性を理解する データ基盤を構成するシステムコンポーネント • データウェアハウス生成処理の例 ◦ JSON データをテーブルデータに変換する ◦ 数値や日付の表現方法をそろえる ◦ 個人情報を除去する ◦ 同じ意味でも異なった表現方法になっている データを紐付ける など • データウェアハウスのデータはデータ分析において最 も利用される中心的なデータとなる ◦ 適切なアクセスコントロール、ユーザインター フェースを整備する必要がある
7. 7 一般的なデータ基盤の全体像と分散処理の必要性を理解する 大量のデータには分散処理が必要 • 各コンポーネントの作り方はデータのサイズに依 存する • 右側の図の例は集計に関する分散処理につい てだが、収集や蓄積においても分散処理が必要 となる • データ活用が進むと大量のデータを処理する必 要があるため、あらかじめ分散処理を前提にし ておくことは重要
8. 8 データソースごとに収集方法が違うこと、 その難しさを理解する データ収集は難しい • データ収集はデータ基盤の中で最も取り扱いの難しいコンポーネントである ◦ データソースの種類 (ストレージ、データベースなど) によって使う技術、ツールが異なる ◦ 企業の業務遂行上、データベースに負荷がかけられないなどの問題もある ◦ データ量、データの性質によっても収集方法が変わる • 安定した収集システムの構築のための技術、ノウハウをこれから紹介していく
9. 9 データソースごとに収集方法が違うこと、 その難しさを理解する データソースの種類ごとの収集方法
10. 10 データソースごとに収集方法が違うこと、 その難しさを理解する フェデレーション • データソースにあるデータを直接分析に利用する 技術 • データを収集せずに分析に利用できる • データソースとデータウェアハウスにあるデータを 掛け合わせることができる • データソースに意図せず負荷を与えてしまう可能 性がある • 製品例としては、Amazon Redshiftの横串検索や BigQueryのCloud SQL連携クエリがある
11. 11 ファイルを収集する場合は最適なデータフォーマットを選択する ファイルデータの収集方法 • ファイルデータの例としては、もともとファイルでしか提供されていない音声、画像、動画、csvファイルなどがある • ファイルシステムとは別に配置の完了を通知するしくみをつくることがポイント ◦ データ基盤側が書き込んでいる途中のファイルを間違って収集してしまうのを防ぐ ◦ 通知機能の製品例としてはAmazon S3のイベント通知や、Google Cloud Storageトリガーなど • キューが準備できない時は「トリガファイル」をファイルシステムに配置する方法もある
12. 12 ファイルを収集する場合は最適なデータフォーマットを選択する ファイルの中身を厳格に管理したい場合はデータ構造も一緒に収集する • ファイル収集でファイルの中身が想定と変わってしまうことがよく問題になる ◦ これを回避するためには、データの中身だけでなくデータの構造も一緒に収集する • 収集対象のデータがJSON の場合はJSON Schema、XMLの場合はXML Schemaでデータ構造を定義できる
13. 13 ファイルを収集する場合は最適なデータフォーマットを選択する ファイルの中身を厳格に管理したい場合はデータ構造も一緒に収集する • よりデータ構造を厳格に管理したいと場合は Apache AVROを用いる • AVROはデータ構造定義ファイルがないとデータの生成 すらできないため、データを生成する時点でデータ構造 の不正に気づくことができる • デメリットとして、バイナリフォーマットなのでデータの中 身を確認することが困難である点がある
14. 14 ファイルを収集する場合は最適なデータフォーマットを選択する データの量を減らしたい場合は Parquet を検討する • ファイルデータを収集するなかでよく問題になるのがデータ量である • そこで、Apache Parquet (パーケット) の出番である ◦ データをバイナリで表現するため、すべてをテキストで表現するCSVやJSONと比べて、データサイズが小さ い ◦ 「列指向圧縮」である → 詳細は2-15節で ◦ データレイクに収集したParquetファイルをデータウェアハウスに取り込む場合に、CSVやJSONのファイルを 取り込むよりも早く取り込める ◦ デメリットはAVROと同様、バイナリフォーマットなのでデータの中身の確認が困難なこと
15. 15 APIのデータ収集では有効期限や回数制限に気をつける API によるデータ収集とは • API(Application Programming Interface)は、一般的にはアプリケーションとアプリケーションをプログラムでつなぐ 際の取り決めを意味する ◦ API エンドポイントとデータフォーマットのことを意味することが多い • API エンドポイントとは、「https://example.com/xxx_data」といった URL のような文字列で表し、データを取り出す 場所とその方法を示す • データフォーマットとは、文字通りこのAPIから取得できるデータの形式を意味する
16. 16 APIのデータ収集では有効期限や回数制限に気をつける API からデータを収集する方法 • この収集処理ではAPIキーを指定して受け取ったJSONをデータレイクにそのままファイルとして格納する • APIキーは、APIの利用者ごとに発行されるのようなもので、APIキーがないとAPIを利用できないことが多い
17. 17 APIのデータ収集では有効期限や回数制限に気をつける API 実行回数制限や API キーの有効期限に注意 • APIを利用する際にはAPIの実行回数制限に注意する ◦ 実行回数制限とは、一定時間にリクエストできる回数を制限するしくみ ◦ リクエスト数を制限し、APIのシステムにかかる負荷を一定に抑えている ◦ 事前にAPI実行回数を見積もり、利用回数制限以内で実施できるように設計する ◦ APIの運用会社が実行回数制限の緩和について相談に乗ってくれることが多い • APIキーの有効期限にも注意する ◦ ある日突然APIキーの有効期限が切れてデータ取得が失敗することになる