Kiro CLI + EKS MCP Server 实战：两种 Fluent Bit 日志落地 S3 Parquet 方案的完整技术对比

需求场景

EKS 上的应用产生 JSON 格式的埋点日志（页面浏览、点击、交易等），需要以 Apache Parquet 格式落地 Amazon S3，供 Athena、Spark、Redshift Spectrum 做离线分析。

Parquet 列式存储对比 JSON，存储成本和查询扫描成本可降低 60-90%。日活百万场景下，4GB/天 JSON 数据压缩到 400-800MB Parquet。

从 EKS 到 S3 Parquet 有两条主要路径，核心区别是 谁来做 JSON → Parquet 的转换。

方案 A：Fluent Bit 原生 Parquet 直写

架构：App Pod → Fluent Bit Sidecar (自编译 Arrow 镜像) → S3 (.parquet)

Fluent Bit S3 output plugin 支持 compression parquet 参数，但需要编译时启用 Apache Arrow（-DFLB_ARROW=On）。

关键步骤

  1. 多阶段 Dockerfile 编译（安装 libarrow-dev + libparquet-dev，约 15 分钟）
  2. 推送 ECR
  3. 创建 S3 bucket + IAM Policy + IRSA
  4. Sidecar 模式部署（App + Fluent Bit 共享 emptyDir）
  5. pyarrow 验证输出

Fluent Bit 配置

[OUTPUT]
    Name    s3
    Match   *
    bucket  eks-fluentbit-logs-<ACCOUNT_ID>
    region  us-west-2
    compression  parquet
    s3_key_format  /parquet-logs/%Y/%m/%d/%H/

方案 B：Fluent Bit → Firehose + Glue → S3

架构：App Pod → Fluent Bit (官方镜像) → Firehose (Data Format Conversion) → S3 (.parquet)

Firehose 根据 Glue Data Catalog 定义的 Schema 做 JSON → Parquet + SNAPPY 压缩。

关键步骤

  1. 创建 Glue Database + Table（声明 Parquet Schema）
  2. 创建 Firehose Delivery Stream（开启 DataFormatConversion）
  3. Firehose IAM Role（S3 写 + Glue 读）
  4. IRSA（授权 Pod 调 firehose:PutRecord）
  5. Fluent Bit 用 kinesis_firehose output plugin

Fluent Bit 配置

[OUTPUT]
    Name    kinesis_firehose
    Match   *
    region  us-west-2
    delivery_stream  eks-parquet-stream

技术对比

维度 方案 A 方案 B
镜像 自编译（C++ Arrow 交叉编译） 官方 aws-for-fluent-bit
转换位置 Pod 本地 Firehose 云端
Schema 管理 无（自动推断） Glue Table 声明式（改 Schema 不需重启 Pod）
额外资源 ECR Firehose + Glue
延迟 低（本地转换） 略高（网络传输 + Firehose 缓冲）
成本（4GB/天） ECR $0.02/月 Firehose $3.5/月

Kiro CLI 在搭建中的作用

Kiro CLI 通过 EKS MCP Server 直接操作集群——部署 K8s 资源、查 Pod 日志、验证数据链路。Steering 机制（.kiro/steering/ 目录放 Markdown 文件）解决了重复上下文问题。

两种方案搭建时间：方案 A 约 30 分钟，方案 B 约 25 分钟（含 Kiro 辅助）。

选型建议

方案 A 适合追求简单架构、对延迟敏感、团队有镜像构建能力的场景。方案 B 适合不想维护自编译镜像、需要 Schema 管理和字段过滤能力的场景。新项目推荐方案 B。

参考

posted @ 2026-04-29 08:07  亚马逊云开发者  阅读(7)  评论(0)    收藏  举报