大数据架构如何做到流批一体？

阿里妹导读：大数据与现有的科技手段结合，对大多数产业而言都能产生巨大的经济及社会价值。这也是当下许多企业，在大数据上深耕的原因。大数据分析场景需要解决哪些技术挑战?目前，有哪些主流大数据架构模式及其发展?今天，我们都会一一解读，并介绍如何结合云上存储、计算组件，实现更优的通用大数据架构模式，以及该模式可以涵盖的典型数据处理场景。

大数据处理的挑战

现在已经有越来越多的行业和技术领域需求大数据分析系统，例如金融行业需要使用大数据系统结合 VaR(value at risk) 或者机器学习方案进行信贷风控，零售、餐饮行业需要大数据系统实现辅助销售决策，各种 IOT 场景需要大数据系统持续聚合和分析时序数据，各大科技公司需要建立大数据分析中台等等。

• 抽象来看，支撑这些场景需求的分析系统，面临大致相同的技术挑战：
• 业务分析的数据范围横跨实时数据和历史数据，既需要低延迟的实时数据分析，也需要对 PB 级的历史数据进行探索性的数据分析;
• 可靠性和可扩展性问题，用户可能会存储海量的历史数据，同时数据规模有持续增长的趋势，需要引入分布式存储系统来满足可靠性和可扩展性需求，同时保证成本可控;
• 技术栈深，需要组合流式组件、存储系统、计算组件和;
• 可运维性要求高，复杂的大数据架构难以维护和管控;

简述大数据架构发展

Lambda 架构

Lambda 架构是目前影响最深刻的大数据处理架构，它的核心思想是将不可变的数据以追加的方式并行写到批和流处理系统内，随后将相同的计算逻辑分别在流和批系统中实现，并且在查询阶段合并流和批的计算视图并展示给用户。Lambda的提出者 Nathan Marz 还假定了批处理相对简单不易出现错误，而流处理相对不太可靠，因此流处理器可以使用近似算法，快速产生对视图的近似更新，而批处理系统会采用较慢的精确算法，产生相同视图的校正版本。

Lambda架构典型数据流程是(http://lambda-architecture.net/)：

1. 所有的数据需要分别写入批处理层和流处理层;
2. 批处理层两个职责：(i)管理 master dataset (存储不可变、追加写的全量数据)，(ii)预计算batch view;
3. 服务层对 batch view 建立索引，以支持低延迟、ad-hoc 方式查询 view;
4. 流计算层作为速度层，对实时数据计算近似的 real-time view，作为高延迟batch view 的补偿快速视图;
5. 所有的查询需要合并 batch view 和 real-time view;

Lambda 架构设计推广了在不可变的事件流上生成视图，并且可以在必要时重新处理事件的原则，该原则保证了系统随需求演进时，始终可以创建相应的新视图出来，切实可行地满足了不断变化的历史数据和实时数据分析需求。

Lambda 架构的四个挑战

1. Lambda 架构非常复杂，在数据写入、存储、对接计算组件以及展示层都有复杂的子课题需要优化：
2. 写入层上，Lambda 没有对数据写入进行抽象，而是将双写流批系统的一致性问题反推给了写入数据的上层应用;
3. 存储上，以 HDFS 为代表的master dataset 不支持数据更新，持续更新的数据源只能以定期拷贝全量 snapshot 到 HDFS 的方式保持数据更新，数据延迟和成本比较大;
4. 计算逻辑需要分别在流批框架中实现和运行，而在类似 Storm 的流计算框架和Hadoop MR 的批处理框架做 job 开发、调试、问题调查都是比较复杂的;

结果视图需要支持低延迟的查询分析，通常还需要将数据派生到列存分析系统，并保证成本可控。

流批融合的 Lambda 架构

针对 Lambda 架构的问题3，计算逻辑需要分别在流批框架中实现和运行的问题，不少计算引擎已经开始往流批统一的方向去发展，例如 Spark 和 Flink，从而简化lambda 架构中的计算部分。实现流批统一通常需要支持：

1. 以相同的处理引擎来处理实时事件和历史回放事件;
2. 支持 exactly once 语义，保证有无故障情况下计算结果完全相同;
3. 支持以事件发生时间而不是处理时间进行窗口化。

Kappa架构

Kappa 架构由 Jay Kreps 提出，不同于 Lambda 同时计算流计算和批计算并合并视图，Kappa 只会通过流计算一条的数据链路计算并产生视图。Kappa 同样采用了重新处理事件的原则，对于历史数据分析类的需求，Kappa 要求数据的长期存储能够以有序 log 流的方式重新流入流计算引擎，重新产生历史数据的视图。

Kappa 方案通过精简链路解决了1数据写入和3计算逻辑复杂的问题，但它依然没有解决存储和展示的问题，特别是在存储上，使用类似 kafka 的消息队列存储长期日志数据，数据无法压缩，存储成本很大，绕过方案是使用支持数据分层存储的消息系统(如 Pulsar，支持将历史消息存储到云上存储系统)，但是分层存储的历史日志数据仅能用于 Kappa backfill 作业，数据的利用率依然很低。

Lambda 和 Kappa 的场景区别：

Kappa 不是 Lambda 的替代架构，而是其简化版本，Kappa 放弃了对批处理的支持，更擅长业务本身为 append-only 数据写入场景的分析需求，例如各种时序数据场景，天然存在时间窗口的概念，流式计算直接满足其实时计算和历史补偿任务需求;

Lambda 直接支持批处理，因此更适合对历史数据有很多 ad hoc 查询的需求的场景，比如数据分析师需要按任意条件组合对历史数据进行探索性的分析，并且有一定的实时性需求，期望尽快得到分析结果，批处理可以更直接高效地满足这些需求。

Kappa+

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!