粗谈大数据的演变过程

Posted 2023-03-11

1. 数据仓库架构的演变

数据仓库演变过程

1.1离线大数据架构

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

• ODS 层

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

• DW数仓

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

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

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

• ADS层

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 批流一体

• 架构角度
• 计算框架处理角度
• SQL支持角度
• 存储层面

1.5 批流一体转到湖仓一体

1.5.1 概念

• 数据库 主要用于「事务处理」，存取款这种算是最典型的，特别强调每秒能干多少事儿：QPS（每秒查询数）、TPS（每秒事务数）、IOPS（每秒读写数）等等。可是，数据库“脑容量不足”，擅长事务性工作，不擅长分析型的工作，于是就产生了数据仓库。
• 数据仓库 相当于一个集成化数据管理的平台，从多个数据源抽取有价值的数据，在仓库内转换和流动，并提供给BI等分析工具来输出干货。但是，企业希望把生产经营中的所有相关数据，历史的、实时的，在线的、离线的，内部的、外部的，结构化的、非结构化的，都能完整保存下来，方便“沙中淘金”。
• 数据湖 是由“数据存储架构+数据处理工具”组成的解决方案，而不是某个单一独立产品。

• 数据存储架构，要有足够的扩展性和可靠性，要满足企业能把所有原始数据都“囤”起来，存得下、存得久。
  一般来讲，各大云厂商都喜欢用对象存储来做数据湖的存储底座，比如 Amazon Web Services（亚马逊云科技），修建“湖底”用的“砖头”，就是S3云对象存储。
• 数据处理工具，则分为两大类

• 第一类工具: 解决的问题是如何把数据“搬到”湖里，包括定义数据源、制定数据访问策略和安全策略，并移动数据、编制数据目录等等。
  比如，Amazon Web Services提供“Lake Formation”这个工具，帮助客户自动化地把各种数据源中的数据移动到湖里，同时还可以调用Amazon Glue来对数据进行ETL，编制数据目录，进一步提高湖里数据的质量。
• 第二类工具: 就是要从湖里的海量数据中“淘金”。
  比如Amazon Web Services来举例子，基于Amazon Athena这个服务，就可以使用标准的SQL来对S3（数据湖）中的数据进行交互式查询。

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 丰富，但却是一个野心勃勃的项目，因为它具有高度抽象和非常优雅的设计，为成为一个通用的数据湖方案奠定了良好基础。

• Databricks 推出的 delta
  
  
  

delta

• Uber 团队在 Apache Hudi
  
  
  

Hudi

• Netflix 和 Apache Iceberg
  腾讯的实时数仓的实现
  
  
  

Iceberg

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. 框架学习

• 数据采集技术：SQOOP、Flume、DataX、Kettle、Maxwell、Canal、Nifi
• 中间件技术：分布式协调服务Zookeeper、分布式缓存Redis、分布式消息系统Kafka、分布式消息系统Pulsar、ELK Stack 数据分析
• 分布式存储技术系统：分布式文件系统Hadoop HDFS、分布式数据库HBase、分布式数据库仓库Hive、数据湖技术Hudi、数据湖Delta lack、数据湖Iceberg
• 分布式计算框架：
• 批处理框架：Hadoop MapReduce
• 流处理框架：Storm
• 混合处理框架：Spark、Flink
• 查询分析框架：Hive 、Spark SQL 、Flink SQL、 Pig、Phoenix
• OLAP生态体系：OLAP-ClickHouse、OLAP-Kudu
• 集群资源管理器：Hadoop YARN
• 任务调度框架：Azkaban、Oozie
• 集群部署和监控：Ambari、Cloudera Manager