构建技术中台——基于SQL的批流一体化ETL

最新推荐文章于 2023-08-14 11:45:20 发布

普元EAWorld

最新推荐文章于 2023-08-14 11:45:20 发布

阅读量580

点赞数

文章标签：数据库分布式大数据 java hadoop

本文链接：https://blog.csdn.net/weixin_45443931/article/details/111602246

版权

转载本文需注明出处：微信公众号EAWorld，违者必究。

本文介绍了 SparkSQL 和 Flink 对于批流支持的特性以及批流一体化支持框架的难点。在介绍批流一体化实现的同时，重点分析了基于普元 SparkSQL-Flow 框架对批流支持的一种实现方式。希望对大家的工作有所帮助，也希望能对 DatasetFlow 模型作为框架实现提供一些启发。

目录：

1.SparkSQL 和 Flink 对于批流支持的特性介绍

2.基于SparkSQL-Flow的批量分析框架

3.基于SparkStreaming SQL模式的流式处理支持

4.对于批流一体化ETL的思考

一、SparkSQL 和 Flink

对于批流支持的特性介绍

关于流和批的一些争论

对于广泛使用的Spark和新秀Flink，对于批和流实现方式上，以及在论坛和一些文章上，对批和流都有不同看法。批是流的特例还是流是批的特例？

1.从批的角度看，流是多个批次一份一份的进行。无限个这样批次构成整个流处理流程，类如SparkStreaming的处理模式；

2.从流的角度看，批是流的有限流处理。它只不过在某个时间点，完成某个条件停止了而已；类如 Flink 的处理模式；

Spark 和 Flink 都具有流和批处理能力，但是他们的做法是截然相反。Spark Streaming是把流转化成一个个小的批来处理，这种方案的一个问题是我们需要的延迟越低，额外开销占的比例就会越大，这导致了Spark Streaming很难做到秒级甚至亚秒级的延迟。Flink是把批当作一种有限的流，这种做法的一个特点是在流和批共享大部分代码的同时还能够保留批处理特有的一系列的优化。数据仓库早期以及大数据早期都是从批处理开始的，所以很多系统都是从批处理做起，包括Spark。在批处理上Spark有着较深的积累，是一个比较优秀的系统。随着技术的发展，很多原来只有批处理的业务都有了实时的需求，流处理将会变得越来越重要，甚至成为一些数据分析的主要场景，如实时管控、预警相关。

Spark 和 Flink 的异同点

Flink 早期仅支持流式处理，这几年的Flink无论从API组织，还是运行方式，还是多样性都越来越像Spark。

批和流是数据融合的两种应用形态

传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。

与批模式相比相比，其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于业务的日志、消息队列的消息。进而通过一个实时计算引擎，进行各种聚合运算，产生输出结果，并且写入下游。Spark 和 Flink 都能够支持批和流两种概念。只不过像 Flink，其原生就是为流而生，所以在流处理上更自然。

Spark 是有太多包袱，Spark 最早采用 RDD 模型，达到比 MapReduce 计算快 100 倍的显著优势，对 Hadoop 生态大幅升级换代。RDD 弹性数据集是分割为固定大小的批数据，自动容错、位置感知、本地计算、可调度可伸缩等众多重要特性。RDD 提供了丰富的底层 API 对数据集做操作，为持续降低使用门槛，Spark 社区开始开发高阶 API：DataFrame/DataSet，Spark SQL 作为统一的 API，掩盖了底层，同时针对性地做 SQL 逻辑优化和物理优化。Spark 早期的主要目标是替代 MapReduce，MapReduce 是大数据批处理的核心模型。

二、基于SparkSQL-Flow的

分析框架

何为 SparkSQL-Flow

1.一个由普元技术部提供的基于 SparkSQL 的开发模型;

2.一个可二次定制开发的大数据开发框架，提供了灵活的可扩展 API；

3.一个提供了对文件，数据库，NoSQL、流处理等统一的数据开发模式；

4.基于 SQL 的开发语言和 XML 的模板配置，支持 SparkSQL UDF 的扩展管理；

5.支持基于 Spark Standlone，Yarn，Mesos 资源管理平台；

6.支持多种平台Kerberos认证（开源、华为、星环）等平台统一认证；

SparkSQL Flow XML 概览

用户只需要定义 Source，Transformer，Target 几个核心组件：

1.Source 数据源：支持Data、DB、File、NoSQL、MQ 等众多源；

2.Transformer 为上述定义的数据源和已有的Transformer 间的组合操作，一般为SQL；

3.Target 为输出目标，支持show、DB、File、NoSQL、MQ 等众多目标，支持类型基本和源相同；

4.用户可以在Properties定义一些变量，作为Source/Transformer/Target 的宏替换；

SparkSQL Flow 适合的场景

1.批量 ETL；

2.非实时分析服务；

3.流式 ETL；

支持从多种获得数据源：

1.支持文件：JSON、TextFile（CSV）、ParquetFile、AvroFile

2.大数据：Hive、HDFS

3.支持RDBMS数据库：PostgreSQL、 MySQL、Oracle

4.支持 NOSQL 数据库：Hbase、MongoDB、Redis

5.Streaming：JMS、AMQP、Kafka、Socket

三、基于SparkStreaming

SQL模式的流式处理支持

SparkSQL-Flow 流式处理支持

ALL in SQL 的设计，能给数据开发人员提供极大方便，复杂SQL的表达能力也不弱。

SparkSQL-Flow 流式处理和批处理的配置没什么不同，定义一个流式 Source，如Kafka。流或批模式是由 Source 的实现决定。SparkSQL-Flow 在加载底层 SPI 来识别该 Source 是 Streaming 模式，还是批处理模式。加载时，配置的 Source 中有任意一个是 Streaming 类型，则认为是流处理模式。

SparkSQL-Flow流处理过程中的关联

在 ETL 或者一些实时流处理中，我们常常需要对数据做一些关联，如字典表关联、字段转义等操作。这在数据处理业务场景中很常见。

我们在 Flow XML 中定义多个Source，这样在流处理过程中，流可以在任意 Transformer 中关联其他 Source 表中的字段。另外，我们可以对作为关联的 Source（Transformer的结果亦可）做 cache 处理，这样根据 Spark 的模式，该表处于内存中，且整个Job 运行时不会再次触发该Source 的 Stage，可以提高性能。

除了使用 Select ... Join 的方式关联，还可以使用自定义 UDF 的方式关联字段，UDF 中可以有转换、调用数据库、可以调用 RESTApi 等等。

四、对于批流一体化ETL的思考

Kettle ETL 工具

提到 ETL 不得不提 Kettle。批、流、数据源、多样性大多数设计的ETL工具在他面前都相形见绌。

Kettle 作业是生成了一个 dbr 文件，该 dbr 本质上是 Kettle 支持的特有规范的一种 XML，Kettle 是实现了执行该 XML 规范的一种解释器。

但是 Kettle 的缺点很明显，他的数据处理都是 Local 模式，对于大数据系统，把数据拉到运行节点再计算缺陷是很明显的。并且作业无法并行化，云化，无法利用大规模集群的算力。

DataX

DataX 是阿里开源的一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。

DataX设计理念

DataX本身作为数据同步框架，将不同数据源的同步抽象为从源头数据源读取数据的Reader插件，以及向目标端写入数据的Writer插件，理论上DataX框架可以支持任意数据源类型的数据同步工作。同时DataX插件体系作为一套生态系统, 每接入一套新数据源该新加入的数据源即可实现和现有的数据源互通。

DataX 理论上也支持流处理，不过他的处理方式跟 Spark 类似，流是当做无限的批来处理。如果了解SpringBatch的话，DataX 更像是多线程的 SpringBatch 的架构。DataX 没有提供设计器，他提供了丰富的Reader和Writer和易扩展的插件系统。和 Kettle一样，DataX 也需要把数据拉到本地计算，并不具有分布式处理能力。

理想中的批流一体ETL

具有如 Kettle 般的算子表达能力，又具有完全的大数据处理能力。