大数据稳定性项目规划
方案
原则
- 存算分离
- 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替代？
-
新老集群数据迁移