When the real-time data processing can not, how should I do?

Author | Zhou Shuang

Zebian | Tu Min

Exhibition | CSDN (ID: CSDNnews)

In many business scenarios, we will ask queries or results of calculations can return to live. Such as fire alarm, pre-credit risk detection, quantification transactions. If after the re-analysis data, this time the fire has taken place, crooks have escaped and fled, market opportunities have been missed, value analysis data caused only limited to "learning of the past" the.

Therefore, we must complete the calculation and analysis of real-time streaming data before the real-time value subside. This requires the calculation of the delay must be small. Sometimes because of large amount of data, the computational complexity reasons, real-time calculation can not be completed, then even at the expense of the accuracy of the partial results, to ensure that the error in the premise of the acceptable range, and can even give priority to real-time computing.

But have to admit that, even though we have taken a variety of very creative and skillful optimization methods, some problems in the current common hardware computing power, the use of distributed, big data, in-memory computing technology, can not be directly get the results calculated in real time. That is not to say that the face of these problems, it's time to completely abandon the idea of real-time computing it?

no. Although not directly answer the real-time calculation of the problem, but we can still indirectly get real-time answers to questions by way of incremental calculation. Even if sometimes the answer has little hysteresis and approximation, but as long as they are able to bring you the latest information value as possible, and that they are also useful.

Lambda architecture is such a process can not be used for real-time computing architecture common problem directly. Lambda architecture was originally proposed by the authors Storm computing framework stream Nathan Marz data to build a large low-latency computing scenarios and common architectural patterns queries. Overall Lambda architecture is divided into three: Batch layer (batch layer), fast processing layer (speed layer) and service layer (serving layer). Batch and fast processing layer in which each incremental data processing historical data and full amount into the new system, and service layer for the results of batch processing and rapid processing layers combined, to provide the end-user or application inquiries.

Lambda architecture

In the Lambda architecture, each layer specific functions are as follows.

批处理层。批处理层是为了存储主数据集和预计算各种批处理视图。当数据进入批处理层时，数据被存储下来，并作为数据系统的主要数据集。由于全量的数据会很大，计算比较耗时，所以批处理层的主要作用就是对预定的查询进行预计算，并将计算结果保存下来。如果做得更精细些，可以在计算结果上生成各种视图，并构建相应的索引，以供后续快速检索和查询。
快速处理层。在最标准的Lambda架构中，快速处理层的作用是实时计算在批处理层两次调度执行期间新到的增量数据，并将计算结果保存下来。在这种标准架构下，理论上快速处理层的输出结果与批处理层的输出结果在业务意义上应该是完全相同。换言之也就是，如果我们分别用两张数据库的表来存储批处理层和快速处理层的计算结果，那么这两张数据库表的表结构应该是相同的。只是因为分析的时间段不同，这两张表里的数据记录不一样而已。但Lambda架构并非铁板一块的“定式”，在很多场景下我们可以根据自己的需求对快速处理层做出改动。比如，既然前一次的批处理层计算结果已经存储在数据库中了，那为什么快速处理层就不可以直接使用这次的批处理层计算结果呢？事实上我们经常这样做，比如用批处理层学习统计模型或机器学习模型，将模型结果保存到数据库，然后快速处理层从数据库中定期更新模型，并根据模型做出实时预测。
服务层。服务层用于将批处理层和快速处理层各自计算所得结果合并起来，从而能够实时提供用户或应用程序在全量数据集上的查询结果。服务层对外提供的查询接口是只读的，这对于实现高性能、无状态、高可靠的查询服务非常有用。所以服务层在技术实现上结构相对简单，但它与具体的业务查询会结合得更加紧密。

Lambda架构是一种架构设计思想，针对每一层的技术组件选型并没有严格限定。所以我们可以根据自己公司和项目的实际情况选择相应的技术方案。批处理层的数据存储，可以选择HDFS、S3等大数据存储方案。批处理层的任务执行框架，则可以选择MapReduce、Hive、Spark等大数据计算框架。批处理层的计算结果（比如数据库表或者视图），由于需要被服务层或快速处理层高速访问，所以可以存放在诸如MySQL、HBase等能够快速响应查询请求的数据库中。对于快速处理层，这就是各种实时流计算框架的用武之地了，比如Flink、Spark Streaming和Storm等。快速处理层由于对性能要求更加严苛，它们的计算结果可以写入像Redis这样具有超高性能表现的内存数据库中。在服务层，当接收到查询请求时，就可以分别从存储批处理层和快速处理层计算结果的数据库中，取出相应的计算结果并做出合并，作为最终的查询输出。

Lambda架构为开发大数据量下的实时应用提供了一种切实有效的通用模式。通过将数据和处理分为批处理层、快速计算层和服务层三个相对独立的层次，Lambda架构降低了大数据在持续更新过程中问题的复杂性，并能够实时获得在全部数据集合上的查询结果。不过Lambda架构也存在一些问题。其中最主要的就是，对于同一个查询目标，需要分别为批处理层和快速计算层开发不同的算法实现。也就是说，对于同一套大体相同的逻辑，需要开发两种完全不同的代码，这对开发、测试和运维都带来一定的复杂性和额外工作量。

为了解决Lambda架构中因为批处理层和快速计算层“异质”带来的复杂性问题，LinkedIn的Jay Kreps在Lambda架构的基础上提出了Kappa架构。Kappa架构的核心思路就是，将批处理层也用快速处理层的流计算技术替换。这样一来，批处理层和快速处理层都是使用了相同的流处理逻辑，在开发、测试和运维上都有一个更统一的框架，从而降低了开发、测试和运维的成本。

Kappa架构

从Lambda架构上演进而来的Kappa架构，通过流来统一编程界面，确实极大简化了数据系统的构建过程。虽然在架构体系和实际代码开发过程中，Kappa相比Lambda具有更好的一致性。但是这并不意味着Kappa比Lambda架构更好，它们有各自的意义和价值。Lambda架构代表的是一种更通用的架构思想，指导我们在碰到不能直接用实时计算方式解决大数据问题时，不妨尝试采用这种离线和实时相结合的折衷方案。而Kappa架构的最大价值，则是启发我们尽量用流式计算框架来统一离线计算和实时计算。

作者：周爽，本硕毕业于华中科技大学，先后在华为2012实验室高斯部门和上海行邑信息科技有限公司工作。开发过实时分析型内存数据库RTANA、华为公有云RDS服务、移动反欺诈MoFA等产品。目前担任公司技术部架构师一职。著有《实时流计算系统设计与实现》一书。

【End】

在全民抗疫的特殊时期下，在人员复杂、流动量大地方的出入口处都设置了无接触式无感红外人体测温系统。

在这次疫情防控中，无感人体测温系统发挥了怎样的作用？高精准的无感人体测温系统的核心技术武器是什么？对于开发者们来说，大家应该了解哪些技术？

今晚7点《多场景疫情防控：解读云边端联动下的全栈 AI 技术应用》