拓冰网站定制 
简介本资源为基于云原生架构的大数据 Lakehouse 服务架构设计源码面向大数据开发工程师、架构学习者及需要搭建数据湖分析平台的技术人员帮助理解数据湖与数据仓库融合的一站式处理方案。压缩包共546个文件约2.75MB以310个Java文件为核心业务实现辅以66个ts与49个tsx构建前端界面28个Scala支撑大数据计算另有scss样式、xml与yaml配置、dockerfile容器化文件及sql脚本等覆盖开发、构建、部署全流程。项目包含lakehouse-common、lakehouse-ui、lakehouse-api等模块分别承担通用封装、界面展示与数据交互接口并兼容主流云厂商对象存储降低迁移成本。目前已有396人学习下载适合希望深入理解云原生大数据架构、参考完整工程组织与模块划分的读者研读借鉴。1. 云原生 Lakehouse 服务架构源码548 个文件里到底装了什么拿到一个 548 文件的源码包第一反应不该是「先跑起来」而是先搞清楚它到底想解决什么问题。这套基于云原生大数据处理的 Lakehouse 服务架构设计源码核心目标很明确把数据湖的存储弹性和数据仓库的事务能力捏在一起让用户不用在「便宜但乱」和「快但贵」之间二选一。它兼容主流云厂商对象存储意味着你现有的 OSS、S3、COS 都能直接挂进来不用为了用这套架构去换基础设施。从文件构成看310 个 Java 文件撑起了后端主体66 个 TypeScript 加 49 个 tsx 负责前端交互28 个 Scala 文件大概率落在 Spark 或 Flink 的计算层22 个 SCSS 管样式17 个 XML 和 6 个 YAML 分别对应 Maven 配置和容器编排。这套组合拳打下来适合两类人一是正在做大数据平台选型、想看看 Lakehouse 落地长什么样的架构师二是手里有云存储资源、想搭一套能跑 SQL 也能跑 Spark 的查询层的中高级开发。如果你只是想要一个能跑 demo 的单机玩具这份源码的组件拆分粒度可能会让你觉得「重」但如果你要的是能往生产环境推的骨架它的分层方式值得逐层拆开看。2. 从 lakehouse-common 到 lakehouse-api模块拆分与依赖关系2.1 三个核心组件的职责边界源码里最显眼的三个模块是 lakehouse-common、lakehouse-ui、lakehouse-api。这不是随便切的它对应的是「通用能力下沉、接口层薄、前端独立」的典型云原生分层思路。lakehouse-common 是地基放的是跨模块复用的东西对象存储的抽象客户端、元数据模型的 POJO、通用异常和工具类。你去看它的 pom.xml大概率会看到对 Hadoop 客户端、云厂商 SDK 的依赖声明。这个模块的设计意图是让上层不直接碰具体存储协议换云厂商的时候只改 common 里的适配层。lakehouse-api 是服务入口对外暴露 REST 接口对内编排查询任务。它依赖 common但不依赖 ui。Java 文件在这里最密集Controller、Service、DTO 转换都在这一层。如果你要加一个新的查询接口改这里就够了。lakehouse-ui 是独立的前端工程TypeScript 和 tsx 文件集中在这里。它通过 HTTP 调 api 层构建产物是静态资源可以单独部署到 Nginx 或对象存储的静态托管上。这种前后端分离的物理结构意味着你可以只替换 ui 而不动后端。2.2 依赖关系的验证方法拿到源码后别急着编译先用 Maven 的依赖树命令把模块间关系看清楚# 在根目录执行查看模块聚合关系 mvn -q -DskipTests dependency:tree -DoutputFiledeps.txt # 只看 lakehouse-api 对 common 的依赖路径 mvn -pl lakehouse-api -am dependency:tree | grep lakehouse-common第一行命令会把整个项目的依赖树导出到 deps.txt重点看有没有版本冲突——尤其是 Hadoop、Spark、云厂商 SDK 这三类库它们经常因为传递依赖打架。第二行命令用-pl指定模块、-am同时构建依赖模块能确认 api 层是否真的引用了 common 的当前版本而不是从远程仓库拉了一个旧包。参数说明-q静默模式只输出结果-DskipTests跳过测试编译加速-DoutputFile把树写到文件方便搜索。如果输出里出现omitted for conflict说明有版本被仲裁掉了这时候要去父 pom 的 dependencyManagement 里锁版本。2.3 容器化文件的分布逻辑源码根目录和子模块下出现了多个 Dockerfile这不是冗余。常见做法是每个可独立部署的模块带自己的 Dockerfile比如 api 模块的 Dockerfile 负责打 Java 运行镜像ui 模块的 Dockerfile 做多阶段构建——先用 node 镜像编译 tsx再把 dist 拷进 nginx 镜像。# 典型的 ui 模块多阶段构建写法根据源码结构推断 FROM node:18-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build FROM nginx:alpine COPY --frombuilder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf这段 Dockerfile 的逻辑是第一阶段用 node 镜像装依赖、编译前端第二阶段只把编译产物和 nginx 配置拷进最终镜像。这样出来的镜像不含 node_modules 和源码体积能小一个数量级。参数上注意npm ci比npm install更适合 CI 环境它严格按 lock 文件装不会偷偷升级小版本。nginx.conf 通常要配try_files $uri $uri/ /index.html否则前端路由刷新会 404。3. 本地跑通环境变量、构建顺序与启动参数3.1 .env.development 里该改什么源码里带了 .env.development这是开发环境的配置入口。别直接拿去生产用但本地跑通必须先把它填对。典型内容会包括对象存储的 endpoint、access key、secret key、bucket 名称以及数据库连接和 Spark 相关参数。# .env.development 关键项示例按实际源码字段调整 LAKEHOUSE_STORAGE_TYPEs3 LAKEHOUSE_STORAGE_ENDPOINThttp://127.0.0.1:9000 LAKEHOUSE_STORAGE_ACCESS_KEYminioadmin LAKEHOUSE_STORAGE_SECRET_KEYminioadmin LAKEHOUSE_STORAGE_BUCKETlakehouse-dev LAKEHOUSE_META_DB_URLjdbc:mysql://127.0.0.1:3306/lakehouse?useSSLfalse LAKEHOUSE_SPARK_MASTERlocal[*]逻辑说明本地开发最省事的方案是用 MinIO 模拟 S3 兼容存储endpoint 指向本地 9000 端口access key 和 secret key 用默认的 minioadmin。LAKEHOUSE_SPARK_MASTERlocal[*]让 Spark 用本地所有核心跑不用起集群。元数据库用 MySQL 存表结构和分区信息这是 Lakehouse 的「仓库」那一半。参数怎么改如果你用阿里云 OSSstorage type 改成 ossendpoint 换成对应 region 的地址access key 换成 RAM 用户的。注意 bucket 要提前建好且权限策略允许 list 和 get/put。useSSLfalse只在本地 MySQL 没配证书时用生产必须去掉。3.2 构建顺序与跳过测试这个项目是多模块 Maven 工程构建顺序由 pom 的 modules 声明决定但手动构建时建议从 common 开始# 先装 common 到本地仓库再构建 api mvn -pl lakehouse-common install -DskipTests mvn -pl lakehouse-api -am package -DskipTests # 前端单独构建 cd lakehouse-ui npm install npm run build第一行把 common 装进本地 .m2 仓库这样 api 构建时能直接引用。第二行-am会顺带构建 api 依赖的其他模块。-DskipTests在首次跑通时建议加上因为测试用例可能依赖外部存储或数据库环境没配好会卡住。前端npm run build的产物在 dist 目录可以拷到 nginx 或者用npm run dev起开发服务器调接口。3.3 启动参数与端口约定Java 服务启动时环境变量注入方式取决于你用哪种部署。本地直接跑 jar 的话java -jar lakehouse-api/target/lakehouse-api-*.jar \ --spring.profiles.activedev \ --server.port8080 \ --lakehouse.storage.endpointhttp://127.0.0.1:9000--spring.profiles.activedev让 Spring Boot 加载 application-dev.yml 或对应的 .env.development。--server.port指定端口避免和本地其他服务冲突。后面的 storage endpoint 是覆盖配置的另一种方式优先级高于配置文件。常见坑是端口被占启动日志里看到Port 8080 was already in use就换一个。4. 避坑排查对象存储对接、Scala 编译与前端联调4.1 对象存储连不上报 UnknownHost 或 403现象启动后调查询接口日志里抛UnknownHostException或者403 Forbidden。原因endpoint 写成了带 bucket 的完整路径或者 access key 没有 list bucket 权限。S3 兼容协议里 endpoint 只到域名和端口bucket 是单独的参数。解决检查 .env 里 endpoint 是否只写到http://host:portbucket 字段单独填。用mc或aws s3 ls先验证凭证能不能列桶再启动服务。4.2 Scala 模块编译报 missing dependency现象mvn package到 Scala 模块时提示找不到scala-library或spark-core。原因Scala 版本和 Spark 版本不匹配或者 Maven 的 scala-maven-plugin 没配好。源码里 28 个 Scala 文件大概率依赖特定 Spark 版本。解决在父 pom 里确认scala.binary.version和spark.version对应比如 Spark 3.3 用 Scala 2.12。然后检查 scala-maven-plugin 的scalaVersion配置是否一致。别混用 2.11 和 2.12 的包。4.3 前端 npm install 卡在 node-sass现象npm install长时间不动最后报 node-sass 编译失败。原因SCSS 文件多22 个如果用了 node-sass 而不是 dart-sass在 Node 18 上容易编译不过。解决把 package.json 里的 node-sass 换成 sassdart-sass或者用npm install --legacy-peer-deps绕过 peer 依赖检查。更稳的做法是锁定 Node 版本到 16用 nvm 切过去再装。4.4 API 跨域前端调不通现象前端页面能打开但请求后端接口报 CORS 错误。原因ui 和 api 不同端口浏览器同源策略拦截。解决在 api 层的配置里加全局 CORS 配置允许前端 origin。或者本地开发时用 vite/webpack 的 proxy 把 /api 转发到 8080。生产环境用 nginx 反代同一域名下就不存在跨域。4.5 元数据库表没建启动报 SQL 异常现象服务启动时 Flyway 或 JPA 报Table lakehouse.xxx doesnt exist。原因源码可能带了 schema.sql 或 migration 脚本但没自动执行。解决找到 resources 下的 SQL 文件手动在 MySQL 里执行一遍。或者确认 spring.jpa.hibernate.ddl-auto 是不是 none改成 update 让它自动建表仅限开发环境。5. 进阶用法用对象存储做版本回溯与查询加速5.1 利用对象存储的版本控制做数据回溯Lakehouse 的一个隐藏优势是当底层对象存储开了版本控制你的数据文件天然有了后悔药。S3 和 OSS 都支持 bucket versioning每次覆盖写会保留历史版本。这意味着你可以通过指定 versionId 读回旧数据而不需要额外维护快照表。# 开启 MinIO 桶的版本控制本地验证用 mc version enable local/lakehouse-dev # 列出对象的历史版本 mc ls --versions local/lakehouse-dev/warehouse/orders/第一行命令对桶开启版本控制之后所有 put 操作都会生成新版本。第二行列出某个表目录下所有对象的历史版本输出里带 version-id。在查询层你可以扩展 common 模块的存储客户端让它支持按 versionId 读取这样就能实现「查某个时间点的数据」而不依赖 Hive 的分区快照。参数说明mc version enable是 MinIO 客户端命令换成 AWS CLI 就是aws s3api put-bucket-versioning。注意版本控制开启后存储成本会上升因为旧版本不删就一直占空间生产环境要配生命周期规则定期清理非当前版本。5.2 小文件合并与查询加速大数据场景下流式写入会产生大量小文件查询时元数据操作成为瓶颈。Lakehouse 架构里通常会在 common 层或独立的 compaction 模块做小文件合并。你可以基于源码里的 Scala 模块写一个定时任务用 Spark 读小文件、repartition 后重写。// 小文件合并的 Spark 作业骨架基于源码 Scala 模块扩展 val df spark.read.parquet(s3a://lakehouse-dev/warehouse/orders/) val merged df.repartition(10) // 按数据量调整分区数 merged.write.mode(overwrite).parquet(s3a://lakehouse-dev/warehouse/orders_compacted/)逻辑说明读入原始小文件目录repartition 到合理分区数通常按目标文件大小 128MB 反推再覆盖写到新目录。参数上repartition(10)的 10 要根据总数据量除以 128MB 估算太小还是小文件太大单文件过大会影响并行度。写完确认行数一致后再切换元数据指向新目录。5.3 验证清单与我的习惯每次改完存储层或查询层我会强制走一遍这个清单先用mc ls确认对象存在且大小合理再用 Spark SQL 跑select count(*)和select * limit 10验证可读最后用 API 层接口跑一次端到端查询确认返回结构没变。这套流程帮我挡掉过好几次「文件写进去了但元数据没更新」的翻车。从那以后我每次动存储配置或 compaction 逻辑都强制先跑一遍 count 和 limit 再推环境。希望帮到你。本文还有配套的精品资源点击获取 云原生Lakehouse架构源码解析：模块拆分、本地部署与对象存储对接
简介本资源为基于云原生架构的大数据 Lakehouse 服务架构设计源码面向大数据开发工程师、架构学习者及需要搭建数据湖分析平台的技术人员帮助理解数据湖与数据仓库融合的一站式处理方案。压缩包共546个文件约2.75MB以310个Java文件为核心业务实现辅以66个ts与49个tsx构建前端界面28个Scala支撑大数据计算另有scss样式、xml与yaml配置、dockerfile容器化文件及sql脚本等覆盖开发、构建、部署全流程。项目包含lakehouse-common、lakehouse-ui、lakehouse-api等模块分别承担通用封装、界面展示与数据交互接口并兼容主流云厂商对象存储降低迁移成本。目前已有396人学习下载适合希望深入理解云原生大数据架构、参考完整工程组织与模块划分的读者研读借鉴。1. 云原生 Lakehouse 服务架构源码548 个文件里到底装了什么拿到一个 548 文件的源码包第一反应不该是「先跑起来」而是先搞清楚它到底想解决什么问题。这套基于云原生大数据处理的 Lakehouse 服务架构设计源码核心目标很明确把数据湖的存储弹性和数据仓库的事务能力捏在一起让用户不用在「便宜但乱」和「快但贵」之间二选一。它兼容主流云厂商对象存储意味着你现有的 OSS、S3、COS 都能直接挂进来不用为了用这套架构去换基础设施。从文件构成看310 个 Java 文件撑起了后端主体66 个 TypeScript 加 49 个 tsx 负责前端交互28 个 Scala 文件大概率落在 Spark 或 Flink 的计算层22 个 SCSS 管样式17 个 XML 和 6 个 YAML 分别对应 Maven 配置和容器编排。这套组合拳打下来适合两类人一是正在做大数据平台选型、想看看 Lakehouse 落地长什么样的架构师二是手里有云存储资源、想搭一套能跑 SQL 也能跑 Spark 的查询层的中高级开发。如果你只是想要一个能跑 demo 的单机玩具这份源码的组件拆分粒度可能会让你觉得「重」但如果你要的是能往生产环境推的骨架它的分层方式值得逐层拆开看。2. 从 lakehouse-common 到 lakehouse-api模块拆分与依赖关系2.1 三个核心组件的职责边界源码里最显眼的三个模块是 lakehouse-common、lakehouse-ui、lakehouse-api。这不是随便切的它对应的是「通用能力下沉、接口层薄、前端独立」的典型云原生分层思路。lakehouse-common 是地基放的是跨模块复用的东西对象存储的抽象客户端、元数据模型的 POJO、通用异常和工具类。你去看它的 pom.xml大概率会看到对 Hadoop 客户端、云厂商 SDK 的依赖声明。这个模块的设计意图是让上层不直接碰具体存储协议换云厂商的时候只改 common 里的适配层。lakehouse-api 是服务入口对外暴露 REST 接口对内编排查询任务。它依赖 common但不依赖 ui。Java 文件在这里最密集Controller、Service、DTO 转换都在这一层。如果你要加一个新的查询接口改这里就够了。lakehouse-ui 是独立的前端工程TypeScript 和 tsx 文件集中在这里。它通过 HTTP 调 api 层构建产物是静态资源可以单独部署到 Nginx 或对象存储的静态托管上。这种前后端分离的物理结构意味着你可以只替换 ui 而不动后端。2.2 依赖关系的验证方法拿到源码后别急着编译先用 Maven 的依赖树命令把模块间关系看清楚# 在根目录执行查看模块聚合关系 mvn -q -DskipTests dependency:tree -DoutputFiledeps.txt # 只看 lakehouse-api 对 common 的依赖路径 mvn -pl lakehouse-api -am dependency:tree | grep lakehouse-common第一行命令会把整个项目的依赖树导出到 deps.txt重点看有没有版本冲突——尤其是 Hadoop、Spark、云厂商 SDK 这三类库它们经常因为传递依赖打架。第二行命令用-pl指定模块、-am同时构建依赖模块能确认 api 层是否真的引用了 common 的当前版本而不是从远程仓库拉了一个旧包。参数说明-q静默模式只输出结果-DskipTests跳过测试编译加速-DoutputFile把树写到文件方便搜索。如果输出里出现omitted for conflict说明有版本被仲裁掉了这时候要去父 pom 的 dependencyManagement 里锁版本。2.3 容器化文件的分布逻辑源码根目录和子模块下出现了多个 Dockerfile这不是冗余。常见做法是每个可独立部署的模块带自己的 Dockerfile比如 api 模块的 Dockerfile 负责打 Java 运行镜像ui 模块的 Dockerfile 做多阶段构建——先用 node 镜像编译 tsx再把 dist 拷进 nginx 镜像。# 典型的 ui 模块多阶段构建写法根据源码结构推断 FROM node:18-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build FROM nginx:alpine COPY --frombuilder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf这段 Dockerfile 的逻辑是第一阶段用 node 镜像装依赖、编译前端第二阶段只把编译产物和 nginx 配置拷进最终镜像。这样出来的镜像不含 node_modules 和源码体积能小一个数量级。参数上注意npm ci比npm install更适合 CI 环境它严格按 lock 文件装不会偷偷升级小版本。nginx.conf 通常要配try_files $uri $uri/ /index.html否则前端路由刷新会 404。3. 本地跑通环境变量、构建顺序与启动参数3.1 .env.development 里该改什么源码里带了 .env.development这是开发环境的配置入口。别直接拿去生产用但本地跑通必须先把它填对。典型内容会包括对象存储的 endpoint、access key、secret key、bucket 名称以及数据库连接和 Spark 相关参数。# .env.development 关键项示例按实际源码字段调整 LAKEHOUSE_STORAGE_TYPEs3 LAKEHOUSE_STORAGE_ENDPOINThttp://127.0.0.1:9000 LAKEHOUSE_STORAGE_ACCESS_KEYminioadmin LAKEHOUSE_STORAGE_SECRET_KEYminioadmin LAKEHOUSE_STORAGE_BUCKETlakehouse-dev LAKEHOUSE_META_DB_URLjdbc:mysql://127.0.0.1:3306/lakehouse?useSSLfalse LAKEHOUSE_SPARK_MASTERlocal[*]逻辑说明本地开发最省事的方案是用 MinIO 模拟 S3 兼容存储endpoint 指向本地 9000 端口access key 和 secret key 用默认的 minioadmin。LAKEHOUSE_SPARK_MASTERlocal[*]让 Spark 用本地所有核心跑不用起集群。元数据库用 MySQL 存表结构和分区信息这是 Lakehouse 的「仓库」那一半。参数怎么改如果你用阿里云 OSSstorage type 改成 ossendpoint 换成对应 region 的地址access key 换成 RAM 用户的。注意 bucket 要提前建好且权限策略允许 list 和 get/put。useSSLfalse只在本地 MySQL 没配证书时用生产必须去掉。3.2 构建顺序与跳过测试这个项目是多模块 Maven 工程构建顺序由 pom 的 modules 声明决定但手动构建时建议从 common 开始# 先装 common 到本地仓库再构建 api mvn -pl lakehouse-common install -DskipTests mvn -pl lakehouse-api -am package -DskipTests # 前端单独构建 cd lakehouse-ui npm install npm run build第一行把 common 装进本地 .m2 仓库这样 api 构建时能直接引用。第二行-am会顺带构建 api 依赖的其他模块。-DskipTests在首次跑通时建议加上因为测试用例可能依赖外部存储或数据库环境没配好会卡住。前端npm run build的产物在 dist 目录可以拷到 nginx 或者用npm run dev起开发服务器调接口。3.3 启动参数与端口约定Java 服务启动时环境变量注入方式取决于你用哪种部署。本地直接跑 jar 的话java -jar lakehouse-api/target/lakehouse-api-*.jar \ --spring.profiles.activedev \ --server.port8080 \ --lakehouse.storage.endpointhttp://127.0.0.1:9000--spring.profiles.activedev让 Spring Boot 加载 application-dev.yml 或对应的 .env.development。--server.port指定端口避免和本地其他服务冲突。后面的 storage endpoint 是覆盖配置的另一种方式优先级高于配置文件。常见坑是端口被占启动日志里看到Port 8080 was already in use就换一个。4. 避坑排查对象存储对接、Scala 编译与前端联调4.1 对象存储连不上报 UnknownHost 或 403现象启动后调查询接口日志里抛UnknownHostException或者403 Forbidden。原因endpoint 写成了带 bucket 的完整路径或者 access key 没有 list bucket 权限。S3 兼容协议里 endpoint 只到域名和端口bucket 是单独的参数。解决检查 .env 里 endpoint 是否只写到http://host:portbucket 字段单独填。用mc或aws s3 ls先验证凭证能不能列桶再启动服务。4.2 Scala 模块编译报 missing dependency现象mvn package到 Scala 模块时提示找不到scala-library或spark-core。原因Scala 版本和 Spark 版本不匹配或者 Maven 的 scala-maven-plugin 没配好。源码里 28 个 Scala 文件大概率依赖特定 Spark 版本。解决在父 pom 里确认scala.binary.version和spark.version对应比如 Spark 3.3 用 Scala 2.12。然后检查 scala-maven-plugin 的scalaVersion配置是否一致。别混用 2.11 和 2.12 的包。4.3 前端 npm install 卡在 node-sass现象npm install长时间不动最后报 node-sass 编译失败。原因SCSS 文件多22 个如果用了 node-sass 而不是 dart-sass在 Node 18 上容易编译不过。解决把 package.json 里的 node-sass 换成 sassdart-sass或者用npm install --legacy-peer-deps绕过 peer 依赖检查。更稳的做法是锁定 Node 版本到 16用 nvm 切过去再装。4.4 API 跨域前端调不通现象前端页面能打开但请求后端接口报 CORS 错误。原因ui 和 api 不同端口浏览器同源策略拦截。解决在 api 层的配置里加全局 CORS 配置允许前端 origin。或者本地开发时用 vite/webpack 的 proxy 把 /api 转发到 8080。生产环境用 nginx 反代同一域名下就不存在跨域。4.5 元数据库表没建启动报 SQL 异常现象服务启动时 Flyway 或 JPA 报Table lakehouse.xxx doesnt exist。原因源码可能带了 schema.sql 或 migration 脚本但没自动执行。解决找到 resources 下的 SQL 文件手动在 MySQL 里执行一遍。或者确认 spring.jpa.hibernate.ddl-auto 是不是 none改成 update 让它自动建表仅限开发环境。5. 进阶用法用对象存储做版本回溯与查询加速5.1 利用对象存储的版本控制做数据回溯Lakehouse 的一个隐藏优势是当底层对象存储开了版本控制你的数据文件天然有了后悔药。S3 和 OSS 都支持 bucket versioning每次覆盖写会保留历史版本。这意味着你可以通过指定 versionId 读回旧数据而不需要额外维护快照表。# 开启 MinIO 桶的版本控制本地验证用 mc version enable local/lakehouse-dev # 列出对象的历史版本 mc ls --versions local/lakehouse-dev/warehouse/orders/第一行命令对桶开启版本控制之后所有 put 操作都会生成新版本。第二行列出某个表目录下所有对象的历史版本输出里带 version-id。在查询层你可以扩展 common 模块的存储客户端让它支持按 versionId 读取这样就能实现「查某个时间点的数据」而不依赖 Hive 的分区快照。参数说明mc version enable是 MinIO 客户端命令换成 AWS CLI 就是aws s3api put-bucket-versioning。注意版本控制开启后存储成本会上升因为旧版本不删就一直占空间生产环境要配生命周期规则定期清理非当前版本。5.2 小文件合并与查询加速大数据场景下流式写入会产生大量小文件查询时元数据操作成为瓶颈。Lakehouse 架构里通常会在 common 层或独立的 compaction 模块做小文件合并。你可以基于源码里的 Scala 模块写一个定时任务用 Spark 读小文件、repartition 后重写。// 小文件合并的 Spark 作业骨架基于源码 Scala 模块扩展 val df spark.read.parquet(s3a://lakehouse-dev/warehouse/orders/) val merged df.repartition(10) // 按数据量调整分区数 merged.write.mode(overwrite).parquet(s3a://lakehouse-dev/warehouse/orders_compacted/)逻辑说明读入原始小文件目录repartition 到合理分区数通常按目标文件大小 128MB 反推再覆盖写到新目录。参数上repartition(10)的 10 要根据总数据量除以 128MB 估算太小还是小文件太大单文件过大会影响并行度。写完确认行数一致后再切换元数据指向新目录。5.3 验证清单与我的习惯每次改完存储层或查询层我会强制走一遍这个清单先用mc ls确认对象存在且大小合理再用 Spark SQL 跑select count(*)和select * limit 10验证可读最后用 API 层接口跑一次端到端查询确认返回结构没变。这套流程帮我挡掉过好几次「文件写进去了但元数据没更新」的翻车。从那以后我每次动存储配置或 compaction 逻辑都强制先跑一遍 count 和 limit 再推环境。希望帮到你。本文还有配套的精品资源点击获取