大数据领域数据服务：实现数据的高效利用与价值创造-优快云博客

大数据数据服务设计实战：从数据到价值的高效转化之路

——基于湖仓一体架构的可复用数据服务实现指南

摘要/引言

问题陈述：企业的“数据困境”

今天，几乎所有企业都在谈“数据驱动”，但大部分企业仍被困在**“数据有很多，价值没多少”**的困境里：

数据孤岛：业务系统、数仓、数据湖中的数据彼此隔离，取一次用户订单数据要跨3个系统，重复开发成本高；
复用率低：同一份用户画像数据，市场部做活动要查一遍，产品部做迭代又要查一遍，没有统一的服务接口；
性能瓶颈：直接查询原始数据湖的响应时间长达数分钟，业务人员等得不耐烦；
价值模糊：数据停留在“统计报表”阶段，不知道如何转化为可复用的服务（比如用户画像API、销量预测接口），更别说变现。

这些问题的核心，不是“没有数据”，而是**“数据没有被高效组织和服务化”**。

核心方案：湖仓一体的数据服务设计框架

针对上述问题，本文提出**“湖仓一体+分层服务+治理保障”**的解决方案：

湖仓一体架构：用Delta Lake整合数据湖（灵活性）与数据仓（结构化管理），解决数据孤岛和 schema 不一致问题；
数据服务分层：将数据服务拆分为“数据资产层→服务封装层→服务治理层→消费层”，实现从原始数据到可复用服务的闭环；
性能与治理：通过预计算、缓存、索引优化服务性能，用监控、权限、日志系统保障服务稳定性。

你能获得什么？

读完本文，你将掌握：

数据服务的核心设计逻辑（从数据到服务的全链路思考）；
湖仓一体架构下的数据建模与服务封装实战；
数据服务的性能优化与治理方法；
一套可直接复用的数据服务代码模板（含API、缓存、Spark优化）。

文章导览

本文将按“背景→概念→实战→优化→展望”的逻辑展开：

先讲清楚“为什么要做数据服务”；
解释数据服务的核心概念（湖仓一体、分层模型）；
手把手教你从0到1实现一个用户画像数据服务；
分享性能优化的 tricks 和常见坑的解决方案；
探讨数据服务的未来方向（实时、AI增强、变现）。

目标读者与前置知识

目标读者

中初级数据工程师：想转型做数据服务，但不知道如何落地；
数据产品经理：想理解数据服务的技术逻辑，更好地设计产品；
后端/全栈开发者：想扩展技能边界，进入大数据领域；
企业IT人员：负责企业数据资产的变现，需要可复用的服务方案。

前置知识要求

基础大数据知识：了解Hadoop/Spark的核心概念（比如RDD、DataFrame）；
数据库基础：熟悉SQL、表分区、索引的作用；
编程基础：会用Python（或Java）写简单的代码；
工具基础：用过Docker（可选，但推荐）、Postman（接口测试）。

问题背景与动机：为什么数据服务是大数据的“最后一公里”？

1. 企业数据的“三座大山”

数据孤岛：不同部门用不同的存储（MySQL、Hive、S3），数据格式不统一，取数要跨5个系统；
复用率低：同一份“用户购买行为”数据，市场部、产品部、风控部各查一遍，重复开发占比达40%；
价值断层：数据停留在“报表”阶段，无法转化为业务能直接调用的服务（比如“给我这个用户的画像”→ 要写SQL查3张表，而不是调用一个API）。

2. 现有方案的局限性

传统数仓（比如Hive）：
优点：结构化管理，查询稳定；
缺点：灵活性差（无法处理半结构化数据，比如JSON日志），服务化能力弱（没有现成的API接口）。
纯数据湖（比如S3+Parquet）：
优点：存储成本低，支持所有数据格式；
缺点：查询性能差（没有索引），数据质量无法保障（schema 混乱）。
传统API服务：
优点：接口标准化；
缺点：直接查询原始数据，性能瓶颈明显（比如查1000万条数据要10秒）。

3. 数据服务的核心价值

数据服务的本质，是将“数据资产”转化为“可消费的服务能力”，解决“数据→价值”的最后一公里问题：

对业务：降低用数成本（不用写复杂SQL，调用API就行）；
对技术：提升复用率（一份数据服务支持多个业务场景）；
对企业：加速价值变现（比如将用户画像服务卖给合作伙伴，或支撑内部AI模型）。

核心概念与理论基础

在开始实战前，我们需要统一对“数据服务”的认知。

1. 数据服务的定义

数据服务（Data Service）：基于企业的大数据资产，通过标准化接口（RESTful API、RPC）向业务提供“数据查询、分析、预测”等能力的服务。
比如：

用户画像API：输入user_id，返回用户的“年龄、偏好、消费能力”；
销量预测API：输入“商品ID+时间范围”，返回未来7天的销量；
实时库存API：输入“商品ID”，返回当前的库存数量。

2. 数据服务的分层模型（重点！）

数据服务不是“把数据直接暴露成API”，而是分层设计的结果。完整的分层模型如下：

graph TD
    A[数据资产层] --> B[服务封装层]
    B --> C[服务治理层]
    C --> D[消费层]
    
    A[数据资产层] --> 存储：湖仓一体（Delta Lake）
    A --> 内容：ODS（原始数据）、DWD（明细数据）、DWS（聚合数据）、ADS（应用数据）
    
    B[服务封装层] --> 技术：FastAPI/Flask、Spark/Flink
    B --> 功能：API设计、缓存、异步处理
    
    C[服务治理层] --> 功能：监控（Prometheus）、日志（ELK）、权限（OAuth2）、降级（Hystrix）
    
    D[消费层] --> 用户：业务系统、数据分析师、AI模型
    D --> 方式：API调用、SDK、可视化报表

各层的作用：

数据资产层：数据服务的“原料库”，用湖仓一体（Delta Lake）存储结构化、半结构化数据，按“ODS→DWD→DWS→ADS”分层（后文会详细讲）；
服务封装层：将数据转化为服务的“加工厂”，用API框架（FastAPI）封装查询逻辑，用缓存（Redis）提升性能；
服务治理层：数据服务的“保障系统”，解决“服务稳不稳、谁能调用、出问题怎么办”；
消费层：数据服务的“用户端”，支持业务系统、分析师、AI模型等多种消费方式。

3. 湖仓一体：数据服务的“地基”

为什么选湖仓一体（Lakehouse）作为数据资产层的架构？
传统数仓（比如Teradata）的问题是“灵活度低”（无法处理非结构化数据），纯数据湖（比如S3）的问题是“管理混乱”（没有ACID、schema 不统一）。

湖仓一体（比如Delta Lake、Iceberg）结合了两者的优点：

支持ACID事务：解决数据写入的一致性问题（比如并发写入不会丢数据）；
schema evolution：数据结构变化时，不需要修改历史数据（比如新增字段不会报错）；
高性能查询：支持Z-order索引、分区，查询速度比纯数据湖快5-10倍；
兼容性：支持Spark、Presto、Trino等多种计算引擎。

4. 数据分层：从“原始数据”到“服务数据”的必经之路

数据服务的性能和复用率，核心在数据分层。我们通常将数据分为4层：

层级	名称	作用	示例
ODS	原始数据层	存储未加工的原始数据（比如日志、数据库备份）	用户行为日志（JSON）
DWD	明细数据层	清洗、结构化原始数据（比如补全缺失值、去除重复）	用户明细（user_id、name）
DWS	聚合数据层	预计算常用的聚合指标（比如用户的“总订单数”“最近购买时间”）	用户画像聚合表
ADS	应用数据层	为特定业务场景准备的数据（比如市场部的“活动用户列表”）	活动目标用户表

关键原则：数据服务尽量查询DWS/ADS层，而不是ODS/DWD层。因为DWS层已经做了聚合（比如用户的总订单数），查询速度比明细层快10倍以上！

环境准备：搭建湖仓一体的数据服务环境

接下来，我们要搭建一个可复现的环境，包含：

湖仓存储：Delta Lake（用S3或本地存储模拟）；
计算引擎：Spark 3.2+（处理数据）；
API框架：FastAPI（封装服务）；
缓存：Redis（提升性能）；
容器化：Docker（避免“环境不一致”的坑）。

1. 工具版本清单

工具	版本	作用
Python	3.8+	编写API和Spark代码
Spark	3.2.4	数据计算
Delta Lake	1.2.1	湖仓存储
FastAPI	0.95.2	API框架
Uvicorn	0.22.0	FastAPI的ASGI服务器
Redis	7.0.11	缓存
Docker	24.0.2	容器化环境

2. 用Docker快速搭建环境

为了避免“本地环境配置半小时”的问题，我们用Docker Compose一键启动所有服务。

步骤1：创建`docker-compose.yml`

version: "3.8"

services:
  # Spark 服务（用于数据计算）
  spark-master:
    image: bitnami/spark:3.2.4
    environment:
      - SPARK_MODE=master
      - SPARK_RPC_AUTHENTICATION_ENABLED=no
      - SPARK_RPC_ENCRYPTION_ENABLED=no
      - SPARK_LOCAL_STORAGE_ENCRYPTION_ENABLED=no
      - SPARK_SSL_ENABLED=no
    ports:
      - "8080:8080"  # Spark Web UI
      - "7077:7077"  # Spark Master端口

  spark-worker:
    image: bitnami/spark:3.2.4
    environment:
      - SPARK_MODE=worker
      - SPARK_MASTER_URL=spark://spark-master:7077
      - SPARK_WORKER_MEMORY=2G
      - SPARK_WORKER_CORES=2
    depends_on:
      - spark-master

  # Redis 缓存服务
  redis:
    image: redis:7.0.11
    ports:
      - "6379:6379"

  # FastAPI 服务（数据服务API）
  data-service:
    build: .
    ports:
      - "8000:8000"
    environment:
      - SPARK_MASTER_URL=spark://spark-master:7077
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      - DELTA_LAKE_PATH=/data/delta  # 本地存储模拟S3
    volumes:
      - ./data:/data  # 本地数据目录映射到容器
    depends_on:
      - spark-master
      - redis

步骤2：创建`Dockerfile`（用于构建FastAPI服务）

# 基础镜像
FROM python:3.8-slim

# 设置工作目录
WORKDIR /app

# 安装系统依赖（比如Java，Spark需要）
RUN apt-get update && apt-get install -y openjdk-11-jre-headless && rm -rf /var/lib/apt/lists/*

# 安装Python依赖
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 复制代码
COPY . .

# 启动FastAPI服务
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--reload"]

步骤3：创建`requirements.txt`

pyspark==3.2.4
delta-spark==1.2.1
fastapi==0.95.2
uvicorn==0.22.0
redis==4.5.5
pydantic==1.10.7
python-multipart==0.0.6

步骤4：启动环境

在项目根目录执行：

docker-compose up -d

验证是否启动成功：

访问http://localhost:8080：Spark Master的Web UI；
访问http://localhost:8000/docs：FastAPI自动生成的API文档（Swagger UI）；
用redis-cli连接localhost:6379：Redis服务正常。

分步实现：从0到1构建用户画像数据服务

现在进入核心实战：我们要实现一个用户画像API，输入user_id，返回用户的“基本信息+消费行为+偏好”。

需求说明：

数据来源：用户明细数据（DWD层）、订单明细数据（DWD层）；
服务逻辑：关联用户表和订单表，计算“总订单数”“最近购买时间”“偏好分类”；
性能要求：响应时间≤500ms（缓存命中时≤100ms）。

步骤1：准备湖仓数据（ODS→DWS层）

首先，我们要在Delta Lake中创建用户DWD层和订单DWD层，并生成用户画像DWS层（预聚合）。

1.1 模拟原始数据（ODS层）

我们用本地CSV文件模拟原始数据：

users_ods.csv（用户原始数据）：

user_id,name,email,register_time
123,张三,zhangsan@example.com,2023-01-01 10:00:00
456,李四,lisi@example.com,2023-02-01 14:30:00

orders_ods.csv（订单原始数据）：

order_id,user_id,product_id,amount,order_time
1001,123,P001,299,2023-03-01 09:00:00
1002,123,P002,199,2023-03-15 14:00:00
1003,456,P003,499,2023-04-01 10:00:00

1.2 构建DWD层（明细数据）

用Spark将ODS层数据清洗后写入Delta Lake的DWD层：

创建data_process.py（Spark数据处理脚本）：

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, to_timestamp

def create_dwd_layers():
    # 初始化Spark Session（带Delta Lake扩展）
    spark = SparkSession.builder \
        .appName("DWD_Layer_Build") \
        .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
        .config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
        .getOrCreate()

    # ------------------------------
    # 1. 处理用户ODS→DWD
    # ------------------------------
    users_ods = spark.read.csv(
        path="/data/ods/users_ods.csv",
        header=True,
        schema="user_id string, name string, email string, register_time string"
    )

    # 数据清洗：转换register_time为Timestamp类型
    users_dwd = users_ods.withColumn(
        "register_time", to_timestamp(col("register_time"), "yyyy-MM-dd HH:mm:ss")
    )

    # 写入Delta Lake（DWD层）
    users_dwd.write.format("delta") \
        .mode("overwrite") \
        .save("/data/delta/dwd/users")

    # ------------------------------
    # 2. 处理订单ODS→DWD
    # ------------------------------
    orders_ods = spark.read.csv(
        path="/data/ods/orders_ods.csv",
        header=True,
        schema="order_id string, user_id string, product_id string, amount int, order_time string"
    )

    # 数据清洗：转换order_time为Timestamp类型
    orders_dwd = orders_ods.withColumn(
        "order_time", to_timestamp(col("order_time"), "yyyy-MM-dd HH:mm:ss")
    )

    # 写入Delta Lake（DWD层）
    orders_dwd.write.format("delta") \
        .mode("overwrite") \
        .partitionBy("order_time")  # 按时间分区，加速查询
        .save("/data/delta/dwd/orders")

    # ------------------------------
    # 3. 生成用户画像DWS层（预聚合）
    # ------------------------------
    # 关联用户DWD和订单DWD
    user_profile_dws = users_dwd.join(orders_dwd, on="user_id", how="left") \
        .groupBy("user_id", "name", "email") \
        .agg(
            col("user_id").alias("user_id"),  # 保持user_id
            col("name").alias("name"),        # 保持name
            col("email").alias("email"),      # 保持email
            col("order_id").count().alias("total_orders"),  # 总订单数
            col("order_time").max().alias("recent_purchase_time"),  # 最近购买时间
            col("product_id").first().alias("favorite_category")  # 偏好分类（假设第一个购买的分类是偏好）
        )

    # 写入Delta Lake（DWS层）
    user_profile_dws.write.format("delta") \
        .mode("overwrite") \
        .save("/data/delta/dws/user_profile")

    spark.stop()

if __name__ == "__main__":
    create_dwd_layers()

1.3 执行数据处理脚本

在Docker容器中执行：

# 进入FastAPI容器
docker exec -it <data-service-container-id> bash

# 执行脚本
python data_process.py

验证数据是否写入成功：
用Spark SQL查询DWS层：

# 进入Spark Master容器
docker exec -it <spark-master-container-id> bash

# 启动Spark SQL CLI
spark-sql \
  --conf spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension \
  --conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog

# 查询用户画像DWS层
SELECT * FROM delta.`/data/delta/dws/user_profile` WHERE user_id='123';

输出结果应包含：user_id=123、total_orders=2、recent_purchase_time=2023-03-15 14:00:00。

步骤2：封装API服务（FastAPI）

接下来，我们用FastAPI封装DWS层的数据，提供RESTful API。

2.1 编写API代码（`main.py`）

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from pyspark.sql import SparkSession
from pyspark.sql.functions import col
import redis
import json
from datetime import datetime

# ------------------------------
# 1. 初始化服务
# ------------------------------
app = FastAPI(title="用户画像数据服务", version="1.0")

# 初始化Spark Session（连接Spark Master）
spark = SparkSession.builder \
    .appName("UserProfileService") \
    .master("spark://spark-master:7077")  # 连接Docker中的Spark Master
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
    .config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
    .getOrCreate()

# 初始化Redis缓存（连接Docker中的Redis）
redis_client = redis.Redis(
    host="redis",
    port=6379,
    db=0,
    decode_responses=True  # 自动将bytes转为字符串
)

# ------------------------------
# 2. 定义请求/响应模型（Pydantic）
# ------------------------------
class UserProfileRequest(BaseModel):
    user_id: str  # 输入：用户ID

class UserProfileResponse(BaseModel):
    user_id: str           # 用户ID
    name: str              # 姓名
    email: str             # 邮箱
    total_orders: int      # 总订单数
    recent_purchase_time: str  # 最近购买时间（格式化）
    favorite_category: str # 偏好分类

# ------------------------------
# 3. 实现API接口
# ------------------------------
@app.post("/api/v1/user/profile", response_model=UserProfileResponse)
async def get_user_profile(req: UserProfileRequest):
    """获取用户画像"""
    # 步骤1：先查缓存（避免重复查询Spark）
    cache_key = f"user:profile:{req.user_id}"
    cached_data = redis_client.get(cache_key)
    if cached_data:
        return json.loads(cached_data)  # 缓存命中，直接返回

    # 步骤2：缓存未命中，查询Delta Lake的DWS层
    try:
        # 读取用户画像DWS层
        profile_df = spark.read.format("delta").load("/data/delta/dws/user_profile")
        
        # 过滤用户（用col函数避免SQL注入）
        user_profile = profile_df.filter(col("user_id") == req.user_id).first()

        # 检查用户是否存在
        if not user_profile:
            raise HTTPException(status_code=404, detail="用户不存在")

        # 步骤3：处理数据格式（比如时间格式化）
        profile_dict = user_profile.asDict()
        profile_dict["recent_purchase_time"] = profile_dict["recent_purchase_time"].strftime("%Y-%m-%d %H:%M:%S")

        # 步骤4：存入缓存（过期时间5分钟）
        redis_client.setex(
            name=cache_key,
            time=300,  # 5分钟后过期
            value=json.dumps(profile_dict)
        )

        # 步骤5：返回响应
        return profile_dict

    except Exception as e:
        raise HTTPException(status_code=500, detail=f"服务异常：{str(e)}")

# ------------------------------
# 4. 启动时预热缓存（可选）
# ------------------------------
@app.on_event("startup")
async def warm_cache():
    """预热高频用户的缓存"""
    high_freq_users = ["123", "456"]  # 假设这两个用户查询频繁
    for user_id in high_freq_users:
        # 调用get_user_profile函数，将结果存入缓存
        await get_user_profile(UserProfileRequest(user_id=user_id))

步骤3：测试API服务

FastAPI自动生成了Swagger UI，访问http://localhost:8000/docs，可以直接测试接口：

点击/api/v1/user/profile接口的“Try it out”；
输入user_id=123；
点击“Execute”，查看响应：

{
  "user_id": "123",
  "name": "张三",
  "email": "zhangsan@example.com",
  "total_orders": 2,
  "recent_purchase_time": "2023-03-15 14:00:00",
  "favorite_category": "P001"
}

步骤4：验证缓存效果

用redis-cli查看缓存：

redis-cli
127.0.0.1:6379> GET user:profile:123
"{\"user_id\":\"123\",\"name\":\"张三\",\"email\":\"zhangsan@example.com\",\"total_orders\":2,\"recent_purchase_time\":\"2023-03-15 14:00:00\",\"favorite_category\":\"P001\"}"

再次调用API，响应时间从2秒（第一次查询Spark）降到50ms（缓存命中）！

关键代码解析与深度剖析

现在，我们要深入讲解核心代码的设计逻辑，回答“为什么这么写”，而不是“是什么”。

1. 为什么用Delta Lake存储DWS层？

Delta Lake的三大优势完美匹配数据服务的需求：

Schema Evolution：如果用户画像新增“年龄”字段，Delta Lake会自动兼容旧数据（不需要修改表结构）；
ACID事务：数据写入时不会出现“部分成功”的情况，保障服务的数据一致性；

Z-order索引：对于高频查询的字段（比如user_id），可以创建Z-order索引，查询速度提升5-10倍：

# 为user_id创建Z-order索引
from delta.tables import DeltaTable
delta_table = DeltaTable.forPath(spark, "/data/delta/dws/user_profile")
delta_table.optimize().executeZOrderBy("user_id")

2. 为什么用FastAPI而不是Flask？

FastAPI的三个核心优势：

高性能：基于ASGI（异步网关接口），比Flask的WSGI快2-3倍；
自动文档：自动生成Swagger UI和Redoc，不用手动写API文档；
类型提示：用Pydantic定义请求/响应模型，自动校验参数（比如user_id必须是字符串），减少Bug。

3. 为什么用Redis缓存而不是Memcached？

Redis比Memcached多了持久化和复杂数据结构的支持：

持久化：缓存数据不会因Redis重启而丢失（可选RDB/AOF）；
过期时间：setex命令可以设置缓存的过期时间，避免数据 stale；
分布式：支持集群模式，适合高并发场景。

4. 为什么查询DWS层而不是DWD层？

看一个对比：

查询DWD层（明细）：需要关联用户表和订单表，做group by，数据量是100万条→响应时间2秒；
查询DWS层（预聚合）：直接取现成的聚合结果，数据量是10万条→响应时间200ms。

结论：数据服务的性能瓶颈，80%出在“查询明细层”。预聚合DWS层，是提升性能的最有效手段！

5. 如何避免SparkSession的“重复初始化”？

在API代码中，我们将SparkSession的初始化放在全局，而不是接口函数内部。因为：

SparkSession是“重量级”对象，初始化一次需要数秒；
全局初始化后，所有接口请求都复用同一个SparkSession，提升性能。

性能优化与最佳实践

现在，我们的服务已经能跑通，但还能更“快”更“稳”。以下是数据服务的性能优化指南。

1. 数据层优化：预聚合+索引

预聚合到DWS/ADS层：尽量让服务查询聚合层，减少实时计算；
Delta Lake索引：对高频查询字段（比如user_id）做Z-order索引，加速过滤；
分区存储：按时间（order_time）或业务维度（product_id）分区，减少扫描的数据量。

2. 服务层优化：缓存+异步

缓存策略：
- 高频数据：用Redis缓存（比如用户画像）；
- 低频数据：不缓存（避免占用内存）；
- 过期时间：根据数据更新频率设置（比如用户画像每天更新，过期时间设为86400秒）；

异步处理：对慢查询（比如统计过去一年的销量），用Celery做异步处理，返回任务ID，后续查询结果：

# 用Celery异步处理慢查询
from celery import Celery

celery = Celery("tasks", broker="redis://redis:6379/0")

@celery.task
def compute_yearly_sales(user_id: str):
    # 慢查询逻辑
    pass

@app.post("/api/v1/user/yearly_sales")
async def get_yearly_sales(req: UserSalesRequest):
    task = compute_yearly_sales.delay(req.user_id)
    return {"task_id": task.id}

3. 计算层优化：Spark资源调优

资源分配：给Spark作业分配足够的CPU和内存（比如--executor-memory 4G --executor-cores 2）；
Shuffle优化：减少Shuffle的数据量（比如groupBy前先过滤，用reduceByKey代替groupByKey）；
谓词下推：让过滤条件尽可能下推到存储层（比如Delta Lake支持谓词下推，过滤user_id时不会扫描全表）。

4. 最佳实践总结

数据服务的核心是“复用”：尽量设计通用的服务（比如用户画像API支持多业务场景），而不是为每个业务做定制；
服务接口要“简单”：输入参数不要超过5个，响应体不要返回冗余字段；
监控是“生命线”：用Prometheus监控QPS、延迟、错误率，用Grafana做可视化，发现问题及时报警。

常见问题与解决方案

在实战中，你可能会遇到这些坑，提前给你解决方案：

问题1：SparkSession初始化失败

报错：Could not find spark-master:7077
原因：Docker容器之间的网络不通，Spark Master的hostname无法解析。
解决方案：

检查docker-compose.yml中的spark-master服务是否启动；
用spark://spark-master:7077作为Master URL（而不是localhost）。

问题2：Delta Lake读取失败

报错：Table not found: delta./data/delta/dws/user_profile``
原因：没有加载Delta Lake的扩展。
解决方案：
在SparkSession中添加以下配置：

.config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
.config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog")