Spark是一个分布式计算平台，所谓的分布式，指的是计算节点之间不共享内存，需要通过网络通信的方式交换数据。Spark最典型的应用方式就是建立在大良廉价的计算节点上，这些节点可以是廉价主机，也可以是虚拟的docker container.
从下面的Spark架构图中我们可以看到Spark程序是由Manager node(管理节点)进行调度组织，由worker node（工作节点）进行具体的计算任务执行，最终将结果返回给Drive Program（驱动程序）。在物理的worker node上，数据还会分为不同的partition(数据分片)，可以说partition是Spark的基础数据单元。
在执行一个具体任务的时候，Spark是怎么协同这么多的工作节点，通过并行计算得出最终的结果呢？下面通过一个任务来解释一下Spark的工作过程。
这个任务并不复杂，我们需要先从本地硬盘读取文件textFile, 再从分布式文件系统HDFS读取文件hadoopfile, 然后分别对他们进行处理，再把两个文件按照ID都join起来得到最终的结果。
在Spark平台上处理这个任务的时候，它会将这个任务拆解成一个子任务DAG(Directed Acyclic Graph,有向无环图)， 再根据DAG决定程序各步执行的方法。从下图可以看到，Spark程序分别从textFile和hadoopfile读取文件，再经过一系列map, filter等操作后进行join,最终得到了处理结果。
这里的shuffle指的是所有partition的数据必须进行洗牌后才能得到下一步的数据，最典型的操作就是上图中的groupByKey操作和join操作。以join操作为例，我们必须对textFile数据和hadoopFile数据做全量的匹配才可以得到 join后的dataframe(spark保存数据的结构)。而groupByKey操作则需要对数据中所有相同的key进行合并，也需要全局的shuffle才能完成。
与之相比，map、filter等操作仅需要逐条地进行数据处理和转换，不需要进行数据间的操作，因此各partition之间可以完全并行处理。
此外，在得到最终的计算结果之前，程序需要进行reduce的操作，从各partition上汇总统计结果，随着partition的数量逐渐减少，reduce操作的并行程度逐渐降低，直到将最终的计算结果汇总到master节点（主节点）上，可以说，shuffle和reduce操作的触发决定了纯并行处理阶段的边界。
总结Spark计算过程：Stage内部数据高效并行计算，Stage边界处进行消耗资源的shuffle操作或者最终的reduce操作。
-
如何利用one-hot编码处理类别特征
广义上将，所有的特征都可以分为两大类，第一类是类别、ID型特征.比如电影风格、ID、标签、导演演员等信息，用户看过的电影ID、用户性别、地理位置信息、当前季节、时间、天气等，这些无法用数字表示的信息全部都可以被看做是类别特征。第二类是数值型特征，简单来说，就是能用数字直接表示的特征就是数值型特征，典型的包括用户的年龄、收入、电影播放时长、点击量、点击率等。
我们进行特征处理的目的，是把所有的特征全部转换成一个数值型的特征向量，对于数值型的特征，这个过程非常简单，直接把这个数值放到特征向量上相应的维度上就可以了，但是对于类别ID类型特征，如何处理呢？
one-hot编码，这是将类别、ID特征转成数值向量的一种最典型的编码方式。 -
数值特征处理 – 归一化和分桶
主要讨论两方面问题：一是特征的尺度，二是特征的分布。
特征的尺度问题不难理解，比如在电影推荐中有两个特征，一个是电影的评价次数fr, 一个是电影的平均评分fs. 评价次数其实是一个数值无上限的特征，电影平均评分，因为一般采用5分为满分，所以特征fs取值范围是【0-5】之间。由于fr和fs两个特征的尺度差距太大，如果我们把特征的原始数值直接输入推荐模型，就会导致这两个特征对模型的影响程度有显著区别，如果模型中未做特殊处理的话，fr这个特征由于波动范围高出fs几个量级，可能会完全掩盖fs的作用，这个当然是我们不愿意看到的。为此，我们希望把这两个特征尺度拉平到一个区域内，通常是【0,1】范围，这个就是所谓的归一化。
归一化虽然能够解决特征取值范围不统一的问题，但是无法改变特征值的分布，比如人们对电影的打分评价有“中庸偏上”的倾向，因此评分大量会集中在3.5附近，而且越靠近3.5密度越大。这对于模型学习来说也不是一个好现象，因为特征区分度并不高。
这该怎么办呢？我们经常会用分桶的方式来解决特征分布极其不均匀的问题。所谓“分桶”，就是将样本按照某特征的值从高到低排序，然后按照桶的数量找到分位数，将样本分到各自的桶中，再用桶ID作为特征值。
在SparkMLib中，分别提供了两个转换器MinMaxScaler和Quantilediscretizer，来进行归一化和分桶的特征处理。他们的使用方法和之前介绍的OneHotEncoderEstimator一样，都是先用fit函数进行数据预处理，再用transformer函数完成特征转换。
当然对于数值型的特征处理方法远不止此，在经典的youtube深度推荐模型中，我们就可以看到一些很有意思的处理方法，比如，在处理观看时间（time since last watch）和视频曝光量(# prevIoUs impresions)这两个特征时， youtube模型对他们进行归一化后，又将他们各自处理成了三个特征 分别是 原始值x, 特征值的平方x^2, 以及特征值得开放，这是为什么呢？
无论是平方还是开方操作，改变的还是这个特征值的分布，这些操作与分桶操作一样，都是希望通过改变特征的分布，让模型能够更好地学习到特征内包含的有价值的信息。但由于我们没法通过人工的经验判断哪种特征处理方式更好，所以索性把他们都输入模型，让模型来做选择。
所以，我们进行特征处理的一个原则，就是特征处理并没有标准答案，不存在一种特征处理方式一定好于另外一个钟。实践中要多尝试一些，找到最能提升模型效果的一种或者一组处理方式。
总结：
类别型特征处理：one-hot编码，multi-hot编码。
数值型特征处理：归一化、分桶、及其他改变特征值分布的处理方式
特征处理的原则：特征处理没有标准答案，需要根据模型效果实践出真知。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
