性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务

这篇具有很好参考价值的文章主要介绍了性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务,flink,oceanbase,大数据

作者介绍:肖赞,贝壳找房(北京)科技有限公司 OLAP 平台负责人,基础研发线大数据平台部架构师。

贝壳找房是中国最大的居住服务平台。作为居住产业数字化服务平台,贝壳致力于推进居住服务的产业数字化、智能化进程,通过聚合、助力优质服务者,为中国家庭提供包括二手房交易、新房交易、租赁、家装、家居、家服等一站式、高品质、高效率服务。

前几天,我们在《贝壳降本提效实践:基于 OceanBase 的实时字典服务》中,介绍了实时字典服务的应用场景,在上线 OceanBase 后,贝壳获得了更高的查询性能和稳定性。今天为大家介绍 OceanBase 在贝壳的第二个应用场景——实时维表服务,通过替代原有的 HBase 维表服务,让贝壳的性能提升了 3-4 倍,硬件成本节省了一半,与此同时,运维成本获得了极大降低。

性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务,flink,oceanbase,大数据

在典型的实时数仓或实时业务场景里,Flink 实时流处理过程中,经常需要将事实表与外部维度表进行关联,查询维度表,补全事实表中的信息。例如,在贝壳家居等业务场景中,需要在用户下单后将订单信息与维度表中商品信息的相关信息进行实时关联。考虑到维表数据量较大,并且 Flink 实时查询 QPS 较高,传统数据库  MySQL 等难以支撑,因此,贝壳采用 HBase 作为维表。HBase 是一个分布式列存储 NoSQL 数据库,具有较好地查询性能,但是也存在一些痛点。

痛点 1:HBase 不支持二级索引

在许多应用场景中,Flink 任务关联维度表时,除了需要基于主键字段进行关联外,还需要其他非主键字段进行关联。但是,HBase 只支持行键(Row Key)作为单一索引,本身并不直接支持二级索引。Apache Phoenix 等项目对 HBase 的基础上进行扩展,能够实现类似于二级索引的功能,但是需要更多的开发和维护成本。

痛点 2:HBase 依赖较多,部署复杂,成本高

HBase 是构建在 Hadoop 生态系统之上的,它依赖于分布式文件系统 HDFS 用于数据的持久化存储,依赖 ZooKeeper 来完成选举、节点管理、集群元数据维护等,因此,在生产环境中部署 HBase 之前,需要先部署和配置 Hadoop、ZooKeeper 等组件,涉及组件多,部署较复杂,运维成本较高,硬件成本也较高,特别是在一些特殊场景下需要分别为其部署独立的 HBase 集群。 

性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务,flink,oceanbase,大数据

基于上述背景,贝壳将目光投向分布式数据库,并锁定具备高性能、高可靠性和可扩展性的 OceanBase。同时,OceanBase 能够很好地解决贝壳业务痛点。

首先,OceanBase 原生支持二级索引功能,可以直接在维表上创建额外的索引,提升维表的查询性能。其次,OceanBase 只有 OBServer 一个角色,不依赖任何外部组件,天然具备高可用能力,部署非常简单。同时,其自带的周边工具也可以快速安装,比如通过 OCP(OceanBase Cloud Platform)白屏化安装或通过 OBD(OceanBase Deployer)命令行安装集群,运维很方便。

在部署资源消耗方面,HBase 方案机器成本大概是 OceanBase 的 2 倍。因为 HBase 为了保证高可用, 采用了双 HRegionServer,而 HBase 又是基于三副本的 Hadoop 存储数据, 所以,一份数据通常需要六副本。在集群规模不大时,使用 Zookeeper、Hadoop 会带来大量额外的机器冗余。但是,使用 OceanBase 存储数据只需要三副本,成本降低一半。

性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务,flink,oceanbase,大数据

因此,贝壳决定在实时计算平台中引入 OceanBase 作为实时维表存储,在此之前,对 OceanBase 和 HBase 在实时维表 1 对 N 关联和维表 1 对 N 关联场景进行了全面的性能测试对比。

性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务,flink,oceanbase,大数据

第一,环境准备

OceanBase 和 HBase 测试集群均采用 3 台 Dell EMC PowerEdge R740 服务器节点组成,节点配置规格为:80C/188G/2.9T Nvme SSD,所有的测试任务均运行在同一个 Hadoop 实时集群。HBase 版本为 1.4.9,HBase 集群由 HBase DBA 协助部署和配置,OceanBase 版本为 3.1.2,使用默认配置。

第二,测试方案

首先,为验证维表数据量对于查询性能影响,分别准备了 1 亿、2000 万、10 万的随机测试数据插入 OceanBase 及 HBase,其中主键(HBase为 rowKey)为从 1 至测试数据量的顺序值,OceanBase 建表 DDL 及样例数据如下:

show create table tb_dim_benchmark_range_partitioned;create table `tb_dim_benchmark_range_partitioned`t1 bigint(20) NOT NULL,t2 varchar(200) DEFAULT NULL, ……t30 varchar(200) DEFAULT NULL,    PRIMARY KEY (`t1`)) DEFAULT CHARSET = utf8mb4  ROW_FORMAT = COMPACT  COMPRESSION = 'zstd_1.3.8' REPLICA_NUM = 3 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE =134217728 PCTFREE = 0 partition by range(t1)(partition PT1 values less than (10000000),partition PT2 values less than (20000000),partition PT3 values less than (30000000),partition PT4 values less than (40000000),partition PT5 values less than (50000000),partition PT6 values less than (60000000),partition PT7 values less than (70000000),partition PT8 values less than (80000000),partition PT9 values less than (90000000),partition PT10 values less than (100000000));
select * from tb_dim_benchmark_range_partitioned limit 1;# 10000000,c5181f1335efd950960f41cbecb1ab0ed97c43502252b99834f4b6905ea7f7490ca72e1d676bbe9b77016d23e52ada249f2c,2b5480769a360133d57f09cba16d1c449cc06b42b614bcfa3f9db6bbf7a04bac2be1d373d11c63a77676daf53111c2321b32,db88f926925d87175aa4be6740f6f2f49d8f8b38f0d0efff2e5e832f3c1aec21e06cc4f2f0b5053e0b9fbab8a16cce80b9ff,9c0b94cdde25b68264704c890d141444d28544a7ce4955856b3115f913442ec4bc741f033477e366005c927e41842a7cd9be,4d69eedaae9e42b4ab7388e66992efddfa39cbb6802cf69b97c5892070a68e6eed51f823770587771a49cbbd1b7be1f2e024,c60b30f6c4e1b3c02d6fb2de58badf8097f782a8534e0c9dc78497ede12b2573e2d9441e0596f37739d26f0830918fb03ff5,a8a01cbe3bd44e6d52b7e83bd020a23ae305713fd376a0627f610302018c39ec3aa540519dccceb764324282dfbf0bdda6cc,fd358773a94c1770980e92e66fcd9e4f70d6f3ef35dff86c65a97826698c750489682c2d1d36ab75ddb588da65b61cd6fc63,cb8a60222389c9ff9ff4e4e492a4f16ed7ea0e6b781379afc7fad78539fbf8da54b0ef8ea7ef9680543ebc0c18a908092bd1,9cdbf58a3d454d2b14ebf17167d045887ab5eb3a21d3916acc393475011a079c350295fa8b4b324dab63a00f1fbadfb22edb,cda510824ef5bc82cd4e014c851ed367dbd6da8828cc261070a0db9cc9341764baf445506a12a7eb7265434f29d63c65b3a1,8d7c4bbcd42364b93b8cae11eff8f50115e36f1f4f4e6a492687bc2374444c4eaf80e1903eb13fcdfbea6f00de999e0f0587,107b23e4b7e5a16149a8ea7f75c45c607bb5974cbbdf36077615d92591f4830ec5b2b33945d82e8e526f92cb0072cbf8a260,cda4ab39b6f2b67d1d283077a1beb01771639eff1ae371372bb2555de594699821d43509fdd7014bcf3e5098bd13c30c8199,a330f59ee2e48051362241f9a24ba1adad4b61fdd18676cd209799bbec6775dc01120abb0e157589d3f594051b5ae2dd6572,b8e98c3979610c67ea65433a560ab6cf8663c9de201ae1051a14034b317f90aaa1085b49eba3d86748677f4e0575169fb76c,6753542147a9cf38f4d040f205483a798d1d2a2c0cf2283ec98c735bf82422a8ecdea432cee8c76a00917b8add7eac5aa0b4,8d8e0c2caeed82f21ddb288affe2fb567c008e8982cb5a4d07343dc4fd6679f550856649fe4bd40eec9747485c660b01e55e,,c261014cf13c462815e0afece1512409d2549a699e33eaf8cb23b0b23719c870c83817fcaa7466d5d88a1ae240458ba0201a,2ac55e6bc39eb79694bf00c2b69768365b7833d9f0cb7df078525d9ab98eba5ce2bfc3cc1fb9f4398c49c16073fb5d863172,77ab6010d7bc664b6861927322276b2d35d4f5ff2d6bc2eec3da9ef936ae836dfbed6783a8c7f9970e19d46e43b52e49a0f6,4109f993c94f8ca40c6932d01a726fb173beb60e34b57bf488f86fe9e6c12f7f7497c720fa95099c6a43cb3442444b367ea4,7891bdf8a52dc19d311f392fa5f34509c6dcb33b8b8e291131ca5d46c517ea0933868874244aff1b3345ea5279fe0c659709,200e69e8ec8e6104834596c2fefe8ed772ba9b7de4f1287c91c3b91469dd985fbb93d55a9497b2606ae9003975458b6b054b,a2de28933b2cf1f9166cf3aab732f5c6b68967eddef0472a8577a82f37e77bcfc45a5e0adc11d382160d3c84ec14e0e75b5d,1fa6bcf4d9ef2076aa016e78db575595a9155dfe6484a9812ae690fc20c244bf2d09355ba7dbc32495330a21b6e3c893ba6b,b01a0b4ba3d8ae159d330720bb8baffe3ad2504b221151b8f68304ed7c14a03d21f75a4e6ad16873ea0c8904717478d3f7c4,a00ae3e9a8c89f5a0f0fae92934d23adeb9117ef7c91f80f0d5306eca558b77422f273283e867a6b7320e91895087e652ed7

其次,为避免测试流程中其他依赖组件(例如物理 Source、Sink)对维表关联性能造成影响,对 SQL 的测试数据源使用 DataGen SQL Connector (支持在内存中随机或顺序 生成记录)及 BlackHole SQL Connector(吞掉所有输入数据,用于性能测试)。 

​​​​​​​​​​​​​​

CREATE TABLE `data_gen_source` (`t1` BIGINT, `t2` VARCHAR, `proctime` AS PROCTIME()) WITH (  'connector' = 'datagen',  'fields.t1.kind' = 'random',  'fields.t1.min' = '1',  'fields.t1.max' = '100000',  'rows-per-second' = '100000000');CREATE TABLE `tb_dim_benchmark_1`(`t1` BIGINT,`t2` VARCHAR,……`t30` VARCHAR,PRIMARY KEY (`t1`) NOT ENFORCED) WITH (  'connector' = 'jdbc',  'url' = '',  'driver' = 'com.mysql.jdbc.Driver',  'sink.buffer-flush.max-rows' = '500',  'table-name' = 'tb_dim_benchmark_range_partitioned_10w'); CREATE TABLE blackhole_table (  `t1` BIGINT,  `t2` VARCHAR,  ……`t30` VARCHAR) WITH ('connector' = 'blackhole');
INSERT INTO blackhole_tableSELECT tb1.`t1`,tb2.`t2`,tb2.`t3`,tb2.`t4`,tb2.`t5`,tb2.`t6`,tb2.`t7`,tb2.`t8`,tb2.`t9`,tb2.`t10`,tb2.`t11`,tb2.`t12`,tb2.`t13`,tb2.`t14`,tb2.`t15`,tb2.`t16`,tb2.`t17`,tb2.`t18`,tb2.`t19`,tb2.`t21`,tb2.`t22`,tb2.`t23`,tb2.`t24`,tb2.`t25`,tb2.`t26`,tb2.`t27`,tb2.`t28`,tb2.`t29`,tb2.`t30`FROM `data_gen_source` tb1  LEFT JOIN `tb_dim_benchmark_1` FOR SYSTEM_TIME as of tb1.`proctime` as tb2 ON tb1.`t1` = tb2.`t1`;

第三,测试结果

  • 维表 1 对 1 关联,即 DataGen 生成随机值与 OceanBase(索引字段)和HBase(RowKey)关联,测试数据如下表所示。

性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务,flink,oceanbase,大数据

  • 维表 1 对 N 关联,即 DataGen 生成随机值与 OceanBase(二级索引列)关联, 测试那颗数据如下表所示。

性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务,flink,oceanbase,大数据

基于测试结果,可以得到四个结论:

  • 维表数据量在 2000 万及 1 亿条(大数据量)时,低任务并行度下的 OceanBase QPS 优于 HBase,高任务并行度下 OceanBase 相比 HBase 有 3-4 倍性能提升,优势明显。

  • 维表数据量在 10w(小数据量)时,低任务并行度下 HBase QPS 略高于 OceanBase,高并行度下 OceanBase 优势明显。

  • 对 OceanBase 使用非索引列关联性能较差,后续使用需注意大维表关联时关联字段加索引,实时计算平台可从平台功能角度优化,例如用户关联了非索引列则在 SQL 校验阶段提示用户创建索引。

  • 对 OceanBase 使用二级索引列关联(1 对 N 关联)性能良好,可满足较高 QPS 业务场景需求。

性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务,flink,oceanbase,大数据

从以上测试结果来看,在相同环境下,OceanBase 综合性能要优于 HBase,并且原生支持二级索引能力,部署简单,具有更低的硬件成本和运维成本,因此,贝壳选择使用 OceanBase 替换 HBase,作为实时计算平台的实时维表存储。

在 OceanBase 的应用过程中,贝壳也提出了一些建议:比如,发现普通的关系表不支持 TTL(当前使用的是 OceanBase 3.1.2 社区版本),经与社区沟通,OceanBase 的 3.1.4 版本已经支持 table API 或 Hbase API 等 API 模型,OceanBase 4.0 版本已经支持全局二级索引。

另外,贝壳建议 OceanBase 在与大数据生态打通(例如导入导出、计算等)方面可以进一步加强,更好地支持大数据到 OceanBase 的导入导出等。文章来源地址https://www.toymoban.com/news/detail-687709.html

到了这里,关于性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Flink动态更新维表

         概念:Lookup join是针对于由作业流表触发,关联右侧维表来补全数据的场景 。 默认情况下,在流表有数据变更,都会触发维表查询(可以通过设置维表是否缓存,来减轻查询压力),由于不保存状态,因此对内存占用较小。(以上来自网络) 具体配置如下:        

    2024年02月09日
    浏览(40)
  • 58、Flink维表的实战-6种实现方式维表的join

    一、Flink 专栏 Flink 专栏系统介绍某一知识点,并辅以具体的示例进行说明。 1、Flink 部署系列 本部分介绍Flink的部署、配置相关基础内容。 2、Flink基础系列 本部分介绍Flink 的基础部分,比如术语、架构、编程模型、编程指南、基本的datastream api用法、四大基石等内容。 3、

    2024年02月02日
    浏览(38)
  • 【flink番外篇】15、Flink维表实战之6种实现方式-维表来源于第三方数据源

    一、Flink 专栏 Flink 专栏系统介绍某一知识点,并辅以具体的示例进行说明。 1、Flink 部署系列 本部分介绍Flink的部署、配置相关基础内容。 2、Flink基础系列 本部分介绍Flink 的基础部分,比如术语、架构、编程模型、编程指南、基本的datastream api用法、四大基石等内容。 3、

    2024年01月21日
    浏览(64)
  • 【flink番外篇】15、Flink维表实战之6种实现方式-通过Temporal table实现维表数据join

    一、Flink 专栏 Flink 专栏系统介绍某一知识点,并辅以具体的示例进行说明。 1、Flink 部署系列 本部分介绍Flink的部署、配置相关基础内容。 2、Flink基础系列 本部分介绍Flink 的基础部分,比如术语、架构、编程模型、编程指南、基本的datastream api用法、四大基石等内容。 3、

    2024年01月20日
    浏览(49)
  • 阿里云高级技术专家林立翔:基于阿里云弹性GPU服务的神龙AI加速引擎,无缝提升AI训练性能

    2023 年 3 月 23 日 14:00,NVIDIA GTC 开发者大会阿里云开发者社区观看入口正式开放,阿里云高级技术专家林立翔带来了题为《基于阿里云弹性 GPU 服务的神龙 AI 加速引擎,无缝提升 AI 训练性能》的分享,以下是他的演讲内容整理。 阿里云弹性 GPU 服务是阿里云为云上客户提供的

    2024年01月17日
    浏览(47)
  • flink1.18.0 flink维表join新思路

    弊端:         虽然缓存可以减轻维表负担,但是如果事实表数据量很大,每秒千万条,维度表只有百万条,也就是说 你会看到大量的无法关联的数据仍然需要查询维度表.  cache缓存千万数据量内存压力又比较大, 那么怎么减轻维表数据库压力,还能做到低延迟. 以往双流join ; a joi

    2024年01月24日
    浏览(43)
  • 轻松通关Flink第19讲:Flink 如何做维表关联

    在实际生产中,我们经常会有这样的需求,需要以原始数据流作为基础,然后关联大量的外部表来补充一些属性。例如,我们在订单数据中,希望能得到订单收货人所在省的名称,一般来说订单中会记录一个省的 ID,那么需要根据 ID 去查询外部的维度表补充省名称属性。 在

    2024年02月13日
    浏览(44)
  • Flink:维表 Join 难点和技术方案汇总

    博主历时三年精心创作的《大数据平台架构与原型实现:数据中台建设实战》一书现已由知名IT图书品牌电子工业出版社博文视点出版发行,点击《重磅推荐:建大数据平台太难了!给我发个工程原型吧!》了解图书详情,京东购书链接:https://item.jd.com/12677623.html,扫描左侧

    2024年04月08日
    浏览(48)
  • 大数据Flink(九十):Lookup Join(维表 Join)

    文章目录 Lookup Join(维表 Join) Lookup Join 定义(支持 BatchStreaming) :Lookup Join 其实就是维表 Join,比如拿离线数仓来说,常常会有用户画像,设备画像等数据,而对应到实时数仓场景中,这种实时获取外部缓存的 Join 就叫做维表 Join。

    2024年02月04日
    浏览(42)
  • flink1.15 维表join guava cache和mysql方面优化

    优化前  mysql响应慢,导致算子中数据输出追不上输入,导致显示cpu busy:100% 优化后效果两个图对应两个时刻: - - 图中guava cache命中率是通过guava自带统计,打印出来的. 1 guava缓存数据量上限 = 类中配置的guava缓存数据上线 * task个数(即flink并行度) 缓存越久 命中率越高 数据越陈旧

    2024年01月17日
    浏览(36)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包