1、业务背景

随着闲鱼业务的发展,用户规模达到数亿级,用户维度的数据指标,达到上百个之多。如何从亿级别的数据中,快速筛选出符合期望的用户人群,进行精细化人群运营,是技术需要解决的问题。业界的很多方案常常需要分钟级甚至小时级才能生成查询结果。本文提供了一种解决大数据场景下的高效数据筛选、统计和分析方法,从亿级别数据中,任意组合查询条件,筛选需要的数据,做到毫秒级返回。

摘要:在阿里云数据库技术峰会上,阿里云高级数据库技术专家队皓庭分享了高度兼容MySQL,并且能免去传统数仓ETL过程实现数据分析,同时支持高并发、大吞吐量的在线事务处理的PB级数据存储数据库是如何实现的。

作者 | 翟娜

2、技术选型分析

从技术角度分析,我们这个业务场景有如下特点:

  1. 需要支持任意维度的组合嵌套查询,且要求低延迟;
  2. 数据规模大,至少亿级别,且需要支持不断扩展;
  3. 单条数据指标维度多,至少上百,且需要支持不断增加;综合分析,这是一个典型的OLAP场景。

下面简单对比下OLTP和OLAP:

OLTP OLAP
定义 联机事务处理 联机分析处理
应用场景 日常业务操作 分析决策,报表统计
事务要求 需要支持事务 无需事务支持
常用数据操作 读/写高并发 查询为主,并发要求相对低
实时性要求 要求不严格
DB大小 MB-GB GB-TB
数据行数 几万到几百万 亿级别甚至几十亿上百亿
数据列数 几十至上百列 百级别至千级别

最常见的数据库,如MySql、Oracle等,都采用行式存储,比较适合OLTP。如果用MySql等行数据库来实现OLAP,一般都会碰到两个瓶颈:

  1. 数据量瓶颈:mysql比较适合的数据量级是百万级,再多的话,查询和写入性能会明显下降。因此,一般会采用分库分表的方式,把数据规模控制在百万级。
  2. 查询效率瓶颈:mysql对于常用的条件查询,需要单独建立索引或组合索引。非索引字段的查询需要扫描全表,性能下降明显。

综上分析,我们的应用场景,并不适合采用行存储数据库,因此我们重点考虑列存数据库。

下面简单对比一下行式存储与列式存储的特点:

行式存储 列式存储
存储特点 同一行数据一起存储 同一列数据一起存储
读取优点 一次性读取整行数据快捷 读取单列数据快捷
读取缺点 单列读取,也需要读取整行数据 整行查询,需要重组数据
数据更新特点 INSERT/UPDATE比较方便 INSERT/UPDATE比较麻烦
索引 需要单独对查询列建索引 每一列都可以作为索引
压缩特点 同一行数据差异大,压缩比率低 一列数据由于相似性,压缩比率高

行存适合近线数据分析,比如要求查询表中某几条符合条件的记录的所有字段的场景。列存适合用于数据的统计分析。考虑如下场景:一个用于存放用户的表中有20个字段,而我们要统计用户年龄的平均值,如果是行存,则要全表扫描,遍历所有行。但如果是列存,数据库只要定位到年龄这一列,然后只扫描这一列的数据就可以得到所有的年龄,计算平均值,性能上相比行存理论上就会快20倍。而在列存数据库中,比较常见的是HBase。HBase应用的核心设计重点是rowkey的设计,一般要把常用的筛选条件,组合设计到rowkey中,通过rowkey的get或者scan查询。因此HBase比较适合有限查询条件下的非结构化数据存储。而我们的场景,由于所有字段都需要作为筛选条件,所以本质上还是需要结构化存储,且要求查询低延迟,因此也无法使用HBase。我们综合考虑集团内多款列式存储的DB产品(ADS/PostgreSQL/HBase/HybridDB),综合评估读写性能、稳定性、语法完备程度及开发和部署成本,我们选择了HybridDB
for MySQL计算规格来构建人群圈选引擎。

HybridDB for MySQL计算规格对我们的这个场景而言,核心能力主要有:

  1. 任意维度智能组合索引(使用方无需单独自建索引)
  2. 百亿大表查询毫秒级响应
  3. MySql BI生态兼容,完备SQL支持
  4. 空间检索、全文检索、复杂数据类型支持

那么,HybridDB for
MySQL计算规格是如何做到大数据场景下的任意维度组合查询的毫秒级响应的呢?

  • 首先是HybridDB的高性能列式存储引擎,内置于存储的谓词计算能力,可以利用各种统计信息快速跳过数据块实现快速筛选;
  • 第二是HybridDB的智能索引技术,在大宽表上一键自动全索引并根据列索引智能组合出各种谓词条件进行过滤;
  • 第三是高性能MPP+DAG的融合计算引擎,兼顾高并发和高吞吐两种模式实现了基于pipeline的高性能向量计算,并且计算引擎和存储紧密配合,让计算更快;
  • 第四是HybridDB支持各种数据建模技术例如星型模型、雪花模型、聚集排序等,业务适度数据建模可以实现更好的性能指标。

综合来说,HybridDB for
MySQL计算规格是以SQL为中心的多功能在线实时仓库系统,很适合我们的业务场景,因此我们在此之上构建了我们的人群圈选底层引擎。

8月24日,阿里云数据库技术峰会到来,本次技术峰会邀请到了阿里集团和阿里云数据库老司机们,为大家分享了一线数据库实践经验和技术干货。阿里云高级数据库技术专家队皓庭分享了高度兼容MySQL,并且能免去传统数仓ETL过程实现数据分析,同时支持高并发、大吞吐量的在线事务处理的PB级数据存储数据库是如何实现的,帮助大家了解了同时支持海量数据在线事务和在线分析的HTAP关系型数据库是如何打造出来的。

大数据时代,数据的价值越来越被重视,企业从海量大数据中挖掘所需要的信息,用来驱动业务决策以获得更大的商业价值。

3、业务实现

在搭建了人群圈选引擎之后,我们重点改造了我们的消息推送系统,作为人群精细化运营的一个重要落地点。

消息推送是信息触达用户最快捷的手段。闲鱼比较常用的PUSH方式,是先离线计算好PUSH人群、准备好对应PUSH文案,然后在第二天指定的时间推送。一般都是周期性的PUSH任务。但是临时性的、需要立刻发送、紧急的PUSH任务,就需要BI同学介入,每个PUSH任务平均约需要占用BI同学半天的开发时间,且操作上也比较麻烦。本次我们把人群圈选系统与原有的PUSH系统打通,极大地改善了此类PUSH的准备数据以及发送的效率,解放了开发资源。

图片 1

离线数据层:用户维度数据,分散在各个业务系统的离线表中。我们通过离线T+1定时任务,把数据汇总导入到实时计算层的用户大宽表中。

实时计算层:根据人群的筛选条件,从用户大宽表中,查询符合的用户数量和用户ID列表,为应用系统提供服务。

人群圈选前台系统:提供可视化的操作界面。运营同学选择筛选条件,保存为人群,用于分析或者发送PUSH。每一个人群,对应一个SQL存储。类似于:select
count from user_big_table where column1> 1 and column2 in and (
column31=1 or
column32=2)同时,SQL可以支持任意字段的多层and/or嵌套组合。用SQL保存人群的方式,当用户表中的数据变更时,可以随时执行SQL,获取最新的人群用户,来更新人群。

闲鱼PUSH系统:从人群圈选前台系统中获取人群对应的where条件,再从实时计算层,分页获取用户列表,给用户发送PUSH。在实现过程中,我们重点解决了分页查询的性能问题。

分页查询性能优化方案:在分页时,当人群的规模很大时,页码越往后,查询的性能会有明显下降。因此,我们采用把人群数据增加行号、导出到MySql的方式,来提升性能。表结构如下:

批次号 人群ID 行号 用户ID
1001 1 1 123
1001 1 2 234
1001 1 3 345
1001 1 4 456
  • 批次号:人群每导出一次,就新加一个批次号,批次号为时间戳,递增。
  • 行号:从1开始递增,每一个批次号对应的行号都是从1到N。

我们为”人群ID”+”批次号”+”行号”建组合索引,分页查询时,用索引查询的方式替换分页的方式,从而保证大页码时的查询效率。

另外,为此额外付出的导出数据的开销,得益于HybridDB强大的数据导出能力,数据量在万级别至百万级别,耗时在秒级至几十秒级别。综合权衡之后,采用了本方案。

本文将介绍HybridDB for
MySQL的定位和现状,以及其技术演进路线和尚待解决的问题。

与此同时,出现了越来越多的大数据技术帮助企业进行大数据分析,例如 Apache
Hadoop,Hive,Spark,Presto,Drill,以及今天我们即将介绍的 Apache Kylin
和 Apache Phoenix 项目等,都是使用 SQL
语言就可以分析大数据,极大地降低了大数据的使用门槛。

4、PUSH系统改造收益

图片 2undefined

人群圈选系统为闲鱼精细化用户运营提供了强有力的底层能力支撑。同时,圈选人群,也可以应用到其他的业务场景,比如首页焦点图定投等需要分层用户运营的场景,为闲鱼业务提供了很大的优化空间。

本文实现了海量多维度数据中组合查询的秒级返回结果,是一种OLAP场景下的通用技术实现方案。同时介绍了用该技术方案改造原有业务系统的一个应用案例,取得了很好的业务结果,可供类似需求或场景的参考。

图片 3

这些大数据技术提供 SQL 查询接口,不只是因为 SQL 学习成本低,同时也和 SQL
拥有丰富而强大的表达能力、能满足绝大多数的分析需求的特性有关系。

5、未来

人群圈选引擎中的用户数据,我们目前是T+1导入的。这是考虑到人群相关的指标,变化频率不是很快,且很多指标都是离线T+1计算的,因此T+1的数据更新频度是可以接受的。后续我们又基于HybridDB构建了更为强大的商品圈选引擎。闲鱼商品数据相比用户数据,变化更快。一方面用户随时会更新自己的商品,另一方面,由于闲鱼商品单库存的特性,以及其他原因,商品状态会随时变更。因此我们的选品引擎,应该尽快感知到这些数据的变化,并在投放层面做出实时调整。我们基于HybridDB和实时计算引擎,构建了更为强大的“马赫”实时选品系统。

本文作者:闲鱼技术-才思

阅读原文

本文为云栖社区原创内容,未经允许不得转载。

HybridDB for MySQL在RDS
MySQL的基础上做了很多拓展和改进,同时也保留了一些传统关系型数据库的特性。Hybrid是在2005年提出的HTAP数据库的概念,指混合的事务和分析处理。传统的数据库因为各方面的限制,偏向于OLTP或OLAP的场景,两者很难兼得,目前也只有Oracle勉强地解决了这个问题。但是在更大的数据场景下,因为Oracle产品价格高昂,一般用户往往难以承担。而MySQL在国内外拥有很高的知名度和用户量,从这个生态出发可以让阿里云研发团队收获更多的产品改进思路。HybridDB
for
MySQL从个角度出发,提供一种高性价比、大数据库的产品,在解决OLTP和OLAP业务的同时,维持好MySQL的生态。

了解 Apache Kylin 和 Apache Phoenix 的同学都知道,它们都是使用 Apache
HBase 做数据存储和查询,那么,同为 HBase 上的 SQL
引擎,它们之间有什么不同呢?下面我们将从这两个项目的介绍开始为大家做个深度解读和比较。

HybridDB for
MySQL在SQL兼容性方面做了很多的扩展,包括支持了TPC-H和TPC-DS这两个OLAP领域的测试集。由于是阿里云的云数据库服务,HybridDB
for
MySQL继承了RDS的云服务特征,高可靠、高可用等特性一应俱全并支持在线的扩容。目前HybridDB
for
MySQL的线上服务规模遍及国内外十多个region,为阿里云及外部的用户提供了可靠服务,总数据量已经达到TB级,日新增数据达百T级。

1、Apache Kylin

图片 4

1.1Apache Kylin 介绍

HybridDB for
MySQL的定位是使用一份数据同时支持OLTP和OLAP。它的创新包括实现了share
noting的架构,支持线性的信息扩展,以及使用了更新颖的高压缩比引擎,可以在大数据规模下有很好的表现。从定位上说,HybridDB
for
MySQL与其他分布式数据库产品各有分工。与其他阿里云数据库产品有所偏向不同,HybridDB
for MySQL在OLTP和OLAP方面均有不错的扩展能力。HybridDB for
MySQL吸收各家所长,希望提供一个通用的数据库解决方案来帮助用户解决大数据场景下基于SQL的业务问题。

Kylin 是一个分布式的大数据分析引擎,提供在 Hadoop 之上的 SQL
接口和多维分析能力,可以做到在 TB 级的数据量上实现亚秒级的查询响应。

图片 5

图片 6

2013年从单机数据库加中间件的思路出发,阿里云利用分库分表中间件形成分库分表数据库。之后,阿里云对存储和计算方面进行了大幅度的优化,支持大数据存储的同时大幅降低成本,改进了SQL兼容性。今年开始做行列混合存储引擎,期望在更高的分析领域场景提供更好的服务。明年期望把RDS的PolarDB当作存储引擎,使整套数据能够运行在共享存储上,解决棘手的运维问题。

图1 Kylin 架构

图片 7

上图是 Kylin 的架构图,从图中可以看出,Kylin 利用 MapReduce/Spark
将原始数据进行聚合计算,转成了 OLAP Cube 并加载到 HBase 中,以 Key-Value
的形式存储。Cube 按照时间范围划分为多个 segment,每个 segment 是一张
HBase 表,每张表会根据数据大小切分成多个 region。Kylin 选择 HBase
作为存储引擎,是因为 HBase
具有延迟低,容量大,使用广泛,API完备等特性,此外它的 Hadoop
接口完善,用户社区也十分活跃。

单机数据库在遇到大数据场景下有很多瓶颈,以MySQL为例,它对SQL的执行只有一个Session线程,最多只能利用一个CPU的核。当单表数据量超过千万时,它的检索显得力不从心。这时候主流搜索引擎像innoDB被加数层级会变得比较高,致使单次OLTP的查询或更新的代价更大,相应时间变高。

2、Apache Phoenix

单机数据库几乎无法解决这种问题,因为它所有的数据(数据结构和磁盘存储)都落在一台机器上,没有办法进行线性扩展。在并发密度高的环境下,不同并发线程间会资源争抢。从硬件的CPU、内存,再到软件的锁、日志和事务,都是线程密集争抢的对象。因此并发越高,数据库的整体存储下降地愈发明显。从这个角度出发,阿里云思考如何将单机数据库的性能扩展起来?

2.1 Apache Phoenix 介绍

图片 8

Phoenix 是一个 Hadoop 上的 OLTP 和业务数据分析引擎,为用户提供操作 HBase
的 SQL 接口,结合了具有完整 ACID 事务功能的标准 SQL 和 JDBC
API,以及来自 NoSQL 的后期绑定,具有读取模式灵活的优点。

传统解决方案利用中间件把一个大数据库的数据切成多个分片,集成到用户的业务代码中提高并行能力,中间件把用户的大查询拆成多个小查询,并行的计算并行的合并。这个思路让用户的代码背上了沉重的中间件,不同的用户想使用这套体系的时候还需要重复地编码。

下图为 Phoenix 的架构图,从图中可以看出,Phoenix 分为 client 和
server,其中 client 又分为 thin(本质上是一个 JDBC
驱动,所依赖的第三方类较少)和非 thin
(所依赖的第三方类较多)两种;server 是针对 thin client 而言的,为
standalone 模式,是由一台 Java 服务器组成,代表客户端管理 Phoenix
的连接,可以进行横向扩展,启动方式也很简单,通过 bin/queryserver.py
start
即可。

从这个角度出发,阿里云研发团队把中间件抽取出来加入到数据库服务器中,对外呈现同一套的数据库访问协议,让用户使用SQL连接数据库进行查询和更新。在这个过程中,中间件代理用户完成并行计算。

图片 9

整个设计思路偏向于MPP数据库。MPP数据库将用户的语句通过查询解析器、优化器翻译成一个并行控制的执行计划。这样一个执行计划可以最大程度地利用多级计算资源,将数据分而治之,所有用户都可以使用MySQL的协议去访问HybridDB
for MySQL而不再关心额外的业务代码。

图2 Phoenix 架构图

在这个设计架构下,阿里云研发团队遇到的问题及解决策略如下:

接下来我们进行一个两者的对比。

1.
事务状态机。研发团队需要解决的问题是如何维护多级间数据一致性,尤其是要与原先用户的事务特性保证兼容?研发人员引入两阶段提交来解决分布式事务的问题。用户的跨区更新可以通过两阶段提交协议来保证强一致性。

3、Kylin 和 Phoenix 的对比

2.
流式执行器。数据库服务器的内存和磁盘空间都是有限的,不能解决超大规模的查询。例如一个表做一个全局的join
in,需要把数据从各个表取出来做本地join
in,如果此时再需要按不同维度排序,很可能产生临时表,而临时表往往扛不住这种压力。所以本阶段只考虑可以流式执行的SQL,包括count、sum等聚合函数以及一个维度的order
by。

3.1 两者优缺点对比

3.
请求级连接池。连接到数据库的用户session很可能超过了单机上限。目前采取的措施是支持一个用户的请求级连接池。数据库从每一个连接请求中提取出执行计划,分析它后端引用的分区,不同的会话可以共享后端的分区连接。这样某些业务的前端并发连接高达数十万,而后端仅需要几千个连接。

我们先来看看 Kylin 和 Phoenix 各自的优点是什么。Kylin
的优点主要有以下几点:

发表评论

电子邮件地址不会被公开。 必填项已用*标注