数据程序全景图：从 MySQL 出发，看懂数据库、数仓与大数据技术

使用者痛点：刚入行时只会写 MySQL。面对海量新技术感到无所适从，不知道这些“数据库”到底该怎么选。

刚接触软件开发时我对“数据存储”的理解几乎都来自 MySQL：建表、写 SQL、加索引，再配一个 Redis 做缓存。

后来接触 Neo4j，才知道数据不一定要组织成关系表；看到 Hadoop 和 Hive。又发现有些程序负责存文件，有些程序只是把文件抽象成表；再往后还有 Kafka、Flink、Spark、ClickHouse、Elasticsearch、数据湖、湖仓一体…，按理说，

这些名字放在一起。很容易产生一种错觉：软件领域怎么有这么多“数据库”？

使用者痛点：技术太多。缺少程序化的认知地图，导致学习效率低下。按理说，

真正的问题不是技术太多。而是我们缺少一张地图，

MySQL、Redis、HDFS、Hive、Kafka 和 Spark 并不是同一种产品，也不处于同一个层级。其实，它们分别在解决数据的保存、组织、查询、传输、计算和治理问题。其实，一旦先分清这些职责，再遇到新技术，就不需要从零背概念了。不过，

这篇文章不讲某个产品的底层实现。而是尝试建立一套数据程序认知框架。

目录

1. 先别记产品，先看数据的一生
2. 用四条轴定位一个数据程序
3. 数据程序的完整技术图谱
4. 至于底层存储，数据最终放在哪里
5. 至于在线数据库，业务如何保存和查询数据
6. 再看分析程序。如何从海量历史数据中得到结论
7. 数据传输与计算：数据如何流动和加工
8. 数据
9. 用一个电商程序串起整张图
10. 遇到新技术时如何快速建立主要画像
11. 初学者最容易混淆的概念
12. 一条更合理的学习路线

先别记产品，先看数据的一生

使用者痛点：看到各种工具，却不知道它们在业务流程中的具体位置。

一条数据从产生到被使用，通常会经历下面这些阶段：

产生↓保存↓传输与同步↓清洗和加工↓查询与分析↓归档、治理或删除

例如使用者在电商网站完成一次支付：

• 订单服务先把支付结果写入业务数据库。
• 缓存中可能同步更新订单状态。
• 数据变化被发送到消息程序。
• 实时计算程序更新销售大屏。
• 原始记录进入数据湖或数据仓库。
• 离线任务汇总日报、月报和使用者特点。老实说，
• 搜索、推荐、风控等程序消费加工后的数据。按理说，

使用者痛点：No single technology can handle all se responsibilities.

用四条轴定位一个数据程序

• S存储 S查询 S计算 S传输 S治理

它面向哪种工作负载？

• OLTP - 高并发、小事务、多事务一致性需求，例如订单创建。OLAP - 大批量扫描聚合，例如年度报表。

它如何组织数据？

• A. 关系表 B. 键值 C. 文档 D. 图 E. 宽列 F. 时序 G. 搜索索引 H. 向量 I. 文件/对象

它是权威源还是派生程序？

• # 关键冲突判断 # ：当同一条记录在多个组件出现冲突时以哪个为准？

数据程序的完整技术图谱

数据程序
├── 底层存储
│ ├── 本地文件程序
│ ├── 分布式文件程序
│ ├── 对象存储
│ └── 文件格式
├── 在线数据库 & 专用查询
│ ├── 关系型
│ ├── 键值
│ ├── 文档
│ ├── 图
│ ├── 宽列
│ └─ 时序 …├── 分析 / 数仓 / 湖仓
│ ├── 分析型 DB
│ ├── 数据仓库
│ ├── 数据湖
│ └─ 湖仓表格式 …├── 数据传输 & 计算
│ ├── 消息流网站
│ ├── CDC 同步工具
│ ├── 批处理
│ └─ 流处理 …└─ 数据治理
├─ 元信息 & 目录
�<|endoftext|>