实时离线融合在唯品会的进展：在实时技术、数据、业务中寻找平衡

本篇文章4567字，读完约11分钟

雷锋。(公开号码:雷锋。com)出版社:本文是基于蒋卫华博士在数字水果智能新产品发布会上所做的“数据链，智能时代的大数据实时分析技术”的演讲。

实时大数据分析是指对大规模数据进行分析，利用大数据技术高效快速地完成分析，从而达到接近实时的结果，更及时地反映数据的价值和意义。

每个人都可以理解，数据的及时性对于数据的价值至关重要。以Vipshop为例，Vipshop已经拥有一套非常成熟的离线数据仓库系统。该系统对业务有很大的指导意义，但目前遇到的问题是如何将各种计算和报表从原来的日级和小时级加速到接近实时。

这就是为什么我们启动了实时离线集成项目。我们是在2016年下半年开始这项工作的，到目前为止它还只是一个半成品，里面包含的很多内容都不是最终的结论。在大多数情况下，它仅基于Vipshop的特性，可能无法无缝应用于其他公司产品。我们希望抛砖引玉对大家都有好处。

1.及时性和大数据

第一个问题是:什么是实时？什么是离线？很多时候，我们自然会将实时等同于流处理、风暴和火花流。但事实上，实时和离线的区别实际上是从延迟的角度来看的。如果短延迟是实时的，则长延迟是离线的。

时间延迟是从数据生成到计算的时间差，时间延迟是从端到端的，而不仅仅是查询的执行时间。它用一个简单的公式表示:时间延迟=数据准备时间+查询计算时间。

实时、接近实时和离线通常通过时间延迟的长度来区分。实时表示毫秒和秒延迟；近实时主要是分钟延迟；离线时有超过十分钟的延迟。

什么是批处理和流处理？批处理通常也称为“离线”，即数据可以作为一个完整的数据集进行处理，并可以重复计算，计算可以定期开始，也可以在数据丢失后按需开始。一般来说，批处理具有大量的数据和很大的延迟，这通常需要完全计算。流处理，也通常称为“实时”，意味着数据以流方式(增量)处理，这与批处理的特征相反。

然而，实时计算不同于流式计算。尽管大多数实时计算都是流计算，但其中许多都可以通过批处理来实现。同时，尽管实时或准实时计算结果在流计算中占很大比例，但流计算可能需要很长时间才能产生结果，例如30分钟的窗口，并在窗口结束后输出结果。

因此，实时计算不等于流式计算。实时服务不必通过流式计算来实现。让我们来看看实时数据处理中流式计算的瓶颈。

2.现状和问题

Vipshop是一个电子商务网站，数据可以分为两类:行为隐藏数据和交易数据。下图是一个典型的交易数据处理环节，行为数据的处理与此非常相似。

这个数字实际上代表了目前大数据处理的典型架构。对于实时和离线，这两条路径与源完全分离。

对于离线/批处理，数据是逐层处理的。用户可以很容易地使用sql，具有低门槛和完整的工具，理论和系统。然而，它有很高的延迟并且无法控制(特别是在大促销的情况下)。

对于流/实时计算，一切都是时间敏感的，链接很短，数据没有层次，大量应用程序直接处理原始数据。所以它唯一的优势在于它的时效性。然而，它的发展是困难的，它的逻辑是复杂的，它的资源需求是巨大的，它的数据质量是难以保证的。与此同时，有必要为每个应用程序独立地开发其应用程序逻辑，这是无法概括的。

对数对于实时应用程序(尤其是报告)来说是最痛苦的事情。典型的场景是使用实时报告来提供结果，但是仍然需要常规和离线报告来比较它们的正确性。一般认为离线应用的准确性高于实时应用，但实时和离线处理方法完全不同，开发方法、方法、处理逻辑和数据源不一致，使得对数非常困难。最根本的原因是实时和离线从一开始就是两条计算路径。登录这两条完全不同的路径非常非常困难。

我们一直在反思如何更好地支持实时业务。因为业务方总是抱怨数据不准确、与线下不兼容、缺乏口径更新、开发效率低、周期长等。很明显，我们也在加班，努力满足业务方面的要求，但我们发现我们永远无法满足业务需求。

3.实时离线融合

当前的实时方法真的是打开它的正确方法吗？对于这个问题，我们的理解是:

业务需求接近实时。大多数服务只需延迟几分钟，甚至5~10分钟。并且不需要几秒钟的时间延迟。因此，使用流计算，如风暴/火花流，实际上是杀鸡和用刀的行为。

业务端需要接近实时，但只有实时团队有能力实现实时。原因是流计算的发展门槛太高。但事实上，业务方希望以一种他们可以轻松控制的方式实现接近实时，而不是将其交给实时团队来安排开发。

基于以上认识，我们启动了实时离线融合项目。该项目的目的是:

让业务方通过他们熟悉的批处理方法实现接近实时的计算。

让实时团队专注于系统和平台，而不是业务。

时间延迟=数据准备时间+查询时间。目前，由于这两个步骤耗时太长，用批处理方法实现近实时计算是不可能的。如果数据准备速度足够快，计算速度足够敏捷，批处理也可以实现接近实时的延迟。

对于批量处理，数据准备时间=计划时间+数据准备计算时间。只有当两者都很小时，数据准备时间才能大大缩短。因此，对于数据准备来说，使用流处理来实现实时数据准备是一个非常合理的想法。同时，由于这类数据一般是由基础数据准备的，与业务逻辑关系不大，所以也非常适合用流的方法来实现。

实时离线融合链接图

在这个环节中，流计算和批处理共享相同的数据准备步骤(清理和扩展)。这些步骤确保数据可以在几毫秒内处理完毕。处理后的数据将被放入蜂箱(延迟以分钟为单位)。这样，近实时的基础数据已经在蜂巢中准备好了。您需要接近实时的应用程序来访问这些数据。

实时数据登陆在hive中，即大量数据经过实时处理后存储在hive中，并提供给后端业务系统进行处理。目前，我们的做法是每5分钟制作一个蜂巢分区，数据将根据事件时间落入相应的蜂巢分区，然后在等待一定时间后关闭分区(这里我们借鉴了流处理中的水印概念)。同时，为了保持与现有配置单元分区的兼容性(也就是说，对一个关闭的分区的两次查询应该得到相同的结果)，并且为了确保该分区能够及时关闭，规定如果它的数据在该分区关闭后到达，数据将落在下一个分区上。

对于那些不关心分区是否关闭，但对及时性要求很高的应用程序，它们可以在分钟级别访问数据(未关闭的分区)；对于大多数应用程序，您可以选择在分区关闭后进行查询(数据准备的延迟约为5~6分钟)。

这类数据的高频着陆也存在一些问题。

首先，过多的小文件(为了确保着陆延迟，必须增加并发性)将导致查询变慢。

其次，主要基于普通磁盘的HDFS(Hadoop Distributed File System)具有不稳定的时延(每个分区的数据可以在几秒钟内快速完成，而慢则需要几分钟)。这挑战了数据着陆的火花流任务。

为了改善这些情况，我们压缩了历史分区以减少文件数量；基于普通磁盘的Hdfs被基于固态硬盘的alluxio和hdfs所取代，以减少其着陆波动。将数据放入高速文件系统不仅可以改善登陆的波动性，还可以提高读取率。

为了与离线系统无缝连接，我们目前的做法是向离线调度系统发出信号，告知该分区的数据在每个分区关闭后都已准备就绪，以便离线调度系统可以正常调度依赖于该分区的下游任务。

当数据准备好实时时，如何缩短离线查询时间？查询时间=计划时间+查询计算时间。为了实现近实时性，有必要减少其调度时间和查询计算时间，以提高离线应用。然后我们需要将高频率调度为5分钟甚至更少，合理地控制资源使用，确保中间结果不会下降，使用spark sql和presto代替hive，并使用elasticsearch、druid、kylin等进行预计算，从而减少计算量，加快查询计算。

如上所示。离线应用的三个维度是nrt的要求(业务本身的属性)、实现最小延迟的成本(人力资源、机器资源)和数据准确性的要求。每个应用程序都应该考虑如何在三者之间实时取得平衡。

这种平衡决定了有三种模式。

首先是零成本加速。通过实时数据登陆，你可以透明地享受30-50分钟的加速；

第二是追求终极的近实时。应用程序越实时越好。不惜一切代价投入了大量的人力物力来彻底重新实现这一逻辑；

第三种介于两者之间，旨在资源有限的情况下加速，但尽可能不增加计算负担。

在实时离线融合的场景中，es、druid、kylin等将扮演越来越重要的角色。因为如果应用程序可以通过使用这些预先计算的存储来实现，那么查询计算时间基本上可以忽略。与此同时，因为这些存储没有像hive这样的分区概念，经过清理和扩展的数据实际上可以流入这些存储(第二层)。然后，用户可以用类似于离线sql的方式在几秒钟内查询数据。

4.实时线下融合带来的挑战

实时线下融合不是免费的午餐。它也带来了一系列新的问题和挑战。

对于实时/流式计算，它成为所有大数据处理的先决条件。这要求it作为一个平台具有高稳定性、可靠性、可管理性、数据质量和sla保证。特别是当现有的流处理系统(风暴、火花流、弗林克)还没有完全实现端到端的理论上的一次。一般来说，批处理系统(hive、spark)非常可靠，只支持一次语义。将基础数据准备从批处理系统替换为流处理系统是一个巨大的挑战。

如何保证蜂巢中数据的质量，我们目前的做法是从多个方面入手:

1.全程监控，确保数据质量；

2.考虑各种极端场景的处理方法；

3.当发现问题时，如何重写整个蜂巢分区；

4.保持当前的对数离线小时采样逻辑。

5.转换当前的流框架以提供更好的处理语义保证。

对于离线(蜂窝、火花)，高频调度对于实时应用是必要的。这也带来了一系列的挑战。如何提高调度效率？当最后一次调度没有完成时，如何处理下一批的调度问题(数据积压)？如何防止过度占用系统资源？因此，有必要对调度系统及其应用进行改革。此外，我们需要区分热数据和冷数据。独立的ssd或alluxio群集用于热数据，而普通hdfs存储冷数据。

实时离线融合。目前，我们只完成了大量的实时基础数据，我们已经能够看到明显的效果。但是这个任务是长期的。由于用户一般更喜欢使用很宽的表，如天空表，而基本的表，如小时表，目前更加实时，如何实时实现(或加速)天空表等宽表是我们目前正在推进的工作。只有在这部分工作完成之后，我们才能说实时离线集成是真正成功的。

作者简介

idh的产品开发经理蒋卫华博士是中国最早的hadoop发行商。主要研究方向集中于大数据的开发，并从事大数据的开源工作。在英特尔的两年中，该团队培训了10名提交者，为上海大数据流处理创建了meetup，并创建了两个新的apache项目。目前，他负责Vipshop的实时平台。

张量流&神经网络算法高级应用类即将开始！

从初级到高级，理论+实战，一站式深入了解张量流！

本课程面向深入学习的开发人员，教授如何使用张量流解决特定问题，如图像识别和文本分析。为期10周的课程将从张量流的原理和基本实践技能开始，逐步教会学生如何在张量流上构建cnn、自编码、rnn、gan等模型，最终掌握一套基于张量流的深度学习和发展的专业技能。

作为思想工作的高级技术专家，童达和白华川两位教师在构建大数据平台和开发深度学习系统方面有着丰富的经验。

时间:每周二和周四晚上20: 00到21: 00

课程时长:共20小时，10周完成，每周2次，每次1小时

在线教学地址:mooc.ai/

雷锋文章版权所有。严禁擅自转载。详情请参考转载说明。

来源：搜狐微门户