本文作者：JORDAN TIGANI；编译：Cointime Freya

十多年来，人们很难从大数据中获得可操作的见解，这一事实一直被归咎于其规模。当时的诊断是，“你的数据对于你那微不足道的系统来说太大了”，而解决办法是购买一些可以处理大规模数据的新技术。当然，在大数据工作组购买了所有新工具并从遗留系统迁移之后，人们发现他们仍然难以理解他们的数据。他们也许已经注意到，数据量其实根本不是真正的问题。

2023年的世界看起来与大数据警报开始响起时不同。所预测的数据大灾难并没有发生。数据量可能略微变大了，但硬件却以更快的速度变大了。供应商仍在大力宣传他们的扩展能力，但从业人员开始思考这与他们现实世界的问题有何关联。

我是谁，我为什么关心该话题？

10多年来，我一直是推动大数据发展的追随者之一。我是谷歌BigQuery的创始工程师，作为团队中唯一一个真正喜欢公开演讲的工程师，我可以前往世界各地参加会议，帮助解释我们将如何帮助人们抵御即将到来的数据爆炸。我曾经在舞台上现场查询 1 PB的数据，证明无论你的数据有多大、损坏程度多严重，我们都能处理，没有问题。

在接下来的几年里，我花了大量的时间来调试客户在使用BigQuery时遇到的问题。我与人合著了两本书，深入研究了该产品的使用情况。2018年，我转到了产品管理部门，我的工作分为与客户交谈（其中许多是世界上最大的企业）与分析产品指标。

最让我惊讶的是，大多数使用“大查询”的人并没有真正的大数据，即使是那些倾向于使用只占其数据量一小部分的工作负载的人。当BigQuery问世时，对于许多人来说就像科幻小说一样——实际上，你无法以任何其他的方式快速处理数据。然而，以前的科幻小说中的东西现在已经司空见惯，处理数据的更传统的方法已经赶上来了。

关于本篇文章

本篇文章将说明，大数据时代已经结束。它有一个良好的运行，但现在我们可以不必再担心数据量，而是关注我们如何利用它做出更好的决策。我将展示一些根据记忆手绘的图表。如果我有权限得到确切数字，那么我就无法分享它们了。但重要的部分是形状，而不是确切的数值。

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

必不可少的介绍幻灯片

在过去的10年里，每一个大数据产品的推广活动都从类似的幻灯片开始的：

在谷歌，我们使用这个版本的幻灯片已经很多年了。当我转到SingleStore时，他们也在使用他们自己的版本，该版本拥有相同的图表。我看到其他几个供应商也有类似的东西。这是“恐慌”幻灯片。大数据来了！你得买我卖的东西！

所传达的信息是，处理数据的老方法是行不通的。数据生成的加速将使过去的数据系统陷入泥潭，而任何接受新理念的人都将能够超越他们的竞争对手。

当然，虽然产生的数据量正在增加，但这并不意味着它对每个人来说都是一个问题——数据分布不均。大多数应用程序并不需要处理大量的数据。这导致了具有传统架构的数据管理系统正在复苏；SQLite、Postgres、MySQL都在强劲增长，而 “NoSQL”"甚至是 “NewSQL ”系统却停滞不前。

多数人并没有那么多数据

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

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

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

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

我们的一个投资者决定找出分析数据的真正规模，并调查了他的投资组合公司，其中一些是退出后的公司（要么已经IPO，要么已经被更大的组织收购）。这些都是科技公司，它们可能会向更大的数据规模倾斜。这位投资者发现，在他的投资组合中，最大的B2B公司有大约1 TB的数据，而最大的B2C公司有大约10 TB的数据。然而，大多数公司拥有的数据其实要少得多。

为了理解为什么说大数据量是罕见的，思考一下数据的实际来源是有帮助的。想象一下，你是一家拥有1,000名客户的中等规模的企业，假设每位客户每天都会下一个包含一百个订单项的新订单。这是相对频繁的，但是每天生成的数据可能还不到1 MB。三年后，你仍然只有1 GB，而要产生1 TB的数据则需要数千年的时间。

另外，假设你的营销数据库中有100万条线索，而且你正在运行几十项活动。你的线索表可能还不到1 GB，在每次活动中跟踪每个线索可能仍然只有几 GB。在合理的规模假设下，很难看出这是如何增加海量数据集的。

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

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

现代云数据平台都将存储和计算分开，这意味着客户不受单一形式因素的束缚。这不仅仅是横向扩展，可能是过去 20 年数据架构中最重要的变化。共享磁盘架构取代了在现实条件下很难管理的 “无共享 ”架构，让你的存储和计算独立增长。可扩展且速度相当快的对象存储（如S3和GCS）的兴起，意味着你可以放松对如何建立数据库的限制。

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

所有的大数据集都是随着时间的推移而生成的。在数据集中，时间几乎总是一个轴。每天都有新的订单进来。新的出租车乘坐次数、新的日志记录、正在玩的新游戏......如果一个企业是静态的，既不增长也不收缩，那么数据就会随着时间线性增长。这对分析需求来说意味着什么？显然，数据存储需求将线性增长，除非你决定删除数据（后面会有更多介绍）。但是随着时间的推移，计算需求可能不会有太大的变化；大多数分析都是根据最近的数据进行的。

扫描旧的数据是相当浪费的，它没有任何变化，那么为什么要一遍又一遍地花钱读它呢？的确，你可能希望保留它，以防你想要提出一个关于数据的新问题，但构建包含重要答案的聚合其实是非常简单的。

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

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

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

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

几年前，我对BigQuery的查询进行了分析，研究了花费超过1000美元/年的客户。90%的查询处理的数据小于100 MB。我对此进行了多方面的分析，以确保不仅仅是几个客户运行了大量查询，从而歪曲了结果。我还删除了元数据查询，这是BigQuery中查询的一个子集，根本不需要读取任何数据。在你进入TB范围之前，您必须在百分位范围上进行相当高的操作，并且很少有查询在TB范围内运行。

拥有庞大数据规模的客户几乎从不查询大量数据

数据规模适中的客户通常会进行第一规模的查询，但数据量巨大的客户几乎从不查询大量的数据。当他们这样做的时候，通常是因为他们正在生成一份报告，而性能并不是真正的优先事项。一家大型社交媒体公司将在周末发布报告，为周一早上的高管会议做准备。这些查询量相当庞大，但它们只是一周内运行的数十万次查询的一小部分。

即使在查询巨型表时，也很少需要处理大量数据。现代分析数据库可以进行列投影，来读取字段的子集，并进行分区修剪，以只读取一个较窄的日期范围。它他们通常可以更进一步，通过聚类或自动微分区消除数据中的局部性。其他的一些技巧，如对压缩数据进行计算、投影和谓词下推等，都是在查询时可以做更少IO的方法。而IO越少，需要做的计算就越少，从而转化为更低的成本和延迟。

严重的经济压力激励人们减少处理的数据量。仅仅因为你可以快速扩展和处理某些内容，并不意味着你可以以较低的成本来做到这一点。如果您使用1,000个节点来获得一个结果，那可能会让您付出很大的代价。我曾在舞台上运行Petabyte查询，以展示BigQuery，零售价为5000美元。很少有人会想运营这么昂贵的东西。

请注意，即使您没有使用按扫描字节数付费的定价模式，处理较少数据的经济动机也适用。如果你有一个 Snowflake 实例，如果你能使你的查询更小，你可以使用一个更小的实例，并支付更少的费用。你的查询会更快，您可以同时运行更多的查询，而且一般来说，随着时间的推移，你通常可以支付更少的费用。

大多数数据很少被查询

在被处理的数据中，有很大一部分是不到24小时的。当数据保存一周时，数据被查询的可能性可能比最近一天低20倍。一个月后，大部分数据被搁置在那里。历史数据往往很少被查询，除非有人需要整合一个罕见的报告。

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

数据的静态化意味着数据工作集的大小比你想象的更容易管理。如果你有一个PB级的表，其中有10年的数据，你可能很少访问任何比今天更早的数据，这可能有不到50GB的压缩量。

数据的静止意味着数据工作集的规模比您预期的更易于管理。如果您有一个包含10年数据的PB表，您可能很少访问比当天更早的数据，这些数据的压缩量还可能不到50 GB。

大数据前沿不断后退

 “大数据 ”的定义是 '任何不适合在单台机器上运行的东西"。根据这一定义，符合条件的工作负载的数量每年都在减少。

在2004年撰写谷歌MapReduce论文的时候，数据工作负载不适合单台商品机器的情况非常普遍。扩大规模的成本很高。2006年，AWS推出了EC2，你唯一能得到的实例大小是一个单核和2GB RAM。有很多工作负载不适合那台机器。

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

过去，大型机器要贵得多。然而，在云端，使用整个服务器的VM的成本只比使用1 / 8服务器的VM贵8倍。成本随着计算能力线性增加，直到达到一些非常大的规模。事实上，如果您查看dremel原始论文中发布的使用3,000个并行节点的基准测试，那么现在你可以在单个节点上获得类似的性能（稍后会做详细介绍）。

数据是一种责任

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

保存数据的成本比存储物理字节的成本要高。根据GDPR和CCPA等法规，你需要跟踪某些类型数据的所有使用情况。有些数据需要在一定时间内删除。如果你在parquet文件中的电话号码，在你的数据库的某个地方放置太久，你可能违反了法定要求。

除了法规之外，数据还可以成为对你提起诉讼的辅助手段。正如许多组织为了减少潜在的责任而强制执行有限的电子邮件保留策略一样，你存储在数据库中的数据也同样可以用来对付你。如果你有五年前的日志，显示您的代码中有安全缺陷或未达到SLA，那么保留旧数据将会延长你的法律风险。如果您有五年前的日志，显示您的代码中有安全缺陷或未达到SLA，保留旧数据会延长您的法律风险。我听说过一个可能是虚构的故事，一家公司对其数据分析能力保密，以防止它们在法律发现过程中被使用。

当代码没有得到积极维护时，它往往会受到人们所说的 "比特腐烂 "的影响。数据也会遭受同样类型的问题；也就是说，人们忘记了专门领域的确切含义，或者过去的数据问题可能已经从记忆中淡忘。例如，可能存在将每个客户的 ID 设置为空的短暂数据错误。或者是发生了一场巨大的欺诈交易，使得2017年第三季度看起来比实际情况要好很多。通常情况下，从历史时间段提取数据的业务逻辑会变得越来越复杂。例如，可能有这样一条规则："如果日期早于2019年，则使用revenue字段，2019年至2021年之间使用revenue_usd字段，2022年之后使用revenue_usd_audited字段。" 你保留数据的时间越长，就越难跟踪这些特殊情况。而且，并不是所有的情况都能轻易解决，特别是在缺少数据的情况下。

如果你要保留旧数据，最好想清楚为什么要保留它。你是否在不断地问同样的问题？如果是这样的话，那么在存储和查询成本方面，仅仅存储聚合数据不是要便宜得多吗？留着它是以备不时之需吗？你是否认为有新的问题想问？如果有，它有多重要？你真正需要它的可能性有多大？你真的只是一个数据囤积者吗？这些都是需要问的重要问题，特别是当你试图计算保留数据的真正成本时。

你是大数据中的百分之一吗？

大数据是真实存在的，但大多数人可能并不需要为此担心。你可以问自己一些问题，来判断你是否是 “大数据中的百分之一”。

如果你对这些问题的任何一个回答是否定的，那么你可能是新一代数据工具的一个很好的候选人，这些工具可以帮助你处理你实际拥有的数据规模，而不是恐慌也许有一天可能拥有的规模。