架构思想

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

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

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

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

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

# broker网络通信模型 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/833f4bb60dc8444184de66

一句话，kafka 的 controller 在 zookeeper 的协助下管理整个 kafka 集群。   首先回顾下 zookeeper 的目录结构：   Controller 的职责主要是：

Kafka作为一个分布式的消息系统，最大的瓶颈在于磁盘I/O以及网络I/O,Kafka实现高性能主要在这两个方面进行优化。   首先在生产者生产消息时是批量发送（参数batch.size），加上粘性分

Kafka的zookeeper依赖演进 clients对zk的依赖 从0.8.x版本到0.11.x版本，clients端已经基本移除对zk的依赖 目前新版本采用kraft替代zk写入效率和切换效率提升

首先，从kafka 2.4版本开始，支持follower对外提供读服务，可以设定哪些follower副本可以对外提供服务，主要是为了避免跨机房的数据消费。kafka从设计理念上来讲并不支持读写分离原因

介绍LSM存储引擎和其他存储引擎的对比，其应用场景。ClickHouse使用LSM存储引擎和列存。按照分区键分成不同的目录，达到阈值后压缩落盘生成block。