TableStore:用户画像数据的存储和查询利器

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
对象存储 OSS,内容安全 1000次 1年
简介: TableStore是阿里云自研的在线数据平台,提供高可靠的存储,实时和丰富的查询功能,适用于结构化、半结构化的海量数据存储以及各种查询、分析。 用户画像数据是一种数据规模较大、数据结构复杂、查询种类多的数据,是公司差异化运营的基础,是打造“千人千面”、智能化的核心数据,帮产品找到最佳目标客户,对各种产品而言是一种很有价值的数据。

TableStore是阿里云自研的在线数据平台,提供高可靠的存储,实时和丰富的查询功能,适用于结构化、半结构化的海量数据存储以及各种查询、分析。

用户画像数据是一种数据规模较大、数据结构复杂、查询种类多的数据,是公司差异化运营的基础,是打造“千人千面”、智能化的核心数据,帮产品找到最佳目标客户,对各种产品而言是一种很有价值的数据。

我们接下来先看一下用户画像数据的场景和特征,仅以存储和查询的角度看一下用户画像数据的存储选择。

用户画像数据特点

数据量大

用户画像的数据有两大类,一类是用户行为日志,实时由用户的行为产生,数据规模和产品用户的数量和活跃程度相关,这部分是用户画像数据的原始素材,用来产生最终的用户画像数据,另一类就是主角:用户画像数据,这部分数据是真正的用户的画像数据,表示用户的多种维度的特征,包括用户属性、社交关系和行为偏好等。第一类数据会经过复杂的计算分析后产生第二种数据。第二种数据会被最终的各类系统用来给不同用户输送不同的内容。

数据结构复杂

用户画像数据中表示了一个用户的多重维度的特征,维度越多,数据格式越复杂,不仅有多种类型, 也有多种层次,比如用户属性、社交关系和行为偏好等:

  • 用户属性:

    • 性别:枚举。
    • 年龄:整数。
    • 职业:字符串。
  • 社交关系:

    • 同好:字符串数组。
    • 好友推荐:字符串数组。
  • 行为偏好:

    • 品牌:字符串。
    • 商圈偏好:字符串。
    • 标签:嵌套类型。

这类数据中的数据类型较多,大多数情况下还会有嵌套类型等多维数据,虽然多维数据更加复杂,但是更加自然,符合人的思维,更好理解,但是大多数分布式系统为了水平扩展而牺牲了对这种类型数据的支持。

查询种类多

用户画像数据需要被多种场景使用,一种是需要被用户行为分析系统查询,这种都是指定用户ID批量读取。再一种是被运营系统查询,这种需要按照多种维度查询,以及会有统计聚合需求,比如查询“对巴厘岛感兴趣”的所有用户,比如比较下“对巴厘岛感兴趣”和“对仙本那感兴趣”的用户的数量或者其他特征值。
上述举得两个简单例子中,就会有多种的查询需求:

  • 单Key查询。
  • 多字段组合查询。
  • 分词查询。
  • 嵌套查询。
  • 统计聚合。

针对上述的场景需求,目前业内已经有多种解决方案,我们接下来看一下:

开源解决方案

一种很容易想到的方案是使用关系型数据库,比如MySQL或PostgreSQL存储,但是这种只适合存储小数据量,如果数据量超过单机存储能力,则会不适合。就算采用了分库分表的方式,也会带来极大的运维压力和产品功能牺牲。

另外一种方案,使用HBase等分布式数据库,但是这种NoSQL数据库只提供单Key和Key前缀范围查询,无法支持按照其他属性列查询,无法满足我们上面的需求,就算引入Phoenix使用了二级索引,也需要提前固定好查询,无法支持自由组合,更无法支持嵌套查询。

还有一种方案,是从查询复杂度考虑,直接使用搜索引擎Elasticsearch或Solr,但是这种虽然能满足查询需求,可惜没法满足数据不能丢的要求,存在丢失数据的风险。

至此,考虑了所有开源系统后,没有一个系统能满足用户需求,那么只能退而求其次,采用组合的方式:
huaxiang_1

  • 存储系统使用HBase,保证数据可靠性。
  • 同步方式采用Lily Indexer。
  • 查询引擎使用solr系统。

上述架构方案,看起来满足了我们上面的所有需求,虽然麻烦了点。但是只能算是基本满足,因为这套架构存在比较大的问题:

  • Lily indexer基于HBase的日志顺序,依赖一个时间戳,推送服务需要根据时间戳进行重排序再写入,在很多场景下难以做到严格的保序,可能会丢数据。
  • 存量数据,以及solr中索引数据损坏后需要rebuild index时,需要使用运维人员通过工具去做,增加风险的同时还要只能整个系统的运维压力。

除此之外,还需要运维HBase、Lily index、Proxy和Solr四个系统,需要配备熟悉这四个开源系统的人员,这个又是一笔额外支出。除了开源解决方案外,如今又多了一种选择,使用云解决方案。

TableStore云解决方案

在现有的各种云产品中,能满足上述用户画像数据存储需求的系统并不多,阿里云TableStore是一款符合要求的系统,10年前就开始自研,多年的双十一、公有云客户的锤炼沉淀,保证了系统的可靠性和稳定性。
我们先来看一下基于TableStore存储用户画像数据的架构方案:

huaxiang_2

  • 数据存储在TableStore中,TableStore可以提供10个9的数据可靠性保障,数据可靠性更高。
  • 数据和索引都在一个系统里面,写入,读取都是通过同一套API写入和查询,易用性更高。
  • 完全满足上述提出的查询需求,包括:

    • 单Key查询。
    • 多字段组合查询。
    • 分词查询。
    • 嵌套查询。
    • 统计聚合。
  • TableStore是分布式系统,可以水平扩展,目前生产环境单表最大有几十PB,每秒写入有几千万行,完全能胜任任何大数据的写入和存储。

示例

接下来,我们举个例子帮助读者理解。
有一个大型连锁超市,有一套自己的用户画像系统,涉及的用户画像包括下列特征;

  • 用户属性:

    • 年龄
    • 性别
    • 家庭住址
    • 家庭位置
  • 社交关系:

    • 邻居
    • 可能认识的人
    • 同好
  • 行为偏好:

    • 价格敏感度
    • 商圈偏好
    • 标签:包括喜好的各种品牌
    • 周期性购买的产品


首先,我们设计TableStore中主表结构:

主键列 属性列 属性列 属性列 属性列 属性列 属性列 属性列
用户ID 年龄 家庭住址 家庭位置 可能认识的人 价格敏感度 商圈偏好 标签
String Long String String String Array bool String Array String Array
100001 39 杭州市xxx街道xxx小区 [30.295,120.059] [1002, 1003] true [{"name": "城西银泰",
"score": 0.80}{"name": "五洲国际", "score": 0.5}]
["周六"、“促销”,“距离远”]

上述表结构中,只能按照用户id查询该用户的画像,但是没法通过用户的画像属性反查用户ID,比如促销系统需要查询周六可能回来购物的用户时,就没法查询了。
为了支持属性列查询,我们需要使用多元索引功能,接下来设计多元索引的结构:

用户ID 年龄 家庭住址 家庭位置 商圈偏好 标签
String Long Text GeoPoint Nested String Array
  • 家庭地址使用Text类型,这样可以支持分词,我们就能支持按分词查询了。
  • 家庭位置是GeoPoint值,那么就可以查询某个卖场附近3公里内的用户有多少,以及特征是啥。
  • 商圈偏好:采用Nested类型,因为每个商圈不仅有名字,还有喜好度,比如0.8,这个时候就需要用Nested,而不是Array。
  • 标签:采用String Array,每个用户可以有多个标签,比如“周六”、“促销”等。

基于上述索引,我没就能支持很多钟查询了,比如:

  • 城西银泰卖场附近三公里,且喜欢促销的用户。
  • 标签中含有“促销”的用户在杭州市各大卖场附近3公里内的数量。
  • 住在“蒋村街道”,且喜欢周六购物的客户。

基于上述的表和index,我们就能满足上述提到的所有需求。

总结

开源解决方案和TableStore云解决方案都介绍完了,使用了TableStore云解决方案后,可以为架构和系统带来不少的收益。

减少运维负担

在TableStore解决方案中,用户只需要运维自己的应用程序,不需要运维任何的存储系统、查询系统和其他中间件,运维压力大大减少,同时也减少了运维方面的成本开支。
同时,TableStore是Serverless的服务化产品,用户也无需考虑运维,不需要关注扩容、水位等事项,即开即用,只需要关注功能开发即可。

系统架构更简单

在开源解决方案中6个系统,而TableStore解决方案中只有3个系统,系统数减少后,系统架构会更简单,系统可能产生的风险会更少,系统的稳定性等会更高,可以提供更优质的服务体验。

减少时间成本

TableStore云架构方案相对于开源方案,系统更少,从零开始到上线需要的开发时间更少,同时,TableStore是serverless的云服务,全球多个区域即开即用,可以大大降低客户的开发上线的时间,提前将产品推出,抢先争取市场领先优势。

服务可用性保障

TableStore作为一款云产品,提供了SLA保障,目前在可用性上是3个9的保障,可靠性是10个9的保障,这个在业内算是比较高的了,比自己搭建开源系统的可用性和可靠性都要高的多。而且,如果达不到,会有多倍赔偿,尽量让用户能安心专注产品研发和占领市场。

最后

目前,已经有大量的业务在使用TableStore,后续我们会继续优化改进TableStore,为客户持续提供一款高性能、丰富功能、低成本、高可用性的分布式系统,为客户的海量数据保驾护航。

相关实践学习
阿里云表格存储使用教程
表格存储(Table Store)是构建在阿里云飞天分布式系统之上的分布式NoSQL数据存储服务,根据99.99%的高可用以及11个9的数据可靠性的标准设计。表格存储通过数据分片和负载均衡技术,实现数据规模与访问并发上的无缝扩展,提供海量结构化数据的存储和实时访问。 产品详情:https://www.aliyun.com/product/ots
目录
相关文章
|
8月前
|
存储 索引
表格存储根据多元索引查询条件直接更新数据
表格存储是否可以根据多元索引查询条件直接更新数据?
75 3
|
1月前
|
分布式计算 DataWorks API
DataWorks常见问题之按指定条件物理删除OTS中的数据失败如何解决
DataWorks是阿里云提供的一站式大数据开发与管理平台,支持数据集成、数据开发、数据治理等功能;在本汇总中,我们梳理了DataWorks产品在使用过程中经常遇到的问题及解答,以助用户在数据处理和分析工作中提高效率,降低难度。
|
1月前
|
DataWorks NoSQL 关系型数据库
可以使用dataworks从tablestore同步数据到mysql吗?
可以使用dataworks从tablestore同步数据到mysql吗?
|
10月前
|
存储 消息中间件 监控
Tablestore 物联网存储全面升级 -- 分析存储公测
物联网存储功能介绍随着物联网技术的快速发展,物联网已广泛应用于制造业、能源、建筑、医疗、交通、物流仓储等多个领域,物联网的应用能够有效节约资源、提高效率、保障安全以及降低成本,帮助各行业实现可持续发展目标。在物联网场景中根据数据特点进行分类,数据主要包括设备元数据、设备消息数据和设备时序数据三种类型,不同类型数据的存储需求不同。物联网场景中不同类型数据的存储核心需求如下:设备元数据:主要数据为设备
226 0
Tablestore 物联网存储全面升级 -- 分析存储公测
|
NoSQL 开发工具
TableStore表格存储(阿里云OTS)多行数据操作查询,支持倒序,过滤条件和分页
1. 批量读取操作 批量读取操作可以通过多种方式进行,包括: GetRow:根据主键读取一行数据。 BatchGetRow:批量读取多行数据。 GetRange:根据范围读取多行数据。
662 0
|
存储 消息中间件 NoSQL
物联网数据通过规则引擎流转到OTS|学习笔记
快速学习物联网数据通过规则引擎流转到OTS
279 0
物联网数据通过规则引擎流转到OTS|学习笔记
|
存储 负载均衡 开发者
表格存储数据多版本介绍| 学习笔记
快速学习表格存储数据多版本介绍。
244 0
表格存储数据多版本介绍| 学习笔记
|
SQL 存储 自然语言处理
表格存储最佳实践:使用多元索引加速 SQL 查询
表格存储(Tablestore)在 2022 年 5 月正式发布了 SQL 商业化版本,业务上只需要在数据表上建立映射关系,就可以基于 SQL 引擎方便地对表格存储中的数据进行访问和计算,大大地降低了用户的学习成本。
676 0
|
存储 编解码 运维
阿里云云存储(OSS\TableStore\NAS )+CDN 产品: 更快速,更低成本|学习笔记
快速学习 阿里云云存储(OSS\TableStore\NAS )+CDN 产品:更快速,更低成本
422 0
|
存储 SQL 传感器
基于 Tablestore 时序存储的物联网数据存储方案
背景物联网时序场景是目前最火热的方向之一。海量的时序数据如汽车轨迹数据、汽车状态监控数据、传感器实时监控数据需要存放进入数据库。一般这类场景下存在如下需求数据高写入,低读取需要对写入数据进行基础的图表展示对写入数据进行聚合分析传统的关系型数据库并不适合此类场景,时序数据库脱颖而出。表格存储时序实例支持时序数据的存储,其具有如下特点:Serverless,分布式,低成本高写入支持优秀的索引能力对数据
1455 0
基于 Tablestore 时序存储的物联网数据存储方案