本文基于Elasticsearch/Clickhouse在B站生产环境的容器化/K8s编排能力落地， 将阐述为何我们需要进行容器化/on k8s， 容器化中遭遇的挑战以及解决方案， 落地的技术细节以及收益。

本文主要介绍滴滴日志检索场景从ES迁移到CK的技术探索。

B站为外部公会提供了主播全生命周期的管理系统，包含主播的入退会管理、主播营收数据分析、主播开播看播数据分析、直播监控、营收账单结算等功能子模块。

ClickHouse是一款开源的列式数据库管理系统，适用于在线分析处理（OLAP）场景，本文通过介绍ClickHouse，帮助读者今后快速地处理大规模数据，并获得实时的分析结果，为业务提供有力支持。

Insights gained and lessons learned from our long video analytics migration journey.

ClickHouse是一个开源的高性能面向列的数据库，用于在线分析处理。Lyft决定扩展ClickHouse并废弃Druid，将现有的Druid用例迁移到ClickHouse。ClickHouse相对于Druid具有简化的基础设施管理、较低的学习曲线、数据去重、较低的成本和专门的引擎等优势。Lyft通过基准测试和性能分析来评估ClickHouse，并进行了平滑的迁移过程。他们在Lyft使用ClickHouse的架构是基于Altinity的Kubernetes Operator，在HA模式下运行，使用AWS M5类型的计算实例和EBS卷进行存储。数据的摄取主要通过Kafka和Kinesis进行，并通过内部代理和可视化工具进行读取查询。Lyft在ClickHouse上处理大量数据，并对查询性能进行了优化，包括使用排序键、跳过索引和投影等技术。他们在ClickHouse上处理多个用例，包括市场健康、政策报告、花费追踪、预测和实验等。然而，在使用ClickHouse过程中也遇到了一些问题，如查询缓存性能和与Kafka集成的问题。此外，Lyft计划进一步扩展ClickHouse的使用，包括稳定批处理架构和使用流式Kinesis摄取。他们还计划将Flink SQL迁移到ClickHouse，并考虑使用ClickHouse Keeper替代ZooKeeper以减少外部组件依赖。

作为线上定位问题和排查故障的重要手段，日志在可观测领域有着不可替代的作用。因此，日志系统需要追求稳定性、性能、成本、易用性、可扩展性等关键点。

目前我司的日志系统是基于ELK的，支持云主机、容器日志采集和特殊分类日志的综合采集等功能。但是随着公司的业务发展，日志应用场景逐渐遇到了一些瓶颈：

1. 数据增长和处理需求增加：业务的不断扩张和数据量的增加，原有的日志系统无法满足现有的数据处理需求。数据处理速度变慢，存储空间不足等问题。
2. 数据质量和可靠性要求提高：日志数据对于公司业务和运维至关重要，因此数据质量和可靠性要求越来越高。原有的日志系统存在日志丢失、日志收集慢等问题，需要进行改进。

现状：目前总共运行 8个 ES 集群，机器数量100+， Logstash 机器 50+，需要的硬件和维护成本很高，通过扩容的方法去满足业务场景，ES集群会太大会变动不稳定，创建独立集群，也需要更高成本，两者都会使得成本和维护工作量剧增。

鉴于这些问题，去年下半年开始探索新的日志系统架构，以彻底解决上面的问题。

用搭建轻量级流程引擎的方案，教你解决数据一致性难题。

REDck 通过云原生架构升级，能够处理万亿级数据规模，实现秒级 OLAP 查询，支持分钟级自动故障恢复、弹性扩缩容能力，成本优化效果显著。

魔笛活动平台要记录每个活动的用户行为数据，帮助客服、运营、产品、研发等快速处理客诉、解决线上问题并进行相关数据分析和报警。可以预见到需要存储和分析海量数据，预估至少几十亿甚至上百亿的数据量，所以需要选择一款能存储海量数据的数据库。由于是通过接收MQ存储或者API方式存储，所以对实时写入性能也有一定要求。同时可能后续还需要一些实时数据分析等。

京喜达技术部在社区团购场景下采用JDQ+Flink+Elasticsearch架构来打造实时数据报表。随着业务的发展 Elasticsearch开始暴露出一些弊端，不适合大批量的数据查询，高频次深度分页导出导致ES宕机、不能精确去重统计，多个字段聚合计算时性能下降明显。所以引入ClickHouse来处理这些弊端。

数据写入链路是业务数据(binlog)经过处理转换成固定格式的MQ消息，Flink订阅不同Topic来接收不同生产系统的表数据，进行关联、计算、过滤、补充基础数据等加工关联汇总成宽表，最后将加工后的DataStream数据流双写入ES和ClickHouse。查询服务通过JSF和物流网关对外暴露提供给外部进行展示，由于ClickHouse将所有计算能力都用在一次查询上，所以不擅长高并发查询。我们通过对部分实时聚合指标接口增加缓存，或者定时任务查询ClickHosue计算指标存储到ES，部分指标不再实时查ClickHouse而是查ES中计算好的指标来抗住并发，并且这种方式能够极大提高开发效率，易维护，能够统一指标口径。

在引入ClickHouse过程中经历各种困难，耗费大量精力去探索并一一解决，在这里记录一下希望能够给没有接触过ClickHouse的同学提供一些方向上的指引避免多走弯路，如果文中有错误也希望多包含给出指点，欢迎大家一起讨论ClickHouse相关的话题。

虽然官方文档记录了 ClickHouse 物化视图很多详细信息，但是使用物化视图还是有很多小细节需要注意，更别说一些最佳实践。本文总结了 ClickHouse 物化视图使用上的各种问题，并展示三个实际案例。

ByteHouse是火山引擎数智平台旗下云原生数据分析平台，为用户带来极速分析体验，能够支撑实时数据分析和海量离线数据分析；便捷的弹性扩缩容能力，极致的分析性能和丰富的企业级特性，助力客户数字化转型。

本文为字节跳动数据平台超话数据直播回顾文章，全篇将从字节内部发展链路、选择ClickHouse原因，基于ClickHouse的四个维度优化、多场景实践四个版块，介绍ByteHouse基于ClickHouse的实时计算能力升级。

1）携程酒店每天有上千表，累计十多亿数据更新，如何保证数据更新过程中生产应用高可用；

2）每天有将近百万次数据查询请求，用户可以从粗粒度国家省份城市汇总不断下钻到酒店，房型粒度的数据，我们往往无法对海量的明细数据做进一步层次的预聚合，大量的关键业务数据都是好几亿数据关联权限，关联基础信息，根据用户场景获取不同维度的汇总数据；

3）为了让用户无论在app端还是pc端查询数据提供秒出的效果，我们需要不断的探索，研究找到最合适的技术框架。

对此，我们尝试过关系型数据库，但千万级表关联数据库基本上不太可能做到秒出，考虑过Sharding，但数据量大，各种成本都很高。热数据存储到ElasticSearch，但无法跨索引关联，导致不得不做宽表，因为权限，酒店信息会变，所以每次要刷全量数据，不适用于大表更新，维护成本也很高。Redis键值对存储无法做到实时汇总，也测试过Presto，GreenPlum，kylin，真正让我们停下来深入研究，不断的扩展使用场景的是ClickHouse。

数据驱动理念已被各行各业所熟知，核心环节包括数据采集、埋点规划、数据建模、数据分析和指标体系构建。

ClickHouse 是 OLAP（Online analytical processing）数据库，以速度见长。