数据架构决策 Checklist：每次选型前必须回答的 20 个问题
一、选型焦虑是数据分析师的第一生产力杀手
"用 ClickHouse 还是 Doris？"
"上 Flink 做实时还是直接用 Spark Streaming？"
"湖仓一体要不要搞？搞了谁来维护？"
7 月有很多朋友问我这类问题。我的回答很统一：架构选型没有标准答案，只有适合不适合。但"适合不适合"需要有一套系统的方法来判断，而不是凭感觉或者跟风。
这篇 Checklist 就是我过去踩了好多选型坑之后总结出来的。20 个问题，分成 5 个维度，每次做技术决策前过一次，能避免 80% 的选型失误。
二、维度一：业务需求分析（5 题）
在做任何技术选型之前，先搞清楚业务到底要什么。很多选型翻车的根源是：技术方案很先进，但和业务需求没关系。
Q1：这个系统的核心查询模式是什么？
- 点查（根据 ID 查一条记录）→ 考虑 MySQL / PostgreSQL
- 范围扫描（查某个时间段的所有数据）→ 考虑 ClickHouse / Doris
- 全文搜索（关键字匹配）→ 考虑 Elasticsearch
- 图遍历（社交关系、推荐路径）→ 考虑 Neo4j / Nebula
- 向量检索（语义搜索）→ 考虑 Milvus / ChromaDB
经验之谈：一个系统 80% 的查询是同一类模式。把这一类模式做到极致，比面面俱到重要得多。
Q2：业务的实时性要求有多高？
- 秒级（实时大屏、风控决策）→ 需要 Flink + Kafka + 实时 OLAP
- 分钟级（运营看板、数据监控）→ T+0 微批足够
- 小时级（日常报表）→ 定时 ETL 即可
- 天级（财务对账、月度复盘）→ T+1 批处理最稳
关键判断：业务方说的"实时"往往不是真正的实时。多问一句"如果数据晚 5 分钟出来会怎样"，能避免过度设计。
Q3：数据一致性要求？
- 强一致（金融交易、库存扣减）→ 传统关系型数据库
- 最终一致（用户画像、推荐系统）→ 分布式系统可接受
- 弱一致（日志分析、流量统计）→ OLAP 系统天然支持
Q4：查询的并发量级？
# 用数字量化，不要用"高并发"这种模糊描述 def estimate_concurrency(peak_qps: int, avg_qps: int) -> str: """ 评估并发量级，给出对应的架构建议 """ if peak_qps < 10: return "低并发 → 单机数据库足够，不用上分布式" elif 10 <= peak_qps < 100: return "中等并发 → 读写分离 + 缓存层" elif 100 <= peak_qps < 1000: return "高并发 → 分布式数据库 + 多级缓存" else: return "超高并发 → 需要专门的架构评审，不是 Checklist 能搞定的"Q5：数据需要留存多久？
- 7 天以内 → 日志型，冷热分离都不用
- 1-3 个月 → 需要冷热分层，热数据 SSD、冷数据 HDD
- 1 年以上 → 需要归档策略和低成本存储（对象存储）
- 永久 → 需要专门的数据治理和生命周期管理
三、维度二：数据规模评估（4 题）
Q6：预估的数据总量（包括未来 1 年的增长）？
- < 100GB → 单机 MySQL/PostgreSQL 足够了，别折腾分布式
- 100GB - 1TB → 可以考虑 ClickHouse 单机版
- 1TB - 10TB → ClickHouse 集群 / Doris / StarRocks
- > 10TB → 需要专业的分区分桶和生命周期管理
Q7：单表最大行数？
-- 一个简单脚本检测你的实际数据量级 -- 在 ClickHouse 中执行即可 SELECT database, table, formatReadableSize(sum(bytes)) AS size, -- 表大小（人类可读） sum(rows) AS row_count, -- 总行数 max(modification_time) AS last_update -- 最后更新时间 FROM system.parts WHERE active = 1 -- 只统计活跃分区 GROUP BY database, table ORDER BY sum(bytes) DESC LIMIT 10;Q8：每天增量数据量？
如果每天新增 1 亿行，一年就是 365 亿行。这种情况下写入性能比查询性能更重要，分区键的选择会直接影响插入速度。
Q9：数据是否有时效性衰减？
- 是（比如日志数据 7 天后基本不会再查）→ TTL 自动清理
- 否（比如用户行为数据长期分析用）→ 按年分区 + 归档
-- ClickHouse TTL 设置示例：数据 90 天后自动删除 CREATE TABLE event_log ( event_time DateTime, user_id UInt64, event_type String ) ENGINE = MergeTree() ORDER BY (user_id, event_time) TTL event_time + INTERVAL 90 DAY -- 超过 90 天的数据自动删除 SETTINGS merge_with_ttl_timeout = 3600; -- 每小时检查一次四、维度三：团队能力匹配（4 题）
这是被忽略最多的维度。你选了一个技术栈天花板很高的方案，但团队里没人会维护，上线两个月就变成"没人敢动的祖传代码"。
Q10：团队里有人能独立运维这套系统吗？
- 有 → 放心选
- 没有但有学习意愿 → 留 2 周学习期 + 1 周踩坑缓冲期
- 没有且不愿学 → 选托管服务（云厂商的 SaaS 版本）
Q11：这套技术的社区活跃度如何？
去 GitHub 看三个指标：
- Stars 数和趋势（是否在增长）
- Issue 响应速度（提了 Bug 多久有人回）
- 最近一次 Release（是否还在活跃维护）
Q12：出现故障时，有人能快速排查吗？
# 一个简单的技术风险评估矩阵 tech_risk_matrix = { "ClickHouse": { "故障排查难度": "中", # 日志清晰、监控完善 "常见问题文档化程度": "高", "社区求助响应速度": "快", "overall_risk": "低" }, "自研系统": { "故障排查难度": "高", # 出问题只能靠自己 "常见问题文档化程度": "无", "社区求助响应速度": "无", "overall_risk": "非常高" } }Q13：有没有和现有技术栈的冲突？
比如团队主力是 Python，你选了一个 Go 生态的工具，虽然能集成但排障时会出现"没人看得懂代码"的尴尬。
五、维度四：运维成本评估（4 题）
Q14：硬件/云资源的月成本估算？
不要只看"官网报价"，实际成本 = 官网报价 × 1.3（预留缓冲）× 环境数量（开发+测试+预发+生产）。
Q15：日常运维工作量？
- 几乎不需要运维（托管服务/SaaS）→ 人力成本最低
- 需要定期巡检和调优 → 每周约 2-4 小时
- 需要专职 DBA → 至少 0.5 个人力
Q16：监控和告警体系的建设成本？
选型时要问自己：这套系统挂了，我能在 5 分钟内知道吗？如果不能，先补监控再上线。
# 数据平台关键监控指标 monitoring_metrics = { "写入健康": [ "每秒写入行数（写入 QPS）", "写入延迟 P99（毫秒）", "写入失败率（%）" ], "查询健康": [ "查询 QPS", "查询延迟 P50 / P99（毫秒）", "慢查询数量（> 5 秒）" ], "资源健康": [ "CPU 使用率", "内存使用率", "磁盘使用率 → 超过 80% 必须告警", "磁盘 IOPS" ], "数据质量": [ "每天增量数据量是否正常（突然暴增/暴跌都可能是 Bug）", "NULL 值占比是否异常波动" ] }Q17：备份和灾难恢复方案？
- 数据能备份吗？备份间隔多久？
- 恢复一个表需要多长时间？（实测，不是估计）
- 如果整个集群宕机，RTO（恢复时间目标）是多少？
六、维度五：未来扩展预留（3 题）
Q18：如果业务量翻 10 倍，能水平扩容吗？
- 能，加节点就行 → 分布式架构的优势
- 需要做分库分表改造 → 提前预留改造窗口期
- 需要完全换技术栈 → 说明当初选型有误
Q19：有没有可能接入 AI/ML 能力？
未来 1-2 年内，大概率你会需要让这个系统支持 AI 分析。选型时考虑：
- 是否支持 Python UDF（方便调用 ML 模型）？
- 是否能和向量数据库对接？
Q20：锁定期多长？
一旦选定了某个技术栈，至少 1-2 年内不要轻易换。迁移数据的成本远超你的想象。所以选型时多花 2 天调研，比 6 个月后花 2 周迁移划算。
七、综合打分卡
把这 20 个问题的答案汇总：
def architecture_scorecard(answers: dict) -> dict: """ 技术选型综合打分 每个问题回答 YES 得 1 分，NO 得 0 分 总分 20 分，评分标准： - 18-20 分：方案成熟，放心推进 - 14-17 分：基本可行，关注低分维度 - 10-13 分：有较大风险，建议重新评估 - < 10 分：强烈建议放弃当前方案 """ total = sum(1 for v in answers.values() if v == "YES") if total >= 18: rating = "强烈推荐" elif total >= 14: rating = "可以推进，关注风险点" elif total >= 10: rating = "建议重新评估" else: rating = "建议放弃" return {"total_score": total, "rating": rating}五、总结
这 20 个问题本质上在帮你做一件事：把模糊的"感觉"变成结构化的"判断"。
架构选型最大的坑不是选错了技术，而是没想清楚就开始选了。先回答清楚业务要什么、数据有多大、团队能搞定什么，技术选项会自然浮出水面。
建议把这份 Checklist 打印出来或者收藏起来，每次开技术选型会议前过一遍。相信我，这 20 个问题回答完，该选什么方案基本心里有数了。
7 月复盘系列第 5 篇，完整系列请查看 22zhuling 博客首页。
资料说明
本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0731 资料来源索引，并在发布前将具体来源贴到对应断言之后。
