大数据的问题 -

2009年7月6日
第7卷，第6期

大数据的问题

如果你的数据集扩大到足够大，你所有的应用程序都会崩溃。典型的问题是什么？瓶颈通常出现在哪里？

Adam Jacobs，1010data 公司

“大数据”到底是什么？吉字节？太字节？拍字节？一段个人的记忆或许可以提供一些视角。在 20 世纪 80 年代后期，在哥伦比亚大学，我有机会接触到当时真正巨大的“磁盘”：IBM 3850 MSS（海量存储系统）。MSS 实际上是一个全自动的机器人磁带库和相关的暂存磁盘，以实现随机访问，即使不是完全即时的，也至少是完全透明的。在哥伦比亚大学的配置中，它总共存储了大约 100 GB 的数据。当我接触到它时，它已经快要被淘汰了，但在它的鼎盛时期，20 世纪 80 年代早期到中期，它曾被用来支持社会科学家访问当时毋庸置疑的“大数据”：整个 1980 年美国人口普查数据库²。

据推测，没有其他实际可行的方法可以为研究人员提供对如此庞大的数据集的便捷访问——以每吉字节接近 40,000 美元的价格³，一个 100-GB 的磁盘阵列将过于昂贵，并且要求操作员手动安装和卸载数千个 40-MB 的磁带将会严重拖慢进度，或者至少会严重限制可以提出的关于人口普查数据的问题类型。

即使在今天，100 GB 左右的数据库也不会被认为是微不足道的，尽管任何一家电脑商店都能以不到 100 美元的价格买到容量是其 10 倍的硬盘。美国人口普查数据库包含许多不同大小的数据集，但让我们稍微简化一下：100 吉字节足以存储至少基本的人口统计信息——年龄、性别、收入、种族、语言、宗教、住房状况和地点，打包在一个 128 位的记录中——适用于地球上每一个活着的人。这将创建一个包含 67.5 亿行和大约 10 列的表格。这还应该被认为是“大数据”吗？当然，这取决于你想用它来做什么。当然，你可以用 10 美元的磁盘存储它。更重要的是，任何有能力的程序员都可以在几个小时内在一台 500 美元的台式个人电脑上编写一个简单的、未经优化的应用程序，配备最少的 CPU 和 RAM，就可以处理这个数据集，并以完全合理的性能返回对简单聚合查询的答案，例如“每个国家按性别划分的年龄中位数是多少？”。

为了演示这一点，我尝试了一下，当然使用的是虚假数据——即一个包含 67.5 亿个 16 字节记录的文件，其中包含均匀分布的随机数据（图 1）。由于一个 7 位的年龄字段最多允许 128 个可能的值，一个用于性别的位只允许两个（我们假设没有 NULL 值），而 8 位用于国家最多允许 256 个（联合国拥有 192 个成员国），我们可以通过使用计数策略来计算年龄中位数：简单地创建 65,536 个桶——每个年龄、性别和国家的组合一个——并计算有多少记录落入每个桶中。我们通过确定每个性别和国家组的 128 个年龄桶的累积计数来找到年龄中位数：中位数是计数达到总数一半的桶。在我的测试中，这个算法主要受限于从磁盘获取数据的速度：在典型的 90 MB/秒的持续读取速度下，⁹ 一次读取数据大约需要 15 分钟多一点，可耻地没有充分利用 CPU 的全部时间。

事实上，我们的“世界人口”表将可以容纳在一台价值 15,000 美元的戴尔服务器的内存中，该服务器配备 128 GB 的 RAM。在内存数据上运行，我简单的按性别和国家划分的年龄中位数程序在不到一分钟的时间内完成。按照这样的标准，我不会犹豫称之为“大数据”，尤其是在像 CERN（欧洲核子研究组织）的 LHC（大型强子对撞机）这样的单个研究站点，预计每年将产生 150,000 倍的原始数据的世界中¹⁰。

然而，对于许多常用的应用程序来说，我们假设的 67.5 亿行数据集实际上会构成一个巨大的挑战。我尝试将我的虚假的 100 GB 世界人口普查数据加载到一个常用的企业级数据库系统（PostgreSQL⁶）中，该系统运行在相对强大的硬件上（一台配备 20 GB RAM 和两个太字节 RAID 0 磁盘的八核 Mac Pro 工作站），但在六个小时后不得不中止批量加载过程，因为数据库存储已经达到了原始二进制数据集大小的许多倍，并且工作站的磁盘几乎已满。（当然，部分原因是数据的“解压缩”。原始文件存储的字段是位打包的，而不是作为不同的整数字段，但随后的测试表明，数据库使用的存储空间是存储每个字段作为 32 位整数所需存储空间的三到四倍。这种数据“膨胀”是传统 RDBMS 的典型特征，不一定被视为问题，尤其是在一定程度上它是提高性能的策略的一部分。毕竟，磁盘空间相对便宜。）

我成功地加载了由最多 10 亿行组成的子集，这些子集仅包含三列：国家（8 位，256 个可能的值）、年龄（7 位，128 个可能的值）和性别（1 位，两个值）。这仅占原始数据的 2%，尽管它最终在 DBMS 中消耗了超过 40 GB 的空间。然后，我测试了以下查询，本质上与图 1 左侧的计算相同

SELECT country,age,sex,count(*) FROM people GROUP BY country,age,sex;

这个查询在小的数据子集上只需几秒钟即可运行，但随着行数超过 100 万（图 2），执行时间迅速增加。应用于整个 10 亿行，该查询花费了 24 个多小时，这表明 PostgreSQL 没有优雅地扩展到这个“大”数据集，大概是由于为给定的数据和查询选择了糟糕的算法。调用 DBMS 的内置 EXPLAIN 功能揭示了问题：虽然查询计划器为小表选择了一个合理的基于哈希表的聚合策略，但在较大的表上，它切换到按分组列排序——对于几百万行来说，这是一个可行但次优的策略，但对于十亿行来说，这是一个非常糟糕的策略。PostgreSQL 跟踪表中的每一列的最小值和最大值等统计信息（并且我验证了它已正确识别所有三列的范围），因此它可以自信地选择哈希表策略。然而，值得注意的是，即使表的统计信息未知，在十亿行上，进行初始扫描并确定分布所花费的时间也远少于开始全表排序。

PostgreSQL 在这里的困难在于分析存储的数据，而不是存储数据。数据库在加载或维护包含十亿条记录的数据库时没有出现问题；据推测，如果我有足够的可用磁盘空间，存储整个 67.5 亿行、10 列的表也不会有任何困难。

关于传统数据库中的大数据的真相是：数据更容易进入，而更难取出。大多数 DBMS 都设计用于高效的事务处理：在大型数据库中添加、更新、搜索和检索少量信息。数据通常以事务方式获取：想象一个用户登录到零售网站（检索帐户数据；会话信息添加到日志中），搜索产品（搜索和检索产品数据；获取更多会话信息），并进行购买（详细信息插入到订单数据库中；用户信息更新）。相当多的数据毫不费力地添加到数据库中，如果这是一个已经运营一段时间的大型网站，那么这个数据库可能已经构成了“大数据”。

这里没有病理；这个故事每天每秒都在世界各地以无数种方式重复上演。当我们想要利用几个月或几年积累的数据，并从中学习一些东西时，麻烦就来了——当然，我们希望在几秒钟或几分钟内得到答案！大数据的病理主要在于分析。这可能是一个略有争议的断言，但我认为事务处理和数据存储在很大程度上是已解决的问题。除了 LHC 规模的科学研究之外，今天很少有企业以如此快的速度生成数据，以至于获取和存储数据构成重大挑战。

至少在商业应用中，数据仓库通常被认为是解决数据库问题（数据进入但无法取出）的方案。数据仓库在传统上被定义为“专门为查询和分析而结构化的事务数据副本”⁴，并且通常理解为从操作数据库中批量提取数据，然后在不同的数据库中以更适合分析查询的形式重建（所谓的“提取、转换、加载”，有时是“提取、加载、转换”过程）。当面临真正庞大的数据积累时，仅仅说“我们将构建一个数据仓库”是不够的。数据必须如何结构化才能进行查询和分析，以及必须如何设计分析数据库和工具才能有效地处理数据？大数据改变了这些问题的答案，因为传统的技术，如基于 RDBMS 的维度建模和基于立方体的 OLAP（在线分析处理），结果证明要么太慢，要么太有限，无法支持提出关于仓库数据的真正有趣的问题。为了理解如何避免大数据的病理，无论是在数据仓库的背景下，还是在物理或社会科学中，我们需要考虑是什么真正使它“大”。

处理大数据

数据在拉丁语中意为“给予的东西”——尽管我们在英语中倾向于将其用作不可数名词，好像它表示一种物质——并且最终，几乎所有有用的数据都是“给予”我们的，要么是自然界给予的，作为对仔细观察物理过程的回报，要么是其他人给予的，通常是无意中给予的（考虑 Web 点击日志或零售交易，这都是大数据的常见来源）。因此，在现实世界中，数据不仅仅是一大堆随机数字；它往往表现出可预测的特征。首先，通常情况下，大多数数据集的最大基数——特别是被观察的不同实体的数量——与观察总数相比很小。

这并不奇怪。人类正在进行观察，或者正在被观察，目前人类数量不超过 67.5 亿，这设置了一个相当实际的上限。我们收集数据的对象，如果是人类世界的对象——网页、商店、产品、帐户、证券、国家、城市、房屋、电话、IP 地址——往往数量少于世界总人口。即使在科学数据集中，基数的实际限制通常是由诸如可用传感器的数量（例如，最先进的神经生理学数据集可能反映 512 个记录通道⁵）或仅仅是人类已经能够检测和识别的不同实体的数量（例如，最大的天文目录包括数亿个物体⁸）等因素设定的。

使大多数大数据变大的原因是随着时间和/或空间的重复观察。Web 日志每天记录数百万次对少量页面的访问；手机数据库每 15 秒存储一次数百万部手机的时间和位置；零售商拥有数千家商店、数万种产品和数百万客户，但每年记录数十亿甚至数百亿笔个人交易。科学测量通常以高时间分辨率（神经生理学中每秒数千个样本，粒子物理学中更多）进行，当它们涉及二维或三维空间时，真的开始变得巨大；fMRI 神经影像研究可以在一次实验中生成数百甚至数千吉字节的数据。总的来说，影像学是某些最大的大数据的来源，但大型图像数据的问题本身就是一个文章的主题；我在这里不再进一步考虑它们。

大多数大型数据集都具有固有的时间或空间维度，或两者兼而有之，这一事实对于理解大数据可能导致性能问题的一个重要方式至关重要，尤其是在涉及数据库时。例如，具有时间维度的数据，在大多数情况下，应该以至少部分的时间顺序存储和处理，以便在按时间顺序使用数据时尽可能多地保留引用的局部性，这似乎是直观明显的。毕竟，大多数重要的分析至少会涉及对一个或多个连续时间间隔内的观察进行聚合。例如，人们更有可能查看一组随机选择的客户在特定时间段内的购买行为，而不是查看一组随机选择的时间中“连续范围”的客户（无论如何定义）。

当我们考虑时间序列分析和预测的需求时，这一点就更加清楚了，这些分析和预测以依赖于顺序的方式聚合数据（例如，累积和移动窗口函数、前导和滞后运算符等）。这些分析对于回答关于时间数据的最真正有趣的问题是必要的，广义上讲：“发生了什么？”“为什么会发生？”“接下来会发生什么？”

然而，今天流行的数据库模型是关系数据库，这个模型明确地忽略了表中行的顺序¹。遵循这个模型，避开表固有顺序的想法的数据库实现，一旦数据量增长到不再适合内存时，将不可避免地以非顺序的方式检索数据。随着数据库中存储的数据总量增长，问题只会变得更加严重。为了在真正的大数据上实现高度依赖于顺序的查询的可接受性能，必须愿意考虑放弃纯粹的关系数据库模型，转而采用一种在实现级别上识别数据固有顺序概念的模型。幸运的是，这一点正在分析数据库领域中慢慢开始被认识到。

不仅在数据库中，而且在一般的应用程序编程中，大数据极大地放大了次优访问模式的性能影响。随着数据集大小的增长，选择尽可能在处理的各个阶段利用顺序访问效率的算法变得越来越重要。除了处理时间增加 10 倍（这很容易由高比例的非顺序访问导致）在单位是小时而不是秒时更加痛苦这个明显的点之外，不断增加的数据大小意味着数据访问变得越来越低效。当硬件的连续阶段的限制耗尽时，低效访问模式的代价会不成比例地增加：从处理器缓存到内存，内存到本地磁盘，以及——现在很少见！——磁盘到离线存储。

在今天的典型服务器硬件上，范围远大于缓存大小的完全随机的内存访问可能比纯粹的顺序访问慢一个数量级或更多，但完全随机的磁盘访问可能比顺序访问慢五个数量级（图 3）。即使是最先进的固态（闪存）磁盘，虽然它们的寻道延迟比磁性磁盘低得多，但在随机和顺序访问模式之间，速度也可能相差大约四个数量级。图 3 中所示测试的结果是每秒从磁盘或内存中 10 亿个长度（4 GB）的数组中读取的四字节整数值的数量；随机磁盘读取是针对在 1 到 10 亿之间随机选择的 10,000 个索引。

一个更广泛被低估的点是：在现代系统中，如图所示，随机内存访问通常比顺序磁盘访问慢。请注意，从磁盘的随机读取比顺序访问慢 150,000 多倍；SSD 将这个比率提高了不到一个数量级。在非常真实的意义上，所有现代形式的存储都只是在程度上有所改进，而不是在它们的本质上有所改进，相对于最古老和顺序的存储介质：磁带。

随机访问的巨大成本对大型数据集的分析具有重大影响（而当数据大小较小时，通常可以通过各种类型的缓存来缓解）。例如，考虑连接未按连接键存储和排序的大型表——例如，一系列 Web 事务和用户/帐户信息列表。事务表已按时间顺序存储，既因为这是收集数据的方式，也因为感兴趣的分析（例如，跟踪导航路径）本质上是时间性的。当然，用户表没有时间维度。

当按时间顺序使用事务表中的记录时，对连接的用户表的访问将有效地是随机的——如果表很大并且存储在磁盘上，则代价很高。如果有足够的内存来保存用户表，则通过将其保存在那里可以提高性能。由于 RAM 中的随机访问本身也很昂贵，并且 RAM 是一种稀缺资源，可能根本无法用于缓存大型表，因此在为分析目的构建大型数据库时（例如，在数据仓库中），最佳解决方案可能是令人惊讶地构建一个完全非规范化的表——也就是说，一个包含每个事务以及所有与分析相关的用户信息的表（图 4）。将 1000 万行、10 列的用户信息表非规范化到 10 亿行、4 列的事务表上，大大增加了必须存储的数据量（非规范化表的大小是原始表组合大小的三倍多）。如果在时间戳顺序中进行数据分析，但需要来自两个表的信息，那么消除用户表中的随机查找可以大大提高性能。虽然这不可避免地需要更多的存储空间，更重要的是，在分析过程中需要从磁盘读取更多的数据，但通过以顺序方式进行所有数据访问所获得的优势通常是巨大的。

硬性限制

数据分析的另一个主要挑战是由应用程序在可以处理的数据大小方面存在硬性限制所例证的。在这里，主要处理构成分析最后阶段的最终用户分析应用程序。有时，这些限制相对随意；考虑 Microsoft Excel 在最新版本之前的所有版本中工作表大小的 256 列、65,536 行的限制。在主内存以兆字节为单位衡量的日子里，这样的限制可能看起来是合理的，但在 2007 年，当 Microsoft 更新 Excel 以容纳多达 16,384 列和 100 万行时，这显然已经过时了。对于任何人来说都足够了吗？Excel 的目标用户不是处理真正庞大的数据集的用户，但事实仍然是，任何处理 100 万行数据集的人（可能是大型连锁店的客户列表及其总购买额）迟早可能会面临 200 万行的数据集，而 Excel 已经让自己出局了。

在设计应用程序以处理不断增加的数据量时，开发人员最好记住硬件规格也在不断改进，并牢记所谓的 ZOI（零一无穷）规则，该规则指出程序应该“允许零个 foo、一个 foo 或任意数量的 foo”¹¹。也就是说，限制不应该是随意的；理想情况下，应该能够使用软件完成硬件平台允许的所有操作。

当然，硬件——主要是内存和 CPU 限制——通常是软件对数据集大小限制的主要因素。许多应用程序被设计为将整个数据集读入内存并在那里处理；流行的统计计算环境 R⁷ 就是一个很好的例子。内存受限的应用程序自然比磁盘受限的应用程序表现出更高的性能（至少在它们执行的数据处理超越了单程、纯粹顺序处理的程度上），但是要求所有数据都适合内存意味着，如果你的数据集大于你安装的 RAM，你就倒霉了。在大多数硬件平台上，内存扩展的限制比磁盘扩展的限制要硬得多：主板只有这么多插槽可以填充。

然而，问题通常不止于此。像计算机硬件的大多数其他方面一样，最大内存容量随着时间的推移而增加；32 GB 不再是台式工作站的罕见配置，服务器通常配置的内存远不止于此。然而，不能保证内存受限的应用程序能够使用所有已安装的 RAM。即使在现代 64 位操作系统下，今天的许多应用程序（例如，Windows 下的 R）也只有 32 位可执行文件，并且地址空间限制为 4 GB——这通常转化为 2 或 3 GB 的工作集限制。

最后，即使在 64 位二进制文件可用的情况下——消除了绝对地址空间限制——来自 32 位代码时代的遗迹仍然过于频繁地渗透到软件中，尤其是在使用 32 位整数来索引数组元素时。因此，例如，64 位版本的 R（适用于 Linux 和 Mac）使用有符号 32 位整数来表示长度，将数据帧限制为最多 2³¹-1，或大约 20 亿行。因此，即使在具有足够 RAM 来保存数据的 64 位系统上，像前面提到的世界人口普查示例这样的 67.5 亿行数据集最终也太大，R 无法处理。

分布式计算作为大数据的策略

任何给定的计算机都有一系列绝对和实际的限制：内存大小、磁盘大小、处理器速度等等。当其中一个限制耗尽时，我们会依赖下一个限制，但会付出性能代价：内存数据库比磁盘数据库快，但配备 2 GB RAM 的 PC 无法将 100 GB 的数据集完全存储在内存中；配备 128 GB RAM 的服务器可以，但在下一代配备两倍内存插槽的服务器问世之前，数据很可能增长到 200 GB。

然而，今天主流计算机硬件的美妙之处在于，它价格便宜且几乎可以无限复制。今天，购买八台配备八个处理核心和 128 GB RAM 的现成的“商品”服务器比购买一台配备 64 个处理器和 1 TB RAM 的单个系统更具成本效益。尽管绝对数字会随着时间的推移而变化，但在计算机体系结构发生根本性变化之前，一般原则在可预见的未来很可能仍然成立。因此，分布式计算是分析超大型数据集的最成功策略也就不足为奇了。

将分析分布在多台计算机上会产生显著的性能成本：即使使用千兆和万兆以太网，带宽（顺序访问速度）和延迟（因此，随机访问速度）都比 RAM 差几个数量级。然而，与此同时，最高速的本地网络技术现在在带宽方面已经超过了大多数本地连接的磁盘系统，并且网络延迟自然远低于磁盘延迟。

因此，在网络中的其他节点上存储和检索数据的性能成本与（在随机访问的情况下，可能远小于）使用磁盘的成本相当。然而，一旦大型数据集以这种方式分布到多个节点，就可以通过分布处理来获得巨大的优势——只要分析适合并行处理。

关于这个主题已经有很多可以说的，并且可以继续说下去，但在分布式大型数据集的背景下，标准本质上与前面讨论的那些标准相关：正如通过顺序访问维护引用的局部性对于依赖于磁盘 I/O 的进程至关重要（因为磁盘寻道很昂贵），因此，在分布式分析中，处理必须包含一个显著的组件，该组件在数据中是局部的——也就是说，不需要同时处理数据集的许多不同部分（因为不同处理域之间的通信很昂贵）。幸运的是，大多数现实世界的数据分析都包含这样的组件。诸如搜索、计数、部分聚合、多个字段的逐记录组合以及许多时间序列分析（如果数据以正确的顺序存储）之类的操作可以在每个计算节点上独立执行。

此外，在需要节点之间通信的情况下，通信通常发生在数据被广泛聚合之后；例如，考虑对存储在多个节点上的数十亿行数据取平均值。每个节点只需要向生成最终结果的节点通信两个值——总和和计数。并非每个聚合都可以如此简单地计算，作为本地子聚合的全局聚合（例如，考虑找到全局中位数而不是平均值的任务），但许多重要的聚合可以，并且对于其他更复杂的任务，也存在分布式算法，这些算法可以最大限度地减少节点之间的通信。

当然，大数据的分布式分析也带来了一系列“陷阱”。主要问题之一是工作在节点之间的非均匀分布。理想情况下，每个节点都将有相同数量的独立计算要完成，然后才能跨节点合并结果。如果情况并非如此，那么工作量最大的节点将决定我们必须等待结果多长时间，这显然会比工作均匀分布时等待的时间更长；在最坏的情况下，所有工作都可能集中在一个节点中，我们将根本无法从并行性中获得任何好处。

这是否是一个问题往往取决于数据在节点之间的分布方式；不幸的是，在许多情况下，这可能与以这样一种方式分布数据的必要性直接冲突，即每个节点上的处理是局部的。例如，考虑一个数据集，该数据集由从 1,000 个传感器站点以 15 秒间隔收集的 10 年观测数据组成。每个站点有超过 2000 万次观测；并且，由于典型的分析将涉及时间序列计算——例如，查找相对于移动平均值和标准偏差的异常值——我们决定按每个传感器站点的时间顺序存储数据（图 5），分布在 10 个计算节点上，以便每个节点获得 100 个站点的所有观测数据（每个节点总共 20 亿次观测）。不幸的是，这意味着每当我们只对一个或几个传感器的结果感兴趣时，我们的大多数计算节点都将完全空闲。行是按传感器还是按时间戳聚类，对于不同查询将执行的并行度有很大的影响。

当然，我们可以按时间顺序存储数据，每个节点一年，以便每个节点都表示每个传感器站点（在计算开始时，我们需要在连续节点之间进行一些通信，以“启动”时间序列计算）。如果我们突然需要对过去一年的数据进行密集分析，这种方法也会遇到困难。以两种方式存储数据将为两种类型的分析提供最佳效率——但数据集越大，两个副本就越有可能对可用的硬件资源来说数据量太大。

分布式系统的另一个重要问题是可靠性。正如四引擎飞机在给定时期内比配备两个同等引擎的飞机更有可能发生引擎故障一样，10 台机器的集群也更有可能需要服务呼叫 10 倍。不幸的是，在集群中复制的许多组件——电源、磁盘、风扇、布线等——往往不可靠。当然，有可能使集群任意抵抗单节点故障，主要是通过跨节点复制数据。令人高兴的是，这里可能有一些协同作用的空间：复制数据以提高不同类型分析的效率，如上所述，也可以提供针对不可避免的节点故障的冗余。然而，再一次，数据集越大，维护数据的多个副本就越困难。

元定义

我在这里试图概述一些在分析大数据时可能出现的问题：许多现成的软件包无法扩展到大型问题；当大部分处理转移到存储层次结构的下层时，避免次优访问模式的至关重要性；以及为了存储和分布式处理效率而复制数据。我还没有回答我在开头提出的问题：什么是“大数据”？

我将尝试给出一个元定义：大数据在任何时间点都应该被定义为“其大小迫使我们超越当时流行的久经考验的方法的数据”。在 20 世纪 80 年代早期，它是如此庞大的数据集，以至于需要机器人“磁带猴子”来换入和换出数千盘磁带。在 20 世纪 90 年代，也许，它是任何超越 Microsoft Excel 和台式 PC 边界的数据，需要 Unix 工作站上的严肃软件来分析。如今，它可能意味着数据太大，无法放入关系数据库并借助台式统计/可视化软件包进行分析——数据，也许，其分析需要大规模并行软件在数十台、数百台甚至数千台服务器上运行。

无论如何，随着对越来越大的数据集的分析变得例行化，定义将继续转变，但有一件事将保持不变：在领先优势方面取得成功的人将是那些能够超越标准的、现成的技术，并理解硬件资源的真实性质以及可供他们使用的全套算法的开发人员。问

参考文献

Codd, E. F. 1970. 大型共享数据库的关系模型。《通讯》13(6): 377-387。
IBM 3850 海量存储系统；http://www.columbia.edu/acis/history/mss.html。
IBM 档案：IBM 3380 直接存取存储设备；http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380.html。
Kimball, R. 1996. 《数据仓库工具包：构建维度数据仓库的实用技术》。纽约：John Wiley & Sons。
Litke, A. M., 等人。2004. 眼睛告诉大脑什么？大规模记录视网膜输出活动系统的开发。《IEEE 核科学汇刊》51(4): 1434-1440。
PostgreSQL：世界上最先进的开源数据库；https://postgresql.ac.cn。
R 统计计算项目；https://r-project.org.cn。
斯隆数字巡天；http://www.sdss.org。
吞吐量和接口性能。《Tom's Winter 2008 硬盘指南》；http://www.tomshardware.com/reviews/hdd-terabyte-1tb,2077-11.html。
WLCG（全球 LHC 计算网格）；http://lcg.web.cern.ch/LCG/public/。
零一无穷规则；http://www.catb.org/~esr/jargon/html/Z/Zero-One-Infinity-Rule.html。

喜欢还是讨厌？请告诉我们

[email protected]

ADAM JACOBS 是 1010data 公司的资深软件工程师，他在该公司领导 Tenbase（该公司超高性能分析数据库引擎）的持续开发等工作。他在大数据集的分布式处理方面拥有超过 10 年的经验，他的早期职业生涯始于康奈尔大学威尔医学院（他在那里担任访问研究员）和加州大学洛杉矶分校的计算神经科学家。他拥有加州大学伯克利分校的神经科学博士学位和哥伦比亚大学的语言学学士学位。

最初发表于 Queue vol. 7, no. 6—
在数字图书馆中评论本文

更多相关文章

Qian Li, Peter Kraft - 事务和无服务器天生一对
数据库支持的应用程序是无服务器计算令人兴奋的新领域。通过紧密集成应用程序执行和数据管理，事务性无服务器平台实现了许多在现有无服务器平台或基于服务器的部署中无法实现的新功能。

Pat Helland - 任何其他名称的身份
新兴的系统和协议既收紧又放宽了我们对身份的理解，这很好！它们使完成工作更容易。REST、IoT、大数据和机器学习都围绕着身份的概念，这些概念被刻意保持灵活且有时模糊。身份的概念是我们分布式系统基本机制的基础，包括互换性、幂等性和不变性。

雷蒙德·布鲁姆，贝齐·拜尔 - 实现数字永恒
当今的信息时代正在为世界所依赖的数据创造新的用途和新的管理方式。世界正在从熟悉的物理实体转向更接近信息本质的新型表示方式。我们需要流程来确保知识的完整性和可访问性，以保证历史将被了解和真实。

格雷厄姆·科莫德 - 数据草图
你是否曾感到被无尽的信息流所淹没？这似乎就像大量的新邮件和短信要求持续的关注，还有需要接听的电话、需要阅读的文章和需要应门的敲门声。将这些碎片拼凑在一起以跟踪重要的事情可能是一个真正的挑战。为了应对这一挑战，流数据处理模型已经变得越来越流行。目标不再是捕获、存储和索引每一个细微的事件，而是快速处理每一个观察结果，以便创建当前状态的摘要。