数据架构决策 Checklist：每次选型前必须回答的 20 个问题

数据架构决策 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分钟级运营看板、数据监控→ T0 微批足够小时级日常报表→ 定时 ETL 即可天级财务对账、月度复盘→ T1 批处理最稳关键判断业务方说的实时往往不是真正的实时。多问一句如果数据晚 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、冷数据 HDD1 年以上 → 需要归档策略和低成本存储对象存储永久 → 需要专门的数据治理和生命周期管理三、维度二数据规模评估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 资料来源索引并在发布前将具体来源贴到对应断言之后。