技术栈 › 总览

一笔订单从下单到出现在报表里:八个系统、十九张图解怎么接在一起

每张图解只讲一个系统。这一页把它们放回同一条链路:谁在谁上面、数据从哪流到哪、为什么要多这一层、多这一层付出了什么。另有六张「地基」图解(B+ 树与 InnoDB 索引、MySQL 事务、LSM-Tree、行级删除、Join 单机算法、JVM 堆与 GC),讲的是这些系统脚下的机制。

读前须知 · 需要你会:写 SQL(SELECT … JOIN … GROUP BY);Java 后端常识(线程池、HashMap、BlockingQueue、文件读写)。不需要:读过任何一张图解。读完这页你会:知道十九张图解分别讲什么、其中在链路里的各坐哪一层、先读哪张;能说清“一笔订单从业务库到报表经过哪些系统、每一层为什么存在、各付出什么代价”;拿到一个问题(怎么少读、怎么改一行、挂了怎么办、小文件、怎么原子提交)时,知道每一层各自怎么回答、去哪张图看细节。本页的链路是为了把其中九张图串起来设计的典型形态【本页设定】,不是公司的真实链路;十九张图的例子各自独立设计,数据都不是实测。

分层地图

上 → 下是层级(上层用下层);左 → 右是数据的流向。点任意方块看它的身份卡;用步进条按顺序走一遍一笔订单的旅程。←/→ 键也能翻步。

窄屏下地图可以左右滑动查看全部。

计算引擎 表格式(文件之上的元数据层) 文件 / 存储格式 存储 来源与使用方(MySQL、Kafka、Redis 有图解;BI 没有) 当前步骤 ByteHouse 的路径【推断】 JVM 底座 / 旁路(有图解,不在数据链路上)

推荐阅读顺序

按“后面的图要用到前面的结论”排:每张卡片写了它依赖哪几张。下划线颜色 = 它在地图上的层。

    为什么是这几层

    每一层都是为了解决下面那一层做不到的事,同时带来新的代价。四个最常被问到的“为什么不直接……”:

    同一个问题,各层怎么答

    面试和排障里反复出现的五个问题。每一层给出的答案不一样,而且上层的答案往往建立在下层的限制上。最右列是去哪张图、哪个视图看细节(打开页面后在顶部切换视图)。

    系统它怎么做 · 代价细节在哪

    标记与数据说明

    【推断】
    按公开资料或开源源码推出来的,没在真实环境核对过。ByteHouse 内部结构没有公开源码,ClickHouse 图解的「存算分离」视图和本页所有 ByteHouse 内容都按开源 ByConity 架构推断。
    【经验值】
    业界常见的量级,随硬件、版本、数据分布变化,只用来判断数量级。
    【简化】
    为了画清楚省掉的细节(比如省掉某个中间进程、某类元数据文件)。
    【本页设定】
    为了让机制显形人为设定的数据或情景(比如某次故障发生的时间、某张表的行数)。
    【缩尺】
    配置值比默认小,是为了用很少的数据把机制演示出来;页面里同时写出真实默认值。
    • 十九张图的数据都是按教学设计构造的,不是实测。唯一的例外:Spark Join 图解的物理计划是本地 Spark 3.5.3 实测的 explain 输出。
    • 各页按页内写明的版本描述行为(Spark 3.5、Flink 1.20、ClickHouse 24.x 等);换版本时默认值可能不同。
    • 本页的链路(MySQL → Flink → Paimon → Spark → Iceberg → ByteHouse)是设计出来的;现实里一个湖通常只选一种表格式,Paimon 和 Iceberg 同时出现只为把两张图串起来。ByteHouse 的导入方式以公司实际为准。