原文：BIG DATA IS DEAD^[1]

翻译：ChatGPT

Jordan Tigani 目前担任 MotherDuck 的 CEO 和联合创始人，曾任 SingleStore 的首席产品官。他不仅是产品领导者和工程领导者，还是 Google BigQuery 的创始工程师之一。

十多年来，人们很难从数据中获得可行的见解，这一事实一直被归咎于数据的规模。“你的数据对你微不足道的系统来说太大了”，这是诊断结果，解决方法是购买一些新的能够处理大规模数据的高端技术。当然，在大数据任务组购买了所有新工具并从传统系统迁移后，人们发现他们仍然难以理解自己的数据。如果他们真的很注意的话，他们可能会注意到，数据大小根本不是问题所在。

2023 年的世界与大数据警报开始时的情况有所不同。预测的数据灾难并没有发生。数据规模可能略有增加，但硬件的增长速度更快。供应商仍在推动他们的扩展能力，但从业者开始怀疑这与他们的现实问题有何关系。

我是谁，为什么我在乎？

十多年来，我一直是大数据的信徒之一。我是 Google BigQuery 的创始工程师之一，作为团队中唯一喜欢公开演讲的工程师，我有机会去世界各地的会议上解释我们将如何帮助人们抵御即将到来的数据爆炸。我曾经在舞台上查询了一 PB 的数据，展示无论你的数据有多大，我们都能轻松处理。

这张照片是我在 2012 年西班牙大数据会议上，警告巨型数据集的危险，并承诺只需使用我们的技术，就能获得解脱。

在接下来的几年里，我花了大量时间解决客户在 BigQuery 中遇到的问题。我共同撰写了两本书，真正深入了解了产品的使用方式。2018 年，我转到了产品管理，我的工作被分为与客户交流，其中许多是世界上最大的企业之一，以及分析产品指标。

最令我惊讶的是，我发现使用“大查询”的大多数人并没有真正的大数据。即使那些确实有大数据的人也倾向于使用仅使用数据集大小的一小部分的工作负载。当 BigQuery 推出时，对许多人来说，它就像科幻小说一样--你无法以任何其他方式处理数据得这么快。然而，现在科幻小说已经司空见惯，传统的数据处理方式也已经赶上了。

关于本文

本文将论述大数据时代已经结束。它运行良好，但现在我们可以不再担心数据大小，而是专注于如何利用数据做出更好的决策。我将展示一些图表；这些图表都是基于记忆手绘的。如果我能够获取准确的数字，我将无法分享它们。但重要的是形状，而不是确切的值。

图表背后的数据来自于分析查询日志、交易事后分析、基准测试结果（已发布和未发布）、客户支持工单、客户对话、服务日志和已发布的博客文章，以及一些直觉。

强制性介绍幻灯片

在过去的 10 年里，每个大数据产品的演示文稿都以类似这样的幻灯片开始：

我们在 Google 使用了这张幻灯片的一个版本多年。当我转移到 SingleStore 时，他们使用了自己版本的，图表相同。我看到其他几家供应商也有类似的东西。这是“恐慌”幻灯片。大数据来了！你需要购买我正在销售的东西！

这个信息是旧的数据处理方法将无法奏效。数据生成的加速将使昨天的数据系统陷入泥潭，而接受新想法的人将能够领先于竞争对手。

当然，仅仅因为生成的数据量增加并不意味着它对每个人都构成问题；数据并不是均匀分布的。大多数应用程序不需要处理大量数据。这导致了传统架构的数据管理系统的复苏；SQLite、Postgres、MySQL 都在大力增长，而“NoSQL”甚至“NewSQL”系统都在停滞不前。

MongoDB 是排名最高的 NoSQL 或其他扩展数据库，虽然它在过去几年里有过良好的增长，但最近略有下降，并没有对 MySQL 或 Postgres 产生太大影响，这两种都是坚定的单体数据库。如果大数据真的

占据主导地位，那么在所有这些年过后，你应该会看到一些不同的东西。

当然，在分析系统中情况有所不同，但在 OLAP 中，我们看到了从本地到云端的巨大转变，并且真正可以与之相媲美的云分析系统并不存在。

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

“大数据即将到来”的预测意味着的主要观点是，很快每个人都将被自己的数据淹没。十年过去了，这个未来还没有出现。我们可以通过几种方式来验证这一点：通过数据（定量）观察，询问人们是否与他们的经验一致（定性观察），以及从第一原则出发进行思考（归纳）。

当我在 BigQuery 工作时，我花了很多时间看客户的数据大小。实际数据非常敏感，所以我不能直接分享任何数字。但我可以说绝大多数客户的总数据存储量都不到一 TB。当然，也有拥有大量数据的客户，但大多数组织，甚至一些相当大的企业，都拥有适度的数据规模。

客户数据大小遵循幂律分布。最大的客户的存储量是下一个最大的客户的两倍，下一个最大的客户的一半，依此类推。因此，虽然有些客户拥有数百 PB 的数据，但规模迅速减小。有成千上万的客户每月支付少于 10 美元的存储费，即半 TB。在使用服务 intensively 的客户中，中位数数据存储大小远远小于 100GB。

当我们与行业分析师（Gartner、Forrester 等）交流时，我们会夸耀我们处理大规模数据集的能力，但他们却对此不以为然。“这很好，”他们说，“但绝大多数企业的数据仓库都小于一 TB。”我们在与行业人士交流时得到的一般反馈是，100GB 是数据仓库的正确数量级。这是我们在基准测试中着重关注的地方。

我们的一位投资者决定弄清楚分析数据大小到底有多大，并对他的投资组合公司进行了调查，其中一些公司已经完成退出（已经上市或被较大的组织收购）。这些都是科技公司，可能倾向于拥有较大的数据规模。他发现他的投资组合中最大的 B2B 公司拥有约一 TB 的数据，而最大的 B2C 公司拥有约 10TB 的数据。然而，大多数公司拥有的数据远远少于这个数量。

要理解为什么大数据规模罕见，有助于考虑数据实际上来自哪里。想象一下你是一家中等规模的企业，有一千个客户。假设你的每一个客户每天都会下单购买一百个产品。这相对频繁，但仍然可能少于一兆字节的数据每天生成。三年后，你只会有一 GB 的数据，而要生成一 TB 的数据可能需要几千年。

另一方面，假设你的营销数据库中有一百万个潜在客户，并且你正在运行数十个营销活动。你的潜在客户表可能仍然不到一 GB，跟踪每个潜在客户参加的每个活动可能仍然只有几 GB。很难想象这将在合理的扩展假设下导致大规模数据集的形成。

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

在分离存储和计算中的存储偏见

现代云数据平台都将存储和计算分离，这意味着客户不会被绑定到单一的形式因素。这一点，比起扩展更加重要，很可能是过去 20 年数据架构中最重要的变化。与“共享无”的架构不同，在真实世界的条件下很难管理，共享磁盘架构可以让您独立地扩展存储和计算。可伸缩且相对快速的对象存储（如 S3 和 GCS）的崛起意味着，您可以放松对构建数据库的约束。

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

所有大型数据集都是随着时间生成的。时间几乎总是数据集中的一个轴。每天都会产生新订单、新的出租车行程、新的日志记录、新的游戏。如果一个企业是静态的，既不增长也不缩小，数据将随着时间线性增长。对于分析需求意味着什么？显然，数据存储需求将线性增长，除非您决定修剪数据（稍后会详细介绍）。但是，随着时间的推移，计算需求可能不会有太大变化；大多数分析是针对最近的数据进行的。扫描旧数据是相当浪费的；它不会改变，那么为什么要花钱一遍又一遍地读取它呢？的确，您可能希望保留它以防万一您想对数据提出新问题，但构建包含重要答案的聚合是相当简单的。

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

这种对存储大小而非计算大小的偏见在系统架构中产生了实际影响。这意味着，如果您使用可伸缩的对象存储，您可能需要的计算量要比您预期的少得多。您甚至可能根本不需要使用分布式处理。

工作负载大小比整体数据大小要小

用于分析工作负载处理的数据量几乎肯定比您想象的要小。例如，仪表板往往是由汇总数据构建的。人们经常查看最近一小时、最近一天或最近一周的数据。较小的表往往被频繁查询，而巨大的表则更加选择性地查询。

几年前，我对 BigQuery 查询进行了分析，研究了年度支出超过 1000 美元的客户。90%的查询处理的数据量都不到 100 MB。我以多种方式对此进行了分析，以确保结果没有被运行大量查询的少数客户所扭曲。我还剔除了仅读取任何数据的 BigQuery 中的一个小子集的元数据查询。您必须在百分位数范围内很高才能进入吉字节范围，而且很少有查询在太字节范围内运行。

数据大小巨大的客户几乎永远不会查询大量数据

数据大小适中的客户往往会进行相当大的查询，但数据大小巨大的客户几乎永远不会查询大量数据。当他们这样做时，通常是因为他们正在生成报告，性能并不是真正的优先事项。一个大型社交媒体公司会在周末运行报告，为周一早上的执行人员做准备；这些查询是相当巨大的，但它们只是他们在其他时间运行的数十万个查询中的一小部分。

即使在查询巨大表时，您很少需要处理

大量数据。现代分析数据库可以进行列投影，只读取一部分字段，并进行分区修剪，只读取一个狭窄的日期范围。它们通常可以通过聚类或自动微分区化来利用数据中的局部性进行段消除等更进一步的处理。诸如在查询时计算压缩数据、投影和谓词下推等技巧可以减少 IO。较少的 IO 转化为较少的需要执行的计算，从而降低成本和延迟。

存在着严峻的经济压力促使人们减少处理的数据量。仅仅因为您可以扩展并快速处理某些内容并不意味着您可以廉价地这样做。如果您使用一千个节点来获取结果，那可能会花费您一大笔钱。我曾经在舞台上运行的一次 Petabyte 查询，以展示 BigQuery 的价格为 5000 美元。很少有人愿意运行如此昂贵的查询。

请注意，即使您不使用按字节扫描收费的定价模型，处理更少的数据的经济激励仍然存在。如果您有一个 Snowflake 实例，如果您可以使您的查询更小，那么您可以使用较小的实例，并支付更少的费用。您的查询速度会更快，您可以更多地并发运行，并且您通常会随时间支付更少的费用。

大多数数据很少被查询

被处理的数据中有很大一部分不到 24 小时的时间。当数据达到一周时，与最近一天相比，它可能被查询的可能性会降低 20 倍。一个月后，数据基本上就静止了。历史数据往往很少被查询，也许只有在运行罕见的报告时才会查询。

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

数据的静止意味着数据工作集的大小比您预期的要容易管理得多。如果您有一个包含了 10 年数据的 PB 表，您可能很少访问任何早于当前日期的数据，这可能压缩后不到 50GB。

大数据前沿不断后退

“大数据”的一个定义是“无法放入单个计算机的任何内容”。根据这个定义，符合资格的工作负载数量每年都在减少。

2004 年，当 Google MapReduce 论文被写作时，一个数据工作负载不适合单个商品机是非常普遍的。扩展是昂贵的。2006 年，AWS 推出了 EC2，而您唯一可以获得的实例大小是一个单核和 2GB RAM。有很多工作负载是不适合那台机器的。

然而，今天，在 AWS 上的标准实例使用的是一台物理服务器，配备 64 核心和 256GB RAM。那是两个数量级的 RAM。如果您愿意为内存优化实例多花一点钱，您可以获得另外两个数量级的 RAM。有多少工作负载需要超过 24TB 的 RAM 或 445 个 CPU 核心呢？

以前，更大的机器价格昂贵得多。但是，在云中，一个使用整个服务器的虚拟机的成本仅比使用服务器的八分之一的虚拟机多 8 倍。成本随着计算能力线性增长，一直增长到一些非常大的尺寸。实际上，如果您看看原始 Dremel 论文中使用的 3,000 个并行节点发布的基准测试，您可以在今天的单个节点上获得类似的性能（稍后将详细介绍）。

数据是一种负担

“大数据”的另一个定义是：“保留数据的成本低于弄清楚该丢弃什么的成本。”我喜欢这个定义，因为它概括了人们最终拥有大数据的原因。并不是因为他们需要它；他们只是懒得删除它。如果您考虑一下组织收集的许多数据湖，它们完全符合这一标准：巨大而混乱的沼泽，没有人真正知道它们包含什么或是否可以安全地清理它们。

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

除了法规，数据也可能成为针对您的诉讼的帮凶。就像许多组织实施有限的电子邮件保留政策以减少潜在责任一样，您数据仓库中的数据也可能被用来对付您。如果您有五年前的日志显示您的代码存在安全漏洞或错过了 SLA，保留旧数据可能会延长您的法律风险。我听说过一家公司为了防止其数据分析能力在法律发现过程中被使用而保持其数据分析能力的可能虚构的故事。

代码在不活跃维护时通常会遭受人们所说的“位腐烂”问题。数据也可能遭受相同类型的问题；也就是说，人们会忘记专业领域的精确含义，或者过去的数据问题可能已经从记忆中消失。例如，也许曾经有一个短暂的数据错误，将每个客户 ID 设置为 null。或者有一个巨大的欺诈交易，使得看起来 2017 年第三季度要好得多。从历史时间段提取数据的业务逻辑通常会变得越来越复杂。例如，可能有一个规则：“如果日期早于 2019 年，请使用收入字段，介于 2019 年和 2021 年之间，请使用 revenue_usd 字段，在 2022 年之后，请使用 revenue_usd_audited 字段。”您保留数据的时间越长，跟踪这些特殊情况就越困难。而且，并非所有情况都能轻松解决，特别是如果存在缺失数据的情况。

如果您保留旧数据，了解为什么保留它是很重要的。您是否一次又一次地询问相同的问题？如果是这样，以存储和查询成本来看，仅存储汇总数据是否会便宜得多？您是否将其保留以备不时之需？您是否认为可能会有新的问题需要提出？如果是这样，那么它有多重要？您真的需要吗？您只是一个数据囤积者吗？这些都是重要的问题，尤其是当您试图弄清楚保留数据的真正成本时。

您是否属于大数据的 1%？

大数据是真实存在的，但大多数人可能不需要担心它。您可以问一些问题，以确定自己是否是“大数据 1%”：

• 您是否真的产生了大量的数据？
• 如果是这样，您是否真的需要一次使用大量数据？
• 如果是这样，数据是否真的太大而无法放入一台计算机？
• 如果是这样，您确定自己不是只是一个数据囤积者吗？
• 如果是这样，您确定自己不会更好地进行汇总吗？

如果您对这些问题的任何一个回答是否定的，那么您可能是新一代数据工具的一个合适候选人，这些工具可以帮助您处理实际数据大小，而不是人们试图吓唬您说您可能会有的数据大小。