本文转自阿里技术（订阅号 id：ali_tech )，经平台同意授权转载。

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

大资料处理的挑战

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

抽象来看，支撑这些场景需求的分析系统，面临大致相同的技术挑战：

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

图 1 Lambda架构示例

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

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

Lambda 架构的四个挑战

Lambda 架构非常复杂，在资料写入、储存、对接计算元件以及展示层都有复杂的子课题需要优化：

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

1.以相同的处理引擎来处理实时事件和历史回放事件；

2.支援 exactly once 语义，保证有无故障情况下计算结果完全相同；

3.支援以事件发生时间而不是处理时间进行视窗化。

Kappa架构

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

图2 Kappa大资料架构

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

Lambda 和 Kappa 的场景区别：

Kappa+是 Uber 提出流式资料处理架构，它的核心思想是让流计算框架直读 HDFS类的数仓资料，一并实现实时计算和历史资料 backfill 计算，不需要为 backfill 作业长期储存日志或者把资料拷贝回讯息伫列。Kappa+ 将资料任务分为无状态任务和时间视窗任务，无状态任务比较简单，根据吞吐速度合理并发扫描全量资料即可，时间视窗任务的原理是将数仓资料按照时间粒度进行分割槽储存，视窗任务按时间序一次计算一个 partition 的资料，partition 内乱序并发，所有分割槽档案全部读取完毕后，所有 source 才进入下个 partition 消费并更新 watermark。事实上，Uber 开发了Apache hudi 框架来储存数仓资料，hudi 支援更新、删除已有 parquet 资料，也支援增量消费资料更新部分，从而系统性解决了问题2储存的问题。下图3是完整的Uber 大资料处理平台，其中 Hadoop -> Spark -> Analytical data user 涵盖了Kappa+ 资料处理架构。

图3 Uber围绕Hadoop dataset的大资料架构

混合分析系统的 Kappa 架构

Lambda 和 Kappa 架构都还有展示层的困难点，结果检视如何支援 ad-hoc 查询分析，一个解决方案是在 Kappa 基础上衍生资料分析流程，如下图4，在基于使用Kafka + Flink 构建 Kappa 流计算资料架构，针对Kappa 架构分析能力不足的问题，再利用 Kafka 对接组合 ElasticSearch 实时分析引擎，部分弥补其资料分析能力。但是 ElasticSearch 也只适合对合理资料量级的热资料进行索引，无法覆盖所有批处理相关的分析需求，这种混合架构某种意义上属于 Kappa 和 Lambda 间的折中方案。

图4 Kafka + Flink + ElasticSearch的混合分析系统

Lambda plus：Tablestore + Blink 流批一体处理框架

Lambda plus 是基于 Tablestore 和 Blink 打造的云上存在可以复用、简化的大资料架构模式，架构方案全 serverless 即开即用，易搭建免运维。

表格储存（Tablestore）是阿里云自研的 NoSQL 多模型数据库，提供 PB 级结构化资料储存、千万 TPS 以及毫秒级延迟的服务能力，表格储存提供了通道服务（TunnelService）支援使用者以按序、流式地方式消费写入表格储存的存量资料和实时资料，同时表格储存还提供了多元索引功能，支援使用者对结果检视进行实时查询和分析。

Blink 是阿里云在 Apache Flink 基础上深度改进的实时计算平台，Blink 旨在将流处理和批处理统一，实现了全新的 Flink SQL 技术栈，在功能上，Blink 支援现在标准 SQL 几乎所有的语法和语义，在效能上，Blink 也比社群Flink更加强大。

在 TableStore + Blink 的云上 Lambda 架构中，使用者可以同时使用表格储存作为master dataset 和 batch&stream view，批处理引擎直读表格储存产生 batch view，同时流计算引擎通过 Tunnel Service 流式处理实时资料，持续生成 stream view。

图5 Tablestore + Blink 的 Lambda plus 大资料架构

如上图5，其具体元件分解：

图6 Lambda plus的资料链路

针对上述 Lambda 架构1-4的技术问题，Lambda plus 的解决思路：

总结，表格储存实现了 batch view、master dataset 直接查询、stream view 的功能全集，Blink 实现流批统一，Tablestore 加 Blink 的 Lambda plus 模式可以明显简化 Lambda 架构的元件数量，降低搭建和运维难度，拓展使用者资料价值。

表格储存是如何实现支援上述功能全集的

储存引擎的高并发、低延迟特性：表格储存面向线上业务提供高并发、低延迟的访问，并且 tps 按分割槽水平扩充套件，可以有效支援批处理和 Kappa backfill 的高吞吐资料扫描和流计算按分割槽粒度并发实时处理；

使用通道服务精简架构：Tablestore 资料通道支援使用者以按序、流式地方式消费写入表格储存的存量资料和实时资料，避免 Lambda 架构引入讯息伫列系统以及master dataset 和伫列的资料一致性问题；

二级索引和多元索引的灵活查询能力：储存在表格储存的 batch view 和 real-time view 可以使用多元索引和二级索引实现 ad-hoc 查询，使用多元索引进行聚合分析计算；同时展示层也可以利用二级索引和多元索引直接查询表格储存 master dataset，不强依赖引擎计算结果。

Lambda plus 的适用场景

基于 Tablestore 和 Blink 的 Lambda plus 架构，适用于基于分散式 NoSQL 数据库储存资料的大资料分析场景，如 IOT、时序资料、爬虫资料、使用者行为日志资料储存等，资料量以 TB 级为主。典型的业务场景如：

大资料舆情分析系统：

参考资料

[1].https://yq.aliyun.com/articles/704171?spm=a2c4e.11153959.0.0.229847a2BpWNvc

[2].http://lambda-architecture.net/

[3].http://shop.oreilly.com/product/0636920032175.do, Martin Kleppmann

[4].https://www.oreilly.com/ideas/applying-the-kappa-architecture-in-the-telco-industry

[5].https://www.oreilly.com/ideas/questioning-the-lambda-architecture,Jay Kreps

[6].http://milinda.pathirage.org/kappa-architecture.com/

[7].Moving from Lambda and Kappa Architectures to Kappa+ at Uber

[8].https://eng.uber.com/hoodie/, Prasanna Rajaperumaland Vinoth Chandar

[9].https://eng.uber.com/uber-big-data-platform/, Reza Shiftehfar