Skip to main content

第 11 章 对移动靶的偏见式看法：复杂分析（A Biased Take on a Moving Target: Complex Analytics）

原文：Readings in Database Systems, Fifth Edition (2015)，Chapter 11: A Biased Take on a Moving Target: Complex Analytics，by Michael Stonebraker。原书文本采用 CC BY-NC-SA 4.0 许可；本译文按同一许可发布。

作者：Michael Stonebraker

在过去 5-10 年里，出现了新的分析工作负载，它们比典型的商业智能（BI）用例更加复杂。例如，互联网广告商可能想知道：“过去四天内购买 Apple 电脑的女性，与同一时期购买 Ford 皮卡的女性，在统计上有什么不同？” 下一个问题可能是：“在我们所有广告中，基于她们的点击可能性，向女性 Ford 买家展示哪一个广告最有利可图？” 这些是今天数据科学家提出的问题，代表了一个与商业智能专家运行的传统 SQL 分析非常不同的用例。人们普遍认为，未来一二十年里数据科学会完全取代商业智能，因为它代表了一种更复杂的数据仓库挖掘新洞察的方法。因此，本文关注数据科学家的需求。

我会先描述我所理解的数据科学家的工作职责。在清洗和整理数据之后（这目前占用了他们绝大多数时间，并在数据集成一节中讨论），他们通常会执行如下迭代：

Until (tired) {
  Data management operation(s);
  Analytic operation(s);
}

换言之，他们有一个迭代式发现过程：先隔离出一个感兴趣的数据集，然后在其上执行某种分析操作。这往往会提示他们换一个数据集尝试同一种分析，或者在同一个数据集上尝试不同分析。总体来说，数据科学区别于商业智能的地方在于，分析内容是预测建模、机器学习、回归等，而不是 SQL 分析。

通常，分析由一条计算流水线构成。例如，Tamr 有一个模块可以在规模化条件下，对一组记录（假设有 N 条）执行实体合并（去重）。为了避免暴力算法的 N ** 2 复杂度，Tamr 会识别一组“特征”，把它们划分为不太可能共同出现的范围，根据这些范围为每条记录计算（可能是多个）“桶”，并行重洗数据使其按桶号分区，对每个桶去重，合并结果，最后从各个重复簇中构造复合记录。这条流水线一部分面向 SQL（分区），一部分面向数组分析。Tamr 似乎是数据科学工作负载的典型代表：它是一条大约有六个步骤的流水线。

有些分析流水线是“一次性”的，只在一批记录上运行一次。然而，大多数生产应用本质上是增量式的。例如，Tamr 会先在初始输入记录批次上运行，随后当新的或变化的输入记录到达时，必须周期性处理新的“增量”。增量操作有两种方法。如果增量以“微批”的形式每隔一段时间（比如一天）处理一次，那么可以把下一个增量加入之前已经处理过的批次，然后每当输入变化时都在所有数据上重新运行整条流水线。这样的策略会非常浪费计算资源。因此，我们会关注这样一种情况：初始批处理操作之后，必须运行增量算法。这种增量算法要求在每次迭代时把分析的中间状态保存到持久存储中。虽然 Tamr 流水线长度约为 6，但其中每个步骤都必须保存到持久存储，以支持增量操作。由于保存状态是一种数据管理操作，这会让分析流水线的有效长度变成 1。

最终的“实时”方案，是使用流式平台连续运行增量分析服务，如新 DBMS 技术一节中讨论的那类平台。根据新记录到达速率的不同，上述任一种方案都可能更合适。

大多数复杂分析都是面向数组的，也就是说，它们是一组定义在数组上的线性代数操作。有些分析是面向图的，例如社交网络分析。显然，数组可以在基于表的系统上模拟，而图可以在表系统或数组系统上模拟。因此，本文后面会讨论这个用例需要多少种不同架构。

有些问题处理稠密数组，也就是几乎所有单元格都有值的数组。例如，NYSE 所有证券随时间变化的收盘价数组就是稠密的，因为每支股票在每个交易日都有收盘价。另一方面，有些问题是稀疏的。例如，如果把社交网络用例表示成矩阵，那么只有以某种方式相关联的每对人员才会有单元格值。显然，这个矩阵会非常稀疏。稀疏数组上的分析与稠密数组上的分析差别很大。

本节会讨论规模化条件下的这类工作负载。如果只想在“小数据”上运行这样的流水线，那么任何方案都可以很好地工作。

数据科学平台的目标，是支持这种迭代式发现过程。我们先从一个令人遗憾的事实开始。大多数数据科学平台基于文件，和 DBMS 毫无关系。大量分析代码运行在 R、MatLab、SPSS、SAS 中，并操作文件数据。此外，许多 Spark 用户也在从文件读取数据。Lawrence Berkeley Labs 的 NERSC 高性能计算（HPC）系统就是这种状态的一个典型例子。这台机器几乎完全用于复杂分析；然而，由于配置限制，我们完全无法让 Vertica DBMS 在其上运行。此外，大多数“大科学”项目会从裸金属开始构建整套软件栈。这种状态很可能会持续下去，DBMS 也可能不会成为这个市场的参与者。不过，也有一些有希望的迹象，例如遗传数据开始部署在 DBMS 上，1000 Genomes Project [144] 就基于 SciDB。

在我看来，文件系统技术有几个重大缺点。首先，元数据（校准、时间等）往往没有被捕获，或者被编码在文件名中，因此不可搜索。其次，数据科学工作负载中用于完成数据管理部分的复杂数据处理能力并不存在，必须以某种方式编写。第三，文件数据很难在同事之间共享。我知道一些项目会连同解析程序一起导出数据。接收方可能无法重新编译这个访问程序，或者程序会生成错误。在接下来的讨论中，我会假设数据科学家会随着时间推移希望使用 DBMS 技术。因此，后文不再进一步讨论基于文件的方案。

在这个背景下，表 1 给出了数据科学平台的分类。按照上面的假设，要执行数据管理部分，需要一个 DBMS。这个 DBMS 可以有两种风味。第一，它可以是面向记录的，例如关系行存储、NoSQL 引擎；也可以是面向列的，例如大多数数据仓库系统。在这些情况下，DBMS 数据结构并不聚焦于分析需求，而分析基本都是面向数组的，因此更自然的选择会是数组 DBMS。后者的优势在于，执行分析时不需要从记录或列结构转换过来。因此，数组结构在性能上会有天然优势。此外，面向数组的存储结构本质上是多维的，而表结构通常是一维的。这也可能带来更高性能。

第二个维度涉及分析与 DBMS 之间的耦合。一方面，它们可以彼此独立；你运行一个查询，把结果复制到另一个地址空间中运行分析。在分析流水线（通常长度为 1）结束时，结果可以保存回持久存储。这会导致 DBMS 与分析之间大量数据 churn。另一方面，也可以把分析作为用户定义函数运行在与 DBMS 相同的地址空间中。显然，紧耦合方案会降低数据 churn，并应带来更好的性能。

从这个角度看，如表 1 所示有四个格子。在左下角，过去典型代表是 Map-Reduce；最近 Spark 已经取代 Map-Reduce，成为最受关注的平台。Spark 中没有持久化机制，它依赖 RedShift、H-Base 或其他系统来完成这个目的。因此，在 Spark 中，用户会在某个 DBMS 中运行查询生成数据集，把它加载进 Spark，然后在其中执行分析。Spark 支持的 DBMS 都是面向记录或列的，因此分析需要转换为数组表示。

右下角的一个显著例子是 MADLIB [85]，它是 RDBMS Greenplum 支持的用户定义函数库。其他厂商最近也开始支持其他替代方案；例如 Vertica 支持 R 中的用户定义函数。右上角则是带内置分析的数组系统，例如 SciDB [155]、TileDB [56] 或 Rasdaman [26]。

松耦合紧耦合
数组表示SciDB、TileDB、Rasdaman
表表示Spark + HBaseMADLib、Vertica + R

表 1：数据科学平台的一种分类

在本文剩余部分，我们讨论性能影响。第一，当从表 1 左下角移动到右上角时，人们会预期性能提升。第二，大多数复杂分析会归约为一小组“内层循环”操作，例如矩阵乘法、奇异值分解和 QR 分解。所有这些都是计算密集型操作，通常是浮点代码。大多数人都接受，面向硬件的流水线优化可以让这类代码的性能差距接近一个数量级。因此，调用硬件优化 Intel MKL 库的 BLAS、LAPACK 和 ScaLAPACK 等库，会比不使用硬件优化的代码快得多。当然，硬件优化会对稠密数组计算产生很大差异，因为大部分工作都在浮点计算上。它对稀疏数组的重要性会低一些，因为索引问题可能主导计算时间。

第三，提供近似答案的代码比产生精确答案的代码快得多。如果你能够接受近似答案，就会节省大量时间。

第四，高性能计算（HPC）硬件通常被配置为支持大型批处理作业。因此，它们往往被组织成由网络连接计算服务器和存储服务器的结构，其中程序必须在计算服务器缓存中为自己的存储需求预分配磁盘空间。这显然与 DBMS 相冲突，因为 DBMS 期望作为服务连续运行。因此，你需要意识到，在 HPC 环境中使用 DBMS 系统可能会遇到麻烦。一个有趣的探索领域是：HPC 机器能否在不牺牲性能的情况下，同时处理交互式工作负载和批处理工作负载。

第五，可扩展的数据科学代码总是在计算机网络中的多个节点上运行，并且往往受网络限制 [55]。在这种情况下，必须仔细关注网络成本，TCP-IP 可能不是好选择。通常 MPI 是性能更高的替代方案。

第六，我们测试过的大多数分析代码无法扩展到大型数据集规模，要么因为主内存耗尽，要么因为生成的临时数据过大。务必在你期望于生产中运行的数据集规模上测试任何候选平台！

第七，分析流水线的结构至关重要。如果你的流水线长度为 1，那么紧耦合几乎肯定是好主意。另一方面，如果流水线长度为 10，松耦合的表现几乎也会同样好。在增量操作中，应预期流水线长度为 1。

总体来说，我们知道的所有方案都有可扩展性和性能问题。此外，上面提到的大多数代表系统都是快速移动的靶子，因此性能和可扩展性无疑会提高。总之，表 1 中哪些格子能站住脚、哪些不能，将很有趣。商业市场会成为最终裁判！

在我看来，复杂分析当前正处在“狂野西部”阶段，我们希望下一版红宝书能够识别出一组核心奠基论文。在此期间，还有大量研究有待完成。具体来说，我们鼓励在这个领域做更多基准测试，以识别现有平台缺陷，并推动进一步研究与开发，尤其是那些考察端到端任务、同时涉及数据管理任务和分析任务的基准测试。这个领域移动很快，因此基准结果可能是短暂的。这也许是件好事：我们正处在一个各个项目应该彼此学习的阶段。

目前，人们对核心分析任务（例如凸优化）的定制并行算法很感兴趣，其中一部分来自数据库社区。看看这些算法能否被纳入分析型 DBMS 会很有趣，因为它们通常并不遵循传统数据流执行风格。这里的一个例子是 Hogwild! [133]，它通过允许共享内存中的无锁并行获得非常快的性能。Google Downpour [49] 和 Microsoft 的 Project Adam [39] 都把这个基本思想适配到深度学习的分布式语境中。

另一个值得探索的领域是外存算法。例如，Spark 要求你的数据结构能够放入集群中各机器主内存总量之内。这类方案会很脆弱，并且几乎肯定会有可扩展性问题。

此外，一个有趣主题是图分析的理想方法。可以构建专门的图分析系统，例如 GraphX [64] 或 GraphLab [105]，并将它们连接到某种 DBMS。或者，也可以用数组分析来模拟这类代码，如 D4M [95] 所倡导的那样；也可以用表分析来模拟，如 [90] 所建议的那样。再次，让方案空间充分繁荣，并由商业市场做裁判吧！

最后，许多分析代码使用 MPI 进行通信，而 DBMS 总是使用 TCP-IP。此外，ScaLAPACK 等并行稠密分析包会把数据组织成跨计算集群节点的块循环组织 [40]。我不知道有任何 DBMS 支持块循环分区。消除分析包与 DBMS 之间的这种阻抗失配是一个有趣的研究领域，也是 Intel 赞助的 Big Data ISTC [151] 所瞄准的方向。

评论：Joe Hellerstein​

2015 年 12 月 6 日

我对这个领域的看法与 Mike 相当不同，无论从商业角度还是研究机会角度都是如此。根本上，我建议对这个领域采取“大帐篷”方法。数据库人有很多东西可以贡献，但如果我们能与其他人良好合作，效果会好得多。

先看看行业。首先，Mike 所说的这类高级分析不会取代 BI。BI 行业很健康，而且还在增长。更根本地说，正如著名统计学家 John Tukey 在其探索式数据分析奠基著作中指出的，一张图表往往比一个复杂统计模型更有价值。尊重图表！

话虽如此，高级分析和数据科学市场确实在增长，并且即将发生变化。但不同于 BI 市场，这不是一个数据库技术目前扮演重要角色的品类。这个空间中的既有巨头是 SAS，一家每年营收数十亿美元的公司，并且明确不是数据库公司。当风险投资人观察这个领域的公司时，他们寻找的是“下一个 SAS”。SAS 用户不是数据库用户。R 这样的开源替代方案用户也不是数据库用户。如果你像 Mike 那样假设“数据科学家会想使用 DBMS 技术”，尤其是单体式“分析 DBMS”，那你就是在强流中逆水而行。

对于高级分析市场，一个更自然的切入方式是问自己：什么是 SAS 的严重威胁？谁能从企业当前花在那里的钱中咬下一大口？下面是一些可以考虑的起点：

  1. 开源统计编程：这包括 R 和 Python 数据科学生态（NumPy、SciKit-Learn、iPython Notebook）。这些方案目前扩展性并不好，但人们正在积极努力解决这些限制。这个生态可能比 SAS 演化得更快。

  2. 与大数据平台的紧耦合。当数据足够大时，性能要求可能会把用户“拖”到一个新平台上，也就是已经承载其组织大数据的平台。因此，人们对 Spark/MLLib、PivotalR/MADlib 和 Vertica dplyr 等平台的 “DataFrame” 接口感兴趣。注意，高级分析社区高度偏向开源。云在这里也是一个有趣平台，并且不是 SAS 拥有优势的地方。

  3. 分析服务。这里我指的是以分析方法为核心的交互式在线服务：推荐系统、实时欺诈检测、预测性设备维护等等。这个空间对响应时间、请求扩展、容错和持续演化有很激进的系统要求，而 SAS 这样的产品并不解决这些要求。今天，这些服务大多由定制代码构建。这无法跨行业扩展，因为大多数公司招不到能在这个层面工作的开发者。因此，从表面看，这里有机会把这种技术商品化，覆盖多数用例。但这个市场还处在早期：分析服务平台能否被做得足够简单以实现商品化部署，还有待观察。如果技术继续演化，那么基于云的服务也可能在这里拥有重要颠覆机会。

在研究前沿，我认为跳出数据库盒子并积极协作至关重要。对我来说，这几乎不言自明。计算机科学中几乎每个子领域都在以某种方式研究大数据分析，来自许多领域的聪明人正在快速学习他们自己关于数据和规模的经验。我们可以愉快地与这些人一起玩，也可以无视他们并让自己受损。

那么，数据库研究在哪些地方可以对这个领域产生重大影响？在我看来，一些不错的可能性包括：

  1. 可扩展性的新方法。我们已经成功展示，并行数据流（想想 MADlib、MLlib 或 Ordonez 在 Teradata 的工作）可以在不对系统架构施暴的情况下，把你带到实现可扩展分析的很远地方。知道这一点很有用。展望未来，我们能否做出比在分区数据上运行并行数据流明显更快、更可扩展的东西？这是否必要？Hogwild! 在这里引发了一些最大的兴奋；注意，这是一项横跨数据库和机器学习社区的工作。

  2. 面向分析服务的分布式基础设施。正如上面提到的，分析服务是一个有趣的创新机会。这条线上的系统基础设施问题仍相当开放。分析服务架构的主要组件是什么？它们如何拼接在一起？组件之间需要怎样的数据一致性？所谓 Parameter Server 目前是一个热门主题，但它只解决了拼图的一部分。已有一些关于模型在线服务、演化与部署的初步工作。我希望后续会更多。

  3. 分析生命周期与元数据管理。在这一点上我同意 Mike。分析往往是一种高度依赖人的活动，除了核心统计建模之外，还涉及数据探索与转换。在整个过程中，需要管理大量上下文，以理解模型和数据产品如何在一系列工具与系统中被开发出来。数据库社区在这个领域有高度相关的视角，包括工作流管理、数据血缘和物化视图维护。VisTrails 是这个领域中已经在实践中使用的研究例子。这也是工业界的迫切需求，尤其是那些考虑现场分析工具和系统真实多样性的工作。

评论脚注​

  • John Tukey, Exploratory Data Analysis. Pearson, 1977.
  • 示例：Ordonez, C. “Integrating K-means clustering with a relational DBMS using SQL.” TKDE 18(2), 2006；以及 Ordonez, C. “Statistical Model Computation with UDFs.” TKDE 22(12), 2010.
  • Ho, Q., et al. “More effective distributed ML via a stale synchronous parallel parameter server.” NIPS 2013.
  • Crankshaw, D., et al. “The missing piece in complex analytics: Low latency, scalable model management and serving with Velox.” CIDR 2015。另见 Schleier-Smith, J. “An Architecture for Agile Machine Learning in Real-Time Applications.” KDD 2015.
  • 见 http://www.vistrails.org。