不想说话

线上已有的topurl方案不能满足数据量增大后的需求，设计通过flink实现topurl，包括参数配置，执行图，，执行脚本等。

ClickHouse的副本协同以及分布式查询是借助zk实现的，首先介绍下zk的目录结构 zk目录结构 zk在系统表中，提供了一张名为zookeeper的代理表，需要指定路径去查询。

通过ck实现topurl功能，包括实现架构，建表方案，写入方案，测试等。提出新的优化点。优化点部分未完待续。。。

线上问题 目前线上使用ES，经常会遇到慢查询报警，目前线上查询时间超过30s会触发慢查询报警。这些慢查询有两个特点： 查询的时间跨度比较大 存在嵌套查询

目前使用了ck和es作为olap组件，ck解决了我们的痛点。从使用方式，写入，查询，查询性能多个角度分析下优劣。

flink优于spark的特性： 首先明确计算模型是不同的： minibatch vs dataflow模型 minibatch:微批，时间驱动； dataflow模型：事件驱动的 长尾效应

线上问题 由于线上Spark集群均为过保机器，经常会出现某台机器出故障的情况，导致任务经常会进行失败重试，下面从源码角度解析失败重试的流程和重试逻辑。 流程 参考 https://juejin.cn/

SortShuffleManager.getReader() 获取map任务状态 MapOutputTrackerWorker.getMapSizesByExecutorId() getStatus

SortShuffleWriter shuffle write流程： 创建ExternalSorter,如果不需要mapSideCombine，把聚合函数和ordering设置为none Extern