/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
结论先行 -> 能看懂的就不用看后面的展开解释咯
Hive 承担批处理 ETL 的数据生产责任（清洗→规范化→汇总），把最终需要被高频、低延迟、高并发查询的那部分结果（DWS/ADS/热明细）以批量的方式 Load 进 Doris；Doris 用合适的表模型和分区/分桶设计把这些结果变成\”可交互查询\”，从而把 BI/运营/接口的体验从\”分钟级\”拉到\”秒级\”。
有个朋友问我，都搞了 Hive 了，还搞 Doris 干吗？
这是个很好的架构问题，其实 Doris 和 Hive 本质上并不是一定要“二选一”，它们解决的是不同层的问题，很多时候是互补。
接下来我们逐条拆开说说
概括的说
Hive 管\”数据怎么存、怎么算\”（批处理存储 + ETL计算底座），Doris 管\”数据怎么查得快\”（交互式分析加速引擎）。两者不在同一个平面上。
成本模型完全不同 —— 这是最根本的原因
| Hive | Doris | |
| 存储 | 数据放 HDFS / S3 / OSS 上，用 Parquet/ORC，每GB成本极低 | 数据存在 Doris 自己的 BE 本地盘上，带索引、物化视图、副本，存储贵很多 |
| 计算 | 跑在 YARN/K8s 上弹性伸缩，半夜跑完释放资源 | MPP 常驻进程，要预留内存/CPU，idle 也在烧钱 |
| 适合的数据量 | PB 级历史数据、原始日志、每天整分区覆写 | 通常是 热数据层（最近几天/几周/ |
