前言：很多初学的朋友对大数据挖掘第一直观的印象，都只是业务模型，以及组成模型背后的各种算法原理。往往忽视了整个业务场景建模过程中，中国直播网 ，看似最普通，却又最精髓的特征数据清洗。可谓是平平无奇，却又一掌定乾坤，中国直播网，稍有闪失，足以功亏一篑。
说明：这篇文章很早就想写了，但是切入点一直拿捏不准，要讲的内容比较大众化，却又是重中之重。
一、数据清洗的那些事
构建业务模型，在确定特征向量以后，都需要准备特征数据在线下进行训练、验证和测试。同样，部署发布离线场景模型，也需要每天定时跑P加工模型特征表。
而这一切要做的事，都离不开数据清洗，业内话来说，也就是ETL处理(抽取Extract、转换Transform、加载Load)，三大法宝。
来自于百度百科
在大数据圈里和圈外，很多朋友都整理过数据，我们这里称为清洗数据。
不管你是叱咤风云的Excel大牛，还是玩转SQL的数据库的能人，甚至是专注HQL开发ETL工程师，以及用MapReduce\Scala语言处理复杂数据的程序猿。(也许你就是小白一个)
我想说的是，解决问题的技术有高低，但是解决问题的初衷只有一个——把杂乱的数据清洗干净，让业务模型能够输入高质量的数据源。
不过，既然做的是大数据挖掘，面对的至少是G级别的数据量(包括用户基本数据、行为数据、交易数据、资金流数据以及第三方数据等等)。那么选择正确的方式来清洗特征数据就极为重要，除了让你事半功倍，还至少能够保证你在方案上是可行的。
你可别告诉我，你仍然选择用Excel，那我选择狗带。
二、大数据的必杀技
在大数据生态圈里，有着很多开源的数据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这方面，就包括执行计划、常用写法、内置函数、一些自定义函数，以及优化策略等等。
幸运的是，这方面资源在网上很全，这是一个值得欣慰的点，基本遇到的大多数问题都能够搜到满意答案。
因此，文章这个版块主要顺着这条主线来——(我在大数据挖掘实践中所做的模型特征清洗)，这样对于大数据挖掘的朋友们来说，更具有针对性。
3.1 知晓数据源
(这里不扩展数据源的抽取和行为数据的埋点)
大数据平台的数据源集中来源于三个方面，按比重大小来排序：
60%来源于关系数据库的同步迁移： 大多数公司都是采用MySQL和Oracle，就拿互联网金融平台来说，这些数据大部分是用户基本信息，交易数据以及资金数据。
30%来源于平台埋点数据的采集：渠道有PC、Wap、安卓和IOS，通过客户端产生请求，经过Netty服务器处理，再进Kafka接受数据并解码，最后到Spark Streaming划分为离线和实时清洗。
10%来源于第三方数据：做互联网金融都会整合第三方数据源，大体有工商、快消、车房、电商交易、银行、运营商等等，有些是通过正规渠道来购买(已脱敏)，大部分数据来源于黑市(未脱敏)。这个市场鱼龙混杂、臭气熏天，很多真实数据被注入了污水，在这基础上建立的模型可信度往往很差。
得数据，得天下?
3.2 业务场景模型的背景
看过我以前文章集的朋友都知道一点，我致力于做大数据产品。
在之前开发数据产品的过程中，有一次规划了一个页面——用户关系网络，底层是引用了一个组合模型。
简单来说是对用户群体细分，判断用户属于那一类别的羊毛党群体，再结合业务运营中的弹性因子去综合评估用户的风险。
截图的原型Demo
大家看到这幅图会有什么想法?
| 简单来说，原型展示的是分析两个用户之间在很多维度方面的关联度
当时这个功能在后端开发过程中对于特征数据的处理花了很多时间，有一部分是数据仓库工具HQL所不能解决的，而且还需要考虑完整页面(截图只是其中一部分)查询的响应时间，这就得预先标准化业务模型的输出结果。
我可以简单描述下需求场景：
• 拿IP地址来说，在最近30天范围内，用户使用互联网金融平台，不管是PC端，还是无线端，每个用户每个月都会产生很多IP数据集。
• 对于拥有千万级别用户量的平台，肯定会出现这样的场景——很多用户在最近一个月内都使用过相同的IP地址，而且数量有多有少。
• 对某个用户来说，他就好像是一个雪花中的焦点，他使用过的IP地址就像雪花一样围绕着他。而每个IP地址都曾被很多用户使用过。
简单来说，IP地址只是一个媒介，连接着不同用户。——你中有我，我中有你。
雪花状
有了上面的背景描述，那么就需要每个读者都去思考下这三个问题：
问题一、如何先通过某个用户最近30天的IP列表去找到使用相同IP频数最多的那一批用户列表呢?
问题二、如何结合关系网络的每个维度(IP、设备指纹、身份证、银行卡和加密隐私等等)，去挖掘与该用户关联度最高的那一批用户列表?
问题三、如何对接产品标准化模型输出，让页面查询的效应时间变得更快些?
| 思考就像吃大理核桃般，总是那么耐人寻味。
3.3 学会用Hive解决70%的数据清洗
对于70%的数据清洗都可以使用Hive来完美解决，而且网络参考资料也很全，所以大多数场景我都推荐用它来清洗。——高效、稳定
一只小蜜蜂呀，飞到花丛中
不过在使用过程中，我有两点建议送给大家，就当作鸡年礼物吧。
第一点建议：要学会顾全大局，不要急于求成，学会把复杂的查询拆开写，多考虑集群整个资源总量和并发任务数。
第二点建议：心要细，在线下做好充足的测试，确保安全性、逻辑正确和执行效率才能上线。
| 礼物也送了，继续介绍
对于上述的用户关系网络场景，这里举IP维度来实践下，如何利用Hive进行数据清洗。
下面是用户行为日志表的用户、IP地址和时间数据结构。
用户、IP和时间
回到上面的第一个思考，如何先通过某个用户最近30天的IP列表去找到使用相同IP频数最多的那一批用户列表呢?
我当时采取了两个步骤。
• 步骤一：清洗最近30天所有IP对应的用户列表，并去重用户
清洗IP对应的用户列表
这里解释三个内置函数concat_ws、collect_set和cast，先更了解必须去亲自实践：
concat_ws，它是用来分隔符字符串连接函数。
collect_set，它是用来将一列多行转换成一行多列，并去重用户。
cast，它是用来转换字段数据类型。
果然很方便吧，下面是第一个步骤的执行结果。
IP马赛克
• 步骤二：清洗用户在IP媒介下，所有关联的用户集列表
清洗用户在IP媒介下的关联用户集
最终对于IP媒介清洗的数据效果如下所示：
用户ID、IP关联的用户集
同理对于其他维度的媒介方法一样，到这一步，算是完成Hive阶段的初步清洗，是不是很高效。
最终结果的样式
但是对于分析用户细分来说，还需要借助MapReduce，或者Scala来深层次处理特征数据。
特别声明：本文为中国直播网直播号作者或机构上传并发布，仅代表该作者或机构观点，不代表中国直播网的观点或立场，中国直播网仅提供信息发布平台。
版权声明：版权归著作权人，转载仅限于传递更多信息，如来源标注错误侵害了您的权利，请来邮件通知删除，一起成长谢谢
欢迎加入：直播号，开启无限创作！一个敢纰漏真实事件，说真话的创作分享平台，一个原则：只要真实，不怕事大，有线索就报料吧！申请直播号请用电脑访问https://zbh.zhibotv.com.cn。
