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

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

本文聚焦长期稳定的基础原理。文中涉及的性能目标均应在真实数据、真实 SQL、真实并发和目标版本上通过 POC 验证，不能把单一案例数字直接当作生产承诺。涉及版本和部署形态的能力会单独说明；业务情境、数据规模和延迟数字均为教学设定或需求示例。

本日学习目标

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

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

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

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

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

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

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

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

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

可以先记住一句话：

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

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

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

2.1 OLTP 解决什么问题

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

这类系统的典型操作很短。下面以 MySQL InnoDB 业务表为例，展示按订单号查询和带条件扣减库存的 SQL 形态；实际业务还需要处理事务边界、受影响行数和请求重试。[3]

-- 查询一个订单
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 系统通常把以下目标放在优先位置：

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

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

一笔订单通常要同时读取订单号、用户、金额、状态、地址等多个字段。以 MySQL InnoDB 为例，聚簇索引的叶子记录保存行数据，按主键读取完整记录时具有良好的局部性。B+Tree 等索引适合按键值或范围定位记录，命中合适索引的单行更新也无需扫描整张表。[3][4]

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

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

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

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

第一，扫描放大。 当执行计划需要扫描聚簇索引或大量回表时，即使查询只需要 region、order_time 和 amount 三列，也可能读取包含其他字段的数据页。宽表越宽，无关数据的读取成本越值得关注。覆盖索引能够避免部分回表，因此要结合实际执行计划判断，不能简单认定行存查询始终读取全部列。[4][21]

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

第三，聚合与 Join 消耗大量资源。 大范围排序、聚合和复杂 Join 会占用 CPU 和内存，部分查询还需要内部临时表；临时数据超过相应内存限制时可能落盘。大扫描也可能挤占 Buffer Pool 的有效缓存空间，影响交易请求。实际影响要结合执行计划、缓存和资源使用情况判断。[5]

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

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

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

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

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

3.1 OLAP 的核心目标

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

典型问题包括下面这种按区域、渠道统计销售额和购买人数的查询。为便于讨论，假设 fact_orders 已按约定的支付口径整理为订单粒度，order_date 为 DATE，金额使用精确数值类型；本节只展示查询形态，不给出未经运行的结果或耗时。

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 就需要读取相应数据，执行过滤、去重、分组、聚合和排序。实际扫描量取决于数据规模、分区裁剪和执行计划，不能从 SQL 文本直接判断。SUM(pay_amount) 汇总非 NULL 金额，COUNT(DISTINCT user_id) 统计分组内非 NULL 的不同用户；同一用户在不同分组中可能分别计数，各组购买人数不能直接相加当作全站去重人数。另一些查询还会关联事实表与多个维度表，计算漏斗、留存、同比环比、排名和滑动窗口。[6]

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

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

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

假设订单明细表有 100 列，经营报表只需要时间、区域、渠道和金额 4 列。在需要扫描大量记录的前提下，列式存储可以按列读取，减少无关字段的读取和解压工作。行式存储的实际读取量则取决于是否使用覆盖索引、是否回表以及数据页布局。这里的 100 列和 4 列只是教学设定，不能据此直接推导实际 I/O 或性能会改善多少倍。[2][4][21]

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

一是同一列通常具有相同的逻辑类型，值的分布也可能更适合字典编码、游程编码和位打包等编码方式，再配合通用压缩减少存储量。编码和压缩的选择取决于类型与数据分布，压缩后的数据更小通常意味着更少的 I/O。在部分低基数字符串计算中，StarRocks 还可以利用字典编码后的值执行操作，减少解码和字符串处理开销；这不等于所有算子都能直接处理任意压缩数据。[2]

二是按列组织的一批数据适合批量计算。过滤一批整数、累加一批金额或比较一批日期时，执行引擎可以减少逐行函数调用和对象开销，更容易利用 CPU Cache 和 SIMD 指令。在 StarRocks 中，承载一批列数据的主要结构叫作 Chunk；这一名称会在后续执行引擎课程中继续使用。[2][7]

列存不能保证所有查询都快。如果每次都要随机读取一整行、频繁修改少量记录，行式组织可能更贴合访问方式。事务能力还取决于数据库的并发控制和读写机制，不能仅凭行存或列存判断。好的数据库设计会让数据布局贴合访问模式，也会承认不同技术各有边界。

3.3 OLAP 中常见的计算算子

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

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

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

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

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

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

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

StarRocks 支持实时更新、复杂分析，并可在满足条件时优化主键点查，覆盖部分面向数据服务的混合场景。它的核心定位仍然是分析型数据仓库。核心账务、支付记账、订单事务等工作通常应继续由成熟 OLTP 数据库承担。1

这里需要分清“有事务能力”和“适合承载交易系统”。StarRocks 从 3.5.0 开始提供 SQL 事务；4.0 起，存算分离集群扩展了事务内 UPDATE、DELETE 和对同一表多次 INSERT 的支持。官方文档仍限定其使用范围：采用受限的 READ COMMITTED，同一事务中后续语句不能读取前面语句尚未提交的修改，还存在同库操作、语句顺序和写冲突检查等边界。因此，交易库中的事务流程需要逐项核对，不能因语法相近就直接迁入。9

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

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

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

• 将高价值、强服务需求的数据导入 StarRocks 原生表，按目标负载进行建模、索引和查询优化；
• 通过 StarRocks 的 External Catalog 直接查询受支持的湖上数据，在减少搬运的同时利用 SQL、缓存和优化能力。具体的数据源、格式、读写权限与支持范围，需要按对应 Catalog 文档确认。10

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

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

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

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

假设 CDC 延迟 1 秒，但报表查询需要 5 分钟，业务体验仍停留在分钟级；如果查询只需 200 毫秒，但数据每天凌晨才导入，整条链路仍属于离线数仓。这些数字仅用于说明链路关系。端到端时效需要沿着业务事件、同步、数据可见、报表刷新和查询返回逐段测量，不能把采集延迟当作完整答案。

在 StarRocks 中，服务端接收到请求、事务提交、数据对查询可见是需要区分的状态。异步 Merge Commit 返回时并不保证数据已经成功写入；普通 Stream Load 返回 Publish Timeout 时，官方说明导入任务已成功提交，但数据尚不可查询；此时应继续确认可见状态，无需重新导入。使用异步物化视图的看板，还要计入刷新调度、刷新执行以及应用缓存造成的延迟。11

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

下文用“三代演进”梳理分析需求的重心变化。这是一种教学划分，各类技术的发展和应用存在重叠，今天也仍然并存；产品能力不能仅凭所属阶段判断。

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

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

分布式存储与批处理让通用机器集群成为保存和处理海量数据的一条重要路径。它非常适合日终汇总、历史归档、复杂 ETL 和对时效要求不高的分析。

以早期基于 MapReduce 的批处理链路为例，作业启动、中间结果落盘和阶段调度都会产生开销，任务常按分钟或小时窗口安排，报表常以 T+1 形式交付。HDFS 的设计也侧重大数据集的高吞吐访问。这样的链路适合许多离线任务，对实时运营和在线风险监测则需要另外设计低延迟路径。这里讨论的是这类架构的典型用法，不能据此断言今天的 Hive 查询只能达到分钟级。13

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

Spark 提供内存中的数据复用和分布式计算能力，可以减少重复计算，支持批处理与迭代任务。Presto、Trino 等 MPP 查询引擎让用户可以直接对多种数据源执行交互式 SQL，不必每次都构建完整离线任务。

这一阶段推动了自助取数和数据湖上的交互式查询。Spark 可以把需要复用的数据持久化到内存中，Trino 则通过协调节点、工作节点和 Connector 组织分布式查询。能否达到秒级响应，仍取决于数据量、文件布局、查询计划和可用资源；远端 I/O、元数据访问和小文件问题也需要在实际数据源上检查。14

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

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

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

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

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

StarRocks 正是实时 OLAP 路线的代表之一。它通过 MPP、列式存储、向量化执行、数据跳读、预计算以及实时和批量导入，服务实时看板、即席分析和数据湖分析等场景。用户画像与日志分析还要结合更新模型、索引和部署形态确定具体方案。后续课程会逐层展开这些能力及其边界。1

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

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

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

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

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

列式存储减少无关列的 I/O；分区裁剪、ZoneMap、前缀索引、Bloom Filter 等机制用于缩小扫描范围，倒排索引可以在适用场景下进一步定位匹配记录。这些机制作用的粒度和触发条件不同，也会读取必要的索引或元信息，不能理解为整条查询完全没有 I/O。分析性能的第一原则往往是尽早排除无关数据，逐行计算速度则影响剩余数据的处理成本。2

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

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

传统逐行执行会频繁调用算子函数，产生分支、对象和虚函数开销。向量化引擎把一批数据按列组织，一次完成过滤、表达式计算或聚合，更容易利用 CPU Cache，并在适用算子中使用 SIMD 指令处理多个值。StarRocks 的 Chunk 保存一组列，Pipeline 算子通过 push_chunk、pull_chunk 传递数据批次；数据如何排布、算子如何处理，需要结合类型和执行路径理解。2

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

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

复杂 SQL 可能有多种 Join 顺序、分发方式和聚合路径。代价优化器需要依赖统计信息选择更合理的计划。对稳定报表，可以用同步物化视图或异步物化视图保存预计算结果，也可以在适用查询中利用缓存。其中，StarRocks Query Cache 主要复用本地聚合的中间结果，不能直接当作任意 SQL 最终结果的缓存。12

高并发点查则可以结合 Primary Key 表、Prepared Statement 和满足条件的短路查询评估。行列混存从 3.2.3 开始提供，要求使用 Primary Key 表；截至本章核对的官方文档，存算分离集群尚不支持这种存储形态。它还会增加存储和写入成本，持续写入对点查延迟的影响也需要单独测试。8

StarRocks 的查询性能来自数据布局、索引、执行引擎、优化器、预计算、缓存和分布式调度的共同作用。任何一个环节设计不当，都可能让预期收益无法兑现。最终仍要用目标查询和实际负载验证。1

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

7.1 实时经营看板

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

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

StarRocks 的适配点：实时导入、分区裁剪、物化视图和资源组可以作为构建看板链路的基础。异步物化视图的刷新策略、查询可用性和数据新鲜度需要一起检查；资源组也不能包办所有导入与后台任务的资源控制。12

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

7.2 自助分析与即席查询

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

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

StarRocks 的适配点：MPP 并行、列式扫描、Runtime Filter、分区裁剪和 CBO 可以为灵活分析提供支持。具体能减少多少扫描和网络交换，需要通过执行计划和 Query Profile 确认。222

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

7.3 实时风控与用户画像

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

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

StarRocks 的适配点：Primary Key 表可以维护可更新的业务状态；导入时的条件更新可以按指定的非主键版本列控制覆盖，Bitmap 和 HLL 分别用于精确集合与近似去重等计算。18

乱序保护需要落实到每个写入入口：仅仅使用 Primary Key 表，并不代表较旧的业务事件必然被拒绝。条件更新也不保护 DELETE，删除后旧消息重放的处理仍须单独设计。用于精确圈选的 Bitmap 还需要可靠的整数标识映射，不能把有碰撞风险的哈希结果当作绝对无误的成员身份。18

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

7.4 日志与可观测性分析

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

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

StarRocks 的适配点：稳定字段可以使用明确的数据类型，动态属性可以放入 JSON；Flat JSON 在适用条件下提取常见字段，减少读取和解析开销，再结合列式聚合分析日志。关键词检索可以评估 GIN 全文倒排索引，但必须核对表模型、分词方式、索引实现和部署形态。4.1 文档新增的内置倒排索引实现支持存算一体和存算分离，旧的 CLucene 实现仍不适用于存算分离。19

这些能力各有适用范围，不能把 JSON 当成 Doris VARIANT 的完全等价替换，也不能从“支持倒排索引”推导出与专用搜索引擎完全相同的查询语义。

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

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

8.1 更适合 StarRocks 的信号

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

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

8.2 StarRocks 优先级较低的场景

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

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

一种常见且边界清晰的架构是：MySQL 或其他 OLTP 系统负责交易，StarRocks 负责分析与数据服务。 是否继续扩展 Serving 范围，应根据更新语义、事务边界、数据新鲜度和实际尾延迟逐项判断。上面的选择方向是工程判断框架，不能代替业务 POC。19

8.3 用七个维度描述需求

在讨论选型之前，先把每条需求写成可测量的画像。下表数字是用于展示填写方式的需求示例，不是 StarRocks 的已测性能、配置建议或容量承诺：

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

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

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

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

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

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

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

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

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

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

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

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

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

这套架构应根据数据价值和 SLA 分层，无需把所有数据都搬进 StarRocks。交易库维护业务事实，StarRocks 承担分析与数据服务；高频热数据可以进入原生表，低频历史数据可以保留在数据湖，并按支持的数据源进行联邦查询。BI 中的库存分析指标允许有已约定的数据延迟，交易是否还能扣减库存仍应由交易链路裁决。1

POC 也不能只执行几条漂亮 SQL。

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

至少应验证：

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

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

从你所在企业或熟悉的业务中选取 5 条真实分析需求，填写下表。不要写“越快越好”，而要写可验证的数字。示例行仍是假设的业务目标，不代表本章已经运行过相应规模的测试。

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

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

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

十二、Knowledge Check

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

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

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

答案要点：查询只读取需要的列，减少 I/O；同列数据类型和分布相近，更易压缩；按列组织的数据适合批量计算，并能在适用算子中利用 SIMD 指令。

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

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

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

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

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

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

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

可以用一句话结束 Day 1：

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

下一篇将正式进入 Day 2｜StarRocks 全景：定位、能力、场景与边界。届时会回答：它的查询、更新与湖仓分析能力分别来自哪里，适合哪些场景，又有哪些需要提前验证的边界。

资料基线

• 1 StarRocks 官方产品介绍：核对分析型定位、导入、数据湖分析与 MySQL 协议接入。
• 2 StarRocks Database Features：核对 MPP、列式组织、向量化和编码后计算；不采纳其中未绑定本实验的性能倍率。
• 3 MySQL 8.4 InnoDB 官方手册：核对事务、锁、并发控制与业务库说明。
• 4 MySQL 8.4 Clustered and Secondary Indexes：核对聚簇索引、回表与覆盖索引的比较前提。
• 5 MySQL 8.4 Internal Temporary Table Use：核对临时表和落盘的条件。
• 6 StarRocks COUNT、SUM 函数文档：核对聚合、NULL 和分组去重语义。
• 7 StarRocks 4.0.14 源码：Chunk 与 Pipeline Operator；按固定 commit 核对批量数据结构和传递接口。
• 8 StarRocks Hybrid row-column storage：核对 3.2.3 起的行列混存、Primary Key 条件及部署限制。
• 9 StarRocks 3.5、4.0 与 4.1 SQL Transaction：核对事务的引入时间、操作范围与受限隔离语义。
• 10 StarRocks Catalog Overview：核对原生表与外部数据源的职责。
• 11 StarRocks Stream Load 与 TransactionStatus 源码：核对请求接收、提交和可见状态的区分。
• 12 StarRocks Asynchronous materialized views：核对预计算、刷新和透明改写的适用条件。
• 13 Apache HDFS Architecture 与 Apache Hive 官方资料：核对批处理设计背景；三代划分仅为本课教学视角。
• 14 Apache Spark RDD Programming Guide 与 Trino Concepts：核对内存复用、分布式执行与 Connector 分工。
• 15 StarRocks 4.0.14 SegmentIterator 源码：核对键范围、ZoneMap 与 Bloom Filter 的扫描裁剪路径。
• 16 StarRocks CBO 统计信息与 Query Cache 文档：核对代价估计和聚合中间结果复用。
• 17 StarRocks Resource Group：核对资源配额与不同工作负载的控制边界。
• 18 StarRocks Primary Key、条件更新、Bitmap 与 HLL：核对更新、删除和集合计算边界。
• 19 StarRocks Flat JSON 与 Full-text inverted index：核对动态属性处理和 GIN 的版本、实现及部署边界。
• 20 StarRocks Architecture：核对存算一体与存算分离的 POC 条件。
• 21 MySQL 8.4 How MySQL Uses Indexes：核对覆盖索引及免回表条件。
• 22 StarRocks Query Profile Tuning Recipes：核对 Runtime Filter 与扫描、Join 的检查方向。
• 23 TiDB TiFlash Overview：作为 HTAP 通过列式副本隔离负载的实现示例。

补充核对入口：SUM、3.5 SQL Transaction、4.0 SQL Transaction、Primary Key、Flat JSON、CBO 统计信息、Bitmap、HLL、Hive、Trino、Pipeline Operator、TransactionStatus。

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