Google BigQuery 创始工程师：大数据已“死”

当然，在分析系统中的情况有所不同，但在 OLAP 中，我们看到了从内部部署到云的巨大转变，并且实际上没有任何可扩展的云分析系统可与之抗衡。

大多数人没有那么多数据

根据上述“大数据即将到来”的图表，用不了多久每个人都会数据淹没。然而十年过去了，我们“预期的未来”仍然未能成为现实。我们可以几种方式验证这一点：查看数据（定量），询问数据量是否与人们的感知一致（定性），从第一原则出发（归纳）思考这个问题。

当初在 BigQuery 工作的时候，我花了很多时间研究客户规模。相关的数据是保密的，所以我不能直接分享任何数字。但是，我可以说绝大多数客户的总数据存储量都不到 1TB。当然，也有一些客户拥有大量数据，但大多数组织，甚至一些巨头企业，他们的数据量也属于中等水平。

客户的数据规模呈幂律分布。存储量最大的客户是第二大客户的两倍，而第二大客户是第三大客户的两倍，依此类推。因此，虽然有些客户拥有数百 PB 的数据，但在分布图上这个规模的下降速度很快。成千上万的客户每月支付的数据存储费用不足 10 美元，即 0.5TB。在大量使用我们的服务的客户中，数据存储规模的中位数远低于 100 GB。

在与行业分析师（Gartner、Forrester 等）交谈的过程中，我们获得了进一步的肯定。当论及我们拥有处理海量数据集的能力时，他们会耸耸肩，然后说：“话虽如此，但绝大多数企业的数据仓库都小于 1 TB。”业内人士给我们的反馈普遍是，适合数据仓库的数量级约为 100 GB。我们的基准测试主要瞄准的也是这个尺度。

我们的一位投资者有意找出分析数据的真实规模，并调查了他自己投资的公司。其中有一些是科技公司，这些公司的数据量普遍偏大。他发现，他投资的最大的 B2B 公司拥有大约 1TB 的数据，而最大的 B2C 公司拥有大约 10TB 的数据。事实上，大多数公司的数据远没有那么多。

为了理解为什么大数据如此罕见，我们需要思考数据的实际来源。假设你拥有一家中型企业，客户规模约为 1000 名。假设每位客户每天都会下一个新订单，其中包含一百个货品。这个频率相对已经很高了，但实际每天生产的数据仍然不足 1MB。三年后，也只有 1GB，而要产生 1 TB 的数据则需要几千年。

再举一个例子，假设你的营销数据库中有 100 万个潜在客户，而且你同时开展了十个活动。即便是这样，数据的规模仍然不到 1GB，而且跟踪每个活动中的每个潜在客户也只需要几GB。在合理的扩展假设下，很难看出数据规模如何能达到海量级。

再举一个具体的例子，2020年～2022年，我在 SingleStore 工作，当时这是一家快速发展的公司，收入可观，而且有成为独角兽企业的潜质。将这家公司的财务数据仓库、客户数据、营销活动跟踪以及服务日志等所有数据都累加起来，总量也只有几GB。无论怎么看，都算不上大数据。

在存储与计算分离的环境中，存储规模增长远大于计算

现代云数据平台都主张存储与计算分离，这意味着，客户不会受到单一外形因素的束缚。这可能是过去二十年中数据架构最重要的变化。在现实世界中“完全不共享”的架构不便于管理，与之不同，共享磁盘架构可以单独增加存储空间或计算空间。随着可扩展且速度非常快的对象存储（如 S3 和 GCS）的兴起，我们可以放宽构建数据库的许多限制。

在实际工作中，数据规模的增长速度远快于计算规模。虽然存储与计算分离的优点在于，你可以随时扩展其中一个，二者的扩展速度无需同步。然而，很多人对此有误解，结果引发了很多关于大数据的讨论，因为大规模计算所需的技术不同于大数据所需的技术。我们应该思考一下为什么会出现这种情况。

所有的大数据集都是经年累月产生的。数据集的发展离不开时间这个维度。每天都有新订单、新的出租车业务、新的日志记录、新的游戏记录等等。如果业务是静态的，既不增长也不收缩，数据将随时间推移呈线性增长。这对分析需求意味着什么？很显然，数据存储的需求将呈线性增长，除非你修剪数据（稍后再详细讨论）。但随着时间的推移，计算的需求可能不会发生太大变化，大多数分析都是针对近期的数据进行的。扫描旧数据会造成巨大的浪费，旧数据又不会变化，为什么要花钱一遍又一遍地看呢？诚然，你仍然希望保留旧数据，以防针对数据提出新问题，但通过聚合数据总结出重要的答案是非常简单的。

很多时候，当数据仓库的客户从没有分离存储与计算的环境转移到分离的环境时，他们的存储使用量会大幅增长，但他们的计算需求往往不会改变。在 BigQuery 中，我们有一个客户是世界上最大的零售商之一。他们有一个本地数据仓库，大约有 100 TB 的数据。迁移到云后，他们最终的数据量约为 30 PB ，增加了 300 倍。如果他们的计算需求也以相似的数量级增加，那么他们的分析开销将高达十亿美元。然而实际上，他们这部分的开销很小。

这种对存储规模超越计算规模的趋势对系统架构产生了实际影响。这意味着，如果使用可扩展的对象存储，你需要使用的计算量远低于预期。你甚至可能不需要使用分布式处理。

00448b7f7e0fe937ed9ded24ece529c3.png

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

分析工作负载的数据量远低于你的想象。举个例子，我们通常会利用聚合数据构建仪表板。人们可以通过仪表板查看过去一个小时、前一天或上周的数据。规模较小的表往往查询频率也更高，而大型表需要更有针对性的查询。

几年前，我对 BigQuery 查询进行了分析，并仔细分析了每年开销超过 1000 美元的客户。90% 的查询处理的数据少于 100 MB。我按照不同的方式，对这些查询进行了切片，以确保这不是少数几个客户运行了大量查询导致的畸形结果。此外，我还删除了纯元数据查询，因为这部分查询根本不需要读取任何数据。最后发现，规模在GB级别的查询非常少，而达到TB级别的查询只有极少数。

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

通常，数据量适中的客户会进行大量的查询，但拥有大规模数据的客户几乎从不查询海量数据。即使查询海量数据，通常也是为了生成报告，也就是说这些查询并不注重性能。一家大型社交媒体公司会在周末发布报告，为周一早上向高管汇报做准备， 这些查询非常庞大，但他们一周内运行的查询数量多达几十万个，而这些查询只占到很小一部分。

即使查询巨型表，也很少需要处理大量数据。现代分析数据库可以通过列投影仅读取字段的子集，还可以通过分区修剪来仅读取一定范围内的日期。还可以更进一步，利用分段消除，通过聚类或自动微分区来利用数据中的局部性。此外，还可以通过压缩数据计算、投影和谓词下推等技巧减少查询中I/O的使用。I/O使用量下降，意味着计算量降低，最终的效果是降低成本和延迟。

巨大的经济压力促使人们减少处理的数据量。即便你可以快速地横向扩展和处理某些数据，但并不意味着相应的成本低廉。使用一千个节点来获得结果，可能会让你付出沉重的代价。我曾在台上展示过 BigQuery 的 PB 级别的查询零售价为 5,000 美元。很少有人愿意运行如此昂贵的查询。

请注意，即使你没有使用按扫描字节数付费的定价模型，经济的压力也会让你减少处理的数据量。假设你有一个 Snowflake 实例，如果可以缩小查询的规模，你就可以使用更小的实例，而且相应的费用也更低。你的查询速度更快，而且还可以并行运行更多服务，通常费用也更低。

0de00015b0950513eb2be131bcb92e65.png

大多数数据很少被查询

我们日常处理的数据中，很大一部分是 24 小时内产生的。保存时间超过一周的数据，被查询到的概率会下降 20 倍。一个月后，大多数数据就无人问津了。历史数据往往很少被查询，只有需要生成某个罕见的报告时才会用到。

数据存储的时间模式通常都很扁平。虽然很多数据很快就会被丢弃，但很多数据会源源不断地附加到表的末尾。最近一年的数据大约只占30%，但99%的访问针对的都是这些数据。最近一个月的数据约为 5%，但访问量高达80%。

数据静止意味着，实际的数据集规模比预期更易于管理。虽然你可能有一个 PB 级别的表，其中包含近10年的数据，但大多数时候你访问的只有当天的数据，这之前的数据很少，因此实际的数据规模可能不到 50GB。

1d47bcd2a0e8200079eff69492f658f7.png

大数据前沿不断后退

一种定义“大数据”的方式是，仅凭一台机器处理不了的数据量。根据这个定义，符合条件的工作负载数量每年都在减少。

2004 年，在 Google MapReduce 论文发布之际，数据工作负载超出一台机器的处理能力的情况非常普遍。扩大规模的开销非常昂贵。2006 年，AWS 推出了 EC2，你可以获得的实例只有单核和 2GB 内存，很多负载都处理不了。

然而，如今，AWS 上的标准实例是具有 64 个核心和 256GB 内存的物理服务器。内存上差了一个数量级。如果你愿意多花一点钱购买高级别的内存，则可以获取可以获得再高两个数量级的内存。有多少工作负载的需求超过了 24TB 的内核或 445 个 CPU 核心？

过去，大型机器的成本非常昂贵。然而，在云中，占据整个服务器的虚拟机的成本是只使用1/8服务器的虚拟机的8倍。也就是说，成本随着计算能力呈线性增长，直到达到一些非常大的规模。事实上，根据 Google 发布的 dremel 论文，他们公布的基准测试使用了 3,000 个并行节点，如今你只需要一个节点就可以获得类似的性能（稍后详细讨论）。

bd67fbbe14c6588409733b2b3fb7a471.png

数据是一种责任

还有一种定义大数据的方式是“当****保存数据的成本低于判断丢弃哪些数据的成本时”。我喜欢这个定义，因为其中概括了为什么数据的规模会发展到大数据的程度。不是因为人们需要这些数据，而是人们懒得删除这些数据。想一想许多组织收集的数据湖，它们就非常符合这个要求：巨大、凌乱的沼泽，没有人知道里面究竟包含什么，也不清楚是否可以安全地清理掉。

保存数据的成本高于存储物理字节。根据 GDPR 和 CCPA 等法规，你需要记录某些类型数据的所有使用情况。有些数据需要在一定时间内删除。如果电话号码在数据湖中的停留时间过长，就有可能违反了法定要求。

除了监管的作用之外，数据还可能制造一些麻烦。许多组织由于害怕担责任而限制电子邮件的保留时长，数据仓库中的数据同样可能会引发这类的麻烦。如果你保留了五年前的日志，这些日志会显示你的代码中存在安全漏洞或错过了 SLA，保留这些旧数据可能会导致你负担的法律风险加大。

没有得到积极维护的代码可能会出现人们所说的“位腐烂”。数据可能会遇到相同类型的问题，也就是说，人们忘记了特定字段的确切含义，或者过去的数据问题可能已经从记忆中消失了。例如，曾有一段时间出现过将每个客户 ID 设置为空的数据错误。从历史时间段提取数据的业务逻辑会变得越来越复杂。例如，你有一个这样的规则：“2019年之前使用字段revenue；2019年～2021年之间使用字段revenue_usd；2022年之后使用字段revenue_usd_audited。”你保存数据的时间越长，就越难跟踪这些特殊情况。并非所有这些问题都可以轻松解决，尤其是在缺少数据的情况下。

如果你想保留旧数据，就需要搞清楚保留的原因。你是否需要反复解决同样的问题？如果是，从存储和查询成本来看，仅存储聚合结果是不是更加实惠？你保留这些数据是为了不时之需吗？你是否会提出新的问题？如果是，这些问题重要吗？你真正需要这些数据的可能性有多大？你喜欢囤积数据吗？这些都是重要的问题，尤其是当你尝试计算保留数据的真实成本时。

dc0eb4ed396af0a6e87e9cfc6f895bc9.png

你是否真的需要大数据？

大数据是真实存在的，但大多数人都没有这种需求。你可以通过以下问题来判断自己是否真的需要大数据：

• 你真的会生成大量数据吗？
• 如果是，你真的需要一次使用大量数据吗？
• 如果是，你的数据量真的过于庞大，无法放在一台机器上吗？
• 如果是，你确定不仅仅是因为你喜欢囤积数据吗？
• 如果是，你确定汇总数据不是更好的选择吗？

对于上述问题，如果你的答案中有一个是“否”，那么新一代的数据工具才是你的理想选择，这些工具可以帮助你处理合理规模的数据量。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

术提升。**

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！