ToB企服应用市场:ToB评测及商务社交产业平台
标题:
2017年全年回顾
[打印本页]
作者:
钜形不锈钢水箱
时间:
2024-5-6 05:47
标题:
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项目的交付工作,参与重要方案的讨论。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)
Powered by Discuz! X3.4