初识Spark

参考Spark高级数据分析和快速大数据分析两本书的内容结合自己的想法和应用。

不定期更新。每周二。

——－——－——－——－——－——－——－——－——－——－——－——－——－——－——－——－——－——－——－

Spark的大名在2018年应当是早已响彻天下。原本只是hadoop生态圈的组件，单因为一个RDD的速度远超mapreduce

就可以获得现在的成功。（毫无疑问现在是成功的开源软件，不由得使我对kudu的应用有了一定的期待）。

 Spark继承了MR的线性扩展型和容错性。执行的事有向无环图算子（DAG），作为图论的一部分我觉得有必要好好去研究，毕竟社交网络的发达促使我们更加关心一件事情时的关联多方因素。完全可以通过基础的图论从生活中映射到数学里。

Spark主要更改的内容是将中间结果直接传到流水作业的下一步。可以理解成从a地到b地平常可能需要换3班公交，每次都需要上下车，但是现在做了spark的线路，我们可以不用下车，直接无缝对接，尽管走的路线还是一样的。

这就非常适合我们需要大量迭代的计算内容，我只需要输入一次全量数据，每次迭代结果直接作为下次的初始数据、在机器学习的迭代中可以直接无脑应用。

书中代言：Spark契合了数据科学领域的硬道理，它认识到构建数据应用的最大瓶颈不是CPU、磁盘或者网络，而是分析人员本身的生产率。

总结一下我们在微粒贷项目里的实战经验：在数据处理和ETL的过程中我们花了超过三分之二的时间在数据预处理。

初始数据都是混乱而且无序的，这样的数据不能称之为数据资产。如何给出清晰的逻辑回路是我们建立数据仓库的中间层、应用层之初就应当考虑到的。（仅仅包含数据字典是完全不够的！）

既然扯到微粒贷，我就多记录一点心路历程。这个微众的确是给了我们不少数据，但是我们在入原始数仓的时候就没剩多少字段了。而且经历了原始数据仓库的建模逻辑，将对应数据分散落到3个主题的20多张表里。很大一部分是拉链表。这给我们的数据预处理带来了非常大的难度。

此前我们对微粒贷没有任何了解，但是经过一轮建模加上二轮数据整理后，我们得到了以下几个结论：

1、我行微粒贷相关数据从15年9月开始  直至16年4月才开始第一次入仓。后续9月份又一次大更新屏蔽了对应手机号 

＊＊＊1234*＊＊＊

2、微粒贷都是分期有可能是1、5、10、20.这一点我们也得到了验证，其中1指就是当时就提前还款了。

3、微粒贷的逾期情况预测分析是我们本次建模的主要目标：为此我们计划是采用贷前数据和贷中数据两类书籍来预测一笔微粒贷的逾期情况。

在贷前方面，我们拥有的数据资产只有此用户的申请信息，然而微信拥有它的相关多渠道信息。（包括蚂蚁也会）所以他们能很好的做贷前客户的筛选和额度定价。

仅基于不完全的贷前信息，我们更应当去研究的是为什么给他们放贷以及对应额度不同。

对于贷中数据、已发生还款的信息，银行会更加明白类似用户的还款情况以及对应可能的逾期情况。但是微信有此人的各种社交行为信息。能更明确什么样的人容易逾期。银行最好还是用什么样的贷款方式、贷款情况容易逾期比较合理可行。

总而言之 二轮建模的主要任务就是基于还款情况来判断一笔借据的逾期情况，想通了这一点，围绕这一点去整理数据对我们会有很大的帮助。

继续回到Spark的使用上来。在微粒贷建模中Spark占据的地位仅次于Yarn，毕竟人家是调度工具。遇到的问题也列在下面：

1、我们跑spark因为是parquet文件所以设计到解压再压缩，这个中间结果就会很大而且很蠢，需要吃更多资源跑的还慢。

2、有一部分内容我们没用 就是pyspark 因为本身对spark了解较少，我们需要在后面多学习相关scala语言的内容，同时每天去学习环境操作一波。

3、书中说的比较严重的问题：看似合理的数据得到看似合理的答案，但其中的确存在巨大问题。

学习spark和scala的目的在于使用它们进行数据分析和数据建模操作。数据建模的模型本身而言是有好与坏之分而没有对与错之分。所以一点疏忽都会影响到整个模型的合理性和可解释性。

下集预告：如何使用scala和spark进行数据分析