大数据生态之数据处理框架探索
数据处理框架
数据处理是一个非常宽泛的概念,数据处理框架在数据架构中,主要是用于数据移动和分析这两大功能当中.对于数据移动,有离线数据移动和实时数据移动,也可以叫做是批量数据移动和流式数据移动.而对于分析这一块,有离线数据分析和实时数据分析,也可以称作是批量数据分析和流式数据分析.离线和实时,批量和流式,针对这两种不同的形式,就出现了多种不同的数据处理框架.有批量的数据处理框架,有流式的数据处理框架,也有批流融合的框架.
批量数据处理框架
批量数据处理框架最经典的就是 mapreduce 了,这也是 apache hadoop 最早期的形态,使用 mapreduce 对 hdfs 上面大批量的数据进行计算和处理.基于它写出来的应用程序能够运行在由上千个商用机器组成的大型集群上，并以一种可靠容错的方式并行处理大批量的数据集。但是由于 mapreduce 的编写并不很直观,对于开发人员的门槛较高,之后在 mapreduce 之上出现了新的产品,做为 mapreduce 的升级产品.那就是 apache pig 和 apache hive. Apache pig 和 apache hive 都是基于 mapreduce ,并给开发人员提供了更加简便使用的方法和接口以及更加丰富的语义处理.
- Apache Pig是MapReduce的一个抽象。它是一个工具/平台，用于分析较大的数据集，并将它们表示为数据流。Pig通常与 Hadoop 一起使用；我们可以使用Apache Pig在Hadoop中执行所有的数据处理操作.
| Apache Pig | MapReduce |
|---|---|
| Apache Pig是一种数据流语言。 | MapReduce是一种数据处理模式。 |
| 它是一种高级语言。 | MapReduce是低级和刚性的。 |
| 任何具备SQL基础知识的新手程序员都可以方便地使用Apache Pig工作。 | 没有相关经验难以编写 |
| 在Apache Pig中执行Join操作非常简单。 | 在MapReduce中执行数据集之间的Join操作是非常困难的。 |
| Apache Pig使用多查询方法，从而在很大程度上减少代码的长度。 | MapReduce将需要几乎20倍的行数来执行相同的任务。 |
| 没有必要编译。执行时，每个Apache Pig操作符都在内部转换为MapReduce作业。 | MapReduce作业具有很长的编译过程。 |
- hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的SQL查询功能，可以将SQL语句转换为MapReduce任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。
| Apache Hive | MapReduce |
|---|---|
| 通过SQL轻松访问数据的工具，从而实现数据仓库任务，如提取/转换/加载（ETL），报告和数据分析。 | 需要使用 java 等编程语言编写 mapreduce 程序来实现 |
| 对于各种不同的数据格式,可为之添加各种抽象的结构化信息,比如表,分区,桶 | 只能对原始数据进行手动的原始的文件管理 |
| 可以直接访问多种数据存储系统,包括 hdfs 和 hbase 等 | 只能直接访问 hdfs |
| 可以使用更加除了 mapreduce 之外更加高级的执行引擎,比如 apache tez,apache spark | 只能以 hadoop 作为执行引擎,效率低 |
Hive 和 Pig 最大的不同就是一种使用 Latin 语言,一种使用 HiveQL 语言.这就导致了如今 Hive 成为了绝对的主流,Pig 已经很少人用了.HiveQL 这种类 SQL 语言解决了批量数据处理的易用性问题,现在不仅开发人员能够编写大数据处理程序,普通的分析人员和业务人员也能够使用Hive进行大数据处理和分析. 但是 Hive 并没有解决速度问题,于是在 Hive 之上,基于 Hive,又出现了新的数据处理技术和框架,比如 impala,presto,kylin 等,这个领域技术方案非常繁荣.这里不赘述。
流式数据处理框架
流式数据处理,也称实时数据处理.数据是一条一条产生的,当数据产生的时候,我们可以把它先存起来,供后续处理,这就是上面所说的离线(批量)数据处理.而现在越来越多的做法是数据产生时就立马对它进行计算和分析,而这就是实时数据处理或者叫实时计算.而数据理论上是不断产生的,不断产生的数据不断的发往数据处理框架进行计算和分析,就像一条流,所以实时计算也称作是流式计算.还有一种做法是把批量数据读成一条一条的进行处理(比如 nifi).所以流式计算处理的不一定是实时数据,也可能是离线数据.
流式框架最经典,也是最老的就是 Storm,Storm 一款开源分布式实时计算框架.它相对比较稳定,具有高容错性,也比较高效.
Storm 的基本概念:
- Stream
以Tuple为基本单位组成的一条有向无界的数据流 - Tuple
Integer,long,short,byte,string,double,float,boolean和byte array，包括自定义类型. - Topology
计算逻辑的封装
由spouts和bolts组成的图，通过stream grouping将图中的spouts和bolts连接起来
类同MapReduce中的job.
Storm 是一款比较老的框架,流式计算的开创者,推出后也有非常广泛的应用.流式计算的框架技术一直不断发展,后来也出现了Storm的类似框架 samza.
国内阿里巴巴也对 Storm 进行了改良 : jstorm ,jstorm 更加稳定,功能更强大. 对 Storm 来说，现在处于一个英雄垂暮的阶段，很多特性是在它那个时代是没有考虑过的.
最近几年,流式数据处理领域,又出现了一些新的参与者.由于流式数据往往不是直接发往流式计算平台进行处理,它需要一个中间层过渡,进行数据的缓冲,缓存和分发,这个中间层就是通常我们所说的消息系统,消息中间件.(老的说法也叫消息队列,但现在的消息系统要比消息队列复杂和强大很多倍).几乎所有的流式计算过程都会前置一个消息系统.所以后来消息系统就干脆集成上流式数据处理的功能,把流式数据处理也一并做了.现在最流行的消息系统就是 kafka ,kafka 在2017 年就推出了 kafka streams.消息系统的后起之秀: apache pulsar ,自带 Pulsar Functions,一个流式数据处理引擎(pulsar 号称是 kafka 的替代品 ,这部分内容待补充)。
Kafka Stream 现在是一个 lib 库,使用这个库可以很方便的构建以 kafka 集群为数据来源的应用和微服务. Kafka streams 最大的特点就是它较为简单,对于开发人员来说门槛比较低:
- 开发只需要一个简单 lib 包,除了 kafka 外没有其余外部依赖了
- 保证只处理一次的语义,开发人员不需要额外关心
- 不仅支持一条条处理数据,也能够基于窗口操作处理多条数据
- 对于流式处理提供高级简单的DSL ,也提供比较低级的处理接口
Kafka Stream 处理的拓扑图:
- stream 是一个抽象概念,代表了没有边界的,持续更新的数据 record 流. Data record 是一个键值对.
- stream processor 整个拓扑图中的一个节点,代表中间的一个处理步骤.有2个特殊的processor: source processor ; sink processor
- stream processing application 一个流式处理应用可由多个处理流程构成:
批流融合数据处理框架
无论是批量处理还是流式处理,技术框架的发展最终都要走向统一,变得更加简单,更加易用.而Spark 就是这个统一者.Spark 框架一经出现,立马就流行起来.如今 Spark 是一个统一的大规模数据处理和分析计算引擎,并且也有非常丰富的spark 生态,官方生态有 DataFrames and SQL (批处理引擎,其中SQL 是比hive 更快的查询引擎),Spark Streaming(流处理引擎),MLib(机器学习库),GraphX(图计算引擎).还有很多基于Spark 的第三方生态.比如 apache mahout(用于开发机器学习应用的框架),Koalas(Python库 pandas 的 Spark 版本).
还有前不久开源的Delta Lake,一个基于 Spark 的数据湖解决方案,它作为一个数据存储层(storage layer),具有非常强大的特性.
Spark 是这个领域老牌框架,但是也有后来者.那就是 Flink,这个数据流计算的新贵.
Flink 的出现是为了解决 Spark Streaming 的一个设计缺陷,Spark Streaming 的设计是通过 micro-batch 微批处理来模拟流处理,实际上并不是真正的流处理.也就是说 Spark Streaming 是达不到 Storm 那样毫秒级的低延时的.Flink 解决了这个问题,它是真正的流处理,真毫秒级的低延时.
虽然,Spark Streaming 在新版本中推出了 Structure streaming,废弃了之前的微批处理,也达到了真正的低延时.不过,目前,国内的公司还是越来越多选择 Flink 作为核心的数据处理框架.这里引用 OPPO 大数据平台负责人张俊的一句话:
但是我们认为，整个技术框架发展，技术最终肯定是趋同的。为什么选择 Flink？还有一个很重要的原因是最近两年 Flink 在国内的发展普及程度。包括像阿里团队，他们也在大力地宣传跟投入，包括今天 QCon 大会上大沙和云邪两位老师，他们也是阿里团队社区的资深大 V。
批流融合处理框架还一个小众的框架 Apache Apex,跟 Flink 差不多.
批流融合之上
上面说过,技术框架的发展最终都要走向统一.如今批流数据和流式数据处理现在统一了,那还能继续统一吗.答案是能.目前批流一体数据处理框架有Spark,有 Flink ,还有基于公有云的 google cloud dataflow.由于开源,这些技术框架都会相互借鉴,最终都会是大同小异.所以就有办法把这些处理框架再统一起来,形成一个统一的编程模型.这个就是 Apache Beam.
Apache Beam 不是一个数据处理引擎,它不自己处理数据.它只是一层 layer.这层 layer 可运行在各种不同的数据处理引擎之上,比如 spark ,flink 等.它的作用简单来说,就是beam编写的一套代码,可以直接运行在 spark,flink 等各种不同的数据处理引擎中.
Apache beam 本质上是一套 sdk ,这一套 sdk 使用统一的编程模型来编写批处理和流处理程序,并且还提供了不同语言的比如python,go ,java的版本.
Beam 提供的这个编程模型就是 Pipeline,使用 beam 来编程,其实就是构建好一个 pipeline ,也可以叫做是数据处理程序的抽象.
这就是一个基本的pipeline,其实跟spark ,flink 中的DAG 图都差不多.
Pipeline 编写时,我们要指定它的runner,这就是 apache beam 的另一个抽象
Runner 即 pipeline 的执行引擎,例如 spark Runner,flink runner 等.beam 就是通过这个 runner 使得 pipeline 可以运行在多种不同的分布式运算框架上.
未完待续
数据处理框架一直飞速发展，但总体来说，有一个清晰的内在发展逻辑：那就是在易用性上，统一性上，经济性上不断向前。目前的国内的一个趋势是整个大数据栈也在往云上走，因为云完全契合这三点。
