大数据分析——Apache Doris（六十六）

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第20天，点击查看活动详情

 Doris on ES在快手商业化的最佳实践

 业务场景介绍

 服务介绍

本案例主要侧重介绍Doris on ES（DOE）在我们业务场景的实践，所以数据架构在这里只做简单介绍。

总体来说数据分为实时+离线两块事实数据写入，外加mysql binlong同步这一部分的维度数据写入。

实时主要是flink+kafka，离线部分基本各大公司都是统一解决方案-HIVE。数据最终导入计算引擎都是由各个引擎适配的工具或组件配合来完成的。如DRUID的KIS(kafka index service)+index_hadoop，Doris的routine load + broker load。

 传统OLAP多维分析查询

传统OLAP多维分析查询基本上是对事实数据(fact table)的下钻、上卷、切片、切块、旋转操作。

 星型模型join场景下的OLAP多维分析查询

星型模型Join场景下的OLAP多维分析查询与传统OLAP多维分析的区分主要是引入了维度数据(dim table)Join。

select
f.key_1,
f.key_2,
d.key_3,
d.key_4,
AGGR_FUNC(f.value_1),
AGGR_FUNC(f.value_2)
from 
f left join d on d.key = f.key_1 -- 维度表必须具有主键，与事实表进行关联
where
    f.dt in (xxx) and
    f.key_xx in (xxx) and
    d.col_2 in (xxx) and        -- 可以基于维度表的col做filter
    d.key_3 match('xxx')        -- match在这里表达的含义是分词模糊匹配场景
group by                                                    
    f.key_1,
    f.key_2,
    d.key_3,
    d.key_4
order by
AGGR_FUNC(f.value_1)  DESC 
having AGGR_FUNC(f.value_2) > xxx
limit N

维度数据主要有两大用处：

• 过滤筛选

• 填充其他维度信息，如name等。

这里解释一下为何我们不能做成大宽表模式。通常来说，针对类似场景通用解决方案一般有两种：

• 大宽表，数据以尽可能全的维度，先join好再写入引擎

• 星型模型关联查询，查询的时候才去做关联join

 业务挑战

• 超大数据量：单表原始数据每天增量百亿

• 查询高QPS：平均QPS千级别

• 高稳定性要求：在线服务要求稳定性4个9

• 星型模型中，维表需要支持高频的UPDATE操作(update qps约1千)，且维表需要支持模糊匹配、分词检索