- Published on
Databricks AI Engineer(FDE)完全合格ガイド:Spark、Unity Catalog、RAGから顧客デプロイまで
- Authors

- Name
- Youngju Kim
- @fjvbn20031
- 1. DatabricksとFDEチームの理解(りかい)
- 2. JD(Job Description)詳細(しょうさい)分析(ぶんせき)
- 3. 技術ディープダイブ
- 4. 面接(めんせつ)予想質問(しつもん)25選(せん)
- 5. 8ヶ月学習ロードマップ
- 6. 資格証ガイド
- 7. ポートフォリオプロジェクト3つ
- 8. クイズ
- 9. 参考(さんこう)資料(しりょう)
- まとめ
1. DatabricksとFDEチームの理解(りかい)
Databricksとは何(なに)か
Databricksは2013年にUC BerkeleyのAMPLabから誕生(たんじょう)したデータ+AIプラットフォーム企業(きぎょう)です。Apache Sparkの創始者(そうししゃ)たち(Ali Ghodsi、Matei Zahariaなど)が共同創業(きょうどうそうぎょう)し、2024年基準(きじゅん)で企業価値(かち)約(やく)620億(おく)ドルと、世界(せかい)で最(もっと)も価値のある非上場(ひじょうじょう)AI企業の一(ひと)つです。
Databricksの核心的(かくしんてき)イノベーション:
- Apache Spark創始:ビッグデータ処理(しょり)の事実上(じじつじょう)の標準(ひょうじゅん)となった分散(ぶんさん)コンピューティングフレームワーク
- Lakehouse Architecture発明(はつめい):Data Lakeの柔軟性(じゅうなんせい)とData Warehouseの安定性(あんていせい)を組(く)み合(あ)わせた次世代(じせだい)アーキテクチャ
- Delta Lakeオープンソース化:ACIDトランザクションをサポートするストレージレイヤー
- Unity Catalog:データ、AIモデル、フィーチャーを統合管理(かんり)するガバナンスプラットフォーム
- Mosaic AI:2024年のMosaicML買収(ばいしゅう)後(ご)に統合されたAI/MLプラットフォームブランド
企業規模(きぼ)と成長(せいちょう):
- ARR(Annual Recurring Revenue)約16億ドル(2024年)
- 顧客(こきゃく)10,000社(しゃ)以上(いじょう)、Fortune 500の60%以上が利用(りよう)
- 従業員(じゅうぎょういん)7,000名(めい)以上、世界30以上のオフィス
- AWS、Azure、GCPの3クラウドすべてで運営(うんえい)される唯一(ゆいいつ)のLakehouseプラットフォーム
FDE(Forward Deployed Engineer)チームとは
DatabricksのFDEチームはProfessional Services組織(そしき)内(ない)の核心エンジニアリングチームです。顧客現場(げんば)で直接(ちょくせつ)Databricksプラットフォームを構築(こうちく)・最適化(さいてきか)し、最(もっと)も複雑(ふくざつ)なデータ/AI課題(かだい)を解決(かいけつ)する役割(やくわり)を担(にな)います。
FDEの核心ミッション:
- エンタープライズ顧客のデータプラットフォームをDatabricks Lakehouseへマイグレーション
- 顧客環境(かんきょう)に最適化されたRAG/AIパイプライン構築
- パフォーマンス最適化:Sparkジョブチューニング、コスト最適化、アーキテクチャ改善(かいぜん)
- 技術(ぎじゅつ)伝達(でんたつ):顧客エンジニアリングチームの能力(のうりょく)向上(こうじょう)支援(しえん)
FDE vs Field Engineer vs Solutions Architect
この3つの役割はよく混同(こんどう)されますが、責任(せきにん)と性質(せいしつ)が異(こと)なります。
| 区分(くぶん) | FDE(Forward Deployed Engineer) | Field Engineer | Solutions Architect |
|---|---|---|---|
| 主要活動(しゅようかつどう) | 顧客現場で直接コード作成(さくせい)・実装(じっそう) | プリセールス技術デモ・POC | アーキテクチャ設計(せっけい)・技術アドバイザリ |
| コーディング比率(ひりつ) | 70-80% | 30-40% | 10-20% |
| 顧客接点(せってん) | 実装チームと密接(みっせつ)に協業(きょうぎょう) | 意思決定者(いしけっていしゃ)・技術リーダー | Cレベル・アーキテクト |
| プロジェクト期間(きかん) | 2-6ヶ月長期(ちょうき) | 1-4週間短期(たんき) | スポット的アドバイザリ |
| 成果指標(しひょう) | プロジェクト成功率(せいこうりつ)、顧客満足度(まんぞくど) | パイプライン貢献度(こうけんど)、技術承認(しょうにん) | ディールクローズ貢献 |
報酬(ほうしゅう)パッケージ
DatabricksのFDEは業界(ぎょうかい)で非常(ひじょう)に競争力(きょうそうりょく)のある報酬を提供(ていきょう)しています。
2025年基準Total Compensation(TC)レンジ:
- Junior FDE(0-2年):約180K-230Kドル
- Mid-level FDE(3-5年):約230K-350Kドル
- Senior FDE(5年以上):約350K-486K+ドル
- FDE平均(へいきん)TC:約238Kドル
報酬構造(こうぞう):
- 基本給(きほんきゅう):TCの約50-60%
- RSU(Restricted Stock Units):TCの約30-40%(IPO前(まえ)の株式(かぶしき)で上場(じょうじょう)時(じ)に大(おお)きな上昇(じょうしょう)の可能性(かのうせい))
- 年間(ねんかん)ボーナス:TCの約10-15%
- 追加(ついか)福利厚生(ふくりこうせい):出張(しゅっちょう)手当(てあて)、学習支援金(ねん5,000ドル)、健康保険(けんこうほけん)、401(k)マッチング
2. JD(Job Description)詳細(しょうさい)分析(ぶんせき)
核心的責任
Databricks FDEのJDを分解(ぶんかい)すると、大(おお)きく4つのカテゴリに分(わ)かれます。
1. 顧客データプラットフォーム構築
- 顧客の既存(きぞん)データインフラ(Hadoop、Snowflake、レガシーDW)をDatabricks Lakehouseへマイグレーション
- Medallion Architecture(Bronze/Silver/Gold)設計・実装
- ETL/ELTパイプライン最適化
2. RAG/AIパイプライン実装
- Mosaic AIを活用(かつよう)したRAGパイプライン構築
- Vector Search Indexの設計・最適化
- Model Serving Endpointのデプロイ・モニタリング
- 顧客データに最適化されたAIエージェント実装
3. テクニカルリーダーシップ
- 顧客エンジニアリングチームとの技術ワークショップ実施(じっし)
- アーキテクチャレビューとベストプラクティスの伝達
- POC(Proof of Concept)設計・実行(じっこう)
4. プロジェクト管理
- 実装スケジュール策定(さくてい)とマイルストーン管理
- 技術リスクの特定(とくてい)・軽減(けいげん)
- PS(Professional Services)からCustomer Successチームへのハンドオフ
必須(ひっす)要件(ようけん)
- Apache Spark:分散データ処理の核心。PySpark又(また)はScala Sparkに精通(せいつう)
- Python/Scala:データエンジニアリングとMLパイプライン開発(かいはつ)の主要言語(げんご)
- SQL:複雑な分析クエリの作成、パフォーマンス最適化、Spark SQL活用
- クラウドプラットフォーム:AWS、Azure、GCPのうち最低(さいてい)1つに深(ふか)い経験(けいけん)。マルチクラウド優遇(ゆうぐう)
- データモデリング:Star Schema、Snowflake Schema、非正規化(ひせいきか)戦略(せんりゃく)
- 顧客対応(たいおう)経験:技術コンサルティング又はProfessional Services経験
優遇要件
- Delta Lake:ACIDトランザクション、Time Travel、Schema Evolutionの実務(じつむ)経験
- MLflow:実験(じっけん)追跡(ついせき)、モデルレジストリ、モデルサービング経験
- Unity Catalog:データガバナンス、リニエージ追跡、アクセス制御(せいぎょ)経験
- Terraform/Pulumi:DatabricksワークスペースのIaCプロビジョニング
- Streaming:Spark Structured Streaming、Kafka、Event Hubs経験
- ML/AI:フィーチャーエンジニアリング、モデル学習(がくしゅう)/デプロイ、RAGパイプライン構築
3. 技術ディープダイブ
3-1. Apache Sparkマスタリー
Apache SparkはDatabricksの技術的核心です。FDEとして単純(たんじゅん)に使(つか)えるだけでなく、内部(ないぶ)動作(どうさ)原理(げんり)を深(ふか)く理解する必要(ひつよう)があります。
RDDからDataFrame、Datasetへの進化(しんか)
# RDD (2014) - 低レベルAPI、型安全だが最適化が困難
rdd = sc.parallelize([1, 2, 3, 4, 5])
result = rdd.filter(lambda x: x > 2).map(lambda x: x * 2).collect()
# DataFrame (2015) - SQL親和的、Catalyst Optimizer活用
df = spark.read.parquet("s3://data/events/")
result = df.filter(df.age > 25).groupBy("city").count()
# Dataset (Scalaのみ) - DataFrame + コンパイル時型安全性
# PythonではDataFrameがDataset[Row]に相当
Catalyst OptimizerとTungsten Engine
Spark SQLの性能(せいのう)はCatalyst OptimizerとTungsten Engineに依存(いぞん)しています。
# Catalystの最適化段階を確認する方法
df = spark.read.parquet("s3://data/sales/")
optimized = df.filter("amount > 1000").join(
spark.read.parquet("s3://data/customers/"),
"customer_id"
)
# 論理的/物理的実行計画の確認
optimized.explain(True)
# 出力例:
# == Parsed Logical Plan ==
# == Analyzed Logical Plan ==
# == Optimized Logical Plan == <-- Predicate Pushdown、Column Pruning適用
# == Physical Plan == <-- Join戦略(BroadcastHashJoinなど)決定
Catalystの核心的最適化:
- Predicate Pushdown:フィルタ条件(じょうけん)をデータソースレベルに押(お)し下(さ)げて不要(ふよう)なデータ読(よ)み込(こ)みを最小化(さいしょうか)
- Column Pruning:必要なカラムのみ読み込んでI/Oを最小化
- Constant Folding:コンパイル時(じ)に定数(ていすう)式(しき)を評価(ひょうか)
- Join Reordering:統計(とうけい)に基(もと)づきJoin順序(じゅんじょ)を最適化してシャッフルデータを最小化
Tungsten Engineの役割:
- オフヒープメモリ管理でGC負担(ふたん)を軽減
- コード生成(Whole-Stage CodeGen)で仮想(かそう)関数(かんすう)呼(よ)び出(だ)しを排除(はいじょ)
- キャッシュフレンドリーなデータ構造の使用
パーティショニング、シャッフル最適化、AQE
# パーティショニング戦略 - データ分布に基づく最適化
# 1. Hash Partitioning(デフォルト)
df.repartition(200, "customer_id")
# 2. Range Partitioning - ソートされたデータに有利
df.repartitionByRange(200, "event_date")
# 3. シャッフル最適化 - broadcast join使用
from pyspark.sql.functions import broadcast
# 小さいテーブル(10MB以下)をブロードキャストしてシャッフルを排除
result = large_df.join(broadcast(small_df), "key")
# 4. Salting - データスキュー解決
from pyspark.sql.functions import concat, lit, rand, floor
# ホットキーにソルトを追加して均等分配
salt_range = 10
skewed_df = skewed_df.withColumn(
"salted_key",
concat("key", lit("_"), floor(rand() * salt_range).cast("string"))
)
# AQE (Adaptive Query Execution) - Spark 3.0+
spark.conf.set("spark.sql.adaptive.enabled", "true")
spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")
spark.conf.set("spark.sql.adaptive.skewJoin.enabled", "true")
AQEの核心機能(きのう):
- シャッフルパーティション自動(じどう)マージ(Coalesce Shuffle Partitions)
- スキューJoin自動最適化(Skew Join Optimization)
- ランタイムでのJoin戦略切(き)り替(か)え(Sort-Merge JoinからBroadcast Hash Joinへ)
PySpark vs Scala Spark
# PySpark - データサイエンティストとのコラボレーションに有利
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, when, sum as spark_sum
spark = SparkSession.builder.appName("etl").getOrCreate()
df = (
spark.read.format("delta")
.load("s3://lakehouse/bronze/events")
.filter(col("event_date") >= "2025-01-01")
.withColumn("category",
when(col("amount") > 1000, "high")
.when(col("amount") > 100, "medium")
.otherwise("low")
)
.groupBy("category")
.agg(spark_sum("amount").alias("total_amount"))
)
// Scala Spark - 型安全性、より良いパフォーマンス
import org.apache.spark.sql.SparkSession
import org.apache.spark.sql.functions._
val spark = SparkSession.builder.appName("etl").getOrCreate()
import spark.implicits._
val df = spark.read.format("delta")
.load("s3://lakehouse/bronze/events")
.filter($"event_date" >= "2025-01-01")
.withColumn("category",
when($"amount" > 1000, "high")
.when($"amount" > 100, "medium")
.otherwise("low")
)
.groupBy("category")
.agg(sum("amount").alias("total_amount"))
選択基準(きじゅん):
- PySpark:ML/AIパイプライン、データサイエンスチーム協業、プロトタイピング
- Scala Spark:パフォーマンスクリティカルなETL、ストリーミングパイプライン、ライブラリ開発
3-2. Delta LakeとMedallion Architecture
ACIDトランザクションとTime Travel
Delta LakeはParquetの上にトランザクションログ(_delta_log/)を追加してACIDを保証(ほしょう)します。
# Delta Lake基本CRUD操作
# 1. テーブル作成
df.write.format("delta").mode("overwrite").saveAsTable("lakehouse.bronze.raw_events")
# 2. 更新(MERGE/UPSERT)
from delta.tables import DeltaTable
target = DeltaTable.forName(spark, "lakehouse.silver.customers")
source = spark.read.format("delta").load("s3://staging/new_customers/")
target.alias("t").merge(
source.alias("s"),
"t.customer_id = s.customer_id"
).whenMatchedUpdate(set={
"name": "s.name",
"email": "s.email",
"updated_at": "current_timestamp()"
}).whenNotMatchedInsertAll().execute()
# 3. Time Travel - 過去バージョン照会
df_v5 = spark.read.format("delta").option("versionAsOf", 5).load(path)
df_yesterday = spark.read.format("delta").option("timestampAsOf", "2025-03-22").load(path)
# 4. RESTORE - テーブルを過去バージョンに復元
spark.sql("RESTORE TABLE lakehouse.silver.customers VERSION AS OF 5")
Medallion Architecture実装
# Bronze Layer - 生データそのまま取り込み(Append-only)
raw_df = (
spark.readStream
.format("cloudFiles") # Auto Loader
.option("cloudFiles.format", "json")
.option("cloudFiles.schemaLocation", "s3://schema/bronze/events/")
.load("s3://raw-data/events/")
)
bronze_df = raw_df.withColumn("_ingested_at", current_timestamp())
bronze_df.writeStream \
.format("delta") \
.outputMode("append") \
.option("checkpointLocation", "s3://checkpoints/bronze/events/") \
.trigger(availableNow=True) \
.toTable("lakehouse.bronze.raw_events")
# Silver Layer - 精製データ(重複排除、クレンジング、型変換)
silver_df = (
spark.readStream.table("lakehouse.bronze.raw_events")
.dropDuplicates(["event_id"])
.filter(col("event_type").isNotNull())
.withColumn("amount", col("amount").cast("decimal(18,2)"))
.withColumn("event_date", to_date(col("event_timestamp")))
)
silver_df.writeStream \
.format("delta") \
.outputMode("append") \
.option("checkpointLocation", "s3://checkpoints/silver/events/") \
.trigger(availableNow=True) \
.toTable("lakehouse.silver.clean_events")
# Gold Layer - ビジネス集計テーブル
gold_df = (
spark.read.table("lakehouse.silver.clean_events")
.groupBy("customer_id", "event_date")
.agg(
count("*").alias("event_count"),
spark_sum("amount").alias("daily_total"),
avg("amount").alias("avg_amount")
)
)
gold_df.write.format("delta").mode("overwrite") \
.saveAsTable("lakehouse.gold.customer_daily_summary")
Change Data Feed(CDF)
-- CDF有効化
ALTER TABLE lakehouse.silver.customers SET TBLPROPERTIES (delta.enableChangeDataFeed = true);
-- CDF照会:変更されたレコードのみ抽出
SELECT * FROM table_changes('lakehouse.silver.customers', 5)
WHERE _change_type IN ('insert', 'update_postimage');
Delta Lake 4.0新機能
- Liquid Clustering:Z-ORDERを代替(だいたい)する自動クラスタリング。クエリパターンに応(おう)じて動的(どうてき)にデータを再配置(さいはいち)
- UniForm:Delta、Iceberg、Hudiフォーマット間(かん)の自動変換。外部(がいぶ)システムとの互換性(ごかんせい)を最大化
- Deletion Vectors:大量(たいりょう)削除(さくじょ)時(じ)にファイル書(か)き換(か)えなしに削除ベクトルで表示(ひょうじ)してパフォーマンス改善
- Row Tracking:行(ぎょう)レベル変更追跡でCDCパイプラインを簡素化(かんそか)
-- Liquid Clustering設定
CREATE TABLE lakehouse.silver.events
CLUSTER BY (event_date, customer_id)
AS SELECT * FROM lakehouse.bronze.raw_events;
-- OPTIMIZEが自動で最適なクラスタリングを適用
OPTIMIZE lakehouse.silver.events;
3-3. Unity Catalogとデータガバナンス
3レベルネームスペース
Unity Catalogはcatalog.schema.table形式(けいしき)の3レベルネームスペースを使用します。
-- カタログ作成
CREATE CATALOG production;
CREATE CATALOG development;
-- スキーマ(データベース)作成
CREATE SCHEMA production.finance;
CREATE SCHEMA production.marketing;
-- テーブル参照
SELECT * FROM production.finance.transactions
WHERE transaction_date >= '2025-01-01';
-- クロスカタログJoin
SELECT a.*, b.segment
FROM production.finance.transactions a
JOIN production.marketing.customer_segments b
ON a.customer_id = b.customer_id;
データリニエージ追跡
Unity Catalogは自動的にデータリニエージを追跡します。どのテーブルがどのソースから来(き)たか、どのノートブック/ジョブがデータを変換(へんかん)したかを可視化(かしか)できます。
# リニエージは自動追跡されるため、追加コード不要
# UIで確認またはREST APIで照会可能
# Unity Catalog REST APIでリニエージ照会
import requests
response = requests.get(
"https://workspace.cloud.databricks.com/api/2.1/unity-catalog/lineage/table-lineage",
headers=headers,
params={"table_name": "production.finance.transactions"}
)
Row/Column Level Security
-- Column Level Security:マスキング関数定義
CREATE FUNCTION production.finance.mask_ssn(ssn STRING)
RETURNS STRING
RETURN CASE
WHEN IS_ACCOUNT_GROUP_MEMBER('finance_admins') THEN ssn
ELSE CONCAT('***-**-', RIGHT(ssn, 4))
END;
-- カラムにマスキング関数を適用
ALTER TABLE production.finance.customers
ALTER COLUMN ssn SET MASK production.finance.mask_ssn;
-- Row Level Security:行フィルタ関数定義
CREATE FUNCTION production.finance.region_filter(region STRING)
RETURNS BOOLEAN
RETURN CASE
WHEN IS_ACCOUNT_GROUP_MEMBER('global_admins') THEN TRUE
WHEN IS_ACCOUNT_GROUP_MEMBER('apac_team') AND region = 'APAC' THEN TRUE
ELSE FALSE
END;
ALTER TABLE production.finance.transactions
SET ROW FILTER production.finance.region_filter ON (region);
3-4. MLflow on Databricks
実験追跡とモデルレジストリ
import mlflow
from mlflow.tracking import MlflowClient
# 実験作成・実行
mlflow.set_experiment("/Shared/customer-churn-prediction")
with mlflow.start_run(run_name="xgboost_v2") as run:
# ハイパーパラメータのロギング
mlflow.log_param("max_depth", 6)
mlflow.log_param("learning_rate", 0.1)
mlflow.log_param("n_estimators", 200)
# モデル学習
model = xgb.XGBClassifier(max_depth=6, learning_rate=0.1, n_estimators=200)
model.fit(X_train, y_train)
# メトリクスのロギング
predictions = model.predict(X_test)
accuracy = accuracy_score(y_test, predictions)
mlflow.log_metric("accuracy", accuracy)
mlflow.log_metric("f1_score", f1_score(y_test, predictions))
# モデルアーティファクトのロギング
mlflow.xgboost.log_model(model, "model")
# Unity Catalogにモデル登録
mlflow.register_model(
f"runs:/{run.info.run_id}/model",
"production.ml_models.churn_predictor"
)
Feature Store連携(れんけい)
from databricks.feature_engineering import FeatureEngineeringClient
fe = FeatureEngineeringClient()
# フィーチャーテーブル作成
fe.create_table(
name="production.features.customer_features",
primary_keys=["customer_id"],
timestamp_keys=["event_date"],
df=customer_features_df,
description="顧客行動フィーチャー:最近の購入頻度、平均購入金額、最終ログイン日数"
)
# フィーチャールックアップで学習データ生成
from databricks.feature_engineering import FeatureLookup
training_set = fe.create_training_set(
df=label_df,
feature_lookups=[
FeatureLookup(
table_name="production.features.customer_features",
lookup_key="customer_id",
timestamp_lookup_key="event_date"
)
],
label="churned"
)
training_df = training_set.load_df()
Model Serving Endpointデプロイ
import requests
import json
# Model Serving Endpoint作成(REST API)
endpoint_config = {
"name": "churn-predictor-endpoint",
"config": {
"served_entities": [{
"entity_name": "production.ml_models.churn_predictor",
"entity_version": "3",
"workload_size": "Small",
"scale_to_zero_enabled": True
}],
"auto_capture_config": {
"catalog_name": "production",
"schema_name": "ml_monitoring",
"table_name_prefix": "churn_predictor"
}
}
}
# エンドポイントに推論リクエスト送信
response = requests.post(
"https://workspace.cloud.databricks.com/serving-endpoints/churn-predictor-endpoint/invocations",
headers=headers,
json={"dataframe_records": [{"customer_id": "C001", "purchase_count": 12, "avg_amount": 150.0}]}
)
3-5. Mosaic AI(RAGとAgents)
Vector Search Index作成
from databricks.vector_search.client import VectorSearchClient
vsc = VectorSearchClient()
# Vector Searchエンドポイント作成
vsc.create_endpoint(name="rag-endpoint", endpoint_type="STANDARD")
# Delta Sync Index作成 - Deltaテーブル変更時に自動同期
vsc.create_delta_sync_index(
endpoint_name="rag-endpoint",
index_name="production.rag.document_index",
source_table_name="production.rag.documents",
pipeline_type="TRIGGERED",
primary_key="doc_id",
embedding_source_column="content",
embedding_model_endpoint_name="databricks-bge-large-en"
)
RAGパイプライン構築
RAGパイプラインはChunk、Embed、Search、Generateの4段階(だんかい)で構成されます。
from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
# Step 1: Document Chunking
loader = PyPDFLoader("dbfs:/documents/product_manual.pdf")
documents = loader.load()
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=200,
separators=["\n\n", "\n", ". ", " "]
)
chunks = text_splitter.split_documents(documents)
# Step 2: Embedding(Databricks Foundation Model使用)
# チャンクをDeltaテーブルに保存するとVector Search Indexが自動エンベディング
chunks_df = spark.createDataFrame([
{"doc_id": f"doc_{i}", "content": chunk.page_content, "metadata": str(chunk.metadata)}
for i, chunk in enumerate(chunks)
])
chunks_df.write.format("delta").mode("append").saveAsTable("production.rag.documents")
# Step 3: Search(類似度検索)
results = vsc.get_index("rag-endpoint", "production.rag.document_index").similarity_search(
query_text="製品の保証ポリシーは何ですか?",
columns=["content", "metadata"],
num_results=5
)
# Step 4: Generate(LLMで回答生成)
import mlflow.deployments
client = mlflow.deployments.get_deploy_client("databricks")
context = "\n".join([r["content"] for r in results["result"]["data_array"]])
prompt = f"""以下のコンテキストに基づいて質問に回答してください。
コンテキスト:
{context}
質問: 製品の保証ポリシーは何ですか?
回答:"""
response = client.predict(
endpoint="databricks-meta-llama-3-1-70b-instruct",
inputs={"prompt": prompt, "max_tokens": 500, "temperature": 0.1}
)
Mosaic AI Agent Framework
from databricks.agents import Agent, AgentTool
# エージェントツール定義
search_tool = AgentTool(
name="document_search",
description="社内ドキュメントから関連情報を検索します",
func=lambda query: vsc.get_index("rag-endpoint", "production.rag.document_index")
.similarity_search(query_text=query, num_results=3)
)
sql_tool = AgentTool(
name="data_query",
description="データベースからビジネスデータを照会します",
func=lambda query: spark.sql(query).toPandas().to_dict()
)
# エージェント作成
agent = Agent(
model="databricks-meta-llama-3-1-70b-instruct",
tools=[search_tool, sql_tool],
system_prompt="あなたはカスタマーサポートエージェントです。ドキュメント検索とデータ照会を通じて正確な回答を提供してください。"
)
Model Gateway
# Model Gateway - 複数のLLMプロバイダーを単一インターフェースで統合
# Databricks UIまたはREST APIで設定
# OpenAIモデルをDatabricks Gatewayを通じて呼び出し
response = client.predict(
endpoint="openai-gpt4-gateway",
inputs={"messages": [{"role": "user", "content": "分析レポートを作成してください"}]}
)
# Anthropic ClaudeをGatewayを通じて呼び出し
response = client.predict(
endpoint="anthropic-claude-gateway",
inputs={"messages": [{"role": "user", "content": "コードをレビューしてください"}]}
)
# オープンソースモデル(Llama、Mistralなど)も同一インターフェース
response = client.predict(
endpoint="databricks-meta-llama-3-1-70b-instruct",
inputs={"prompt": "データを要約してください", "max_tokens": 300}
)
3-6. Spark Structured Streaming
トリガーモード
# 1. Available Now - 現在利用可能なデータのみ処理して終了(バッチ-ストリーミング統合)
query = (
df.writeStream
.format("delta")
.trigger(availableNow=True)
.option("checkpointLocation", checkpoint_path)
.toTable("lakehouse.silver.events")
)
# 2. Processing Time - 指定間隔でマイクロバッチ実行
query = (
df.writeStream
.format("delta")
.trigger(processingTime="30 seconds")
.option("checkpointLocation", checkpoint_path)
.toTable("lakehouse.silver.events")
)
# 3. Continuous(実験的) - ミリ秒レイテンシのリアルタイム処理
query = (
df.writeStream
.format("delta")
.trigger(continuous="1 second")
.option("checkpointLocation", checkpoint_path)
.toTable("lakehouse.silver.events")
)
ウォーターマークとLate Data Handling
# イベント時間ベースのウィンドウ集計 + ウォーターマーク
from pyspark.sql.functions import window
windowed_counts = (
events_df
.withWatermark("event_time", "10 minutes") # 10分遅延まで許容
.groupBy(
window("event_time", "5 minutes", "1 minute"), # 5分ウィンドウ、1分スライド
"device_type"
)
.count()
)
windowed_counts.writeStream \
.format("delta") \
.outputMode("append") \
.trigger(processingTime="1 minute") \
.option("checkpointLocation", checkpoint_path) \
.toTable("lakehouse.gold.device_counts_5min")
Delta Live Tables(DLT)
import dlt
from pyspark.sql.functions import col, current_timestamp
# Bronze:生データ収集
@dlt.table(
name="bronze_events",
comment="生イベントデータ",
table_properties={"quality": "bronze"}
)
def bronze_events():
return (
spark.readStream
.format("cloudFiles")
.option("cloudFiles.format", "json")
.load("s3://raw-data/events/")
)
# Silver:データ品質検証を含む
@dlt.table(
name="silver_events",
comment="精製されたイベントデータ"
)
@dlt.expect_or_drop("valid_event_id", "event_id IS NOT NULL")
@dlt.expect_or_fail("valid_amount", "amount >= 0")
@dlt.expect("valid_email", "email RLIKE '^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+$'")
def silver_events():
return (
dlt.read_stream("bronze_events")
.dropDuplicates(["event_id"])
.withColumn("processed_at", current_timestamp())
)
# Gold:ビジネス集計
@dlt.table(
name="gold_daily_summary",
comment="日別ビジネスサマリー"
)
def gold_daily_summary():
return (
dlt.read("silver_events")
.groupBy("event_date", "category")
.agg(
count("*").alias("total_events"),
spark_sum("amount").alias("total_amount")
)
)
Auto Loader
# Auto Loader - クラウドストレージの新規ファイルを自動検知して取り込み
df = (
spark.readStream
.format("cloudFiles")
.option("cloudFiles.format", "json")
.option("cloudFiles.schemaLocation", "s3://schema/auto_loader/events/")
.option("cloudFiles.inferColumnTypes", "true")
.option("cloudFiles.schemaEvolutionMode", "addNewColumns")
.load("s3://raw-data/events/")
)
# Auto Loaderの利点:
# 1. ファイルリスト管理不要 - 新規ファイル自動検知
# 2. スキーマ推論・進化 - 新カラム自動追加
# 3. Exactly-once処理保証
# 4. 数百万ファイルでも効率的(ファイル通知モード)
3-7. クラウドインフラストラクチャ
AWS環境
# AWSでのDatabricksアーキテクチャ
# 1. ストレージ:S3 + Delta Lake
storage_config = {
"data_bucket": "s3://company-lakehouse-prod/",
"checkpoint_bucket": "s3://company-checkpoints-prod/",
"metastore_bucket": "s3://company-unity-catalog/",
"encryption": "SSE-KMS",
"kms_key": "arn:aws:kms:us-east-1:123456789012:key/xxx"
}
# 2. コンピュート:EC2インスタンスベースのクラスター
cluster_config = {
"spark_version": "14.3.x-scala2.12",
"node_type_id": "i3.xlarge",
"driver_node_type_id": "i3.2xlarge",
"num_workers": 8,
"autoscale": {"min_workers": 4, "max_workers": 16},
"aws_attributes": {
"instance_profile_arn": "arn:aws:iam::123456789012:instance-profile/databricks-role",
"availability": "SPOT_WITH_FALLBACK",
"spot_bid_price_percent": 100
}
}
Azure環境
# AzureでのDatabricksアーキテクチャ
# 1. ストレージ:ADLS Gen2 + Delta Lake
storage_config = {
"container": "abfss://lakehouse@companystorage.dfs.core.windows.net/",
"metastore": "abfss://unity-catalog@companystorage.dfs.core.windows.net/",
"encryption": "Microsoft Managed Keys",
"network": "Private Endpoint"
}
# 2. ネットワーキング:VNet Injection
# DatabricksワークスペースをカスタマーVNetに直接デプロイ
# - Private Linkでコントロールプレーンアクセス
# - No Public IPでクラスター運用
# - NSG(Network Security Group)でトラフィック制御
GCP環境
# GCPでのDatabricksアーキテクチャ
# 1. ストレージ:GCS + Delta Lake
storage_config = {
"bucket": "gs://company-lakehouse-prod/",
"metastore": "gs://company-unity-catalog/",
"encryption": "Customer-Managed Encryption Key (CMEK)"
}
# 2. BigQuery連携
# DatabricksからBigQueryテーブルを直接照会
bq_df = (
spark.read
.format("bigquery")
.option("table", "project.dataset.table")
.option("viewsEnabled", "true")
.load()
)
TerraformでDatabricksワークスペースプロビジョニング
# TerraformでDatabricksワークスペース + Unity Catalog設定
provider "databricks" {
alias = "workspace"
host = databricks_workspace.main.workspace_url
}
# ワークスペース作成(AWS例)
resource "databricks_workspace" "main" {
workspace_name = "production-lakehouse"
region = "us-east-1"
aws_config {
subnet_ids = var.private_subnet_ids
security_group_ids = [var.security_group_id]
instance_profile = var.instance_profile_arn
}
storage_config {
s3_bucket_name = var.root_bucket_name
}
}
# Unity Catalog Metastore
resource "databricks_metastore" "main" {
provider = databricks.workspace
name = "production-metastore"
storage_root = "s3://unity-catalog-metastore/"
force_destroy = false
}
# クラスターポリシー
resource "databricks_cluster_policy" "data_engineering" {
provider = databricks.workspace
name = "Data Engineering Policy"
definition = jsonencode({
"spark_version" : { "type" : "fixed", "value" : "14.3.x-scala2.12" },
"autoscale.max_workers" : { "type" : "range", "maxValue" : 20 },
"node_type_id" : { "type" : "allowlist", "values" : ["i3.xlarge", "i3.2xlarge"] },
"custom_tags.team" : { "type" : "fixed", "value" : "data-engineering" }
})
}
3-8. 顧客対応能力(のうりょく)
FDEは単純な技術専門家(せんもんか)ではなく、顧客対応のスペシャリストでもあります。技術と同(おな)じくらい重要(じゅうよう)なソフトスキルを見(み)ていきましょう。
Technical Discovery:顧客データ環境の把握(はあく)
Discoveryフレームワーク:
-
現状(げんじょう)(As-Is)評価
- 既存データインフラ:Hadoop、Snowflake、Redshift、Oracle DWなど
- データボリューム:日別取(と)り込(こ)み量(りょう)、総(そう)ストレージ量、増加率(ぞうかりつ)
- 現在のETL/ELTツール:Informatica、Talend、dbt、Airflowなど
- データガバナンス成熟度(せいじゅくど):リニエージ追跡、アクセス制御、データ品質管理
-
目標状態(じょうたい)(To-Be)定義(ていぎ)
- Lakehouseアーキテクチャへのマイグレーション範囲(はんい)
- リアルタイム処理要件
- AI/MLパイプライン目標
- コスト最適化ターゲット
-
ギャップ分析
- 技術能力ギャップ:顧客チームのSpark/Delta Lake経験
- インフラギャップ:クラウド成熟度、ネットワーク構成
- プロセスギャップ:CI/CD、データ品質管理
Architecture Workshop:ソリューション設計ワークショップ
ワークショップ構造(通常(つうじょう)2-3日間(にちかん)):
- Day 1:現在のアーキテクチャレビュー + Lakehouseコンセプト教育(きょういく)
- Day 2:Medallion Architecture設計 + ハンズオン実習(じっしゅう)
- Day 3:マイグレーション計画策定 + ロードマップ合意(ごうい)
核心的成果物(せいかぶつ):
- アーキテクチャダイアグラム(As-Is / To-Be)
- データフローダイアグラム
- マイグレーション優先度(ゆうせんど)マトリックス
- リソース計画(人員(じんいん)、インフラ、タイムライン)
POC実行と成功基準の定義
POC成功基準の例:
| 指標 | 基準値 | 測定方法(そくていほうほう) |
|---|---|---|
| ETL処理時間 | 既存比50%短縮(たんしゅく) | 同一データセットベンチマーク |
| クエリパフォーマンス | P95レイテンシ5秒以内 | ダッシュボードクエリ実行 |
| データ品質 | 99.9%精度(せいど) | ソースvsターゲット比較(ひかく) |
| コスト | 月額運用費30%削減 | クラウドコスト比較 |
ハンドオフ:PSからCustomer Successへ
ハンドオフチェックリスト:
- アーキテクチャドキュメント完成(かんせい)
- 運用ランブック作成
- モニタリング/アラート設定完了(かんりょう)
- 顧客チーム教育完了(最低2名が自立可能)
- パフォーマンスベースライン確立(かくりつ)
- エスカレーションパス定義
4. 面接(めんせつ)予想質問(しつもん)25選(せん)
Spark技術(8問(もん))
Q1. SparkのCatalyst Optimizerがクエリパフォーマンスを改善する主要メカニズム3つを説明してください。
模範回答(かいとう):Predicate Pushdown(フィルタ条件をデータソースレベルに押し下げて不要なデータ読み込みを最小化)、Column Pruning(必要なカラムのみ読み込んでI/Oを最小化)、Join Reordering(統計に基づきJoin順序を最適化してシャッフルデータを最小化)があります。Catalystはルールベースとコストベースの2つの最適化戦略を使用し、物理計画段階でBroadcastHashJoin、SortMergeJoinなど最適なJoin戦略を選択します。
Q2. SparkでData Skew(データ偏(かたよ)り)が発生した時の解決方法は何ですか?
模範回答:主要な解決方法は3つです。第一(だいいち)に、Salting技法でホットキーにランダム接尾辞(せつびじ)を追加してパーティションを均等(きんとう)分配します。第二に、AQEのskewJoin機能を有効化するとランタイムで自動的にスキューを検知して大きなパーティションを分割します。第三に、Broadcast Joinで小さいテーブルをブロードキャストしてシャッフル自体(じたい)を排除します。
Q3. PySparkでUDF使用時にパフォーマンス低下が発生する理由と代替手段は何ですか?
模範回答:PySpark UDFはJVMとPythonプロセス間でデータをシリアライズ/デシリアライズ(SerDe)する必要があり、オーバーヘッドが発生します。代替として、ビルトイン関数(pyspark.sql.functions)を最大限活用するか、Pandas UDF(ベクトル化UDF)を使用するとApache Arrowベースでバッチ単位でデータを転送し、10-100倍のパフォーマンス向上が可能です。
Q4. Spark Shuffleとは何であり、シャッフルを減(へ)らすための戦略は何ですか?
模範回答:ShuffleはSparkでパーティション間のデータ再分配が必要な時に発生するコストの高い演算です(groupBy、join、repartitionなど)。シャッフルを減らすにはBroadcast Joinで小テーブルのシャッフル排除、適切なパーティショニング(co-partitioning)、map-side aggregation(reduceByKey vs groupByKey)、そしてAQEのパーティションマージ機能を活用します。
Q5. Sparkのメモリ管理モデルを説明し、OOMエラーの解決方法は何ですか?
模範回答:SparkはUnified Memory Managerを使用し、Execution Memory(シャッフル、ジョイン、ソート)とStorage Memory(キャッシュ、ブロードキャスト)が動的に共有されます。OOM解決方法としては、ドライバーメモリ増加、エグゼキューターメモリ調整、パーティション数増加によるデータ分散、ブロードキャストジョイン閾値調整、persistレベル変更(MEMORY_AND_DISK)などがあります。
Q6. Spark 3.xにおけるAQEの3つの核心機能を説明してください。
模範回答:第一に、Coalesce Shuffle Partitionsでシャッフル後の過剰(かじょう)に小さいパーティションを自動マージします。第二に、Skew Join Optimizationでランタイムにデータスキューを検知し、大きなパーティションを分割して均等に処理します。第三に、Dynamic Join Strategy Switchingでランタイム統計に基づきSort-Merge JoinからBroadcast Hash Joinに切り替えます。
Q7. SparkのPartition Pruningとは何であり、Dynamic Partition Pruningとの違(ちが)いは何ですか?
模範回答:Partition Pruningはクエリフィルタ条件に合うパーティションのみ読み込んでI/Oを減らす最適化です。Static Partition Pruningはコンパイル時にフィルタ値が分かる時に適用されます。Dynamic Partition Pruning(DPP)はSpark 3.0で導入(どうにゅう)され、Join時に一方のテーブルの結果に基づいてもう一方のテーブルのパーティションをランタイムにプルーニングします。大型ファクトテーブルと小さなディメンションテーブルのJoin時に大きな効果(こうか)があります。
Q8. SparkのWhole-Stage Code Generationとは何ですか?
模範回答:Whole-Stage Code GenerationはTungsten Engineの核心機能で、複数のオペレーターを単一のJavaメソッドにコンパイルして仮想関数呼び出しと中間データコピーを排除します。従来(じゅうらい)は各オペレーターがnext()メソッドを呼び出して1行ずつ処理していましたが、コード生成はタイトなループで行を直接処理し、CPUキャッシュ効率と処理速度を大幅(おおはば)に向上させます。
Delta Lake / Unity Catalog(7問)
Q9. Delta LakeのACIDトランザクションはどのように実装されていますか?
模範回答:Delta Lakeはトランザクションログ(_delta_log/)を通じてACIDを実装しています。すべての書き込み操作はJSON形式のコミットログを順次記録し、楽観的並行制御(Optimistic Concurrency Control)を使用します。衝突検知時に自動リトライし、10コミットごとにチェックポイントファイルを生成してログ読み取り性能を維持します。
Q10. Medallion Architectureの各レイヤー(Bronze/Silver/Gold)の役割と設計原則は何ですか?
模範回答:Bronzeは生データをそのまま取り込むAppend-onlyレイヤーで、データソースの完全な履歴(りれき)を保存します。Silverは精製されたデータで重複排除、スキーマ標準化、データ品質検証を行います。Goldはビジネス観点の集計テーブルで、ダッシュボードとMLモデルが直接消費します。核心原則は、各レイヤーが独立(どくりつ)して再処理可能であり、BronzeからGoldに向かうほどデータのビジネス価値が高まるということです。
Q11. Delta LakeのLiquid Clusteringと従来のZ-ORDERの違いは何ですか?
模範回答:Z-ORDERは手動(しゅどう)で実行する必要があり、クラスタリングカラム変更時にテーブル全体を書き換える必要があります。Liquid ClusteringはOPTIMIZE実行時に段階的にデータを再配置し、クラスタリングキーを動的に変更できます。また、クエリパターンに応じて自動的に最適なクラスタリングを適用し、メンテナンス負担を大幅に軽減します。
Q12. Unity CatalogでRow Level SecurityとColumn Level Securityを実装する方法を説明してください。
模範回答:Column Level Securityはマスキング関数を定義して、ユーザーグループに応じて特定カラムの値を異なる表示にします。IS_ACCOUNT_GROUP_MEMBER関数でグループメンバーシップを確認し、原本値またはマスキングされた値を返します。Row Level Securityは行フィルタ関数をテーブルに適用して、ユーザーグループに応じて特定行のみ表示します。両機能ともUnity Catalogで一元管理されるため、すべてのアクセスパスで一貫して適用されます。
Q13. Change Data Feed(CDF)とは何であり、どのような状況で使用しますか?
模範回答:CDFはDeltaテーブルの変更履歴(INSERT、UPDATE、DELETE)を別途の変更データとして追跡する機能です。主にCDCパイプラインで変更されたデータのみを下流に伝搬(でんぱん)する時に使用します。SilverからGoldテーブルへの増分更新、監査(かんさ)ログ、リアルタイムダッシュボード更新に効果的です。
Q14. Unity Catalogでデータリニエージが重要な理由とその活用方法は何ですか?
模範回答:データリニエージはデータの出所(しゅっしょ)と変換過程を追跡するもので、規制遵守(じゅんしゅ)(GDPRのデータ処理記録)、影響分析(ソーステーブル変更時の下流への影響把握)、デバッグ(データ品質問題の根本原因追跡)に必須です。Unity Catalogはノートブック、ジョブ、クエリの実行を自動追跡し、テーブルレベルとカラムレベルのリニエージを提供します。
Q15. UniFormとは何であり、なぜ必要ですか?
模範回答:UniFormはDelta LakeテーブルをApache IcebergとApache Hudiフォーマットでも自動的に公開(こうかい)する機能です。Databricks外部システム(Snowflake、Trino、Prestoなど)が同一データを各自のネイティブフォーマットで読み取れるようにします。これによりデータコピーなしでマルチエンジン環境をサポートし、ベンダーロックインを防止(ぼうし)します。
RAG/AI(5問)
Q16. RAGパイプラインの4段階を説明し、各段階での最適化ポイントは何ですか?
模範回答:1) Chunking:ドキュメントを適切なサイズに分割します。チャンクサイズ(500-1500トークン)とオーバーラップ(10-20%)が検索品質に大きく影響します。2) Embedding:テキストをベクトルに変換します。ドメインに合ったエンベディングモデルの選択が重要です。3) Search:ベクトル類似度検索で関連ドキュメントを検索します。ハイブリッド検索(ベクトル+キーワード)が精度を向上させます。4) Generate:LLMが検索結果をコンテキストとして使用して回答を生成します。プロンプトエンジニアリングとtemperature調整が鍵です。
Q17. DatabricksのVector SearchにおけるDelta Sync Indexの利点は何ですか?
模範回答:Delta Sync IndexはDeltaテーブルの変更を自動的にベクトルインデックスに同期します。利点として、第一に別途の同期パイプライン構築が不要です。第二にCDFベースで変更データのみ増分インデキシングして効率的です。第三にUnity Catalogのガバナンスがベクトルインデックスにもそのまま適用されてセキュリティが一貫します。第四にテーブルバージョンとインデックスバージョンが同期されてデータ整合性が保証されます。
Q18. Mosaic AI Agent Frameworkでエージェントを設計する際の核心的考慮事項は何ですか?
模範回答:第一に、ツール設計でエージェントが使用できるツールの範囲と権限を明確に定義する必要があります。第二に、ガードレールでエージェントの行動範囲を制限し、機密(きみつ)操作には人間の承認を要求します。第三に、評価フレームワークでエージェントの精度、安全性、レイテンシを継続的(けいぞくてき)に測定します。第四に、観測可能性(Observability)でエージェントの推論過程とツール呼び出しを追跡します。
Q19. Model Gatewayを使用する利点は何ですか?
模範回答:Model Gatewayは複数のLLMプロバイダー(OpenAI、Anthropic、オープンソースモデル)を単一インターフェースで統合します。利点として、第一にAPIキー管理の一元化でセキュリティ強化。第二にモデル間切り替えがコード変更なしで設定のみで可能。第三にコスト追跡と使用量モニタリングの統合。第四にレートリミットとフォールバック戦略の一元管理。第五にUnity Catalogのガバナンスが LLM呼び出しにも適用されます。
Q20. RAGシステムでハルシネーション(幻覚(げんかく))を減らすための戦略は何ですか?
模範回答:第一に、検索品質改善でハイブリッド検索(ベクトル+BM25)、リランキングモデル適用、メタデータフィルタリングで関連性の高いコンテキストを提供します。第二に、プロンプトエンジニアリングで「提供されたコンテキストにのみ基づいて回答してください」という指示を追加します。第三に、引用(いんよう)(Citation)を強制してLLMが回答の根拠を明示するようにします。第四に、回答検証パイプラインで生成された回答がソースドキュメントと一致するか自動検証します。
顧客シナリオ(5問)
Q21. 顧客がHadoopからDatabricksへマイグレーションしたいと考えています。どのようなアプローチを提案しますか?
模範回答:段階的マイグレーションを提案します。フェーズ1:データレイクマイグレーションでHDFSデータをS3/ADLSに移動しDelta Lakeに変換。フェーズ2:ETLパイプラインマイグレーションでHive/PigジョブをSpark/Delta Live Tablesに変換。フェーズ3:分析ワークロードマイグレーションでHiveクエリをSpark SQLに変換。全マイグレーション期間中、両システムを並行運用してリスクを最小化し、各フェーズでデータ整合性検証を実施します。
Q22. POCで顧客が期待するパフォーマンスを達成(たっせい)できなかった場合(ばあい)、どう対応しますか?
模範回答:まずパフォーマンスのボトルネックを正確に分析します。Spark UIでStage別実行時間、シャッフルデータ量、スキュー発生有無を確認します。次に最適化を試(こころ)みます:パーティショニング戦略変更、キャッシング、ブロードキャストジョイン、AQE有効化など。データ特性上目標達成が困難な場合は、顧客に透明に共有し、達成可能な現実的数値と追加最適化ロードマップを提示します。
Q23. 顧客のデータエンジニアがSparkに不慣(ふな)れです。どのように技術伝達しますか?
模範回答:3段階教育戦略を使用します。第1段階Hands-on Workshop(1週間):実際の顧客データで基本ETLパイプラインを一緒に構築します。第2段階Pair Programming(2-4週間):顧客エンジニアとペアプログラミングで実践プロジェクトを進行し、段階的に主導権(しゅどうけん)を移譲(いじょう)します。第3段階Self-service(以降):文書化されたベストプラクティス、テンプレートノートブック、トラブルシューティングガイドを提供し、週次オフィスアワーでサポートします。
Q24. 顧客がコスト最適化を要請します。どのような分析と改善を提案しますか?
模範回答:まずコスト分析ダッシュボードを構築します。クラスター別、ワークロード別、チーム別コストを可視化します。主要な最適化ポイント:Spotインスタンス活用で40-90%コスト削減。自動終了ポリシーで未使用クラスターコスト排除。クラスタープーリングで起動時間短縮とリソース共有。Delta LakeのOPTIMIZEとVACUUMでストレージコスト削減。ジョブクラスターでインタラクティブクラスター対比コスト最適化。通常30-50%のコスト削減が可能です。
Q25. 金融機関(きんゆうきかん)の顧客がデータガバナンスと規制遵守(GDPR、SOX)を最優先(さいゆうせん)に要求します。どう設計しますか?
模範回答:Unity Catalogを中心にガバナンスフレームワークを構築します。GDPR対応:PIIカラムにマスキング関数適用、データリニエージ追跡で処理記録維持、削除要請(Right to Erasure)対応のためのDelta LakeのDELETE + VACUUMプロセス。SOX対応:Row Level Securityで財務データアクセス制御、監査ログで全データアクセス記録、変更履歴をDelta LakeのTime Travelで保存。追加でデータ分類タギング、保存ポリシー、暗号化(あんごうか)(保存時/転送時)を適用します。
5. 8ヶ月学習ロードマップ
| 月 | テーマ | 目標(もくひょう) |
|---|---|---|
| 1-2月 | Apache Spark基礎(きそ)-中級(ちゅうきゅう) | PySpark DataFrame APIを習得、Spark SQL、基本最適化 |
| 2-3月 | Delta LakeとLakehouse | Medallion Architecture実装、ACID/Time Travel実習 |
| 3-4月 | Unity CatalogとGovernance | 3レベルネームスペース、アクセス制御、リニエージ追跡 |
| 4-5月 | MLflowとFeature Engineering | 実験追跡、モデルレジストリ、Feature Store活用 |
| 5-6月 | Mosaic AI(RAG/Agents) | Vector Search、RAGパイプライン、Agent Framework |
| 6-7月 | クラウドインフラとTerraform | AWS/AzureでDatabricksプロビジョニング、IaC |
| 7-8月 | 顧客シナリオと模擬面接 | POCシミュレーション、アーキテクチャ設計、プレゼン練習 |
| 8月 | 資格証(しかくしょう)と最終準備 | Databricks Certified Data Engineer Associate取得 |
月別詳細ガイド:
1-2月:Sparkマスタリー
- Databricks Community Edition(無料(むりょう))に登録(とうろく)
- PySpark DataFrame APIを実際のデータセットで練習(れんしゅう)
- Spark UI読解能力の養成(ようせい):Stage、Task、Shuffle分析
- 最適化練習:broadcast join、partition pruning、AQE
3-4月:Delta Lake + Unity Catalog
- Delta Lake QuickstartでCRUD、Time Travel実習
- Medallion ArchitectureをEコマースデータセットで実装
- Unity Catalogでカタログ/スキーマ/テーブル作成と権限管理
- Row/Column Level Security実習
5-6月:AI/MLパイプライン
- MLflowでモデル実験追跡とレジストリ使用
- RAGパイプラインをPDFドキュメントで構築
- Vector Search Index作成と類似度検索実装
- Model Serving Endpointデプロイ
7-8月:統合プロジェクトと面接準備
- エンドツーエンドプロジェクト構築(ポートフォリオ参照(さんしょう))
- 顧客シナリオロールプレイ練習
- Databricks資格証取得
- 模擬面接5回(かい)以上実施
6. 資格証ガイド
Databricks Certified Data Engineer Associate
- 難易度(なんいど):中級
- 範囲:Spark、Delta Lake、ETL、Lakehouse基本概念(がいねん)
- 形式:45問、90分、合格点(ごうかくてん)70%
- 推奨準備期間:4-6週間
- 核心:Databricks環境でのデータエンジニアリング基礎
Databricks Certified Machine Learning Associate
- 難易度:中級
- 範囲:MLflow、Feature Store、AutoML、Model Serving
- 形式:45問、90分、合格点70%
- 推奨準備期間:4-6週間
- 核心:Databricks環境でのMLライフサイクル管理
Databricks Certified Data Engineer Professional
- 難易度:上級(じょうきゅう)
- 範囲:高度なETL、パフォーマンス最適化、本番パイプライン、Delta Live Tables
- 形式:60問、120分、合格点70%
- 推奨準備期間:8-12週間
- 核心:大規模本番環境でのデータエンジニアリング専門性
Databricks Generative AI Engineer Associate(2025年新設(しんせつ))
- 難易度:中上級
- 範囲:RAG、Vector Search、Mosaic AI、Agent Framework、Model Gateway
- 形式:45問、90分、合格点70%
- 推奨準備期間:6-8週間
- 核心:Databricks環境でのGen AIアプリケーション構築
取得順序推奨:Data Engineer Associateを先(さき)に取得後、ML AssociateまたはGen AI Associateを追加取得するとFDEポジションに強力なアピールになります。
7. ポートフォリオプロジェクト3つ
プロジェクト1:Eコマース Lakehouse(Medallion Architecture)
目標:実際のEコマースデータでBronze/Silver/Goldパイプライン構築
技術スタック:PySpark、Delta Lake、DLT、Unity Catalog、Auto Loader
実装内容:
- Bronze:Auto LoaderでJSONイベントデータのリアルタイム取り込み
- Silver:データ品質検証(DLT Expectations)、重複排除、スキーマ標準化
- Gold:顧客別RFM(Recency、Frequency、Monetary)分析、日別売上集計
- Unity Catalogでデータガバナンス設定:PIIマスキング、チーム別アクセス制御
プロジェクト2:カスタマーサポートRAGチャットボット
目標:社内ドキュメントベースのカスタマーサポートチャットボット構築
技術スタック:Vector Search、Mosaic AI、LangChain、MLflow、Model Serving
実装内容:
- 製品マニュアル、FAQ、技術ドキュメントのチャンキングとエンベディング
- Delta Sync Indexでドキュメント更新の自動反映
- Mosaic AI Agent Frameworkでエージェント構築
- MLflowでRAG品質評価(faithfulness、relevance、groundedness)
- Model Serving Endpointで本番デプロイ
プロジェクト3:リアルタイム異常検知パイプライン
目標:IoTセンサーデータのリアルタイム異常(いじょう)検知(けんち)
技術スタック:Spark Structured Streaming、Delta Lake、MLflow、Model Serving
実装内容:
- KafkaからセンサーデータをStructured Streamingで取り込み
- ウィンドウベースの統計(移動平均、標準偏差)で異常検知
- MLflowで学習したIsolation Forestモデルによるリアルタイム推論
- 異常検知時にSlack/PagerDutyアラート発信
- ダッシュボードでリアルタイムモニタリング
8. クイズ
学(まな)んだ内容(ないよう)を確認(かくにん)しましょう。
Q1. DatabricksのLakehouse Architectureとは何であり、従来のData LakeとData Warehouseのどのような限界を解決しますか?
A:Lakehouse ArchitectureはData Lakeの柔軟性(非構造化データ保存、低コストストレージ)とData Warehouseの安定性(ACIDトランザクション、スキーマ管理、パフォーマンス)を組み合わせた統合プラットフォームです。Data Lakeの限界であるデータ品質管理の不在、トランザクション未サポート、メタデータ管理の不備を解決し、Data Warehouseの限界である非構造化データ処理不可、高コスト、MLワークロード未サポートを解決します。Delta Lakeがストレージレイヤーとして、Unity Catalogがガバナンスレイヤーとして、Lakehouseの核心を構成します。
Q2. SparkでAQE(Adaptive Query Execution)を有効化するとどのような問題が自動的に最適化されますか?
A:AQEが解決する3つの核心的問題は以下の通りです。第一に、過剰なシャッフルパーティション問題:シャッフル後の小さなパーティションを自動マージ(Coalesce)してタスク数を削減します。第二に、データスキュー問題:ランタイムでスキューを検知し、大きなパーティションを自動分割して均等処理します。第三に、Join戦略の非効率:ランタイム統計に基づきSort-Merge JoinからBroadcast Hash Joinに自動切り替えします。すべての最適化はコード変更なしで設定のみで適用されます。
Q3. Unity Catalogの3レベルネームスペース(catalog.schema.table)構造がデータガバナンスに重要な理由は何ですか?
A:3レベルネームスペースは組織のデータ資産を体系的に分類し、きめ細かいアクセス制御を可能にします。Catalogレベルで環境(production/development)やドメイン(finance/marketing)を分離し、Schemaレベルでデータ主題領域を区分し、Tableレベルで個別データセットを管理します。各レベルで独立した権限設定が可能で最小権限の原則を適用でき、クロスカタログJoinもサポートしながらデータリニエージが自動追跡されます。
Q4. RAGパイプラインにおけるチャンクサイズとオーバーラップが検索品質に与える影響は何ですか?
A:チャンクサイズが小さすぎるとコンテキスト情報が不足して検索結果の意味が不完全になり、大きすぎるとノイズが多く含まれて関連性が低下します。一般的に500-1500トークンが適切です。オーバーラップはチャンク境界で情報が途切れることを防止します。10-20%のオーバーラップが一般的で、オーバーラップがないと文章が途中で切れて意味を失う可能性があります。最適値はドキュメント特性に依存するため、実験を通じて決定する必要があります。
Q5. FDEのPOCプロジェクトでパフォーマンス目標を達成できなかった場合、どのようなステップで問題を分析し対応すべきですか?
A:体系的な分析が必要です。第1段階診断:Spark UIでStage別実行時間、シャッフルデータ量、スキュー有無、GC時間を分析します。第2段階最適化:パーティショニング戦略変更、ブロードキャストジョイン適用、AQE有効化、キャッシング戦略、クラスターサイズ調整を試みます。第3段階コミュニケーション:最適化結果と現実的に達成可能な数値を顧客に透明に共有します。追加最適化ロードマップを提示し、必要に応じてアーキテクチャレベルの変更(例:バッチからストリーミングへの転換)を提案します。核心はデータに基づいて問題を隠さず透明にコミュニケーションすることです。
9. 参考(さんこう)資料(しりょう)
公式ドキュメント
- Databricks公式ドキュメント - docs.databricks.com - Databricksプラットフォーム全体リファレンス
- Apache Spark公式ドキュメント - spark.apache.org/docs - Spark APIとガイド
- Delta Lake公式ドキュメント - docs.delta.io - Delta Lakeオープンソースドキュメント
- MLflow公式ドキュメント - mlflow.org/docs - MLflow APIとガイド
資格証準備
- Databricks Academy - academy.databricks.com - 無料/有料トレーニングコース
- Data Engineer Associate試験ガイド - databricks.com/learn/certification
- Gen AI Engineer Associate試験ガイド - databricks.com/learn/certification
- Databricks Community Edition - community.cloud.databricks.com - 無料実習環境
学習リソース
- Learning Spark, 2nd Edition - Jules Damji他著、Sparkバイブル
- Delta Lake: The Definitive Guide - O'Reilly、Delta Lake公式ガイドブック
- Databricks Blog - databricks.com/blog - 最新技術アップデートと事例
- Data + AI Summit動画 - databricks.com/dataaisummit - 年次カンファレンスセッション
業界動向(どうこう)
- Databricks IPO関連ニュース - Bloomberg、Reutersなどで追跡可能
- Lakehouseアーキテクチャ論文 - "Lakehouse: A New Generation of Open Platforms"
- Gartner Magic Quadrant for Cloud DBMS - 市場ポジショニング分析
コミュニティ
- Databricks Community Forum - community.databricks.com
- r/databricks - reddit.com/r/databricks - コミュニティQ&A
- Databricks Slack - 公式Slackチャンネルでエンジニアと直接コミュニケーション
まとめ
DatabricksのAI Engineer(FDE)ポジションはAI時代(じだい)の最(もっと)もエキサイティングな役割の一つです。単純にコードを書(か)くだけでなく、世界最高水準(すいじゅん)のLakehouse技術をエンタープライズ顧客に直接届(とど)ける役割です。
このガイドで扱(あつか)った内容をまとめると:
- Databricksは620億ドルの企業価値を持(も)つLakehouse発明企業で、FDEは顧客現場の核心チーム
- Spark、Delta Lake、Unity Catalog、Mosaic AIが技術的核心スタック
- Medallion ArchitectureとRAGパイプライン構築能力が差別化(さべつか)要素(ようそ)
- 8ヶ月の体系的(たいけいてき)な学習と3つのポートフォリオプロジェクトで準備可能
- 顧客対応能力が技術と同じくらい重要
このロードマップに従(したが)って体系的に準備すれば、Databricks FDEとしてのキャリアを始(はじ)める確固(かっこ)たる基盤(きばん)になるでしょう。LakehouseとAIの交差点(こうさてん)にあるこの分野は急速(きゅうそく)に成長しており、この能力を持つエンジニアへの需要(じゅよう)は今後(こんご)も増(ふ)え続(つづ)けるでしょう。
頑張(がんば)ってください!