乐趣区

关于数据库:芒果TV-x-StarRocks极速统一的流批处理架构全新进化助力数据分析乘风破浪

jiezi

作者：黄立超、刘波澜 芒果 TV 产品技术核心数据技术部资深大数据研发工程师

StarRocks 小编导语：
在引入 StarRocks 之前，芒果 TV 的智慧经营平台架构采纳云上 EMR 平台，Hive 存储历史数据，Kudu 存储实时数据，用 Presto 做对立的查问引擎。随着业务复杂度减少，该架构面临很大的挑战，架构扩散简单，业务开发运维老本很高，查问性能也逐渐遇到瓶颈。在降级到 StarRocks 对立湖仓架构后，极大的简化了整体数据分析架构，同时综合查问性能晋升 10+ 倍。

芒果 TV 是湖南广电旗下的互联网视频平台，为年老用户带来陈腐综艺和内容剧集的高质量长视频内容。小芒是芒果 TV 旗下新潮国货内容电商平台，也是芒果 TV 长视频内容 IP 电商变现之路上的一颗新星。芒果智慧经营平台次要负责芒果 TV 会员、广告业务以及小芒的数据建设，为数据分析人员提供自助的实时数据用户行为剖析，业务数据的个性化报表搭建，自定义用户分群计算等数据分析服务，致力于突破数据孤岛，驱动产品和业务智能与增长。

原有架构与痛点

智慧经营平台数据源次要有用户行为数据与业务数据。用户行为数据由客户端埋点上报，通过 Flume 发送到 OSS 与 Kafka 原始日志 topic。OSS 数据荡涤后写入 Hive，作为离线历史数据。Kafka 数据通过 Flink 实时荡涤后写入 Kudu，作为实时数据。业务数据次要是后端服务业务库中的 MySQL 数据，通过自研数据同步平台，实时同步到 Kudu。智慧经营平台应用 Presto 作为查问引擎，将历史数据与实时数据合并，再与业务数据进行关联，提供自助式实时查问服务。

原有的技术架构中，Kudu 存储引擎满足秒级低提早批量数据插入与实时查问。数据由离线局部（Hive 表）和实时数据（Kudu 表）两局部组成，Kudu 中只保留少部分数据，这样 Kudu 存储引擎数据合并压力会小很多，整个零碎也就更加稳固。公司各部门都有本人保护的业务数据表，Presto 的联邦查问可能帮忙疾速的买通各业务数据。Presto 架构简略，可能疾速扩容应答流量压力。

随着数据业务的一直倒退，用户查问的数据量、Query 的复杂度，查问并发度都急剧增大，原有架构存在一些问题:

  • Presto 查问性能个别，无奈满足业务方心愿能疾速获取数据的需要。
  • 数据关联组件多、保护老本高。
  • 资源应用老本较高。
  • Presto 高并发反对不够，coordinator 容易成为瓶颈。
  • 短少 Bitmap 数据类型，在标签计算方面存在一些有余。

引入 StarRocks

在 2022 年年底咱们开始新的技术架构探讨和布局，咱们秉承“既要”、“又要”准则。新的数据架构既要能解决以后架构的问题，又要可能满足将来数仓存算拆散与引擎一体化的要求。

数据架构的抉择实质上就是数据引擎的抉择。那么满足咱们“既要”“又要”要求的现实数据引擎须要达到哪些条件呢？上面这些是咱们抉择新的数据引擎的规范：

  1. 高稳定性：在商业产品中，数据平台的稳定性大于所有，抛开零碎稳定性去谈查问性能优化毫无意义，咱们只有在保障系统高可用的前提下，再去思考数据查问的效率和性能。
  2. 架构简略，保护成本低：最近几年大火的 Iceberg 和 Hudi 开源数据湖解决方案就是因为其保护和治理老本较高, 咱们最终放弃抉择 Iceberg 和 Hudi。
  3. 联结查问效率高：在咱们业务实际中，仅查问单个大宽表的场景非常少，用户常常须要联结查问多张业务表，这个时候就考验数据引擎 Join 联查效率了，ClickHouse 在单表查问的时候性能极高，然而一旦波及多表联查，其查问效率就会急剧下降。基于咱们业务联结查问占比十分高，咱们在数据引擎抉择上也就放弃了 ClickHouse。
  4. 反对联邦查问：因为咱们有几千上万张的历史 Hive 表，而且咱们的业务也须要这部分数据，所以咱们心愿新的查问引擎可能和 Presto 一样，反对不同数据源的 Catalog 查问，升高咱们整体架构迁徙老本。
  5. 综合查问效率高：咱们目前在应用 Presto 查问的时候有一个问题就是查问耗时长，产品和经营同学会常常反馈查问慢，所以咱们心愿找到一款查问性能上有极致优化的引擎，可能大大降低查问响应工夫，让数据平台可能给使用者提供一个较好的体验。
  6. 自生态：尽可能少的依赖内部组件，比方不须要依赖 Hadoop 和 ZooKeeper 等这些宏大的大数据根底组件，整套零碎本身就会造成闭环的数据生态。
  7. 存算拆散：因为业务一直接入和倒退，数据越来越多，传统的存算一体计划须要应用到本地磁盘和多正本机制。这就带来了居高不下存储老本，相比之下云厂商的对象存储不仅在老本上只有本地磁盘的 1/10 而且还不须要思考多正本机制。所以将来的数据引擎，必须是领有存算拆散架构的。

综上所述，咱们在 2023 年 Q1 季度对多种数据引擎进行综合调研比照，StarRocks 因其稳定性高、查问速度快并且领有齐备的存算拆散架构特点，成为了咱们新的数据架构外围引擎最终抉择。

具体应用形式如下图所示，行为数据先通过 Flink 荡涤后写入 Kafka 荡涤日志 topic，再通过 Routine Load 将数据导入 StarRocks。业务数据通过同步平台，采纳 Stream Load 导入全量数据 +Flink 生产 Canal Binlog 增量数据的形式同步。

实际经验总结

  1. 实时同步业务库 MySQL 数据到 StarRocks：

MySQL 数据会频繁的 update/delete，局部表进行了分库分表设计，全量数据超过 20 亿，且主键为字符串类型，综合内存占用、性能等思考，采纳了主键模型 + 索引长久化，防止因主键索引占用 BE 内存过大而导致查问内存溢出。

  1. 利用物化视图减速查问：针对一些查问频率高，耗时长的查问，构建物化视图，在查问无感知的状况下实现性能减速。一些耗时几十秒到数分钟的查问，利用物化视图减速到 1 秒以内。
  2. 利用聚合模型优化数据统计：以明细数据的形式将数据实时导入聚合模型表，实现局部数据指标的聚合，升高统计延时。将原来须要按分钟、小时定时聚合的数据，升高到毫秒级实时聚合。
  3. 利用 Bitmap 类型，实现秒级海量用户标签圈选性能：在一些须要疾速圈人场景下，利用 Bitmap 的位计算能够极大晋升效率与升高资源应用。Bitmap 应用要求存入的数据为数字类型，在咱们的业务场景中，都是依据用户 uuid/did 来进行抉择，须要将字符串类型的 uuid/did 转换为数字类型。利用 StarRocks 的自增列性能，联合主键模型，局部列更新性能，实现全局字典表性能。通过 Bitmap 函数，进行用户标签圈选人数计算、用户导出，将原来耗时数秒甚至数分钟的查问，升高到毫秒级别。
#1 导入数据到用户自增 ID 表
应用 routine load，将用户行为数据导入自增 ID 表，设置局部列更新 "partial_update" = "true"

#2 用户自增 ID 表建表语句示例
CREATE TABLE `auto_user` (`did` varchar(64) NOT NULL COMMENT "",
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT "自增 id"
) ENGINE=OLAP
PRIMARY KEY(`did`)
COMMENT "用户自增 ID 表"
DISTRIBUTED BY HASH(`did`) BUCKETS 6;

#3 日沉闷用户 bitmap 表建表语句示
CREATE TABLE `active_user` (`date` int(11) NOT NULL COMMENT "",
`bm_ids` bitmap BITMAP_UNION NOT NULL COMMENT ""
) ENGINE=OLAP
AGGREGATE KEY(`date`)
COMMENT "日沉闷用户 bitmap 表"
DISTRIBUTED BY HASH(`date`) BUCKETS 3;

#4 插入数据到沉闷用户表
insert into active_user select date,to_bitmap(b.id) from event a left join auto_user b on a.did=b.did where `date`=20230501;

#5 圈人查问
查问 5 月 1 - 7 号都沉闷的用户数
select bitmap_count(bitmap_intersect(bm_ids)) from active_user where `date`>=20230501 and `date`<=20230507；查问 5 月 1 - 7 号都沉闷的用户 did：select b.id,b.did from (select unnest as id from (select bitmap_intersect(bm_ids) as bm_ids from active_user where `date`>=20230501 and `date`<=20230507) t, unnest(bitmap_to_array(bm_ids))) a inner join auto_user b on a.id=b.id;
  1. 利用 Query Cache 保留查问的两头计算结果：智慧经营平台的大部分查问都是不再变更的历史数据 + 当天的实时数据的合并，在之前的架构中，咱们基于查问性能、数据实时性、数据准确性等多方面思考，进行了简单的缓存治理。StarRocks 的 Query Cache，能将基于 Per-tablet 计算的两头后果进行缓存，反对针对分区、多版本的缓存机制，极大进步了缓存利用率，晋升了查问性能。将原有的智慧经营平台的缓存治理，交由 StarRocks 本身，使得缓存应用更加简略、高效。通过应用 Query Cache，使查问效率晋升超过 50%。
  2. 抉择 Zstd 作为压缩格局：综合比照了 StarRocks 反对的 4 种压缩格局，基于压缩比 / 查问导入性能综合比照，咱们抉择应用了更高性价比的 Zstd 作为数据压缩格局。(Zstd 比照 lz4 压缩比高 20%，查问写入性能低 5% 左右)
  3. 依据业务特点调整 Compaction 相干参数：在以 LSM-Tree 为架构的零碎中是十分要害的模块，在后期的测试中，咱们也遇到了因 Compaction 不及时带来的多种问题。依据本身业务的数据特点，咱们优化数据存储构造，调整导入、Compaction 相干参数，使 Compaction 可能及时顺利完成，保证数据写入与查问的均衡。

性能测试

在应用 StarRocks 优化后，咱们进行了 SSB 性能测试，也基于理论业务中的一些典型 Query 进行了性能测试，StarRocks 比照原有计划都有显著的性能晋升。

SSB 宽表

SSB 多表 Join

理论业务 Query

将来布局

StarRocks 在 3.0 版本中推出了存算拆散性能，使得 StarRocks 作为云原生数据湖计划成为了可能。存算拆散在存储老本、高可用、疾速扩缩容都带来了质的晋升，咱们也打算在将来构建基于 StarRocks 的云原生数据湖仓，以 StarRocks 为底座，构建新一代数据平台。

退出移动版