大数据架构：Push、Pull 还是 Search in Place

在 Splunk 峰会有个令人惊讶的共同主题，它是个和大数据架构相关的问题：“我应该使用那种方法和架构呢？push（推送）、pull（拉取）还是 search in place（靠近数据搜索）？”

在理论上，基于 pull（pull-based）模式的系统其容错性是最好的。你只需要简单地等待结果，当预期的时间到达时，一次性导入那些完成的日志即可。虽然这可以在任何时间发生，但通常它们会是夜间批处理作业的一部分。并且如果什么地方出了错，你可以简单重新运行作业。但是，从 Splunk 上得到的通常观点则是和基于 pull 模式的设计理念截然相反的。

对于 pull 模式最大的批评在于它缺乏实时性的信息。你必须要等一天、一周，甚至是一个月的时间来获取关键信息，而这在很多公司被认为是不可接受的。产生这种认识的原因在于：当获取到这些信息的时候，再采取相应的行动可能就太迟了。

另一个批评在于基于 pull 模式的系统在实际使用中有些脆弱。假设有一个处理只能在深夜运行，那么当发生错误时，相关的作业就只能在第二天再重新运行，这进一步增加了延迟。

对于 Spark 企业版（Splunk Enterprise），它的核心产品采用了基于 push（push-based）模式的系统作为其缺省模型。在靠近数据源的地方，会安装一个转发器（forwarder），或者将其内建到数据生成器（generator）或收集器（collector）中，然后将事件推送到索引器中（indexer）。对于那些没有使用 Splunk 的场景，事件则会推送到某些数据仓库中，比如 SQL Server Columnstore、Hadoop 或者 Cassandra 中。

理论上基于 push 模式的设计会有更多的问题，因为它依赖于数据流目的点持续性激活且保持可用状态，所以必须依靠一些复杂的回退机制来确保在网络中断和目的服务器失败的情况下，数据不会丢失。

实际情况是，从很多商家的报告中都可以看到其使用良好。这些产品的用户可以近乎实时的访问他们所需要的报告。

除了 pull 和 push 模式，还有第三个选项，它很简单，你根本不需要移动数据，相反你会使用search in place（搜索靠近数据） 技术，这有些像 map-reduce。这种技术带来最大的好处是你不必为移动数据而预先付出时间和网络带宽上的损耗。特别是你的报告仅仅包括一部分数据或者是总结性试图（summarized view）时，这种处理方式的效果就会更好。Splunk 的 Hunk 产品，其后端基于 Hadoop，在设计上就倾向于这种模型。

这种模型不好的一面在于其对数据源带来了非常大的压力（译者注：搜索的计算量引起）。在一个客户的展示中，他们引用了其采用 ETL 作业，以及后来采用 Splunk Enterprise 的主要原因在于，他们的搜索在其 Dynatrace（译者注：Dynatrace 是美国一家应用性能管理软件公司）服务器上引起了非常严重的性能问题。

还有第四种模型，我们称之为“pull on demand（根据需要拉取数据）”。这是一种反模式，即你的搜索引擎只会在搜索启动后，将所需要的原始数据拉取过来进行计算。通常当搜索完成后，搜索引擎会马上将拉取的数据丢弃掉，这意味着每次搜索进行时，都需要重新进行代价高昂的拉取操作。在最佳设计方案中，会将拉取过来的数据保存在本地缓存。但这仍然意味着搜索的运行时间将是不可预测的，因为数据会在本地缓存中移进或移出。先前提到的 Hunk，其在 verbose 模式下就会按照这样的方式运行。

哦，别跑远，我们正在这讨论大数据架构。对于小规模的数据，pull on demand（根据需要拉取数据）也许是一种可接受的设计模式。

InfoQ 提问: 看完这篇文章，对于性能和可靠性，你更倾向于 push、pull 还是 search-in-place 的设计呢?

查看英文原文： Big Data Architecture: Push, Pull, or Search in Place?