波仔
📊 第6章 大数据的积累
📄 一句话概括

三条路：SQL on Hadoop、列式 MPP、云数仓，分别对应「量极大」「要秒级」「不想运维」。 算一笔账：100TB 存三年，三副本 216000 元、云对象存储 72000 元、 压缩后列式 18000 元。 选型先问四件事：数据量、延迟、成本、团队。 顺序不能反。

📝 本章和前面几章的关系

上一篇讲列存为什么快。这一篇讲具体选哪个产品——但不点名推荐，只讲判断方法。 教材 6.4、6.5 两节：SQL on Hadoop、DWH 制品，分别对应「分析型 DB 的选择方法」的前篇和后篇。 产品名一年一变，判断方法十年不变。所以这一篇重方法，不重品牌。

一、三条路，各解一个痛点

SQL on Hadoop：数据已经躺在分布式文件系统上了，你想用 SQL 去查它。代表是 Hive 那类。 它解的是「量极大、但能等」的问题。 列式 MPP：多台机器并行扫，秒级出结果。代表是 ClickHouse、Doris 那类。 它解的是「要快、量也不小」的问题。 云数仓：基础设施全托管，你只管建表写 SQL。它解的是「没人运维」的问题。

三条路不是先进程度的排序，是三个不同的取舍。选错了不是「性能差一点」，是「根本用不下去」。 比如数据只有 500GB，上了一套 Hadoop——每次查询要等几分钟，团队还以为「大数据就是这样」。

二、先算存储成本

演示算了一笔：100TB 数据，按 20 元/TB/月（这是示例量级，不是任何厂商报价）。 自建三副本：三倍空间，三年 216000 元。 云对象存储：单份，三年 72000 元。

压缩后存列式：按压到 25% 估，三年 18000 元。 看倍数关系：三副本是单份的三倍，压缩到四分之一就省四分之三。 这就是为什么第 6.2 篇那个「列存压到 8%」不是小事——存储费是按 TB 收的，压缩率直接换成钱。

当然这只是存储。真正的成本还有计算资源、网络流量、以及最贵的一项：人力。

三、再问四个问题

第一，数据量。现在多少、三年后多少、单机装不装得下。 第二，延迟。要秒级出结果，还是要能等十分钟？这一条决定要不要上 MPP。 第三，成本。存储费和人力费哪个是大头？小团队往往人力更贵。

第四，团队。有人能维护集群吗？没有就只能上云。 这四条里，最常见也最贵的错误是先选技术再想需求。 先上一套分布式系统，结果数据量小、查询固定，用普通数据库加几个索引就够——省下的不是钱， 是运维的人力，而人力恰恰是最贵的。

四、一条经验判断线

演示给了四条粗线：1GB 以下直接放业务库；1GB 到 1TB 建个独立分析库； 1TB 到 100TB 上列式 MPP 或云数仓；100TB 以上考虑分布式存储加 SQL on Hadoop。 这条线只是经验，不是定律。 因为延迟要求会大幅改变结论。 1TB 数据要秒级响应，也得上 MPP；100TB 数据只要隔夜出报表，Hive 也能凑合。

所以选型的第一句话永远是：这个查询要多快出结果？ 回答不了这个问题，任何选型都是猜。而猜错的代价，往往是半年后重来一遍。

五、动手 Demo：100TB 存三年，三种方案各多少钱

列三类方案各自解什么痛点。 按 100TB 算一笔三年存储成本。 最后给选型的四个问题和一条经验线。

tb, q = 100, 20.0        # TB 数，元/TB/月（示例值）

self_built = tb * 3 * q * 36    # 三副本
cloud      = tb * q * 36        # 单份
compressed = tb * 0.25 * q * 36 # 按压到 25% 估

print('自建三副本 %.0f 元' % self_built)
print('云对象存储 %.0f 元' % cloud)
print('压缩后列式 %.0f 元' % compressed)

实跑输出：

--------------------------------------------------------------------
分析型库怎么选：三类方案的成本账
--------------------------------------------------------------------

  ① 三类方案
  --------------------------------------------------------------------

| 类型 | 代表 | 适合什么 | 不适合什么 |
|---|---|---|---|
| SQL on Hadoop | Hive、Presto | 数据已经在 HDFS 上、量极大 | 要秒级响应 |
| 列式 MPP | ClickHouse、Doris | 固定报表、高并发聚合 | 频繁更新的数据 |
| 云数仓 | 各家云上的数仓 | 不想自己运维 | 长期成本高、数据出不去 |

  教材 6.4、6.5 两节分别讲「SQL on Hadoop」和「DWH 制品」，其实是同一个问题的两个答案：
  数据量很大时，怎么还能用 SQL 查。

  ② 算一笔存储成本
  --------------------------------------------------------------------
  假设有 100 TB 数据，单价 20.0 元/TB/月（示例值，不是报价）

| 方案 | 三年存储费 | 说明 |
|---|---:|---:|
| 自建三副本 | 216000 元 | 三副本要三倍空间 |
| 云对象存储 | 72000 元 | 按量，不含请求费 |
| 压缩后存列式 | 18000 元 | 按压到 25% 估 |

  这几行都是算出来的，单价是我随手写的一个量级，不代表任何厂商报价。
  重点看倍数关系：三副本是单份的三倍，压缩到四分之一就省四分之三。
  所以第 6.2 篇那个「列存压得动」不是小事——存储费是按 TB 收的。

  ③ 选型看四件事
  --------------------------------------------------------------------

| 维度 | 要问的问题 |
|---|---|
| 数据量 | 现在多少？三年后多少？单机能装下吗？ |
| 延迟 | 要秒级还是能等十分钟？这决定要不要上 MPP |
| 成本 | 存储费和人力费哪个是大头？ |
| 团队 | 有人能维护集群吗？没有就只能上云 |

  这四条的优先级因人而异，但有一个常见错误：先选技术再想需求。
  先上一套 Hadoop，结果数据只有 500GB、查询只有十条固定报表——用 MySQL 加几个索引就够，
  省下的是运维的人力。

  ④ 一条经验判断
  --------------------------------------------------------------------
  给一个粗略的判断线，只是经验，不是定律：

| 数据量 | 常见做法 |
|---|---|
| 1GB 以下 | 直接放业务库，写 SQL 就行 |
| 1GB ~ 1TB | 单独建一个分析库（列式或普通库都行） |
| 1TB ~ 100TB | 列式 MPP 或云数仓 |
| 100TB 以上 | 得上分布式存储 + SQL on Hadoop 那类方案 |

  这条线之所以「只是经验」，因为延迟要求会大幅改变结论：1TB 数据要秒级响应，也得上 MPP；
  100TB 数据只要隔夜出报表，Hive 也能凑合。
  所以选型的第一句话永远是：这个查询要多快出结果。

第一张表的三行不是「技术优劣」，是「适用场景」。看到「不适合什么」那一列，比看「适合什么」更有用。 第二段的单价 20 元是我随手写的一个量级，不代表任何厂商的真实报价。 这组数字的用途是看倍数，不是看绝对值。 第三段那四个问题里，第二个最容易被跳过。大家喜欢讨论「用哪个产品」，不愿意回答「要多快」。 最后那张经验表一定要配着「延迟会改变结论」这句话读，否则就成了教条。

30 秒实验

  1. 把 tb 从 100 改成 10，看三种方案的差价变成多少。
  2. 把压缩率从 0.25 改成 0.08（第 6.2 篇量出来的列存压缩率），看能省多少。
  3. 给自己的项目算一笔：数据量多少、要多快、有没有人能运维。

常见误区

  1. 「数据大就得上大数据技术栈。」500GB 用 Hadoop 是自找麻烦。先看数据量，再看延迟。
  2. 「云上更贵。」短期看是，但把人力算进去常常反过来。
  3. 「选最流行的那个。」流行度和你的场景没关系。要问的是「它不适合什么」。
自测三问（点开对答案） 1. 三类方案的差别是什么？ —— SQL on Hadoop 解「量极大但能等」，列式 MPP 解「要快且量不小」，云数仓解「没人运维」。 2. 为什么说压缩率直接换成钱？ —— 因为存储按 TB 收费。同样 100TB，压到 25% 就只付四分之一。三年下来差别是几万块。 3. 选型时最该先回答哪个问题？ —— 「这个查询要多快出结果」。 它决定要不要上 MPP，而其他三个问题（数据量、成本、团队）都要配合它。

下一篇进第 7 章：数据攒好了，怎么用出去。

相关笔记