在过去的两天里，我重点介绍了Fuze后端数据平台是如何发展以满足不断增长的客户需求的。从通信数据收集到商业智能，我们需要解决我们的系统架构，以保持事情顺利运行。当谈到报告时，我们知道我们是彻底的，但我们如何确保我们的报告是最新的要求？使我们的报告实时化 当我们意识到，使用上面描述的ETL驱动方法，我们永远无法满足实时报告的需求。我们开始了一个新项目，目标是实现近乎实时的报告。到目前为止，已经有一些关于实时数据流处理方法来解决这类问题的文献和例子。我们做的第一件事是将数据源从日志文件更改为事件。修改了功能环境，以便除了日志文件外，事件还可以在发生时写入网络。这一点非常重要，因为它避免了等待作业运行以从日志文件中收集源数据。在我们的方法中，发射的事件被发送到卡夫卡。许多实时数据流体系结构都使用Kafka，它作为需要处理的事件的队列。这一点很重要，因为生成事件的速率有时可能会超过处理事件的速率。在上图中，生成的事件被发送到左侧Kafka中的队列。在右侧，Storm从队列中获取事件并进行处理。与批处理系统不同，这种处理可以随着事件的到来而发生。在面向批处理的系统中，这种逻辑是在ETL层中实现的，在这个场景中是在Storm中实现的。在这个版本中，Storm jobs将数据写入我们报告数据库中的一组特定的实时表中。命中这些数据库表的报告现在显示实时数据。数据集成管道的激增 值得注意的是，虽然我们实现了实时报告的目标，但我们没有取代现有的面向批处理的系统。该系统仍然为我们的大多数报告和发票功能提供动力。所以我们真正做的是在我们的环境中添加第二个数据集成管道。当我们生活在这个双管道场景中时，几个问题开始变得明显。第一个实际问题是需要在ETL分支和实时分支中复制数据转换和加载逻辑。因此，当我们想要添加一个报告特性时，我们需要在ETL和实时方面都添加逻辑。由于一个系统非常以SQL为中心，而另一个系统的逻辑是用java实现的，因此没有明显的方式来共享逻辑。除此之外，我们的最终用户开始指出其他问题。我们开始得到错误报告，这些报告中的数据与实时报告中的数据不同。当这种情况发生时，我们将不得不开始从报告向后返回到数据源，以找出发生分歧的地方。有时，观察到的问题是由批处理或实时方面的数据转换逻辑中的错误引起的。有时日志文件中的源数据和发出的事件是不同的，必须在特性平台中进行修复，或者在转换逻辑中进行说明。更深层次的问题是，面对矛盾，什么是记录制度？走向兰姆达建筑？ 对于上述双流场景的问题，一个可能的解决方案是所谓的lambda体系结构。有许多高知名度的用户使用这种方法，包括Twitter，Storm就是在那里开发的。在这种方法中，您将所有源数据合并到一个流中。对我们来说，这意味着完全转向基于事件的数据。这消除了批处理派生数据和实时派生数据之间的数据差异由于源数据差异而不同的问题。每个人都在使用相同的源数据。这个单一的源数据流被输入到一个Kafka队列中。数据由两个处理程序（有时称为批处理层和速度层）处理出队列。批处理层类似于上面示例中的ETL流。许多人使用基于HDFS和MapReduce的方法作为批处理流的处理程序。结果数据通常写入HDFS。速度层与前面描述的实时方法类似。当数据进来时，暴风作业会消耗掉卡夫卡队列中的数据。数据在到达时被处理，并被写入HDFS。这里的关键点是批处理和实时处理程序都在向同一个HDFS目标系统写入数据。我们的想法是创建一个单一的记录系统。在报告层中，总是尽可能显示批处理派生的数据，并且只在批处理数据不可用时显示实时数据。当新的批处理派生数据出现时，它将根据权限替换实时派生数据。这里的结果是，你有一个单一的记录系统，其中有接近实时的数据，这是一个真正的成就。但问题是，您仍然有两组不同的转换逻辑需要维护。这是一个主要的缺点，特别是考虑到我们对现有双流实现进行故障排除的经验。此外，我们开始质疑是否真的有一个单独的数据存储可以满足我们大多数的查询需求。越来越清楚的是，我们需要为不同的用例优化多个数据存储。因此，虽然我们花了大量的时间来考虑这种方法，但最终我们决定采用一种不同的、更以实时为中心的方法。走向实时体系结构 我们建立的体系结构试图将lambda体系结构的批处理和速度层整合到一个单一的实时流中。仍然有从功能环境生成的事件发送到Kafka队列。但从这一点来看，与之前提出的lambda架构有分歧。原始事件被持久化到HDFS中。如果我们发现数据处理逻辑有问题，需要重放这些问题，就需要这些。卡夫卡对原始事件的处理是用燧石（类似于风暴）进行的。当原始事件被处理时，它们被写回Kafka，创建一个新的已处理事件队列，其中的事件已被其他系统的数据查找修饰。现在不同的数据使用者订阅处理过的事件流。这些已处理的事件也被持久化到hdf中，以防我们以后需要重放它们，例如，如果我们需要用Kafka队列中包含的历史数据填充新的数据存储。这种方法的好处是避免了lambda体系结构中存在的数据转换逻辑的重复。根据定义，一组逻辑比两组更容易维护。它还非常适合拥有多个消费数据存储的现实，每个存储都针对特定目的进行了优化。我们可以继续使用列式数据仓库进行聚合、分析和开票。我们可以使用HBase查询特定场景的消息和调用。我们可以使用ElasticSearch对邮件进行全文搜索。我们期望用例优化数据存储的数量会随着时间的推移继续增长。这种方法的另一个重要点是，消费者都是从卡夫卡那里提取数据，而不是将数据推送到他们那里。这是一个微妙的问题，但根据我们的经验，我们更喜欢基于拉的架构，而不是基于推的架构。在下游报告系统出现故障或停机时，系统将在恢复联机状态时迎头赶上，而有人需要弄清楚如何从目标系统关闭时返回并重新加载数据。那么这种方法的缺点是什么呢？更困难的是数据的重放和修复。随着时间的推移，总会有数据问题被发现。其中一些问题可能出现在上游数据生成系统中。这些问题也可能来自数据处理和转换层的错误。不管怎样，问题都会变成，在你解决了问题之后你会怎么做？如何修复下游报告系统中的数据？或者你真的要这么做吗？在这里，我想说面向批处理的方法针对记录数据库系统有一些优点。您可以重新运行批处理作业以重新填充/覆盖现有数据。这个问题就是为什么我们在HDFS中持久化所有的原始和已处理的事件，以便在事后执行修复操作。另一个缺点是，最终在所有这些不同的数据存储中都有许多数据副本。我们接受这一点作为能够为特定目的使用正确的查询引擎的代价。一个数据库可以满足80%的查询需求的想法已经不复存在了。如果有的话，事情似乎朝着另一个方向发展，在任何一种趋同发生之前，会有更多的分歧。总结性思考在定义数据体系结构和策略时，并没有一种一刀切的方法。很多架构和技术的选择很大程度上取决于您正在使用的数据，以及您的查询需求是什么样子的。但有些原则确实从我们的经验中脱颖而出，值得考虑。与维护多个数据集成管道相比，创建数据使用者可以订阅的单个数据集成管道有显著的简化。如果这个单一的数据集成管道是实时的，而不是面向批处理的，也有很多好处。我们相信，在可预见的未来，将需要多个具有优化查询引擎的数据存储。我们倾向于把这些不同的系统看作是数据的索引。因此，您选择的数据集成方法应该支持这一现实。如果你有兴趣阅读更多关于这些主题的文章，我想给你举几个广告