开篇

缘由

工作2年多了, 由于一直忙于工作, 基本也就是看看别人写的技术文章, 没有进行过知识的输出, 近期反思了一下自己, 工作上做的大部分内容都是跟业务相关的, 目前的状态在外人看起来都是比较忙碌的, 但是实际上呢, 自己实际得到的提升并不是很明显, 起码是自己不太满意的程度. 乘着近期任务比较少, 思考问题的时间比较多, 其中有一个问题是是如何尽可能高效地提升自己, 突然想到自己的之前大学期间坚持写的博客也接近2年没更新了, 之前写博客的时候状态不错, 写得也是杂七杂八的, 看的人可能不多, 但是在这过程中有对自己进行总结, 在那段时间学到的东西也是蛮多的. 何不重新开始写博客呢?

其实这两年多也有很多次想重新写博客的想法, 但是只是闪念而已, 没有强烈的冲动, 可能是刚开始做的事情比较杂, web业务后端, 没有可以成体系分享的东西. 最近一年的时间基本都在基于Spark开发应用, 相对比较聚焦, 在这过程中, 同时对大数据领域的东西有了一定了解, 自己也对这方面的兴趣比较浓厚. 说实话, 大数据领域整个体系还是很大的, 而且更新特别频繁,有脑子不够用的感觉,而且现在的公司大数据相关的机器加起来也就400多台物理机,规模说不上大 但是大数据的整套技术体系还是由一个大牛(Hadoop社区committer)规划的, 加上公司分工也比较明确, 集群运维 平台开发 应用开发是分开的, 在一个方面专注了, 难免会一叶障目.

拿这一年做的开发的针对大规模机器学习的特征处理系统来说, 目前处理的样本量在数十亿, 特征在数亿维, 我只能从公开渠道了解百度和google的的特征规模在百亿和千亿左右, 众所周知, 对外宣传一般会夸张一下, 但是实际情况是怎样呢?

在做Spark应用的开发过程中, 为了满足处理业务要求的数据规模, 在提高应用灵活性的基础上又能保持性能, 基本上侧重做的点也是根据业务的理解做业务流程上的优化 使用姿势的调整 还有就是应用一些数据结构还尽可能地压榨单机性能和针对场景做取舍进行优化.对内部的一些实现了解偏少.

毕业后也只在一家公司呆过, 其他同行公司的大数据体系是怎样的呢? 也是一无所知的, 由于没有很好的渠道去了解, 一般也就是看看网上发的文档, 美团关于这方面的分享还是很多的, 在此顺便感谢美团的技术博客, 虽然有小道消息说有些文章是产品经理写的, 内部也不一定是已经实现的,(美团的同学看到之后不知道会怎样),但是对于我了解一些技术和业务发展方向还是提供了很大的帮助.

Action

针对以上问题, 多找渠道了解, 那我感觉技术博客应该是很合适的, 把我遇到的问题抛出来,解决的或者没解决的, 引发讨论的同时, 也能给自己带来新的思路. 顺便交个朋友, 互相八卦分享下内部消息也是不错的.

那么主要侧重什么主题合适呢, 在工作中, 由于平台的推广和大家的一心学习大数据的热情, 我发现身边的小伙伴的系统都逐渐使用Spark来完成计算的任务. 但是呢, 我看他们使用的时候, 使用姿势千奇百怪, 而且很多high-level api 几行代码搞定的事情, 还自己用RDD去实现, 最后还遇到了一些性能上的问题. 在学习spark的时候, 看的第一本书是Spark快速大数据分析,大部分篇幅还是介绍RDD的, 第九章10多页介绍了Spark sql, 于是我在开发系统前开始调研了一把, high-level api既简洁, 性能又好, 而且目前整个社区都在针对这一块去优化, 为何不用呢? 整个系统绝大部分代码都是基于high-level api去实现, 当然有些点由于high-level api没有对应的实现, 只能用RDD去实现了, 一轮使用下来, 对api还是比较熟练的.

出于一些原因的考虑, 我当时使用的Java来实现整个工程的, 至于为啥这样选择,后面的文章我会说明. 我希望是把我在实际过程中使用的一些经验, 包括工程结构, 部署方式, 和其他程序的配合, 使用姿势, 踩过的坑, 从整个大的工程里面拆成小的点整理出来,另外把一些解决问题的工具单独提供出来,做成Cookbook的方式, 直接可用这类工具解决问题, 由于使用的环境差异性比较大, 经过和大家的不断讨论和调整, 最终目标能整理出Spark的最佳实践, 就像springside对于spring地位一样.

短期目标

立个flag, 在接下来的半年能保证每周一更, 不管点的大小, 持续输出更重要.

长期目标

持续输入和输出大数据领域的技术. 顺便解释下organization的名字的来头, spark + storm 在实时和离线领域各有专长, 现在来看虽然不是最佳组合, 但是取名的是时候为了好听点, 显得厉害点, 中文名好取点, 当时就想了这个.闪电暴风雨是不是特别霸气.