clickhouse在有赞的使用和优化

（第1期） ClickHouse在有赞的使用和优化 陈琦有赞基础架构组 相关介绍 有赞是什么: 是一家商家服务公司。致力于成为商家服务领域里最被信任的引领者；并持续做一个Enjoy的组织。 •SaaS服务:有赞微商城，有赞零售，有赞连锁，有赞美业，有赞小程序。 •PaaS云服务:面向第三方开发者的有赞云。 •支付业务。 个人介绍: 陈琦kakachen(https://github.com/kaka11chen) 十年以上的工作经验。Java/C/C++程序员。 专注于网络编程，系统编程和大数据基础组件。Druid，ClickHouse，Presto，Flink，Hudi等项目的Contributor。2018年加入有赞，目前在有赞负责OLAP和实时相关技术。 目录 01OLAP@有赞 02 ClickHouse在有赞的 平台化工具建设 03 ClickHouse在有赞的 应用 04 未来规划和一些探索 有赞OLAP发展 2018 2019 Presto 离线数据的交互式分析问题。 MPP架构，全内存+ Pipeline。 应用场景包括临时查询，BI报表，元数据等。 Kylin 性能要求高，精确度要求高的离线数据分析。 完全预聚合立方体。 应用场景包括商家后台，流 量分析，财务分析等。 2019 Druid 实时数据分析。 预计算最细粒度的聚合+实时聚合。 应用场景包括实时监控，实 时分析，实时数据产品等。 2020 ClickHouse 实时数据分析。 明细动态聚合查询+物化视图。 应用场景：SCRM，DMP，CDP，直播分析，日志指标分析等。 有赞OLAP发展和选型 ClickHouse特性 特性: •灵活，支持明细数据SQL查询，并用物化视图加速。 •多核(垂直扩展)，分布式处理(水平扩展)，MPP架构。 •支持实时批量数据摄入。 •列式存储，向量化引擎，代码编译生成。 •主键索引，二级索引。 不擅长: •没有高速，低延迟的更新和删除方法。 •稀疏索引使得点查性能不佳。 •不支持事务。 应用场景: •用户行为分析，精细化运营分析:日活，留存率分析，路径分析，有序漏斗转化率分析，Session分析等。 •实时日志分析，监控分析，实时数仓。 ClickHouse原理简介 为啥快呢？ 自底而上的设计，极度关注底层实现性能，各种优化。比如Aggregator针对不同数据类型使用不同的Hash表进行优化 MergeTree原理: ClickHouse集群部署 •LoadBalancer:LVS。 •Proxy:APISIX代理网关，用于熔断，限流，安全，日志等功能。 •Distributetable:分布式表，分发查询请求，合并，排序结果。 •CHShard&Replication:分片，副本。 •ZooKeeper:协调多个副本复制。 因为考虑到机器的成本，分布式表层和分片复制集层是在部署在同一个主机上的。 ClickHouse写入 •离线通过Spark将Hive表数据导入，实时通过Flink将Kafka数据导入。 •批量方式写入。 •写本地表，读分布式表。 •Random，Hash等方式。 ClickHouse写入 •离线导入:•实时导入: ClickHouse离线读写分离 •Why: 业务场景写入量巨大，写多读少。为写入扩分片，提高写入吞吐，但是读写不分离，查询QPS又不 高，导致资源浪费。 •解决方案: 离线读写分离，将写入单独分离出来，构建完数据文件后，attach到目标集群。 •可行的方案: •使用K8sch临时集群来写入，构建数据文件。 •使用Spark构建数据文件。 我们采用K8s方案，因为相对容易实现。 ClickHouse离线读写分离 基本工作流程: 1.启动DataImportJob任务进行相关数据库/表/分区的导入。 2.使用ch-operator构建k8s临时写入集群。其中一个pod运行两个container:Clickhouseserver和CHSegementPusher。 3.从正式集群获得相关表schema进行创建，启动Spark任务写入数据到k8s临时写入集群。 4.Spark任务写完数据后，发送push任务到分布式任务队列，CHSegementPusher接收到相应任务开始detach表数据到相关目录，pushsegment到HDFS。 5.所有的CHSegementPusher处理完数据后，发送pull任务到分布式任务队列。 6.CHSegmentPuller部署在CH正式集群的每个节点上，从任务队列取出任务。根据任务的segmentid从HDFS上下载相关segment，attach到表数据。 其中ApacheHelix(基于zk)负责: •集群管理，master，puller，pusher不同角色resource的管理，高可用，扩缩容等。 •通过自定义helixrebalancer来保证相同分片的replicas形成一个 partition。 •分布式任务队列分派机制。 DMP人群画像系统 DMP人群画像计算: •静态标签预计算成正交位图。 •实时标签通过行为明细计算，转换成位图。 SCRM商家会员管理系统 •非常灵活 •维度可变，状态回溯 •动态圈选 •跨店，跨天去重 天网日志监控TopN系统 业务场景: 根据一些维度，计算一些指标(比如最大值，最小值，求 和)，取TopN的数据。 包含以下场景: •错误日志TopN：了解应用的健康状况、关键问题所在。 •商家限流TopN：了解每个商家的业务规模跟目前的服务等级的匹配度。 •服务吞吐量TopN：了解应用提供的哪些服务是核心。 •特性/功能TopN：了解哪些特性/功能更受用户喜欢。 性能指标: •每秒100w行数据的Kafka写入QPS •内部使用，查询QPS在20左右。 技术栈演进: Druid预聚合 =》 Flink+ClickHouse(使用物化视图进行预聚合)。 收益: •节省了60%以上的硬件资源。 •同时，性能体验也大大提升。 ClickHouse有赞的未来规划 •ClickHouse容器化部署:容器化部署更高拥有更好的弹性伸缩能力，也能和其它的服务进 行混合部署来节省成本。 •ClickHouse更多的推广，更多业务的接入:比如用户行为分析，实时数仓，实时报表等业务。 •ClickHouse更好的平台化以及故障防范:ClickHouse平台化，业务方易用性，多租户隔离，限流，熔断，监控报警，业务治理等方面进行更多地投入。 •使用Druid+ClickHouse的双链路或者将Druid的业务迁移到ClickHouse。 ClickHouse当前痛点 ClickHouse痛点: •ClickHouse不太像一个传统意义上的分布式数据库，整体来说比较“手动档”。很多地方都需要用户自己去设计一个流程去完善，比如写入，物化视图等。 •没有自动Rebalance的能力，导致扩容缩容运维特别复杂。 •Join不是采用Shuffle/ExchangeJoin，数据量大性能差。 •行级别Update/Delete性能差，官方也不推荐。 •社区和很多大厂都在针对这些痛点进行相关的尝试，改进，比如存储计算分离，ExchangeJoin实现等。 那么ApacheDoris呢？ ApacheDoris也在快速发展，好多大厂也开始尝试使用。相比ClickHouse，Doris更像一个分布式数据库，也解决了部分痛点，比如能够自动平衡，支持ShuffleJoin等。但是就目前为止单表性能，成熟度，稳定性还不如ClickHouse。 DorisDB和Hologres,TiFlash等:可以尝试，未知程度比较高，也不知道未来是否开源。 ClickHouse+DorisPOC实现 于是我们产生了一个想法: 能否结合两者，利用高性能的ClickHouse算子实现替换基于Impala的ApacheDoris，在未来打造出更好的分布式OLAP数据库。 POC实现主要是验证可行性的，因此实现起来以快为主，很多地方可能只是临时Mock之类的。 1.尝试将Dorisbe的代码一起编译到ClickHouse中运行起来。DONE 2.尝试将解析相关fragments，并且映射成clickhouse的几个简单的算子(Storage扫描，聚合，表达式)，能跑一 个简单的单机SQL。DONE 3.尝试将DorisOLAP的存储实现成ClickHouse的Storage(StorageDorisOLAP)，并且能跑一个简单的单机SQL。如果能用Doris的相关存储，也能使用其自动平衡的能力。DONE 4.尝试实现Dorisexchangenode的算子，能够跑通一个简单的分布式SQL。DOING 5.。。。 总体来说，从目前来说，我觉得这应该是可行的。如果顺利，后期我们会投入更多的精力在这上面。 ClickHouse+DorisPOC实现 •Dorisfe: •使用ClickHouse模拟的Dorisbe: ClickHouse+DorisPOC实现 •单机SQL执行:(简单的聚合，表达式计算) •StorageDorisOLAP 大数据数据库未来趋势 •云原生:可任意扩缩容，存储计算分离，多租户，Serverless，按需付费。 (Snowflake，BigQuery，SaaS/DaaS) •多模数据库:融合OLAP，OLTP能力，一站式解决。(TiDB+TiFlash, Hologres) •利用新硬件:GPU，FPGA。。 THANKS 合作伙伴：