大数据开发中遇到的鬼魅魍魉，清除30%以上经验总结

大数据开发中遇到的鬼魅魍魉，清除30%以上经验总结@TOC

导语

一部分工作原因，一部分觉得收益低， 没怎么写博客。在做大数据的一些事情，与其是做事，不如是找虐。大数据这些开源组件与工具，看上去很美好，实际问题多多，受虐多多。趁着最近对自己做了点思考，写点总结。内容还没想好，后续再添。

窘境

你遇到一个问题，然后花了一天时间，甚至通宵，找到这个bug的原因，然后又花了半天时间，解决这个bug。问题是解决了，但是，值得吗？
你的1.5天生命==1个bug。
现代社会，对程序员要求极为苛刻。不能有伤残，少一根手指，别人敲2行代码了，你才敲一行；近视高一些，就会容易刮花显示器，损害公司财产。
肉体，真的只是肉体。

武器

装备

boss

小鬼

俗说“小鬼缠身”，组件、代码依赖也一样。“依赖缠身”让人烦不胜烦。
优化思路：

山鬼

大数据组件多，每个组件又有各自的运行环境、参数搭配、资源限制，能力特长。其中，配置参数优化是典型问题。有时，搞定这个组件，另一个组件又衔接不上。犹如一个一个的拦路鬼。不用想了，此鬼一定会遇到。
优化思路：
使用OptDev开发模式。环境、代码、配置、数据分离而独立。用ansiable工具管理环境软件（比如jdk、kafka）安装脚本。用maven+svn（git）+jenkins工具管理代码。用apollo工具管理配置。数据也做开发、测试，生产等不同版本的切换。

音狱鬼

此鬼似乎很可爱，很美好。比如，远观大数据，可实现N备的性能提高，N倍的数据处理能力，N倍的计算能力，N倍的潜在价值！但实际上，向领导要资源，要硬件，没硬件；要数据，没数据；要时间，没时间；要人，没人。

毒鬼

开发中，经常遇到很毒的实现机制和复杂的代码。比如说，spark，计算能力很强，可内部实现，概念新奇，复杂困难，盘根错节。
这种情况，能看懂代码执行流程就不错了。但对于不是太复杂的功能的调试和诊断，有一些优化思路可供参考。
优化思路：
代码开发和调用规范：

代码诊断：

红邪鬼

此鬼邪门。往往单机环境没问题，一到分布式环境，就瘫了。

蛊之鬼

蛊不仅毒，而且四不像，给人一团乱麻。特指在复杂的环境，写复杂的代码，有调用组件本身的代码，有多线程，IO，权限等，牵涉广。实现的时候内心焦躁，测试的时候内心不安，遇到疑难杂症，内心惶恐。
通常有3种情况：
（1）功能代码有了积累，做的版本多了。再回头去改里面的某些东西，头皮发麻。
（2）功能本身复杂，牵涉的技术点广。不仅实现费劲，测试也费劲。
（3）需求改来改去。在已实现的代码上改来改去。
以上每样，在大数据开发这块，难度均加成30%。

炼狱鬼

大数据仅仅依靠一两个组件，能实现的功能有限，往往会有多个组件衔接搭配。因此，大数据开发具有流程性的特征，上下前后关系依赖性较强。然而，弊端很明显，中间有一个不行，整个链子就串不起来，容易掉链子。一旦深陷其中，犹如炼狱。

鬼城主

改一次，重启一次，看效果，反复…犹如在鬼城打转，绝望溢于言表。

宝仙鬼

问题重现。问题如何重现，这是个经典问题。如果问题得以重现，那之前的迷惘扫清大半，简直比捡到钱还开心。

宝塔巨鬼

死神鬼

此鬼属于三不知领域。一知半解没有用；熟悉并精通没有用；必须得完全掌握可控才行。比如spark，笔者就觉得很难。在用spark做复杂的应用的时候，各种鸡毛乱舞是少不了的。遇到这种，好吧，直接躺平。