这篇不是 Doris 表模型大全，而是我结合 BigData-Notes 的学习整理，以及淘宝数仓、Olist 湖仓的本地项目文档，给自己写的一份组件分工备忘。

一开始我很容易把这些组件都理解成“查数据的工具”。后来发现它们的价值其实不在同一个层面：Hive 更像元数据和离线 SQL 入口，Spark 是计算引擎，Parquet 是湖仓存储格式，Doris 更适合服务层和高并发查询。

01Hive：统一元数据，而不只是执行 SQL

Hive 最容易被误解成“慢 SQL 引擎”。但在湖仓项目里，Hive Metastore 的价值比 Hive 执行引擎更稳定。

Hive 负责把 HDFS 上的文件组织成表：

  1. 数据库、表、字段、分区、Location。
  2. ODS、DWD、DWS、Quality、Graph、Streaming 等结果的统一目录。
  3. 让 Spark SQL、Hive SQL 和后续查询工具共享同一份元数据。

Olist 的表设计把 HDFS 输出组织为多个 Hive database：

Database内容
olist_odsODS Parquet 表
olist_dwdDWD fact/dim 表
olist_dwsDWS 维度和月度汇总
olist_quality质量门禁与异常评估结果
olist_graph图节点、边、PageRank、组件和特征
olist_streaming流式聚合、重放 manifest 和一致性指标

这个设计让“湖仓物理数据在 HDFS，元数据在 Hive”这件事变得清楚。

02Spark：离线加工和复杂计算主力

Spark 的优势在于批处理、复杂 ETL、窗口计算、机器学习和图分析。相比 Hive MR，它更适合在项目里承担 DWD/DWS/Quality/Streaming 这些计算任务。

在淘宝数仓中，Spark SQL 主要用于：

  1. ODS Parquet 转换。
  2. DWD 19 列宽表加工。
  3. DWS 用户、商品、漏斗汇总。
  4. ADS 指标计算。

在 Olist 湖仓中，Spark Scala JAR 负责：

  1. ODS/DWD/DWS 分层构建。
  2. Deequ 质量规则执行。
  3. GraphX/图特征输出。
  4. Kafka 事件重放与 Structured Streaming 聚合。
  5. batch-stream consistency 校验。

所以我的理解是：Spark 不应该只被当作“更快的 Hive”，而是数仓链路里真正的计算层。

03Parquet：离线湖仓的默认存储选择

BigData-Notes 里反复提到，Parquet 是面向分析场景的列式存储格式。项目里这个选择很直观：淘宝 ODS 从 TEXTFILE 转成 Parquet Snappy 后，同一批数据的存储占用明显下降。

Parquet 的收益主要来自：

  1. 列式读取，查询只扫描需要的列。
  2. 压缩效率高。
  3. 和 Spark/Hive 生态集成好。
  4. 分区目录天然适合按天、按月管理。

在我的项目里，ODS、DWD、DWS 和很多实验结果都优先落 Parquet，而不是一开始就写进 Doris。原因很简单：离线加工层需要的是便宜、稳定、可重跑的存储，不是高并发低延迟查询。

04Doris：不要同步所有表，只同步服务层需要的表

Doris 更适合作为服务层。它的价值是面向看板、报表和交互查询提供低延迟 OLAP，而不是替代整个 HDFS 湖仓。

Olist 项目里只同步了最有展示和查询价值的表：

Doris 表来源用途
dws_user_monthHive DWS用户月度行为分析
dws_category_monthHive DWS品类趋势和 GMV 排名
dws_region_monthHive DWS区域经营分析
quality_batch_resultQuality 输出质量门禁状态
quality_rule_resultQuality 输出规则级质量明细
graph_metricsGraph 输出图实验指标
seller_graph_featuresGraph 输出卖家 PageRank 和图特征
batch_stream_consistencyStreaming 输出批流一致性结果

随后基于这些服务表创建 ADS views，例如 KPI 卡、月度 GMV 趋势、品类 Top、区域 Top、质量状态、图指标和批流一致性卡片。

这个取舍很重要：Doris 不是数据湖的垃圾桶。只有需要被前端频繁查询、需要低延迟服务、口径已经稳定的结果才值得同步。

05表模型选择：先看查询场景

Doris 常见表模型包括 Duplicate、Aggregate、Unique。我的经验是不要先选模型，而要先问查询场景：

  1. 明细查询和追加日志：Duplicate。
  2. 固定维度的预聚合指标：Aggregate 或提前在 ADS 层算好。
  3. 需要按主键覆盖更新的维表或状态表：Unique。

在 Olist 的服务层设计里，很多结果表倾向 Duplicate 或 Unique，不是为了炫表模型，而是因为它们大多是已加工好的 DWS/ADS 或质量结果，查询重点是过滤、排序、聚合展示。实际的 Doris smoke check 和性能对比仍应在服务真正拉起后补做，不能只凭表定义推断查询效果。

06小结

我现在会这样划分这几个组件：

text
HDFS + Parquet：低成本、可重跑的湖仓存储
Hive Metastore：统一元数据目录
Spark：离线加工、质量检测、流式实验和复杂计算
Doris：面向前端和报表的服务层

这套分工不是唯一答案，但能解释为什么项目不该“所有东西都进 Doris”：明细层、实验中间层、可重跑的批处理结果留在湖仓；稳定、高频、面向展示的结果再同步到 Doris。这样系统边界会清楚很多。