Kafka日志聚合与处理中Spark与Kafka Streams选型及高效方案咨询

不需要必须使用Spark作业，常规日志聚合过滤场景下仅用Kafka Streams即可实现。
两种技术的适用场景可以按需求划分：

• 如果你的需求仅为字段提取、无效日志过滤、格式转换（比如转换为Splunk兼容格式、按日志级别/服务名做路由）这类轻量操作，优先选择Kafka Streams：和Kafka生态原生打通，不需要额外部署独立计算集群，资源开销低，处理延迟可以做到毫秒级，维护成本远低于Spark。如果不想写代码，还可以用ksqlDB，直接通过SQL编写过滤、转换逻辑，开发效率更高。
• 只有当你需要实现复杂大窗口聚合、多流关联、状态计算、轻量机器学习推理这类重计算需求时，才有必要引入Spark作业。你的场景是日志过滤后输出到Splunk，绝大多数场景下Kafka Streams完全可以覆盖需求，不需要额外引入Spark技术栈增加复杂度。

可以从接入、处理、输出三层做标准化设计，实现新日志类型接入仅需少量配置、无需大幅改动代码：

• 统一接入层规范：预先定义全链路通用日志元数据规则，强制所有从S3、Kinesis等上游接入的日志，都通过连接器内置的转换能力补全log_source、log_type、generate_time、service_name四类通用元字段，统一输出为JSON格式，上游连接器仅需一套通用配置即可适配绝大多数日志源接入。
• 配置化处理层逻辑：将处理逻辑拆分为通用公共逻辑和自定义扩展逻辑两部分：
  • 公共逻辑：格式校验、敏感信息脱敏、通用字段补全、冷数据归档这类所有日志都需要执行的逻辑，开发一次全量复用，不需要针对新日志类型修改。
  • 扩展逻辑：不同日志的特殊过滤、转换规则全部配置化实现，将过滤字段、阈值、路由规则等参数存放在配置中心，新增日志类型仅需新增对应配置即可，不需要修改处理代码。如果使用ksqlDB做处理，可以预先编写SQL模板，新日志接入仅需替换模板变量即可快速上线。
• 统一输出层规则：预先定义输出到Splunk的标准化格式，以及通用的Kafka到Splunk的连接器配置，所有处理后符合标准格式的日志都可以直接通过统一链路输出，不需要为单种日志单独配置输出通道。
• 另外建议按日志类型做Topic隔离，不同类型的日志写入对应独立的Topic，通用处理逻辑可以批量消费所有Topic执行公共逻辑，特殊处理逻辑单独消费对应Topic即可，可扩展性更高。

内容的提问来源于stack exchange，提问作者Tabber