リアルタイムデータ処理ができない場合、私はどのようにすればよいですか？

著者| 周シュアン

Zebian |火ミン

出品 | CSDN（ID：CSDNnews）

多くのビジネスシナリオでは、我々は生きるために戻ることができますクエリや計算の結果を聞いてきます。このような火災警報、事前に信用リスクの検出、定量取引など。再解析データの後、火災が起きたこの時間は、詐欺師が脱出し逃げた、市場機会を逃してきたしている場合は、値の分析データは、限られた「過去の学習」を引き起こしました。

したがって、我々はリアルタイム値治まる前に、リアルタイムのストリーミングデータの計算や分析を完了する必要があります。これは、遅延時間の計算が小さくなければならない必要です。大量のデータを、計算の複雑さの理由は、リアルタイム計算を完了することができないので、時には、その後も部分的な結果の精度を犠牲にして確保するために、その許容範囲を前提に誤差、さらにはリアルタイムシステムに優先順位を与えることができます。

しかし、我々は非常に創造的で巧みな最適化の様々な方法をとっているにもかかわらず、コンピューティングパワーを、現在の一般的なハードウェアでいくつかの問題が、メモリ内の分散、ビッグデータの利用、コンピューティング技術は、直接することができない、ということを認めざるを得ませんリアルタイムで計算結果を得ます。つまり、これらの問題の顔と言っても、それを完全に計算したリアルタイムの考えを放棄することの時間ではないでしょうか？

そうではありません。が直接問題をリアルタイムで計算を答えるが、我々はまだ、間接的に増分計算の仕方によって質問にリアルタイムで回答を得ることができません。時々答えは少しヒステリシスと近似が、限り、彼らはできる限りあなたに最新の情報価値をもたらすことができますように、と彼らはまた、有用であることを持っている場合でも。

ラムダアーキテクチャは、プロセスが直接リアルタイムコンピューティングアーキテクチャの一般的な問題のために使用することができません。ラムダアーキテクチャは元々ストームが大きい低遅延計算シナリオと共通のアーキテクチャパターンクエリを構築するためのフレームワークストリームネイサンマルツデータを計算する著者によって提案されました。バッチ層（バッチ層）、高速処理層（速度層）とサービス層（層にサービスを提供する）：全体的なラムダアーキテクチャは3分割されています。バッチおよびエンドユーザまたはアプリケーションの問い合わせを提供することで各増分新しいシステムに履歴データと全額をデータ処理、バッチ処理と組み合わさ迅速処理層の結果のためのサービス層、高速処理層。

ラムダアーキテクチャ

ラムダアーキテクチャでは、各レイヤの特定の機能は次の通りです。

批处理层。批处理层是为了存储主数据集和预计算各种批处理视图。当数据进入批处理层时，数据被存储下来，并作为数据系统的主要数据集。由于全量的数据会很大，计算比较耗时，所以批处理层的主要作用就是对预定的查询进行预计算，并将计算结果保存下来。如果做得更精细些，可以在计算结果上生成各种视图，并构建相应的索引，以供后续快速检索和查询。
快速处理层。在最标准的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 技术应用》