Tencent Cloud · Beginner Data Journey

一条订单，如何从 MySQL 走到 BI 报表？

把自己当成第一次接触大数据：先看业务数据库如何产生变化，再看 CDC 如何读取源库 Binlog，最后理解 COS、Iceberg、Parquet、建模与 BI 各自负责什么。

零基础主线变化高亮可点击快照中英双语

购物车商品10尚未成为订单

源库订单0MySQL COMMIT 后可见

可信收入¥0通过质量门后统计

采集模式实时 CDC读取源 MySQL Binlog

学习进度0%先完成一次下单

One continuous route

先看全图，再从上到下逐段理解

最重要的边界MySQL 是业务真相来源；Binlog 属于源 MySQL。COS 数据湖保存对象文件，没有 MySQL Binlog。

Source database

先产生一笔真实、已提交的业务订单

购物车不是最终业务数据；只有订单服务成功 COMMIT 到 MySQL，CDC 才能看见。

Editable source event

编辑购物车，再提交订单

购物车	用户	商品	数量	单价	区域

相同 cart_id 的商品会在订单服务中合并成一条 orders 主表记录，同时逐条写入 order_items。先修改数据，再点击“合并并下单”。

Stage inspector

用户点击下单

01 / Checkout

Extraction & ingestion

CDC 读取的是源数据库 Binlog，不是数据湖 Binlog

点击 INSERT、UPDATE、DELETE，观察“源库行 → Binlog 事件 → CDC 消息 → 湖文件”的变化。

业务应用订单服务BEGIN / INSERT / COMMIT

源系统MySQL 业务库orders / order_itemsBinlog 在这里

源库日志MySQL Binlog已提交 INSERT / UPDATE / DELETE

采集层CDC Connector解析 before / after

流处理CKafka / Oceanus分发、转换、检查

数据湖COS + IcebergParquet / Metadata / Manifest这里没有 MySQL Binlog

Lake write

变化写入 COS；Iceberg 把 Parquet 组织成可版本化的表

文件格式负责保存数据，Iceberg 负责事务、快照和文件索引，COS 负责持久化对象。

Storage anatomy

湖中的文件分别做什么？

Storage choice

HDFS 与 COS 的区别

Snapshot → Parquet mapping

不同 Snapshot 到底对应哪些 Parquet 文件？

Snapshot 通过 Manifest 间接引用文件

不是一对一关系

一个 Snapshot 表示某次成功提交后的整张表状态。它可复用旧 Parquet、增加新 Parquet，也可通过 Delete file 表达删除。请选择 S1、S2、S3 查看变化。

新增发生变化复用删除规则

Iceberg metadata chain

从 Catalog 指针一路找到真实数据文件

Iceberg 是表格式，不是固定 Catalog 名称

核心关系

Catalog 只把 sales.orders 指向当前 metadata JSON；metadata JSON 内的 Snapshot 再指向 Manifest list，Manifest list 指向 Manifest，Manifest 最终列出 Data/Delete files。

写 Data/Delete files写 Manifest写 Manifest list写新 metadata JSONCatalog 原子切换指针

术语依据：Apache Iceberg Terms · Iceberg Table Spec

Transform & model

清洗、质量门、分层建模，再形成 Mart / Gold

EMR、DLC、Oceanus 是计算工具；它们读取湖表、执行规则，并回写新的 Iceberg Snapshot。

Data quality gate

制造脏数据，观察哪些记录不能进入可信层

通过质量门0进入 Clean / Silver

拒绝记录0进入隔离区

先完成下单，再注入一种异常。

Lakehouse layers

同一份订单如何从 Raw 变成可信指标

Product guide

不同计算与服务产品负责什么？

EMR component stack

EMR 各层组件怎么理解？

可用组件取决于发行版和集群类型，不代表一套集群要全部安装。

版本依据：Tencent Cloud EMR Component Versions

Serve, BI & report

把治理后的数据变成可重复使用的经营指标

Gold 数据可直接由 EMR/DLC 探索；生产 BI 通常发布到 TCHouse，再经语义层统一指标。

Dynamic BI dashboard

从当前可信订单实时生成经营报表

只使用通过质量门的订单，并按 order_id 关联 order_items。修改源数据并重新下单后，指标会一起变化。

报表区域

收入¥0已支付且通过质量门

已支付订单0唯一 order_id

平均客单价¥0收入 ÷ 已支付订单

售出件数0可信订单关联明细

各区域收入来自 curated_orders

各区域订单占比已支付订单分布

热销商品仅关联通过质量门的 order_id

新鲜度与质量尚未生成报表

Query lab

运行一个分析查询

SELECT region,
       COUNT(*) AS orders,
       SUM(amount) AS revenue
FROM curated_orders
WHERE status = 'PAID'
GROUP BY region
ORDER BY revenue DESC;

点击“执行查询”查看结果

Operations & governance

上线后持续检查新鲜度、质量、分区和血缘

知识问答已移除；这里保留更贴近生产的健康检查。

AppSource MySQLBinlog / CKafkaOceanus / SparkCOS / IcebergTCHouse / BI

新鲜度 SLA等待检查

质量通过率等待检查

分区与小文件等待检查

血缘与责任人等待检查