基于TableStore的数据采集分析系统介绍

本文涉及的产品
对象存储 OSS,20GB 3个月
日志服务 SLS,月写入数据量 50GB 1个月
文件存储 NAS,50GB 3个月
简介: 摘要 在互联网高度发达的今天,ipad、手机等智能终端设备随处可见,运行在其中的APP、网站也非常多,如何采集终端数据进行分析,提升软件的品质非常重要,例如PV/UV统计、用户行为数据统计与分析等。虽然场景简单,但是数据量大,对系统的吞吐量、实时性、分析能力、查询能力都有较高的要求,搭建起来并不容易。

摘要

在互联网高度发达的今天,ipad、手机等智能终端设备随处可见,运行在其中的APP、网站也非常多,如何采集终端数据进行分析,提升软件的品质非常重要,例如PV/UV统计、用户行为数据统计与分析等。虽然场景简单,但是数据量大,对系统的吞吐量、实时性、分析能力、查询能力都有较高的要求,搭建起来并不容易。今天我们来介绍一下基于阿里云表格存储,以及相关的大数据产品来采集与分析数据的方案。

TableStore

TableStore(表格存储)是阿里云自主研发的专业级分布式NoSQL数据库,是基于共享存储的高性能、低成本、易扩展、全托管的半结构化数据存储平台,支撑互联网和物联网数据的高效计算与分析。

目前不管是阿里巴巴集团内部,还是外部公有云用户,都有成千上万的系统在使用。覆盖了重吞吐的离线应用,以及重稳定性,性能敏感的在线应用。表格存储的具体的特性可以看下面这张图片。

tablestore

基于TableStore的数据采集分析系统

一个典型的数据采集分析统计平台,对数据的处理,主要由如下五个步骤组成:
sjcjfxlc

对于上图流程的具体实现,网上有许多可以参考的案例,数据在客户端采集完以后,如果量比较小,我们可能直接在后端的API上做一次透传,然后持久化到RDBMS类型的数据库中就好了,通过Sql可以进行数据分析。如果数据量很大,就需要一些中间件来辅助收集和上传,然后分别将数据写入到在线和离线的系统中,比如先上传到Flume,Flume可以做数据的采集与聚合,再将Flume作为消息的生产者,将生产的消息数据通过Kafka Sink发布到Kafka中,Kafka作为消息队列的角色,可以对接后端的在线和离线计算平台。如下图所示:
ybsjcjfs

引入Flume和Kafka的原因有很多,比如他们可以处理大流量的数据、做数据聚合、保证数据不丢失等,但最关键的原因是他们拥有高吞吐的能力。引入的组件多,系统的复杂性和成本也会相应的增加,上图中,Spark Streaming/Storm分析完成以后,结果数据还需要引入另外的存储组件进行存储,比如HBase/MySQL,如果引入MySQL可能还需要再引入Redis做热点数据缓存,这样一来就更加复杂了。
我们尝试一种基于TableStore和阿里云其他大数据产品的新方案,我们先看架构图:
shujucaiji

图中关键路径分析:
1、Web页、APP等客户端先通过埋点系统收集数据,然后通过表格存储的SDK将数据写入TableStore的原始数据表。
2、MaxCompute直读TableStore原始数据表的数据进行分析,然后QuickBI读取MaxCompute的数据进行展示,具体操作可参考:MaxCompute直读直写表格存储QuickBI新建云数据源
3、TableStore原始数据表中的数据可增量同步到ElasticSearch或者openSearch中,同步方法参考:TableStore数据同步到ElasticSearchTableStore数据同步到OpenSearch
4、TableStore中的数据可增量同步到Blink/Flink进行分析,分析完以后的数据再写回TableStore的结果数据表中,DavaV读取结果数据表的数据进行展示。

新架构优势分析:
1、客户端数据直读直写TableStore,不需要再引入API层进行数据透传,降低了复杂度,对于大型应用来说也减少了不少的服务器成本。
2、TableStore已经对接了丰富了大数据组件,包括阿里云的大数据产品和开源大数据产品,数据的同步与读写非常容易。
3、实时分析与离线分析后的结果数据再写回TableStore,DataV直接读取结果数据进行展示,因为TableStore具备高性能与高吞吐特点,不需要再引入Redis等缓存组件,可以简化整个系统。

直读直写安全问题:
关于数据直读直写TableStore,大家可能都会想到一个安全的问题,客户端直连TableStore不是要把AccessKey和AccessId暴露在客户端吗?答案是不用,我们使用STSToken授权访问TableStore,过程如下图所示:
sts

TableStore提供的SDK都支持使用STS授权的方式进行访问,示例可参考TableStore NodeJs SDK使用STSToken,使用STS方式访问TableStore需要控制好授权策略,客户端不需要的接口请不要授权。

浏览器跨域访问TableStore:
如果在浏览器端直接访问TableStore,由于浏览器有同源策略的限制,会产生跨域问题。因为TableStore的EndPoint域名与用户Web站点的域名不同。解决这个问题的思路有两个:一是Web端不直接访问TableStore,改为先请求自己的Web Server端,Web Server端再使用TableStore SDK来发起请求,这样其实就是后端访问了,问题解决了但也没了我们直读直写的优势;二是TableStore服务端通过某种方式直接支持js跨域请求,这条路我们正在支持当中,当前处于开发阶段,支持的方式是cors协议支持跨域。但目前也有快捷的支持方式,如果您有浏览器直接访问TableStore的需求,可以直接联系我们,支持起来也很快。

总结

表格存储因其高性能、高吞吐、高可靠的特性,使得它在数据采集这种对后端吞吐要求很高的场景下非常适用,客户端数据直读直写表格存储,也为后端节省了中间层数据流转这一层服务,减少了复杂性也节省了成本。另外,表格存储对接了丰富的计算、分析、展示工具可以覆盖数据采集与分析的几乎所有场景,本文所介绍的周边组件也只涵盖了一部分,更多的示例与说明请参考表格存储用户指南,也欢迎加入表格存储公开交流群,钉钉群号:11789671,与我们交流。

<div align="center">![dingding | center ](http://tablestore-doc.oss-cn-hangzhou.aliyuncs.com/tablestore_dingding.jpg?x-oss-process=image/resize,m_lfit,h_400 "")<div>
相关实践学习
消息队列+Serverless+Tablestore:实现高弹性的电商订单系统
基于消息队列以及函数计算,快速部署一个高弹性的商品订单系统,能够应对抢购场景下的高并发情况。
阿里云表格存储使用教程
表格存储(Table Store)是构建在阿里云飞天分布式系统之上的分布式NoSQL数据存储服务,根据99.99%的高可用以及11个9的数据可靠性的标准设计。表格存储通过数据分片和负载均衡技术,实现数据规模与访问并发上的无缝扩展,提供海量结构化数据的存储和实时访问。 产品详情:https://www.aliyun.com/product/ots
目录
相关文章
|
3月前
|
分布式计算 搜索推荐 物联网
大数据及AI典型场景实践问题之通过KafKa+OTS+MaxCompute完成物联网系统技术重构如何解决
大数据及AI典型场景实践问题之通过KafKa+OTS+MaxCompute完成物联网系统技术重构如何解决
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
本文简要介绍了基于 MySQL 结合 Tablestore 的大规模订单系统方案。这种方案支持大数据存储、高性能数据检索、SQL搜索、实时与全量数据分析,且部署简单、运维成本低。
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
|
存储 SQL 运维
基于Tablestore 实现大规模订单系统海量订单/日志数据分类存储的实践
前言:从最早的互联网高速发展、到移动互联网的爆发式增长,再到今天的产业互联网、物联网的快速崛起,各种各样新应用、新系统产生了众多订单类型的需求,比如电商购物订单、银行流水、运营商话费账单、外卖订单、设备信息等,产生的数据种类和数据量越来越多;其中订单系统就是一个非常广泛、通用的系统。而随着数据规模的快速增长、大数据技术的发展、运营水平的不断提高,包括数据消费的能力要求越来越高,这对支撑订单系统的数据库设计、存储系统也提出了更多的要求。在新的需求下,传统的经典架构面临着诸多挑战,需要进一步思考架构优化,以更好支撑业务发展;
790 0
基于Tablestore 实现大规模订单系统海量订单/日志数据分类存储的实践
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
背景订单系统存在于各行各业,如电商订单、银行流水、运营商话费账单等,是一个非常广泛、通用的系统。对于这类系统,在过去十几年发展中已经形成了经典的做法。但是随着互联网的发展,以及各企业对数据的重视,需要存储和持久化的订单量越来越大,数据的重视程度与数据规模的膨胀带来了新的挑战。首先,订单量对于数据的存储、持久化、访问带来了挑战,这不仅增加了开发面对的困难,也为系统的运维带来了挑战。其次,随着大数据技
2660 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
|
canal 存储 SQL
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇
前言 前文架构篇,可以看到 MySQL + Tablestore 非常适合大规模订单系统这一类需求场景。那么,我们首先要做的是,利用 CDC(Change Data Capture) 技术将订单数据实时从 MySQL 同步到 Tablestore 中。对于订单系统的数据同步,我们需要关注同步的稳定性、实时性。目前,存在多款工具可以实现这一功能,他们有的是开源工具如 Canal,有的是阿里云端服务如
1093 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇
|
canal NoSQL 关系型数据库
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 Canal 篇
前言 在基于 MySQL + Tablestore 分层存储架构的大规模订单系统中,利用 CDC 技术将 MySQL 数据同步到 Tablestore 是不可缺少的一步。前文已经详细讲述了如何使用 DTS 向 Tablestore 同步数据。对于中小规模的数据库,或者个人开发者,还可以使用 Canal 从 MySQL 向 Tablestore 同步数据。Canal 部署简单,易于运维,且相比于 D
728 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 Canal 篇
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-订单搜索篇
背景在大规模订单系统中,存在以下常见需求:查询某店铺过去一段时间成交额查询某品牌商品在过去一周内的成交额查询在某店铺购物的客户列表……因此,开发者对于数据库在非主键查询、多列的自由组合查询等复杂查询需求上会有比较高的要求。传统的订单系统会使用 Elasticsearch 或者 Solr 来实现这一需求,但伴随而来的是更高的系统复杂度和更加昂贵的系统维护成本。Tablestore 的多元索引,能够支
1027 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-订单搜索篇
|
SQL 存储 NoSQL
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-SQL 查询和分析
前言前面我们介绍了基于 MySQL + Tablestore 分层架构的订单系统。订单数据储存进入 Tablestore 后,用户可以使用 SDK 中的 API 访问数据,也可以继续使用 SQL 访问 Tablestore 中的数据。Tablestore 提供了多种 SQL 的接入方式,客户可以通过 DLA 访问 Tablestore,也可以利用 Tablestore 自身对 SQL 的支持能力,
971 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-SQL 查询和分析
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-基于 DLA 的联邦查询
前言在订单系统中,基于订单数据对客户和商家商品进行画像分析是一种常见的需求。常见的分析需求有:基于主键、分区键数据的条件组合检索,例如获取某用户最近 30 的订单列表。根据非主键列、分区键的条件组合检索工作,例如查询过去一天异常订单列表、查询过去一天成交额最大的10 笔订单。聚合统计类需求,比如统计某店铺过去一个月各商品销售额排名;统计双十一期间销售额前 10 的店铺;统计双十一期间某店铺每天订单
596 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-基于 DLA 的联邦查询
|
存储 SQL 分布式计算
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据处理ETL篇
前言大数据计算服务 MaxCompute(原名 ODPS)是一种快速、完全托管的EB级数据仓库解决方案。随着数据收集手段不断丰富,行业数据大量积累,数据规模已增长到了传统软件行业无法承载的海量数据(TB、PB、EB)级别。MaxCompute 致力于批量结构化数据的存储和计算,提供海量数据仓库的解决方案及分析建模服务。它具有大规模计算存储、多种计算模型、强数据安全、低成本、免运维、极致弹性扩展的优
561 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据处理ETL篇