大数据引擎分类总结

目前世面上大数据处理引擎有非常多，让人眼花缭乱，为方便在学习使用中，进行合理的技术选型，业界从不同的角度对大数据引擎进行分类。

一、按响应时间分类

2016年AtScale在一篇SQL On Hadoop大数据引擎性能测评报告中，指出没有一个大数据计算引擎能够在所有场景下胜出，为区分一众大数据引擎，报告中根据用户提交查询到结果返回的时间长短，将大数据处理系统分为三类：Batch SQL、InteractiveSQL，operation SQL。

离线批处理引擎(Batch SQL)

离线批处理引擎响应时间通常在分钟、小时级别。常见的包括Hadoop MapReduce、Apache Spark、Hive等，阿里的MaxCompute。具体特点：

1. 应用场景：主要处理静态的、历史积累的大量数据，通过批处理提供全面、准确可靠的数据运用于业务。像阿里所有业务数据每天都会批量同步到MaxCompute，应用于计算分析报表，优化训练推荐算法，构建搜索引擎索引，共享数据给电商下游广告&物流开展业务。
2. 批量处理：执行大规模的数据计算和转换任务，如数据清洗、转换、关联聚合计算等。
3. 高吞吐量：设计用于处理大量数据，通常具有较高的吞吐量。
4. 高延迟性：处理结果通常不是实时的，有一定的延迟，如T+1（今日处理昨日数据）、小时级别数据。
5. 资源消耗：由于处理大量数据，可能会占用较多的计算资源和存储资源。

交互式分析引擎(Interactive SQL)

交互式分析引擎响应时间通常在秒、分钟级别。常见包括Apache Impala、ClickHouse、Google BigQuery，阿里ADS，FAE等。具体特点：

1. 应用场景：主要用于交互式分析，我知道的比较广泛的是阿里各种人群画像、标签系统，比如阿里妈妈的达摩盘【DMP】，淘天的奥格，一般是提供给业务运营，小二使用来从各种维度快到圈选到目标数据用以辅助开展业务。
2. 低延迟：提供快速的查询响应时间，通常延迟在数秒到数分钟之间。
3. 复杂查询：支持复杂的查询条件和多维度分析，满足灵活的数据分析需求。
4. 大规模查询：能够处理千亿级别的表记录，并返回相对较小的结果集。
5. 并发度：支持几百甚至上千条查询同时并发执行。
6. 易用性：提供SQL接口，便于用户编写和执行查询语句。

实时操作引擎（Operation SQL）

查询计算延迟在毫秒-秒级别。常见技术包括Apache Kafka、Apache Flink、Spark Streaming、Redis、Hbase、Hologress、Mysql等。

1. 应用场景：适用于实时监控、实时分析、在线决策支持等场景。或应用于联机在线应用系统，各类APP中用户大部分操作后台应用背后都是这类引擎。
2. 实时性：能够实时或近实时地处理数据，确保数据的最新状态被及时反映。
3. 低延迟：处理结果几乎立即可用，适合需要快速响应的场景。
4. 高吞吐量：尽管处理的是实时数据流，但也需要具备处理高吞吐量的能力。
5. 容错性：具备高容错性，确保在数据流中断或处理异常时能够恢复并继续处理。

二、按引擎实现架构分类

计算机发展早期SMP（Symmetric Multi-Processing，对称多处理）、NUMA（Non-Uniform Memory Access，非一致存储访问）、MPP（Massively Parallel Processing，海量并行处理）这些名词是用来描述服务器架构的，主要区分依据是CPU、内存的配合方式。

后来随着互联网、分布式系统的发展，也会用来描述分布式系统架构，因为分布式系统本质也是在用多个服务器来解决大规模计算、存储的问题。

SMP（对称多处理）架构

SMP（Symmetric Multi-Processing，对称多处理）架构是一种多计算节点，各计算节点之间共享存储节点的系统。在这种架构中，所有的计算节点地位平等，没有主次从属关系，它们共同协作完成计算任务。

这种架构一般用于客户请求并发不是很高的系统，比如企业ERP，CRM系统，小二运营后台，配置运维系统。

特点：

• 存储资源共享：所有计算节点共享存储，访问延迟一致。
• 扩展性有限：随着计算节点数量的增加，共享资源的访问冲突也会增加，从而影响系统整体性能。
• 负载均衡：系统需要确保各个计算节点的负载均衡，以避免资源浪费。

NUMA（非一致存储访问）架构

NUMA（Non-Uniform Memory Access，非一致存储访问）允许业务请求被分配到任一计算节点，每个计算节点拥有自己的本地内存。计算节点可以访问本地内存，也可以访问任意存储节点，来完成业务请求。

互联网面向C端高并发的系统一般是这种架构，比如淘宝商品详情，购物车，下单交易，评论等系统。可以横向扩展节点来支持双11大促，或者用户日益增长的诉求。

特点：

• 访问延迟低：通过将计算请求分配到各个节点，计算节点可以优先访问本地内存，或者访问某个存储节点即可完成请求计算。访问延迟很低。
• 高扩展性：NUMA架构允许系统以节点为单位进行横向扩展，可以灵活调整系统的规模。当然存储节点的横向扩展因为涉及数据迁移会稍微麻烦一些。
• 负载均衡：通过分散负载到不同的节点，可以实现系统的负载均衡。

MPP（海量并行处理）架构

MPP（Massively Parallel Processing，海量并行处理）架构是一种数据库系统的设计模式，它允许数据处理任务在多个计算节点上并行执行。每个节点都有自己的处理器、内存和本地存储，可以独立执行查询的一部分。

MPP架构非常适合处理大规模数据集和执行复杂的查询操作。它广泛应用于大数据处理、机器学习和高性能计算等场景。

具体案例如搜索引擎，广告推荐引擎，标签系统一般采用这种架构，需要多个计算、存储节点配合，快速高效的从海量数据集中计算出用户搜索，喜欢的商品，内容。

特点：

• 并行处理：MPP架构的核心优势在于能够将数据处理任务分解并在多个节点上并行执行。
• 分布式数据存储：数据被水平分割并分布在不同的节点上，每个节点只存储数据的一部分。
• 高可用性和容错性：MPP架构通常支持冗余和容错机制，确保系统的可靠性和数据完整性。
• 高可扩展性：通过增加节点，MPP架构可以很容易地扩展处理能力和存储容量。

三、按数据流处理架构分类

Lambda架构

一、基本概念

Lambda架构由Twitter前工程师Nathan Marz提出，旨在处理大规模数据时，同时发挥流处理和批处理的优势。通过批处理提供全面、准确的数据，通过流处理提供低延迟的数据，从而达到平衡延迟、吞吐量和容错性的目的。

Lambda架构主要包含三层：

批处理层（Batch Layer）：

• 负责存储和管理主数据集，预先批处理计算好的视图，确保数据的准确性。
• 使用Hadoop、Spark等框架计算。

速度处理层（Speed Layer）：

• 实时处理新数据，提供最新的数据视图以最小化延迟。
• 使用Storm、Spark Streaming、Flink等框架计算。

服务层（Serving Layer）：

• 合并批处理层和速度层的结果，响应查询请求。

二、主要优点

• 实时与批量处理结合：同时提供实时和离线的数据处理能力。
• 数据准确性：批处理层保证数据的准确性。
• 容错性：系统设计能够容忍机器故障和人为错误。
• 低延迟：通过速度层提供实时数据处理。
• 可扩展性：通过增加资源来应对数据量和负载的增长。

三、主要问题

• 开发成本高：需要在两个不同的API中对同样的业务逻辑进行两次编程。
• 数据口径问题：实时和批量计算走的是两个计算框架和计算程序，数据结果可能不一致。空间浪费。
• 维护学习成本高：由多种引擎和系统组合而成，维护成本高，学习成本高。

阿里绝大部分业务场景早期都是这种架构，至今仍然有很大一部分使用的是这种架构。

Kappa架构

一、基本概念

Kappa架构由LinkedIn的前首席工程师Jay Kreps提出，可以看作是Lambda架构的简化版本。Kappa架构的核心思想是仅使用一套流处理系统来处理实时数据和历史数据，从而简化系统架构。

Kappa架构主要包含两层：

消息传输层（Speed Layer）：

• 提供接收和存储流数据的消息队列，数据可以在某个需要限度内全量存储，并在必要时从头开始读取重新计算，从而获得可靠结果。

流处理层（Serving Layer）：

• 提供流计算引擎，用于进行流分布式实时计算。同时，这一层也负责响应查询请求。

二、主要优点

• 简化开发和维护：只需要维护一套数据处理逻辑。
• 实时与批量处理一致性：通过数据重放机制，确保实时处理和批量处理结果的一致性。
• 易于扩展：基于流处理，可以水平扩展来处理不断增长的数据量。

三、主要问题

• 流处理系统的成本高：由于流处理系统很多临时状态都是在内存中进行。对海量历史数据处理时，内存资源开销会非常大，导致计算成本很高。
• 历史海量数据复杂运算困难：对历史海量数据进行大规模关联，去重以及进行复杂算法计算时，单纯用流处理系统无法胜任，需要额外增加数据库，Redis等外挂状态缓存增加计算任务复杂度。

Lambda架构与Kappa架构的对比

总之，Lambda架构和Kappa架构各有优缺点，选择哪种架构应根据实际业务需求和数据处理场景来决定。

HSAP：服务分析一体化架构

一、基本概念

无论是lambda、Kappa都有一定的硬伤，阿里提出了HSAP（Hybrid Serving and AnalyticalProcessing）理念，它既能支持很高QPS场景的查询写入，又能将复杂的分析场景在一套体系里面完成。

HSAP理念的架构目标：

• 首先，要有一套非常强大的存储，能够同时存储实时数据和离线数据，统一数据存储；
• 同时还要有一种高效的查询服务，在同一个接口下（比如SQL），能够支持高QPS的查询，支持复杂的分析以及联邦查询和分析；
• 系统能够直接对接前端应用，例如报表和在线服务等，不需要再额外的导入导出就能即席分析，统一数据服务，减少数据移动。

该架构实现引擎Hologress参考我的另外一篇文章：Hologress服务分析一体化数仓简介

阿里云官方文档：实时数仓 Hologres

二、主要优点

• 开发&维护非常简单：只需要维护一套数据存储，计算逻辑，可以像使用mysql一样使用Hologress进行各种复杂的点查，数据分析计算。
• 实时与批量处理能力都很强：实时流&离线流，存储计算代码逻辑是一致的，由引擎封装，无需开发者维护。
• 可直接对接前端应用：例如报表和在线服务等，不需要再额外的导入导出就能即席分析，统一数据服务，减少数据移动。

三、主要缺点

• 成本：虽然Hologres提供了低成本的数据仓库解决方案，但随着数据量的增长和查询复杂度的提高，所需的计算资源和存储成本可能会显著增加。
• 性能瓶颈：在处理极大规模的数据集或进行非常复杂的查询时，Hologres的性能可能会受到一定的限制。这可能需要通过优化查询语句、调整资源配置或采用其他技术手段来缓解。