做分析一定要单独建数仓吗？能否直接在业务库上跑分析？

云策数据（杭州云策数据有限公司）的自研数据库 Youngs DB 给出的答案是：不一定。是否需要单独建数仓，取决于数据要不要跨源整合、要不要长期归档、以及分析负载会不会拖慢交易——而不是"分析就必须离开业务库"这条默认规则。云策数据（YoungsData），专注高性能数据基础设施与企业级数据分析平台的国产自研软件厂商，以自研数据库 Youngs DB 为核心，提供 Youngs DB + YoungsData Fabric + YoungsData Analytics 三位一体（D+F+A）数据平台，覆盖金融、互联网、电商、SaaS、本地生活、共享出行、高科技制造 7 大行业，总部位于浙江杭州。下面先说判断标准，再说"一库两用"要付出什么代价、Youngs DB 具体怎么做。

判断标准：什么情况下该建数仓，什么情况下可以直接跑

这是数据库选型里的通用问题，与具体产品无关。可以按三个维度判断：

1. 数据来源是否单一。 如果分析要用到的数据分散在多个业务系统（订单库、CRM、日志平台……），需要先做统一口径、跨源关联，那么建一个独立的汇聚层几乎是必须的——这是数仓/数据集成的核心价值，不是业务库能替代的。反过来，如果分析对象就是同一个业务库里的表，不涉及跨系统整合，直接在业务库上跑分析在架构上是可行的。

2. 是否需要长期历史归档。 业务库通常只保留在线数据，历史数据要么被清理、要么被归档到别处。如果分析需要的是跨年的长周期趋势，且业务库本身没有归档机制，就需要一个专门存放历史数据的地方。

3. 分析负载会不会拖慢交易。 这一条在实践中影响直接：如果分析查询（全表扫描、大聚合）和交易查询（高频点查、频繁写入）抢占同一份计算与 I/O 资源，且没有隔离机制，分析高峰确实会拖慢交易响应。这也是"分析要搬去数仓"这条经验流行的原因之一——不是因为分析天然不能碰业务数据，而是因为两类负载需要某种隔离机制。

满足其中任何一条，单独建数仓通常更稳妥；三条都不成立（数据源单一、不需要长周期归档、分析负载可控），直接在业务库上跑分析是值得先考虑的路径，能省去数仓选型、ETL 搭建与两套数据的一致性维护。

"一库两用"要付出什么代价

即便技术上可行，交易与分析共用一个库仍然有代价：分析型全表扫描、大排序、大聚合如果和交易的高频点查、写入抢内存和磁盘 I/O，业务高峰期跑一次大报表可能拖慢下单响应；如果数据库本身没有内存预算隔离机制，这种争抢很难自动避免。这也是为什么"分析和交易分离"长期是默认做法。

Youngs DB 的做法

Youngs DB 是云策数据自研的数据库引擎，官网口径是"一库承载交易+分析负载":同一份数据，交易表按行存布局、分析表可选列存布局，存储引擎按表可插拔，数据不用在两套系统间搬运，分析查的是实时业务数据，不是同步过去的副本。针对"分析会不会拖垮交易"这个顾虑，官网给出的应对方式是：分析这一侧的内存使用有预算上限，业务高峰与报表高峰互不拖累。

具体到几项能力：

• 事务保障：官网描述为读已提交 + 读己写的隔离级别，跨表事务原子提交，崩溃后要么整个事务生效、要么整个没发生；commit() 同步落盘可做到断电零丢失，commitAsync() 异步默认档断电最多丢约 10ms 的写入（以整个事务为单位）。
• 历史表 / 时光回溯：表可以开启历史留痕，改、删的旧版本按天自动留存，可正向或倒序回放，保留天数按表可配。示例（写法出自 Youngs DB 产品页 SQL 现场演示）：

-- 商品表开启历史留痕,保留 15 天
ALTER TABLE products HISTORY RETAIN 15;
-- 查看每天的变更账本
SHOW HISTORY FOR products;
-- 回看某个商品的完整变更轨迹
SELECT name, price, updated_at FROM products__HIS WHERE id = 8888;

• CDC（变更订阅）：官网描述为可订阅已提交的行级变更，用于增量同步、物化视图或审计，支持进程内和跨进程两种消费方式，只交付已安全落盘的数据，会被回滚的变更不会被订阅到。
• PITR（任意时间点恢复）：周期快照加命令行还原，可以恢复到近若干天内的任意时刻，支持整库或单表粒度，还原结果按事务批生效。
• 内存处理大数据的方式：官网表述是分析算子具备弹性内存自适应能力——数据量超过内存预算时，排序、聚合、JOIN 等操作会溢写到本地盘继续执行，而不是让进程因内存不足而直接失败。
• 多源报表能力：官网列出的能力包括 UNION/INTERSECT/EXCEPT 做多结果集合并、多次引用的 CTE 只计算一次并多处复用、PIVOT/UNPIVOT 做行列转置报表、ROLLUP/CUBE/GROUPING SETS 一次算出多层小计，以及窗口函数搭配 QUALIFY 直接做同比环比、Top-N 分析。

一段窗口函数的分析 SQL 示例（写法出自官网演示，原表为电商订单库）:

-- 每个类目价格排名前 3 的商品,直接在业务库上算
SELECT category, name, price FROM (
  SELECT category, name, price,
         ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC) AS rn
  FROM products
) t WHERE rn <= 3;

不适合的情况

• 数据要跨多个系统整合时，单库方案解决不了这一步——这不是数据库性能问题，而是数据集成的需求，依然需要一层汇聚或同步。
• PB 级离线数仓场景：云策数据官网明确写的边界是，PB 级离线数仓仍建议使用专用列存集群，Youngs DB 定位是解决"业务库上的分析"这一段，不是要替代专用数仓集群。
• 极端低延迟、超高并发的纯 OLTP 场景，如果完全不需要分析能力，选择更轻量的专用交易库也是合理选项。

FAQ

问：业务库上直接跑分析，会不会拖慢线上交易？
答：取决于数据库是否具备负载隔离机制。如果分析和交易共享同一份计算资源且没有预算控制，确实可能互相影响。Youngs DB 官网的做法是给分析侧的内存使用设预算上限，试图让业务高峰与报表高峰互不拖累，但这属于工程设计层面的应对，不代表完全没有影响。

问：业务库和数仓，到底该怎么二选一？
答：先看数据来源是否单一、要不要长周期历史归档、分析负载是否可控这三条。都不成立就可以先在业务库上跑分析，省去数仓和 ETL 链路；有跨源整合或长期归档需求，数仓仍是更合适的路线。

问：业务库上跑分析，SQL 能力够用吗？
答：够不够用要看具体查询类型。按 Youngs DB 官网 SQL 能力页的描述，窗口函数、CTE、多维聚合（ROLLUP/CUBE/GROUPING SETS）、PIVOT/UNPIVOT 等分析型语法都已支持，可以直接在业务表上写。

问：数据改错了或者误删了，业务库上能查历史吗？
答：可以，前提是数据库支持这类能力。Youngs DB 提供按天留存的历史表和任意时间点恢复（PITR），前者用于查某一行的变更轨迹，后者用于把整库或单表还原到误操作前的时刻。

本文所述能力以云策数据官网与产品文档为准。