3. 如何思考回答

这个问题想要回答好，一定不能只是简单说下问题的表面特征，然后再匆匆给个解决这个问题的办法就敷衍了事。

面试官真正想听的是你的思考路径，和支撑这个思考背后的逻辑，下面就根据上面的几个问题，来谈谈我的思考路径：

3.1 架构设计问题的优化

所有技术架构设计的初衷都是为了解决实际业务问题，不是玩花拳绣腿，其实一个技术架构设计的好坏，开发人员是能明显感知的，因为这个跟你的系统运行效率、稳定性、后期维护成本息息相关，比如对于数据接入模块，对于同一种类型的数据，用一个数据接入组件足够，用了Sqoop，就尽量别去用dataX，用了Filebeat，就别用flume、logstash等等，尽量把一个工具能够覆盖的功能用全，用深入。

一来可以增加对单个技术的理解深度，二来可以减少开发人员的工作量，三来还可以增强系统稳定性、可维护性，砍掉过多的中间环节。

所以你可以这么回答：技术架构设计的核心一定是遵从满足需求原则和简单原则，其次考虑扩展性。那么对于一些明显拖垮效率，以及给系统增加复杂度和稳定性的冗余设计，就可以考虑砍掉。

比如我看很多小项目中，明明数据量不大，用一个普通数据库，通过合理的表设计以及索引设计，就可以搞定数据查询效率的问题，非得学人家在数据库和服务端加一层缓存，结果效率没见快多少，反而引来很多数据不一致的新问题，把开发人员搞的痛苦不堪。

那么如果是你，是不是可以考虑从哪些技术维度去优化和解决呢？

3.2 需求设计问题的优化

比如一个很常见的数据处理场景，每次数据处理时需要对当前的数据做是否存在的判断，也就是当前数据如果之前处理过了就不再处理，这个时候很多的设计一般都是做【全量比对】，也就是直接查看当前这条数据在之前的处理记录中有没有，如果有，不处理，如果没有，新写入。

但是这样做最大的一个问题是对数据库系统有很大的【侵入性】，因为你需要频繁的查询，如果数据量巨大，那么对数据库系统会造成不小的访问压力，所以需要你优化。

一种优化就是，把比对剥离出来放到一个第3方的位置，比如Redis，这样原本数据库的压力就小了，但是你要知道这么做，随着数据处理量的增大，Redis的数据压力也会越来越大。

那么为了进一步减少Redis的压力，就需要根据当前的业务特点进一步优化，因为当前的业务要求只要判断数据是否存在就可以，不要做那种一一比对，那么完全可以利用Redis的BitMap特性，这样可以大大减少Redis的存储压力，虽然Bitmap存在一定的误判：如果没有则证明一定没有，但如果有也可能没有。

但是没有关系，误判的那部分完全可以再到数据库查一次就好了，这样对数据库的侵入性就大大减轻。

3.3 数据处理效率优化

这个应该是开发人员遇到最多的问题了，比如对一份数据的处理复杂度过高，明明可以放到一个HashSet中的数据集，却放到了Array中，把时间复杂度可以为O(1)的逻辑，写成了时间复杂度为O(N)。

比如数据处理过程中，明明可以一步到位的，却加入了很多无谓的中间步骤，让数据落盘，增加多余的IO操作，或者明明可以设计一张带索引的表(比如ES、MySQL)，来提高查询效率，但是却偏偏让数据写入到弱索引的表中（比如hive）。

再比如，很多数据处理步骤完全可以在计算引擎端完成，结果全部给写到了数据库中，然后在查询阶段，通过复杂的SQL语句来完成本可以前置的数据处理步骤，降低了查询性能。

如果是你，你该如何优化？

3.4 针对难点问题

对于一个有些经验的开发来说，其实这种【棘手问题】时不时就会碰到的，有些人经历过了就过了，没有去好好思考和包装，以至于在回答这样的问题时并不出彩。

比如上面提到的软件工程中的jar包冲突问题，有的候选人可能一句话就说完了，而有些聪明的候选人则可以把这个问题进行展开(具体可参考文章：一次硬核的项目jar包冲突实战)，这样面试官会认为：这个问题你确实会。

再比如说程序OOM，OOM有很多种，有些OOM纯粹只需要你在运行时增加点内存就够了，但是你要这么回答，会显得你特别【寒酸】，面试官心想：就这？也值得拿出来说的吗？

而如果问题变成，即便加内存了也依然会出现OOM，那么问题就变得不一样了，这个时候大概率是内存泄露导致，那正确的玩法就是把这个程序的JVM中的各种堆栈对象给dump出来，看看哪些对象在不断的生成，而没有被GC掉。

而这个也一定是因为你代码写有问题导致的，比如把不断增长的数据放到静态成员变量中，会导致这个对象一直膨胀，且不会被回收，那么内存爆掉是早晚的事情，你再结合下原因给面试官一顿侃，能够做到知其然且知其所以然，这么这道题应该就不会有什么问题。

再说兼容性问题，在一个大数据项目中，那么多组件一起配合工作，不同的组件又是不同团队的人开发的，那么不兼容是件很正常的事情，所谓不兼容一般要么不能直接通信，要么就是数据在两个软件之间无法直接互通，我的你不认识，你的我不认识。

找到问题核心，如果是通信问题，那就看他们的通信协议兼不兼容，如果通信协议兼容，那就看其通信使用的框架版本是否一致，比如几年前，我升级spark + Elasticsearch的组合时，当时把Elasticsearch从2.x升级到6.x，结果直接玩不转了。

后面各种尝试，最后发现是Elasticsearch升级后，原本的spark所用的netty版本过低导致，但是程序根本没有一点提示，只是告诉你连接超时，具体原因你得自己去定位，所以当时排除各方面原因后，断定原因出在通信上，最后定位这个问题，升级netty解决的。

再比如数据不兼容问题，比如spark跟hive的兼容问题，之前文章有讲(spark2 + hive3遇到的坑)，感兴趣的同学可以去看看，完全可以作为你的案例拿出去说，但前提是你真的理解了。

|最后

看到这，可能有些小伙伴会失望，说：这也没告诉我答案啊。

确实，像这样的问题，我给不了答案，也没那个水平，只能说给你提供些个问题回答的思路，至于具体如何组织语言，优化细节，依然需要你的思考。

因为只有你自己的回答，才是这个问题的最佳答案。