万亿级数据秒级实时分析，小红书OLAP引擎的进化之路

小红书是年轻人的生活记录、分享平台，用户可以通过短视频、图文等形式记录生活点滴，分享生活方式。最近几年，随着业务类型和用户体量的爆炸式增长，各类数据分析的需求以及应用系统的数据需求快速出现，例如：商业智能分析，数据应用报表，用户行为分析、算法策略数据等。

小红书大数据团队逐步引入了多种OLAP分析引擎以及自建引擎来更好的满足需求。当前Flink+Doris和Flink+Clickhouse(自建版)已成为小红书构建统一实时数据服务的核心技术方案，大大降低了数据链路开发复杂性，提升了高并发极速查询能力。

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

第一阶段

在2017年之前，数据总量还不是特别大，这个阶段使用AWS的Redshift，此时数仓体系还没有完全建立，很多数据需求的实现都是用短平快、烟囱式开发的方式来满足。数据ETL、数仓模型到最后报表端展现，在Redshift中一站式完成。但随着业务复杂度不断提升，以及数据量的快速增长，这种模式很快遇到了瓶颈。主要有以下问题：

Redshift无法在不影响线上查询性能的前提下弹性扩展，一旦涉及到扩容，就会涉及到数据重分布，从而影响集群的性能以及可用性。ETL任务严重影响集群可用性。在Redshift中同时进行ETL任务的时候，会大量抢占资源，从而影响数据分析的效率，导致查询超时甚至因为集群负载过大后整个集群崩溃不可用。没有良好的存算分离，数据存储容量存在瓶颈，无法满足随业务而快速增长的数据量存储需求。

第二阶段

随着数据仓库在Hadoop/Hive体系上搭建和完善，ETL任务全部转移至Hadoop集群，这个阶段使用Presto完成OLAP分析。Presto天然和Hive共享元数据信息，且共同使用物理数据存储，即插即用。大量的对数仓表的灵活查询使用Presto完成。

第三阶段

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

第四阶段

小红书大数据团队进行了实时数仓的整体设计和搭建，同时为统一对各业务团队提供数据接口而构建了数据服务平台，外接了多个内部或者To B服务的应用系统。既需要做低延时的复杂查询，同时对并发量也有很高的要求。这个阶段我们又根据场景引入了Doris引擎，以满足以上各类需求。

第五阶段

小红书大数据团队在Clickhouse的基础上自研了Redck引擎。小红书作为一个内容分享平台，用户的行为特征数据分析是最具价值同时也是最具挑战的，日常存在大量的功能表现、流量漏斗、用户路径、实验分析、属性分布等分析场景。而这些场景，都对平台同时具备实时，秒级响应分析万亿行级别数据的能力有着很高的要求。基于这些实际业务需求，我们利用Clickhouse天然的Mpp特性，加上自主开发的元数据管理，存算分离架构，冷热数据分层，实时数据写入等特性，构建了小红书自己的用户行为分析平台，提供高效快速的人群行为分析、实验分析洞察能力。

二、小红书数据分析体系架构

1、小红书OLAP体系现状

小红书的整个数据分析体系，由数据采集、数据存储加工/数据共享和应用层组成。

数据采集

服务器日志或者App日志通过Flume收集埋点日志，数据同时分发到离线存储S3和实时存储kafka；线上业务数据库通过Canal实时采集MySQL binlog等信息。

数据存储加工

离线数据处理：利用Hive/Spark高可扩展的批处理能力承担所有的离线数仓的ETL和数据模型加工的工作。实时数据处理：Flink完成实时侧数据的ETL（包括维度丰富，双流Join，实时汇总）；离线表通过调度平台同步到***/DorisDB，我们Flink实现了***和DorisDB的sink connector，落地到DorisDB或***。

数据共享

数据共享层的主要提供对外服务的底层数据存储,离线或者实时的数据写入相关的数据库组件中，面向多种服务，不同场景提供查询能力。数据共享层主要有TiDB/HbaseDoris。通过Doris和***提供的高速OLAP查询能力，在应用侧承接了报表平台，提供即席分析的平台，对开发侧提供数据接口，以及实现多个数据产品（比如流量分析平台，用户标签平台）。

应用层

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

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

1）Clickhouse

① 优点

很强的单表查询性能，适合基于大宽表的灵活即席查询。包含丰富的MergeTree Family，支持预聚合。非常适合大规模日志明细数据写入分析。

② 缺点

不支持真正的删除与更新。Join方式不是很友好。并发能力比较低。MergeTree合并不完全。

2）DorisDB

① 优点

单表查询和多表查询性能都很强，可以同时较好支持宽表查询场景和复杂多表查询。支持高并发查询。支持实时数据微批ETL处理。流式和批量数据写入都能都比较强。兼容MySQL协议和标准SQL。

② 缺点

周边生态比较不完善。部分SQL语法不支持。

3）TiDB/TiFlash

① 优点

支持更新/删除。兼顾了OLTP的需求。支持Flink  ExactlyOnce语意，支持幂等。

② 缺点

查询性能弱，无法较好支持OLAP查询场景。不支持实时预聚合。TiFlash暂时不支持所有的SQL写法以及函数。

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

1、业务场景概述

2、原有解决方案

1）技术架构

在引入Doris引擎之前，是用大量Flink任务进行写入MySQL/Redis/HDFS/***，以达到数据的落地。Flink中核心处理逻辑有几类：

前端用户广告展示信息事件流和后端算法推荐流双流关联并去重，完善广告信息。接入反作弊，清除作弊事件。按不同业务场景需求汇总结果写入不同的数据库组件中。

2）技术痛点

原有架构主要有以下问题：

数据逻辑没有很好做归拢合并，维护工作量大，新需求无法快速响应。Clickhouse的并发能力不足以及扩容复杂度在可见未来会成为整体广告系统瓶颈。因为Flink层逻辑散落，由大量小的Flink任务构成，因此导致整个架构无法满足高可用要求，只要任何一个任务出现问题，都会影响线上业务。

3、基于Flink+Doris的解决方案

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

能支撑大吞吐量的数据写入要求。可以支持多维度组合的灵活查询，TP99在100ms以下。有实时汇总上卷的能力，提高查询性能，支持qps达到上万的要求。通过Binlog实时同步MySQL的数据，并及时对数据进行封装。比较好的支持多表关联。

经过大量调研，DorisDB比较契合广告数据中心的整体要求。基于DorisDB本身高效的查询能力，支持高QPS的特性，可以为广告的算法策略、广告实时计费、广告平台实时的数据报告提供一体化服务。新架构具备以下优点：

结构清晰，Flink专注于数据的清洗，业务逻辑计算从Flink迁到DorisDB内实现，DorisDB就是数据业务逻辑的终点。可以维护统一的数据口径，一份数据输入，一套广告统计口径输出。在底层实现DorisDB主备双活，更好的支持高QPS场景。

1）数据表设计数据模型设计

DorisDB本身提供三种数据模型：明细模型/聚合模型/更新模型。对小红书广告业务来说，三种数据模型各尽其用：

2）数据分区/分桶

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

3）物化视图

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

4）数据导入

实时的数据导入分为两种：

有ETL处理需求的，会利用Flink进行ETL逻辑转化，使用Flink DorisDB Connector写入DorisDB。在实时数仓公共层的，配置Routine Load任务，将数据10s一个batch写入DorisDB表中。

离线数据报告导入DorisDB：

在DorisDB提供的原生的Broker Load基础上在小红书数仓的调度平台上封装了导数模版，通过界面化配置的方式，将离线数仓的表导入到DorisDB中。

5）数据查询

在我们的查询场景中，广告主业务查询服务对查询并发度要求很高。Doris采用的是MPP查询架构，底层数据按照Range和Hash两级分片，非常适合广告主业务的查询场景。

内部做的线上查询压测结果，每个FE能到2000左右的QPS，整个集群能提供上万的QPS，TP99的查询在100毫秒以下。

6）系统运维

广告数据中心是非常核心的一个线上服务，因此对高可用及灵活扩容能力有非常高的要求。Doris引擎本身支持fe/be多副本，没有单节点问题，当有节点故障的时候也可以保证整个集群的高可用。另外，当前体系结构在大数据规模下可以进行在线弹性扩展，在扩容时无需下线，不会影响到在线业务。

在此基础上，我们同时建设了主备双活链路，使用consul进行连接管理，一旦出现单条链路失效，可以一体化切换所有线上查询服务，在日常开发新需求上线时，也可以保持备用链路上线运行，主备对比校验，再进行主链路升级，做到业务上线对下游无感知。

四、总结

    以上就是本篇文章【万亿级数据秒级实时分析，小红书OLAP引擎的进化之路】的全部内容了，欢迎阅览 ！ 文章地址：http://www.glev.cn/news/9083.html 
     资讯      企业新闻      行情      企业黄页      同类资讯      首页      网站地图      返回首页 歌乐夫资讯移动站 http://wlb.glev.cn/ , 查看更多