【外评】大数据已死

大数据| 2024-05-29

十多年来，人们一直将难以从数据中获得可行见解的原因归咎于数据的规模。诊断结果是 “你的数据太大，你的系统太弱”，而治疗方法就是购买一些能够处理大规模数据的新技术。当然，在大数据工作组购买了所有新工具并从传统系统中迁移出来后，人们发现他们仍然难以理清他们的数据。他们还可能注意到，如果他们真正关注的话，数据规模并不是真正的问题所在。

2023 年的世界与大数据警钟开始敲响时有所不同。人们所预言的数据大灾难并没有发生。数据规模可能略有扩大，但硬件却以更快的速度变大。供应商仍在大力宣传其扩展能力，但从业人员开始怀疑这与他们的实际问题有什么关系。

我是谁？我为什么在乎？

十多年来，我一直是大数据鼓吹者之一。我是 Google BigQuery 的创始工程师，也是团队中唯一一个喜欢公开演讲的工程师，因此我经常参加世界各地的会议，解释我们将如何帮助人们抵御即将到来的数据爆炸。我曾经在台上现场查询过一个 PB 的数据，证明无论你的数据有多大、有多糟糕，我们都能轻松应对。

这张照片是我 2012 年在西班牙大数据大会上的照片，当时我警告人们大数据集的危险，并承诺只要他们使用我们的技术，就能摆脱困境。

在接下来的几年里，我花了大量时间调试客户在使用 BigQuery 时遇到的问题。我与他人合作撰写了两本书，深入研究产品的使用方式。2018 年，我转到了产品管理部门，工作内容主要是与客户（其中许多是全球最大的企业）交流，以及分析产品指标。

最让我惊讶的是，大多数使用 “大查询 “的人并没有真正的大数据。即使是那些拥有大数据的人，他们使用的工作负载也往往只占其数据集规模的一小部分。BigQuery 问世之初，对许多人来说就像科幻小说一样–用任何其他方法都无法以如此快的速度处理数据。然而，科幻小说中的东西现在已经司空见惯，更传统的数据处理方式已经迎头赶上。

关于本文

本篇文章将论证大数据时代已经结束的观点。大数据时代曾经风光无限，但现在我们可以不用再担心数据规模，而专注于如何利用数据做出更好的决策。我将展示一些图表；这些都是根据记忆手绘的。如果我真的能获得准确的数字，我也无法与大家分享。但重要的是形状，而不是确切的数值。

图表背后的数据来自于对查询日志、交易后记、基准结果（已发布和未发布）、客户支持单、客户对话、服务日志和已发布博文的分析，再加上一点直觉。

必备的介绍幻灯片

在过去 10 年中，每种大数据产品的推介会都会以这样一张幻灯片作为开场白：

我们在谷歌使用这个版本的幻灯片多年。当我转到 SingleStore 时，他们使用的是自己的版本，其中有相同的图表。我看到其他几家供应商也有类似的版本。这是一张 “吓人 “的幻灯片。大数据即将到来！你需要购买我所销售的产品！

它传达的信息是，旧的数据处理方式行不通了。数据生成的加速将使昔日的数据系统陷入泥潭，而任何接受新理念的人都能超越竞争对手。

当然，数据量的增加并不意味着每个人都会遇到问题；数据的分布并不均等。大多数应用程序并不需要处理海量数据。这导致采用传统架构的数据管理系统再度兴起；SQLite、Postgres、MySQL 都在强劲增长，而 “NoSQL “甚至 “NewSQL “系统却停滞不前。

MongoDB 是排名最靠前的 NoSQL 或其他扩展型数据库，虽然多年来有过不错的发展，但最近略有下滑，在与 MySQL 或 Postgres 这两个绝对单一的数据库的竞争中也没有取得什么进展。如果大数据真的席卷而来，那么经过这么多年的发展，你应该会看到一些不同的东西。

当然，分析系统的情况看起来有所不同，但在 OLAP 领域，你会看到从内部部署到云的大规模转变，而且实际上没有任何可与之比较的扩展型云分析系统。

大多数人没有那么多数据

从 “大数据即将到来 “图表中得到的启示是，很快每个人都会被自己的数据淹没。十年过去了，这个未来还没有实现。我们可以通过几种方式来验证这一点：查看数据（定量）、询问人们数据是否与他们的经验相符（定性），以及从第一原理出发进行思考（归纳）。

我在 BigQuery 工作时，花了很多时间研究客户规模。这里的实际数据非常敏感，所以我不能直接分享任何数字。不过，我可以说，绝大多数客户的总数据存储量都低于1TB。当然，也有数据量巨大的客户，但大多数企业，甚至是一些相当大的企业，数据量都适中。

客户数据大小呈幂律分布。最大客户的存储量是次大客户的两倍，次大客户的存储量是其一半，等等。因此，虽然有的客户拥有数百 PB 的数据，但其数据规模很快就下降了。有成千上万的客户每月支付的存储费用不到 10 美元，也就是半个 TB。在大量使用该服务的客户中，数据存储容量的中位数远远低于 100 GB。

在与行业分析师（Gartner、Forrester 等）交谈时，我们发现这一点得到了进一步的支持。我们赞美我们处理海量数据集的能力，他们却耸耸肩。”他们说：”这很好，但绝大多数企业的数据仓库都小于 1 TB。我们与业内人士交谈后得到的普遍反馈是，100 GB 是数据仓库的正确数量级。这也是我们制定基准的重点所在。

我们的一位投资者决定弄清分析数据规模到底有多大，并对他所投资的公司进行了调查，其中一些公司已退出市场（要么已首次公开募股，要么已被更大的企业收购）。这些公司都是科技公司，数据规模可能会偏大。他发现，其投资组合中最大的 B2B 公司的数据量约为 1 TB，而最大的 B2C 公司的数据量约为 10 TB。不过，大多数公司的数据量要少得多。

为了理解为什么大数据量很少见，思考一下数据的实际来源是很有帮助的。假设您是一家中型企业，拥有上千名客户。假设您的每位客户每天都会下一个新订单，其中有一百个细列项目。这虽然相对频繁，但每天产生的数据可能还不到一兆字节。三年后，您仍然只有千兆字节的数据，而生成一兆兆字节的数据则需要几千年的时间。

另一种情况是，假设您的营销数据库中有一百万条销售线索，而且您正在开展数十个营销活动。您的线索表可能还不到千兆字节，在每个营销活动中跟踪每个线索可能也只有几千兆字节。在合理的扩展假设下，很难看出这将如何增加海量数据集。

举个具体的例子，2020-2022 年，我在 SingleStore 工作，当时它是一家快速成长的 E 轮公司，拥有可观的收入和独角兽估值。如果把我们的财务数据仓库、客户数据、营销活动跟踪和服务日志加起来，可能只有几千兆字节。无论如何想象，这都不是大数据。

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

现代云数据平台都将存储和计算分离开来，这意味着客户不会受限于单一的形式因素。这可能是过去 20 年中数据架构发生的最重要变化，其意义远大于规模扩展。共享磁盘架构取代了在现实条件下难以管理的 “无共享 “架构，让您可以独立地扩展存储和计算。S3 和 GCS 等可扩展且速度相当快的对象存储的兴起，意味着你可以放宽对数据库构建方式的许多限制。

实际上，数据规模的增长速度远远快于计算规模的增长速度。虽然对存储和计算分离的好处的流行描述让人觉得您可以随时选择扩展其中任何一个，但这两个轴实际上并不等同。对这一点的误解导致了很多关于大数据的讨论，因为处理大型计算需求的技术不同于处理大型数据的技术。探讨为什么会出现这种情况是有帮助的。

所有大型数据集都是随着时间的推移而产生的。时间几乎总是数据集中的一个轴。每天都有新订单。每天都有新的出租车乘客。新的日志记录。新的游戏。如果一项业务是静态的，既不增长也不萎缩，那么数据就会随着时间线性增长。这对分析需求意味着什么？显然，数据存储需求将呈线性增长，除非您决定修剪数据（稍后详述）。但计算需求可能不会随着时间的推移而有很大变化；大多数分析都是在最近的数据上完成的。扫描旧数据是非常浪费的；这些数据不会发生变化，为什么要反复花钱去读取呢？诚然，您可能希望保留这些数据，以防您想对这些数据提出新的问题，但建立包含重要答案的聚合数据是非常琐碎的事情。

通常，当数据仓库客户从一个没有存储和计算分离的环境迁移到一个有存储和计算分离的环境时，他们的存储使用量会大幅增长，但他们的计算需求往往不会真正改变。在 BigQuery 中，我们有一个客户是全球最大的零售商之一。他们的内部数据仓库大约有 100 TB 的数据。当他们迁移到云后，数据量达到了 30 PB，增长了 300 倍。如果他们的计算需求也有类似的增长，那么他们在分析上的花费将达到数十亿美元。相反，他们只花费了其中的一小部分。

这种偏向存储规模而非计算规模的做法对系统架构产生了实际影响。这意味着，如果使用可扩展的对象存储，使用的计算量可能会比预期的少得多。甚至可能根本不需要使用分布式处理。

工作负载规模小于总体数据规模

分析工作负载所处理的数据量几乎肯定比你想象的要小。例如，仪表盘通常是根据汇总数据构建的。人们查看的是上一小时、上一天或上一周的数据。小表的查询频率往往更高，而大表的查询则更有选择性。

几年前，我对 BigQuery 查询进行了一次分析，研究对象是每年花费超过 1000 美元的客户。90%的查询所处理的数据少于100 MB。我采用了多种不同的方法对其进行切分，以确保并非只有少数客户运行了大量查询，从而导致结果偏差。我还剔除了纯元数据查询，这是 BigQuery 中的一小部分查询，根本不需要读取任何数据。在达到千兆字节之前，你必须在百分位数范围内进行相当高的查询，而运行在太字节范围内的查询非常少。

数据量巨大的客户几乎从未查询过海量数据

数据量适中的客户通常会进行相当大的查询，但数据量巨大的客户几乎从不查询海量数据。即使有，通常也是因为要生成报告，而性能并不是优先考虑的因素。一家大型社交媒体公司会在周末运行报告，为周一早上的高管会议做准备；这些查询量相当大，但只是一周其他时间数十万次查询中的一小部分。

即使在查询巨型表时，也很少需要处理大量数据。现代分析型数据库可以进行列投影，只读取字段的子集，也可以进行分区剪枝，只读取很小的日期范围。它们通常还能进一步消除分段，通过聚类或自动微分区来利用数据的位置性。其他技巧，如在压缩数据上计算、投影和谓词下推，都是在查询时减少 IO 的方法。减少 IO 就能减少需要进行的计算，从而降低成本和延迟。

巨大的经济压力促使人们减少数据处理量。仅仅因为你能快速扩展和处理某些数据，并不意味着你能以低廉的成本做到这一点。如果你使用一千个节点来得到一个结果，那很可能要花费你一只胳膊和一条腿。我在台上展示 BigQuery 时使用的 Petabyte 查询按零售价计算需要花费 5,000 美元。很少有人愿意运行如此昂贵的东西。

请注意，即使您不使用按字节扫描付费的定价模式，处理较少数据的经济激励也是有效的。如果您有一个 Snowflake 实例，如果您可以将查询次数减少，您就可以使用较小的实例，并支付较少的费用。您的查询速度会更快，并发运行的次数会更多，而且随着时间的推移，您通常会支付更少的费用。

大多数数据很少被查询

在被处理的数据中，有很大一部分是不足 24 小时的数据。当数据使用一周后，被查询的可能性可能比最近一天低 20 倍。一个月后，数据大多就被搁置了。历史数据的查询频率往往不高，也许是在有人运行罕见的报告时。

数据存储年龄模式要平缓得多。虽然很多数据很快就会被丢弃，但也有很多数据会被添加到表的末尾。最近一年可能只有 30% 的数据，但却有 99% 的数据访问量。最近的一个月可能只有 5% 的数据，但却有 80% 的数据访问量。

数据的静态化意味着数据工作集的大小比你想象的更容易管理。如果你有一个拥有 10 年数据的 PB 级表，你可能很少访问比当前日期更早的数据，而当前日期的压缩数据可能不到 50 GB。

大数据前沿不断后退

大数据 “的一个定义是 “无法在单台机器上运行的数据”。根据这一定义，符合条件的工作负载数量逐年减少。

在 2004 年撰写 Google MapReduce 论文时，数据工作负载无法在单台商品机器上运行的情况非常普遍。扩展成本高昂。2006 年，AWS 推出了 EC2，当时能获得的实例大小只有一个内核和 2 GB 内存。很多工作负载都无法在这台机器上完成。

但如今，AWS 上的标准实例使用的是 64 个内核和 256 GB 内存的物理服务器。这相当于多了两个数量级的内存。如果你愿意多花一点钱购买内存优化的实例，就能再获得两个数量级的内存。有多少工作负载需要超过 24TB 的内存或 445 个 CPU 内核？

过去，大型机的成本要高得多。然而，在云计算中，使用整台服务器的虚拟机成本仅为使用八分之一台服务器的虚拟机成本的 8 倍。成本与计算能力呈线性增长，直至一些非常大的规模。事实上，如果你看看最初的 dremel 论文中发布的使用 3,000 个并行节点的基准测试，你今天在单个节点上就能获得类似的性能（更多详情请见下文）。

数据是一种负担

大数据的另一个定义是 “当保留数据的成本低于确定丢弃数据的成本时”。我喜欢这个定义，因为它概括了人们最终使用大数据的原因。这并不是因为他们需要这些数据，而是他们懒得删除这些数据。如果你想想企业收集的许多数据湖，它们就完全符合这个定义：巨大而杂乱的沼泽，没有人真正知道它们拥有什么，也不知道清理它们是否安全。

保存数据的成本高于存储物理字节的成本。根据 GDPR 和 CCPA 等法规，您必须跟踪某些类型数据的所有使用情况。有些数据需要在一定时间内删除。如果您在数据湖的某个地方长期保留了parquet文件中的电话号码，那么您就可能违反了法规要求。

除了监管之外，数据还可能成为针对您的诉讼的辅助工具。正如许多组织为了减少潜在的责任而强制执行有限的电子邮件保留政策一样，数据仓库中的数据同样可以用来对付你。如果你有五年前的日志，可以显示代码中的安全漏洞或错过了 SLA，那么保留旧数据可能会延长你的法律风险。我听说过一个可能是天方夜谭的故事，说的是一家公司对其数据分析能力保密，以防止在法律取证过程中被利用。

代码如果没有得到积极维护，往往会出现人们所说的 “比特腐烂 “问题。数据也会出现同样的问题，即人们忘记了专门字段的确切含义，或者过去的数据问题可能已经淡忘。例如，可能出现过一个短暂的数据错误，将所有客户 ID 设置为空。或者曾有一笔巨额欺诈交易，使 2017 年第三季度的业绩看起来比实际情况好很多。通常，从历史时间段中提取数据的业务逻辑会变得越来越复杂。例如，可能会有这样一条规则：” 如果日期早于 2019 年，则使用收入字段，在 2019 年至 2021 年之间，则使用收入_美元字段，在 2022 年之后，则使用收入_美元_审计字段”。保存数据的时间越长，就越难跟踪这些特殊情况。而且并非所有情况都能轻易解决，尤其是在数据缺失的情况下。

如果您还保留着旧数据，最好了解一下保留这些数据的原因。你是否在反复询问同样的问题？如果是这样，只存储聚合数据的存储和查询成本不是要低得多吗？您是在以备不时之需吗？您是否在考虑您可能想问的新问题？如果是，它有多重要？您真正需要它的可能性有多大？你真的只是一个数据囤积者吗？这些都是要问的重要问题，尤其是当你试图弄清楚保留数据的真正成本时。