大数据挖掘更多时间都在于清洗数据

一、数据清洗的那些事 构建业务模型，在确定特征向量以后，都需要准备特征数据在线下进行训练、验证和测试。同样，部署发布离线场景模型，也需要每天定时跑P加工模型特征表。 而这一切要做的事，都离不开数据清洗，业内话来说，也就是ETL处理（抽取Extract、转换Transform、加载Load），三大法宝。 很多初学者，对大数据的概念都是模糊不清的，大数据是什么，能做什么，学的时候，该按照什么线路去学习，学完往哪方面发展，想深入了解，想学习的同学欢迎加入大数据学习企鹅群：458345782，有大量干货（零基础以及进阶的经典实战）分享给大家，并且有清华大学毕业的资深大数据讲师给大家免费授课，给大家分享目前国内最完整的大数据高端实战实用学习流程体系。 来自于百度百科 在大数据圈里和圈外，很多朋友都整理过数据，我们这里称为清洗数据。 不管你是叱咤风云的Excel大牛，还是玩转SQL的数据库的能人，甚至是专注HQL开发ETL工程师，以及用MapReduce\Scala语言处理复杂数据的程序猿。（也许你就是小白一个） 我想说的是，解决问题的技术有高低，但是解决问题的初衷只有一个——把杂乱的数据清洗干净，让业务模型能够输入高质量的数据源。 不过，既然做的是大数据挖掘，面对的至少是G级别的数据量（包括用户基本数据、行为数据、交易数据、资金流数据以及第三方数据等等）。那么选择正确的方式来清洗特征数据就极为重要，除了让你事半功倍，还至少能够保证你在方案上是可行的。 二、大数据的必杀技 在大数据生态圈里，有着很多开源的数据ETL工具，每一种都私下尝尝鲜也可以。但是对于一个公司内部来说，稳定性、安全性和成本都是必须考虑的。 就拿Spark Hive和Hive来说，同样是在Yarn上来跑P，而且替换任务的执行引擎也很方便。 修改任务执行引擎 的确，Spark的大多数任务都会比MapReduce执行效率要快差不多1/3时间。但是，Spark对内存的消耗是很大的，在程序运行期间，每个节点的负载都很高，队列资源消耗很多。因此，我每次提交Spark离线模型跑任务时，都必须设置下面的参数，防止占用完集群所有资源。 spark-submit --master yarn-cluster --driver-memory 5g --executor-memory 2g --num-executors 20 其中： driver-memory是用于设置Driver进程的内存，一般不设置，或者1G。我这里调整到5G是因为RDD的数据全部拉取到Driver上进行处理，那要确保Driver的内存足够大，否则会出现OOM内存溢出。 executor-memory是用于设置每个Executor进程的内存。Executor内存的大小决定了Spark作业的性能。 num-executors是用于设置Spark作业总共要用多少个Executor进程来执行。这个参数如果不设置，默认启动少量的Executor进程，会很大程度影响任务执行效率。 单独的提交Spark任务，优化参数还可以解决大部分运行问题。但是完全替换每天跑P加工报表的执行引擎，从MapReduce到Spark，总会遇到不少意想不到的问题。对于一个大数据部门而言，另可效率有所延迟，但是数据稳定性是重中之重。 Spark运行Stage 所以，大部分数据处理，甚至是业务场景模型每天的数据清洗加工，都会优先考虑Hive基于MapRedcue的执行引擎，少部分会单独使用编写MapReduce、Spark程序来进行复杂处理。 三、实践中的数据清洗 这节要介绍的内容其实很多，单独对于Hive这方面，就包括执行计划、常用写法、内置函数、一些自定义函数，以及优化策略等等。 幸运的是，这方面资源在网上很全，这是一个值得欣慰的点，基本遇到的大多数问题都能够搜到满意答案。 因此，文章这个版块主要顺着这条主线来——&#