话题中间件与数据库 › ClickHouse

中间件与数据库:ClickHouse

映客基于Clickhouse的日志体系建设实践

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

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

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

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

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

火山引擎 ByteHouse:ClickHouse 如何保证海量数据一致性

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

ClickHouse 存算分离改造:小红书自研云原生数据仓库实践

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

基于ClickHouse解决活动海量数据问题

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

万字长文详述ClickHouse的探索与实践

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

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

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

​深入浅出 ClickHouse 物化视图

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

ByteHouse:基于ClickHouse 的实时计算能力升级

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

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

每天十亿级数据更新,秒出查询结果,ClickHouse在携程酒店的应用

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

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

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

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

B站基于ClickHouse的海量用户行为分析应用实践

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

ClickHouse 查询优化详细介绍

ClickHouse 是 OLAP(Online analytical processing)数据库,以速度见长。

ClickHouse在自助行为分析场景的实践应用

为了支撑业务精细化运营场景下实时多维分析能力,本文将为大家带来主流MPP架构数据库ClickHouse在自助分析场景中的探索及实践。

clickhouse在风控-风险洞察领域的探索与实践

以Clickhouse+Flink实时计算+智能算法为核心架构搭建的风险洞察平台,建立了全面的、多层次的、立体的风险业务监控体系,已支撑欺诈风险、信用风险、企业风险、小微风险、洗钱风险、贷后催收等十余个风控核心场景的实时风险监测与风险预警,异常检测算法及时发现指标异常波动,基于根因策略快速做到风险归因分析并生成风险报告,接入MQ主题500+、数据模型6000+、实时预警4000+、 风险监控看板1000+、 异常检测模型10000+, 大促时期分钟级消息处理量达3400w/min,日均消息处理量达百亿。

ClickHouse 冷热分离存储在得物的实践

文章主要讲解了前一段时间 DBA 团队在日志平台的业务改造中参与的一部分事项,如表字段索引设计建议,过期策略的方案制定,SQL 编写和优化建议,提供成本降低方案等输出。

B站基于Clickhouse的下一代日志体系建设实践

日志作为线上定位问题排障的重要手段,在可观测领域有着不可替代的作用。​稳定性、成本、易用性、可扩展性都是日志系统需要追求的关键点。

火山引擎在行为分析场景下的 ClickHouse JOIN 优化

随着接入应用以及应用的 DAU 日益增加,ClickHouse 表的事件量增长迅速;并且基于行为数据需要分析的业务指标越来越复杂,需要 JOIN 的表增多;我们遇到有一些涉及到 JOIN 的复杂 SQL 执行效率低,内存和 CPU 资源占用高,导致分析接口响应时延和错误率增加。

漫谈Clickhouse Join

随着公司业务的不断发展,不同业务线数据都有了大规模积累。在此基础上为了精细化运营,更好地服务客户,就需要通过积累的数据沉淀出各类实体标签,比如用户标签、帖子标签、基金标签。

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.123.1. UTC+08:00, 2024-03-29 02:05
浙ICP备14020137号-1 $访客地图$