2017年全年回顾
本文理论上讲应当在2018年Q1的时候发出来，结果出于各种原因，推迟到了现在。个人收获
基于SpringBoot、Spring Cloud交付了多个项目，加深了对新技术的理解。
上手大数据平台，在交付项目的过程中，学习HBase、Kafka、SparkSQL的调优方法，积累了一定的运维经验。
学习架构设计的理论，在项目交付中积累经验。
学习方案分析和评估的方法，在项目中实战，进而积累经验。
通过面试官课程的学习和考试，掌握了STAR方法，作为面试官参与部门的招聘工作，在实战中积累面试工作的经验。
本年度被动转岗，进入一个全新的业务领域，在陌生的环境中，新的业务，新的角色，逐步站稳脚跟，获得周边领导和同事的认可。
全年参与的项目比较多，接触的人比较多，交流比较多，听到的新鲜事比较多，比如：
[*]常年B即精神离职。
[*]分工决定绩效。
[*]选择大于努力。
[*]人与人的差异没有那么大。
[*]绩效考评的分布比例。
大事记
软件挑战大赛
从16年底一直持续至17年中，我负责的是决赛的裁判平台。
作为主要责任人，完成需求分析、架构设计、开发工作，压力比较大。后期部门接口人看我的状态不好，增加了几个同事一起投入测试和验证工作。
在研发同事的支撑下，大赛决赛当天的裁判工作顺利完成。
但是我个人的结果不太好，辛苦了半年多，结果接口人对我的表现不满意，进而影响了上半年的绩效。
就技术而言，本项目中应用了很多比较新的技术，比如：
[*]SpringBoot
[*]SpringCloud
[*]feign
[*]zuul
[*]config
[*]zipkin
[*]admin
[*]nginx
[*]Docker
同样遇到了一些有趣的话题，比如：
[*]使用MySQL作为数据库，遇到数据目录所在分区被写满的故障，恢复的手段。
[*]使用docker封装比赛环境。
[*]wall clock的计时准确性问题。JVM由于存在GC，导致使用Java语言的选手，需要考虑额外的补偿。
[*]参赛选手使用的部分算法。
[*]蚁群算法
[*]网络流算法
[*]模拟退火算法
[*]遗传算法
这件事情耗费了很大一块精力，中间有很多故事，本来想详细记录下来，但想想事情都过去了，就算了。
部门的新项目
从17年中持续至17年的7月底。
大赛结束之后，回归部门的新业务。
有机会尝试当时比较新颖的技术，比如SpringBoot、SpringCloud、AngularJS、Docker、nginx、angularJS等。
只可惜设计团队的胃口有点大，同时外部形势不明确，导致需求、方案不太稳定。另外涉及的技术点比较多，开发团队的积累不足，从而导致加班很多，但可惜项目的结果不太好。
SDN产品
XX产品线被解散，于是在领导的运作下，我和几个同事被提前输出到SDN产品团队，期望占据好一些的位置。这个变动并不意外，在参与原部门的新业务时，周边不时传一些小道消息，只是苦于位置太低，得到的消息都是碎片化的。
既来之，则安之。
输出到新的产品团队后，面对陌生的领导、工作方式，以及全新的业务，内心充满了忐忑。
好在几个小伙伴同心协力，一起努力，完成了换岗后的第一次大考，大家都通过了考验。
很快，我接手了性能特性DE的工作，直面老大难特性的毒打。
老大难特性基于大数据平台的如下组件实现：
[*]Spark
[*]Kafka
[*]HBase
[*]Zookeeper
关键业务流程
说起来并不复杂，简单总结如下：
[*]设备端
[*]使用protobuf编码统计数据。
[*]使用统计信道上报数据。
[*]SDN服务端
[*]适配器在统计信道接收数据。
[*]适配器基于业务规则校验，重新编码后将数据写入Kafka。
[*]SDN服务端统计业务
[*]基于Spark实现的流式计算任务，提交至大数据平台运行。
[*]流式任务。
[*]从Kafka中提取数据。
[*]基于SparkSQL执行汇总统计。
[*]汇总结果写入HBase的数据表，时序表。
[*]查询服务
[*]应用服务器，按照一定条件从HBase的数据表中提取原始数据。
[*]依据业务规则加工原始数据。
[*]返回处理结果，供界面呈现。
老大难特性存在的问题
[*]统计数据的流式任务
[*]任务故障，导致跌零。
[*]统计数据不准确。
[*]可靠性不足，节点故障时可能导致任务整体挂掉。
[*]查询服务
[*]不合理的查询方式。
[*]查询超时。
[*]多用户并发查询，体验差。
[*]数据处理策略实现不正确，比如手写的排序算法，存在很多错误。
设计类的问题
[*]基于HBase表的存储
[*]Key过长。
[*]Key的设计，不满足查询要求。
[*]写入数据时，相关操作未做调优。
[*]查询服务
[*]缺少缓存层，考虑到短时间内、相同条件的查询条件，查询结果不变，相关数据如果放在缓存内，可以有效减少对HBase表的查询操作，缩短查询路径，改善操作体验。
[*]查询操作的实现不合理，未充分利用HBase的特性以及对应业务的特点。
[*]统计结果预期占用空间，不清楚。
主要的优化手段
[*]业务方案的优化。
[*]裁剪掉不必要的业务。
[*]聚焦业务，调整统计图表的呈现顺序。
[*]非关键的数据图表放到次级页面。
[*]关键的数据图表的数据，预置到缓存中。
[*]大数据组件的基本参数的优化方案。
[*]JVM的GC算法及参数。
[*]JVM的内存参数。
[*]JVM的CPU、内存资源的评估方案。
[*]Kafka
[*]topic是确定的，优化partition的数量。
[*]优化数据在partition的分布策略，改善流式任务加载数据的成本。
[*]SparkSQL的SQL优化方案。
[*]HBase的数据表占用空间的评估方案。
[*]向HBase的数据表写入数据的优化方案。
[*]界面查询体验的优化方案，包括：
[*]从HBase的数据表读出数据的优化方案。
[*]数据加工的优化方案。
主要的成果
[*]作为大数据技术的带头人，支撑开发团队定位、修复问题。
[*]作为产品的接口人，和大数据团队沟通，澄清问题，获取技术支持。
[*]支持测试团队，参与疑难问题的攻关。
[*]支撑一线团队，顺利通过客户侧的POC测试。
[*]完善特性的性能方案评估方案。
[*]作为特性的方案设计责任人
[*]看护设计方案，识别方案中存在的问题，并给出解决方案。
[*]与周边特性的设计责任人对接，及时识别方案变动点，并推动在版本中落地。
[*]支撑解决方案SE，澄清特性的各类细节问题。
[*]作为产品团队的接口人，参与B项目的交付工作，参与重要方案的讨论。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]