Databricks Certified Data Engineer Associate 教科書
第2章 データ取り込みとロード(Data Ingestion and Loading, 21%)
🎯 この節の学習目標
データエンジニアリングの最初の仕事は、社内外に散らばるデータを分析可能な形でレイクハウスに取り込むことです。Databricks では、取り込んだデータは最終的に Unity Catalog 管理下の Delta テーブル(UC-governed tables)に着地させるのが基本です。テーブルとして着地させることで、以降の変換(第3章)・オーケストレーション(第4章)・ガバナンス(第5章)がすべて統一された仕組みの上で動きます。
試験のセクション2(出題比率 21%)では、「どのソースから」「どの手段で」「どのパターンで」取り込むかの判断が問われます。まず本節で全体の地図を頭に入れ、2-2 以降で個々の手段を掘り下げます。
取り込みの「タイミングと粒度」で分類すると、次の3パターンに整理できます。
| パターン | 動き方 | 典型的な用途 | 代表的な手段 |
|---|---|---|---|
| バッチロード | ある時点のデータをまとめて一括で読み込む。実行のたびに対象範囲を自分で決める | 初回の全件ロード、日次・月次の定期取り込み | CREATE TABLE AS SELECT、spark.read、JDBC 読み取り |
| 増分ロード | 前回からの差分(新規・変更分)だけを読み込む。既処理分の記録を仕組みが持つ | クラウドストレージに日々追加されるファイルの取り込み | COPY INTO(2-2)、Auto Loader(2-3)、Lakeflow Connect(2-4) |
| ストリーミングロード | 到着するデータを継続的に処理し続ける。低遅延で反映される | センサーデータ、イベントログのリアルタイム取り込み | Structured Streaming、Auto Loader(継続実行) |
📝 試験のポイント
増分ロードの本質は「同じデータを二度処理しない仕組みを誰が持つか」です。バッチの spark.read では既処理の管理はすべて自分の責任ですが、COPY INTO はロード済みファイルの記録を、Auto Loader はチェックポイントを使って自動管理します。「毎回全件を読み直すのは無駄。新しいファイルだけ処理したい」という問題文が出たら、増分ロード(COPY INTO / Auto Loader)を選ぶのが定石です。
また、Auto Loader のようにストリーミング技術を基盤としつつ trigger(availableNow=True) で「その時点までの未処理分を処理したら停止する」というバッチ的な運用もできます。ストリーミングと増分バッチの境界は連続的であり、同じ仕組みを実行方法だけ変えて使い分けられるのが Databricks の特徴です(詳細は 2-3)。
次に「どこからデータが来るか」で整理します。試験ではソースの説明から適切な手段を選ばせる問題が中心です。
| ソースの種類 | 例 | 主な取り込み手段 |
|---|---|---|
| ローカルファイル | 手元の CSV・Excel を入れたい | 単発なら UI からのファイルアップロード、繰り返しなら Unity Catalog Volume に置いて COPY INTO / Auto Loader(下の 3-1 参照) |
| クラウドオブジェクトストレージ | S3 / ADLS / GCS 上のファイル(CSV・JSON・Parquet など) | COPY INTO(SQL・小〜中規模)、Auto Loader(大規模・継続的)、Lakeflow Connect の標準コネクタ |
| SaaS アプリケーション | 営業支援システム、会計システムなどの業務アプリ | Lakeflow Connect のマネージドコネクタ(フルマネージド取り込み) |
| リレーショナルデータベース | 業務システムの RDB(PostgreSQL、SQL Server など) | Lakeflow Connect のマネージドコネクタ、または JDBC での読み取り(2-5) |
| REST API | 外部サービスの HTTP API | ノートブックで requests 等により取得し Delta テーブルへ書き込み(2-5) |
| メッセージバス | Kafka などのイベントストリーム | Structured Streaming の Kafka ソース |
この対応関係を1枚の図にすると、次のようになります。
図:ソース種別ごとの取り込み手段と、UC 管理 Delta テーブルへの着地(矢印はいずれも UC テーブルに向かう)
どの経路をたどっても、着地点は Unity Catalog 管理下の Delta テーブルで統一されます。「ソースは多様でも出口は1つ」という構図を押さえておくと、以降の節の位置づけが明確になります。
手元のファイルをレイクハウスに入れる方法は2つあります。1つ目はワークスペース UI の「ファイルのアップロード」(Create or modify table from file upload)です。ブラウザから CSV・TSV・JSON・Excel などの小規模ファイルを選ぶだけで、プレビューで列名や型を確認しながら、そのまま Unity Catalog のテーブルとして作成(または既存テーブルへ追記・上書き)できます。コードを一切書かないため、少量のデータを単発で入れたい場面や、SQL に不慣れな非エンジニアがマスタ表・参照表を持ち込む場面に向きます。
2つ目は、ファイルをいったん Unity Catalog Volume(UC が管理するファイル置き場)へアップロードし、その Volume のパスを対象に COPY INTO(2-2)や Auto Loader(2-3)で取り込むパターンです。Volume はクラウドオブジェクトストレージと同じように「ファイルの置き場」としてパス指定でアクセスできるため、以降の取り込みはストレージ経由とまったく同じ仕組みに乗ります。ファイルが繰り返し届く運用(たとえば毎週手元に届く実績ファイルを継ぎ足す)では、こちらを選べば既処理ファイルの管理を仕組み側に任せられます。
使い分けの目安は「単発の小規模ファイルなら UI アップロード、繰り返し届くファイルなら Volume + COPY INTO / Auto Loader」です。UI アップロードは手軽な反面、毎回の手作業が前提になるため、定常的な運用パイプラインには組み込みません。
💡 具体例:同じ CSV 置き場を「バッチ」と「増分」で読む
-- (1) バッチロード:実行のたびに全ファイルを読み直す
CREATE OR REPLACE TABLE main.bronze.sales AS
SELECT * FROM read_files(
's3://my-bucket/sales/',
format => 'csv',
header => true
);
-- (2) 増分ロード:COPY INTO はロード済みファイルをスキップする
COPY INTO main.bronze.sales
FROM 's3://my-bucket/sales/'
FILEFORMAT = CSV
FORMAT_OPTIONS ('header' = 'true');(1) は毎回テーブルを作り直すため、ファイルが増えるほど処理時間もコストも膨らみます。(2) の COPY INTO は2回目以降、新しく置かれたファイルだけを追加ロードします。この「差分だけ処理する」発想が第2章全体を貫くテーマです。構文の詳細は 2-2 で扱います。
試験では、取り込み対象となる「Databricks 自身が生成するデータ」の配信仕様のような細かい知識が問われることもあります。公式サンプル問題では、Databricks 監査ログ(audit logs)の配信仕様が題材になった例があります。
📝 試験のポイント
「JSON 形式」「15分以内が典型」「上書きあり」の3点セットで覚えておきましょう。このような仕様知識は暗記するしかありませんが、裏を返せば「監査ログのようなシステム生成データも、クラウドストレージ経由で増分取り込みする対象になる」という文脈で理解しておくと記憶に残りやすくなります。
本章の以降の節は、全体マップの各経路を1つずつ掘り下げる構成です。
✅ この節のまとめ
問1. クラウドストレージに毎日数十個の CSV ファイルが追加される。毎回の処理では新しく追加されたファイルだけをテーブルに取り込みたい。この要件を最も端的に表す取り込みパターンはどれか。
正解:B
「新しく追加されたファイルだけ」という要件は増分ロードそのものです。COPY INTO や Auto Loader が既処理ファイルを記録し、未処理分だけを取り込みます。AとCは毎回全件を処理するため、データ量の増加とともに時間・コストが増大します。Dはストレージのコピーであり、テーブルへの取り込みという要件を満たしません。
問2. 営業部門が利用する SaaS アプリケーションのデータを、コードをほとんど書かずに定期的に Unity Catalog 管理下のテーブルへ取り込みたい。最も適切な手段はどれか。
正解:B
SaaS アプリケーションからのフルマネージドな取り込みは Lakeflow Connect のマネージドコネクタの守備範囲です(詳細は 2-4)。Aは手作業が毎回発生し、定期取り込みの要件に反します。CとDは誤りで、COPY INTO と Auto Loader のソースはクラウドオブジェクトストレージ上のファイルであり、SaaS アプリケーションを直接ソースにはできません。
問3. Databricks の監査ログ配信の仕様として正しい説明はどれか。
正解:B
監査ログの配信は「JSON 形式」「配信開始後15分以内が典型」「上書き(再配信)あり」の3点で押さえます。Aは形式と不変性の両方が誤り、Cは形式と周期が誤りです。Dについては、システムテーブルとして参照できる仕組みも存在しますが、「ファイルとしては取得できない」という言い切りが誤りです。
問4. Databricks におけるデータ取り込みの設計方針として最も適切なものはどれか。
正解:C
「ソースは多様でも出口は UC 管理 Delta テーブルに統一」が Databricks の基本方針です。これにより権限管理・監査・リネージ・後続の変換処理が一元化されます。Aは管理の分断を招き、Bはクラスタのローカルディスクが揮発的である点からも不適切です。Dはソースシステムへの負荷や可用性の問題があり、分析基盤にデータを取り込む目的そのものに反します。