Kappa数据架构

典型的互联网大数据架构

大数据平台由上到下，可分为三个部分：数据采集、数据处理、数据输出与展示。

数据采集

将应用程序产生的数据和日志等同步到大数据系统中，由于数据源不同，这里的数据同步系统实际上是多个相关系统的组合。数据库同步通常用 Sqoop，日志同步可以选择 Flume，打点采集的数据经过格式化转换后通过 Kafka 等消息队列进行传递。

不同的数据源产生的数据质量可能差别很大，数据库中的数据也许可以直接导入大数据系统就可以使用了，而日志和爬虫产生的数据就需要进行大量的清洗、转化处理才能有效使用。

数据处理

这部分是大数据存储与计算的核心，数据同步系统导入的数据存储在 HDFS。MapReduce、Hive、Spark 等计算任务读取 HDFS 上的数据进行计算，再将计算结果写入 HDFS。

MapReduce、Hive、Spark 等进行的计算处理被称作是离线计算，HDFS 存储的数据被称为离线数据。在大数据系统上进行的离线计算通常针对(某一方面的)全体数据，比如针对历史上所有订单进行商品的关联性挖掘，这时候数据规模非常大，需要较长的运行时间，这类计算就是离线计算。

除了离线计算，还有一些场景，数据规模也比较大，但是要求处理的时间却比较短。比如淘宝要统计每秒产生的订单数，以便进行监控和宣传。这种场景被称为大数据流式计算，通常用 Storm、Spark Steaming 等流式大数据引擎来完成，可以在秒级甚至毫秒级时间内完成计算。

数据输出与展示

大数据计算产生的数据还是写入到 HDFS 中，但应用程序不可能到 HDFS 中读取数据，所以必须要将 HDFS 中的数据导出到数据库中。数据同步导出相对比较容易，计算产生的数据都比较规范，稍作处理就可以用 Sqoop 之类的系统导出到数据库。

这时，应用程序就可以直接访问数据库中的数据，实时展示给用户，比如展示给用户关联推荐的商品。

除了给用户访问提供数据，大数据还需要给运营和决策层提供各种统计报告，这些数据也写入数据库，被相应的后台系统访问。很多运营和管理人员，每天一上班，就是登录后台数据系统，查看前一天的数据报表，看业务是否正常。如果数据正常甚至上升，就可以稍微轻松一点;如果数据下跌，焦躁而忙碌的一天马上就要开始了。

将上面三个部分整合起来的是任务调度管理系统，不同的数据何时开始同步，各种 MapReduce、Spark 任务如何合理调度才能使资源利用最合理、等待的时间又不至于太久，同时临时的重要任务还能够尽快执行，这些都需要任务调度管理系统来完成。

Lambda架构的缺点，Kappa架构产生的原因 

数据从底层的数据源开始，经过各种各样的格式进入大数据平台，在大数据平台中经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算。一条线是进入流式计算平台（例如 Storm、Flink或者Spark Streaming），去计算实时的一些指标；另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见。

Lambda架构经历多年的发展，其优点是稳定，对于实时计算部分的计算成本可控，批量处理可以用晚上的时间来整体批量计算，这样把实时计算和离线计算高峰分开，这种架构支撑了数据行业的早期发展，但是它也有一些致命缺点，并在大数据3.0时代越来越不适应数据分析业务的需求。缺点如下：

● 实时与批量计算结果不一致引起的数据口径问题：因为批量和实时计算走的是两个计算框架和计算程序，算出的结果往往不同，经常看到一个数字当天看是一个数据，第二天看昨天的数据反而发生了变化。

● 批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。

●数据源变化都要重新开发，开发周期长：每次数据源的格式变化，业务的逻辑变化都需要针对ETL和Streaming做开发修改，整体开发周期很长，业务反应不够迅速。

● 服务器存储大：数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。ka

14年，Jay Kreps指出了Lambda架构的一些缺点。这次讨论使大数据社区找到了一种使用更少代码资源的替代方案——Kappa数据架构。

1、什么是Kappa数据架构

Kappa（以希腊字母 ϰ 命名，在数学中用于表示循环）背后的主要思想是单个技术堆栈可用于实时和批量数据处理。该名称反映了该体系结构对连续数据处理或再处理的重视，而不是基于批处理的方法。

Kappa 的核心依赖于流式架构。传入数据首先存储在事件流日志中。然后，它由流处理引擎（例如 Kafka）连续实时处理或摄取到另一个分析数据库或业务应用程序中。这样做需要使用各种通信范例，例如实时、近实时、批处理、微批处理和请求响应等。

2、Kappa数据架构的组成

数据重新处理是 Kappa的一项关键要求，使源端的任何更改对结果的影响可见。因此，Kappa 架构仅由两层组成：流处理层和服务层。

在Kappa架构中，只有一层处理层：流处理层。该层负责采集、处理和存储直播数据。这种方法消除了对批处理系统的需要。相反，它使用先进的流处理引擎（例如 Apache Flink、Apache Storm、Apache Kafka 或 Apache Kinesis）来处理大量数据流并提供对查询结果的快速、可靠的访问。

流处理层有两个组件：

· 摄取组件：该层从各种来源收集传入数据，例如日志、数据库事务、传感器和 API。数据被实时摄取并存储在分布式数据存储中，例如消息队列或NoSQL数据库。

· 处理组件：该组件处理大量数据流并提供对查询结果的快速可靠的访问。它使用事件处理引擎（例如 Apache Flink 或 Apache Storm）来实时处理传入数据和历史数据（来自存储区域），然后将信息存储到分布式数据存储中。

对于几乎所有用例，实时数据都胜过非实时数据。尽管如此，Kappa架构不应该被视为 Lambda 架构的替代品。反之，在不需要批处理层的高性能来满足标准服务质量的情况下，您应该考虑 Kappa架构。

 Kappa架构分层:

        (1)实时层。该层核心功能是处理输入数据,生成实时视图。具体来说是采用流式处理引擎逐条处理输入数据,生成实时视图。架构实现方式是采用Apache Kafka 回访数据,然后采用 Flink或 Spark Streaming 进行处理。
        (2)服务层。该层核心功能是使用实时视图中的结果数据集响应用户请求。实践中使用数据湖中的存储作为服务层。
        因此Kappa 架构本质上是通过改进 Lambda 架构中的加速层,使它既能够进行实时数据处理,同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据。
        Kappa架构的优点是将离线和实时处理代码进行了统一,方便维护。缺点是消息中间件有性能瓶颈、数据关联时处理开销大、抛弃了离线计算的可靠性。
        Kappa 架构常见变形是Kappa+架构,

3、Kappa架构的优势

Kappa架构旨在提供可扩展、容错且灵活的系统，用于实时处理大量数据。它使用单一技术堆栈来处理实时和历史工作负载，并将所有内容视为流。Kappa 架构的主要动机是避免为批处理层和速度层维护两个独立的代码库（管道）。这使得它能够提供更加精简的数据处理管道，同时仍然提供对查询结果的快速可靠访问。

4、Kappa架构的缺点

Kappa架构承诺可扩展性、容错性和简化的管理。然而，它也有缺点。

· Kappa架构理论上比 Lambda更简单，但对于不熟悉流处理框架的企业来说，技术上仍然可能很复杂。

· 扩展事件流平台时的基础设施成本。在事件流平台中存储大量数据可能成本高昂，并会引发其他可扩展性问题，尤其是当数据量达到TB或PB级时。

· 事件时间和处理时间之间的滞后不可避免地会产生数据延迟。因此，Kappa 架构需要一套机制来解决这个问题，例如水印、状态管理、重新处理或回填。

5.kappa架构数据处理流程

6.Kappa架构的核心思想，包括以下三点：

1.用Kafka或者类似MQ队列系统收集各种各样的数据，你需要几天的数据量就保存几天。

2.当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。

3.当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。