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

摘要： 摘要 在互联网高度发达的今天，ipad、手机等智能终端设备随处可见，运行在其中的APP、网站也很是多，如何采集终端数据进行分析，提高软件的品质很是重要，例如PV/UV统计、用户行为数据统计与分析等。虽然场景简单，可是数据量大，对系统的吞吐量、实时性、分析能力、查询能力都有较高的要求，搭建起来并不容易。

摘要

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

TableStore

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

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

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

一个典型的数据采集分析统计平台，对数据的处理，主要由以下五个步骤组成：

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

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

图中关键路径分析：
一、Web页、APP等客户端先经过埋点系统收集数据，而后经过表格存储的SDK将数据写入TableStore的原始数据表。
二、MaxCompute直读TableStore原始数据表的数据进行分析，而后QuickBI读取MaxCompute的数据进行展现，具体操做可参考：MaxCompute直读直写表格存储、QuickBI新建云数据源。
三、TableStore原始数据表中的数据可增量同步到ElasticSearch或者openSearch中，同步方法参考：TableStore数据同步到ElasticSearch，TableStore数据同步到OpenSearch。
四、TableStore中的数据可增量同步到Blink/Flink进行分析，分析完之后的数据再写回TableStore的结果数据表中，DavaV读取结果数据表的数据进行展现。

新架构优点分析：
一、客户端数据直读直写TableStore，不须要再引入API层进行数据透传，下降了复杂度，对于大型应用来讲也减小了很多的服务器成本。
二、TableStore已经对接了丰富了大数据组件，包括阿里云的大数据产品和开源大数据产品，数据的同步与读写很是容易。
三、实时分析与离线分析后的结果数据再写回TableStore，DataV直接读取结果数据进行展现，由于TableStore具有高性能与高吞吐特色，不须要再引入Redis等缓存组件，能够简化整个系统。

直读直写安全问题：
关于数据直读直写TableStore，你们可能都会想到一个安全的问题，客户端直连TableStore不是要把AccessKey和AccessId暴露在客户端吗？答案是不用，咱们使用STSToken受权访问TableStore，过程以下图所示：

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的需求，能够直接联系咱们，支持起来也很快。 做者：boxiao