MotherDuck:大数据已死


十多年来,人们很难从他们的数据中获得可操作的洞察力,这一事实被归咎于其规模。诊断结果是 "你的数据对你那微不足道的系统来说太大了",而治疗方法是购买一些能够处理大规模的新的花哨的技术。当然,在大数据工作组购买了所有新的工具并从遗留系统迁移之后,人们发现他们仍然难以理解他们的数据。

他们还可能注意到,如果他们真的注意到了,数据规模其实根本就不是问题所在

10 多年来,我一直是推动大数据发展的追随者之一。我是 Google BigQuery 的创始工程师,作为团队中唯一真正喜欢公开演讲的工程师,我必须前往世界各地参加会议,帮助解释我们将如何帮助人们抵御即将到来的数据爆炸。我曾经在台上直播查询一个PB,证明无论你的数据有多大,多坏,我们都能搞定,没问题。

在接下来的几年里,我花了很多时间调试客户在使用 BigQuery 时遇到的问题。我与人合着了两本书,并真正深入研究了产品的使用方式。2018 年,我转向产品管理,我的工作分为与客户交谈(其中许多是世界上最大的企业)和分析产品指标。

我了解到的最令人惊讶的事情是大多数使用“大查询”的人并不真正拥有大数据。即使是那些这样做的人也倾向于使用仅使用其数据集大小的一小部分的工作负载。当 BigQuery 面世时,对许多人来说就像科幻小说一样——您实际上无法以任何其他方式快速处理数据。然而,科幻小说现在已经司空见惯,更传统的数据处理方式也迎头赶上。

这篇文章将证明大数据时代已经结束。它运行良好,但现在我们可以不再担心数据大小,而是专注于我们将如何使用它来做出更好的决策。

我会展示一些图表;这些都是凭记忆手绘的。如果我确实可以访问确切的数字,我将无法分享它们。但重要的部分是形状,而不是确切的值。
图表背后的数据来自对查询日志、交易事后分析、基准测试结果(已发布和未发布)、客户支持票、客户对话、服务日志和已发布的博客文章的分析,以及一些直觉。

大多数人没有那么多数据
客户数据大小服从幂律分布。最大客户的存储量是第二大客户的两倍,第二大客户的存储量是第二大客户的一半,依此类推。因此,虽然有客户拥有数百 PB 的数据,但大小很快就会下降。有成千上万的客户每月支付不到 10 美元的存储费用,即 0.5TB。在大量使用该服务的客户中,数据存储大小的中位数远低于 100 GB。

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

为了理解为什么大数据很少见,思考数据的实际来源是有帮助的。假设您是一家拥有 1000 名客户的中型企业。假设您的每位客户每天都会下一个包含一百个订单项的新订单。这是相对频繁的,但它仍然可能少于每天生成的 1 兆字节数据。三年后你仍然只有 1 GB,而要产生 1 TB 则需要几千年。

或者,假设您的营销数据库中有一百万条线索,并且您正在开展数十个活动。您的线索表可能仍然不到 1 GB,并且跟踪每个活动中的每个线索可能仍然只有几 GB。在合理的扩展假设下,很难看出这如何增加海量数据集。

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

存储和计算分离中的存储偏差
现代云数据平台都将存储和计算分开,这意味着客户不受单一外形因素的束缚。这不仅仅是横向扩展,可能是过去 20 年数据架构中最重要的单一变化。与在现实世界条件下难以管理的“无共享”架构不同,共享磁盘架构让您可以独立增加存储和计算。

随着时间的推移,计算需求可能不需要改变太多;大多数分析都是针对最近的数据进行的。扫描旧数据非常浪费;它不会改变,那么你为什么要花钱一遍又一遍地阅读它?诚然,您可能希望保留它以防万一您想对数据提出新问题,但构建包含重要答案的聚合非常简单。

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

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

几年前,我对 BigQuery 查询进行了分析,查看了每年花费超过 1000 美元的客户。90% 的查询处理的数据少于 100 MB。我以多种不同的方式对此进行了切片,以确保不仅仅是几个客户运行了大量查询来扭曲结果。我还删除了纯元数据查询,它们是 BigQuery 中根本不需要读取任何数据的查询的一小部分。在进入千兆字节之前,您必须在百分位数范围内走得相当高,而且在 TB 范围内运行的查询非常少。

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

大多数数据很少被查询
得到处理的数据中有很大一部分不到 24 小时。到数据保存一周时,查询的可能性可能比最近一天低 20 倍。一个月后,数据大多就在那里。历史数据往往很少被查询,也许当有人正在运行一个罕见的报告时。

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

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

数据是一种责任
如果您要保留旧数据,最好了解为什么要保留它。你是否一遍又一遍地问同样的问题?如果是这样的话,就存储和查询成本而言,仅存储聚合是否会便宜得多?你把它留着以备不时之需吗?您是否认为您可能想提出新的问题?如果是这样,它有多重要?您真正需要它的可能性有多大?你真的只是一个数据囤积者吗?这些都是要问的重要问题,尤其是当您试图计算出保留数据的真实成本时。

你是大数据的百分之一吗?
大数据是真实存在的,但大多数人可能不需要担心。您可以提出一些问题来确定您是否是“大数据 One-Percenter”:

  • 您真的会生成大量数据吗?
  • 如果是这样,您真的需要一次使用大量数据吗?
  • 如果是这样,数据真的太大而无法放在一台机器上吗?
  • 如果是这样,你确定你不仅仅是一个数据囤积者吗?
  • 如果是这样,您确定总结一下会更好吗?

如果您对这些问题中的任何一个回答“否”,那么您可能是新一代数据工具的理想人选,这些工具可以帮助您以实际拥有的规模处理数据,而不是人们试图恐吓您以为您可能拥有的规模有一天。


不同意见:
大数据已死……大数据万岁

最近的一篇博客文章宣称“大数据已死”。并非巧合的是,此声明是由支持 DuckDB 的人员发布的,DuckDB 是一种针对本地进程内部署优化的数据库系统。

我借鉴了数据库研究社区的经验教训,认为任何组织都有大数据、中型数据和小数据需求。作为数据基础设施工具构建者,我们不应因为数据的大小或数据需求而羞辱人们,而是应该优化如何帮助人们从数据中获得所需的洞察力——无论是报告、可视化还是可视化的形式ML 模型——与大小无关,使用他们最熟悉的模式。我们应该学会接受——并承认——各种规模的数据的合法存在!

我是Ponder的联合创始人和加州大学伯克利分校的副教授。至此,我加入数据库研究社区已有十多年了。当“大数据”成为热门的新流行词时,我就在那里——尽管数据库社区自 1970 年代中期以来就举办了 VLDB(超大型数据库)会议。在 Stonebraker 和 DeWitt 宣布MapReduce 是一个巨大的倒退时,我进入了这个社区(2008 年)。当 MongoDB 声称是“网络规模”时,我就在附近(2010 年)。当 Spark 首次出现时,我也在(2012 年)。

在过去的十年里,我一直致力于支持小型、中型和大型数据分析环境的系统,包括电子表格和可视化系统,以及最近的 pandas——一种经常用于中小型环境的系统.
我关心的主要是因为我认为数据基础设施社区已经有足够多的流行语了!哪里有空白,哪里就会出现一个新的流行语。十年后,在不情愿地接受它之后,我开始喜欢上“大数据”。所以这是对每个人的绝望请求,请不要杀死“大数据”。

声明 1:与传统数据管理系统相比,用于 OLAP 的 NoSQL 系统停滞不前
评级:部分正确
真理:OLAP 的纯 NoSQL 系统相对于传统数据管理系统停滞不前,因为传统系统慢慢扩展了对 NoSQL 功能的支持


主张 2:大多数人没有那么多数据
评级:误导
老生常谈:如果人们不收集任何数据,他们就没有多少数据。

主张 3:在存储和计算分离中存在偏向存储的偏见:随着存储的增长,计算保持不变
评级:误导
老生常谈:计算需求不会随着时间的推移保持不变——需求会随着日常工作负载的不同而变化。数据大小和计算维度的灵活性是关键。

主张 4:大多数历史数据很少被查询
评级:部分正确
老生常谈:虽然查询最近的数据更多,但许多关键任务需求需要查询所有数据


主张 5:大数据前沿不断后退。
评级:部分正确
老生常谈:更现代的服务器可以自己处理“大数据”,但与按需扩展和缩减集群中的低成本机器相比,始终配置它们可能非常昂贵

主张 6:数据是一种责任
评价:大部分不真实
老生常谈:除非你在逃避法律,否则对于大多数组织而言,数据是一种资产。

一个有用的类比:潜水与浮潜
思考大数据工具和中小型数据工具之间区别的一种方法是水肺潜水和浮潜之间的区别。

潜水和浮潜的共同点是它们都是令人愉快的水上活动。当您佩戴水肺装备时,您可以留在水面附近,也可以潜到深处。当您佩戴通气管时,您必须靠近水面。水肺装备可以完全替代呼吸管,并提供超越它的功能。有些人可能会说水肺潜水装备很笨重,但对于大多数尝试过这两种潜水的人来说,水肺潜水比必须经常返回水面更令人愉快和有益!基本上,当一个人可以潜入水中时,为什么只停留在表面上呢?

同样,有时需要深入研究数据,有时需要表面层面的洞察力——最好使用一种工具,让您可以做到这两点。