基础及入门（2）-流数据处理机制

Kafka 消息字节流
    ↓
JsonRowDeserializationSchema（内置 JSON 反序列化器）
    ↓
Flink 内部统一数据结构：RowData 对象
    ↓
字段映射：EVENT_NO / PATIENT_ID / CLINIC_DEPT_CODE / CLINIC_DOCTOR_CODE / REGISTER_TIME

• 'json.ignore-parse-errors' = 'true'：当某条 JSON 消息格式异常（字段缺失、类型不匹配）时，不抛异常、直接跳过这条消息，返回 null 行。这是生产环境防止脏数据崩溃任务的重要保护。
• 'scan.startup.mode' = 'group-offsets'：从消费者组记录的上次提交偏移量继续消费，任务重启后不会重复消费也不会丢失。
• 所有字段定义为 STRING：因为 Kafka 的 JSON 消息里 REGISTER_TIME 是字符串格式，Flink 在 Source 阶段不做类型转换，保留原始字符串，转换推迟到计算层处理。

SQL 文本
  → Parser（语法解析）→ AST 抽象语法树
  → Validator（语义校验）→ 检查字段是否存在、类型是否合法
  → Planner（优化器，基于 Calcite）→ 逻辑执行计划 → 物理执行计划
  → 生成算子 DAG 图（JobGraph）
  → 提交到 TaskManager 执行

WHERE REGISTER_TIME IS NOT NULL
  AND CLINIC_DEPT_CODE IS NOT NULL 
  AND CLINIC_DOCTOR_CODE IS NOT NULL

CAST(SUBSTRING(REGISTER_TIME, 1, 10) AS DATE) AS dim_date

• SUBSTRING(str, start, length)：字符串截取，从 "2024-01-15 08:30:00" 截取 "2024-01-15"。
• CAST(... AS DATE)：显式类型转换，将字符串转为 Flink 内部的 DateData（实际存储为距离 epoch 的天数整数）。

GROUP BY CAST(SUBSTRING(REGISTER_TIME,1,10) AS DATE), CLINIC_DEPT_CODE, CLINIC_DOCTOR_CODE

每来一条新数据（dim_date=2024-01-15, dept=001, doctor=D01）
  → 计算分组 Key 的哈希值
  → 查询 State Backend 中该 Key 的当前累加值（比如当前是 5）
  → 执行 SUM(1)：5 + 1 = 6
  → 将新值 6 写回 State Backend
  → 向下游 Sink 发出两条消息：
      撤回消息（Retract）：(-) [2024-01-15, 001, D01, 5]  ← 旧值无效
      插入消息（Accumulate）：(+) [2024-01-15, 001, D01, 6]  ← 新值生效

提交 SQL 时（编译期）：
  Validator 校验：发现 REGISTER_TIME 是 STRING，目标是 DATE
  → 检查是否有 CAST 表达式 → 有 → 校验通过

运行期（每条数据处理时）：
  Calc 算子对每条 RowData 执行：
    1. SUBSTRING("2024-01-15 08:30:00", 1, 10) → "2024-01-15"
    2. CAST("2024-01-15" AS DATE)
       ↓
       内部：DateTimeUtils.parseDate("2024-01-15")
       ↓
       转为 int：距离 1970-01-01 的天数（如 19737）
       ↓
       存储为 Flink 内部 DateData 类型

来自 GroupAggregate 的数据（含 Retract 消息）
  → Sink Buffer（内存缓冲区）
  → 满足以下任一条件触发 flush：
      ① 缓冲行数 ≥ sink.buffer-flush.max-rows（10000行）
      ② 距上次 flush ≥ sink.buffer-flush.interval（5000ms）
  → 序列化为 JSON 格式
  → HTTP POST → Doris FE 的 Stream Load 接口

• partial_update = 'true'：开启部分列更新模式。Doris 会根据主键（dim_date + dim_dept + name_employe_no 联合主键）查找已有行，如果存在则只更新 outp_cn 字段，不影响其他列。这正好配合了 Flink 的 Retract 机制——旧值被新值覆盖，实现了流式聚合结果的持续更新。
• Doris 内部会先将数据写入内存的 MemTable，达到阈值后 flush 成不可变的 Segment 文件，后台 Compaction 线程负责将多个小 Segment 合并成大 Segment，这就是为什么你查询 Doris 时数据会有短暂延迟的原因。