Day 1｜数据系统版图：从 OLTP、OLAP 到实时分析

在学习 Doris 的表模型、分区分桶、导入方式和查询优化之前，先把一个更根本的问题讲清楚：企业为什么需要独立的分析系统，Doris 又位于数据系统版图的什么位置？

本文聚焦长期稳定的基础原理。文中涉及的性能目标均应在真实数据、真实 SQL、真实并发和目标版本上通过 POC 验证，不能把单一案例数字直接当作生产承诺。

本日学习目标

完成这一天的学习后，你应当能够：

准确区分 OLTP、OLAP、HTAP、数据湖与实时分析系统的职责；
解释 MySQL 可以执行聚合 SQL，同时说明它单独承载大规模分析时的主要风险；
理解分析技术从离线批处理、交互式查询到实时 OLAP 的演进逻辑；
从数据量、写入方式、查询复杂度、新鲜度、并发和一致性要求判断是否需要 Doris；
为一个真实业务填写《分析型数据库需求画像表》，形成可验证的 POC 输入。

一、从一个经营问题开始：数据系统为什么要分工

假设一家零售企业的负责人在上午九点问了五个问题：

昨天全国销售额是多少，和上周同日相比增长还是下降？
今天开店后半小时，哪些区域的支付转化率突然下跌？
某个爆款商品还有多少可售库存，是否存在超卖风险？
新会员在注册后的七天内，复购率和客单价分别是多少？
刚刚发布的新版本，错误日志和接口 P99 延迟是否出现异常？

这些问题表面上都在“查数据”，背后却对应完全不同的工作负载。

库存扣减、订单创建和支付记账要求每一次写入都正确，通常只访问一条或少量记录，并且可能有大量用户同时操作。它们属于交易处理问题。全国销售汇总、渠道转化漏斗和用户留存则要扫描大量历史记录，进行分组、聚合、关联、排序和窗口计算，属于分析问题。日志检索还可能涉及半结构化字段、全文匹配与时间范围过滤。管理驾驶舱则要求同一批指标被许多用户反复访问，并且希望结果在秒级甚至更低延迟内返回。

如果把这些负载全部压在一个业务数据库上，风险会迅速放大。报表 SQL 可能持续占用 CPU、内存和磁盘 I/O，挤占交易线程，导致下单、支付或库存服务的尾延迟升高。反过来，如果所有分析都依赖凌晨批处理，业务看到的永远是昨天的数据，无法支撑实时经营。

因此，数据架构的第一原则是先识别不同负载，再让系统承担它擅长的工作。试图用一个数据库包揽所有问题，往往会牺牲稳定性和成本效率。

可以先记住一句话：

OLTP 负责把业务做对，OLAP 负责把数据看懂。

两者承担不同职责，并通过数据链路协作。大多数成熟企业会让交易数据库维护业务事实，再通过 CDC、流式同步或批量任务，把变化送入分析系统，最终供 BI、报表、数据应用、API 和 AI Agent 使用。

二、OLTP：业务系统首先要保证“每一笔都正确”

2.1 OLTP 解决什么问题

OLTP 是 Online Transaction Processing，即联机事务处理。订单、支付、账户、库存、CRM、ERP 等系统都以 OLTP 负载为主。

这类系统的典型操作很短：

-- 查询一个订单
SELECT * FROM orders WHERE order_id = 10001;

-- 扣减某个 SKU 的库存
UPDATE inventory
SET available_qty = available_qty - 1
WHERE sku_id = 9001 AND available_qty > 0;

一次请求往往只影响一行或少量行，但请求数量很大，而且对正确性高度敏感。支付不能重复记账，库存不能被扣成负数，订单状态不能出现相互矛盾的结果。于是，OLTP 系统通常把以下目标放在优先位置：

事务正确性：通过 ACID、隔离级别、锁或 MVCC 等机制保证业务约束；
低延迟：单次读写通常希望在毫秒级完成；
高并发写入：大量用户可以同时下单、支付、修改状态；
精确定位：大量查询通过主键、唯一键或高选择性索引快速找到少量记录；
可恢复性：通过日志、复制、备份和故障切换降低数据丢失风险。

2.2 为什么 OLTP 常使用行式组织和 B+Tree 索引

一笔订单通常要同时读取订单号、用户、金额、状态、地址等多个字段。行式存储把一行的多个列放在相邻位置，读取完整记录时具有良好的局部性。B+Tree 等索引适合按主键或范围快速定位记录，更新单行时也无需扫描整张表。

这套设计非常适合“找到一条、修改一条、提交事务”。面对“读取十亿行中的三列，再按十个维度聚合”这类任务时，它的成本会快速上升，因为两类负载的成本结构完全不同。

2.3 MySQL 能执行聚合，为什么还需要分析数据库

MySQL 当然可以执行 GROUP BY、JOIN、窗口函数和子查询。选型时还需要继续追问：在目标数据规模、查询复杂度和并发条件下，它是否仍然经济、稳定、可预测。

分析 SQL 对 OLTP 系统通常带来五类压力。

第一，扫描放大。 行存中，即使查询只需要 region、order_time 和 amount 三列，也可能读取包含几十个字段的完整记录。宽表越宽，无效 I/O 越明显。

第二，索引不可能覆盖所有组合。 运营人员可能按区域、渠道、商品、会员等级、活动、时间段任意组合筛选。为每种组合建立复合索引既不现实，也会增加写放大和维护成本。

第三，聚合与 Join 消耗大量资源。 大范围排序、哈希聚合、复杂 Join 会占用 CPU 和内存，还可能产生临时文件，污染 Buffer Pool，影响交易请求。

第四，扩展方式不同。 OLTP 常围绕主从复制、分库分表和垂直拆分扩展；分析系统更希望把一个查询拆到多台机器并行执行，再合并结果。

第五，尾延迟会互相干扰。 即使平均响应时间尚可，一条突然扫描全表的报表 SQL 也可能让交易接口的 P99 抖动。对核心业务来说，这种不可预测性往往比“报表慢”更危险。

培训中经常用“数据达到百万行以后聚合会变慢”帮助初学者建立直觉，但工程上不存在统一的魔法阈值。十万行的错误 SQL 也可能很慢，数亿行在良好索引和低并发下也可能可接受。判断依据应当是数据规模、查询形态、并发、硬件、缓存命中、更新压力和 SLA 的组合。

因此，独立 OLAP 的价值首先是负载隔离，其次才是单条 SQL 的极限速度。让交易库专注交易，让分析引擎专注扫描、聚合和服务，可以同时保护业务正确性与决策效率。

三、OLAP：围绕“读很多、算复杂、看趋势”设计

3.1 OLAP 的核心目标

OLAP 是 Online Analytical Processing，即联机分析处理。它关注从大量事实中发现规律、解释变化并辅助决策，单笔交易是否成功通常由 OLTP 系统负责。

典型问题包括：

SELECT
    region,
    channel,
    SUM(pay_amount) AS gmv,
    COUNT(DISTINCT user_id) AS buyers
FROM fact_orders
WHERE order_date BETWEEN '2026-08-01' AND '2026-08-15'
GROUP BY region, channel
ORDER BY gmv DESC;

这条 SQL 可能扫描数亿乃至更多记录，却只读取少数列；它还要执行过滤、去重、分组、聚合和排序。另一些查询会关联事实表与多个维度表，计算漏斗、留存、同比环比、排名和滑动窗口。

因此，OLAP 系统通常围绕以下目标设计：

在海量数据上进行大范围扫描；
高效执行聚合、Join、排序、窗口和集合运算；
支持不固定的即席查询，而不依赖为每个问题预先建立索引；
通过横向扩展提升吞吐和计算能力；
在持续写入的同时，为查询提供稳定、可理解的数据快照；
在性能、数据新鲜度、并发和成本之间取得平衡。

3.2 列式存储为什么更适合分析

假设订单明细表有 100 列，经营报表只需要时间、区域、渠道和金额 4 列。行式存储倾向于把完整行读入内存，列式存储则可以只读取参与查询的列。对宽表和大扫描而言，这会显著减少磁盘读取、网络传输和解压工作。

列式组织还有两个额外优势。

一是同一列的数据类型相同、分布相近，更容易使用字典编码、游程编码、位重排和通用压缩算法获得较高压缩率。压缩后的数据更小，意味着更少的 I/O；现代执行引擎还可以直接在编码或压缩后的数据上做部分过滤。

二是连续的同类型值适合批量计算。过滤一批整数、累加一批金额或比较一批日期时，执行引擎可以按 Block 处理，减少逐行函数调用和对象开销，更容易利用 CPU Cache 和 SIMD 指令。

列存不能保证所有查询都快。如果每次都要随机读取一整行、频繁更新少量字段，或者强依赖复杂事务，行存仍然更合适。好的数据库设计会让数据布局贴合访问模式，也会承认不同技术各有边界。

3.3 OLAP 中常见的计算算子

理解 OLAP，可以从查询算子看它的资源需求：

Scan：从分区、文件或 Tablet 中读取需要的列；
Filter：尽早淘汰不满足条件的数据；
Aggregate：执行 SUM、COUNT、MAX、MIN、去重等计算；
Join：关联事实与维度、订单与用户、日志与服务信息；
Sort / TopN：排序并返回前若干结果；
Window：计算排名、累计值、移动平均和同比环比；
Exchange：在分布式节点之间重新分发数据；
Materialization：通过预聚合或物化视图复用计算结果。

分析性能通常由少读数据、并行计算、减少网络交换、控制内存，以及优化器选择合理计划共同决定。CPU 性能只是其中一项。

四、HTAP、数据湖与实时分析：几个容易混淆的概念

4.1 HTAP 的关键在于负载协同与隔离

HTAP 是 Hybrid Transactional/Analytical Processing，目标是让事务与分析更紧密地协同，缩短数据从产生到被分析的链路。实现方式可能是同一引擎同时承担两类负载，也可能是共享日志、共享存储或通过副本进行计算隔离。

HTAP 的核心难题集中在资源与一致性的权衡。交易希望稳定的毫秒级尾延迟，分析可能瞬间消耗大量 CPU 和内存；事务写入强调强一致，分析则更关注快照、吞吐和可接受的数据延迟。只看功能列表很容易低估这些冲突。缺少良好隔离机制时，两类负载会互相影响。

Doris 可以支持实时更新、高并发点查和复杂分析，覆盖部分面向数据服务的混合场景，但它的核心定位仍然是分析数据库。核心账务、支付记账、订单事务等工作通常仍应由成熟 OLTP 数据库承担。

4.2 数据湖擅长低成本保存与开放格式，在线分析仍需计算服务

数据湖通常把 Parquet、ORC 等文件存储在 HDFS 或对象存储中，强调开放格式、低成本和多引擎共享。它很适合保存海量历史数据、训练数据和原始明细，但文件存储本身不会自动提供高并发、低延迟、复杂 SQL 优化和在线服务能力。

因此，现代架构中常见两种路径：

将高价值、强服务需求的数据导入 Doris 原生表，获得更稳定的查询性能；
通过 Doris 的 Catalog 能力直接查询湖上数据，在减少搬运的同时利用统一 SQL、缓存和优化能力。

湖与仓通常围绕数据价值、访问频率、成本和 SLA 分层协作。

4.3 “实时”至少包含三层含义

很多项目只关注 Kafka 消息是否被消费，却忽略了用户真正感受到的端到端时效。一个实时分析链路至少要回答三件事：

采集实时性：业务变化多快进入同步链路；
可见实时性：数据写入后多快对查询可见；
查询实时性：数据可见以后，用户多快拿到结果。

如果 CDC 延迟 1 秒，但报表查询需要 5 分钟，业务体验仍停留在分钟级；如果查询只需 200 毫秒，但数据每天凌晨才导入，整条链路仍属于离线数仓。端到端新鲜度应从业务事件发生时刻，一直计算到用户看到正确结果的时刻。

五、分析技术的三代演进：目标持续向更低延迟、更强并发推进

5.1 第一代：Hadoop 与 Hive，让海量数据“存得下、算得动”

早期企业面对的核心矛盾是单机数据库无法经济地保存和处理持续增长的数据。HDFS 提供分布式存储，MapReduce 和 Hive 让开发者可以在廉价机器集群上执行大规模批处理。

这一代技术最大的贡献是把海量离线计算从昂贵专用设备带到通用集群。它非常适合日终汇总、历史归档、复杂 ETL 和对时效要求不高的分析。

代价同样明显：任务通常以分钟或小时计，计算过程包含较多落盘、调度和阶段等待；数据链路多，问题定位复杂；报表常以 T+1 形式交付。对于月报和监管报送，这可能完全可以接受；对于实时运营和在线风控，就显得太慢。

5.2 第二代：Spark、Presto 与 Trino，让分析开始“交互化”

Spark 通过内存计算和更丰富的执行模型显著提升批处理与迭代计算效率。Presto、Trino 等 MPP 查询引擎让用户可以直接对多种数据源执行交互式 SQL，不必每次都构建完整离线任务。

这一阶段把等待时间从小时级压缩到分钟级乃至秒级，推动了自助取数和数据湖查询。但在高并发、复杂 Join、资源隔离、缓存命中和稳定尾延迟方面，通用查询引擎仍可能面临挑战。尤其当文件数量、分区元数据和数据源种类持续增加时，性能会受到远端 I/O、元数据服务和小文件问题影响。

它们今天依然有重要价值：Spark 擅长通用数据处理，Trino 擅长跨源联邦查询。实时 OLAP 面向“持续写入、持续查询、持续服务”的负载，提供了更专门的底座。

5.3 第三代：实时 OLAP，让数据持续可见、查询持续在线

实时 OLAP 把数据写入、列式存储、分布式执行、查询优化、索引与在线服务结合起来。系统要在单次大查询上保持速度，也要在数据持续更新、多个用户并发访问的情况下维持稳定。

这一代系统关注的指标更完整：

数据从产生到可查需要多久；
查询的 P50、P95、P99 延迟分别是多少；
并发升高后是否出现排队或抖动；
导入、Compaction 与查询是否互相争抢资源；
同等 SLA 下需要多少机器和存储成本；
集群能否长期稳定运行，单次 Benchmark 的高分无法替代长期验证。

Doris 正是实时 OLAP 路线的代表之一。它通过 MPP、列式存储、向量化执行、数据跳读、预计算和实时导入等能力，服务实时看板、即席分析、用户画像、日志分析和数据湖查询。具体能力将在后续课程逐层展开。

六、实时 OLAP 为什么快：多层能力共同作用

6.1 MPP：把一个大问题拆给多台机器

MPP 是 Massively Parallel Processing。一个查询会被拆成多个可并行执行的部分，分发到不同节点扫描和计算，再通过网络交换数据并合并结果。

横向扩展的价值在于：当数据量和查询量增长时，可以增加节点，让更多 CPU、内存、磁盘和网络共同承担负载。并行同样有成本。数据倾斜会让某个节点成为瓶颈，Shuffle 会消耗网络，过高并发也可能让线程、内存和调度器承压。因此，后续还需要理解分区、分桶、统计信息、Join 策略和资源治理。

6.2 列存与数据跳读：最快的数据，是根本不读取的数据

列式存储减少无关列的 I/O，分区裁剪、ZoneMap、前缀索引、Bloom Filter 和倒排索引继续减少无关数据块。分析性能的第一原则往往是尽可能在扫描前排除数据，逐行计算速度只影响剩余数据的处理成本。

这也解释了为什么建表设计如此重要：如果时间条件能命中分区，过滤字段能利用排序与索引，查询读取的数据量可能下降几个数量级；如果分区、排序和查询模式完全错位，再强的 CPU 也会浪费在无效扫描上。

6.3 向量化执行：按 Block 批量处理，减少逐行调用

传统逐行执行会频繁调用算子函数，产生分支、对象和虚函数开销。向量化引擎把一批同类型数据放在连续内存中，一次完成过滤、表达式计算或聚合，更容易命中 CPU Cache，并使用 SIMD 指令并行处理多个值。

列存解决“读什么”，向量化解决“怎么计算”，二者结合才能发挥现代 CPU 的能力。

6.4 优化器、预计算与缓存：避免重复做昂贵工作

复杂 SQL 可能有多种 Join 顺序、分发方式和聚合路径。代价优化器需要依赖统计信息选择更合理的计划。对稳定报表，还可以通过同步 Rollup、异步物化视图和缓存复用结果。高并发点查则可能使用主键索引、Prepared Statement 和行存能力缩短路径。

“Doris 快”来自数据布局、索引、执行引擎、优化器、预计算、缓存和分布式调度的共同作用。任何一个环节设计错误，都可能让优势无法兑现。

七、四类典型业务场景：先看需求画像，再谈产品能力

7.1 实时经营看板

业务特征：SQL 相对稳定，指标口径明确，访问人数多，希望数据持续更新；大促、活动或管理驾驶舱可能出现明显并发峰值。

核心要求：端到端新鲜度低，查询 P95/P99 稳定，重复查询能够复用预计算或缓存，导入不能把在线查询拖慢。

Doris 的适配点：实时导入、分区裁剪、预聚合、物化视图、高并发服务和资源隔离可以形成完整链路。

常见误区：只压测单用户平均延迟，不测试并发、数据持续写入和缓存失效后的尾延迟。

7.2 自助分析与即席查询

业务特征：分析师通过 BI 工具自由选择维度和指标，SQL 不固定，难以为每个问题预先构建 Cube。

核心要求：对大范围扫描、复杂 Join 和多维聚合保持可接受响应；优化器能够根据统计信息选择计划；不同团队的查询相互隔离。

Doris 的适配点：MPP 并行、列式扫描、Runtime Filter、智能索引和 CBO 能够支持更灵活的分析。

常见误区：把“即席”理解成任何 SQL 都必须毫秒返回。实际需要先按查询复杂度和价值设定分级 SLA。

7.3 实时风控与用户画像

业务特征：数据持续更新，需要按用户、设备、账户、标签或行为快速过滤和聚合；部分请求是主键点查，部分请求是复杂人群圈选。

核心要求：更新可见性、去重与乱序处理、精确或近似集合计算、高并发与一致快照。

Doris 的适配点：Unique Key 更新模型、Sequence Column、Bitmap/HLL、复杂类型和点查优化可以覆盖多种服务形态。

边界：真正的核心交易风控决策仍要评估事务、状态机和极低尾延迟要求，不能仅凭“支持点查”就把分析系统当作交易数据库。

7.4 日志与可观测性分析

业务特征：写入量大，字段可能动态变化，既要按关键词检索，也要按服务、时间、版本和错误码聚合分析。

核心要求：高吞吐写入、冷热分层、半结构化字段处理、全文检索与聚合协同，以及合理的数据保留成本。

Doris 的适配点：Variant、倒排索引、列式聚合和对象存储能力使“搜索后分析”和“分析后下钻”可以在同一 SQL 体系中完成。

边界：如果业务高度依赖复杂相关性排序、搜索生态插件或专用检索能力，仍应与搜索引擎进行针对性 POC。单看存储单价容易得出偏差结论。

八、Doris 适用性判断：适合与不适合的边界

8.1 更适合 Doris 的信号

当需求同时出现以下多个特征时，值得认真评估 Doris：

数据规模持续增长，单机数据库分析成本明显上升；
查询需要扫描大量记录，只读取部分列并进行复杂聚合；
需要秒级或更低的数据可见性，而传统 T+1 无法满足业务；
有实时看板、自助分析、用户画像、日志检索或湖仓查询需求；
查询并发较高，希望通过横向扩展和资源治理保持稳定；
希望减少 MySQL、Hive、Kylin、ES、预计算服务之间的重复链路；
团队希望继续使用 SQL、MySQL 协议和主流 BI 工具；
可以接受将交易库与分析库分工，通过 CDC 同步数据。

8.2 Doris 优先级较低的场景

以下场景中，Doris 通常不适合作为首要系统：

核心支付、总账、订单创建等强事务 OLTP；
以单行随机写为主、几乎没有分析需求的业务；
依赖复杂跨行事务、外键级联和高度规范化更新的系统；
数据量很小、查询简单，现有 MySQL 已稳定满足 SLA；
只需要对象存储归档，不需要在线 SQL 服务；
只需要专业全文检索与复杂相关性排名，且没有聚合分析诉求；
没有明确指标和查询集，仅因为“听说很快”就进行迁移。

正确的架构通常是：MySQL 或其他 OLTP 系统负责交易，Doris 负责分析与数据服务。 只有在充分验证更新语义、事务边界、延迟和稳定性以后，才考虑让 Doris 承担更多 Serving 负载。

8.3 用七个维度描述需求

在讨论选型之前，先把每条需求写成可测量的画像：

维度	应回答的问题	示例
数据规模	当前数据量、日增量、保留周期是多少？	20 TB，日增 500 GB，保留 3 年
写入形态	批量、流式、CDC、更新还是追加？	MySQL CDC + Kafka 日志
数据新鲜度	业务事件发生后多久必须可查？	5 秒内
查询延迟	P50、P95、P99 目标分别是多少？	P95 < 2 秒，P99 < 5 秒
并发与 QPS	峰值同时多少查询，是否有突发流量？	200 并发，峰值 500 QPS
SQL 复杂度	点查、聚合、Join、窗口还是全文检索？	5 表 Join + 分组聚合
一致性与事务	是否要求多行事务、强一致和立即读己之写？	分析快照可接受秒级延迟

没有这些数据，所谓“选型讨论”往往会退化成产品功能对比；有了这些数据，才可以设计数据模型、集群规模、压测方法和验收门槛。

九、四个常见选型误区：数据库没有“万能型冠军”

9.1 误区一：只要查询慢，就应该立即更换数据库

慢查询可能来自错误 SQL、缺失过滤条件、统计信息失真、网络瓶颈或数据模型不合理。更换引擎之前，应先确认瓶颈属于工作负载不匹配，还是现有系统没有被正确使用。若一张几十万行的小表因为写了笛卡尔积而慢，迁移到任何系统都只是把问题推迟。

9.2 误区二：Benchmark 第一名就一定最适合生产

公开 Benchmark 可以帮助理解引擎上限，业务 POC 仍然必不可少。生产环境的数据分布、更新频率、SQL 复杂度、并发模型、冷热状态和故障条件往往与测试集不同。尤其要警惕只展示单并发、全热缓存和最优查询的结果，同时忽略持续导入、资源竞争与 P99。

9.3 误区三：实时就是每条数据都立刻触发一次查询

实时系统仍然需要批量化。流式导入通常会在吞吐、可见延迟和小文件数量之间做权衡；查询引擎也会按 Block 批量计算。工程目标是满足业务可感知的端到端 SLA，理论上的零等待缺乏实际意义。过度缩小批次可能降低吞吐、增加版本和 Compaction 压力，最终让系统更不稳定。

9.4 误区四：采用 Doris 后，MySQL、数据湖和搜索系统都可以删除

统一分析平台的价值是减少重复链路和数据孤岛，同时保留必要的专用系统。交易数据库仍负责核心事务，数据湖仍适合低成本保存开放格式数据，专业搜索引擎在复杂相关性和搜索生态上也可能更合适。架构优化追求边界更清晰、链路更短、总成本更低，组件数量应服从业务目标。

十、从业务 SLA 反推架构：贯穿 30 天的电商案例

后续课程将持续使用一个电商实时经营平台作为案例。它的交易链路与分析链路如下：

MySQL 保存订单、支付和库存等交易事实；
Kafka 接收点击、曝光、搜索和应用日志；
CDC 与流式链路持续捕获变化；
Doris 保存可分析明细、更新后的业务状态与预聚合结果；
BI 看板展示 GMV、转化率、库存和履约指标；
分析师进行渠道、商品和用户的即席探索；
API 或 Data Agent 对外提供受控的数据服务。

这套架构应根据数据价值和 SLA 分层，无需把所有数据都搬进 Doris。交易库维护业务事实，Doris 承担大规模分析；高频热数据可以进入原生表，低频历史数据可以保留在数据湖，并按需要联邦查询。

POC 也不能只执行几条漂亮 SQL。至少应验证：

POC 前还要固定测试条件：明确 Doris 版本、机器规格、数据副本数、压缩方式、数据是否已进入缓存、并发模型、查询超时和资源组配置；保存完整 DDL、导入脚本、SQL、结果集与监控截图。只有可复现的测试，才能用于容量规划和采购决策。若测试过程中不断临时改 SQL、换数据或只挑最快结果，最终只能得到演示结果，无法形成工程结论。

结果是否正确，口径是否与原系统一致；
端到端数据新鲜度是否满足要求；
冷查询、热查询的 P50/P95/P99；
峰值并发下是否排队、超时或出现明显抖动；
持续导入时查询是否退化；
机器、磁盘、对象存储和运维成本；
节点故障、扩缩容和长时间运行下的稳定性。

十一、动手练习：完成《分析型数据库需求画像表》

从你所在企业或熟悉的业务中选取 5 条真实分析需求，填写下表。不要写“越快越好”，而要写可验证的数字。

需求	数据来源	当前规模/日增量	写入方式	新鲜度	延迟目标	峰值并发	SQL 特征	初步判断
示例：全国实时销售看板	MySQL 订单库	8 TB / 200 GB	CDC	5 秒	P95 < 2 秒	150	分组聚合、同比	适合实时 OLAP
需求 1
需求 2
需求 3
需求 4
需求 5

填写完成后，再回答三个问题：

哪些需求必须与交易系统隔离？
哪些需求可以接受分钟级，哪些必须秒级？
哪些需求需要 Doris 原生表，哪些可以继续留在数据湖或 MySQL？

这份表将成为后续建模、导入、容量规划和 POC 的共同输入。

十二、Knowledge Check

1. OLTP 与 OLAP 的核心差异是什么？

答案要点：OLTP 以高并发小事务、低延迟写入和强一致为核心；OLAP 以大规模扫描、复杂聚合、灵活分析和横向并行为核心。两者应根据工作负载分工协作，不能简单互相替代。

2. 为什么列存适合宽表聚合？

答案要点：查询只读取需要的列，减少 I/O；同列数据类型和分布相近，更易压缩；连续同类型数据适合向量化与 SIMD 批量计算。

3. 实时 OLAP 的“实时”体现在哪些环节？

答案要点：采集延迟、写入后可见延迟和查询返回延迟三者共同决定端到端新鲜度。只优化其中一个环节不能保证业务实时。

4. 列出两个 Doris 优先级较低的场景。

答案示例：核心支付记账和订单事务；数据量很小且 MySQL 已满足 SLA；只需专业相关性搜索而无分析需求；以单行随机写为主且几乎没有聚合查询。

十三、本日总结：先建立坐标系，再深入 Doris

今天最重要的收获，是建立一套判断框架。产品名称只起到辅助作用：

先区分交易负载与分析负载；
再判断数据规模、新鲜度、查询延迟、并发和一致性；
理解离线数仓、交互式引擎、实时 OLAP 和数据湖各自解决的问题；
用可测量的业务 SLA 反推架构；
把 Doris 放在分析与数据服务的位置上，明确它与交易数据库、数据湖和搜索系统的边界。

可以用一句话结束 Day 1：

好的数据架构会把每类工作负载送入合适的执行路径，并通过清晰的数据链路协同。

下一篇将正式进入 Day 2｜Apache Doris 全景：定位、能力、场景与边界。届时会回答：Doris 的“快、简单、统一”分别来自哪里，它能覆盖哪些场景，又有哪些明确边界。

资料基线

Apache Doris 4.x Overview：用于产品定位、核心架构与典型场景的稳定描述；
Apache Doris POC 指南：用于需求画像、测试指标与验收方法；
本系列培训材料第 2–7 页及相关架构、场景章节：用于课程组织与视觉表达。

后续涉及参数、语法、默认值与版本行为时，将继续以对应版本的官方文档和可复现实验为准。