DBPA · 16.2

HTAP 与大数据时代的新型数据仓库

订单刚提交，分析报表什么时候能看见

VER. 2608.4 Built with impress.js

学习目标

围绕“订单提交后多久进入地区销售报表”，你能够

01说明订单为什么已提交却还没有出现在分析报表中
02用同一软件、统一 SQL 接口和同一业务数据定义 HTAP
03比较单引擎与多引擎处理订单更新和地区分析的方式
04解释行存、列存、格式转换和副本同步带来的代价
05沿业务源、ETL、仓库和 OLAP 找出等待与重复计算
06根据新鲜度、隔离和移动成本选择架构起点

2/14

LEARNING OBJECTIVES

HTAP 缩短事务到分析的距离

10:00:00 订单提交成功，10:00:20 地区销售报表仍没有这笔订单

一种行列协作实现：业务写入经同步机制进入列存分析路径 — 一种物理实现示意，不代表所有 HTAP 都先写行存再复制到列存

订单提交→等待复制或转换→分析端可见

逻辑上，HTAP 用同一套数据库软件和统一 SQL 接口，在同一业务数据上同时支持事务与分析

物理上，系统仍可以维护行存、列存或其他副本，因此分析可见时间仍要检查

3/14

HTAP

单引擎可以在一个系统内组织两种负载

订单写入和地区汇总使用不同访问方式，存储组织也会产生不同代价

负载	典型组织	主要取舍
写入一笔订单	行存储	便于按记录点查和更新；扫描大量订单可能较慢
汇总地区销售	列存储	便于扫描、压缩和并行；更新或格式转换有成本
写入与汇总并存	行列混合组织	少跨一个系统，但仍要处理转换、同步和资源竞争

4/14

SINGLE ENGINE

多引擎用组件专业化换取同步和接口成本

事务系统写订单，分析系统做汇总；两边怎样同步成为新的问题

OLTP 加 OLAP

订单进入事务系统，再经 ETL 或复制进入仓库；地区报表会晚于事务提交

OLTP 加 NoSQL

订单表留在关系数据库，点击日志进入大数据平台；接口和字段含义要另外对齐

共同难题

两种路线都要处理副本同步、故障恢复和统一查询入口

Takeaway

多引擎保留专业组件，也增加了数据移动和接口维护

5/14

MULTI ENGINE

大数据时代改变规模、类型和分析任务

同一个销售主题开始同时接收订单表、点击日志和商品图片

规模

订单和访问记录从 TB 增长到 PB，单机扫描时间和存储成本上升

类型

结构化订单、半结构化点击日志和非结构化商品图片需要不同处理方式

分析

除了销售报表，还要做预测、关联和 what-if 分析

6/14

NEW REQUIREMENTS

混合负载与新硬件的压力

下单高峰与全量销售扫描同时发生，二者会争用处理器、内存和带宽

负载

短事务持续写入订单，长查询同时扫描历史销售

硬件

多核、大内存和高速网络可以加速处理，但不能替系统决定谁先使用资源

Takeaway

硬件提供并行能力，系统仍要隔离短事务与长查询

7/14

NEW WORKLOADS

分层架构的数据移动成本

跟着一笔订单走过业务源、ETL、仓库和 OLAP，就能找到等待发生在哪里

一种传统批处理路径经过业务源、ETL、仓库和 OLAP 多个边界，数据移动造成等待与重复计算 — 典型批处理分层与数据移动路径

01

写入

订单先在事务系统提交

02

抽取

ETL 等待批次，再复制和转换订单

03

组织

仓库重组主题数据，OLAP 建立汇总结构

04

查询

地区报表读取分析端当前可见的数据

8/14

DATA MOVEMENT

新增“退货原因”会改动哪些环节

一个新字段会从订单源一路传到地区销售分析

01订单系统增加退货原因并确定取值口径
02ETL 增加字段映射和清洗规则
03仓库修改事实或维度结构并重新装载
04报表增加退货分析并重新计算历史结果

Takeaway

架构不仅要缩短数据等待，也要缩短业务变化传到分析端的路径

9/14

ADAPTATION

关系与大数据平台共存的代价

订单表留在关系仓库，点击日志进入大数据平台，连接器负责交换数据

关系仓库订单＋大数据平台日志→连接器交换→统一查询入口

目标	设计回应	新的瓶颈
高扩展	分布式和并行平台	跨节点协调与故障恢复
混合负载	行存、列存或多副本	资源隔离与副本同步
开放接口	连接器和统一 SQL	传输带宽与字段含义对齐
低延迟	就地分析和缓存	可见新鲜度与资源隔离

连接器可以搬运数据，但不会自动统一字段含义或保证副本一致

10/14

COEXISTENCE

练习：为三个销售场景选择架构起点

Exercise

场景	先写出关键要求	选择的架构起点
新订单一分钟内进入地区报表，同时不能拖慢下单	新鲜度、事务隔离	单引擎／多引擎／继续核对
夜间生成一次销售报表，现有仓库运行稳定	延迟容忍、维护成本	单引擎／多引擎／继续核对
订单表与点击日志联合分析，两个平台都要保留	语义映射、移动成本	异构共存／其他／继续核对

Takeaway

先写出可见时间、隔离要求和数据移动，再选择系统组合

11/14

DESIGN CHECK

本节回顾：从分离式仓库到方案判断

从订单提交到地区报表，架构选择始终围绕可见时间、事务隔离和数据移动

HTAP

同一软件和统一 SQL 接口同时服务订单事务与销售分析

单引擎

少跨一个系统，但仍要处理行列转换与资源竞争

多引擎

事务与分析各用专业系统，但订单要等待复制和转换

异构共存

连接器交换订单与日志，字段含义和副本一致仍需维护

Takeaway

没有脱离场景的最佳架构，先说明时间、负载和数据路径

12/14

RECAP

本节知识地图

13/14

KNOWLEDGE MAP

本节问题

01订单已经提交，为什么地区销售报表仍可能看不到它？
02单引擎和多引擎分别怎样处理订单事务与销售分析？
03行存和列存分别适合什么访问方式，格式转换会增加什么代价？
04一笔订单经过业务源、ETL、仓库和 OLAP 时，等待可能发生在哪里？
05新增“退货原因”为什么会引起整条仓库链的修改？
06面对三个销售场景，你会选择哪种架构起点，依据是什么？

14/14

CHECK YOUR UNDERSTANDING