データエンジニアリングの基礎

データエンジニアリングは、散らばったデータを集め、使える形に整え、分析やで使える場所へ届ける仕事です。DEA-C01 の問題は、ほぼすべてが「このデータを、どの速さで、どの形で、どこへ運ぶか」という判断から始まります。この章では、その判断に使う共通の言葉 (データの性質、処理の方式、保管先の役割) を整理します。

Point

DEA = Data Engineer Associate の略です。
ETL = Extract, Transform, Load (抽出・変換・ロード)、ELT = Extract, Load, Transform です。順番の違いが、変換をどこで行うかの違いになります。
和訳
- Ingestion: 取り込み
- Weblio英和辞書「ingestion」

概要

データパイプラインは、取り込み、保管、変換、提供の4つの段階でとらえると整理しやすくなります。

段階	主な AWS サービス	試験で問われる判断
取り込み	、、、、	ストリーミングかバッチか、どのソースか
保管	、、、/	アクセスパターン、コスト、性能
変換	、、、Redshift ()	データ量、処理時間、運用負荷
	、、Glue ワークフロー、	依存関係、再実行、スケジュール
提供・分析	、Redshift、、	誰が、どの頻度で、どの形で使うか

試験では、問題文の「データの量」「届く速さ」「形のばらつき」「求める鮮度」「運用負荷を減らしたいか」を読み取り、段階ごとにサービスを選びます。

主要技術

①ボリューム・速度・多様性 (3V) ⚠️ 頻出

データの性質は、3つの V で表します。どの V が厳しいかで、選ぶサービスが変わります。

V	意味	厳しいときの例	設計への影響
Volume (ボリューム)	データの量	1日に数 TB のログ	分散処理 (、 )、列指向形式、パーティション
Velocity (速度)	データが届く速さと、求める鮮度	毎秒数万件のクリックイベント	ストリーミング取り込み (、)、リアルタイム処理 ()
Variety (多様性)	形式や構造のばらつき	CSV、、画像、音声が混在	スキーマを後で決める保管 ()、カタログ (Glue Data Catalog)

3V に加えて、データの正確さ (Veracity) と価値 (Value) を挙げることもあります。データ品質の確保は、Veracity の問題として出ます。

Point

Volume = 量、Velocity = 速度、Variety = 多様性です。
Velocity は「届く速さ」だけでなく「どれだけ早く結果が欲しいか」も含むと考えると、問題文を読みやすくなります。
和訳
- Velocity: 速度
- Weblio英和辞書「velocity」
- Variety: 多様性
- Weblio英和辞書「variety」

②構造化・半構造化・非構造化データ

種類	例	保管先の例	処理の例
	のテーブル、CSV	/、
半構造化データ	、XML、、ログ	、、	()、の JSON SerDe
	画像、音声、PDF、自由記述の文章	S3	、、などで情報を取り出す

構造化データはスキーマ (列と型の定義) が先に決まっています。半構造化データは、レコードごとにフィールドの増減があり得ます。非構造化データは、そのままでは SQL で扱えないため、まず特徴や文字を取り出してから構造化します。

スキーマを書き込み時に決めるか、読み取り時に決めるかも区別します。

方式	意味	代表例
スキーマオンライト	書き込む前にスキーマを決め、合わないデータは入れない	Redshift、RDS
スキーマオンリード	生データをそのまま置き、読むときにスキーマを当てる	S3 + Glue Data Catalog + Athena

⚠️ 頻出: 形式がばらばらなデータを、まず失わずに全部ためたいなら、S3 のにそのまま置き (スキーマオンリード)、後で Glue のとカタログでスキーマを当てる構成を選びます。

③バッチ処理とストリーミング処理 ⚠️ 頻出

観点	バッチ処理	ストリーミング処理
データの単位	ある期間分をまとめて処理	1件ずつ、または数秒単位の小さなまとまり
鮮度	時間〜日単位	秒〜分単位
主なサービス	ジョブ、、の、全ロード	、、、
向くケース	日次の売上集計、月次レポート	不正検知、リアルタイムダッシュボード、IoT の監視
コストの傾向	処理する時間だけ費用がかかる	常時動くため、常時の費用がかかる

ニアリアルタイム (数十秒〜数分の遅れを許す) は、Data Firehose のバッファリングや、マイクロバッチの Glue ストリーミングジョブで満たせます。秒未満の遅れや、イベントごとの判定が必要ならストリーミング処理を選びます。

問題文に「1日1回」「夜間に」とあれば、ストリーミングの基盤を常時動かす選択肢は過剰でコスト高です。逆に「数秒以内に」とあれば、バッチは要件を満たしません。

④ETL と ELT

方式	流れ	変換の場所	向くケース
	抽出 → 変換 → ロード	、などの変換基盤	保管先に入れる前にクレンジングやの除去が必要
	抽出 → ロード → 変換	など保管先の	保管先の計算資源が強く、生データも残したい

ELT では、まずや Redshift のステージングテーブルへロードし、Redshift の SQL (INSERT INTO … SELECT、、) で変換します。ETL では、Glue ジョブで結合・クレンジングしてから書き込みます。

統合 ( やから Redshift へ自動で複製する仕組み) は、パイプラインを自分で作らずに運用データを分析側へ届ける選択肢です。詳しくは「 (CDC) と zero-ETL」の章で扱います。

⑤データレイク・データウェアハウス・レイクハウス

仕組み	特徴	AWS の典型
	形式を問わず生データを安く大量にためる。スキーマオンリード	+ Data Catalog +
(DWH)	整えたに高速な分析を行う。スキーマオンライト
	データレイクの上で DWH のようなテーブル操作 (ACID、更新、) を行う	S3 + 、、、の lakehouse

データレイクは、ゾーン (層) に分けて管理するのが一般的です。

ゾーン	内容
raw (生データ、ブロンズ)	取り込んだままのデータ。再処理の元になる
cleansed (整形済み、シルバー)	型をそろえ、重複や不正値を除き、などへ変換したデータ
curated (利用向け、ゴールド)	集計や結合を済ませ、分析やレポートでそのまま使うデータ

raw ゾーンを消さずに残すと、変換ロジックの誤りが見つかったときに、そこから作り直せます (パイプラインの再現性)。

⑥データパイプラインの品質と運用の観点

DEA では、データを動かすだけでなく、動かし続けることが問われます。

観点	具体的な手段	詳しい章
再現性	raw の保持、な書き込み、ストリームの保持期間	ストリーミング取り込みの設計
	、、ワークフロー	パイプラインのオーケストレーションの選び方
監視	の・ログ・	CloudWatch によるパイプラインの監視
データ品質	、処理中のチェック	データ品質の確保
セキュリティ	、、	各 D4 の章
コスト	列指向形式、パーティション、、スポット	データ処理の

試験対策

①判断マトリクス

問題文のキーワード	まず考える方式・サービス
数秒以内に反応、イベントごとに判定	ストリーミング (、、)
数分の遅れは許容、へためたい	(バッファリング付き配信)
1日1回、夜間にまとめて	バッチ ( ジョブ、、 )
形式がばらばら、まず全部ためる	S3 + Glue Data Catalog (スキーマオンリード)
整ったを高速に集計	Redshift ()
データレイク上で更新・削除・	、 ()
ロード後に保管先の SQL で変換	(Redshift の SQL)
保管前にの除去やクレンジング	(Glue、EMR)
パイプラインを作らず運用 DB を分析へ	統合

②よくある誤答

鮮度の要件が日次なのに、ストリーミング基盤を常時動かすこと。コストと運用負荷が増えます。
画像や PDF をに入れようとすること。の保管先はです。
に変換後のデータだけを置き、raw を消すこと。作り直しができなくなります。
データレイクとを二者択一で考えること。S3 にためて、必要な部分をへロードする、またはで S3 を直接問い合わせる組み合わせが一般的です。