[译]LinkedIn如何解决信息流处理难题

原文： Stream Processing Hard Problems Part 1: Killing Lambda

译者：杰微刊兼职翻译张迪

我们生活在这样一个时代，想在世界各地事情发生之时就获得消息，一个基于我们的好恶即时更新数字内容的时代；一个信用卡欺诈、安全漏洞、设备故障和站点中断并需要尽快检测并纠正的时代。这是一个大规模事件捕获和实时处理的时代。实时事件处理(信息流处理)并不是新的，并且现在已经无处不在，已经达到相当大的规模。

信息流处理存在有许多难题。这是一系列文章的第一篇，我将讨论一些我们面临的重要问题，并试图在LinkedIn中解决。

在这篇文章中，我将重点关注人们经常在信息流处理应用程序中使用Lambda架构的主要原因和建议的替代品。有很多的之前的材料解释过Lambda，所以我将跳过这些基础的内容。Lambda为信息流处理应用程序解决了一些重要的问题。然而，有一些关于Lambda架构的关键问题：例如，在建构处理管道的热(nearline)和冷(offline)路径方面的重复开发工作、处理的额外开销、服务之前合并线上和线下处理结果的开销。

应该注意的是，这篇文章不是为了覆盖现有离线数据分析现存的Hadoop和Spark-based分批处理解决方案良好运行的场景。虽然LinkedIn为了信息流处理使用了Apache Samza，在这篇文章中大部分讨论的也适用于其他流媒体系统。

让我们深入研究一下为什么发人员倾向于使用复制(nearline+offline)处理模型的原因。

一、使信息流处理产生准确的结果

这是一个很好的研究领域，有一些伟大的论文就是写的这个主题。然而，它并不总是很容易地让人理解，为什么信息流处理并不总是产生精确的结果。显而易见的问题，这个问题让我放大的一个例子，来看看这个问题通常是如何体现在LinkedIn上的。

LinkedIn是部署在多个地理分布的数据中心中。对网站问题来说，一个星期内，我们数据中心之间的透明故障转移用户流量有很多次。现在想象一下，当一个用户查看广告(AdViewEvent)与另一个事件生成的信息流时，当用户点击一个广告(AdClickEvent)时，我们有一个连接事件生成的信息流(Kafka主题)的流处理应用程序。这个应用程序会产生AdQualityEvent来指示一个广告是好还是坏。应用程序逻辑可能非常简单，比如：如果用户点击一个广告，并在一分钟内看到这个广告，那说明那么广告是好的。

正如你在上面的图片中所看到的，两个数据中心的事件都是复制的，所以，信息流处理器从两个数据中心得到了所有事件的超集。

在正常操作流处理器的情况下得到了AdClickEvent一分钟内接收的AdViewEvent。然而，当有一个数据中心故障转移，成员会话的AdViewEvent可能在DataCenter1产生，但AdClickEvent可能在DataCenter2 中产生如下描述：

数据中心故障转移期间，就像上面那个例子一样，我们可以有一个“迟到”，即信息流处理器可能会在AdClickEvent 发生几分钟后看到AdViewEvent。写得差的信息流处理器可能推断出这个广告是一个低质量的广告，实际上正好相反，这个广告可能是高质量的。另一个异常是信息流处理器可能会在看到相应的AdViewEvent之前看到AdClickEvent。为了确保信息流处理器的输出是正确的，我们必须要用逻辑来处理这种“混乱消息的到来。”

在上面的示例中，数据中心的geo-distributed自然很容易解释延迟。然而延迟可以由于GC问题、Kafka集群升级、分区调整、分布式系统和其他存在于同一个数据中心自然发生的现象。

Lambda架构不能解决这个问题？

在LinkedIn，许多源事件流既被发送到实时Samza-based信息流处理系统和又被发送到Hadoop和Spark-based离线分批处理系统。

常见的假设是，因为分批处理发生在一个更大的时间窗内(如一个小时)，延迟造成的误差和故障数据的到来通常只在边缘的间隔方面影响窗口的时间。例如，你可以让延迟影响一项工作的前五分钟和最后五分钟，处理一个小时内在Hadoop上的离线数据。是不是说，工作的一个五分钟的窗口处理60分钟的无关紧要数据呢？答案取决于您正在开发的应用程序。在大多数情况下，这些错误是不能接受的。如果你每15分钟左右运行一次你的分批处理作业，错误会变得更加明显。

在LinkedIn上，为一些高价值的数据集在分批处理方面解决这种错误，我们采用以下正确性检查：

例如，处理下午12点到下午1点之间的事件时，我们将在下午1:20启动Hadoop的工作。这给了数据20分钟时间来被反射通过Kafka管道并进入HDFS。在LinkedIn上的Kafka生态系统拥有一个叫Audit Service的服务，这个服务持续跟踪，在一段时间内，每个生产集群发布多少消息到一组主题上。在以钟点计算的Hadoop作业开始前，它通过查询Audit Service来找出正在考虑放入的主题会在最后一小时有多少事件产生到Kafka。然后检查已经从Kafka摄取到HDFS的事件数量是否匹配在生产集群中产生的事件数量。

正如你所看到的，得到准确的分批处理作业需要加很多的小心和注意。尽管上述的方法改善了分批处理作业的准确性，但它所面临的问题是，如果在管道上有延误，然后正确性检查失败、分批处理作业就运行失败了。一段时间后(在上面的示例中20分钟)，它也迫使分批处理作业开始运行，对数据移动到HDFS的这个过程负责。

相反，大多数用户想要的应用程序在事件发生的同时就进行处理，延迟和次序颠倒的事件发生时也有能力更新结果。

那么我们如何提高精确度？

谷歌上的MillWheel和Dataflow论文详细讨论了这个话题。在此篇博客中，Tyler Akidau继续解释了一个信息流处理器是如何处理延迟和次序颠倒消息到达。大多数流媒体平台从应用程序开发人员开始，通过添加管道来隐藏延迟和次序颠倒到达的复杂性。

LinkedIn和其他几家公司因为信息流处理而使用了Apache Samza。除了Samza的其他关键改善之外，我们正在研究一套核心运营商，让应用程序做窗口更方便，用高度准确的结果加入事件流。核心逻辑是相同的：

1、在Samza工作上，存储所有输入事件有更长的停留时间。如果Samza应用程序是做纯聚合(如平均/sum，等等)，那么没有必要存储所有的输入事件。相反，我们只需要为每一个时间窗口存储聚合的结果。

2、当有一个迟到时，Samza工作可以重新发出被延迟影响了的window/s输出。

1）如果它是一个标准的翻转(非重叠)窗口，然后只有一个窗口的输出必须重新发出。

2）如果它是一个滑动窗口(重叠)，然后一个独立事件可能会出现在多个窗口，因此所有受影响窗口的输出都必须重新发射。

你可以通过这篇设计文档了解更多的细节。正如你想象的，很多数据必须存储验算并为受影响的窗口重新发出结果，比如延迟或乱序到达。一些系统在内存中存储所有的数据，当事件保留时间超过几分钟时(取决于事件率)就会导致不稳定。一些系统将其存储在远程数据库。这类作品甚至扩展的良好。然而由于CPU太高(序列化成本)和网络远程调用的开销，这样的解决方案需要一个大大的硬件足迹。使Samza在建立以上功能时变得独特的功能是它一流的/量产使用嵌入式、容错的RocksDB-based键值存储来支持本地状态。更多关于Samza状态管理的信息可以在这里找到。我也打算在以后的文章中关注状态管理的细节。

二. 再加工

让我们研究一个在LinkedIn上的场景，这需要再加工的数据。LinkedIn允许你为你当前的职位设置任何你想要的。你可以说你是你公司的“首席数据书呆子”。我们需要知道你在公司实际做的事情来提供相关的工作建议，新闻等。为了解决这个问题，我们有Samza-based事件处理器，使用我们现有的变化捕获系统：Databus，侦听Espresso-based 简要数据库所做的更改。由成员提出的他们个人资料来制作每次更新，它会咨询机器学习模型(派生离线)，然后根据你的实际标题（和其他属性）定一个有根据的推测。这个机器学习模型获得定期更新(有时一周多次)。当模型改变时，我们需要再加工所有现有的LinkedIn会员的资料，这样他们就能使用最新的标准化模型。

许多人使用Hadoop或Spark做这种离线再加工。这意味着，核心应用程序逻辑必须重载实现分批处理系统。如果信息流处理器调用生活服务或在线数据库，然后将逻辑移植到分批处理系统，这不是简单能做到的。大多数Hadoop网格大小是很重要的(成千上万的机器)。如果他们调用在线服务/数据库，然后他们会轻易地为这些系统最大化指定配额，并带来对网站的影响。因此，nearline和分批处理系统之间的应用程序逻辑并不完全相同。

Databus提供了一个功能，我们称之为“引导”，在这里，消费者可以直接从数据库备份中读取和处理整个数据库，而不影响实际数据库的服务延迟。通过Databus，每当应用程序需要处理整个数据集时，我们只要开始一个Samza-based信息流处理器以引导模式从Databus中读取即可。

上面的方法确实有一个重要的方面。引导或再加工需要几个小时特别是在我们限制整个系统的吞吐量的时候。在此期间，我们想继续并行运行在线信息流处理器直到引导处理器被赶上。这确实提出了一个问题，那就是合成数据集要存储在哪里。我们有单独的数据存储或我们可以将在线处理器和引导处理器的结果合并到一个数据库吗？这两种选择都是可能的，都有自己的优点和缺点。有独立的数据存储需要一个服务层负责合并结果(类似于Lambda架构)。在LinkedIn，我们还在为服务导出数据开发一个新的存储，这个项目被称为Project Venice，能无缝地处理在线和引导处理器的合并输出量。在缺乏这样一个数据存储的情况下，在线和引导处理器将其结果输出到常见的Kafka主题。另一个Samza工作负责合并这些结果，并将其编写到一个类似Espresso的数据库。

在上面的场景中，整个数据库(从一开始的时间)就必须重新加工。还有其他的场景，只有几小时的数据要必须进行再加工。例如，在一个应用程序升级一个bug过程中引入信息流处理器。如果你有良好的监测，然后在几分钟到几个小时后你就会意识到发生了什么。假设处理是等幂的，你就要恢复应用程序，倒回输入流(支持消息传递系统就像Kafka、AWS Kinesis、Azure EventHub等)，再加工数据。

这种方法的问题是什么？

当你在线上信息流处理器做再加工时，你必须记住以下几件事：

1、当你倒回，并在信息流处理工作开始再加工，工作是直接为用户请求服务更新数据库，你需要担心的是可能影响网站的延迟。因此重要的是要控制信息流处理器的并发性。在Samza这样一个框架中，有一种方法可以控制你的总并行工作。

2、虽然没有技术大小限制，你可以在类似于Samza的流媒体系统中再加工，但有一点就是，你可能需要成千上万的机器在合理的时间内做再加工，例如一个有几百字节或更多的数据集。在LinkedIn，这样的数据集只在我们的Hadoop网格上再加工。这种集群的分离可以避免网络饱和，并避免其他DOS在我们的网上集群触发。

三. 易于编程和实验

创建一个近线“始终运行”的信息流处理应用程序需要一个更高的标准。多数时候，逻辑都是非常复杂和繁琐的，在Java上表达与像SQL一样的高级语言截然相反。应用程序开发人员和数据科学家喜欢使用更高水平的语言来敏捷发展，像在Hadoop上用HIVE/PIG表达他们的逻辑。然而，大多数开源信息流处理框架没有一流的SQL功能。一个商业信息流处理器的一个很好的例子是Azure Stream Analytics，为SQL在实时流方面提供一流的支持。在信息流中缺乏SQL，在LinkedIn上，许多nearline工作在Hadoop/Spark上被替代执行，并被配置来在较短的频率中运行。其他一些应用程序在他们的nearline信息流处理工作中最终实现基本/简单的逻辑，但有一个更全面的处理要在他们的离线Hadoop/Spark工作中完成。然后以经典的Lambda形式合并结果并使其可用于消费。

这是一个众所周知的差距，是信息流处理框架发展的活跃区域。朱利安?海德描述了一个成就，那就是使用Apache Calcite让SQL靠Samza支持。这项工作尚未生产就绪，所以我们不在LinkedIn使用这个。在缺乏一流SQL支持的情况下，开发人员使用CEP框架(复杂事件处理)，并结合信息流处理系统来准备更高级别的抽象概念。来自优步的Shuyi陈在最近的信息流处理Meetup @ LinkedIn上发表了一次演讲，解释了他们是如何嵌入一个开源CEP引擎(Siddhi)到Samza-based信息流处理器的，使其更容易实现业务规则，而无需深入到Java / python。

除了高级语言的支持，我们的Hadoop网格也为反复的实验提供一个良好的模型。在online/nearline系统上做同样的实验会更麻烦，当访问事件源和数据库时，为了不在在线系统产上生负面影响，还有额外的事情需要注意。在LinkedIn，很多最相关的数据集被复制到Hadoop/Spark网格，并准备在离线分批处理作业前使用。因此，许多用户宁愿在Hadoop上离线做大部分的实验。幸运的是，类似于Samza的信息流处理器已经在YARN上运行(将来会在Mesos上运行)。因此，很容易让它们运行在Hadoop的网格上。我们正在为Samza开发一个HDFS系统消费者，这个系统将允许应用程序逻辑编写一次，能够开关HDFS、Kafka、Databus和其他来源之间的输入。我们希望在今年晚些时候让Samza可以发布。

加入我们

如果你想要了解更多，请加入我和Yi Pan在2016年6月29日，即将在San Jose举办的Hadoop峰会上的关于“Lambdaless Stream Processing @ Scale in LinkedIn”的会议。

我们正在招聘！如果您热衷于构建大规模分布式信息流基础设施，然后请联系我或者LinkedIn信息流基础设施团队的成员。