粗谈大数据的演变过程

2023-03-09  本文已影响0人  Crespo_Curry

1. 数据仓库架构的演变

数据仓库演变过程

1.1离线大数据架构

数据源通过离线的方式导入到离线数仓中。下游应用根据业务需求选择直接读取 DM 或加一层ADS数据服务，比如 MySQL 或 Redis。数据仓库从模型层面分为三层：

ODS 层: Operation Data Store，数据准备区，贴源层。直接接入源数据的：业务库、埋点日志、消息队列等。ODS 层数数据仓库的准备区

DWD 层:Data Warehouse Details,数据明细层，属于业务层和数据仓库层的隔离层，把持和 ODS 层相同颗粒度。进行数据清洗和规范化操作，去空值/脏数据、离群值等。

DWM 层:Data Warehouse middle,数据中间层，在 DWD 的基础上进行轻微的聚合操作，算出相应的统计指标

DWS 层:Data warehouse service,数据服务层，在 DWM 的基础上，整合汇总一个主题的数据服务层。汇总结果一般为宽表，用于 OLAP、数据分发等。

ADS 层:Application data service, 数据应用层，存放在 ES,Redis、PostgreSql 等系统中，供数据分析和挖掘使用。

离线大数据架构

1.2 Lambda 架构

Lambda 架构（Lambda Architecture）是由 Twitter 工程师南森·马茨（Nathan Marz）提出的大数据处理架构。这一架构的提出基于马茨在 BackType 和 Twitter 上的分布式数据处理系统的经验。

Lambda 架构使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性。

Lambda 架构

1.3 Kappa 架构

Lambda 架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现，流处理技术很成熟了，这 时为了解决两套代码的问题，LickedIn 的 Jay Kreps 提出了 Kappa 架构。
Kappa 架构可以认为是 Lambda 架构的简化版（只要移除 lambda 架构中的批处理部分即可）。

在 Kappa 架构中，需求修改或历史数据重新处理都通过上游重放完成。
Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

图片.png

1.3 Lambda 架构与 Kappa 架构的对比

d 优点 缺点
Lambda 1、架构简单
2、很好的结合了离线批处理和实时流处的优点
4、稳定且实时计算成本可控
5、离线数据易于订正		 1、实时、离线数据很难保持一致结果
2、需要维护两套系统
3、批和流同时运行，消耗资源大
Kappa 1、只需要维护实时处理模块
2、可以通过消息重放
3、无需离线实时数据合并		 1、强依赖消息中间件缓存能力
2、消息中间件无法支持高效OLAP
3、无法复用数据血缘管理体系
4、消息中间件不支持update/upsert

Kappa在抛弃了离线数据处理模块的时候，同时抛弃了离线计算更加稳定可靠的特点。Lambda虽然保证了离线计算的稳定性，但双系统的维护成本高且两套代码带来后期运维困难。

为了实现流批处理一体化

1.4 批流一体

1.5 批流一体转到湖仓一体

1.5.1 概念

1.4.2 三大数据湖技术Delta、Hudi、Iceberg

目前市面上流行的三大开源数据湖方案分别为：Delta、Apache Iceberg 和 Apache Hudi。其中，由于 Apache Spark 在商业化上取得巨大成功，所以由其背后商业公司 Databricks 推出的 Delta 也显得格外亮眼。Apache Hudi 是由 Uber 的工程师为满足其内部数据分析的需求而设计的数据湖项目，它提供的 fast upsert/delete 以及 compaction 等功能可以说是精准命中广大人民群众的痛点，加上项目各成员积极地社区建设，包括技术细节分享、国内社区推广等等，也在逐步地吸引潜在用户的目光。Apache Iceberg 目前看则会显得相对平庸一些，简单说社区关注度暂时比不上 Delta，功能也不如 Hudi 丰富，但却是一个野心勃勃的项目，因为它具有高度抽象和非常优雅的设计，为成为一个通用的数据湖方案奠定了良好基础。

2.计算框架对比Apache Flink、Spark Structured Streaming、Storm

2.1 Flink

Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed to run in all common cluster environments, perform computations at in-memory speed and at any scale.

Flink

2.2 Spark Structured Streaming

Structured Streaming is a scalable and fault-tolerant stream processing engine built on the Spark SQL engine. You can express your streaming computation the same way you would express a batch computation on static data. The Spark SQL engine will take care of running it incrementally and continuously and updating the final result as streaming data continues to arrive


Structured Streaming

2.3 对比

Apache Flink Spark Streaming（Spark 2.4后，基本不维护） Spark Structured Streaming Storm
定义 Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。 Spark Streaming是将流式计算分解成一系列短小的批处理作业。这里的批处理引擎是Spark，也就是把Spark Streaming的输入数 据按照batch size（如1秒）分成一段一段的数据（Discretized Stream），每一段数据都转换成Spark中的RDD（Resilient Distributed Dataset ） ， 然 后 将 Spark Streaming 中 对 DStream 的 Transformation 操 作 变 为 针 对 Spark 中 对 RDD 的 Transformation操作，将RDD经 过操作变成中间结果保存在内存中。 Structured Streaming是一个基于sparksql引擎开发的可伸展和容错的流处理引擎。Structured Streaming传输中的关键思想是将实时数据流视为被连续添加的表。
这导致了一个新的流处理模型，该模型与批处理模型非常相似。您将像在静态表上一样将流计算表示为类似于批处理的标准查询，Spark在无界输入表上将其作为增量查询运行。		 Storm是一个免费并开源的分布式实时计算系统。利用Storm可以很容易做到可靠地处理无限的数据流，像Hadoop批量处理大数据一样，Storm可以实时处理数据。
架构 架构介于Spark和Storm之间，主从结构与SparkStreaming相似，DataFlow Grpah与Storm相似 架构依赖Spark，每个Batch处理都依赖主（Driver），可以理解为时间维度上的spark DAG。 主从模式，且以来Zookeeper，处理过程中对主节点依赖不大。
处理模式 Native Micro-batch Micro-batch
Continuous mode
是传统的流处理模式，通过运行一个 long-running 的 operator 用来处理数据。		 Native
容错 基于CheckPoint机制
检查点机制：通过分布式一致性快照机制， 对数据流和算子状态进行保存。在发生错误时，使系统能够进行回滚。		 WAL及RDD机制
会将经常用的RDD或者对宽依赖加Checkpoint。利用SparkStreaming的direct方式与Kafka可以保证数据输入源的，处理过程，输出过程符合exactly once。		 Structured Streaming采取检查点机制，把进度offset写入stable的存储中，用JSON的方式保存支持向下兼容，允许从任何错误点进行恢复。 Records ACK
ACK 机制：对每个消息进行全链路跟踪，失败或者超时时候进行重发
处理模型与延迟 单条事件处理 亚秒级低延迟 窗口事件处理 秒级高延迟 窗口事件处理事件处理 亚秒级低延迟 单条事件处理 亚秒级低延迟
吞吐量 High High High Medium
数据处理保证 excatly once excatly once excatly once
At-least-once		 excatly once
高级API SQL
Table API
SQL支持方面还有很大提升空间		 Spark SQL
相应的优化、扩展和性能更好		 Spark SQL
相应的优化、扩展和性能更好		 应用需要按照特定的Storm定义的规则编写。
易用性 支持SQL streaming，Batch和Streaming采用统一变成框架 支持SQL straming，Batch和Streaming采用统一变成框架 支持SQL straming，Batch和Streaming采用统一变成框架 不支持SQL streaming。
成熟性 新兴项目，处于发展阶段 成熟，稳定 成熟，稳定 相对较早的流系统，比较稳定
部署性 部署相对简单，只依赖Java环境 部署相对简单，只依赖Java环境 部署相对简单，只依赖Java环境 依赖Java和Zookeeper

At-most-once: 这实质上是一个“尽力而为”（best effort）的方法。数据或者事件被保证只会被应用中的所有算子最多处理一次
At-least-once: 数据或事件被保证会被应用图中的所有算子都至少处理一次。这通常意味着当事件在被应用完全处理之前就丢失的话，其会被从source开始重放（replayed）或重传（retransmitted）。由于事件会被重传，那么一个事件有时就会被处理超过一次，也就是所谓的at-least-once。
Exactly Once : 每个消息对于接收者而言正好被接收一次，保证即不会丢失也不会重复。

3. 框架学习

上一篇下一篇

猜你喜欢

热点阅读