易坊好文馆

  1. 首页 > 生活百科 >

小红书基于DorisDB实现数据服务平台统一化，简化数据链路

红书是年轻人的生活记录、共享平台，用户可以以短视频、文字等形式记录生活点滴，共享生活方式 。2017年以后，随着业务类型和用户数量的爆炸性增加，各种数据分析的需求和应用系统的数据需求迅速出现，如商业智能分析、数据应用报告、用户行为分析、算法战略数据等 。小红书大数据团队逐渐引入各种OLAP分析引擎，更好地满足需求 。DorisDB采用全面向量化的计算技术，是性能非常强大的下一代MPP数据库 。通过引入DorisDB，小红书搭建了全新的统一数据服务平台，大大降低了数据链路开发的复杂性，提高了高并发速度查询能力 。

一、OLAP引擎在小红书的演进史

第一阶段，截止到2017年，数据总量并不特别大 。在这个阶段使用AWSRedshift，此时数仓系统尚未完全建立，许多数据需求的实现以短平快、烟囱式开发的方式满足 。数据ETL、数仓模型出现在最后的报告方面，在Redshift中一站式完成 。

但随着业务复杂性的提高，数据量的急速增加，该模式很快成为瓶颈 。主要存在以下问题:

Redshift不能在不影响在线查询性能的前提下弹性扩展，一旦涉及扩展，就会涉及数据重新分布，从而影响集体的性能和可用性 。

ETL任务严重影响集团的可用性 。在Redshift中同时执行ETL任务时，大量占领资源，影响数据分析的效率，查询超时，集团负荷过大，集团整体崩溃，无法使用 。

没有良好的存算分离，数据存储容量存在瓶颈，不能满足随业务快速增长的数据存储需求 。

第二阶段，随着数据仓库在Hadoop/Hive系统中建立和完善，ETL任务全部转移到Hadoop集团，在此阶段使用Presto完成OLAP分析 。Presto天然与Hive共享元数据信息，共同使用物理数据存储，即插入使用 。大量对数仓表的灵活查询由Presto完成 。

第三阶段，业务实时性增强，对查询性能的要求不断升高，同时许多数据应用产生 。这个阶段引入了ClickHouse，用来建设性能更强悍，响应时间更短的数据分析平台以满足实时性要求 。

第四阶段，小红书大数据团队在实时数据仓库的整体设计和构建的同时，为各业务团队提供数据接口，构建了数据服务平台，连接了多个内部和Tob服务的应用系统 。需要进行低延迟的复杂查询，同时对并发量也有很高的要求 。在这个阶段，我们根据场景引进了DorisDB，以满足上述需求 。

二、红书数据分析系统结构

1、红书OLAP系统现状

红书的数据分析系统由数据收集、数据存储加工/数据共享和应用层构成 。

1)数据收集

服务器日志或App日志通过Flume收集埋入日志，数据同时分发到离线存储S3和实时存储kafka的在线业务数据库通过Canal实时收集MySQL

2)数据存储加工

离线数据处理:利用Hive/Spark可扩展的批处理能力承担所有离线数仓的ETL和数据模型加工的工作 。

实时数据处理:Flink完成实时侧数据的ETL(含维度丰富、双流Join、实时总结)离线表通过调度平台与ClickHouse/DorisDB同步，Flink实现ClickHouse和DorisDB的sink

3)数据共享

数据共享层主要提供对外服务的基础数据存储，离线或实时数据写入相关数据库组件，为多种服务提供查询能力

数据共享层主要有TiDB/Hbase/ClickHouse/DorisDB 。通过DorisDB和ClickHouse提供的快速OLAP查询能力，在应用端接受报表平台，提供即时分析的平台，在开发端提供数据接口，实现多个数据产品(例如流量分析平台、用户标签平台) 。

4)应用层

应用层主要面向管理和运营者的报告，具有并发、延迟、需求更新频繁等要求，面向数据分析师的即时查询，支持复杂的sql处理、大量的数据查询等能力

2、各OLAP分析工具选型比较

#formatimgID_1#

1)Clickhouse:

优点:

强的单表查询性能，适用于基于宽表的灵活即时查询 。

包含丰富的MergeTreeFamily，支持预聚合 。

非常适合大规模日志明细数据填写分析 。

缺点:

不支持真正的删除和更新 。

Join方式不太友好 。

并发能力相对较低 。

MergeTree合并不完整 。

2)DorisDB:

优点:

单表查询和多表查询性能强，同时支持宽表查询场景和复杂多表查询 。

支持高并发查询 。

支持实时数据微批ETL处理 。

流动和批量数据的填写都很强 。

兼容MySQL协议和标准SQL 。

缺点:

周边生态不完善 。

部分SQL语法不支持 。

3)TiDB/TiFlash:

优点:

支持更新/删除 。

兼顾了OLTP的需求 。

支持Flink ExactlyOnce语意，支持幂等 。

缺点：

查询性能弱，无法较好支持OLAP查询场景 。

不支持实时预聚 。

TiFlash暂时不支持所有SQL的写法和函数 。

三、DorisDB在广告数据中心的应用实践

1、业务场景概述

广告业务的核心数据有两个 。一个是广告曝光点击流，即所有广告单元的展示销售信息，二个是广告效果的原因数据，如红书站内的订单转换、相关表单提交、笔记的赞词、收藏、关注等参与度 。

根据这些数据，根据不同的业务场景需求，实时总结相关的业务统计指标，并对外提供查询分析服务 。

2、原有解决方案

1)技术结构

在引进DorisDB之前，用大量的Flink任务写入MySQL/Redis/HDFS/ClickHouse，以达到数据的着陆 。

Flink的核心处理逻辑有几种:

前端用户广告展示信息事件流程和后端算法推荐流程的双流关联和重量，完善广告信息 。

访问反作弊，消除作弊事件 。

根据业务场景的需要总结结果，写入不同的数据库组件 。

2)技术痛点

原始结构主要存在以下问题:

数据逻辑不能合并，维护工作量大，新需求无法迅速应对 。

【小红书基于DorisDB实现数据服务平台统一化，简化数据链路】Clickhouse的并发能力不足以及扩容复杂度在可见未来会成为整体广告系统瓶颈 。

因为Flink层逻辑散落，由大量小的Flink任务构成，因此导致整个架构无法满足高可用要求，只要任何一个任务出现问题，都会影响线上业务 。

3、基于DorisDB的解决方案

因此，我们希望优化原始系统，核心思路是利用OLAP引擎统一这一层，对OLAP引擎的要求比较高:

可以支持大吞吐量的数据写入要求 。

可支持多维度组合灵活查询，TP99低于100ms 。

有实时汇总上卷的能力，提高查询性能，支持qps达到上万要求 。

通过Binlog实时同步MySQL的数据，立即封装数据 。

支持多表关联 。经过大量调查，DorisDB符合广告数据中心的整体要求 。基于DorisDB本身的高效查询能力，支持高QPS的特性，可为广告算法策略、广告实时记账、广告平台实时数据报表提供一体化服务 。

新结构具有

结构清晰，Flink专注于数据清洗，业务逻辑计算从Flink转移到DorisDB，DorisDB是数据业务逻辑的终点 。

可以维持统一的数据口径，输入数据，输出广告统计口径 。

在基础上实现DorisDB的主要工作，更好地支持高QPS场景 。

1)数据表设计

数据模型设计

DorisDB本身提供三种数据模型:详细模型/聚合模型/更新模型 。对于小红书广告业务，三种数据模型分别使用:

广告曝光点击流写在聚合模型，根据业务所需的维度，如广告主、广告类型、创意、广告单元、搜索词、地区、用户属性等设计聚合的所有维度，根据所需的指标进行聚合 。

广告侧后端有很多在线MySQL，通过DorisDB更新模型访问MySQL进行实时更新 。

在Hadoop线下数仓还定期统计了一些数据报告同步到DorisDB，这些数据使用了DorisDB的详细模型 。

数据分区/桶

DorisDB提供的数据分区功能可以提高广告场景下查询的性能 。例如，广告侧查询常见的查询场景是查询过去一段时间内的数据，我们可以在DorisDB中根据时间进行分区，过滤不必要的分区数据 。此外，广告查询还会根据广告主进行筛选，我们将广告主ID作为排名键的最前沿，可以快速定位广告主数据，DorisDB还支持根据广告主ID进行Hash分桶，减少整个查询数据量进行快速定位，这对于高并发场景也具有非常大的意义，尽量减少查询词句所复盖的数据范围，提高并发能力 。

物化视图

我们可以利用DorisDB物化视图实时、批量构建，灵活增加删除和透明使用的特性，基于广告主粒度、用户特征粒度、广告单元粒度、具体创意粒度根据这些物化视图，可以大大加速查询 。

2)数据导入

实时数据导入分为

有ETL处理需求的，利用Flink进行ETL逻辑转换，使用Flink开发DorisDB

实时数仓公共层配置Routineload任务，将数据10sbatch写入DorisDB表 。

离线数据报告导入DorisDB:

根据DorisDB提供的原始Brokeroload，在红书数仓的调度平台上包装导数模板，通过界面化配置将离线数仓的表导入DorisDB

3)数据查询

在我们的查询场景中，广告主业务查询服务对查询并发性要求很高 。DorisDB采用MPP查询结构，基础数据分为Range和Hash两级，非常适合广告主业务的查询场景 。

内部在线查询测量结果，每个FE可以达到2000左右的QPS，整个集团可以提供数万个QPS，TP99的查询不超过100毫秒 。

4)系统运输

广告数据中心是非常核心的在线服务，因此对高可用性和灵活扩展能力有非常高的要求 。DorisDB支持fe/be多副本，无单节点问题，有节点故障时也能保证整个集团的高可用性 。此外，DorisDB还可以在大数据规模下进行线上弹性拓展，在拓展的时候不需要线下，不影响线下的业务，这种能力也是我们非常需要的 。

小红书从今年年初开始调查引进DorisDB，现在已经有5个DorisDB集团稳定运行，其中2个开始稳定提供在线服务，3个还在试运行 。引入DorisDB后，实现了数据服务的统一化，大大简化了实时数据处理链接，同时保障了高查询并发和低响应延迟要求，之后将用于提高更多业务场景的数据服务和查询能力 。最后，感谢鼎石科技的大力支持，也期望DorisDB作为性能强悍的新一代MPP数据库引领者越来越好!(作者：吴浩亮 小红书大数据团队，数据仓库架构师)

    推荐阅读


    上一篇：茅岩莓茶的禁忌

    下一篇：艾叶洗澡的禁忌