大数据稳定性复盘
目标回顾
Why
EMR成本
稳定性
复杂度
数据流转详情:
What
方案1
优点
- 业务代码无需改动
- 云厂商服务能满足80~90%以上需求
- cls作为关键链路,能备份原始日志、对数据进行加工、转换成parquet写入cos
缺点
-
对腾讯云组件依赖,对跨云迁移可能存在问题(阿里云有类似能力)
-
转换parquet需要4月低上线
方案2
优点
- 简化数据采集流程(业务方可直接在业务代码或者消费kafka方式对数据进行做ETL处理)
- 大数据不用关心数据ETL
缺点
- 需要业务做ETL处理
- 对腾讯云组件依赖,对跨云迁移可能存在问题
- 原始日志备份需要业务采用CLS方案或者自身工具
Who
- 大数据团队
- 业务方
- 运维
When
Deadline
6.9 缩减旧集群/迁移号码
实际
6.30 jump/dot/num等任务迁移至新集群
7.14 旧集群释放
How
总结结果
分析原因
为什么项目延期
- 安排过多时间处理集群参数调优
- 数据验证方案计划不够,时间点安排太偏后、验证方法太依赖大数据
- 腾讯云数据加工能力不完善、写parquet存在问题、数据采集单线程导致数据量偏少
- 疫情导致在家办工
为什么放弃DLC
- 团队成员意愿不够
- DLC组件欠缺、不好用
- 需要维护emr集群和dlc,表数据需要创建2份
为什么集群可维护性低于预期
- 腾讯云集群版本不完善、需要替换必要jar
- azkaban需要自己维护、管理
- 集群参数并不是最优,需要做一些调整
为什么集群成本不能缩减5W
-
5W目标制定是拍脑袋
-
emr集群master、common规格以及机型最次购买太高
-
emr集群3台router节点资源太浪费
-
cos存储偏高
为什么集群成本能下降
- 任务缩减占主要原因
- 大数据需求降低
- 集群足够简单、现阶段运行方案并不一定是最优方案
- 任务队列(单队列)