2017年全年回顾

本文理论上讲应当在2018年Q1的时候发出来,结果出于各种原因,推迟到了现在。


个人收获

基于SpringBootSpring Cloud交付了多个项目,加深了对新技术的理解。
上手大数据平台,在交付项目的过程中,学习HBaseKafkaSparkSQL的调优方法,积累了一定的运维经验。
学习架构设计的理论,在项目交付中积累经验。
学习方案分析和评估的方法,在项目中实战,进而积累经验。
通过面试官课程的学习和考试,掌握了STAR方法,作为面试官参与部门的招聘工作,在实战中积累面试工作的经验。
本年度被动转岗,进入一个全新的业务领域,在陌生的环境中,新的业务,新的角色,逐步站稳脚跟,获得周边领导和同事的认可。

全年参与的项目比较多,接触的人比较多,交流比较多,听到的新鲜事比较多,比如:

  • 常年B即精神离职。
  • 分工决定绩效。
  • 选择大于努力。
  • 人与人的差异没有那么大。
  • 绩效考评的分布比例。

大事记

软件挑战大赛

从16年底一直持续至17年中,我负责的是决赛的裁判平台。
作为主要责任人,完成需求分析、架构设计、开发工作,压力比较大。后期部门接口人看我的状态不好,增加了几个同事一起投入测试和验证工作。
在研发同事的支撑下,大赛决赛当天的裁判工作顺利完成。
但是我个人的结果不太好,辛苦了半年多,结果接口人对我的表现不满意,进而影响了上半年的绩效。

就技术而言,本项目中应用了很多比较新的技术,比如:

  • SpringBoot
  • SpringCloud
    • feign
    • zuul
    • config
    • zipkin
    • admin
  • nginx
  • Docker

同样遇到了一些有趣的话题,比如:

  • 使用MySQL作为数据库,遇到数据目录所在分区被写满的故障,恢复的手段。
  • 使用docker封装比赛环境。
  • wall clock的计时准确性问题。JVM由于存在GC,导致使用Java语言的选手,需要考虑额外的补偿。
  • 参赛选手使用的部分算法。
    • 蚁群算法
    • 网络流算法
    • 模拟退火算法
    • 遗传算法

这件事情耗费了很大一块精力,中间有很多故事,本来想详细记录下来,但想想事情都过去了,就算了。

部门的新项目

从17年中持续至17年的7月底。
大赛结束之后,回归部门的新业务。
有机会尝试当时比较新颖的技术,比如SpringBootSpringCloudAngularJSDockernginxangularJS等。
只可惜设计团队的胃口有点大,同时外部形势不明确,导致需求、方案不太稳定。另外涉及的技术点比较多,开发团队的积累不足,从而导致加班很多,但可惜项目的结果不太好。

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的分布策略,改善流式任务加载数据的成本。
  • SparkSQLSQL优化方案。
  • HBase的数据表占用空间的评估方案。
  • HBase的数据表写入数据的优化方案。
  • 界面查询体验的优化方案,包括:
    • HBase的数据表读出数据的优化方案。
    • 数据加工的优化方案。

主要的成果

  • 作为大数据技术的带头人,支撑开发团队定位、修复问题。
  • 作为产品的接口人,和大数据团队沟通,澄清问题,获取技术支持。
  • 支持测试团队,参与疑难问题的攻关。
  • 支撑一线团队,顺利通过客户侧的POC测试。
  • 完善特性的性能方案评估方案。
  • 作为特性的方案设计责任人
    • 看护设计方案,识别方案中存在的问题,并给出解决方案。
    • 与周边特性的设计责任人对接,及时识别方案变动点,并推动在版本中落地。
    • 支撑解决方案SE,澄清特性的各类细节问题。
  • 作为产品团队的接口人,参与B项目的交付工作,参与重要方案的讨论。

热门相关:娇妻如云   玉堂金闺   北宋闲王   神秘老公,晚上见!   重开地狱