以服务于中国广大创业者为己任,立志于做最好的创业网站。

标签云创业博客联系我们

导航菜单

社区分析报告的内容有哪些,短视频内容数据分析报告

  

  近日,字节跳动旗下企业级技术服务平台火山引擎正式发布“ByteHouse”作为ClickHouse的企业版,解决开源技术问题。   

  

  尝试高成本的痛点,同时提供商业产品和技术支持服务。   

  

  作为国内最大的ClickHouse用户,目前字节跳动ClickHouse节点超过15000个,管理数据总量超过。   

  

  600PB,最大集群规模超过2,400个节点。一般来说,字节跳动很多广泛的业务增长分析都是基于基于ClickHouse的查询引擎。建筑。   

  

  在ClickHouse企业版《ByteHouse》的征途中,经过多年的探索和沉淀,今天我们和大家分享一下ClickHouse在字节跳动的过往使用。   

  

  的两个典型应用和优化案例。   

  

  #推荐系统实时指标。   

  

  “AB实验”在字节跳动被广泛使用,尤其是在验证推荐算法和函数优化的效果时。最初,公司的专业AB实验平台已经提供了T 1。   

  

  推荐系统需要更快地观察到某个函数的算法模型或在线效果,因此需要一个可以实时反馈的数据作为补充:   

  

  *可以同时查询汇总指标和明细数据;   

  

  *可支持数百列维度和指标,场景灵活,会不断增加;   

  

  *可以高效地按ID过滤数据;   

  

  *需要支持一些机器学习和统计相关的指标计算(如AUC)。   

  

  蚣际跹   

  

  以字节为单位的分析引擎有很多,比如ClickHouse、Druid、Elastic Search、Kylin等。在分析用户需求后,选择了ClickHouse:   

  

  *算法模型可以更快地被观察到,而不会因为预先计算而导致高数据延迟;   

  

  * ClickHouse不仅适用于聚合查询,在与hop索引匹配后,对详细检查也有很好的性能;   

  

  *字节开发的ClickHouse支持Map类型,支持动态变化的维度和指标,更符合需求;   

  

  * BitSet的滤镜Bloom Filter是一个不错的解决方案,ClickHouse最初是BF支持的;   

  

  *字节开发的ClickHouse引擎通过UDF实现了相关功能,具有较好的扩展性。   

  

  每个产品都有自己适合的场景,但是ClickHouse更适合当前场景的需求评估。   

  

  蚍桨钙拦   

  

  方案对比   

  

  确认技术选型后,也有两种实现方式:   

  

     

  ByteHouse:实时数据分析场景中的优化实践'/   

  

  最终方案 效果最终计划   

  

  由于不可控的外部编写和技术栈,我们最终采用了Kafka Engine的方案,即ClickHouse内置消费者进行消费。   

  

  卡夫卡.整体结构如下图所示:   

  

     

  ByteHouse:实时数据分析场景中的优化实践'/   

  

  *数据由推荐系统直接生成并写入Kafka――为了弥补Flink ETL能力的不足,推荐系统做了相应的配合,修改了Kafka Topic的消息格式,直接适配模式;ClickHouse表的;   

  

  *敏捷BI平台也适应实时场景,可以支持交互查询分析;   

  

  *如果实时数据有问题,也可以将Hive中的数据导入ClickHouse。此外,业务端会导入1%的离线采样数据进行一些简单的验证,1%的采样数据一般会保存更长的时间。   

  

  除了技术选型和实现方案外,我们在支持推荐系统的实时数据方面也遇到了很多问题,其中最大的问题是推荐系统产生的数据量在不断增加,单个节点的消耗能力也在不断增加,主要遇到了以下问题:   

g>蛭侍庖唬盒慈胪掏铝坎蛔

  

挑战 :在有大量辅助跳数索引的场景下,索引的构建严重影响写入吞吐量。

  

解决方案异步构建索引。

  

  

ByteHouse:实时数据分析场景下的优化实践' />   

社区版本的实现里的具体逻辑如下:

  

* 解析输入数据生成内存中数据结构的 Block;

  

* 然后切分 Block,并按照表的 schema 构建 columns 数据文件;

  

* 最后扫描根据 skip index schema 去构建 skip index 文件。三个步骤完成之后才会算 Part 文件构建完毕。

  

在需要保证构建完 columns 数据之后用户即可正常查询的前提下,ByteHouse 同步完成前面两步,第三步把构建好的 part

  

放入到一个异步索引构建队列中,由后台线程构建索引文件。

  

效果 :在改成异步后,整体的写入吞吐量大概能提升 20%。

  

蛭侍舛:Kafka 消费能力不足

  

挑战 :社区版本的 Kafka 表,内部默认只会有一个消费者,这样会比较浪费资源并且性能达不到性能要求。

  

尝试优化过程:

  

* 尝试通过增大消费者的个数来增大消费能力,但社区的实现是由一个线程去管理多个的消费者,多个消费者消费到的数据最后仅能由一个输出线程完成数据构建,所以这里没能完全利用上多线程和磁盘的潜力;

  

* 尝试通过创建多张 Kafka Table 和 Materialized View 写入同一张表,但是对于运维会比较麻烦。

  

解决方案支持多线程消费。

  

  

ByteHouse:实时数据分析场景下的优化实践' />   

前面提到的优化手段都不尽如人意,最后决定改造 Kafka Engine

  

在其内部支持多个消费线程,简单来说就是每一个线程它持有一个消费者,然后每一个消费者负责各自的数据解析、数据写入,这样的话就相当于一张表内部同时执行多个的

  

INSERT Query。

  

效果 :通过多线程实现多消费者同时消费写入表,写入性能达到接近于线性的提升。

  

蛭侍馊:出现故障无法保证数据完整性

  

挑战

  

:在主备模式下,如果数据同时两个节点都写入,一旦一个节点出现故障,新启的节点恢复过程中容易出现各种问题,包括性能下降,无法保证分片,最严重可能导致查询结果不正确。

  

解决方案确保主备模式下只会写入一个主备其中一个节点。

  

为了避免两个节点消费这个数据,改进版的 Kafka Engine 参考了 ReplicatedMergeTree 基于 ZooKeeper

  

的选主逻辑。对于每一对副本的一对消费者,会尝试在 ZooKeeper 上完成选主逻辑,确保选举成为主节点的消费者才能消费,另一个节点则会处于一个待机状态。

  

  

ByteHouse:实时数据分析场景下的优化实践' />   

有了这样的单节点消费机制, 系统会检测 ReplicatedMergeTree 表数据是否完整,如果数据不完整则代表不能正常服务,此时消费者会主动出让

  

Leader,让副本节点上成为消费者,也就是新写入的数据并不会写入到缺少数据的节点,对于查询而言,由于查询路由机制的原因也不会把 Query

  

路由到缺少数据的节点上,所以一直能查询到最新的数据。

  

  

ByteHouse:实时数据分析场景下的优化实践' />   

效果 :改进 Kafka engine 确保主备模式下只有一个节点能消费数据,即使出现节点故障在新节点恢复过程中同样保障了解决了数据完整性的问题。

  

# 标题广告投放实时数据

  

第二个典型案例关于广告的投放数据,一般是运营人员需要查看广告投放的实时效果。由于业务的特点,当天产生的数据往往会涉及到多天的数据。这套系统原来基于

  

Druid 实现的,Druid 在这个场景会有一些难点:

  

  

ByteHouse:实时数据分析场景下的优化实践' />   

选择了 ClickHouse 之后能解决 Druid 不足的地方,但还是有部分问题需要解决。

  

蛭侍庖唬Buffer Engine 无法和 ReplicatedMergeTree 一起使用

  

问题 & 挑战:社区提供了 Buffer Engine 为了解决单次写入生成过多 parts 的问题, 但是不太能配合

  

ReplicatedMergeTree 一起工作, 写入不同 Replica 的 Buffer 仅缓存了各自节点上新写入的数据,

  

导致查询会出现不一致的情况。

  

  

ByteHouse:实时数据分析场景下的优化实践' />   

解决方案

  

改进了 Buffer Engine 做了如下的调整和优化:

  

* 我们选择将 Kafka/Buffer/MergeTree 三张表结合起来,提供的接口更加易用;

  

* 把 Buffer 内置到 Kafka engine 内部, 作为 Kafka engine 的选项可以开启/关闭,使用更方便;

  

* Buffer table 内部类似 pipeline 模式处理多个 Block;

  

* 支持了 ReplicatedMergeTree 情况下的查询。

  

首先确保一对副本仅有一个节点在消费,所以一对副本的两个 Buffer

  

表,只有一个节点有数据。如果查询发送到了没有消费的副本,会额外构建一个特殊的查询逻辑,从另一个副本的 Buffer 表里读取数据。

  

  

ByteHouse:实时数据分析场景下的优化实践' />   

效果 :增强 Buffer Engine,解决了Buffer Engine 和 ReplicatedMergeTree

  

同时使用下查询一致性的问题。

  

蛭侍舛:出现宕机后可能会出现数据丢失后者重复消费的情况

  

挑战 :ClickHouse 缺少事务支持。一批次写入只写入部分 part 后出现宕机,因为没有事务保障重启后可能出现丢失或者重复消费的情况。

  

  

ByteHouse:实时数据分析场景下的优化实践' />   

解决方案

  

  

ByteHouse:实时数据分析场景下的优化实践' />   

参考了 Druid 的 KIS 方案自己管理 Kafka Offset,实现单批次消费/写入的原子语义:实现上选择将 Offset 和 Parts

  

数据绑定在一起,增强了消费的稳定性。每次消费时,会默认创建一个事务,由事务负责把 Part 数据和 Offset

  

一同写入磁盘中,如果出现失败,事务会一起回滚 Offset 和写入的 part 然后重新消费。

  

效果 :确保了每次插入数据的原子性,增强了数据消费的稳定性。

  

# 小结

  

实时数据分析是 ClickHouse 的优势场景,结合字节跳动实时数据场景的特点,我们对 ClickHouse 进行了优化和改造,并将这些能力沉淀到了

  

ByteHouse 上。ByteHouse

  

基于自研技术优势和超大规模的使用经验,为企业大数据团队带来新的选择和支持,以应对复杂多变的业务需求,高速增长的数据场景。未来,ByteHouse将不断以字节和外部最佳实践输出行业用户,帮助企业更好地构建交互式大数据分析平台,并更广泛的与

  

ClickHouse 研发者社群共享经验,共同推动 ClickHouse 社区的发展。

  

ByteHouse中文官网:企业级 Clickhouse | 产品 | ByteHouse

  

点击ByteHouse 企业版-火山引擎,即可申请试用~

  

> 近日,火山引擎首度发布限时增长助推计划「火种计划」,助力企业伙伴实现数字化转型,为企业发展增添新引擎、注入新动力。点击「火种计划-火山引擎」,了解更多!

  

  

ByteHouse:实时数据分析场景下的优化实践' />