大数据稳定性项目规划
方案
原则
- 存算分离
- cos
- emr
- 弹性扩缩
- DLC(临时查询或者特殊查询,待定)
- 数据ETL
- cls
- 采集
- 加工
- cls
风险
TKE日志采集
-
支持黑名单逻辑,预计6月份之前完成
-
支持暂停采集(topic粒度),预计6月份之前完成
数据加工
- IP 地理函数功能支持,预计4月30号完成
- 数据加工解析能力,现有号码等日志解析逻辑是否能完全采用数据加工(如:json函数包含特殊字符\n,cls解析存在异常)
- 数组json平铺,预计4月30号完成。
- 体验:invate date 界面显示问题,预计5月底完成优化。
- 数据加工成本
投递COS
- 支持256MB 已经支持
- 支持转换parquet数据格式,预计4月30号完成
EMR
cos读性能
对比本地盘问题
- 腾讯基准20%
- 测试30%~40%
解决方案
- 融合cos(元数据加速)
- 元数据加速功能是由腾讯云对象存储(Cloud Object Storage,COS)服务提供的高性能文件系统功能。元数据加速功能底层采用了云 HDFS 卓越的元数据管理功能,支持用户通过文件系统语义访问对象存储服务,系统设计指标可以达到2.4Gb/s带宽、10万级 QPS 以及 ms 级延迟。存储桶在开启元数据加速功能后,可以广泛应用于大数据、高性能计算、机器学习、AI 等场景
- 扩task节点
- 调整spark/hive执行参数
存在问题
- 融合cos后续收费问题
- 测试结论不充分(COS节点带宽等是否考虑全面)
旧集群上直接实施
- 优点
- 成本小
- 只需改动解析任务,其他任务不需变动
- 缺点
- 稳定性差,因为在集群直接操作易出问题
- cls方案落地后,需要替换集群core节点
- 直接在旧集群调整集群参数,影响线上稳定性
- 在旧集群也需并行测试,旧集群现有资源只能满足线上任务,如需新加测试任务,需额外添加资源,且与线上任务不是完全物理隔离,可能影响线上
- 在旧集群上,改造后整体资源相比之前的使用情况,无法精准评估
新建集群实施
-
优点
- 稳定性高, 不影响旧集群任务运行
- 可选:可采用新版emr, 可能有性能和易用性提升
- 可对集群现有任务进行梳理,重点针对重复计算部分,构建可多次复用的中间数据,在新集群实施
- 可针对号码表,重新设计表结构,只保留必需字段,或新增分区字段或设计倾斜表来提高查询效率
- 新集群购买新机型,规避部分旧机型引起的问题
-
缺点
- 成本在双集群共存时较高
- 搭建新集群以及配置调整有人力和时间成本
- 最终保留新集群后,原旧集群任务都需要迁移到新集群
- 在迁移和尝试阶段, 需在新旧集群间移动数据
- 如果改变数据结构,新旧数仓能否完全兼容
新集群方案实施步骤及问题
1 组件
- 集群必须组件: zk, hdfs, yarn, hive, knox, hue, spark, sqoop, tez, ranger
- 自维护组件: azkaban, metabase
- 可考虑和尝试新版本emr
2 集群配置
- 和旧集群总cpu和内存相同,磁盘可以相对应减少,只保留足够的shuff所需的hdfs容量。
- 考虑到COS性能降低,为保持任务和之前执行时间相对一致,新集群资源需要视情况增加
3 实施步骤
- 根据旧集群规模新建集群, 自搭建azkaban和metabase服务, 并根据旧集群调整新集群参数
- 先测试cls采集解析日志到cos走通
- 分别迁移号码,jump, dot等重要日志, 通过cls方式实现
- 将相关重要日志计算任务迁移到新集群,同时在旧集群停止(旧集群可以根据情况缩容)
- 旧集群迁移
- 腾讯新旧集群迁移,可与腾讯确认是否有迁移工具,尽可能降低迁移成本
- 新旧集群都会存在的问题:不管在旧集群改还是新集群改,风险都有。旧集群改直接影响线上,风险立刻可以暴露。即使并行一段时间相对稳定,无法确保是否会和之前阿里迁移腾讯一样,很多问题后期才会暴露出来
目标
任务
num/jump/u3/dot
时间节点
5月中下旬
完整并行时间
1周~2周
Milestone
-
Emr集群搭建
-
CLS
- 数据加工
- parquet
- 鲁棒性
-
号码
- 字段梳理并重新定义
- 任务梳理并重新设计
- 数据ETL
- 数仓建设
- partition划分
- 相关生产DWS、DWD任务存在一个流中
- 任务监控
- 任务性能优化
- oppo log改造
-
dot
- 业务代码改造
- 数仓建设
- 任务监控
- 任务性能优化
-
jump
- 数仓建设
- 任务梳理
- 任务监控
- 任务性能优化
-
u3
- cos桶设计
- 停掉或者原始json替代?
-
新老集群数据迁移