项目回顾
大数据离线任务调度系统
定义
大数据离线任务调度系统 是指用于 管理、编排和执行批处理（离线）数据任务 的平台，它确保 数据在正确的时间、以正确的依赖关系顺序、在正确的计算资源上被处理，以支持数据仓库建设、ETL流程、数据分析、数据报表等工作。
上下游关联：上层是数据开发平台、BI平台、机器学习平台等等，下层是Spark、MR、异步数据源同步引擎等底层引擎
运行频率：一般是分钟级、小时级、日级
痛点问题
- 调度时延高：对于到达就绪时间的任务，旧架构下采取轮询的模式从DB查询任务，时延较高
- 有状态服务：服务内存中存储DAG结构，服务重启或故障情况下需要恢复内存状态
- 单点问题：服务发布、单点故障会导致服务不可用。
关键设计
事件驱动+分布式
非阻塞设计，有效降低任务和链路的调度时延
优点：
- 异步非阻塞：使得系统响应速度更快，延迟更低
- 扩展性强：事件可以作为切面，可以支持更丰富的hook逻辑，而不阻塞主业务逻辑
- 高可用：事件缓存在消息队列，部分服务器上的服务异常，不会影响服务整体的可用性
挑战：
- 事件幂等：事件消息生产-消费的过程中，为了避免网络问题等导致流程异常中断，一定会做重试。所以要对事件的处理做幂等处理。通过【状态机+事件去重】来做幂等
- 事件乱序并发：状态机校验+partition分区，同一任务相关事件单线程处理，类似actor模式，避免复杂的并发处理，避免在任务粒度上加分布式锁带来的性能开销
“无状态”服务
基于缓存中间件存储DAG结构，服务重启或单点故障时无需做状态恢复
组件选型
定时触发任务
Quartz vs 延迟队列（kafka+tair时间轮）
消息队列
Kafka vs rabbitMQ vs RocketMQ
分布式内存
Redis-cluster vs Tair
分布式协调服务
ZooKeeper vs ETCD
详细设计
延迟队列：对比Quartz等分布式方案，没有使用分布式锁，而是基于kafka+tair用时间轮实现，延迟更低
事件消费速度：partition单线程拉取+多线程批量消费，滑动窗口ACK
分布式有序提交：mr模式，map基于sorted set设计的优先级队列，reduce采用dispacther线程单线程提交，多实例采用zk公平锁实现均衡
自动容错：服务重启，节点宕机情况下能自动容错。注册中心zk
不停机运维：版本号的事件设计，运维操作需要与调度并行，对于子DAG的运维需要在不影响其他任务的前提下，不受非运维消息的影响
问题与解决方案
Q：单线程dispatcher缓存操作效率低
A：批处理+pipeline
Q：未知原因导致调度慢？CPU指标较高？
A：redis监控，服务日志无异常。Arthas火焰图大部分时间做监控数据上报，调小监控上报的线程池大小
Q：kafka partition批量消费加了内存锁，一个事件处理线程卡住？
A：jstack发现一个线程卡住，定位到实现的一个LockManager对于unlock操作不当
Q：上游触发下游执行时给事件赋值版本号，此时可能同时存在运维动作
A：版本号+上游依赖版本
大数据资产管理与治理平台
提升数据资产(Hive 表、Spark、Flink 任务等)全方位可视化管理、优化资源利用、实现智能治理，并提供量化收益评估，最终推动资源合理使用，提高数据资产的整体价值
痛点问题
业务痛点：分区生命周期应该配置多久？如果发现无效的离线数仓表/任务？怎么常态化推动持续治理？
技术难点：复杂业务流程建模、流程自动化、流程可视化。等待用户确认，操作分区数据等能力做抽象，具备复用能力
关键设计
fe：
主要负责资产360，资产问题发现与治理
spark+hive/es构建资产元数据，SpringBoot+es+doris搭建资产管理与治理系统。定义问题资产评估标准，定期扫描百万级数据表/任务，辅助定位资源问题，同时提供治理流程追踪与自动化治理，提升治理效率
be：
主要承载资产管理能力，如表及分区周期清理、降低副本、ORC压缩
spiffworkflow：python实现的一套BPMN workflow框架，组织各种同步/异步任务的处理流程
celery：异步任务处理