携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第2天，点击查看活动详情
前言
说到大数据，大家很容易联想到Hadoop。在spark诞生之前，Hadoop是用来做大数据运算最多的工具。随着spark的诞生，因其拥有速度快、语言兼容性强、通用性强等优势，spark成为了大数据运算的新宠。就在这里简单回顾一下使用spark的历程。
使用背景
当时接手的第一个项目是对电商数据清洗及相关统计。简单来说就是将业务每天的订单数据以及在线广告数据，通过设定的过滤规则清洗一版数据，最后按照不同的维度统计相关数据。
因为涉及的平台特别多，数据量也很大，当时日均订单超过6w。接手前的代码都是用pandas来处理逻辑的,跑一次全量数据需要超过1天的时间。
熟悉需求和瓶颈后，就是对于该项目的优化工作了。
pyspark初体验
鉴于当时的处理工具是pandas，因为pandas是单核计算，在大数据运算上没有优势。调研之后，因spark能够充分利用多核处理器性能、基于内存的存储、支持分布式运算等特点，我们选择了spark来优化项目。
因当时项目优化时间短，没有做充足的整改计划。将代码改成pyspark后，在单机上部署了spark（后来对spark熟悉之后发现单机版并不能充分发挥spark的作用）。
虽说spark的运用不是很得当，但最后测试之后效果却挺显著的（傻笑），全量数据运行一次时间压缩到了7小时。
pyspark优化
项目经过spark的改造，时间一下压缩了75%。但基于运行时间还是过长，所以得继续优化。通过分析sparkui上的Task，发现有一些任务消耗时间很长，造成了瓶颈。
定位到瓶颈任务的代码位置，经过分析后，我们找到瓶颈原因：
- 在处理数据时，sql使用不规范。有些spark sql在聚合之后的过滤可放在聚合之前处理的；
- 拉取的数据量过大，IO占了很长时间。
定位到原因后，首先第一点很好办，将sql优化一下就OK了。主要是第二点，因为我们的数据是存在阿里云的oss中，大量数据拉取到本地，IO难免会占用过多资源及时间。我们尝试过将服务部署在阿里云服务器，这样可以走阿里云内网，拉取速度更快。就这样优化之后，运行时间压缩到了6.5小时。
但有一个致命的问题，我们没用到spark的分布式运算特点。因此我们用3台服务器搭建了spark CDH集群，项目用上了集群之后，运算效率进一步提升，最后把运算时间优化到了不到4小时。
总结
这个项目对于spark的摸索使用，取得了相关效果。但后来对spark进行了更深层次的了解，才发现对于spark的理解和使用才不到冰山一角，spark的设计架构、使用技巧、配置要点以及调优策略，这里面都有很大的学问。只有更加熟悉它，才能更好的运用它。
后续会准备总结一下spark的相关理解和调优技巧。
