暂无图片
暂无图片
2
暂无图片
暂无图片
暂无图片

第一次探索HTAP系统的模型基准设计

原创 大数据模型 2022-07-03
835

国产数据库哪家强?尤其是HTAP系统谁家更好一点,国产主流上支持HTAP的产品仅有TiDB和OceanBase这两家。哪家更好一点, 用什么样的方式 去评估度量它们 最为妥当。一个好的基础系统开源项目就好像骨头,只要骨头框架够好,自然就有人给你添血加肉,我们叫做生态。 目前HTAP没有标准的基准性能测试,长久接触 OB,笔者想象了第一个HTAP典型应用场景,主要是结合应用 场景和概念定义进行真实业务场景HTAP压力测试,由于笔者水平有限,考虑不够周全,设计不够谨 慎,请多指正。

定义HTAP

从TiDB和OceanBase来看,HTAP是一个以OLTP为主, OLAP为辅的应用系统,首先用户 通过OLTP产生数据,包括转帐、核算、清算等行为,当交易数据沉淀后,快速把交易数据与其它数据整合在一起进行分析,根据用户需求,迅速反馈数据结果给前端用户,理想的情况让用户再次通过OLTP下单,反复迭代,进入下一轮的循环。某个程度上来说,OLTP模型与OLAP模型是紧密相连的。

电商本质思考

HTAP系统的最佳应用是电子商务业务场景,首先电子商务会产生大量的电子交易,同时通过业务电商画像对数据进行分析,电子商务与企业实体的关系,包括有
自动化:买家、卖家、中介、商家之间交流信息
协作:为了彼此的利益在买家、卖家、中介、商家之间共享信息和知识
电商组织:建立一个交流信息和交易的空间和平台
供应链的集成:最普遍的商业流程就是供应链的集成。在已有的系统中添加选择合作伙伴、供应商、消费者的接口,将自身供应链的一部分甚至全部集成在一起。

企业工作实体与供应链管理紧密相连的一些商业流程,包括有供应商管理、库存管理、分发管理、传播渠道管理、结算管理、财务管理、销售反馈机制

供应商管理:订单、发货、仓库存储的流程整合,保障数据一致性和准确性。
库存管理:通过在订货-运输-销售各环节间建立电子化的联系来缩短运作周期,以减少库存。
分发管理:把诸如帐单、订单、运输通告公共电子平台,从而节省资源。
传播渠道管理:在合作伙伴间快速的交流商业运作信息。技术、生产和价格等以往需要通过电话来交流
结算管理:在企业、供应商和传播者间以电子信息的方式进行结算,从而每周可以节省上百小时的 工时。
财务管理:使整个公司的资金可以集中使用几个外部帐户统一管理。
销售反馈机制:增强信息在销售者、客户、生产者之间的流动,从而能够更好的了解市场与竞争者的信息。

电商业务探索

一个支持HTAP的电子商务系统可能要考虑以下的问题

  • 支持高并发的高质量电子商务交易系统
  • 如何促进用户进行网络消费
  • 如何对已经进行消费的用户进行资产分类再引导消费
  • 如何提高活动工作赋能效率
  • 识别商品与其中零件的间接影响关系
  • 用户评价、用户收藏在用户购买行为中的权重。
  • 生产、库存和交易、订单的一致性。

以对以上问题,我们需要及时跟踪以下信息

  • 为企业相关的组织和人员建立独立实体,包括供应商、活动、用户、访问者、链接来源、商品
  • 跟踪用户的产品济览痕迹和产品购物记录以及交易记录
  • 用户的基本信息和金融帐面信息
  • 订单交易模型的上下游关系
  • 满足企业事务模型的各种关联
  • 满足购物的整个流程

难以落地的模型

根据上述需求,数据库建模如下,主要是用户实体、商品实体【拆分SPU和SKU】、活动实体为主,穿插用户浏览收藏、购物、下单、使用优惠券、交易成功、评价等行为。

image.pngimg

理想很美丽,现实很残酷,当落地实施我发现有诸多阻碍,我要从零开始开发基于上述模型 的OLTP应用以及OLAP应用,我必须十分了解熟悉业务,可能的熟悉只是我个人偏见,而技术上我开发的OLTP应用未必好。。。。。。 概念转化为现实需要大费周章。

另觅新方向

于是我把目光转向了行业成熟的OLAP基准测试tpc-h和OLTP基准测试benchmarksql。

TPC-H模拟了一个供应商和采购商之间的交易行为,主要用来评估在线分析处理的基准程序。在应用建模角度来看,它包含了OLTP重要的实体建模,其中8张表定义用户实体、订单实体、商品实体,但TPC-H进行的却是分析测试,分析业务场景如下

查询场景 查询内容 语句特点
Q1:价格统计报告查询 查询lineitem的一个定价总结报告。在单个表lineitem上查询某个时间段内,对已经付款的、已经运送的等各类商品进行统计,包括业务量的计费、发货、折扣、税、平均价格等信息。 带有分组、排序、聚集操作并存的单表查询操作。这个查询会导致表上的数据有95%到97%行被读取到。
Q2: 最小代价供货商查询 查询获得最小代价的供货商。得到给定的区域内,对于指定的零件(某一类型和大小的零件),哪个供应者能以最低的价格供应它,就可以选择哪个供应者来订货。 带有排序、聚集操作、子查询并存的多表查询操作
Q3: 运送优先级查询 查询得到收入在前10位的尚未运送的订单。在指定的日期之前还没有运送的订单中具有最大收入的订单的运送优先级(订单按照收入的降序排序)和潜在的收入(潜在的收入为l_extendedprice * (1-l_discount)的和) 带有分组、排序、聚集操作并存的三表查询操作。
Q4: 订单优先级查询 查询得到订单优先级统计值。计算给定的某三个月的订单的数量,在每个订单中至少有一行由顾客在它的提交日期之后收到。 带有分组、排序、聚集操作、子查询并存的单表查询操作。子查询是相关子查询。
Q5: 某地区供货商为公司带来的收入查询 查询得到通过某个地区零件供货商而获得的收入(收入按sum(l_extendedprice * (1 -l_discount))计算)统计信息。可用于决定在给定的区域是否需要建立一个当地分配中心。 带有分组、排序、聚集操作、子查询并存的多表连接查询操作。
Q6: 预测收入变化查询 查询得到某一年中通过变换折扣带来的增量收入。这是典型的“what-if”判断,用来寻找增加收入的途径。预测收入变化查询考虑了指定的一年中折扣在“DISCOUNT-0.01”和“DISCOUNT+0.01”之间的已运送的所有订单,求解把l_quantity小于quantity的订单的折扣消除之后总收入增加的数量 带有聚集操作的单表查询操作。查询语句使用了BETWEEN-AND操作符,有的数据库可以对BETWEEN-AND进行优化。
Q7: 货运盈利情况查询 查询从供货商国家与销售商品的国家之间通过销售获利情况的查询。此查询确定在两国之间货运商品的量用以帮助重新谈判货运合同。 带有分组、排序、聚集、子查询操作并存的多表查询操作。子查询的父层查询不存在其他查询对象,是格式相对简单的子查询。
Q8: 国家市场份额查询 查询在过去的两年中一个给定零件类型在某国某地区市场份额的变化情况。 带有分组、排序、聚集、子查询操作并存的查询操作。子查询的父层查询不存在其他查询对象,是格式相对简单的子查询,但子查询自身是多表连接的查询。
Q9: 产品类型利润估量查询 查询每个国家每一年所有被定购的零件在一年中的总利润。 带有分组、排序、聚集、子查询操作并存的查询操作。子查询的父层查询不存在其他查询对象,是格式相对简单的子查询,但子查询自身是多表连接的查询。子查询中使用了LIKE操作符,有的查询优化器不支持对LIKE操作符进行优化。
Q10: 货运存在问题的查询 查询每个国家在某时刻起的三个月内货运存在问题的客户和造成的损失。 带有分组、排序、聚集操作并存的多表连接查询操作
Q11: 库存价值查询 查询库存中某个国家供应的零件的价值。 带有分组、排序、聚集、子查询操作并存的多表连接查询操作。子查询位于分组操作的HAVING条件中。
Q12: 货运模式和订单优先级查询 查询获得货运模式和订单优先级。可以帮助决策:选择便宜的货运模式是否会导致消费者更多的在合同日期之后收到货物,而对紧急优先命令产生负面影响。 带有分组、排序、聚集操作并存的两表连接查询操作
Q13: 消费者订单数量查询 查询获得消费者的订单数量,包括过去和现在都没有订单记录的消费者。 带有分组、排序、聚集、子查询、左外连接操作并存的查询操作。
Q14: 促销效果查询 查询获得某一个月的收入中有多大的百分比是来自促销零件。用以监视促销带来的市场反应。 带有分组、排序、聚集、子查询、左外连接操作并存的查询操作。
Q15: 头等供货商查询 查询获得某段时间内为总收入贡献最多的供货商(排名第一)的信息。可用以决定对哪些头等供货商给予奖励、给予更多订单、给予特别认证、给予鼓舞等激励。 带有分排序、聚集、聚集子查询操作并存的普通表与视图的连接操作。
Q16: 零件/供货商关系查询 查询获得能够以指定的贡献条件供应零件的供货商数量。可用于决定在订单量大,任务紧急时,是否有充足的供货商。 带有分组、排序、聚集、去重、NOT IN子查询操作并存的两表连接操作。
Q17: 小订单收入查询 查询获得比平均供货量的百分之二十还低的小批量订单。对于指定品牌和指定包装类型的零件,决定在一个七年数据库的所有订单中这些订单零件的平均项目数量(过去的和未决的)。如果这些零件中少于平均数20%的订单不再被接纳,那平均一年会损失多少呢?所以此查询可用于计算出如果没有小量订单,平均年收入将损失多少(因为大量商品的货运,将降低管理费用)。 带有聚集、聚集子查询操作并存的两表连接操作。
Q18: 大订单顾客查询 查询获得比指定供货量大的供货商信息。可用于决定在订单量大,任务紧急时,验证否有充足的供货商。 带有分组、排序、聚集、IN子查询操作并存的三表连接操作。
Q19: 折扣收入查询 查询得到对一些空运或人工运输零件三个不同种类的所有订单的总折扣收入。零件的选择考虑特定品牌、包装和尺寸范围。本查询是用数据挖掘工具产生格式化代码的一个例子。 带有分组、排序、聚集、IN子查询操作并存的三表连接操作
Q20: 供货商竞争力查询 查询确定在某一年内,找出指定国家的能对某一零件商品提供更有竞争力价格的供货货。所谓更有竞争力的供货商,是指那些零件有过剩的供货商,超过供或商在某一年中货运给定国的某一零件的50%则为过剩。 带有排序、聚集、IN子查询、普通子查询操作并存的两表连接操作。
Q21: 不能按时交货供货商查询 查询获得不能及时交货的供货商。 带有分组、排序、聚集、EXISTS子查询、NOT EXISTS子查询操作并存的四表连接操作
Q22: 全球销售机会查询 查询获得消费者可能购买的地理分布。本查询计算在指定的国家,比平均水平更持肯定态度但还没下七年订单的消费者数量。能反应出普通消费者的的态度,即购买意向。 带有分组、排序、聚集、EXISTS子查询、NOT EXISTS子查询操作并存的四表连接操作。

TPH-H基准的特性是首先遵从第三范式建模,第三范式最大满足了操作型应用需求,不会发生操作异常和数据冗余,但是模型上没有符合星型,自由分析会多表关联,造成大量的计算,恰恰是HTAP系统的真实需求。关键是如何把benmarksql的OLTP特性融合进来,下面是benmarksql的模型结构。

image.png

New-Order:新订单,主要对应 new_orders 表

Payment:支付,主要对应 orders、history 表

Order-details:订单详细,主要对应 orders、Order-details表

订单orders:发货,主要对应 orders表

商店Stock-Level:主要对应库存,主要对应 stock 表

customer客户:主要对应 customer 表

distric地区:主要对应 district 表

item商品:主要对应 item 表

warehouse仓库:主要对应 warehouse 表

benchmarkSQL的事务过程包括 创建订单、订单支付、查询订单、发货以及查询库存等等,业务归纳如下

  • 新订单的提交、运行、回滚
  • 支付的提交、运行、回滚
  • 订单的提交、运行、回滚
  • 发货的提交、运行、回滚
  • 库存的确认、提交、回滚

观察benchmark的主体代码有如下文件

image.png

其中是OLTP业务逻辑内容最为直接相关的是./src/client/jTPCCConnection.java

image.png

假使我要对OceanBase进行HTAP压力测试,那么可以使用OceanBase版的benchmarkSQL,为了避免benchmarkSQL的业务侵入,benchmarkSQL的模型结构保持不变,把TPC-H的模型集成进来。

image.png

原tpc-h模型如上

当两个模型成功融合后如下,benchmarkSQL9个表与tpc-h8个表,其中用户表、订单表、地区表、商品表交叉融合,按需添加属性或删除属性。

image.png

理想的新模型同时承受BenchmarkSQL基准测试与TPC-上测试,这是HTAP压力测试的必填选项,作为一个应用系统,数据是不断在增加中,考虑通过jmeter并发插入数据。

最后,HTAP模型上已经有了一定的数据,通过jmeter继续插入数据【模仿新增用户、新增商品】,过程中我们在后台运行TPC-H测试以及BenchmarkSQL,观察收集HTAP的系统工作负担。

image.png

最后修改时间:2022-07-04 13:34:13
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

文章被以下合辑收录

评论