乐趣区

关于大数据:Apache-Doris-在小米亿级用户行为分析平台的实践|最佳实践

导读:过来 3 年工夫里,Apache Doris 曾经在小米外部失去了宽泛的利用,反对了团体数据看板、广告投放 / 广告 BI、新批发、用户行为剖析、A/B 试验平台、天星数科、小米有品、用户画像、小米造车等小米外部数十个业务,并且在小米外部造成了一套以 Apache Doris 为外围的数据生态。本文将为大家分享小米用户行为剖析平台基于 Apache Doris 向量化版本的革新实际,包含数据存储架构和查问服务架构的演进与革新教训分享。

作者|小米数据智能部开发工程师 汤佳树

小米用户行为剖析对立平台是基于海量数据的一站式、全场景、多模型、多维度、自助式大数据智能洞察剖析服务平台,对接各类数据源,进行加工解决、剖析开掘和可视化展示,满足各类用户在用户洞察场景下的数据分析利用需要,提供高效极致的剖析体验。

业务需要

平台能够基于数据进行工夫剖析,留存剖析,散布剖析,漏斗剖析等,业务方次要基于事件进行剖析,事件是追踪或记录的用户行为或业务过程,能够是单个事件也能够是多个事件组合的虚构事件。

数据来源于各业务的打点数据,且基于事件模型进行建模,用户在产品中的各种操作都能够形象成 Event 实体,并且外面都会蕴含五因素:

  • Who:即参加这个事件的用户是谁,例如用户的惟一 ID
  • When:即这个事件产生的理论工夫,例如 time 字段,记录准确到毫秒的事件产生工夫
  • Where:即事件产生的地点,例如依据 IP 解析出的省份和城市
  • How:即用户从事这个事件的形式,例如用户的设施,应用的浏览器,应用的 App 版本等等
  • What:形容用户所做的这件事件的具体内容,例如点击类型的事件,须要记录的字段有点击 URL,点击 Title,点击地位等

数据基于 OLAP 引擎 Doris 进行存储,随着接入业务一直增多,且接入的业务量一直收缩,Top 级利用能够达到 100 亿条 / 天,查问压力和工夫相继增大,用户对查问时延的吐槽愈来愈多,咱们急迫的须要晋升查问性能来晋升用户的体验。

痛点问题

针对于业务需要,咱们总结了以下痛点问题:

  • 为了实现简单的业务需要,OLAP 剖析引擎须要留存、漏斗等剖析函数撑持。
  • 增量数据 100 亿 / 天,导入压力大,局部业务要求数据导入不丢不重。
  • 业务接入一直增多,数据量收缩,须要 PB 级的数据下的交互式剖析查问达到秒级响应。

为了解决以上的痛点问题,咱们比照了多款 OLAP 剖析引擎,最终抉择了 Apache Doris。Doris 提供了留存、漏斗剖析等函数,极大水平的简化了开发的老本。在数据导入的过程中,咱们尝试 Doris 刚推出的 Merge On Write Unique Key 导入模型,能够抗住 100 亿 / 天 的增量数据压力。针对于向量化查问引擎的革新也是的性能较之前的版本有 3-5 倍 的晋升。

架构演进

一个优良的零碎离不开继续迭代与演进。为了更好的满足业务需要,咱们在存储架构与查问引擎两个层面上一直进行尝试,小米用户行为剖析零碎在上线后,目前已实现 3 次革新,以下将为大家介绍革新历程。

数据存储构造:数据架构的演进

在小米的用户行为剖析平台中,原始数据通过小米自研的音讯队列 Talos,在 Flink 中荡涤与建模后,被上游的 Doris 与 Hive 生产。全量的数据会存储在 Hive 中,进行批量 ETL 或历史数据召回的查问。实时增量数据被存储在 Doris 中,用来做热数据的查问操作。基于冷热数据拆散的架构,咱们进行了 3 次架构的演进。

第一阶段:基于明细宽表的查问

在最后的阶段咱们应用了基于明细的宽表查问模式 。为了解决灵活多样的剖析申请,在零碎中,咱们配合对立埋点平台解决数据,接入的 OLAP 的数据是间接埋点的全字段展平。在入库之前,咱们在 Flink 中将数据打平,以宽表的模式存储在 Doris 明细表中。依据查问的需要,咱们将常常应用的列作为建表的维度列,利用前缀索引的个性进行查问减速。 但某些头部大数据量业务容易查问多天数据,一个大查问可能就会将集群资源占满甚至导致集群不可用,且查问耗时相当之久

第二阶段:基于聚合模型的查问减速

在革新的第二阶段,咱们应用了聚合模型对业务查问进行减速。 咱们对接入行为剖析的利用进行统计分析,绝大多数接入行为剖析的利用数据量在 1 亿 / 天数据量以内。对于局部应用频率较高的表,咱们采纳聚合表实现查问减速,对单天数据量超 10 亿且高频的头部利用做聚合表减速。具体流程为依据数据量挑选出头部利用,对其进行字段解析,并挑选出罕用指标及维度,由 Hive 表数据进行聚合 T-1 产出数据,最初写入到 Doris 中,进行查问减速。该阶段的革新解决了集群头部业务大查问的问题,此时尽管独立集群存储没问题,但因为其余业务接入后还会继续减少数据量和 埋点 字段,这样会导致元数据最先进入瓶颈

第三阶段(以后阶段):业务适配的建表革新

以后阶段,咱们对业务需要进行深度解析后从新布局了建表构造。咱们对某些利用的埋点字段进行剖析,发现有些用户埋点字段多达 500+,但在行为剖析里理论用到的可能只有 100+,这显然有所节约。所以咱们与用户沟通调研需要,配合行为剖析平台侧的能力,用户可在平台对有用事件和属性进行筛选,同时设置字段映射和过滤逻辑,而后再进行建表。

查问服务架构:查问引擎的革新与演进

咱们基于业务深度革新了查问的服务架构,构建了新的查问引擎架构,实现 SQL 的权重、路由、缓存和资源调度操作。依据查问条件,路由引擎会将 SQL 拆分成多条子查问,在 Doris 或 Hive 中执行后,将子查问的后果汇总,失去最终的后果。针对查问引擎,咱们也进行了 3 次技术架构的革新。

第一阶段:基于集群粒度的查问资源管理

咱们对集群粒度进行查问资源管理,在资源调度中,咱们会给每一个 Doris 集群设置一个总的资源池大小(依据集群能力和测试进行量化),依据数据量大小和查问天数对每个 SQL 进行加权,并对资源池的最大最小并行 SQL 数进行限度,如果计算的 SQL 超过限度则进行排队。其次,还会利用 Redis 对数据进行 SQL 级别缓存。

第二阶段:基于 SQL 路由的革新

为适配聚合表减速做了路由层,晋升缓存命中率和利用率,此阶段拆分原始提交 SQL,基于指标进行缓存,粒度更细,服务端可依据指标进行适当计算更易于缓存命中。值得一提的是排队工夫往往会比拟长,有些场景下可能会进行反复提交或拆分成同样的 SQL,为了提高效率会在 SQL 排队前和排队后各进行一次缓存校验。

第三阶段(以后阶段):基于 SQL 权重的革新

整体架构方面,因为采取了筛选埋点字段而非全量字段导入 Doris,针对头部问题用户,咱们会基于查问历史统计指标及维度,依据指定的某些规定进行默认初始化操作,并以此沟通用户并进行疏导降级。此外为了更精密的管制资源调度,本阶段对对 SQL 内容进行加权,如含有 DISTINCTLIKEVARIANCE_SAMP 等字样再加权。对于资源耗费较大的操作,如 DISTINCT,会给予更高的权重,调度引擎在执行时会调配更多的资源。

实际利用

数据建模

对业务来讲,剖析查问须要较高的灵便度,且是对用户粒度进行剖析,所以须要保留较多的维度和指标,咱们选用 Doris 作为存储查问引擎,且采纳明细表建模,这样能够保障用户可能依据剖析需要查出数据。另一方面,因为查问剖析是一个延时要求较高的产品,对于数据量大、查问天数多、语句简单的状况,查问延时会很高,所以对于头部利用,咱们依据高频指标维度进行了聚合表模型建模。

 CREATE TABLE `doris_XXX_event` (`olap_date` bigint(20) NOT NULL COMMENT "",
  `event_name` varchar(256) NOT NULL COMMENT "",
  `uniq_id` varchar(256) NOT NULL COMMENT "",
  `dim1` varchar(256) REPLACE NULL COMMENT "",
  `dim2` varchar(256) REPLACE NULL COMMENT "",
  ...
  `cnt` bigint(20) REPLACE NULL COMMENT "",
  `index1` double REPLACE NULL COMMENT "",
  `index2` double REPLACE NULL COMMENT "",
  ...
) ENGINE=OLAP
AGGREGATE KEY(`olap_date`, `event_name`, `uniq_id`)
COMMENT "OLAP"
PARTITION BY RANGE(`olap_date`)

数据导入

明细表局部,咱们接入 Json 格局 TalosTopic,动静获取 Doris 表的 Schema 信息,通过双缓冲区循环攒批的形式,利用 StreamLoad 向 Doris 中写数据,如果在导入 Doris 时有呈现失败的批次,重试 10 次依然失败,会将数据依照利用粒度存入 HDFS,并在凌晨定时调度工作从新写入 T-1 未写入的数据。聚合表局部,咱们由 Talos 落盘的 Iceberg 表,每日进行 T-1 数据的聚合,依据服务端选取的维度和指标,以及聚合类型(count ,count distinct , sum ,max ,min),进行聚合存入两头 Hive 表,再由对立导入 Doris 程序进行导入。

数据管理

明细数据和利用聚合表分库存储,TTL 均为 33 天。数据表会有数据品质监控,如果总行数或者设置指标环比稳定太大,会进行告警人工染指确认数据是否有误,视紧急水平进行回补解决。

数据查问及利用

绝大多数用户会锚定事件,进行含指标聚合,去重用户数(简直占总查问的 50%)的事件行为剖析,同时还会有留存剖析,漏斗剖析,散布剖析等剖析类型。

建表模型的保护

为了适配业务的变更,上游的埋点信息会周期性的更新。原有的表构造须要进行变更以适配埋点的减少。在过来的 Doris 版本中,Schema Change 是一项绝对耗费较大的工作,须要对文件进行批改。在新版本中开启 Light Schema Change 性能后 对于增减列的操作不须要批改文件,只须要批改 FE 中的元数据,从而实现毫秒级的 Schame Change 操作。

利用现状

小米目前在 300 多个业务线上线了 Doris 集群,超过 1.5PB 的业务数据。在初期咱们抉择了两个应用较为频繁的集群进行向量化降级。

现迁徙 Doris 向量化集群的行为剖析业务有 2 个,7 天增量数据的平均值在 百亿左右 ,存储空间占用 7T/ 天 左右。在降级到向量化的版本后,存储资源有较大的节俭,只须要原有集群约 2/3 的存储空间

性能晋升

申请粒度

降级 Doris 向量化版本后,行为剖析平台以 申请粒度 统计查问耗时 P80 和均值,P80 耗时 降落 43%,均匀耗时 降落 27%;统计口径:汇总 12.07-12.11 期间,行为剖析申请粒度查问执行工夫。

SQL 粒度

降级 Doris 向量化版本后,行为剖析平台以 SQL 粒度 来统计查问耗时 P80 和均值,耗时 P80 降落 70%,均匀耗时 降落 54%统计口径:汇总 12.04-12.11 期间,行为剖析 SQL 粒度查问执行工夫(未含排队)

降级 Doris 向量化版本后,行为剖析平台以 SQL 粒度 统计查问耗时 P80 和均值,耗时 P80 降落 56%,均匀耗时 降落 44%

统计口径:汇总 12.02-12.11,行为剖析 SQL 粒度查问总工夫 (含排队)

去重优化

在 ID-Mapping 的时候,通常须要针对 ID 进行去重操作。在最后咱们应用了 COUNT DISTINCT 来实现去重。

SELECT      a.`olap_date` AS `time`, 
            count(distinct a.`distinct_id`) AS distinct_id 
FROM        analysis.doris_XXX_event a 
WHERE       `a`.`olap_date` BETWEEN 20221218 AND 20221220 AND 
            a.`event_name` IN(XXXX, XXX, XXX, XXX) AND 
            ... ... 
GROUP BY    1 
ORDER BY    2 DESC 
LIMIT       10000

在通过优化后,咱们应用子查问 + GROUP BY 来代替 COUNT DISTINCT 的性能

SELECT      z.`time`, 
            count(distinct_id) var1 
FROM        (SELECT     a.`olap_date` AS `time`, 
                        a.`distinct_id` AS distinct_id 
            FROM        analysis.doris_XXX_event a 
            WHERE       `a`.`olap_date` BETWEEN 20221218 AND 20221220 AND 
                        a.`event_name` (XXXX, XXX, XXX, XXX) AND 
                        ... ...
            GROUP BY 1, 2) z 
GROUP BY    1 
ORDER BY    2 DESC 
LIMIT       10000

相较于原有的COUNT DISTINCT,应用子查问+ GROUP BY 的模式性能有 1/3 的晋升

将来布局

在过来的三年工夫里,Apache Doris 曾经在小米外部失去了宽泛的利用,反对了团体数据看板、广告投放 / 广告 BI、新批发、用户行为剖析、A/B 试验平台、天星数科、小米有品、用户画像、小米造车等小米外部数十个业务,并且在小米外部造成了一套以 Apache Doris 为外围的数据生态。随着业务的持续增长,将来咱们会进一步推动小米的其余业务上线向量化版本。

非常感谢 Apache Doris 社区与 SelectDB 公司的鼎力支持,小米团体作为 Apache Doris 最晚期的用户之一,始终深度参加社区建设,参加 Apache Doris 的稳定性打磨,将来咱们也会密切联系社区,为社区奉献更多的力量。

退出移动版