ClickHouse

Multiple small inserts in clickhouse

由 我的未来我决定 提交于 2021-01-02 05:42:44
问题 I have an event table (MergeTree) in clickhouse and want to run a lot of small inserts at the same time. However the server becomes overloaded and unresponsive. Moreover, some of the inserts are lost. There are a lot of records in clickhouse error log: 01:43:01.668 [ 16 ] <Error> events (Merger): Part 201 61109_20161109_240760_266738_51 intersects previous part Is there a way to optimize such queries? I know I can use bulk insert for some types of events. Basically, running one insert with

Multiple small inserts in clickhouse

由 我的梦境 提交于 2021-01-02 05:42:36
问题 I have an event table (MergeTree) in clickhouse and want to run a lot of small inserts at the same time. However the server becomes overloaded and unresponsive. Moreover, some of the inserts are lost. There are a lot of records in clickhouse error log: 01:43:01.668 [ 16 ] <Error> events (Merger): Part 201 61109_20161109_240760_266738_51 intersects previous part Is there a way to optimize such queries? I know I can use bulk insert for some types of events. Basically, running one insert with

ClickHouse和他的朋友们（14）存储计算分离方案与实现

由 不打扰是莪最后的温柔 提交于 2020-12-28 09:36:15
原文出处：https://bohutang.me/2020/09/18/clickhouse-and-friends-compute-storage/ 最后更新: 2020-09-18 如果多个 ClickHouse server 可以挂载同一份数据(分布式存储等)，并且每个 server 都可写，这样会有什么好处呢？ 首先，我们可以把副本机制交给分布式存储来保障，上层架构变得简单朴素； 其次，clickhouse-server 可以在任意机器上增加、减少，使存储和计算能力得到充分发挥。 本文就来探讨一下 ClickHouse 的存储计算分离方案，实现上并不复杂。 1. 问题 ClickHouse 运行时数据由两部分组成：内存元数据和磁盘数据。 我们先看写流程： w1. 开始写入数据 w2. 生成内存part信息，并维护part metadata列表 w3. 把part数据写到磁盘 再来看读流程： r1. 从part metadata定位需要读取的part r2. 从磁盘读取part数据 r3. 返回给上层数据 这样，如果 server1 写了一条数据，只会更新自己内存的 part metadata，其他 server 是感知不到的，这样也就无法查询到刚写入的数据。 存储计算分离，首先要解决的就是内存状态数据的同步问题。 在 ClickHouse 里，我们需要解决的是内存中

clickhouse小工具&小技巧收集汇总

由 扶醉桌前 提交于 2020-12-26 00:53:19
0x01. 排查clickhouse问题 找到问题发生的时间点，可以对照grafana中的资源监控来看时间点 找/var/log/clickhouse-server/clickhouse-server[-err].log对应时间点的日志 查看system.query_log/processes具体的一些动作，定位问题 0x02. 琐碎的小技巧和系统表 改名 rename table ods_data.single_point_log_2 to ods_data.single_point_log on cluster cluster_2shard_5_6_2replicas_5_6; 更改或者删除表数据 ALTER TABLE [db.]table [ON CLUSTER cluster] DELETE WHERE filter_expr clickhouse中这些语句是异步执行的，查询这些语句执行情况，可以查看system.mutations表，找到执行语句对应的记录，is_done为1表示执行完成 system.query_log与慢查询查询 query_log系统表记录clickhouse中sql执行的历史，可以查看执行时间，影响的数据行等信息，可以为优化SQL提供一些关键性的信息。当然基于此我们也可以做一些监控，例如下面的慢查询语句 --查询执行超过1000秒的语句

ClickHouse数据库培训实战 （PB级大数据分析平台、大规模分布式集群架构）

由 和自甴很熟 提交于 2020-12-17 07:50:20
一、ClickHouse数据库培训实战课程 （PB级大数据分析平台、大规模分布式集群架构）视频教程 为满足想学习和掌握ClickHouse大数据分析专用的数据库，风哥特别设计的一套比较系统的ClickHouse数据库培训课程； 本套ClickHouse数据库培训实战课程 课程共计10小时，内容涉ClickHouse数据库基础知识、ClickHouse分布式集群特性与解决方案、ClickHouse分布式集群生产项目实战（分片/副本/复制/负载分发）、ClickHouse数据库日常维护与管理入门等，适合运维/数据库/大数据等人员用于实际项目工作之中，用于大数据分析平台的建设与管理。 本课程学习下载地址： https://edu.51cto.com/course/26149.html 欢迎加入： 51CTO学院Oracle/MySQL/DB2数据库学习专用QQ群： 199 479 729、189 07 0296 ClickHouse是2016年俄罗斯Yandex公司开源出来的一款MPP架构（大规模并行处理）的列式数据库，主要用于大数据分析（OLAP）领域，具有快速查询、线性可扩展、功能丰富、硬件利用效率高、容错、高度可靠等优点。 ClickHouse主要应用场景： 电信行业用于存储数据和统计数据使用 用户行为数据记录与分析 信息安全日志分析 商业智能与广告网络价值数据挖掘分析

function same as lag partition by in clickouse

由 China☆狼群 提交于 2020-12-15 06:21:08
问题 I need to know the frequency of order for each user. I mean difference between 2 order time for each user. In SQL I used "Lag Partition by" but I don't know how I can calculate this in click house. I need this data: at first I should sort data with user_id and created_at then I need to have next order time for each user id in row. I can't use neighbor function because it can't do partition by user_id. 回答1: I didn't understand why neighbor cannot be used in your case, but it should works well:

性能提高15倍！只是把MySQL换成了ClickHouse

由 人盡茶涼 提交于 2020-12-15 01:56:48
简介 我们需要存储结构化时序数据，时间间隔为5分钟或1分钟，计算 95峰值 、 995峰值 、 最值 等指标，并且在网页中展示。 MySQL 项目开发初期，为了快速开发原型，验证产品，我们使用MySQL作为整个项目的存储。带来的问题是时序数据库范围分析查询耗时很长，计算30天的数据需要30s+，到了无法容忍的地步，即便是创建索引、使用BitInt存储时间戳，几乎没有性能提升。 后来我们组其他同事说换ClickHouse来存储时序数据，于是我们就开始了替换之旅。 ClickHouse ClickHouse是面向OLAP（在线分析处理）、兼容SQL标准的列式数据库，主要的不足是 不支持事务 。因此我们目前没有把整个存储都迁移到ClickHouse上，而是只把时序数据存过来。 本以为替换过程会很麻烦，可能修改大量的代码和逻辑，实际上很快，因为之前接口的逻辑设计很合理，所以只替换了数据库ORM库，从gorm换成了sqlx，花了1天时间( 前期重构逻辑花了1个星期我会乱说 )。 更重要的是，ClickHouse提供了很多聚合函数，之前计算95值需要2次查询，而现在只需要一次查询就够了，对应的SQL如下： select d.en_name, max (d.in_value) as peak_in, max (d.out_value) as peak_out, max (d.max_value)

数据仓库搭建及指标体系建设

由 懵懂的女人 提交于 2020-12-14 12:58:46
12月19日，13：30-17：10，由陌陌科技数据基础架构总监金晓烨老师出品的DataFunTalk年终大会——数据仓库论坛，将邀请来自滴滴、陌陌、贝壳、熵简科技、阿里云等公司的5位嘉宾，就数据仓库相关话题进行分享。本次会议 全程直播 ，详细信息如下： 01 论坛日程 论坛名称 数据仓库论坛 论坛时间 12月19日，13:30-17:10 论坛出品 金晓烨 陌陌 数据基础架构总监 分享时间 分享内容 13:30-14:10 滴滴数据仓库指标体系建设实践 滴滴数仓高级专家 曹雷 14:15-14:55 大数据治理优化在陌陌的探索与实践 陌陌数据仓库工程师 刘志祖 15:00-15:40 贝壳基于Druid的OLAP引擎应用实践 贝壳找房资深研发工程师 王啸 15:45-16:25 金融资管数据中台体系在熵简科技的探索与实践 熵简科技技术合伙人 金晨 16:30-17:10 ClickHouse在海量数据分析场景下的应用实践 阿里云数据库资深技术专家 魏闯先 02 论坛报名 识别二维码，免费报名 03 详细介绍 出品人： 金晓烨 陌陌科技 | 数据基础架构总监 出品人简介： 北京邮电大学网络技术研究院硕士，2013年初加入陌陌，专注于数据密集型应用的系统架构研究，致力于实现公司数据平台能力开放、数据使用赋能、高 SLA 数据生产保障的团队目标，推进陌陌数据平台

腾讯云数据库MySQL高可用实践

由 允我心安 提交于 2020-12-13 10:20:55
主题： 腾讯云数据库MySQL高可用实践 大纲： 1. 给刚进入数据库行业新人的一些建议 2. 目前腾讯云RDS的可用性达到了99.9999%，需要做好哪些工作才能达到如此高的稳定性 3. 腾讯云RDS的性价比很高，请问都包含了哪些方面 4. TXSQL的好处 5. 腾讯云下关于MySQL高可用还需要使用者额外去监控哪些内容 听说3306π要搞事情了 是啊，马上要搞3306π深圳站了 啊，是吗？哪天啊，在哪里办，怎么报名？ 12月19日 ，就在 深圳南山区海岸城 ，点文末的原文链接或者扫描二维码就可以报名了，一起来吹吹牛逼。 嘉宾自我介绍 杨杰 架构师 CDB/CynosDB数据库管控平台架构师，TXSQL内核源码贡献者，腾讯内部开源MySQL 无锁备份工具作者 01 很多小伙伴进入数据库行业，都会把进入腾讯作为目标，杨老师作为过来人可否给大家一些建议吗？ 以我自身的经历来说，进入数据库行业也是偶然的机会。在腾讯数据库团队已经是第8个年头，最近几年招聘工作也比较多，算是有些心得吧。对于毕业生来说，我关注的是基础的技术能力、逻辑思维和技术热情。基础能力包括编程语言基础、数据结构和算法，这方面是硬实力，不可或缺但比较容易掌握，建议可以多刷题。 逻辑思维能力，即分析问题的能力，对所做的事情是有一个较全面的认识，对项目/技术有思考。 技术热情比较好理解，就不在赘述了。 对于已经在职同学来说

Flink 消息聚合处理方案

由 时间秒杀一切 提交于 2020-12-12 13:53:53
微博机器学习平台使用 Flink 实时处理用户行为日志和生成标签，并且在生成标签后写入存储系统。 为了降低存储系统的 IO 负载，有批量写入的需求，同时对数据延迟也需要进行一定的控制，因此需要一种有效的消息聚合处理方案。 在本篇文章中我们将详细介绍 Flink 中对消息进行聚合处理的方案，描述不同方案中可能遇到的问题和解决方法，并进行对比。 基于 flatMap 的解决方案 这是我们能够想到最直观的解决方案，即在自定义的 flatMap 方法中对消息进行聚合，伪代码如下： 对应的作业拓扑和运行状态如下： 该方案的优点如下： 逻辑简单直观，各并发间负载均匀。 flatMap 可以和上游算子 chain 到一起，减少网络传输开销。 使用 operator state 完成 checkpoint，支持正常和改并发恢复。 与此同时，由于使用 operator state，因此所有数据都保存在 JVM 堆上，当数据量较大时有 GC/OOM 风险。 使用 Count Window 的解决方案 对于大规模 state 数据，Flink 推荐使用 RocksDB backend，并且只支持在 KeyedStream 上使用。与此同时，KeyedStream 支持通过 Count Window 来实现消息聚合，因此 Count Window 成为第二个可选方案。 由于需要使用 KeyedStream
订阅 ClickHouse