小红书是年轻人的生活记录、分享平台,用户可以通过短视频、图文等形式记录生活点滴,分享生活方式。在 2017 年后,随着业务类型和用户体量的爆炸式增长,各类数据分析的需求以及应用系统的数据需求快速出现,例如:商业智能分析,数据应用报表,用户行为分析、算法策略数据等。小红书大数据团队逐步引入了多种 OLAP 分析引擎来更好的满足需求。DorisDB 采用了全面向量化的计算技术,是性能非常强悍的新一代 MPP 数据库。通过引入 DorisDB,小红书构建了全新的统一数据服务平台,大大降低了数据链路开发复杂性,提升了高并发极速查询能力。
第一阶段,在 2017 年之前,数据总量还不是特别大,这个阶段使用 AWS 的 Redshift,此时数仓体系还没有完全建立,很多数据需求的实现都是用短平快、烟囱式开发的方式来满足。数据 ETL、数仓模型到最后报表端展现,在 Redshift 中一站式完成。但随着业务复杂度不断提升,以及数据量的快速增长,这种模式很快遇到了瓶颈。主要有以下问题:
第二阶段,随着数据仓库在 Hadoop/Hive 体系上搭建和完善,ETL 任务全部转移至 Hadoop 集群,这个阶段使用 Presto 完成 OLAP 分析。Presto 天然和 Hive 共享元数据信息,且共同使用物理数据存储,即插即用。大量的对数仓表的灵活查询使用 Presto 完成。
第三阶段,业务实时性增强,对查询性能的要求不断升高,同时许多数据应用产生。这个阶段引入了 ClickHouse,用来建设性能更强悍,响应时间更短的数据分析平台以满足实时性要求。
第四阶段,小红书大数据团队进行了实时数仓的整体设计和搭建,同时为统一对各业务团队提供数据接口而构建了数据服务平台,外接了多个内部或者 To B 服务的应用系统。既需要做低延时的复杂查询,同时对并发量也有很高的要求。这个阶段我们又根据场景引入了 DorisDB,以满足以上各类需求。
小红书的整个数据分析体系,由数据采集、数据存储加工/数据共享和应用层组成。
1)数据采集
服务器日志或者 App 日志通过 Flume 收集埋点日志,数据同时分发到离线存储 S3 和实时存储 kafka;线上业务数据库通过 Canal 实时采集 MySQL binlog 等信息。
2)数据存储加工
离线数据处理:利用 Hive/Spark 高可扩展的批处理能力承担所有的离线数仓的 ETL 和数据模型加工的工作。实时数据处理:Flink 完成实时侧数据的 ETL(包括维度丰富,双流 Join,实时汇总);离线表通过调度平台同步到 ClickHouse/DorisDB,Flink 实现了 ClickHouse 和 DorisDB 的 sink connector,落地到 DorisDB 或 ClickHouse。
3)数据共享
数据共享层的主要提供对外服务的底层数据存储,离线或者实时的数据写入相关的数据库组件中,面向多种服务,不同场景提供查询能力。
数据共享层主要有 TiDB/Hbase/ClickHouse/DorisDB。通过 DorisDB 和 ClickHouse 提供的高速 OLAP 查询能力,在应用侧承接了报表平台,提供即席分析的平台,对开发侧提供数据接口,以及实现多个数据产品(比如流量分析平台,用户标签平台)。
4)应用层
应用层主要为面向管理和运营人员的报表,具有并发、延迟、需求更新频繁等要求,面向数据分析师的即席查询,要求支持复杂 sql 处理、海量数据查询等能力。
1)Clickhouse:
优点:
缺点:
2)DorisDB:
优点:
缺点:
3)TiDB/TiFlash:
优点:
缺点:
广告业务的核心数据有两大块:一个是广告的曝光点击流,即所有广告单元的展点销信息;第二个是广告效果归因数据,比如说在小红书站内的订单转化,相关表单提交,笔记的点赞、收藏、加关注等参与程度。
基于这些数据,根据不同的业务场景需求,实时汇总出相关业务统计指标,对外提供查询分析服务。
1)技术架构
在引入 DorisDB 之前,是用大量 Flink 任务进行写入 MySQL/Redis/HDFS/ClickHouse,以达到数据的落地。Flink 中核心处理逻辑有几类:
2)技术痛点
原有架构主要有以下问题:
因此我们希望对原有体系进行优化,核心思路是利用一个 OLAP 引擎进行这一层的统一, 对 OLAP 引擎的要求是比较高的:
经过大量调研,DorisDB 比较契合广告数据中心的整体要求。基于 DorisDB 本身高效的查询能力,支持高 QPS 的特性,可以为广告的算法策略、广告实时计费、广告平台实时的数据报告提供一体化服务。
新架构具备以下优点:
数据模型设计
DorisDB 本身提供三种数据模型:明细模型/聚合模型/更新模型。对小红书广告业务来说,三种数据模型各尽其用:
数据分区/分桶
DorisDB 提供的数据分区功能,可以很好的提升广告场景下查询的性能。例如,广告侧查询常见的一种查询场景,是查询过去某一段时间内的数据,我们可以在 DorisDB 中根据时间进行分区,过滤掉不必要的分区数据。另外,广告查询会根据广告主进行筛选,我们将广告主 ID 作为排序键的最前列,就可以快速定位到广告主的数据,DorisDB 还支持按照广告主 ID 进行 Hash 分桶,减少整个查询的数据量进行快速定位,这对高并发场景也具有非常大的意义,尽量减少了查询语句所覆盖的数据范围,提高了并发能力。
物化视图
我们利用 DorisDB 物化视图能够实时、批量构建,灵活增加删除以及透明化使用的特性,建立了基于广告主粒度、基于用户特征粒度、基于广告单元粒度、基于具体创意粒度的物化视图。基于这些物化视图,可以极大加速查询。
实时的数据导入分为两种:
在我们的查询场景中,广告主业务查询服务对查询并发度要求很高。DorisDB 采用的是 MPP 查询架构,底层数据按照 Range 和 Hash 两级分片,非常适合广告主业务的查询场景。内部做的线上查询压测结果,每个 FE 能到 2000 左右的 QPS,整个集群能提供上万的 QPS,TP99 的查询在 100 毫秒以下。
广告数据中心是非常核心的一个线上服务,因此对高可用及灵活扩容能力有非常高的要求。DorisDB 支持 fe/be 多副本,没有单节点问题,当有节点故障的时候也可以保证整个集群的高可用。另外,DorisDB 在大数据规模下可以进行在线弹性扩展,在扩容时无需下线,不会影响到在线业务,这个能力也是我们非常需要的。
小红书从今年年初开始调研引入 DorisDB,当前已经有五个 DorisDB 集群在稳定运行中,其中有两个开始稳定提供线上服务,三个还在试运行。引入 DorisDB 后,实现了数据服务统一化,大大简化了实时数据处理链路,同时也能保障较高的查询并发和较低的响应延迟要求,之后将用来提升更多业务场景的数据服务和查询能力。最后,感谢鼎石科技的大力支持,也期望 DorisDB 作为性能强悍的新一代 MPP 数据库引领者越来越好!
(作者:吴浩亮 小红书大数据团队,数据仓库架构师)
领取专属 10元无门槛券
私享最新 技术干货