大数据已死？谷歌十年老兵吐槽：收起 PPT 吧！数据大小不重要，能用起来才重要

大数据| 2023-04-20

图0: 大数据大数据已死？谷歌十年老兵吐槽：收起 PPT 吧！数据大小不重要，能用起来才重要

随着云计算时代的发展，大数据实际已经不复存在。在真实业务中，我们对大数据更多的是存储而非真实使用，大量数据现在已经变成了一种负债，我们在选择保存或者删除数据时，需要充分考虑可获得价值及各种成本因素。

十多年来，人们一直很难从数据中获得有价值的参考信息，而这被归咎于数据规模。“对于你的小系统而言，你的数据量太庞大了。”而解决方案往往是购买一些可以处理大规模数据的新机器或系统。但是，当购买了新的设备并完成迁移后，人们发现仍然难以处理、理解他们的数据。你们可能已经意识到了，数据规模并不是问题关键所在。

2023 年的世界看起来与大数据警报响起时不同。预言中的数据灾难并没有发生。数据规模是变大了一些，但是相比而言硬件规模变的更加庞大。供应商仍在推动其规模扩大，但从业者开始思考现实世界的真实需求，开始怀疑这样做的必要性。

我是谁，我为什么关心这些？

十多年来，我一直在为大数据摇旗呐喊。我是谷歌BigQuery 的创始工程师。作为团队中唯一一个非常喜欢公开演讲的工程师，我到世界各地参加会议，解释我们将如何帮助人们抵御即将到来的数据爆炸。我曾经在台上实时查询千兆级的数据，证明无论你的数据有多大、有多糟糕，我们都能够处理它，没有任何问题。

在接下来的几年里，我花了大量时间解决用户使用 BigQuery 遇到的问题。我与别人合著了两本书，在其中深入研究了产品的使用方式。2018 年，我转向了产品管理，我的工作主要是与客户沟通以及分析产品指标，其中许多客户是世界上的头部企业。

让我惊讶的是，大多数使用 BigQuery 的客户并没有真正的大数据。即使是拥有大数据的客户，也倾向于仅使用一小部分数据集。对于很多人来说，BigQuery 的出现就像科幻小说一样——你真的不可能用其他任何方法这么快地处理数据。然而，曾经是科幻小说的东西现在已经司空见惯，传统的数据处理方式已经赶上来了。

这篇文章将解释为什么大数据时代已经结束。现在我们可以不再担心数据大小，而是专注于如何使用它来做出更好的决策。我会展示一些图表，这些图表都是根据记忆手绘的，即便我有确切的数字，但我也不能分享它们。其实重要的是图像形状，而不是确切的值。

图表背后的数据来自于日志查询、交易事后分析、基准测试结果(已发布和未发布)、客户服务单、客户调研、服务日志和对已发布博客文章的分析，也包括了一些我个人的直觉感知。

必不可少的 PPT

在过去的 10 年中，每一个大数据产品的每一次推销都以一张 PPT 开始，幻灯片大体像下图这样：

图2: 大数据大数据已死？谷歌十年老兵吐槽：收起 PPT 吧！数据大小不重要，能用起来才重要

我们在谷歌使用这个幻灯片很多年了。当我转到 SingleStore 时，他们虽使用的是自己的版本，但有着相同的图表。我见过其他几个供应商也有类似的图表。这是“恐吓”幻灯片：大数据来了！你需要买我卖的东西！

这其中传达的信息是，旧的数据处理方式将不再适用。数据生成的速度将使过去的数据系统陷入泥潭，接受新思想的人才能超越竞争对手。

不过，产生的数据量在增加，并不意味着它会成为每个人的问题。大多数应用程序不需要处理大量数据。这是采用传统架构的数据管理系统复兴的原因，SQLite、Postgres、MySQL都在强劲增长，而“NoSQL”甚至“NewSQL”系统却停滞不前。

MongoDB是排名最高的 NoSQL 扩展数据库，尽管多年来增长迅速，但最近略有下降。与 MySQL 或 Postgres 这两个有绝对优势的数据库相比，它并没有真正取得多大突破。如果大数据真的占据了主导地位，那么在经历了这么多年之后，我们应该看到一些不同的东西。

当然，分析系统的情况看起来有所不同，但在 OLAP 中，可以看到从本地部署到云的巨大转变，而且实际上没有任何可与之相比的扩展云分析系统。

大多数人并没有那么多数据

从“大数据即将到来”的图表中可以看出，很快每个人都会被他们的数据淹没。十年过去了，这个现象还没有出现。我们可以通过几种方式验证这一点:查看数据(定量地)、询问人们是否有过大数据的感知经历(定性地)、从基本原理(归纳地)思考分析。

在 BigQuery 工作时，我花了很多时间研究客户规模。这里的真实数据比较敏感，所以我不能直接分享任何数字。但我能肯定的是，绝大多数客户的数据存储总量不到 1TB。当然，有的客户确实有大量数据，但大多数组织，甚至一些相当大的企业，都只有中等规模的数据。

客户的数据量大小遵循幂律分布。最大的客户拥有的存储量是第二大客户的两倍，第三大的客户存储拥有量又是前者的一半，以此类推。虽然有数百 PB 级数据存储量的客户，但这种级别的很快就会减少。有成千上万的客户每月支付的存储费用不到 10 美元，即半 TB 数据量的费用。在大量使用存储服务的客户中，数据存储容量的中值远小于 100GB。

我们在与行业分析师（Gartner、Forrester 等）交谈后得到了进一步的印证。我们鼓吹我们处理海量数据集的能力时，他们则会耸耸肩。“这很好，”他们说，“但绝大多数企业的数据仓库都小于 1TB。”我们与业内人士交谈时得到的普遍反馈是，100GB 是数据仓库的合理数量级。这正是我们在基准测试中投入大量精力的地方。

我们的一位投资者决定弄清楚分析数据规模到底有多大，并调查了他的投资组合公司，其中一些是退出后的公司(要么已经上市，要么被更大的机构收购)。这些都是科技公司，它们倾向于拥有更大的数据量。他发现，在他的投资组合中，最大的 B2B 公司拥有大约 1TB 的数据，最大的 B2C 公司拥有大约 10TB 的数据。然而，大多数公司的数据量要少得多。

想要理解为什么大数据这么少，我们就要从数据的实际来源方面思考一下。假设你是一家中型企业，拥有 1000 名客户。假设每个客户每天都下 100 个商品的新订单。这种频率已经非常高了，但每天产生的数据可能还不到 1MB。三年后，你只有 1GB，而产生 1TB 数据需要数千年的时间。

或者，假设你的营销数据库中有一百万个线索，你正在进行几十个活动。你的潜在客户表可能还不到 1GB，在每个活动中跟踪每个潜在客户可能也只产生几 GB 数据。在合理的缩放范围内，很难想象如何增长到海量数据。

举一个具体的例子，我 2020-2022 年在 SingleStore 工作，当时它是一家进入 E 轮的快速增长的公司，拥有可观的收入和独角兽估值。如果将我们的财务数据仓库、客户数据、营销活动跟踪记录，以及服务日志数据相加，可能也只有几 GB 的数据规模。无论怎么看，这都不是大数据。

存储和计算分离中的存储偏差

现代云数据平台都将存储和计算分离，这意味着客户不受单一因素的限制。这可能是过去 20 年中数据架构中最重要的一次变化，而不仅仅是横向扩展。与现实环境中难以管理的“无共享”体系结构不同，共享磁盘体系结构使你能够独立地增加存储和计算能力。S3 和 GCS 等可扩展、高速的对象存储的兴起，让我们在构建数据库时变的非常容易。

在实践中，数据大小的增长比计算能力的增长快得多。虽然存储和计算分离的优势特性，让我们可以随时选择扩展其中任何一个，但这两个轴实际上并不等效。对这一点的误解导致了大量关于大数据的讨论，因为处理大型计算需求的技术与处理大数据的技术是不同的。探究为什么会出现这种情况是有必要的。

所有大型数据集都是随着时间的推移而生成的。时间几乎总是数据集中的一个轴。每天都有新订单、新的出租车服务、新的日志记录、新的一局游戏。如果一个业务是静态的，既不增长也不萎缩，数据将随着时间线性增长。这对分析需求意味着什么?显然，数据存储需求将呈线性增长，除非你删除数据(稍后将详细介绍)。但是计算需求可能不需要随着时间的推移而改变太多，大多数分析都是针对最近的数据进行的。扫描旧数据相当浪费资源，它不会改变，所以你为什么要花钱一遍又一遍地读取它呢？你可能希望先保存下来，以防对数据进行重新挖掘价值信息，但构建包含重要信息的聚合更加有效。

通常情况下，当数据仓库客户从存储和计算一体的环境转移到一个存储和计算分离的环境时，他们的存储使用量会急剧增长，但他们的计算需求往往不会真正改变。在 BigQuery 时，我们有一个客户是世界上最大的零售商之一。他们有一个内部数据仓库，大约有 100TB 的数据。当他们迁移到云端时，他们最终的数据量是 30PB，增长了 300 倍。如果他们的计算需求也增加了类似的数量，他们将需要在数据分析上花费数十亿美元。不过，他们只花了这个数字的一小部分。

这种偏向于存储大小而不是计算大小的做法对系统架构产生了真正的影响。这意味着，如果使用可扩展对象存储，那么你所使用的计算量可能会远远少于预期。你甚至可能根本不需要使用分布式处理。

工作负载大小小于总体数据大小

用于分析工作的数据量肯定比想象的要小。例如，动态监控面板通常由聚合数据构建。人们往往需要查看的是前一小时、前一天或上周的数据，这通常需要频繁查询较小的表，对大型表只要选择性地查询便可以了。

几年前，我对 BigQuery 的查询情况做了一个分析，分析了每年花费超过 1000 美元的客户。90%的查询处理的数据小于 100MB。我用了很多不同的分析方法，以确保结果不被进行了大量查询的几个客户的行为所扭曲。我还把仅对元数据的查询剔除了，这是 BigQuery 中不需要读取任何数据的部分查询。到达 GB 这个量级的非常少，极少量的查询能达到 TB 级。

拥有中等数据量的客户经常进行相当大的查询，但是拥有海量数据的客户几乎从不查询大量的数据。当他们这样做时，通常是因为他们需要生成一份报告，而这时性能并不是真正的优先考虑事项。一家大型社交媒体公司会在周末发布报告，为高层领导周一上午做准备，这些查询非常庞大，但也仅占一周内他们所做的数十万次查询中的一小部分。

图1: 大数据大数据已死？谷歌十年老兵吐槽：收起 PPT 吧！数据大小不重要，能用起来才重要

即使在查询大型表时，也很少需要处理大量数据。现代分析数据库可以通过列投影来只读字段的子集，通过分区修剪来只读较窄的日期范围。他们通常可以更进一步，通过聚类或自动微分区，利用数据中的局部性来消除段。其他一些技巧，如对压缩数据进行计算、投影和谓词下推，都可以在查询时减少 IO 操作。更少的 IO 意味着更少的计算量，从而降低成本和延迟。

严峻的经济压力促使人们减少对大数据量的处理。我们可以快速地扩展和处理一些东西，但并不代表着你可以廉价地获得这个能力。如果使用一千个节点来获得一个结果，这可能会消耗你大量的资源。我在会议上演示的 BigQuery 的 PB 级查询零售价是 5000 美元，很少有人愿意花费如此昂贵的费用。

请注意，即使你没有使用按字节付费的定价模型，关于对少量数据优惠的激励政策也是有效的。假设你有一个 Snowflake 实例，如果你可以让你的查询更小，你可以使用一个更小的实例，从而支付更少的费用。你的查询会更快，可以并发地运行更多查询，随着时间的推移，你最终支付的费用通常会更少。

大多数数据很少被查询

我们处理的数据中有很大一部分是 24 小时以内的。当数据超过一周时，它被查询的可能性可能比最近一天的数据低 20 倍。一个月后，数据基本上就只是存储在那里了。历史数据往往很少被查询，除非有人需要做一份特殊的报告。

图3: 大数据大数据已死？谷歌十年老兵吐槽：收起 PPT 吧！数据大小不重要，能用起来才重要

数据存储时间的曲线扁平化得多。很多数据很快就会被丢弃，不过仍会有很多数据被追加到表中。最近一年，99%的数据访问只针对 30%的数据量。最近一个月 80%的数据访问可能只是针对 5%的数据量。

大量数据不被使用，意味着数据集的大小比预期更易于管理。如果有一个 PB 级的表，其中包含 10 年的数据，你可能很少访问比今天更早的任何数据，这些数据压缩后可能小于 50 GB。

大数据边界不断缩小

“大数据”的一种定义是“不适合只用一台机器处理的数据”。根据这个定义，符合条件的工作机器在不断减少。

2004 年，谷歌 MapReduce 论文发表时，数据不适合在单个商用机器上处理是很常见的，对机器扩容也非常昂贵。在 2006 年，AWS 推出了 EC2，我们能得到的唯一实例大小是一个单核和 2 GB 的 RAM。有很多工作都不适合那台机器。

然而，现在 AWS 上的一个标准实例使用一个具有 64 核和 256 GB RAM 的物理服务器。RAM 多了两个数量级。如果你愿意多花一点钱优化下内存，你可以获得另外两个数量级的 RAM。有多少工作需要用到超过 24TB 的 RAM 或 445 个 CPU 核？

过去，大型机器非常昂贵。然而，在云计算中，使用整个服务器的虚拟机的成本仅比使用八分之一服务器的虚拟机的成本高出 8 倍。成本随着计算能力线性增加，规模非常大时也是如此。事实上，dremel 原始论文中发布的使用 3000 个并行节点的基准测试，我们现在可以在单个节点上就获得类似的性能(稍后会详细介绍)。

数据是一种负债

大数据的另一种定义是“保存数据的成本低于丢弃数据的成本”。我喜欢这个定义，因为它概括了人们最终选择大数据的原因。这并不是因为我们需要它，我们只是懒得删除而已。想想现在的许多数据湖，它们完全符合这一要求：巨大而混乱的沼泽，没有人真正知道它们包含什么，也没有人知道清理它们是否安全。

让数据一直存在业务中的成本比仅仅存储物理字节的成本要高。根据 GDPR 和 CCPA 等法规，你必须跟踪某些特定类型数据的所有使用情况。部分数据需要在一定时间内删除。如果你把电话号码长时间保存在数据湖中的某个 parquet 文件中，你就可能违反了法定要求。

除了监管法规，数据还可以用来起诉你。正如许多组织执行有限的电子邮件保留策略以减少潜在的责任一样，数据仓库中的数据也可能被用来对付你。如果你有 5 年前的日志，这些日志显示代码中存在安全漏洞或 SLA 缺失，保留旧数据可能会延长您的法律风险。我听说过一个可能是杜撰的故事，讲的是一家公司对其数据分析能力保密，以防止其在法律取证过程中被使用。

当代码没有得到积极维护时，它经常会遭受人们所说的“比特腐烂”。数据可能会遇到相同类型的问题；也就是说，人们忘记了专业领域的确切含义，或者过去的数据问题可能渐渐地被遗忘了。例如，可能存在一些数据错误，使得每个客户的 id 为空。或者有一笔巨大的欺诈交易，使 2017 年第三季度看起来比实际情况要好得多。从历史时间段提取数据的业务逻辑会变得越来越复杂。例如，可能有这样的规则，“如果日期早于 2019 年，则使用 revenue 字段，2019 年至 2021 年之间使用 revenue_usd 字段，2022 年之后使用 revenue_usd_audited 字段。”数据保存的时间越长，跟踪这些特殊情况就越困难。而且并不是所有这些问题都能轻松解决掉，尤其是在数据缺失的情况下。

如果你要保留旧数据，那么最好想清楚为什么要保留它，三思而后行。如果一定要保存，仅仅存储聚合的存储和查询，成本不是要低得多吗？你留着它以备不时之需吗？你是觉得你可能未来从数据中获得新的价值信息么？如果是，它有多重要？你真的需要它的可能性有多大？你真的不是一个数据囤积者吗？这些都是要思考的重要问题，尤其是当你试图计算保存数据的真实成本时。