几种数据处理框架的场景比较：传统ETL工具MapreduceHiveSpark

Posted 2021-04-19 twt企业IT社区

提起“大数据”就不得不提起有关数据的处理，虽然有人说过大数据在数据质量方面的要求不比传统数据的要求那么严格，当然这也是分场景的断言，但是无论何时数据处理在大数据的生态中始终处于不可缺少的地位，因为数据处理的时效性行，准确性直接影响数据的分析与挖掘，分析的最终结果影响业务的营销与收入。

一般而言，数据处理包括前期数据的规整，比如时间格式化，字段的补齐等；中期，比如为了统计出某个指标，需要多报表关联进行数据逻辑处理等，概况为两个原则分别为保证数据的完整性，准确性，即在尽量保证数据的完整性也就是不要无故的丢失底层采集的数据情况下对数据处理要保证准确性，比如你的数据里面时间是UTC时区，那你要根据你的业务判断是否需要进行时区修正，比如你的用户id原则上都是数字类型但是出现空的，那你要弄清用户id为空是什么场景下发生，数据处理应该怎么处理，是保留还是放弃等。

而现阶段的有关数据的处理，有传统的ETL工具利用多线程处理文件的方式；有写MapReduce，有利用Hive结合其自定义函数，以及最近比较热的利用Spark进行数据清洗等，可以说每种方式都有各自的使用场景。因此，我们在实际的工作中，需要根据不同的特定场景来选择数据处理方式。

下面就几种数据处理框架进行一下场景比较：

1.传统的ETL工具比如Kettle、Talend、Informatica等，可视化操作，上手比较快，但是对于数据量上升导致性能出问题，可优化的空间就不是很大了，毕竟底层人家都已经帮你封装好了.

2.写Mapreduce进行数据处理，需要利用java、python等语言进行开发调试，没有可视化操作界面来的那么方便，在性能优化方面，常见的有在做小表跟大表关联的时候，可以先把小表放到缓存中(通过调用Mapreduce的api),另外可以通过重写Combine跟Partition的接口实现，压缩从Map到reduce中间数据处理量达到提高数据处理性能。

3.Hive，在没有出现下面要说的Spark之前，Hive可谓独占鳌头，涉及离线数据的处理基本都是基于Hive来做的，早期的阿里的云梯1就是充分利用Hive的特性来进行数据处理Hive采用sql的方式底层基于Hadoop的Mapreduce计算框架进行数据处理，所以他的优化方案很多，常见的场景比如数据倾斜，当多表关联其中一个表比较小，可以采用mapjoin，或者设置set hive.groupby.skewindata=true等，当碰到数据量比较大的时候，可以考虑利用分桶，分区（分为静态分区，动态分区）进行数据重新组织存储，这样在利用数据的时候就不需要整表去扫描，比如淘宝常常对一个业务场景利用不同算法进行营销活动，每个算法的营销活动可以存放到不同的分桶中，这样统计数据的时候就会提高效率。对于hive的性能优化我后面会有一个专题进行介绍，这里只简单提一下常用的场景。

4.Spark基于内存计算的准Mapreduce，在离线数据处理中，一般使用Spark sql进行数据清洗，目标文件一般是放在hdf或者nfs上，在书写sql的时候，尽量少用distinct，group by reducebykey 等之类的算子，要防止数据倾斜。在优化方面主要涉及配置每台集群每台机器运行task的进程个数，内存使用大小，cpu使用个数等。从我个人的角度来看，我觉得spark sql跟上面所说的hive sql差不多，只不过spark sql更加倾向于内存处理。但是他不具有较强的模板话，如果修改里面逻辑要重新编译调试运行，比较适合改动比较小的业务场景，比如数据仓库

模型中ods，dwd层的数据处理。因为这两层都是宽表级别的粗处理，目的很简单旨在数据最优存储支撑上层ads层报表开发。

目前业内数据处理，阿里的Odps平台底层利用自己的一套Hadoop集群每天提供上P级的数据处理，每天有上百数据开发工程师在上面写Hive sql，当然这么庞大的数据平台维护的人员也不少，每天有工程师24小时轮流值班。Facebook目前正在进行是将Hive sql的脚本迁移到spark sql，当然这也是他们的业务发展的需求，华为目前还是在基于Hadoop集群云化ETL处理数据，其他的一些小公司或者中型公司要么买外面创业型数据公司的服务，要么自己研发了一个ETL数据处理平台。

最后通过以上个人对于目前业内数据处理这块的一些总结，我觉得不管用什么方式进行数据处理，都要严格遵守数据完整性，准确性这两个原则。

更多大数据处理平台选型探讨，欢迎点击阅读原文浏览