第1章 选型起点
第 1 章 · 选型起点：Doris 是什么
章节摘要：本章回答一个前置问题——在动手之前，凭什么判断 Doris 适合你的业务。我们先沿时间线看清它从百度内部引擎到 Apache 顶级项目的演化动机，再用一张能力坐标图定位它的强项边界，最后把它放回 ClickHouse、Trino、Hive、StarRocks 等同场对手中间做同维度对比。读完这章，你应该能在选型评审会上拿出有依据的结论，而不是一句"Doris 很快"。
学习目标
完成本章后，你应当能够：
- 说清 Doris 的三次关键转向（内部孵化、开源捐献、存算分离探索）各自解决了什么矛盾；
- 用"MPP + 列存 + 向量化 + 主键更新"四个词组向非存储背景的同事概括 Doris；
- 给出自己的业务画出能力象限图，标出强一致性更新、高并发点查、超大规模离线扫描三类需求的落点；
- 对照六款主流引擎的差异表，写出至少三条适用于本团队的选型理由；
- 判断 T+1 报表、准实时看板、交互式即席分析、日志检索四类负载分别落在哪些引擎的舒适区。
核心概念速览
一个值得先立住的判断：Doris 不是"更快的 MySQL"，也不是"简化版的 Hive"，而是一台为高频写入、低延迟聚合、中等规模数据量设计的分析机器。传统离线数仓赢在规模与生态，输在延迟；纯列式 OLAP 赢在单表扫描速度，输在 Join 复杂度与更新能力；Doris 把筹码押在"统一的实时分析底座"上，用一套元模型同时支撑多种表形态与导入通道。
金句：选型不是挑最强的引擎，而是挑代价结构与你业务曲线最贴合的那一台。
给这张演化链补一个实用的读法：每一次架构转向都不是凭空的升级，而是上一代形态把某个矛盾推到不可忍受后的产物。T+1 报表把"决策等不起"推到极限，才有批流双轨；双轨的组件税太重，才有单件列式引擎；单件引擎在更新与关联上欠的账，又由统一底座来还。评审会上有人问"为什么要引入新组件"时，沿着这条因果链讲，比罗列功能清单更有说服力——架构史本身就是最好的选型论据。
子章节导航
- 1.1 核心概念与发展历程：Palo 到 Doris 的演化叙事，MPP、HTAP、湖仓三个关键词的历史来路。
- 1.2 技术定位与核心特性：把"实时""统一""易用"翻译成可验证的技术特征，并划出不适用的场景。
- 1.3 六款 OLAP 引擎同台对比：同一张电商订单分析需求下，横向对照 Doris、StarRocks、ClickHouse、Trino、Doris 与 Hive 的表现侧重与工程代价。
子章节之间的逻辑关系
历史交代"为什么长成这样"，定位划定"适合做什么"，对比回答"和别人比凭什么"。三者共同构成选型论证链条：
演化动机 ──> 能力边界 ──> 同台对比 ──> 选型结论 │ │ │ 讲因果 划边界 看代价
缺了第一环，定位会变成营销话术；缺了第三环，定位说服不了评审会上的怀疑者。
前置知识与后续延伸
前置要求不高：懂基本的关系库概念（主键、索引、聚合）、听说过数据仓库分层即可。若你有 Hive 或 Spark 使用经验，1.2 中关于"为什么不能用离线思路建 Doris 表"的部分会更有共鸣。读完本章可直接进入第 2 章——理解 FE 与 BE 的分工后，后续所有"为什么这么设计"的问题都有了解释入口；急于动手的读者也可以先跳读 3.4 的建模复盘找手感，再回头补架构。
给自己留一道自测：合上书，用三分钟向一位虚构的评审会听众回答"我们为什么需要 Doris"。若你能不重复地讲出演化因果、能力边界与至少两条对比结论，本章的使命就完成了；若只能说出"它很快"，建议重读 1.2 的定位边界一节——"快"从来不是选型理由，"快的代价结构匹配业务曲线"才是。