stream.flatmap本身是单机内存操作，不能替代分布式日志分析引擎；它仅在flink等框架中作为无状态解析算子，负责非结构化→半结构化转换，如日志行拆解、字段提取、嵌套展开与过滤。
Stream.flatMap 本身无法实现大规模分布式日志的全量实时搜索——它不是分布式引擎，也不具备索引、分片、倒排、跨节点查询等搜索能力。真正支撑全量实时搜索的是 Elasticsearch、Flink + Stateful 窗口 + 外部索引服务，或专用流式搜索引擎（如 RisingWave + OpenSearch）。flatMap 在其中只承担一个轻量但关键的角色：把原始日志行“拆开、解析、展开”成可搜索的事件粒度。
flatMap 的真实定位：日志解析层的“解包器”
在完整链路中，flatMap 不负责搜索，只负责让数据变得“可被搜索”：
- 将一行含多个操作的 JSON 日志（如用户会话日志）展开为多条独立事件（登录、点击、支付、退出）
- 从 Nginx 或 Spring Boot 的单行文本日志中，用正则提取 IP、路径、状态码、耗时、User-Agent，并构造结构化 LogEvent 对象
- 对嵌套异常堆栈（Caused by: … at com.xxx…）逐行拆解，每行生成一个 ExceptionLineEvent，带上下文字段（traceId、level、lineNo）
- 过滤掉空行、健康检查日志、调试日志等无关内容，减少下游索引压力
全量实时搜索依赖的三层协同架构
要达成“全量+实时+可检索”，需明确 flatMap 所在层级与其他组件的分工：
- 采集层（Kafka/Filebeat）：保障日志不丢、有序、低延迟入队；Filebeat 做初步过滤与字段打标
- 流处理层（Flink）：用 flatMap 解析 → keyBy(service, traceId) → 滚动窗口聚合指标 → 写入 ES 或 Hologres；同时用侧输出流（Side Output）分离脏数据、超长日志、加密字段
- 搜索层（Elasticsearch / OpenSearch）：接收 Flink 写入的结构化事件，建立倒排索引；支持全文检索、聚合分析、高亮、时间范围筛选；通过 IK 分词器支持中文日志关键词搜索
关键实现细节：让 flatMap 输出真正适配搜索
flatM ap 的输出质量，直接决定搜索的准确率和性能：
- 避免返回 null：使用 Optional.ofNullable(items).orElse(Collections.emptyList()).stream() 替代可能为空的集合流
- 统一时间字段命名：强制输出
timestamp（毫秒级 long）、log_time（ISO 格式字符串），便于 ES 自动识别 @timestamp - 保留原始行（raw_line）与解析后字段并存：既支持“全文检索原始报错信息”，也支持“按 status_code=500 精确过滤”
- 对敏感字段（如手机号、token）做脱敏再输出，防止 flatMap 后直接落库造成泄露
为什么不能跳过 Flink 直接用 Java Stream.flatMap？
因为本地 Stream.flatMap 运行在单 JVM 中：
- 无法消费 Kafka 分区数据，做不到水平扩展
- 无 checkpoint 机制，故障后无法恢复消费位点
- 不能维护 session 窗口、event-time 语义、keyed state
- 内存受限，面对 GB/s 级日志流会 OOM
