欧宝买球:B站依据ClickHouse的海量用户行为剖析运用实践
数据驱动理念已被各行各业所熟知，中心环节包含数据搜集、埋点规划、数据建模、数据剖析和方针体系构建。在用户行为数据范畴，对常见的多维数据模型进行信息提炼和模型整合，能够构成一套常见的数据剖析方法来发现用户行为的内在联系，能更好洞悉用户的行为习惯和行为规则，帮忙企业发掘用户数据的商业价值。
行业界最早可追溯到Google Analytics埋点剖析东西，国内较早开端这方面研讨的是百度大数据剖析渠道；跟着15年后国内大数据鼓起，神策的用户行为剖析渠道、GrowthingIO的添加渠道等独立数据剖析渠道公司相继建立；18年后一些展开较快的大厂经过几年数据堆集也有了自己的剖析渠道，例如美团点评的Ocean行为剖析渠道、字节的火山引擎添加剖析渠道等等。
只要当数据抵达必定规划才更合适用科学化的方法来进步数据剖析功率，如前面所述，尽管Google和百度在这块最早探究，但后边一些互联网公司也是过几年才有自己的产品，即数据产品的展开需求与实践数据规划和事务展开相符。B站最早从19年开端重视大数据建造，到现在现已有一套较为老练的数据产品——北极星，能够完结对用户行为数据进行埋点搜集、埋点测验、埋点办理、行为数据剖析等功用。行为数据剖析渠道首要包含下图所列功用模块，本文介绍首要模块原理和相关技能完结。
这个阶段首要使命是功用完结，依据用户前端查询参数，提交Spark Jar作业等候回来成果。不同的剖析模块对应不同的Spark Jar作业，也对应不同加工好的用户行为模型。数据架构如下图所示:
部分模型化：用户维度信息需求提早加工到模型表中，后边不易改动和运维，且前期剖析模型规划不支撑私参查询，即明细数据信息只保存了一部分；
资源自习惯问题：Spark Jar使命每次发动都需求经过YARN独自恳求资源，不同查询条件对应的使命核算杂乱度不同，但使命资源参数固定，一方面资源的恳求和分配就需求花费较长时刻，另一方面不能动态习惯使命杂乱度，就算保护一个常驻内存的 SparkSession供查询使命调用，也无法处理依据查询使命的资源自习惯问题；
并发受限：同一时刻段查询的恳求太多，后边恳求一向会等候前面恳求对应Spark使命开释所占用资源，且资源未阻隔，会影响其他正常ADHOC查询。
在实践运用中核算时刻太长，单事情剖析需求超越3分钟回来成果，漏斗和途径剖析需求超越30分钟回来成果，导致产品可用性极低，查询安稳性和成功率不是很高，运用人数不是许多。这个阶段的埋点办理和上报格局未彻底标准化，所以要点仍是做后者。
ClickHouse是Yandex公司于2016年开源的一个列式数据库办理体系。Yandex的中心产品是查找引擎，十分依靠流量和在线广告事务，因而ClickHouse天生就合适用户流量剖析。B站于2020年开端引进ClickHouse，结合北极星行为剖析场景进行重构，如下图所示：
这儿直接从原始数据开端消费，经过Flink清洗使命将数据直接洗入ClickHouse生成用户行为明细，能够称作无模型化明细数据。Redis维表被用来做实时用户特点相关，字典服务被用于把String类型的实体ID转成Bigint，运用ClickHouse原生的RoaringBitMap函数对参加核算的行为人并差集核算。这一代完结了实时埋点作用检查，上线以来北极星产品周活人数进步了300%以上，相关于前代，功用有较大进步：
查询速度极大进步：90%事情剖析查询能够在5秒内回来查询成果，90%的漏斗查询能够在30S内回来查询成果，速度进步抵达98%以上；
实时性查询：能够对当天实时的用户行为数据进行剖析，极大的添加了用户获取剖析成果的及时性
但自身这种功用进步是以资源耗费为条件的。以移动端日志为例，FLink消费使命峰值能够抵达百万条每秒，对Redis维表相关和字典服务处理应战很大，核算并发度乃至抵达1200core，遇到特别流量事情往往呈现堆积、推迟、断流，对人工运维本钱耗费也较大。此外这种Lambda数据流架构，实时和离线清洗逻辑需求保持一致，不然很简略导致数据解说本钱进步。别的自身实时+离线保护两套对存储上也是极大糟蹋，即Kafka、Hive、CK都需求存储同一份数据。到21年末，跟着事务展开CK存储几经横向扩大剩下不到10%，而集群的扩展和数据搬家也需求较大精力，本文后边小节会详细介绍。功用方面，直接对明细数据运用原生CK函数查询的跨天留存剖析、途径剖析需求用时分钟级，体会不是很好。
22年开端公司大力推进降本增效，这就要求以尽或许少的资源最大化行为剖析产品效能。全体中心思路是全模型化聚合加快，底层流量数据链路走kappa架构，不会再用北极星运用数据和流量表不一致的状况，数据小时级产出。这次改造实时资源能够节约1400core，节约Redis内存400G、节约Kafka300 Partiton。每天数据量由千亿数据下降为百亿，经过特定的sharding方法合作下推参数，运用分区、主键、索引等手法支撑事情剖析(均匀查询耗时2.77s)、事情兼并去重剖析(均匀查询耗时1.65s)、单用户细查(均匀查询耗时16.2s)、漏斗剖析(均匀查询耗时0.58s)，留存剖析和途径剖析从分钟级查询到10s内相应。数据架构如图所示：
全模型聚合：21年中开端咱们就规划了一款通用流量聚合模型，能够认为是全信息的hive流量模型结构，除了把时刻维度退化外其他信息根本能完好保存，本来千亿级的量级能够紧缩为百亿内
BulkLoad出仓：数据按文件批次从HDFS导入到ClickHouse，千亿等级的数据一小时内能够导完，其原理后文会有介绍
字典服务晋级：咱们经过加强版的snowflake+redis+公司自研rockdbKV存储，大大增强了字典服务功用，压测可支撑40万QPS
用户特点现算形式：不再选用预核算形式，而是经过咱们另一套依据CK的标签渠道所生成的指定用户标签人群跨集群相关现算，这样能够灵敏指定想要剖析的用户特点
到22年中，跟着数据湖的鼓起，咱们将hive流量聚合模型搬家到Iceberg上，日常事情查询能够在10s内完结，能够作为CK数据的备用链路。这条链路不但下降了紧急事情运维本钱，进步数据可用性确保，还能够支撑用户日常流量相关其他事务定制化查询取数。通用的模型结构除了支撑流量行为日志外，经过映射办理能够快速接入其他服务端日志，扩展其运用的场景。下图为22年12月份最近一周各功用模块运用状况：
从展开进程来看，用户行为数据剖析阅历了从强离线引擎驱动到强OLAP驱动，离不开业界大数据技能不断展开和前进，北极星行为数据底层明细后边也会切换到Hudi，能够满意愈加实时的数据消费，让专业的东西做专业的事。
事情剖析是指对详细的行为事情进行相关方针核算、特点分组、运算、条件挑选等操作，本质上是剖析埋点事情的用户触发状况以及埋点事情的剖析核算状况。留存剖析能够依据事务场景以及产品阶段的不同，自定义开端行为和后续行为做留存核算，帮忙剖析用户运用产品的粘性，依据留存剖析成果有针对性地调整战略，引导用户发现产品价值，留住用户，完结用户实在的添加。
曩昔北极星剖析渠道的剖析模块大多以B站的千亿明细行为数据为根底，经过ClickHouse查询引擎的方针函数例如uniq()，能够支撑单个事情剖析、多个事情的比照剖析以及多个事情的复合方针运算，支撑指定时刻内的行为留存剖析(参加后续行为的用户占参加初始行为用户的比值)，经过挑选、分组等组件满意多样化剖析需求。可是曩昔的北极星事情剖析是依据明细数据，B站行为数据每天增量千亿等级，存储日增10T以上资源耗费巨大，明细数据剖析查询比较慢，每天用户慢查询均匀30s～50s体会较差，而且其功用比较单薄，只能支撑30天的查询窗口，用户留存、用户分群等杂乱剖析模块很难完结。而且海量行为数据剖析也面临许多应战，每天千亿行为数据，顶峰期写入QPS百万以上。怎么完结既满意时效性又满意海量数据压力的核算方法？怎么满意杂乱剖析场景的一起，紧缩存储进步查询功率？怎么简化数据链路，模块化插件化下降接入本钱，进步扩展性？怎么打通标签、ABTest等其他事务体系将北极星的行为剖析才能标准化？
为了处理以上痛点和海量数据剖析的应战，新的事情、留存剖析经过准实时方法建模分层，用户、事情、时刻等粒度的预聚合紧缩，不只一致了离线口径，而且自研拉宽会聚spark脚本能够承载千亿数据压力，调配多种聚合模型完结丰厚的剖析模块。一起开释实时资源离线小时使命确保时效性，维表压力选用join离线维表+特点字典维度服务的方法处理，而且早于渠道自研可指定shard的BulkLoad出仓东西，合作下推参数可加快查询，数据链路可扩展易运维。比较较以往的处理千亿明细数据，准实时在DWB层完结了对数据的紧缩，将每天千亿数据紧缩到每天百亿等级。OLAP层也经过汇总后的数据代替了原先的明细数据，大大缩小存储的一起也进步了查询功用，每天用户慢查询可降到10s以内，时刻窗口可扩大到45天乃至更长。而且对高杂乱的查询比方用户留存，用户分群等剖析场景能够更好的支撑。
1.流量聚合模型创立。首要准实时清洗DWD层B站千亿明细行为数据，流量数据都是分为私有参数和公有参数，其间公有参数在用户粒度下是不会常常改动的，咱们会用一般聚合函数取必定时刻内指定设备和行为事情下最新保存的不变公有参数，而将平等粒度下改变比较频频的私有参数维度名写入Array结构，运用map索引原理，把私参维度值组合经过spark自定义逻辑计数并入map的key中，map的value则用来写入各种公共方针聚合成果，整个进程均经过spark脚本完结，终究写入到Iceberg引擎中。因为Iceberg能够相关其他任何已有hive表，经过快速事务表相关也能够支撑到其他多项事务运用，也能够作为不出仓的北极星降级备用方案支撑大部分查询剖析功用。
4.流量聚合模型在ClickHouse下查询。在ClickHouse查询上规划特定的CK-UDF来解析嵌套map结构，确保杂乱剖析场景的一起用于加快了查询，比较用ClickHouse原生多个函数组合解析要快30%左右，比原先明细模型的查询要快更多。而且经过脚本完结了多维度的ClickHouse小时等级的机器人监控告警，早于渠道对此定制化监控告警的支撑。
现在北极星剖析渠道均匀查询耗时3.4s，经过通用聚合模型，下流能够对行为人群进行交并核算完结标签画像和人群圈选等转化剖析功用，也能够运用Retention函数完结了N日的事情留存剖析。终究比较前代方案节约核算资源1400C、节约存储资源40%，进步查询功率60%以上，运用RBM完结了北极星、标签、ABTest等多事务打通。
流量事务剖析场景上会检查一群用户在客户端或许网页上的途径流通信息，途径剖析将用户在产品中的运用途径用桑吉图呈现，展示用户在页面与页面流通中的流量走向。经过途径剖析能够帮忙验证产品运营战略，优化产品规划思路。漏斗是用户在产品运用中完结的一系列行为转化。漏斗剖析能够帮忙了解用户在行为进程中的转化或丢掉状况，然后经过优化产品或许展开运营活动进步转化率，到达事务方针。
在事务日益添加的状况下，对用户漏斗、途径精细化剖析诉求逐步添加，为此北极星剖析渠道添加此类型支撑，用于剖析一群用户在某一页面、某一模块前后的流量流通改变。漏斗剖析业界常见处理此类场景运用ClickHouse供给了一个名叫windowFunnel的函数来完结对明细数据的漏斗剖析。而途径剖析技能一般分为两种，一种为明细数据结合sequenceCount(pattern)(timestamp, cond1, cond2, ...)做简略的途径剖析，而杂乱的途径剖析又名智能途径剖析能够经过ClickHouse供给的高阶数组函数进行曲线救国。
可是曩昔的流量漏斗、途径剖析都是依据明细数据进行的。存储资源耗费大、剖析查询慢、功用比较单薄等。为了处理以上痛点，新的漏斗、途径剖析经过离线方法的建模分层、用户途径粒度的预聚合、存储引擎ClickHouse的RBM物化视图等技能，将每天千亿数据紧缩到每天几十亿。查询功率也从分钟级优化到秒级，更是经过相关标签和人群支撑到了各种转化查询剖析。大大缩小存储的一起查询功用大大进步，终究完结了相关标签和人群圈选等功用。
1.途径聚合DWB模型创立。首要离线处理B站的千亿明细行为数据，经过维度裁剪改变比较频频的私有参数，保存用户粒度下的公有参数，而且经过buvid(设备id)粒度进行聚合，将同一个buvid的一切事情依据时刻线串联聚合到一个字段中，聚合之后的数据构成DWB层落地到hive表。
2.途径聚合DWS模型创立。在上一步的根底上，对DWB层的数据进行途径的汇总，将同一个途径的buvid(设备id)汇总聚合到数组结构中，这个进程呈现许多搅扰事情，比方某些途径会频频呈现，会乱序而搅扰真实的用户行为，所以咱们会经曩昔重等手法进行搅扰事情过滤途径补位拼接构成桑基图节点，当然咱们还引进了RBM数据结构存储聚合后的设备编码，终究落到hive表。整个进程都是经过spark脚本运用代码和算法完结的。
3.途径聚合模型Clickhouse表规划。接下来咱们运用渠道东西将hive数据出仓到ClickHouse，在ClickHouse表结构规划上，选用了ClickHouse的物化视图技能和RBM数据结构，进一步紧缩buvid(设备id)集合为RBM编码，运用数组物化RBM的方法大大紧缩了存储，可经过Bitmap交并核算途径相关方针，千亿数据紧缩到几十亿做到了秒级查询。
4.途径聚合模型漏斗剖析查询。在功用上漏斗剖析经过windowFunnel函数进行核算，将核算周期内每个用户的行为明细按时刻次序聚合为对应事情链，然后查找滑动时刻窗口满意漏斗条件的事情链，并核算从链中发生的最大事情数level，终究对各级level核算uv取得成果。
在树型图中的对应联系：表明途径e0->
e4→e1→e3→e2在窗口期内的总uv为1。左边同理，方向相反。
5.途径聚合模型途径剖析查询。同理途径剖析在ClickHouse数据根底上运用数据协议和杂乱sql制作出途径树状图然后拼接出桑基图，可直观的展示用户干流流程，帮忙确认转化漏斗中的关键进程，敏捷发现被用户疏忽的产品价值点，批改价值点曝光方法并发现用户的丢掉点，一起经过Bitmap的交并核算完结了标签画像和人群圈选等转化剖析功用。
B站的北极星行为剖析渠道、标签画像渠道、AB试验人群包都是依据ClickHouse的RBM(RoaringBitMap)完结，此外RBM还有其他多项运用，比方事情剖析标签人群圈选、预核算的途径剖析、创立用户行为的用户分群等，详细可检查之前文章[1]。
RBM当然好用，可是只支撑int或许long类型，假如去重字段不是int或许long怎么办呢？海量数据运用层的维度服务怎么做到高可用高并发？依靠的链路出问题怎么快速康复，数据怎么确保？
特点字典维度服务便是可解码编码多事务特点、可输出办理多事务维度，具有散布式、高可用、高并发等特性的服务体系，经过特点字典维度服务可完结多维度办理多事务打通，为海量数据运用层定制化供给技能支撑。
高可用方面Grpc+LoadCache+Redis+公司自研rockdbKV存储，多级缓存散布式架构支撑滑润扩容和翻滚发布，可做到日常缓存命中率70%以上，底层ID生成算法依据Leaf-SnowFlake快速生成，压测可支撑50w以上QPS高并发。一切恳求经过公司的日志传输通道能够小时级同步到hive做备份，事端状况下合作BulkLoad读写别离可40分钟内康复20亿+特点字典。
终究运用特点字典对buvid(设备id)等事务特点编码和解码，对用户标签和AB人群进行创立，而且经过RBM交并核算完结了北极星剖析渠道、用户画像渠道、AB试验渠道的多事务打通。
如上文所述，北极星是依据ClickHouse构建的一套海量UBA技能处理方案，底层ClickHouse集群的安稳性 、读写功用、资源运用率均会影响上层事务的运用体会。与此一起，海量数据怎么导入ClickHouse，以及数据导入进程的安稳性、导入功率、资源耗费在很大程度上决议了ClickHouse集群的全体安稳性和运用功率。所以，一个安稳高效的数据导入方案关于一套UBA处理方案来说是必不可少的。
在B站内部，针对数据写入到各个数据库/引擎首要有两套pipeline：一套是依据Spark的离线导入链路，大部分数据来源于Hive；另一套是依据FLink的实时导入链路，大部分数据源来源于kafka。这两套链路都支撑clickhouse作为data sink，UBA场景最开端也是依据这两套链路来做数据导入的，首要运用的是实时导入链路，在历史数据初始导入和毛病补数等少数状况下也用到离线导入链路。
如上图所示，离线和实时导入终究都运用ClickHouse JDBC向ClickHouse发送数据，这种写入方法完结起来比较简略，运用开源的ClickHouse JDBC Driver就能够运用标准JDBC接口向ClickHouse写入数据。一起，flink实时写入的数据推迟比较低，端到端推迟可操控在秒级。但这个方案存在以下问题：
ClickHouse Server端的资源耗费比较大（因为数据的排序，索引生成，数据紧缩等进程均是在server端完结），在顶峰时会影响查询功用。
实时使命写入频次较高，数据会在写入后触发许多merge操作，形成“写扩大”，耗费更多的磁盘IO和CPU资源，或许导致too many parts过错。
实时Flink使命需求长时刻占用许多资源，且在毛病状况下简略呈现数据堆积、推迟、断流等问题，运维本钱较高。
以上问题在资源充分的状况下不会影响事务运用，但当集群资源挨近瓶颈时，查询功用受写入影响，写入功用和安稳性受merge影响，终究导致集群全体安稳性下降，影响事务运用。
UBA场景的多个剖析模块对数据推迟要求不尽相同，大部分数据实时性要求并不高，小时级推迟在大部分模块下是可接受的。因而，为了处理上述JDBC写入方案的问题，咱们针对大部分对时效性要求不高的数据导入需求，构建了一套依据中心存储的BulkLoad导入方案：
首要，将clickhouse格局的data part文件的生成进程转移到Spark Application中完结，这样就能够运用Yarn集群的资源来完结数据排序，索引生成，数据紧缩等进程。
因为Bulkload导入将数据写入data part文件这个进程移到了Spark端履行，大大下降了ClickHouse Server数据写入对资源的耗费。与此一起，因为在Spark端数据批量写入之前现已完结了repartition和攒批，抵达ClickHouse Server的data part数量相较JDBC写入要少许多，所以clickhouse的merge压力也大幅下降。该方案上线后，数据写入对clickhouse查询的影响根本消除，集群安稳性得到大幅进步。
以HDFS作为文件传输的中心存储，添加了数据传输的耗时和网络开支，一起会占用HDFS的存储资源。
DataReceive服务答应运用HTTP客户端直接将数据文件发送到ClickHouse，ClickHouse端会进行鉴权、数据校验、流量操控、并发操控、磁盘负载均衡等操作。该方案相较于依据HDFS中心存储的Bulkload方案，大致有一倍的功用进步。
B站每天的用户行为数据量达数千亿行，UBA场景需求剖析最近半年以上的历史数据，所以底层ClickHouse需求存储PB级的已紧缩数据。一起，跟着B站活泼用户日益添加，需求存储的数据量也在不断添加，所以集群扩容的需求是必不可少的。
但是，因为受限于存算一体的架构规划，ClickHouse集群现在无法做到弹性扩容，数据需求在新集群中完结重分配。因而，ClickHouse怎么高效安稳地完结数据重平衡（Data Rebalance）是ClickHouse集群办理人员有必要面临和处理的的问题。
咱们在UBA场景集群扩容的预备和施行进程中，阅历了从手动化，到半自动化，再到服务化的演进。在此期间，咱们将在海量数据重平衡实践进程中遇到的问题与处理方法转化成为了一套自动化东西服务。下面，咱们就来介绍一下这套东西服务的功用与完结原理。
集群中表的巨细差异很大，有些抵达几百TB, 有些只要几GB，怎么衡量数据的平衡程度，挑选出需求平衡的表？咱们引进了一些数学公式来处理这个问题。
变异系数：当需求比较两组数据离散程度巨细的时分，假如两组数据的丈量标准相差太大，或许数据量纲的不同，直接运用标准差来进行比较不合适，此刻就应当消除丈量标准和量纲的影响，而变异系数能够做到这一点，它是原始数据标准差与原始数据均匀数的比，取值规模0~1，值越小，离散程度越小。
关于待平衡的表，有些事务希望最大程度的平衡，进步并行度，发挥集群的最大算力，而有些表容量过大，事务希望以最小的搬家本钱，快速平衡数据，抵达相对较优的平衡。
希望抵达极致的均衡，数据量较小时，引荐运用装箱算法。希望以最小的搬家本钱，抵达较优的均衡，引荐运用贪心算法。
算法全体选用Best Fit(最优装箱算法) + AVL树的规划。每个ClickHouse节点即为一个Node，每个Node有初始阈值capacity，代表ClickHouse节点的包容量。将预备平衡的part依照巨细次序排序，并依据Best Fit算法顺次填充到Node中，Node依据remain_capacity(剩下容量)，左旋右旋组成一棵AVL树，以此进步查询功率，便利快速完结平衡。
算法全体选用不断轮询 + 部分最优的规划。将ClickHouse节点依照巨细排序，找出最大和最小的节点，假如将某个part从最大的节点搬家至最小的节点，迁出的节点依然大于迁入节点，则搬家该part，直到最大节点无法迁出。依此类推，持续依照巨细排序ClickHouse节点，每次找到最大最小节点，平衡part至部分最优，直到轮询ClickHouse节点完毕。
依据平衡算法，能够得出集群中节点方案的迁入、迁出状况。平衡单位为表等级，搬家粒度到part，能够理解为表内部part平衡。
如下图所示，能够看到表平衡前后的平衡度，以及节点1方案的迁入、迁出状况。平衡方案生成完结后，能够依据需求挑选履行特定的平衡方案。
在履行平衡方案的进程中，怎么精确、高效地将part迁入和迁出？怎么确保原子性，防止数据呈现丢掉或重复的问题？怎么限流，防止因平衡占用过多的资源，影响集群的安稳性？
平衡期间关于不同阶段的反常，添加了相应的重试和回滚机制，以此来掩盖网络颤动、zookeeper重衔接等问题，然后确保了平衡的原子性，数据一致性。
平衡期间经过限流装备(max_replicated_fetches_network_bandwidth)，来操控平衡速度，确保了集群的安稳性，防止影响其他事务的正常查询。
在支撑UBA场景各项功用模块的进程中，咱们针对ClickHouse的查询，存储等方面做了许多运用优化作业。下面选取其间几个优化点做简略介绍。
ClickHouse中的针对散布式表的查询会被改写成对local表的查询并发送到集群各个shard履行，然后将各个shard的中心核算成果搜集到查询节点做兼并。当中心核算成果很大时，比方countDistinct、 windowFunnel函数等，查询节点的数据搜集和数据兼并或许成为整个查询的功用瓶颈。
查询下推的思路便是尽量将核算都下推到各个shard履行，查询节点仅搜集兼并少数的终究核算成果。不过，也不是一切查询都合适做下推优化，满意以下两个条件的查询能够考虑做下推优化：
数据现已依照核算需求做好sharding：比方，UBA场景的数据已按user id做好了sharding，所以针对用户的漏斗剖析，UV等核算能够下推到各个shard履行。不然，下推后的核算成果是不精确的。
核算的中心成果较大：sum，count等核算是无需下推的，因为其间间成果很小，兼并核算很简略，下推并不能带来功用进步。
上图是用windowFunnel函数完结漏斗剖析的一个SQL，如图中“履行进程”所示，该查询需求从各shard搜集许多数据并在查询节点完结核算，会发生许多数据传输和单点核算量。
优化SQL-V1将windowFunnel的核算下推到各个shard履行，仅在查询节点对windowFunnel的终究成果做聚合核算。在咱们的场景下，该版别较上一版别功用进步了5倍以上。
为了更进一步做查询下推，咱们运用cluster + view的函数组合，将聚合查询进一步下推：
UBA场景中的事情数据有许多公共特点和私有特点，公共特点被规划为表的固定字段，而私有特点因为各个事情不尽相同，所以选用Array/Map来存储。开始的规划是选用两个数组别离存储特点名和特点值，ClickHouse支撑Map结构后，则在后续模块中选用Map来满意相似需求。无论是Array仍是Map，开始都不支撑创立跳数索引，所以在其他索引字段过滤作用有限的状况下，针对Array和Map的操作或许会成为查询的功用瓶颈。
针对这个问题，咱们给Array和Map加上了Bloom filter等跳数索引支撑，针对Map仅对其key构建索引。在某些呈现频率较低的私有特点过滤场景下，Array/Map的跳数索引能够收成数倍的功用进步。
ClickHouse常用的数据紧缩方法有三种，别离为LZ4、LZ4HC以及ZSTD。针对不同的数据类型，数据散布方法来运用特定的编码方法能够大大进步数据紧缩率，以削减存储本钱。
针对UBA场景，咱们测验了不同紧缩算法的紧缩率，写入功用，查询功用。相较默许的LZ4，ZSTD(1)在紧缩率上遍及能够节约30%以上的存储空间，查询功用方面未见显着差异，不过写入功用在某些场景下有20%左右的下降。因为UBA场景数据存储压力较大，一起对数据时效性要求不是很高，因而咱们终究挑选了ZSTD(1)作为首要的紧缩方法。
UBA场景的泛化形状实践是人+内容+行为，例如用户能够在观看场景产出弹幕行为或许点赞行为，这类数据不同于传统的SDK日志数据具有通用的埋点格局，但咱们能够经过笼统映射到通用行为聚合模型上来，来完结对服务端日志的行为剖析。现在咱们正在对社区服务端日志和其他非埋点标准的事务SDK日志进行泛化支撑，尽或许复用已有才能进步用户查询和剖析功率。
在UBA场景下，同一张表或许在多个模块中运用到，比方，用户行为事情数据在事情剖析等剖析模块中运用，一起在单用户行为明细查询中会运用到。这两种运用场景下对表的查询是依据不同过滤维度的，但clickhouse现在的主键索引很难一起对多个维度过滤都有较好过滤作用，因而很难一起满意多个场景下的查询功用要求。咱们现已完结了ZOrder索引的开发，现在正在开发相应的编码类型，使得UBA场景下的数据能够运用ZOrder index一起支撑多个维度的高效查询。
