数据仓库处理架构: lambda架构、kappa架构
大数据处理架构详解：Lambda架构、Kappa架构、流批一体、Dataflow模型、实时数仓
Lambda
Lambda架构（Lambda Architecture）是由Twitter工程师南森·马茨（Nathan Marz）提出的大数据处理架构。
它的目标是构建一个通用的、健壮的大数据系统，能够同时满足实时查询和历史数据批处理的需求。
随着大数据的兴起，越来越多的公司开始面临海量数据的处理问题。传统的批处理系统无法满足实时数据处理的需求，而简单的流式处理系统又无法进行复杂的历史数据分析。这就需要一种混合架构，能够兼顾实时性和复杂分析。Lambda架构应运而生。
关于 Lambda 架构的详情请参考我的博客——《什么是Lambda架构？》
Lambda架构的缺点
Lambda架构解决了大数据量下实时计算的问题，但架构本身也存在一定缺点。
- 实时与批量计算结果不一致引起的数据口径问题：因为批量和实时计算走的是两个计算框架和计算程序，算出的结果往往不同，经常看到一个数字当天看是一个数据，第二天看昨天的数据反而发生了变化。
- 批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
- 开发和维护的复杂性问题：Lambda 架构需要在两个不同的 API（application programming interface，应用程序编程接口）中对同样的业务- - 逻辑进行两次编程：一次为批量计算的ETL系统，一次为流式计算的Streaming系统。针对同一个业务问题产生了两个代码库，各有不同的漏洞。这种系统实际上非常难维护
- 服务器存储大：数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。
Kappa
Kappa架构是对Lambda架构的改进和优化，由Jay Kreps于2014年首次提出。
随着流式计算系统的发展，Lambda架构存在的一些问题逐渐显现出来：
- 系统复杂度高：需要同时开发和维护批处理系统和流式系统。
- 通过日志重播实现低延迟查询，会导致数据冗余。
- 实时视图和批处理视图存在延迟不一致的问题。
为了解决这些问题，Jay Kreps提出了Kappa架构。Kappa架构去除了Lambda架构的批处理层，直接通过流式处理系统实现整个流程。
Kappa架构主要包含两个层:
- 流式处理层：通过流式处理系统接收所有数据，并进行实时计算，更新存储中的结果视图。
- 服务层：对外提供查询服务，直接基于流式处理层更新的结果视图进行查询返回。
统一流处理：所有数据（实时和历史）均通过流处理层处理，历史数据通过事件日志重放实现重新计算
Kappa架构减少了系统复杂度，避免了数据冗余和数据不一致的问题。但需要流式处理系统能够保证Exactly-once语义，以保证流式计算的正确性。而且，去除批处理系统后，对历史数据的复杂计算会更加困难。
流批一体
流批一体(Unified Batch and Streaming Processing)是指将流式处理和批处理统一在一个运行时框架中，进行一体化的处理。
在流批一体架构中，实时数据流和历史数据批量处理可以使用同一组数据处理工具和技术，例如Apache Spark、Apache Flink等。流批一体架构可以将实时数据和历史数据进行统一的处理和分析，以简化数据处理的复杂性和提高数据处理的效率。
在流批一体架构中，实时数据流和历史数据批量处理可以使用同一套数据处理代码。这意味着，数据处理人员可以使用同一种编程语言、框架和工具来处理实时数据和历史数据。这样可以减少数据处理人员的学习和使用成本，并提高数据处理的效率和精度。
流批一体架构还可以将实时数据和历史数据存储在同一套数据存储系统中，例如Apache HBase、Apache Cassandra等。这样可以简化数据存储的管理和维护，并提高数据的可用性和可靠性。
总之，流批一体是一种将流数据处理和批数据处理整合在一起的数据处理架构，它可以简化数据处理的复杂性和提高数据处理的效率。流批一体架构可以在实时数据处理和历史数据批量处理之间实现无缝切换，以满足不同的数据处理需求。