干货 | 小米A/B实验场景查询提速：数据预聚合方案

最新推荐文章于 2024-06-16 01:07:28 发布
最新推荐文章于 2024-06-16 01:07:28 发布
阅读量516 收藏
点赞数
原文链接：https://mp.weixin.qq.com/s?__biz=MzUxMDQxMDMyNg==&mid=2247496241&idx=1&sn=7fdac15f6927a88cb961b43f8636a55d&chksm=f901d908ce76501e80dc7e0f92956974c6837485d6b65a6bbde00dd99140bc44834a01bf4df1&scene=126&&sessionid=0
版权
本文分享了小米A/B实验平台在使用Apache Doris时面临的查询性能问题及解决方案。通过数据现状分析，发现查询基于明细数据、字段查询热度分层、实验组ID匹配效率低和进组人数计算等问题。针对这些问题，提出了预聚合处理、选取高频使用维度、精确匹配实验组ID和使用BITMAP去重计算进组人数的优化策略，显著提升了查询效率和集群资源利用率。
摘要由CSDN通过智能技术生成

“

本期技术干货，我们邀请到了小米集团大数据工程师乐涛，和大家分享基于Apache Doris的小米A/B实验场景查询提速实践。

”

一、业务背景

A/B实验是互联网场景中对比策略优劣的重要手段。为了验证一个新策略的效果，需要准备原策略A和新策略B两种方案。随后在总体用户中取出一小部分，将这部分用户完全随机地分在两个组中，使两组用户在统计角度无差别。

将原策略A和新策略B分别展示给不同的用户组，一段时间后，结合统计方法分析数据，得到两种策略生效后指标的变化结果，并以此判断新策略B是否符合预期。

6cb746c8f0da07c111ad3220b08e32ac.png

小米A/B实验平台是一款通过A/B实验的方式，借助实验分组、流量拆分与科学评估来辅助完成科学的业务决策，最终实现业务增长的一款运营工具产品。其广泛的应用于产品研发生命周期中各个环节：

角色

场景

产品

产品功能迭代、用户路径设计、UI&交互优化

运营

运营活动优化：落地页、素材...

推送方案择优：推送时机、文案...

研发

推荐算法优化、排序算法优化...

本文主要从数据的角度分析A/B实验场景查询的性能现状，探讨一下性能优化的解决方案。

二、数据平台架构

A/B实验平台的架构如下图所示：

73f1c0aa7cf0b8dc295fbf3e05b194b4.png

  • 平台使用的数据主要包含平台自用的实验配置数据、元数据，以及业务方上报的日志数据。

  • 由于业务方引入SDK，并与分流服务进行交互，日志数据中包含其参与的实验组ID信息。

  • 用户在实验平台上配置、分析、查询，以获得报告结论满足业务诉求。

鉴于AB实验报告各个业务方上报数据的链路都大体类似，我们就拿头部业务方广告业务举例，数据流程如下图所示：

62582c09af4d5f8eefffe7dda2afb709.png

整个数据链路并不复杂，日志数据传入后，经过必要的数据处理和清洗工作进入Talos（小米自研消息队列），通过Flink任务以明细数据的形式实时写入到Doris表中，同时Talos数据也会同步到Hive表进行备份，以便问题排查和数据修复。

出于对高效写入以及字段增减需求的考虑，Doris明细表以Duplicate模型来建模：

CREATE TABLE `dwd_xxxxxx` (
  `olap_date` int(11) NULL COMMENT "分区日期",
  `user_id` varchar(256) NULL COMMENT "用户id",
  `exp_id` varchar(512) NULL COMMENT "实验组ID",
  `dimension1` varchar(256) NULL COMMENT "",
  `dimension2` varchar(256) NULL COMMENT "",
  ......
  `dimensionN` bigint(20) NULL COMMENT "",
  `index1` decimal(20, 3) NULL COMMENT "",
  ......
  `indexN` int(11) NULL COMMENT "",


) ENGINE=OLAP
DUPLICATE KEY(`olap_date`, `user_id`)
COMMENT "OLAP"
PARTITION BY RANGE(`olap_date`)
(
PARTITION p20221101 VALUES [("20221101"), ("20221102")),
PARTITION p20221102 VALUES [("20221102"), ("20221103")),
PARTITION p20221103 VALUES [("20221103"), ("20221104"))
)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 300
；

三、数据现状分析

在提速之前，小米A/B实验平台完成实验报告查询的P95时间为小时级，实验报告使用数据的方式存在诸多的性能问题，直接影响业务部门做运营和决策的效率。

>>>>  3.1 报告查询基于明细

当前报告查询的数据来源为明细表，而明细表的数据量巨大：

单日记录数量级

单日存储量级(Doris replication_num=3)

字段数量

十亿级

TB级别

百余个

而且，实验报告的查询条件中时间范围常常横跨多天。基于历史查询报告统计，查询条件中时间范围大于一天的报告占比69.1%，具体的时间跨度占比分布如下：

e9beb64dea0f8b3f0aedf851abdac2a8.png

明细数据的巨大扫描量给集群带来了不小的压力，且由于报告查询存在并发以及SQL的拆分，如果一个SQL请求不能快速的返回结果释放资源，也会影响到请求的排队状况。

因此在工作时间段内Doris集群BE节点CPU负载状况基本是持续满载，磁盘IO也持续处于高负荷状态，如下图所示：

7fdc2a288ace95a05d3bc99d9008d4ba.png

BE节点CPU使用率

780431b21594a7bffeeab7d251c931cf.png

BE节点磁盘IO

个人思考：

  • 当前报告所有查询基于明细数据，且平均查询时间跨度为4天，查询扫描数据量上百亿。由于扫描数据量级大，计算成本高，给集群造成较大压力，导致数据查询效率不高。

  • 如果通过对数据进行预聚合处理，控制Scan Rows和Scan Bytes，减小集群的压力，查询性能会大幅提升。

>>>>  3.2 字段查询热度分层分布

由于之前流程管控机制相对宽松，用户添加的埋点字段都会进入到明细表中，导致字段冗余较多。统计历史查询报告发现，明细表中常用的维度和指标只集中在部分字段，且查询热度分层分布：

维度字段名

使用次数

exp_id

4000+

维度1

维度2

维度3

维度4

维度5

维度6

维度7

1000-4000

维度8

维度9‍

维度10‍

维度11

维度12

小于1000

维度13

其余11个维度字段

0a1f0a8bd7f3249e24d35ddf2d84f385.png

参与计算的指标也集中在部分字段，且大部分都是聚合计算(sum)或可以转化为聚合计算(avg)：

字段名算子‍使用次数
指标1sum‍1000+
指标2sum
指标3sum
指标4sum
指标5avg(sum/cnt)
指标6sum
指标7sum
指标8avg(sum/cnt)
指标9sum
指标10sum
指标11sum
指标12avg(sum/cnt)
指标13uniq_user_avg(sum/count(distinct user_id))

个人思考：

  • 明细表中参与使用的维度只占54.3%，高频使用的维度只占15.2%，维度查询频次分层分布。

  • 数据聚合需要对明细表中维度字段做取舍，选择部分维度进行上卷从而达到合并的目的，但舍弃部分字段必然会影响聚合数据对查询请求的覆盖情况。而维度查询频次分层分布的场景非常适合根据维度字段的热度做不同层次的数据聚合，同时兼顾聚合表的聚合程度和覆盖率。

>>>>  3.3 实验组ID匹配效率低

当前明细数据的格式为：

810aadc309a74e7a22ac3ad3e916f317.png

明细数据中的实验组ID以逗号分隔的字符串形式聚拢在一个字段中，而实验报告的每条查询语句都会使用到exp_id过滤，查询数据时使用LIKE方式匹配，查询效率低下。

个人思考：

  • 将实验组ID建模成一个单独的维度，可使用完全匹配代替LIKE查询，且可利用到Doris索引，提高数据查询效率。

  • 将逗号分隔的实验组ID直接打平会引起数据量的急剧膨胀，因此需要设计合理的方案，同时兼顾到数据量和查询效率。

>>>>  3.4 进组人数计算有待改进

进组人数查询是实验报告的必查指标，因此其查询速度很大程度上影响实验报告的整体查询效率，当前主要问题如下：

  • 当进组人数作为独立指标计算时，使用近似计算函数APPROX_COUNT_DISTINCT处理，是通过牺牲准确性的方式提升查询效率。

  • 当进组人数作为复合指标的分母进行计算时，使用COUNT DISTINCT处理，此方式在大数据量计算场景效率较低。

个人思考：

  • AB实验报告的数据结论会影响到用户决策，牺牲准确性的方式提升查询效率是不可取的，特别是广告这类涉及金钱和业绩的业务场合，用户不可能接受近似结果。

  • 进组人数使用的COUNT DISTINCT计算需要依赖明细信息，这也是之前查询基于明细数据的重要因素。必须为此类场景设计新的方案，使进组人数的计算在保证数据准确的前提下提高效率。

四、数据优化方案

基于以上的数据现状，我们优化的核心点是将明细数据预聚合处理，通过压缩数据来控制Doris查询的Scan Rows和Scan Bytes。与此同时，使聚合数据尽可能多的覆盖报告查询。从而达到，减小集群的压力，提高查询效率的目的。

新的数据流程如下图所示：

47ccca0fdcad397baed48143d37c039d.png

整个流程在明细链路的基础上增加聚合链路，Talos数据一方面写入Doris明细表，另一方面增量落盘到Iceberg表中，Iceberg表同时用作回溯明细数据以及生成聚合数据。我们通过工场Alpha（小米自研数据开发平台）的实时集成和离线集成保证任务的稳定运行和数据的一致性。

>>>>  4.1 选取高频使用维度聚合

在生成数据聚合的过程中，聚合程度与请求覆盖率是负相关的。使用的维度越少，能覆盖的请求就越少，但数据聚合程度越高；使用的维度越多，覆盖的请求也越多，但数据粒度就越细，聚合程度也越低。因此需要在聚合表建模的过程中取得一个平衡。

我们的具体做法是：拉取历史（近半年）查询日志进行分析，根据维度字段的使用频次排序确认进入聚合表的优先级。在此基础上得出聚合表的覆盖率和数据量随着建模字段增加而变化的曲线，如下图所示：

d3dce42c98555f6702f227d316da3795.png

其中覆盖率根据历史请求日志代入聚合表计算得出。

我们的原则是：针对OLAP查询，聚合表的数据量应尽可能的控制在单日1亿条以内，请求覆盖率尽可能达到80%以上。因此不难得出结论：选择14个维度字段对聚合表建模比较理想，数据量能控制到单日8千万条左右，且请求覆盖率约为83%。

>>>>  4.2 使用物化视图

在分析报告历史查询日志时，我们发现不同的维度字段查询频次有明显的分层：

聚合表维度使用此维度的报告占比
exp_id100%
维度1100%
维度299.29%
维度399.29%
维度499.12%
维度598.98%
维度698.67%
维度735.63%
维度835.63%
维度926.78%
维度1023.66%
维度1115.23%
维度122.31%
维度132.19%

Top7维度字段几乎出现在所有报告的查询条件之中，对于如此高频的查询，值得做进一步的投入，使查询效率尽可能的提升到最佳。

Doris的物化视图能够很好的服务于此类场景。

▍什么是物化视图？

物化视图是一种特殊的物理表，其中保存基于基表(base table)部分字段进一步上卷聚合的结果。

虽然在物理上独立存储，但它是对用户透明的。为一张基表配置好物化视图之后，不需要为其写入和查询做任何额外的工作：

  • 当向基表写入和更新数据时，集群会自动同步到物化视图，并通过事务方式保证数据一致性。

  • 当对基表进行查询时，集群会自动判断是否路由到物化视图获取结果。当查询字段能被物化视图完全覆盖时，会优先使用物化视图。

因此我们的查询路由如下图所示：

5563eaeb4804c97fe7f9ce9d798a7551.png

用户的查询请求会尽可能的路由到聚合表物化视图，然后是聚合表基表，最后才是明细表。如此使用多梯度的聚合模型的配合来应对热度分层的查询请求，使聚合数据的效能尽可能的发挥到最大。

>>>>  4.3 精确匹配取代LIKE查询

既然物化视图这么好用，为什么我们不是基于Doris明细表配置物化视图，而是单独开发聚合表呢？

是因为明细数据中的实验组ID字段存储和查询方式并不合理，聚合数据并不适合通过明细数据直接上卷来得到。3.3节已经提到，exp_id（实验组ID）在明细表中以逗号分隔的字符串进行存储，查询数据时使用LIKE方式匹配。作为AB实验报告查询的必查条件，这种查询方式无疑是低效的。

我们希望的聚合方式如下图所示：

dd614a6d8742de9b48e00e87df406fa1.png

我们需要将exp_id字段拆开，把数据打平，使用精确匹配来取代LIKE查询，提高查询的效率。

▍控制聚合表数据量

如果只做拆分打平的处理必然会导致数据量的激增，未必能达到正向优化的效果，因此我们还需要想办法来压缩exp_id打平后的数据量：

  1. 聚合表选取维度字段建模的时候，除了4.1节提到的，以字段的使用频次热度作为依据之外，也要关注字段的取值基数，进行综合取舍。如果取值基数过高的维度字段进入聚合表，必然会对控制聚合表的数据量造成阻碍。因此，我们在保证聚合表请求覆盖量的前提下，酌情舍弃部分高基数（取值有十万种以上）的维度。

  2. 从业务的角度尽可能过滤无效数据（比如一个实验组的流量为0%或者100%，业务上就没有对照的意义，用户也不会去查，这样的数据就不需要进入聚合表）。

经过这一系列步骤，最终聚合表的数据量被控制在单日约8000万条，并没有因为exp_id打平而膨胀。

值得一提的是，exp_id字段拆分后，除了查询从LIKE匹配变为精确匹配，还额外带来了两项收益：

  • 字段从String类型变为Int类型，作为查询条件时的比对效率变高。

  • 能利用Doris的前缀索引和布隆过滤器等能力，进一步提高查询效率。

>>>>  4.4 使用BITMAP去重代替COUNT DISTINCT

要提速实验报告查询，针对进组人数（去重用户数）的优化是非常重要的一个部分。作为一个对明细数据强依赖的指标，我们如何在不丢失明细信息的前提下，实现像Sum,Min,Max等指标一样高效的预聚合计算呢？

BITMAP去重计算可以很好的满足我们的需求。

▍什么是BITMAP去重？

BITMAP去重简单来说就是建立一种数据结构，表现形式为内存中连续的二进制位(bit)，参与去重计算的每个元素（必须为整型）都可以映射成这个数据结构的一个bit位的下标，如下图所示：

de76c0892ee6810db00927a360525a76.png

计算去重用户数时，数据以bit_or的方式进行合并，以bit_count的方式得到结果。更重要的是，如此能实现去重用户数的预聚合。BITMAP性能优势主要体现在两个方面：

  1. 空间紧凑：通过一个bit位是否置位表示一个数字是否存在，能节省大量空间。以Int32为例，传统的存储空间为4个字节，而在BITMAP计算时只需为其分配1/8字节（1个bit位）的空间。

  2. 计算高效：BITMAP去重计算包括对给定下标的bit置位，统计BITMAP的置位个数，分别为O(1)和O(n)的操作，并且后者可使用CLZ，CTZ等指令高效计算。此外，BITMAP去重在Doris等MPP执行引擎中还可以并行加速处理，每个节点各自计算本地子BITMAP，而后进行合并。

当然，以上只是一个简化的介绍，这项技术发展至今已经做了很多优化实现，比如RoaringBitmap，感兴趣的同学可以看看：

https://github.com/RoaringBitmap/RoaringBitmap

  • 全局字典

要实现BITMAP去重计算，必须保证参与计算的元素为UInt32 / UInt64，而我们的user_id为String类型，因此我们还需设计维护一个全局字典，将user_id映射为数字，从而实现BITMAP去重计算。

由于聚合数据目前只服务于离线查询，我们选择基于Hive表实现全局字典，其流程如下：

e38e043872330b77b42c7fac0dc77f8a.png

  • 指标聚合

生成Doris聚合表时，将user_id作为查询指标以BITMAP类型来存储，其他常规查询指标则通过COUNT / SUM / MAX / MIN等方式聚合：

cf328d2943d07fe04df7ce3a2af9b690.png

如此明细表和聚合表的指标计算对应关系如下：

指标计算

明细表

聚合表

[总数]

COUNT(*)

SUM(cnt)

[总和]

SUM($col)

SUM($col_sum)

[最大值]

MAX($col)

MAX($col_max)

[最小值]

MIN($col)

MIN($col_min)

[去重用户数]

SELECT COUNT(DISTINCT user_id)
或
SELECT COUNT(*)
FROM (
   SELECT user_id
   FROM table
   GROUP BY user_id
)

BITMAP_UNION_COUNT($bitmap_user_id)

五、优化效果

5.1. SQL视角

查询请求转换成SQL之后，在明细表和聚合表的表现对比如下：

[总数]

-优化前

select count(*)
from doris_xxx 
where olap_date = 20221105
and event_name='VIEW'
and exp_id like '%154556%';
bbbf348c486b962d564227ca43ffc2b4.png

[总数]

-优化后

select sum(cnt)
from doris_xxx_agg
where olap_date = 20221105
and event_name='VIEW'
and exp_id = 154556;

647de8ce9d93625d036b5e990e608757.png

[常规聚合]

-优化前

select sum(totalFee)
from doris_xxx
where olap_date = 20221105
and event_name='VIEW'
and exp_id like '%154556%';

be61e7586a9b96f1ec404cd62ac4ca25.png

[常规聚合]

-优化后

select sum(totalFee)
from doris_xxx_agg
where olap_date = 20221105
and event_name='VIEW'
and exp_id = 154556;

b5725370821335428344c9b255ca2e00.png

[进组人数]

-优化前

select count(distinct user_id)
from doris_xxx
where olap_date = 20221105
and event_name='VIEW'
and exp_id like '%154556%';

9434f1b36ebfaf0ee541b4785ce182c7.png

[进组人数]

-优化前

select bitmap_union_count(bitmap_user_id)
from doris_xxx_agg
where olap_date = 20221105
and event_name='VIEW'
and exp_id = 154556;

e70e8c6b61ba16a7d699716376b2ed5a.png

  • 常规聚合指标查询的性能提升自不必说（速度提升50~60倍）

  • 进组人数查询性能的提升也非常可观（速度提升10倍左右）

5.2. 集群视角

SQL查询的快进快出，使查询占用的资源能快速释放，对集群压力的缓解也有正向的作用。Doris集群BE节点CPU使用情况和磁盘IO状况的改变效果显著：

CPU使用率

-优化前

ab0cfbe0ea2f4aa7c129f82e20b039e2.png

CPU使用率

-优化后

68338f8a3b927cace37457eaf772192f.png

磁盘IO

-优化前

28cb9fc885e95233b70784b67346f4c3.png

磁盘IO

-优化后

d29f43fc4daa2328174ce37a327e23e0.png

需要说明的是，集群状况的改善（包括实验报告查询P95提升）并不全归功于数据预聚合优化工作，这是各方合力协作（如产品业务形态调整，后端查询引擎排队优化，缓存调优，Doris集群调优等）的综合结果。

六、小技巧

由于业务查询需求的多样，在查询明细表时，会出现一个字段既作为维度又作为指标来使用的情况。

如广告业务表中的targetConvNum(目标转化个数)字段，此字段的取值为0和1，查询场景如下：

--作为维度
select targetConvNum,count(distinct user_id)
from doris_xxx_event 
where olap_date = 20221105
and event_name='CONVERSION'
and exp_id like '%154556%'
group by targetConvNum;


--作为指标
select sum(targetConvNum)
from doris_xxx_event 
where olap_date = 20221105
and event_name='CONVERSION'
and exp_id like '%154556%';

如果这个字段被选取进入聚合表，应该如何处理呢？

我们的处理方式是：

  • 在聚合表中把这类字段建模成维度

  • 聚合表中需要一个计数指标cnt，表示聚合表中一条数据由明细表多少条数据聚合得到

  • 当这类字段被作为指标查询时，可将其与cnt指标配合计算得到正确结果

明细表查询

select sum(targetConvNum)
from doris_xxx_event 
where olap_date = 20221105
and event_name='CONVERSION'
and exp_id like '%154556%';
对应的聚合表查询
select sum(targetConvNum * cnt)
from doris_xxx_event_agg
where olap_date = 20221105
and event_name = 'CONVERSION'
and exp_id = 154556;

七、结束语

经过这一系列基于Doris的性能优化和测试，A/B实验场景查询性能的提升超过了我们的预期。值得一提的是，Doris较高的稳定性和完备的监控、分析工具也为我们的优化工作提效不少。希望本次分享可以给有需要的朋友提供一些参考。

7ae2a4859f6fd2d7f6952b6a1f306969.gif

6c1f13a44b5035f5ee8c656f9dd51301.png

小米技术
关注
【Flink实战系列】自定义通用的 flatmap 实现数据预聚合功能(keyby + countWindow)
JasonLee实时计算
01-23 1979
需求 有时候我们需要对数据做预聚合操作,比如下游需要批量写入或者批量请求访问的时候,关于预聚合大概有两种解决方案,一种是使用 keyby + countWindow 的方式,第二种就是今天要介绍的 flatmap 的方式.并且还要实现一个通用的 flatmap . 思路 实现过程非常的简单,定义一个泛型类实现 FlatMapFunction 接口,然后定义一个成员变量 List 重写 flatMap 方法,每次把数据缓存到 List 里面攒一个 batch 然后发送到下游,并清空 List 的数据.
数据湖存储与查询
AI天才研究院
08-16 1197
作者：禅与计算机程序设计艺术 1.简介 数据湖（Data Lake）由大量非结构化、半结构化、非时序的数据汇总而成，具有海量数据的价值。数据湖存储与查询是企业利用大数据进行决策支持的一项重要功能。数据湖存储与查询可将非结构、半结构、非时序的数据在HDFS（Hadoop Distributed File
独家 | 使用机器学习加速对非结构化数据的查询-第1部分（使用BlazeIt加速聚合和限制查询）...
数据派THU
12-01 364
作者：Daniel Daniel，Peter Bailis和Matei Zaharia翻译：Kay校对：王雨桐本文约2800字，建议阅读13分钟。本文为大家介绍了针对非结构化数据如何加快...
Spark性能调优-----算子调优（五）reduceByKey本地聚合
weidajiangjiang的博客
11-30 478
reduceByKey相较于普通的shuffle操作一个显著的特点就是会进行map端的本地聚合，map端会先对本地的数据进行combine操作，然后将数据写入给下个stage的每个task创建的文件中，也就是在map端，对每一个key对应的value，执行reduceByKey算子函数。reduceByKey算子的执行过程如图2-8所示： 使用reduceByKey对性能的提升如下： 1.本地聚合...
广告业务系统 之 辅助决策 —— “ AB 实验平台”
魏小言的博客
01-12 1089
在广告业务中，数据通常作为业务前进的内在驱动力之一。 AB 实验平台是以实验数据来衡量各个需求变更、未来业务发展方向、及业务潜在增长点 的重要辅助决策工具。
ABTEST实验平台
搜索引擎、个性化推荐、大数据相关学习笔记|
09-29 2591
ABTEST实验与闭环 一、单层实验 一般早期的ab-test都是单层实验，逻辑非常简单，比如使用userId/deviceId做hash然后取模，将流 量打在0-99，做成100份。 有如下问题: 1、扩展性差，只能同时支持少量实验。但是以数据驱动的业务，需要极快的创新速度，大量的创新 需要被测试，会严重delay业务。 2、如果在单层同时进行多个实验，实验之间不是独立事件，并行的时候，同一个策略，只能进行一 个实验，如果多个并行支持，无法实现。不同策略之间也有影响。 3、流量饥饿问...
迪比特数据仓库方案书样本.doc
12-17
【迪比特数据仓库方案书样本】的文档主要阐述了一个旨在构建面向业务战略的商务智能平台的系统规划。这个平台的主要目标是整合迪比特集团各业务系统的历史数据，以提升信息管理和决策支持的能力。以下是该方案书中...
clickhouse 增量更新_干货 | 每天十亿级数据更新，秒出查询结果，ClickHouse在携程酒店的应用...
weixin_34413579的博客
12-24 434
本文转自| 携程技术中心 作者| 蔡岳毅作者简介蔡岳毅，携程酒店大数据高级研发经理，负责酒店数据智能平台研发，大数据技术创新工作。喜欢探索研究大数据的开源技术框架。一、背景1)携程酒店每天有上千表，累计十多亿数据更新，如何保证数据更新过程中生产应用高可用；2)每天有将近百万次数据查询请求，用户可以从粗粒度国家省份城市汇总不断下钻到酒店，房型粒度的数据，我们往往无法对海量的明细数据做进一步层次的...
干货 | 每天十亿级数据更新，秒出查询结果，ClickHouse在携程酒店的应用
携程技术中心
06-26 1917
作者简介蔡岳毅，携程酒店大数据高级研发经理，负责酒店数据智能平台研发，大数据技术创新工作。喜欢探索研究大数据的开源技术框架。一、背景1）携程酒店每天有上千表，累计十多亿数...
如何支持亿级用户分流实验？AB实验平台在爱奇艺的实践
开发者技术前线-DevolperFront
08-29 464
01背景随着互联网公司的产品和业务越来越多样，利用数据来驱动业务决策成为必然，而AB实验正是以数据指标来判断产品功能和运营策略迭代效果的方法和工具，其可以在保证样本同时性和同质性基础上，对...
AB实验平台在贝壳找房的设计与实践
漠北鹰的专栏
06-16 4176
作者雏鹰（企业代号名），目前负责贝壳找房增长方向AB实验平台研发工作。 引言 ​ 随着贝壳找房业务的不断增长，精细化运营显得尤为重要。为了保证每一次迭代，每一个方案能够真正得到用户的认可，为贝壳带来有效的商机转化率，我们就不得不理性对待每次功能上线，反复对比找到产品方案中的不足加以改进。基于这种需要，我们推出了贝壳找房AB实验平台（Athena）（以下简称ab平台）来为大家做产品方案的优化测试...
ABTest实验系统在搜索简单实践
qqwwssaagg的博客
08-08 910
背景： 1、当我们要上一个排序策略，只有这个排序的优化方向，离线指标都是正向的，那么我们有勇气替换掉目前的排序吗？ 2、同一个功能点 有两种召回策略 离线评估都不错 上哪个留哪个？ 3、调整产品广告位或不同活动位在搜索列表中出现的位置，用对哪种方式是无感可接受的？ 等一系列线下只有方向但不能确定的事，我们可以把这类问题交给用户来让他们帮我们做正向的引导，前提是小流量不伤害用户为前提，实现 衡量 - 发现 - 迭代 - 验证 的过程，那么就有了ABTest。 1、ABTest架构 1）ABTest服务，用于读
AB实验全面介绍
最新发布
lonelymanontheway的博客
06-16 1344
概述、AARRR、AB实验、核心步骤、应用场景、分流策略、统计学基础（中心极限定理，正态分布，z检验、H0、H1假设和显著性、置信区间、统计功效）、样本量、流程、问题（证实偏差、幸存偏差、统计功效不足、辛普森悖论、均值回归、基于会话指标的谬误）、平台架构、AB指标
转转AB平台的设计与实现
zhuanzhuantech的博客
12-28 435
在数据驱动时代，不管是在产品功能迭代还是策略决策时都需要数据的支撑。那么，当我们准备上线一个新功能或者策略时，如何评估新老版本优劣，即数据的可量化就成了问题。这个时候就需要引入 A/B Test 了。
AB实验平台：为什么AB实验平台必不可少？
u013920601的博客
06-24 1280
1.概述 1.1 为什么AB实验平台必不可少？ 1.1.1 1.1.2 1.1.3 市面上可参考的平台 美团AB平台-Gemi：《美团机器学习实践》第17章 云测AB实验：https://testin.cn/（内测版本已关闭） 贝壳流量实验平台-Athena：https://www.jianshu.com/p/79d31a72978f 腾讯实验平台：https://abtest.qq.com/ 京东商户实验平台：http://aiceshi.shop.jd.com 1.2 平台架构 1.2.1 架构设计图
doris进阶之bitmap_union_count查询性能优化
u011624157的专栏
10-08 955
doris进阶之bitmap_union_count查询性能优化
Apache Doris 系列： 基础篇-使用BitMap函数精准去重（2）
修破立生
01-28 1893
Apache Doris 原有的BitMap函数虽然比较通用， 但在亿级别的BitMap大基数并交计算性能较差，解决方案：将bitmap列的值按照范围划分，不同范围的值存储在不同的bucket上，确保在不同bucket的bitmap值是正交的。在查询的时候，先对不同bucket的bitmap值完成聚合计算，上层的FE节点只需合并聚合过的数据并输出即可。如此会极大的改善计算效率，和解决FE节点成为计算瓶颈的问题。
Doris bitmap实现留存计算
鲸鱼
07-27 3106
Doris背景留存计算方法二级目录三级目录 背景 留存计算方法 二级目录 三级目录
Doris数据分层 亿级别数据实时性 达到分钟级
聊聊学习到的技术和工作中遇到的问题
01-21 1986
在doris怎么进行数据分层，使用bitmap数据结构，bitmap_count和bitmap_union_count的使用场景，最后结合案例讲述亿级数据在增量统计怎么实现分钟级别出结果。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值