从数据采集到 OLAP 分析：看懂大数据软件如何部署、运行与协作

这是一篇给大数据入门者看的“看懂运行原理”笔记。 我们不急着背产品名称，而是先弄明白：它是什么软件？安装在哪里？启动后有哪些进程？数据是怎样从一台机器跑到另一台机器的？以及，什么时候才值得使用它？

阅读时可以一直带着一个画面：几台装了 Linux 的普通服务器、一些运行中的程序，以及在它们之间流动的数据。 大数据系统并没有神秘到脱离这些东西。

阅读路线：这篇文章很长，但不需要一次读完

本文围绕一条数据链路展开，并不要求读者提前掌握 Linux 集群或大数据经验。第一次阅读可以按下面的路线走：

• 想看清“分布式软件到底长什么样”：先读第 2～9 节，重点是 Hadoop、HDFS、YARN、MapReduce、Spark、Flink 的进程与协作。
• 想理解“怎样把数据拿过来”：读第 10～12 节，认识 SeaTunnel、DataX、NiFi、Kafka 与 CDC。
• 想理解“数据放哪里、怎样查得快”：读第 13～14 节，认识文件系统、数据湖和 OLAP 数据库。
• 正在做真实项目：重点看第 15～18 节的断点恢复、业务正确性和 PoC。

每个产品都尽量回答同样的四件事：它是什么、运行什么进程、数据如何流动、适合什么工作。文中的文字架构图用于解释角色，不是可以直接照搬的生产部署拓扑。

---

1. 为什么突然要学习这些东西？从一次医疗数据抽取说起

我过去主要做 Java 后端，习惯了 MySQL、Oracle、Spring Boot 这样的技术组合。接到需求后，写接口、查数据库、处理业务，再返回结果，这套思路很熟悉。

后来参与一个医疗专病研究平台，情况变了：医院的数据总量达到亿级，目标是筛选约 18 万名患者及其历史诊断、就诊和检验数据。一位患者可能有多次就诊，每次就诊又对应许多检验报告和明细。原本看似不大的患者数量，展开后便是大量的医疗事实。

源数据库是一份截至 2025 年年底的 Oracle 11g 只读历史镜像。部分源表缺少合适的索引，医院内网连接也不稳定，抽取过程中还反复遇到 Connection reset。

最开始尝试自己在 Java 中实现分页、并行读取、重试和断点续传，结果花了大量时间处理那些与医疗业务无关、却又绝不能做错的基础设施问题。后来先用 Python 脚本完成了这一轮历史数据导入，再将数据整理到 MySQL 中供后续检索使用。

这让我产生了一个问题：既然大数据行业已经发展这么多年，难道这些采集、传输、计算、存储的能力，还需要每个项目从头写一遍吗？

答案显然不是。但另一个极端也不对：看到“分布式”“实时”“亿级”就把 Hadoop、Kafka、Flink 全装上，系统可能会比原先更难维护。

所以，这篇文章不打算做“产品名称大全”，而是从软件如何运行的角度，把这些工具真正串起来。

说明：文中的项目背景用于解释工程问题，不涉及真实患者数据。后文提到的 V2 抽取方案是设计思路，不能当作已实现、已测试的能力。

---

2. 先建立一个画面：大数据系统到底长什么样？

2.1 它的本质还是一些普通的软件进程

想象我们有三台服务器：

                  局域网
                     │
     ┌───────────────┼───────────────┐
     │               │               │
服务器 A          服务器 B          服务器 C
Linux             Linux             Linux
CPU / 内存 / 磁盘   CPU / 内存 / 磁盘   CPU / 内存 / 磁盘
     │               │               │
 某些服务进程      某些服务进程      某些服务进程
     └───────────────┼───────────────┘
                 网络通信

一套分布式系统，通常就是把不同的服务进程部署在这些机器上，再让它们通过网络协作。

例如你熟悉的 Spring Boot：启动一个 JAR，操作系统里就出现一个 Java 进程，它监听端口、访问数据库、处理请求。大数据软件并没有脱离这个模型，只是同一套软件可能需要启动多种不同角色的进程。

有些角色负责管理，有些角色负责真正读写数据或执行计算。于是，你会反复遇到 Master/Worker、Coordinator/Executor、Frontend/Backend 等词。

这些词常常表示“协调者”和“执行者”，但不同产品的名字、职责以及高可用设计并不完全一样。

2.2 一定要区分四个层次

听到的词	它可能是什么	可以怎样理解
概念或算法	OLAP、CDC、Map/Reduce 思想、幂等	一种做事的方法，不一定有独立程序
软件项目	Hadoop、Spark、Flink、Doris	可下载安装的代码、服务、库或工具集合
进程 / 服务角色	NameNode、DataNode、JobManager、BE	软件启动后实际运行的某类服务
一次任务	MapReduce Job、Spark Job、SeaTunnel 同步 Job	用户提交的一次具体工作，有开始和结束，或持续运行

“某产品用 Java 开发”也不等于“它在每台机器上只启动一个 Java 程序”。 有的产品由多个 JVM 进程组成，有的核心服务是 C++ 程序，还有的工具只是库或命令行客户端。

再记住三个小词：

• 节点（Node）：通常指一台服务器或虚拟机；在容器化部署中，也要注意区分节点、容器和进程。
• 集群（Cluster）：一组共同提供服务的节点和进程。不是把机器放进同一个机柜就自动变成集群。
• 任务（Task）：一次作业被拆分出来的执行单元。一台机器上可以同时运行多个 Task。

2.3 一条数据链路：采集、传输、存储、计算、分析

先画一张总图：

Oracle / MySQL / 文件 / 日志 / API
                │
                ▼
         ① 采集 Ingestion
     （把数据从源头取出来）
                │
                ▼
         ② 传输 Transport
     （把数据稳定地送往下游）
                │
                ▼
         ③ 存储 Storage
     （把数据保存下来）
                │
                ▼
         ④ 计算 Processing
     （清洗、关联、转换、聚合）
                │
                ▼
         ⑤ 分析 Analytics
     （查询、报表、筛选、研究）

这只是为了学习而画的逻辑链路。真实系统会交叉：采集时可以进行转换，计算结果还会写回存储，分析型数据库自己也负责计算。

环节	先记住的代表产品	核心问题
采集	DataX、SeaTunnel、NiFi、Debezium	从哪里取数据，怎么识别变化
传输	Kafka、Pulsar	上下游速度不一样，怎么办
存储	MySQL、HDFS、对象存储、数据湖表格式	数据如何可靠保存
计算	MapReduce、Spark、Flink	如何让多台机器一起处理
分析	Doris、ClickHouse、Hive、Trino	如何让大范围查询足够快

下面从最容易在脑海里画出来的 Hadoop 开始。

2.4 ETL 与 ELT：先处理再存，还是先存再处理？

另外两个常见词是 ETL 和 ELT。它们描述数据集成与加工的顺序，而不是两款必须安装的软件。

• ETL（Extract → Transform → Load）：先抽取，再转换，最后写入目标。例如先把来源系统的单位、代码转换成统一格式，再写入研究库。
• ELT（Extract → Load → Transform）：先抽取并加载到受控存储，再用数据库或计算引擎加工。例如把经过授权的原始字段保存到暂存层，再用 SQL 或 Java 规范化。

ETL：Oracle → 抽取 → Java/Spark 转换 → 分析库
ELT：Oracle → 抽取 → 暂存区 → SQL/计算引擎转换

实际项目经常混用两者：进入暂存区前先做必要脱敏、格式校验，之后继续完成复杂标准化。ETL/ELT 描述流程安排，不规定你必须使用 Spark 或某个特定产品。

---

3. Hadoop 到底是个什么东西？

3.1 首先，它确实是一套软件，不仅仅是“思路”

Apache Hadoop 是一个真实存在、可以下载、安装、配置、启动的开源软件项目。 它由多个模块构成，而它背后的设计思想是：将大量普通机器组织起来，共同承担存储与计算。

所以，说它是一种“思路”是在解释思想；说它是“一套软件”是在描述实际形态。二者都对，但对于初学者，应该先把它想象成一套可以部署的 Java 软件和相关组件。

Hadoop 传统核心包括：

组件	负责什么	是否有实际运行的服务
HDFS	分布式文件存储	有，如 NameNode、DataNode
YARN	管理集群计算资源	有，如 ResourceManager、NodeManager
MapReduce	批量并行计算框架	有实际计算进程，但在 YARN 模式下通常按作业启动
Hadoop Common	共享的 Java 库、工具和配置	主要是公共基础模块，不是必须独立常驻的一个服务

可以这样理解：HDFS 是仓库，YARN 管人力和机器资源，MapReduce 是一种安排工人做批量计算的方法。

3.2 一套简化的 Hadoop 集群长什么样？

                  Hadoop 集群（逻辑示意）

管理节点 A                      工作节点 B           工作节点 C
┌────────────────────┐        ┌─────────────┐     ┌─────────────┐
│ NameNode（HDFS）    │        │ DataNode    │     │ DataNode    │
│ ResourceManager     │        │ NodeManager │     │ NodeManager │
└──────────┬─────────┘        └──────┬──────┘     └──────┬──────┘
           │                         │                   │
           └──────────网络────────────┴───────────────────┘
                   │                         │
             管理文件位置              存放文件块、运行任务

这张图是教学简化图，不是生产推荐部署方案。生产环境通常还会配置高可用、独立管理节点、多个工作节点以及安全认证。

特别注意：HDFS 和 YARN 是两套不同的服务体系。它们可以部署在同一批服务器上，但“存储节点”和“计算节点”并不必须完全重合。

---

4. HDFS：到底是哪几个 Java 程序在存文件？

4.1 HDFS 是什么？

HDFS（Hadoop Distributed File System）是一套分布式文件系统软件。你可以像操作普通文件系统一样读写文件，但文件的实际内容可能分散在多台服务器磁盘上。

它的核心实现基于 Java。典型部署中会运行两类主要的 JVM 服务：

• NameNode：掌管“文件目录和文件块在哪里”的信息；
• DataNode：负责把真正的文件块保存到本机磁盘，并响应客户端读写。

4.2 谁在管文件？谁在保存文件？

比如要保存一个大文件 lab-2025.csv。在简化示例中，把它分为 A、B、C 三块：

          NameNode（文件管理员）
    /data/lab-2025.csv → [A, B, C]
                   │
       记录每个 Block 的位置
                   │
    ┌──────────────┼──────────────┐
    ▼              ▼              ▼
DataNode 1     DataNode 2     DataNode 3
保存 A、B       保存 B、C       保存 A、C

这里为方便理解，画的是“多个数据块拥有多个副本”。块大小与副本数都可以配置；在某些经典部署中，128 MiB 块大小、3 副本是常见选择，但并非所有版本和集群的固定值。

NameNode 主要保存元数据，不是把全部文件内容搬到自己内存里再转发。 这点很重要，否则 NameNode 很容易成为每次读写都必须经过的超级瓶颈。

4.3 走一遍上传文件的过程

假设客户端要上传一个 500 MiB 的文件，以下是简化后的步骤：

1. 问 NameNode：客户端要创建 /data/lab-2025.csv，NameNode 检查路径、权限，并决定数据块应放在哪里。
2. 切成 Block：客户端按文件系统配置，将文件组织成多个数据块。
3. 直接写 DataNode：客户端将数据写给指定的 DataNode，副本通常通过 DataNode 之间的流水线复制完成。
4. 报告进度：DataNode 定期向 NameNode 报告存活状态和块信息，NameNode维护数据块位置与副本情况。

客户端 ──询问“写到哪里”──▶ NameNode
  │                            │
  ◀──────返回节点位置──────────┘
  │
  └────数据流────▶ DataNode 1 ──副本流水线──▶ DataNode 2 ──▶ DataNode 3

读取时类似：客户端先问 NameNode 文件块在哪里，然后直接从相应的 DataNode 读取内容。

4.4 坏了一台服务器会怎样？

NameNode 会通过心跳及块报告发现某个 DataNode 不可用。只要对应块还有健康副本，客户端通常还能从其他节点读取数据，系统还可以按策略补足副本。

但要区分两种故障：

• DataNode 坏了：主要影响局部数据副本与可用容量。
• NameNode 坏了：如果只有一个 NameNode，元数据服务可能不可用；生产环境需要考虑 Active/Standby 等高可用方案。

另外，副本不是备份的同义词。误删除、权限误操作、软件 Bug 仍可能影响所有副本，重要数据还需要备份、快照和恢复策略。

4.5 HDFS 跟平时使用的磁盘有什么区别？

HDFS 比较适合顺序读写大文件，而不是把它当成高并发事务数据库。它通常不适合直接承载海量细小文件，也不提供 MySQL 那样的 SQL 事务能力。

记住一句话：HDFS 是跨机器保存文件的系统，不是一个数据库。

---

5. YARN：让不同计算程序共享一批服务器

5.1 YARN 是什么软件？

YARN（Yet Another Resource Negotiator）是 Hadoop 的集群资源管理系统。它也是能安装、启动的服务体系，核心组件用 Java 实现。

假设同一批服务器要运行十个计算任务。如果大家都抢 CPU 和内存，机器可能被挤爆。YARN 的作用就是协调“谁能在哪台机器上用多少资源”。

5.2 启动后有哪些角色？

            ResourceManager
         （全局资源协调者）
                   │
      ┌────────────┼────────────┐
      ▼            ▼            ▼
 NodeManager   NodeManager   NodeManager
  工作节点 1     工作节点 2     工作节点 3
      │            │            │
 Container      Container      Container
（某个任务）     （某个任务）     （某个任务）

• ResourceManager（RM）：负责整个集群的资源分配。
• NodeManager（NM）：通常在每个参与计算的工作节点上运行，报告资源情况，负责启动、监视本机的任务容器。
• ApplicationMaster（AM）：每个应用/作业的协调者，负责为该作业申请资源、组织任务，并不是全局唯一常驻的“大老板”。
• Container：YARN 用于分配和隔离任务执行资源的单位；这里不是说它必须是 Docker 容器。

5.3 一个作业怎样借用机器？

1. 客户端把作业交给 ResourceManager。
2. YARN 为这个应用启动 ApplicationMaster。
3. ApplicationMaster 申请适合的计算资源。
4. ResourceManager 分配资源，NodeManager 在对应节点启动任务进程。
5. 任务运行，ApplicationMaster 收集进度；完成后释放资源。

YARN 不是计算引擎。 它决定“把工作安排到哪里运行”，具体数据怎么算，由 MapReduce、Spark 等框架负责。

---

6. MapReduce：它既是一套编程模型，也有能运行的框架

6.1 先纠正一个容易想错的画面

我们经常说“MapReduce 在每个计算节点运行”，但需要更准确地理解。

MapReduce 是一种批量并行计算模型，也是一套具体的软件框架。 经典 Hadoop MapReduce 的实现主要是 Java，开发者可以编写 Map 和 Reduce 的逻辑，提交到集群执行。

不过，在现代 Hadoop 的 YARN 模式下，并不是每台机器上长期运行一个叫 MapReduce 的独立守护进程，然后它们自己做所有工作。典型情况是：NodeManager 常驻，MapReduce 作业提交后再启动对应的 ApplicationMaster 和 Map/Reduce 任务进程。

补充一段历史：在 Hadoop 1.x 的旧架构里，曾经使用 JobTracker / TaskTracker 作为 MapReduce 的主从服务角色；到了 Hadoop 2.x 及之后的 YARN 架构，资源调度被拆到 ResourceManager、NodeManager，作业协调改由 ApplicationMaster 负责。

不能把这两代架构混在一起画成一张“现代部署图”。

6.2 用“统计单词出现次数”理解 MapReduce

假设 HDFS 里有 100 个大文件，想统计全部文件中 error 出现了多少次。

Map： 每个任务读取自己分到的数据片段，输出类似：

(error, 1)
(error, 1)
(info, 1)
(error, 1)

Shuffle： 框架根据 Key 整理中间结果，将相同单词送到对应的 Reduce 任务。

Reduce： 把收到的 error 的次数加起来，写出最终结果。

HDFS 文件
   │
   ├──▶ Map Task 1 ──┐
   ├──▶ Map Task 2 ──┼──▶ Shuffle / Sort ──▶ Reduce Task ──▶ HDFS 结果
   └──▶ Map Task 3 ──┘

6.3 真正运行时发生了什么？

1. 开发者打包好 MapReduce 作业并提交。
2. YARN 启动作业专属的 MRAppMaster。
3. MRAppMaster 组织输入切分、申请资源并安排 Map/Reduce Task。
4. 工作节点上的任务进程从 HDFS 读取对应的数据；Map 输出通常会落到执行节点的本地磁盘供 Shuffle 使用。
5. Reduce 拉取需要的中间数据，完成汇总，把输出写到 HDFS 等目标存储。

这里还有一个很重要的优化思路：尽量让计算靠近数据。如果工作节点 B 本来就存着需要的 HDFS 数据块，调度器会尽量考虑让相关任务在 B 或附近运行，从而减少不必要的跨网络搬运。

6.4 MapReduce 的局限

它适合大规模、明确边界的批任务，但传统框架在需要反复计算和多阶段处理中，通常会有较重的任务启动与中间数据 I/O 开销。这也是后来 Spark 等引擎受到欢迎的原因之一。

---

7. Hive：数据文件在 HDFS，为什么还能写 SQL？

7.1 Hive 是什么？

想象你已经把 10 TB CSV 或 Parquet 文件放在 HDFS 里。文件系统知道 /hospital/lab/2025/ 下有哪些文件，却不知道里面有 patient_id、item_code、value 这些列。

Apache Hive 是数据仓库软件。它提供表结构、SQL 接入与查询管理，让你可以把文件当作“表”来理解和查询。

Hive 不是一台神奇的数据库服务器，自己把所有 TB 级数据塞进内存。经典架构中，Hive 会与存储系统、元数据服务、计算引擎一起工作。

7.2 Hive 运行时有哪些组件？

         JDBC 客户端 / Beeline
                 │ SQL
                 ▼
          HiveServer2
          （SQL 接入服务）
              │      │
 查询元数据 ───┘      └── 生成/提交计算任务
       ▼                       ▼
Hive Metastore          Tez / Spark 等引擎
       │                       │
  元数据数据库                  │
（例如 MySQL）                  │
                               ▼
                           HDFS 文件

• HiveServer2：接收 SQL 的服务进程，支持 JDBC/ODBC 客户端连接。
• Hive Metastore：管理表名、列名、分区、存储位置等元信息的服务；它可以使用 MySQL 等关系型数据库保存这些元数据。
• 执行引擎：真正执行扫描、过滤、聚合的程序；不同 Hive 版本和部署中，可以使用不同执行引擎。
• HDFS / 对象存储：存放实际数据文件。

最容易误解的地方：Metastore 里的 MySQL 保存的通常是“表的说明书”，不是几十 TB 的业务数据本体。

7.3 一条 SQL 是怎么跑起来的？

例如：

SELECT item_code, COUNT(*)
FROM lab_result
GROUP BY item_code;

大致流程：

1. JDBC 客户端把 SQL 交给 HiveServer2。
2. 查询服务读取 Metastore 中的表结构和文件位置。
3. 执行引擎将 SQL 转化为并行任务。
4. 工作节点读取 HDFS 中相关文件，进行分组和计数。
5. 查询结果返回给客户端。

因此可以这样记忆：Hive 负责让人用 SQL 理解和管理大规模数据，底层文件系统负责存储，计算引擎负责干活。

---

8. Spark：为什么说它是“计算引擎”？

8.1 Spark 是什么软件？

Apache Spark 是一套分布式计算框架，核心主要由 Scala/Java 生态实现，既支持 Scala、Java，也提供 Python、SQL 等使用接口。

Spark 不负责替你建一个 HDFS，也不是非得依赖 Hadoop 才能运行。它可以运行在 Standalone、YARN、Kubernetes 等环境里，从 HDFS、对象存储、数据库等数据源读取数据。

8.2 Spark 启动后有哪些角色？

            Spark Driver
       （你的作业协调进程）
                 │
        申请执行资源 / 分发任务
                 │
    ┌────────────┼─────────────┐
    ▼            ▼             ▼
Executor 1   Executor 2    Executor 3
（JVM）       （JVM）        （JVM）
   │            │             │
 Task         Task          Task

• Driver：运行用户程序的协调逻辑，生成执行计划、调度任务、追踪执行结果。
• Cluster Manager：分配资源，可以是 Spark Standalone 自己的管理器、YARN 或 Kubernetes。
• Executor：为 Spark 应用启动的工作进程，实际执行 Task，并可缓存数据。
• Task：被分发到 Executor 执行的最小工作单元之一。

8.3 走一遍 Spark SQL 的执行过程

假设用 Spark 统计上亿条检验数据的平均值：

1. 开发者提交一个 Spark 程序或 SQL。
2. Driver 构建逻辑与物理执行计划，形成可以并行运行的阶段。
3. 集群管理器分配 Executor 资源。
4. Driver 把 Task 分发给各 Executor。
5. Executor 并行扫描数据、执行过滤与部分聚合；必要时通过 Shuffle 交换数据。
6. 结果返回 Driver 或写入目标存储。

Spark 的优势之一是能够缓存中间结果，减少某些迭代任务的重复读取。但它并不是“只用内存、不碰磁盘”，Shuffle、缓存溢出等场景照样可能产生磁盘 I/O。

8.4 Spark 与 Hive 到底是什么关系？

Hive 主要提供数据仓库、元数据和 SQL 语义层能力；Spark 主要负责执行计算。Spark SQL 也可以直接读取 Hive Metastore，查询同一批存储文件。

两者能协作，不意味着必须捆绑部署。

---

9. Flink：一条永远不停止的数据流水线，谁在管理？

9.1 Flink 是什么？

Apache Flink 是分布式数据处理引擎，尤其擅长长时间运行、不断接收新数据、需要维护状态的任务。

比如：

• 订单系统每秒产生新的交易事件；
• 数据库不断发生新增和修改；
• 平台希望实时计算过去五分钟内的事件统计。

它并非只能做实时流，Flink 也支持有界数据的批处理。

9.2 Flink 集群有哪些进程？

           Flink Client
          （提交作业）
                │
                ▼
           JobManager
     （调度任务、协调 Checkpoint）
                │
     ┌──────────┼──────────┐
     ▼          ▼          ▼
TaskManager  TaskManager  TaskManager
   JVM          JVM          JVM
    │            │            │
 Slot / Task   Slot / Task   Slot / Task

• Client：将程序或 SQL 转换成可执行作业并提交。它通常不是长驻在集群里负责执行任务的进程。
• JobManager：统一协调作业调度、任务失败处理、检查点和恢复。
• TaskManager：执行实际的 Source、计算算子和 Sink 任务。典型实现是 JVM 进程。
• Task Slot：TaskManager 用于资源分配和任务调度的槽位概念，不是一台单独的服务器。

Flink 可以直接在机器上部署，也可以由 Kubernetes、YARN 等环境管理运行。

9.3 用“持续统计”走一遍 Flink 数据流

Kafka 中的新事件
       │
       ▼
 Source 任务（读）
       │
       ▼
 Filter 任务（过滤）
       │
       ▼
 Window 任务（按时间窗口累计）
       │
       ▼
 Sink 任务（写 Doris）

这些算子可以拆成多个并行子任务，分布在不同的 TaskManager 上。只要作业持续运行，新事件就会不断进入，统计结果随之更新。

9.4 State 与 Checkpoint 到底保存什么？

假设一条任务要统计某患者最近一小时的检验事件数量。为了计算下一条记录，程序需要知道过去已经累计了多少，这部分就是状态（State）。

如果 TaskManager 突然宕机，光重新启动 Java 进程是不够的，还需要恢复之前的计算状态。**Checkpoint（检查点）**就是 Flink 定期制作的、一组相互一致的分布式状态快照。故障发生时，任务可以从成功完成的检查点恢复。

但请记住：Flink 能恢复自己的计算状态，不等于外部 Oracle、MySQL、Doris 的所有操作天然具备端到端精确一次语义。 还要看 Source 和 Sink 的具体实现。

9.5 什么叫“Flink 生态”？

生态就是围绕一个核心产品形成的工具和项目集合：

• Flink Runtime：核心运行引擎；
• Flink SQL / Table API：用 SQL 或表模型描述计算；
• Flink Connector：从数据库、Kafka 等地方读取数据或写入数据；
• Flink CDC：基于 Flink 生态实现数据库全量与变更同步；
• Flink Kubernetes Operator：协助在 Kubernetes 上部署和管理 Flink 作业。

其中 Flink CDC 不是 Flink 的另一个名字，它侧重数据库数据同步；Flink 本身是更通用的计算引擎。

9.6 Hadoop 周边的管理软件：不是 Hadoop 核心进程

过去的 Hadoop 生态还经常出现 Apache Ambari、Apache Bigtop、Cloudera Manager / CDH、HDP、Hue 等名称。它们并非 HDFS 或 MapReduce 的另一种名字。

• Ambari：一套带 Web 管理界面的集群管理软件，管理端与节点 Agent 配合，协助安装、配置、启停和监控 Hadoop 组件；在新项目中应核对维护与版本适配情况。
• Bigtop：主要提供 Hadoop 相关项目的打包、测试和集成工具，不是替代 NameNode 的服务。
• Cloudera Manager / CDH、HDP：商业 Hadoop 发行版及运维管理相关产品和历史产品线，用于把大量组件打包、管理起来。
• Hue：带 Web 界面的交互工具，帮助开发者编写 SQL、浏览文件与数据。它是入口界面，不负责在所有工作节点执行 Map 任务。

可以简单地记成：Hadoop 核心负责存储和执行，周边平台帮助我们安装、管理和操作它们。 构建 SeaTunnel 或 Doris 系统，不需要先拥有整套 Hadoop 生态。

---

10. 数据采集工具：它们到底是怎么“跑”起来的？

现在再看 SeaTunnel、DataX 等工具，就容易理解了：它们大多是在执行读取任务 → 处理或传递记录 → 执行写入任务。

先认识四个常见词：

Source（数据输入） → Transform（转换） → Sink（数据输出）
     ▲                                      ▲
     └──────── Connector（连接器）───────────┘

• Source：负责从 Oracle、MySQL、Kafka 等获取记录；
• Transform：负责过滤字段、修改格式等转换；
• Sink：把记录写往数据库、文件或消息队列；
• Connector：实现“如何连接某种数据源”的插件。

这里的 Sink 原意是“水槽”，在数据领域就是输出端。它是工作职责，不等同于“必须是一台数据库服务器”。

10.1 DataX：启动一个离线同步作业

DataX 是阿里巴巴开源的离线数据同步框架，核心实现基于 Java，通常通过 Python 启动脚本调用 Java 程序。它的开源版经典形态以单机进程内多线程并发完成同步，而不是默认自带一个像 Hadoop 那样的多节点资源管理集群。

你写一份任务配置，说明：

• 从哪张 Oracle 表读取；
• 写到哪张 MySQL 表；
• 使用什么 Reader、Writer；
• 需要多少并发。

运行过程可以想象成：

DataX Job（本机 Java 进程）
          │
       拆分 Task
          │
     ┌────┴────┐
     ▼         ▼
   Task 1    Task 2       ……
     │         │
   Reader    Reader
     ▼         ▼
   Channel   Channel     （缓冲、限速、传输）
     ▼         ▼
   Writer    Writer
     │         │
     └────┬────┘
          ▼
        MySQL

它最像一个现成的、可配置的批量搬运程序。 不必先架设 Hadoop 集群。它很适合在实验中作为手写 Python / Java 抽取器的对照组。

10.2 Apache SeaTunnel：专门执行数据同步任务的引擎

Apache SeaTunnel 是一套真正可以部署的数据集成软件，不是一份 JDBC 工具包。它提供连接器、转换组件和任务执行机制。

使用自身 Zeta Engine 时，可以理解为：有负责协调作业的 Master/Coordinator 逻辑，也有实际运行 Source、Transform、Sink 任务的 Worker 逻辑。既可以进行小规模部署，也可以按需求扩展到多节点执行。

               SeaTunnel 客户端
              （提交作业配置）
                      │
                      ▼
           Zeta Coordinator / Master
             （计划、调度、恢复）
                      │
             ┌────────┴────────┐
             ▼                 ▼
          Worker 1          Worker 2
          ┌──────┐          ┌──────┐
Oracle ──▶│Source│          │Source│◀── Oracle
          └──┬───┘          └──┬───┘
             ▼                 ▼
          Transform         Transform
             ▼                 ▼
          MySQL Sink        MySQL Sink

以上是理解职责的逻辑图，不是要求每个 Worker 都必须同时包含一整条 Source→Sink 流水线。实际任务如何切分、部署，要看执行计划和配置。

SeaTunnel 的 Zeta 引擎可以管理任务切分、资源、状态和检查点；其连接器负责具体数据库的读取和写入。部分场景也可以接入 Flink 或 Spark 执行体系，所以使用 SeaTunnel 不等于必须另外安装 Flink。

对我们最重要的问题是：它能不能在 Oracle 11g、弱网和缺索引的大表环境里可靠抽取？ 这需要 PoC 验证，而不能从“支持 Oracle JDBC”直接推导出“故障恢复一定没问题”。

10.3 Apache NiFi：拖拽数据流，后台运行 Processor

Apache NiFi 是可视化的数据流管理软件，核心运行时基于 JVM。安装后，可以打开 Web 界面，把一系列 Processor 连接起来。

数据库 Processor ──▶ 过滤 Processor ──▶ 文件/数据库 Processor
                      │
                 Connection 队列

• Processor：实际执行读取、转换、路由、写入的组件；
• FlowFile：在流程里流动的数据对象，包含内容及属性；
• Connection：连接 Processor 的队列，可设置积压阈值，触发背压（Backpressure）；
• Flow Controller：在 NiFi 进程中安排 Processor 的执行。

如果下游 MySQL 写得慢，队列会积压，NiFi 可以据此减缓上游处理速度。这比自己在 Java 里到处写线程池和阻塞队列更直观。

NiFi 适合医院 A 给数据库、医院 B 给 CSV、医院 C 给 HTTP API 的复杂接入环境。它的优势是流程编排和可观察性，而不是保证任意复杂 SQL 都能跑得比 SeaTunnel 快。

10.4 用一张表看清三个工具的运行形态

产品	你实际要运行什么	最像什么	适合先研究的场景
DataX	主要是每个离线作业对应的 Java 执行进程及线程	批量数据搬运程序	Oracle → MySQL 离线抽取
SeaTunnel	任务提交入口、连接器、Zeta 执行引擎及 Worker	可扩展的数据同步执行平台	大量任务、并行同步、恢复
NiFi	一个或多个 JVM 服务、Web UI、Processor 与队列	可视化数据流编排平台	数据源协议复杂、流程常变

它们可以同时涉及采集、传输和转换，不是“采集层每次必须装一个，传输层还要再装一个”。

---

11. Kafka：数据为什么要先进一个“中转站”？

11.1 Kafka 是什么软件？

Apache Kafka 是分布式事件流平台，通常表现为一个由多个 Broker 服务组成的集群，以及向其中写入、从中读取的客户端。

它可以当作一种可持久化的“消息中转站”，但与传统只做即时交付的队列不同，Kafka 还会按照保留策略保存事件日志，消费者可以在允许的范围内重新读取历史事件。

11.2 运行中的 Kafka 长什么样？

生产者 Producer
    │  写入事件
    ▼
 ┌────────────────Kafka 集群────────────────┐
 │ Broker A        Broker B        Broker C │
 │ Topic 分区 0     Topic 分区 1     副本等   │
 └──────────────────┬─────────────────────┘
                    │
             消费者 Consumer
           （读事件并处理）

• Producer：往 Kafka 发消息的应用；
• Broker：Kafka 服务端进程；
• Topic：一类事件的逻辑名称，例如 lab-events；
• Partition：Topic 的分区，Kafka 用它分散存储和并行处理；
• Consumer Group：一组协作消费分区的消费者实例；
• Offset：消费者读取日志时用到的分区内位置。

Kafka 当前还涉及 KRaft 等集群元数据管理机制；对入门者先理解 Broker、Topic、Partition 与消费组就足够了。

11.3 为什么不让 Source 直接写数据库？

假设医院系统持续产生大量新记录，而 Doris 在某一时刻正在维护或写入较慢。

没有中间缓冲时，源端与目标端耦合得很紧；有了 Kafka，可以先将事件持久化，消费者按自己的能力继续处理。这有助于缓冲、解耦、重放和多消费者订阅。

但 Kafka 并不是必须的：一次性 Oracle 历史快照 → MySQL，如果 SeaTunnel 已能可靠直连写入，硬塞 Kafka 只会多出 Broker、磁盘、Topic、消费者和运维工作。

同类技术：Apache Pulsar 也是消息与流平台，拥有不同的架构和存储组织方式。入门时先掌握 Kafka 的角色模型，再比较差异更容易。

---

12. CDC：到底是谁在“盯着数据库”？

12.1 CDC 是技术方式，不是一个软件名称

**CDC（Change Data Capture，变更数据捕获）**表示识别并传递数据库发生的增、删、改变化。

常见方式包括：

1. 定时 SQL 查询：例如查 updated_at 晚于上次位置的记录；
2. 事务日志 CDC：读取 MySQL Binlog、Oracle Redo Log 等相关变更信息。

日志 CDC 可以减少反复扫描业务表的需要，但需要权限、日志保留、数据库配置与连接器支持，不等于“绝对零开销”。

12.2 Debezium 真正部署在哪里？

Debezium 是专注数据库变更捕获的软件项目，最常见的部署方式是作为 Kafka Connect 的 Source Connector 运行。

MySQL
  │ 写业务数据
  ▼
Binlog（事务日志）
  │
  ▼
Kafka Connect Worker 进程
  └── Debezium Connector / Task
              │
              ▼
         Kafka Topic
              │
              ▼
       下游消费者 / Doris

这里要特别区分：

• Kafka Broker：保存消息的服务；
• Kafka Connect Worker：负责运行 Connector 任务的服务；
• Debezium Connector：真正懂得怎样读取某种数据库变更的插件。

三者不是同一个程序。 Debezium 也有不同于 Kafka Connect 的运行方式，因此上图只表示最经典、最容易理解的架构。

12.3 Flink CDC、Canal、Maxwell 又是什么？

• Flink CDC：围绕 Flink 运行与数据同步能力构建的数据库采集工具，适合需要与流计算衔接的场景。
• Canal：主要关注 MySQL Binlog 解析，把变更事件交给下游系统。
• Maxwell：较轻量的 MySQL Binlog 采集工具，通常把变化转为 JSON 等事件输出。
• Kafka Connect：运行各种 Source/Sink Connector 的框架，本身并不等于 CDC。

12.4 为什么当前医疗项目不急着上 CDC？

我们手里的数据源是一份截至某个时点的 Oracle 11g 静态镜像。它不持续产生新的业务记录，就没有持续消费变更日志的必要。

而且，Oracle 11g 对不少现代 CDC 工具而言涉及版本兼容限制。产品介绍写着“支持 Oracle”，不代表它正式支持所有旧版本数据库。

因此现在应优先验证全量快照采集。如果未来医院提供定期更新的镜像，可以研究两次快照的比对、补采；只有在具备合适的在线数据库、权限和日志条件时，才进一步考虑日志 CDC。

12.5 如果数据来自日志文件或 HTTP 接口呢？

除了数据库，还会遇到服务器日志、容器日志、CSV 文件以及第三方 HTTP API。这时负责“读取日志”的软件，和负责“解析数据库事务日志”的 CDC 软件不是一个概念。

产品	它是什么、跑在哪里	如何工作
Fluent Bit	通常部署在应用服务器或容器节点上的轻量级代理，核心实现以 C 语言为主	从日志文件、系统日志等读取记录，解析、过滤，再发送到下游
Filebeat	Elastic 生态的轻量级日志采集程序（Go 实现）	在服务器上跟踪文件的新增内容，把记录发往 Elasticsearch、Logstash 等目标
Apache Flume	传统 Hadoop 生态的日志采集系统，核心基于 Java	运行 Flume Agent，用 Source 接收、Channel 缓冲、Sink 发送
Apache NiFi	前面介绍过的 JVM 数据流平台	用 Processor 组合 HTTP、SFTP、数据库、文件等接入方式

Flume 的典型模型可以画成：

日志来源 → Flume Agent
               │
             Source
               │
             Channel（缓冲）
               │
              Sink → HDFS 等目标

请注意：Flume Agent 里的 Sink 是它这个采集程序的输出端，和 SeaTunnel Sink 是同一类抽象概念，不代表二者是同一个插件。

这类工具主要解决日志、事件和多协议数据的接入；对 Oracle 大表按业务键读取，应优先研究 JDBC 类采集工具。

---

13. 数据如何保存：MySQL、HDFS、对象存储与数据湖

13.1 MySQL 和 HDFS 不是竞争关系

• MySQL：数据库服务，管理表、索引和事务，适合业务读写。
• HDFS：分布式文件系统，主要管理文件和块，适合大规模文件存储。

HDFS 里面可以保存 CSV、Parquet、ORC 等数据文件，但HDFS 自己并不负责解析 SQL 并返回 SELECT 结果。

13.2 对象存储是什么？

对象存储可以把数据作为对象保存，通过 S3 等 API 访问。例如 MinIO 或云厂商的对象存储服务。

从使用方式看，它与本地目录和 HDFS 的文件系统接口不同。典型对象存储更强调对象、Bucket、Key。在数据湖架构中，很多计算引擎都可以读取对象存储上的 Parquet 等文件。

不要把“对象存储”误解成“一定比 HDFS 快”或“只有云上才能用”；它们取舍依赖数据量、运维方式、成本以及读写工作负载。

13.3 Parquet / ORC 是什么？数据湖表格式又是什么？

这是新手非常容易混淆的一组概念：

• Parquet、ORC：主要是文件格式，规定数据在文件里怎样按列编码、压缩和组织。
• Iceberg、Hudi、Paimon：主要是数据湖表格式或表管理技术，帮助管理一组数据文件及其元数据、快照、变更和表级操作。
• HDFS、S3 兼容对象存储：负责实际存放文件。
• Spark、Flink、Trino 等：可以作为读取或处理这些数据的计算/查询引擎。

Spark / Flink / Trino（读取和计算）
                │
   Iceberg 等表格式（管理表）
                │
   Parquet 等文件格式（保存内容）
                │
 HDFS / 对象存储（放置文件）

不要把 Iceberg 当成另一台必须启动的数据库服务器。它主要定义表如何通过元数据和数据文件组织起来；不同部署还会有 Catalog 等配套服务。

---

14. OLAP 数据库：Doris 和 ClickHouse 究竟运行了哪些东西？

14.1 先理解 OLTP 与 OLAP 的区别

**OLTP（联机事务处理）**更擅长记录和维护日常业务：新增订单、修改账户、按主键读取少量数据。

**OLAP（联机分析处理）**更关心大范围的统计与检索：某五年时间段内，各年龄组有哪些诊断及异常指标？

维度	OLTP	OLAP
主要任务	日常业务事务	聚合、过滤、多维分析
典型查询	按主键查一行或少量记录	扫描大量记录、计算统计值
常见存储组织	行存	列存，但不绝对
常见产品	MySQL、PostgreSQL、Oracle	Doris、ClickHouse、StarRocks

区别是设计目标，不是 SQL 语法。 MySQL 完全可以 GROUP BY，而且索引恰当时也很快。是否需要 OLAP 引擎，要看实际工作负载。

14.2 为什么列式数据库经常很快？

想象一张有 100 列的表，你只需要 age 和 gender 两列来统计。

行存倾向于把一行的各个列放在一起，适合一次拿到整条业务记录；列存倾向于把同一列的数据组织在一起，因此可以减少读取无关字段的开销。

配合下面几种机制，能进一步加速：

1. 列裁剪和压缩：只读需要的列，同列相似值便于压缩；
2. Min-Max / Zonemap：先看数据块的范围，跳过不可能命中的块；
3. 字典、Bitmap、倒排索引：减少字符串比较或快速找到符合条件的记录集合；
4. 向量化执行：一次处理一批数值，减少逐行调度开销；
5. 排序键、分区与数据跳过：尽量把相关数据放得更近，缩小扫描范围。

这些优化并非所有引擎、所有表都会自动同时使用。尤其“向量化”和 SIMD 不是同一回事：前者是批量执行方式，后者是CPU 指令级并行能力。

14.3 Doris 是什么？启动之后有哪些进程？

Apache Doris 是一套可以直接接收 SQL、保存分析数据并执行分布式查询的 OLAP 数据库软件。 它不是简单的 MySQL 插件。

经典的存算一体部署主要分为两类进程：

 MySQL 客户端 / BI / Java JDBC
             │ SQL
             ▼
       Doris FE
  （FrontEnd 前端）
解析 SQL、管理元数据
生成和协调查询计划
             │
   ┌─────────┼─────────┐
   ▼         ▼         ▼
Doris BE  Doris BE   Doris BE
保存数据   保存数据    保存数据
执行计算   执行计算    执行计算

• FE（Frontend）：负责 SQL 接入、解析和规划，管理库表等元数据，并协调分布式查询；FE 主要由 Java 实现。
• BE（Backend）：负责存储数据分片和执行查询计算；经典 BE 核心主要由 C++ 实现。

一次查询流程：客户端向 FE 提交 SQL → FE 生成执行计划 → 多个 BE 并行扫描、过滤、聚合和交换部分结果 → 返回最终结果。

Doris 支持不同数据模型，例如 Unique Key 可以满足某些按键更新的需求。它也有存算分离架构，因此 FE/BE 本地多副本存储图是便于理解的经典形态，不代表所有部署方式。

14.4 ClickHouse 又是什么形态？

ClickHouse 也是分析型数据库软件，其服务端核心主要由 C++ 实现。安装后可以启动 clickhouse-server，它能处理 SQL 并保存 MergeTree 等表引擎的数据。

最容易理解的是单节点模式：

SQL 客户端 ──▶ ClickHouse Server
                   │
              MergeTree 表
            （列式数据文件）

多节点场景下，可以通过**分片（Shard）和副本（Replica）**组织数据，还可能使用 ClickHouse Keeper 等组件协调复制元数据：

      查询入口
         │
ClickHouse 节点
         │
 分布到多个 Shard
    │       │
 Shard A  Shard B
 多副本    多副本

它与 Doris 的 FE/BE 两类角色划分不完全相同。初学者不必强行把 ClickHouse 某个节点叫作 FE 或 BE。

14.5 Doris 与 ClickHouse 怎么选？

角度	Doris	ClickHouse
初学者先认识的部署角色	FE 协调 + BE 存储/计算（经典模式）	ClickHouse Server；按需组成分片与副本
常见优势场景	交互式多维查询、实时分析、复杂 SQL	日志、事件、时序、大规模聚合与分析
数据更新	可按表模型设计 Upsert	依表引擎与更新策略设计
学习重点	FE/BE、数据模型、分桶、索引	MergeTree、排序键、分片、副本

不能只凭“某系统支持 JOIN”或“不支持 JOIN”选型。二者都能做不少复杂查询，真正差别需要通过数据模型、SQL 和压测来判断。

14.6 Trino 和 Hive 为什么也出现在分析清单里？

Trino 是分布式 SQL 查询引擎，典型集群有 Coordinator 和多个 Worker，通过 Connector 访问外部数据源。它自己不是以本地管理一套业务数据为核心定位的 Doris 式存储型数据库。

SQL 客户端 → Trino Coordinator → Trino Workers → 各类数据源

Hive 更多承担数据仓库 SQL 和表管理角色，通常与底层文件存储、执行引擎配合。它们都是分析链路里的工具，但“分析工具”并不意味着底层架构必须相同。

---

15. 批量数据抽取：真正难的不是写 SELECT

前面认识了软件进程，现在回到最初的 Oracle 抽取问题。

15.1 ResultSet.next() 不一定是一条一次网络请求

Java 用 JDBC 逐行遍历 ResultSet，不意味着驱动必然每调用一次 next() 就走一次网络。实际可能由数据库驱动根据 fetchSize 等机制分批取回记录。

性能需要同时看 SQL 执行计划、索引、数据库 I/O、网络、批大小和写入端吞吐。

15.2 Offset 分页和 Keyset 分页

深度偏移分页可能需要反复跳过大量记录。如果有稳定唯一、适合索引访问的排序键，Keyset 往往更合适：

SELECT *
FROM lab_result
WHERE id > :last_committed_id
ORDER BY id;

这是展示核心思想的 SQL。实际每批还需要限制记录数；在 Oracle 11g 中可使用有序内层查询与外层 ROWNUM 等写法，而不是直接套用新版本的 OFFSET ... FETCH 语法。

没有适合的索引时，Keyset 可以降低逻辑断点复杂度，却不保证数据库能低成本定位下一页。

15.3 为什么 Checkpoint 和“写入成功”不是一回事？

假设原计划读取 1000 行：

1. Oracle 已经返回 800 行；
2. MySQL 只成功提交了 600 行；
3. 网络突然断开。

如果系统把断点记为 800，下次从第 801 行继续，就漏掉了 200 条数据。

一种稳妥的思想是：先让目标端确认提交，再推进已完成进度；遇到不确定的提交结果，先查询回执，再决定是否重试。

读取一个确定范围
       │
       ▼
写入目标端 / 提交事务
       │
       ▼
确认提交回执
       │
       ▼
推进完成进度

这就是为什么还需要学习幂等、At-Least-Once、Checkpoint、Exactly-Once。

• At-Least-Once（至少一次）：失败后可以重试，某些记录可能被再次处理；
• 幂等：同一份记录重复处理，不造成重复业务结果；
• Checkpoint：系统可恢复的内部进度或状态；
• Exactly-Once：在严格约定的系统边界内，最终效果相当于只处理一次。

不要因为工具介绍中写着“支持 Exactly-Once”，就以为它已经替医疗业务完成了患者归并、临床事实事务、血缘保存和 Doris 投影更新。

15.4 无索引大表，成熟工具也不能凭空修好

无论使用 Java、Python、DataX 还是 SeaTunnel，最终都需要 Oracle 执行查询。如果一张表没有合适索引，执行计划需要反复扫描大表，再优秀的传输引擎也无法凭空改变这一点。

因此应该先研究：

• 能否让筛选在 Oracle 源端完成；
• 能否避免针对每个患者重复扫描同一张大表；
• 是否有稳定分片键或合理的范围扫描策略；
• 是否有源表版本/快照的一致性保证；
• 是否会因为并发太高影响源库；
• 数据库和磁盘条件是否允许建设额外索引。

工具解决的是通用执行问题，源数据库的物理访问路径仍决定性能下限。

---

16. 医疗数据为什么还需要自己的 Java 业务处理层？

假设 SeaTunnel 已经把 Oracle 检验记录准确写入 MySQL 暂存表，我们能直接宣布“研究数据已经准备好”吗？未必。

因为医疗数据还有专门的业务语义：

• 两个系统里的患者标识是否指向同一个人？
• 这条检验结果属于哪次就诊、哪份报告？
• 数值和单位是否统一？
• 某个疾病诊断与某个检验指标是否必须发生在同一次就诊？
• 这条研究事实来自哪张源表、哪个源记录、哪轮处理规则？

16.1 患者级与就诊级是两个不同问题

例如患者 2023 年诊断糖尿病，2025 年另一次就诊发生血糖升高。

检索“糖尿病 AND 血糖升高”：

• 患者级 AND：两项条件在患者历史上分别出现即可；
• 就诊级 AND：必须同一次就诊满足才算命中。

到底哪一个正确？取决于产品定义。通用数据同步框架不知道医生究竟想表达哪种含义。

16.2 一个更合理的职责拆分

医院 Oracle 11g 历史镜像
          │
          ▼
  SeaTunnel / DataX
 （通用数据采集和搬运）
          │
          ▼
   受控暂存区 / 来源证据
          │
          ▼
 Java 医疗领域处理服务
 （身份、事实、标准化、血缘、幂等）
          │
          ▼
  MySQL 业务数据 / Outbox
          │
          ▼
     Doris / 查询投影
          │
          ▼
    智能检索 / 研究分析

这个图表达的是一种可验证的候选架构，不是已经选定的最终实施方案。暂存区会增加存储、隐私和生命周期管理成本，也必须避免它与已有的证据存储重复。

通用框架负责把数据尽量可靠地搬过来；业务系统负责让数据具有正确的临床含义。 这就是复用成熟软件与保留自研价值之间的边界。

16.3 数据批次版本，也不能代替就诊关系

再补一个工程里很容易混淆的概念：抽取版本号可以表示“哪次导入的数据”“用了哪套标准化规则”，有助于重放与排查；但它不能表示患者的一次就诊或一份检验报告。

同一抽取批次里可能包含该患者几十次就诊、上百份报告。若要表达“同一次就诊的诊断与检验”，仍然需要可靠的就诊 ID、报告 ID、来源业务键及其关联关系。

因此，“数据来源和处理版本”与“临床事件之间的关联”，是两条不同维度的线索。

---

17. 一次完整的实战推演：从 Oracle 到智能检索

为了把前面的名词连起来，我们假设建设一个仅处理离线历史快照的专病数据平台。

第一步：选择采集方式

因为 Oracle 数据已经冻结，优先选择 JDBC 全量/范围抽取，而不是直接部署 CDC。

第二步：执行抽取任务

SeaTunnel 从配置中读取 Oracle 连接信息和查询条件；Zeta 引擎安排 Source 任务；Source 读取记录并交给目标端 Sink。

这一阶段关注 SQL 执行计划、分片、网络超时、失败恢复与目标端幂等。

第三步：写入受控存储

可以先写入 MySQL 暂存区，保留必要的来源键、抽取批次和追溯信息；根据合规要求进行访问控制、加密、脱敏、保留与清理。

第四步：Java 领域服务加工

医疗领域服务把来源患者、就诊、报告、检验项目整理成可用事实，并以业务事务保障身份映射、标准值、血缘和回执的一致性。

第五步：建立分析层

根据实际 SQL 和性能测试，决定继续优化 MySQL，还是将分析投影写入 Doris 等 OLAP 数据库。

第六步：向医生提供检索

医生选择患者年龄、诊断和检验条件，应用生成具有明确患者级/就诊级语义的查询，并返回可追溯的结果。

请注意：在这条离线链路里，完全可能不需要 Kafka、Flink、HDFS。 当你真的出现持续变更、大规模流处理或数据湖存储需求时，再按问题引入对应软件。少装几个组件，不代表技术落后。

---

18. PoC：如何验证一个产品是否真的适合？

PoC（Proof of Concept，概念验证） 是正式重构或引入技术前，先进行的小范围可行性实验。

它与 Demo（展示效果）、MVP（最小可行产品）不一样：PoC 主要回答“技术在我们的条件下能不能成立”。

针对 SeaTunnel，可以设计这样一个小实验：

1. 选择一张脱敏的 Oracle 检验表，固定患者范围和抽取量；
2. 用 SeaTunnel 抽取到隔离的 MySQL 测试表；
3. 记录抽取耗时、源库负载、网络流量和目标端吞吐；
4. 主动断网、重启进程，检查恢复位置；
5. 按来源业务键核对漏数、重复与内容一致性；
6. 与现有 Python/Java 脚本比较性能及部署维护成本。

Benchmark（基准测试） 则更侧重吞吐、延迟和资源消耗。PoC 可以包含 Benchmark，但还需要验证正确性与恢复能力。

---

19. 一张“软件运行形态”速查表

产品 / 技术	它到底是什么	通常如何运行或协作	最主要用途
Hadoop	包含多模块的软件项目与生态	HDFS、YARN、MapReduce 等配合	分布式存储与计算基础
HDFS	分布式文件系统	NameNode 管元数据；DataNode 保存文件块	保存大规模文件
YARN	集群资源管理系统	ResourceManager、NodeManager、ApplicationMaster	安排计算资源
MapReduce	编程模型及执行框架	作业协调者分派 Map/Reduce 任务	离线批量计算
Hive	数据仓库 SQL 与元数据软件	HiveServer2 + Metastore + 执行引擎 + 存储	管理、查询海量表数据
Spark	分布式计算引擎	Driver 向 Executor 分发 Task	批量、SQL、迭代等计算
Flink	分布式批流计算引擎	JobManager 调度 TaskManager	有状态实时处理、批处理
DataX	离线数据同步框架	单机作业进程及并发 Reader/Writer 线程	批量数据库同步
SeaTunnel	数据集成软件平台	Source/Transform/Sink + Zeta 执行引擎等	批流数据集成
NiFi	可视化数据流系统	JVM + Web UI + Processor + 队列	多协议流程编排
Kafka	分布式事件流平台	Broker 保存 Topic 分区；生产者写、消费者读	缓冲、解耦、事件传输
Debezium	CDC 连接器与平台	常作为 Kafka Connect Task 运行	捕获数据库变更
Flink CDC	数据库同步工具	在 Flink 体系中执行相关采集同步	全量与增量同步
Doris	分析型数据库	经典 FE/BE 进程分工	交互式 OLAP 查询
ClickHouse	分析型数据库	ClickHouse Server；按需配置分片副本	大规模分析、聚合
Trino	分布式 SQL 查询引擎	Coordinator + Workers + Connectors	跨数据源查询
Iceberg	数据湖表格式	元数据、快照与文件配合计算引擎	以表方式管理湖中数据

表格是帮助建立第一印象的简化模型。同一产品在不同版本、单机/集群、容器/物理机和不同配置下，部署进程会有所差异。

---

20. 结语：看到新名词，先问它“住在哪里、干什么”

回头看，所谓大数据平台，其实就是许多软件合作完成一条数据链路：

• HDFS 告诉我们，文件可以分散在多台机器上保存；
• YARN 告诉我们，资源可以由统一的调度系统分配；
• MapReduce、Spark、Flink 告诉我们，计算可以拆成很多任务并行执行；
• DataX、SeaTunnel、NiFi、Debezium 告诉我们，数据可以由现成的采集与集成工具搬运；
• Kafka 告诉我们，事件可以在生产者与消费者之间持久化、缓冲和重放；
• Hive、Trino、Doris、ClickHouse 告诉我们，查询海量数据可以有不同的存储和计算组织方式。

以后再遇到一个新产品，不妨先问五个问题：

1. 它是什么？ 是一个概念、库、独立程序，还是一整套软件？
2. 它在哪里运行？ 单机、集群、容器，还是作为别人的插件？
3. 谁和谁协作？ 有哪些管理进程、工作进程和存储组件？
4. 数据怎么走？ 从哪里进入、在什么地方处理、最后写到哪里？
5. 解决了什么实际问题？ 如果不引入它，需要付出什么代价？

当这些问题能回答清楚，产品名称就不再是需要死记硬背的术语，而是一组可以在脑海里运行起来的软件。

学习大数据，不是收集更多技术名词，而是逐渐看清它们怎样工作、怎样协作，以及什么时候根本不需要它们。

官方资料与进一步阅读

• Apache Hadoop：单机部署与进程
• Apache Hadoop：HDFS 用户指南
• Apache Hadoop：YARN 架构
• Apache Hadoop：MapReduce Tutorial
• Apache Hive：HiveServer2
• Apache Spark：Cluster Mode Overview
• Apache Flink：架构
• Apache SeaTunnel：架构
• Apache SeaTunnel：Zeta 引擎
• Alibaba DataX：框架介绍
• Apache NiFi：架构与核心概念
• Apache Kafka：入门概念
• Debezium：运行架构
• Apache Doris：系统架构
• ClickHouse 官方文档
• Trino：基本架构