秒级实时分析万亿数据，小红书OLAP引擎生活方式的进化。近年来，随着业务类型和用户量的爆发式增长，各种类型的数据分析需求和应用系统的数据需求迅速涌现，例如：商业智能分析、数据应用报告、用户行为分析、算法策略数据、ETC。。小红书大数据团队逐步推出多种OLAP分析引擎和自建引擎，更好地满足需求。目前，Flink+Doris和Flink+Clickhouse（自建版）已经成为小红书构建统一实时数据服务的核心技术方案，大大降低了数据链路开发的复杂度，提高了高并发和超快的查询能力。1、OLAP引擎在小红书的第一阶段进化史是2017年以前，数据总量不是特别大。这个阶段使用了AWS的Redshift。满足短、平、快、烟囱式发展。数据ETL和数据仓库模型展示在最终报表端，在Redshift中一站式完成。但随着业务复杂度的不断增加和数据量的快速增长，这种模式很快遇到了瓶颈。主要问题如下：Redshift无法在不影响在线查询性能的情况下进行弹性扩展。一旦涉及到扩容，就会涉及到数据的重新分布，影响集群的性能和可用性。ETL任务严重影响集群可用性。Redshift同时执行ETL任务时，会占用大量资源，影响数据分析效率，造成查询超时，甚至导致整个集群因集群负载过大而崩溃不可用.如果存储和计算没有很好的分离，数据存储容量就会出现瓶颈，无法满足随着业务快速增长的数据存储需求。第二阶段，随着数据仓库在Hadoop/Hive系统上的搭建和完善，所有的ETL任务都转移到Hadoop集群上。本阶段使用Presto完成OLAP分析。Presto和Hive自然共享元数据信息，一起使用物理数据存储，即插即用。大量对数仓表的灵活查询都是使用Presto完成的。第三阶段，业务实时性增强，对查询性能的要求不断提高，同时产生很多数据应用。这一阶段引入了ClickHouse，构建性能更强、响应时间更短的数据分析平台，满足实时性要求。第四阶段，小红书大数据团队进行了实时数仓的整体设计和建设。同时搭建数据服务平台，为各业务团队提供数据接口，对接多个内部或ToB服务应用系统。不仅需要做低延迟的复杂查询，而且对并发度的要求也很高。现阶段我们根据场景引入了Doris引擎来满足上述各种需求。第五阶段，小红书大数据团队在Clickhouse的基础上开发了Redck引擎。作为小红书的内容分享平台，用户行为特征的数据分析是最有价值的，也是最具挑战性的。有大量的日常分析场景，如功能性能、流量漏斗、用户路径、实验分析、属性分布等。这些场景都对平台具备万亿级数据的实时秒级响应和分析能力提出了很高的要求。基于这些实际的业务需求，我们利用Clickhouse天然的Mpp特性，加上自研的元数据管理、存储计算分离架构、冷热数据分层、数据实时写入等特性，来构建小红书自己的用户行为。分析平台提供高效快速的人群行为分析、实验分析和洞察能力。二、小红书数据分析系统架构1、小红书OLAP系统现状小红书整个数据分析系统由数据采集、数据存储处理/数据共享和应用层组成。数据采集??服务器日志或App日志通过Flume采集埋点日志，数据同时分发到离线存储S3和实时存储Kafka；在线业务数据库通过Canal实时采集MySQLbinlog等信息。数据存储与处理离线数据处理：利用Hive/Spark高度可扩展的批处理能力，承担离线数仓的所有ETL和数据模型处理。实时数据处理：Flink完成实时侧数据的ETL（包括丰富维度、双流Join、实时汇总）；离线表通过调度平台同步到ClickHouse/DorisDB，我们的Flink实现了ClickHouse和DorisDB的sinkconnector，落地到DorisDB或者ClickHouse。数据共享数据共享层主要为对外服务提供数据底层存储，将离线或实时数据写入相关数据库组件，提供多种服务、不同场景的查询能力。数据共享层主要包括TiDB/Hbase/ClickHouse/Doris。通过Doris和ClickHouse提供的高速OLAP查询能力，承接应用端报表平台，提供即席分析平台，为开发端提供数据接口，实现多种数据产品（如流量分析平台,用户标签平台）。应用层应用层主要是面向管理运营人员的报表，需求的并发、延迟、频繁更新等需求，以及面向数据分析师的即席查询，需要具备支持复杂SQL处理和海量数据查询的能力。2、各种OLAP分析工具的选择与比较1）Clickhouse①单表查询性能强，适用于基于大宽表的灵活即席查询。包含丰富的MergeTreeFamily，支持预聚合。非常适合编写和分析大规模的日志明细数据。②缺点不支持真正的删除和更新。Join方法不是很友好。并发度比较低。MergeTree合并不完整。2）DorisDB①优点单表查询和多表查询性能都非常强，可以更好的同时支持宽表查询场景和复杂的多表查询。支持高并发查询。支持实时数据微批量ETL处理。流式和批量数据写入都可以比较强。兼容MySQL协议和标准SQL。②劣势周边生态相对不完善。不支持某些SQL语法。3）TiDB/TiFlash①的优点是支持更新/删除。考虑到OLTP的需求。支持FlinkExactlyOnce语义和幂等性。②缺点查询性能较弱，不能很好地支持OLAP查询场景。不支持实时预聚合。TiFlash暂时不支持所有的SQL写法和函数。三、DorisDB在广告数据中心的应用实践1、业务场景概述广告业务的核心数据有两部分：一是广告的曝光点击流，即所有广告单元的销售信息；二是广告效果属性由于数据，比如小红书网站的订单转化，相关表单的提交，参与点赞，收藏，跟帖等。基于这些数据，根据不同业务场景的需求，实时汇总相关业务统计指标，对外提供查询分析服务。2、原方案1）Doris引擎引入技术架构之前，大量使用Flink任务写入MySQL/Redis/HDFS/ClickHouse实现数据落地。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本身提供了三种数据模型：详细模型/聚合模型/更新模型。对于小红书的广告业务，三种数据模型各取所需：广告曝光点击流写入聚合模型，根据业务需要的维度，如广告主、广告类型、创意、广告单元、搜索词等、地域、用户属性等设计聚合维度，根据需要的指标进行聚合。广告端后台有很多在线的MySQL，通过DorisDB更新模型连接到MySQL，进行表的实时更新。在Hadoop离线数仓中，也会定时统计一些数据报表，并同步到DorisDB中。这些数据使用了DorisDB的详细模型。2）数据分区/分桶DorisDB提供的数据分区功能可以提高广告场景下的查询性能。比如广告端查询一个常见的查询场景是查询过去某个时间段的数据。我们可以在DorisDB中按照时间进行分区，过滤掉不需要的分区数据。另外，广告查询会根据广告主进行筛选。我们使用广告主ID作为排序键的最前面，快速定位到广告主的数据。DorisDB还支持根据广告商ID进行Hash分桶，减少整个查询的数据量，对于高并发场景也有重要意义，最大限度减少查询语句覆盖的数据范围，提高并发能力。3）物化视图我们利用DorisDB物化视图实时、批量构建、灵活增删改查、透明使用的特点，建立基于广告主粒度、用户特征粒度、广告单元粒度的物化视图，以及具体的创意粒度。基于这些物化视图，可以大大加快查询速度。4）数据导入实时数据导入有两种：有ETL处理需求的会使用Flink进行ETL逻辑转换，使用FlinkDorisDBConnector写入DorisDB。在实时数仓的公共层，配置RoutineLoad任务，以10秒为单位批量写入DorisDB表。离线数据报表导入DorisDB：在DorisDB提供的原生BrokerLoad的基础上，在小红书数仓调度平台封装衍生模板，通过接口配置将离线数仓的表导入DorisDB。5）数据查询在我们的查询场景中，广告主业务查询服务对查询并发度要求很高。Doris采用MPP查询架构，底层数据按照Range和Hash切分，非常适合广告主业务的查询场景。根据内部在线查询压测结果，每个FE可以达到2000QPS左右，整个集群可以提供上万QPS，TP99的查询不到100毫秒。6）系统运维广告数据中心是非常核心的在线业务，因此对高可用和灵活扩展能力的要求非常高。Doris引擎本身支持fe/be多副本，不存在单节点问题。当有节点故障时，也能保证整个集群的高可用。另外，目前的架构在大数据规模下可以在线弹性扩容，扩容时无需下线，不影响线上业务。在此基础上，我们同时搭建了主备双活链路，并使用consul进行连接管理。一旦单个链路出现故障，所有在线查询业务可实现一体化切换。备份链路上线，主链路比对验证，主链路升级，实现下游无感知业务上线。4.总结实时系统基于Flink+Doris的整体框架搭建后，实现了数据服务的统一，大大简化了实时数据处理环节，同时查询并发度高，低可以保证响应延迟要求。目前，作为小红书数据中心的核心架构，为广告平台分众平台的重构和业务迭代，电商方舟系统和鹰眼系统的迭代和稳定运行提供底层架构支持。也将用于提升更多业务场景的数据服务和查询能力。
