使用 Amazon Athena 分析 Kiro 团队用量报表：动态模型列的数据建模实践
内容提要
本文介绍使用Amazon Athena分析Kiro团队用量报表的实践。针对CSV中动态模型列可能导致数据错位的问题，通过ETL将宽表转为长表，采用Parquet格式和Partition Projection建表，实现稳定查询。方案完全Serverless化，月成本低于1美元，并接入Amazon QuickSight构建看板，便于团队观测用量、治理额度。
延伸解读
动态列漂移的隐患
Kiro 报表的模型列按字母序动态排列，当新增模型时列位置会变化。若直接用 OpenCSVSerDe 按列位置映射，旧分区与新分区同一列可能代表不同模型，导致数据语义错位且无报错。本文通过 ETL 将宽表转长表，将模型从列转为行，从根本上规避了此问题，确保 schema 稳定。
Serverless 成本优势
该方案完全 Serverless，无常驻基础设施。月数据量仅百 KB 级，Athena 按扫描量计费，单次查询费用极低，月度总成本低于 1 美元。相比常驻数据仓库，此场景下 Athena 更具成本效益，且 S3 原地查询免去数据搬迁，适合小数据量、低频访问的分析需求。
BI 层避免 JOIN 放大
在 Amazon Quick 中，作者保留两张独立数据集而非 JOIN。因为 fact_user_day_model 是长表，若与 fact_user_day 拉平 JOIN，静态度量（如 credits_used）会被模型行数复制放大，导致 SUM 结果虚高。每张数据集只承担各自维度的度量，是避免此类错误的关键实践。
Q&A
Kiro 的 per-user activity 报表中动态模型列会导致什么问题？
Kiro 报表中的模型消息数列是动态的，按字母序排列，当新增模型时列顺序会变化。而 OpenCSVSerDe 按列位置映射，导致旧分区与新分区在同一张表下相同位置的列代表不同模型，造成数据语义错位且无报错。
如何解决 Kiro 报表中动态模型列导致的数据错位问题？
通过增加一层轻量级 ETL，将宽表展开为长表，把模型从列转为行，生成 fact_user_day_model 表，使下游 schema 稳定，不再依赖上游列序。
为什么选择 Amazon Athena 来分析 Kiro 用量报表？
因为数据规模小（每月百 KB 量级），Athena 按扫描量计费，成本低；S3 原地查询无需数据搬迁；Partition Projection 支持新分区零运维。
在 Athena 建表时有哪些 DDL 实践注意事项？
Date 是保留字需重命名；列名不能含点号，需在 ETL 中转换；单次只能执行一条 DDL；CREATE DATABASE 时用 default 库；谨慎使用行内注释；跨区域访问会额外开销。
如何用 Athena 查询每个用户的月度用量汇总？
使用 SQL：SELECT user_email, MAX(subscription_tier) AS tier, COUNT(DISTINCT report_date) AS active_days, SUM(total_messages) AS messages, ROUND(SUM(credits_used), 2) AS credits FROM kiro_analytics.fact_user_day WHERE year = '2026' AND month = '06' GROUP BY user_email ORDER BY credits DESC;
在 Amazon Quick 中构建看板时，为什么保留两张独立 Dataset 而不做 JOIN？
因为 fact_user_day_model 是长表，一个 user-day 会展开成多行，如果与 fact_user_day 拉平 JOIN，静态度量（如 credits_used）会被复制多份，SUM 时被放大。独立 Dataset 可避免此问题。
整套方案每月运行成本大约多少？
日常使用下，S3 存储成本与 Athena 查询成本相加低于 1 USD/月。
