随着 ClickHouse 越来越火热，很多公司都迫切地想体验一下这匹来自战斗民族的黑马，但体验这匹黑马，首先需要解决原有 Hive 数据仓库的数据和 ClickHouse 的互通问题。

本次分享主要带来唯品会如何选型组件 Sea Tunnel (原 Waterdrop) 完成 ClickHouse 和 Hive 的数据出仓入仓，内容包括过程中唯品会遇到了哪些痛点，是怎么解决的，在原有的功能上做了哪些优化等等，希望能和大家互相学习，交流经验。

演讲提纲：

1. ClickHouse 数据导入的需求和痛点
2. ClickHouse 和 Hive 出仓入仓工具的选型
3. Hive 出仓 ClickHouse
   • 使用 Sea Tunnel 中 HyperLogLog 加速
   • Bitmap 出仓入仓的实现
4. ClickHouse 数据入仓 Hive (含 Bitmap 数据类型)
5. Sea Tunnel 在唯品会数仓中扮演的角色
   • 平台的集成与扩展

听众受益：

• 完整了解 ClickHouse 和其他数据组件的数据导出导入
• 规避初次接触 ClickHouse 数据出入仓时可能碰到的问题和痛点

ClickHouse 的实时处理能力强悍，网易使用 ClickHouse 搭建了数据平台，承担数据存储和指标计算任务。但是数据平台在使用过程中，我们发现了 ClickHouse 的一些痛点问题：

• 更新支持能力弱
• 对明细表统计分析数据量极大时，查询时间较长
• 并发查询能力弱

网易是如何解决这些问题的？这是我今天要分享的重点，希望能和你一起交流讨论，给你在使用 ClickHouse 时提供一些帮助。

演讲提纲：

1. ClickHouse 在网易 CDP 中的角色
2. ClickHouse 更新能力弱
   • 如何利用聚合表实现以插入代替更新
3. ClickHouse 查询性能瓶颈
   • 如何利用预计算来加速查询
   • 网易预计算系统的实现思路
4. ClickHouse 大并发的查询时
   • 如何减少并发量

听众受益：

• 深入理解 ClickHouse 聚合表
• 了解 ClickHouse 做预计算的新视野
• 大并发的场景的解决方案

2016 年 ClickHouse 刚开源时，云智慧就被它强悍的查询性能和可以支撑的数据规模所吸引到，期望能将它应用于 AIOps 的场景中。随着 ClickHouse 本身的迭代完善和对其不断学习和研究，到 2018 年我们已经将 ClickHouse 作为了我们 AIOps 产品运维主数据的存储引擎，其以成本优势、支撑的数据规模和查询性能在实际项目中得到了不少客户的认可。迄今为止，已经服务了约数百个大中型的客户，在这个过程中，也遇到了不少问题和挑战，很高兴能和广大 ClickHouse 的用户和爱好者进行分享和交流，希望能互相学习共同进步。

演讲提纲：

1. AIOps 场景介绍
   • AIOps 在数据库方面的挑战
   • 为什么选择 ClickHouse 作为主数据库
2. ClickHouse 集群部署问题
   • 数据库集群的资源隔离问题
   • 集群配置以及数据冗余问题
   • 集群的动态扩容
   • 数据迁移备份问题
3. ClickHouse 对日志实时写入与查询问题
   • 海量日志及指标数据的实时写入
   • 读写分离
   • 确保写入一致性
   • 日志数据查询性能优化
   • 支持有并发要求的场景
   • 通过异常查询排查定位问题

你将获得：

• 了解 AIOps 的场景中 ClickHouse 使用方案

在使用 ClickHouse 集群时，很多人都以为必须使用 ZooKeeper。实际上 ZooKeeper 只是起到了一个辅助作用，可以让不熟练的人快速上手。事实上，用了 ZooKeeper 会在数据录入上导致不小的麻烦。因此，本次我分享的重点是联想如何去除 ZooKeeper 的依赖。

演讲提纲：

1. 为什么不使用 ZooKeeper 来完成标准集群实现
   • ZooKeeper 同步出现延迟问题
   • ZooKeeper 压力太大, 表处于“read only mode”模式
   • on Cluster 只支持 MergeTree 相关引擎的表
2. 实现无 ZooKeeper 的高可用的理论基础
   • ClickHouse 的独立性
   • ClickHouse 分片原理
   • Distributed 表引擎的原理
3. 实现高可用的历程
   • 通过 Distributed 实现数据同步复制
   • 通过修改 JDBC 实现数据复制同步
   • 通过修改 JDBC 实现读写分离

你将获得：

• 去 ZooKeeper 的 ClickHouse 使用方案

微信丰富多样的业务生态对数据分析产生了巨大的需求，如何对无时无刻不在产生的海量数据进行分析也成了一个艰巨的挑战。ClickHouse 作为当前 OLAP 领域的一匹快马，目前已成为微信团队实现数据驱动的重要载具。本次分享将聚焦 ClickHouse 的海量数据接入问题，分享微信 OLAP 团队在 ClickHouse 数据接入层累积的经验。

演讲提纲：

1. ClickHouse 在微信的应用(实验平台、BI 分析、特征计算，监控) 
2. ClickHouse 数据写入的一般原理与常见问题 
3. 微信 ClickHouse 数据接入层介绍（离线 & 在线）
4. Hash 路由写入实践 
5. 实时数据接入中的端到端的精确一次 
6. 效果总结与未来展望

针对业务日志信息的统计是一种常见的需求场景，实现方法也多种多样。中国移动在数据千亿条的场景下，先尝试了 ETL+MySQL，可处理的数据量又无法满足需求，又尝试了 ETL+Hive，但计算性能较差。我们希望在满足容量需求的情况下，能达到较好的性能，对整体架构进行了优化。本次分享将给大家带来使用 ClickHouse 实现千亿条日志数据统计的架构落地及优化，以及 ClickHouse 在这个过程中有哪些优势又有哪些问题。

演讲提纲：

1. 业务日志统计应用面临的问题
   • 业务需求概述
   • 应用的第一次尝试——MySQL
   • 应用的第二次尝试——Hive
2. 基于数据流动的架构优化
   • 架构优化思路
   • 基于 ClickHouse 的性能优化
   • 基于 ClickHouse 的数据流优化
   • 基于 ClickHouse 的数据生命周期优化
3. 后续的故事
   • 存在的问题以及后续研发方向

你将获得：

• 中国移动业务日志统计的选型经验
• 使用 ClickHouse 实现千亿条日志数据统计的落地方案