一、数据量预估的核心依据
源系统现有数据存量
业务库（MySQL/Oracle）、日志服务器、埋点系统、第三方接口的当前总数据量、单表行数、单表大小。
源系统日增量（最关键）
日订单量、日用户注册、日PV/UV、日日志条数、日接口调用量、日消息量。
核心业务规模指标
总用户数、日活DAU、商户数、设备数、单据量、支付笔数——业务量直接决定数据量。
数仓分层膨胀/压缩系数
ODS/DWD/DWS/ADS 每层会放大或缩小，有行业固定经验值。
数据保留周期（TTL）
ODS存3个月/1年？DWD永久？日志存30天？直接决定总存量。
技术架构系数
Hadoop 3副本、压缩比（ORC/Snappy）、冷热分离、冗余预留（30%）。
二、标准化预估公式
1. 单表日增量（基础）
日增量(GB) = 日记录数 × 单条记录大小(KB) ÷ 1024 ÷ 1024
2. 数仓每层数据量（核心）
数仓某层量 = ODS原始量 × 分层系数
3. 总存量
总存量(GB) = 历史存量 + 日增量 × 保留天数 × 3副本(默认) ÷ 压缩比
4. 集群总存储预估
集群需求 = 数仓总数据量 × 1.3（预留30%冗余）
三、数仓分层系数（经验值）
初期建设直接用这个系数，误差≤30%：
重点：埋点/日志数据是数仓80%存储，业务数据只占20%，一定要分开估。
注意：制造业类似，制造业设备的日志数据与业务数据也需要分开估算，其中设备日志数据占绝大多数（80%）
四、案例
场景1：结构化业务数据（订单/用户/支付）
日订单：10万条
单条订单：2KB
保留：永久
历史存量：1000万条
ODS日增量：
10万 × 2KB ≈ 0.19GB/天
年增量：0.19 × 365 ≈ 69GB
DWD：69 × 1.1 ≈ 76GB
DWS：69 × 0.2 ≈ 14GB
场景2：埋点/行为日志（占存储大头）
DAU：50万
人均日行为：50条
单条日志：1KB
保留：90天
日日志量：50万 × 50 = 2500万条
ODS日增量 ≈ 23.8GB
90天存量：23.8 × 90 ≈ 2142GB
3副本：2142 ×3 = 6426GB
压缩比（ORC+Snappy≈4）：6426 ÷4 ≈ 1606GB
五、初期数仓建设预估原则（避免踩坑）
宁大勿小：初期估大30%，后期扩容麻烦，浪费一点成本远好过不够用。
日志优先估：日志占80%存储，业务数据可以粗略。
压缩必须算：Hive数仓默认压缩比3~5倍，不算会估大4倍。
增长预期：常规业务月增5%~15%，电商大促月增30%+。
不用追求精准：0-1阶段误差±30%完全可接受，核心是量级别错（GB/TB/PB别搞反）。
