当前位置：首页 > news >正文

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

news 2026/8/1 6:33:30

数据架构决策 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}