格存储: 数据存储和数据消费All in one

表格存储（Table Store）是阿里云自研的NoSQL多模型数据库，提供PB级结构化数据存储、千万TPS以及毫秒级延迟的服务能力。在实时计算场景里，表格存储强大的写入能力和多模型的存储形态，使其不仅可以作为计算结果表，同时也完全具备作为实时计算源表的能力。

https://help.aliyun.com/product/27278.html

通道服务是表格存储提供的全增量一体化数据消费功能，为用户提供了增量、全量和增量加全它量三种类型的分布式数据实时消费通道。实时计算场景下，通过为数据表建立数据通道，用户可以以流式计算的方式对表中历史存量和新增数据做数据消费。

https://yq.aliyun.com/articles/692516

利用表格存储存储引擎强大的写入能力和通道服务完备的流式消费能力，用户可以轻松做到数据存储和实时处理all in one！

Blink: 流批一体的数据处理引擎

Blink是阿里云在Apache Flink基础上深度改进的实时计算平台，同Flink一致Blink旨在将流处理和批处理统一，但Blink相对于社区版Flink，在稳定性上有很多优化，在某些场景特别是在大规模场景会比Flink更加稳定。Blink的另一个重大改进是实现了全新的 Flink SQL 技术栈，在功能上，Blink支持现在标准 SQL 几乎所有的语法和语义，在性能上，Blink也比社区Flink更加强大，特别是在批 SQL 的性能方面，当前 Blink 版本是社区版本性能的 10 倍以上，跟 Spark 相比，在 TPCDS 这样的场景 Blink 的性能也能达到 3 倍以上[1]。

https://help.aliyun.com/product/45029.html

从用户技术架构角度分析，结合表格存储和Blink可以做到：1. 存储侧，使用表格存储，则可以做到写一份数据，业务立即可见，同时原生支持后续流式计算消费，无需业务双写；2. 计算侧，使用Blink流批一体处理引擎，可以统一流批计算架构，开发一套代码支持流批两个需求场景。

本文就将为大家介绍实时计算的最佳架构实践：基于表格存储和Blink的实时计算架构，并带快速体验基于表格存储和Blink的数据分析job。

更优的实时计算架构：基于表格存储和Blink的实时计算架构

我们以一个做态势感知的大数据分析系统为例，为大家阐述表格存储和Blink实时计算的架构优势。假如客户是大型餐饮企业CEO，连锁店遍布全国各地，CEO非常关心自己有没有服务好全国各地的吃货，比如台湾顾客和四川顾客在口味评价上会不会有不同？自己的菜品是否已经热度下降了？为了解决这些问题，CEO需要一个大数据分析系统，一方面可以实时监控各地菜品销售额信息，另一方面也希望能有定期的历史数据分析，能给出自己关心的客户变化趋势。

用技术角度来解读，就是客户需要：1. 客户数据的实时处理能力，持续聚合新增的订单信息，能大屏展示和以日报形式展示；2.对历史数据的离线分析能力，分析离线数据做态势感知、决策推荐。

经典的解决方案基本上基于Lambda大数据架构[2]，如下图1，用户数据既需要进入消息队列系统（New Data Stream如Kafka）作为实时计算任务的输入源，又需要进入数据库系统(All Data如HBASE)来支持批处理系统，最终两者的结果写入数据库系统(MERGED VIEW)，展示给用户。

这个系统的缺点就是太庞大，需要维护多个分布式子系统，数据既要写入消息队列又要进入数据库，要处理两者的双写一致性或者维护两者的同步方案，计算方面要维护两套计算引擎、开发两套数据分析代码，技术难度和人力成本很高。

利用表格存储同时具备强大的写入能力、实时数据消费能力，Blink + SQL的高性能和流批融合，经典Lambda架构可以精简为下图2，基于表格存储和Blink的实时计算架构：

该架构引入的依赖系统大大减少，人力和资源成本都明显下降，它的基本流程只包括：

• 用户将在线订单数据或者系统抓取数据写入表格存储源表，源表创建通道服务数据通道；
• 实时计算任务(黄线)，使用Blink表格存储数据源DDL定义SQL源表和结果表，开发和调试实时订单日聚合SQL job；

https://www.atatech.org/articles/133106

• 批处理计算任务(绿线)，定义批处理源表结果表[1]，开发历史订单分析SQL job;
• 前端服务通过读取表格存储结果表展示日报和历史分析结果；

快速开始

介绍完架构，我们就来迅速开发一个基于TableStore和Blink的日报实时计算SQL，以流计算的方式统计每日各个城市的实时用餐单数和餐费销售额。

1. 在表格存储控制台创建消费订单表consume_source_table(primary key: id[string])，并在订单表->通道管理下建立增量通道blink-demo-stream, 创建日统计结果表result_summary_day(primary key: summary_date[string])；

https://ots.console.aliyun.com

2.在Blink开发界面，创建消费订单源表、日统计结果表、每分钟聚合视图和写入SQL：

---消费订单源表
CREATE TABLE source_order (
 id VARCHAR,-- 订单ID
 restaurant_id VARCHAR, --餐厅ID
 customer_id VARCHAR,--买家ID
 city VARCHAR,--用餐城市
 price VARCHAR,--餐费金额
 pay_day VARCHAR, --订单时间 yyyy-MM-dd
 primary(id)
) WITH (
 type='ots',
 endPoint='http://blink-demo.cn-hangzhou.ots-internal.aliyuncs.com',
 instanceName="blink-demo",
 tableName='consume_source_table',
 tunnelName='blink-demo-stream',
);
---日统计结果表
CREATE TABLE result_summary_day (
 summary_date VARCHAR,--统计日期
 total_price BIGINT,--订单总额
 total_order BIGINT,--订单数
 primary key (summary_date)
) WITH (
 type='ots',
 endPoint='http://blink-demo.cn-hangzhou.ots-internal.aliyuncs.com',
 instanceName="blink-demo",
 tableName='result_summary_day',
 column='summary_date,total_price,total_order'
);
INSERT into result_summary_day
select 
cast(pay_day as bigint) as summary_date, --时间分区
count(id) as total_order, --客户端的IP
sum(price) as total_order, --客户端去重
from source_ods_fact_log_track_action
group by pay_day;

1. 上线聚合SQL, 在表格存储源表写入订单数据，可以看到result_summary_day持续更新的日订单数，大屏展示系统可以根result_summary_day直接对接；

总结

使用表格存储和Blink的大数据分析架构，相对于传统开源解决方案，有很多优势：

1、强大的存储和计算引擎，表格存储除了海量存储、极高的读写性能外，还提供了多元索引、二级索引、通道服务等多种数据分析功能，相对HBASE等开源方案优势明显，Blink关键性能指标为开源Flink的3到4倍，数据计算延迟优化到秒级甚至亚秒级；

2、全托管服务，表格存储和Blink都全托管的serverless服务，即开即用；

3、低廉的人力和资源成本，依赖服务全serverless免运维，按量付费，避免波峰波谷影响；

篇幅原因，本文主要介绍了表格存储和Blink结合的大数据架构优势，以及简单SQL演示，后续更复杂、贴近场景业务的文章也会陆续推出，敬请期待！

参考文献

1. Blink解密，https://yq.aliyun.com/articles/689117

2. Lambda大数据架构，https://mapr.com/developercentral/lambda-architecture/

作者：竹千代_

.在用户没有与因特网连接时，可以正常访问站点或应用。

2.在用户与因特网连接时，更新用户机器上的缓存文件。

原理：HTML5的离线存储是基于一个新建的.appcache文件的缓存机制(不是存储技术)，通过这个文件上的解析清单离线存储资源，这些资源就会像cookie一样被存储了下来。之后当网络在处于离线状态下时，浏览器会通过被离线存储的数据进行页面展示。

如何使用：

一、页面头部像下面一样加入一个manifest的属性；

二、在cache.manifest文件的编写离线存储的资源；

CACHE MANIFEST
#v0.11

CACHE:

js/app.js
css/style.css

NETWORK:
resourse/logo.png

FALLBACK:
/ /offline.html

离线存储的manifest一般由三个部分组成:

1.CACHE:表示需要离线存储的资源列表，由于包含manifest文件的页面将被自动离线存储，所以不需要把页面自身也列出来。

2.NETWORK:表示在它下面列出来的资源只有在在线的情况下才能访问，他们不会被离线存储，所以在离线情况下无法使用这些资源。不过，如果在CACHE和NETWORK中有一个相同的资源，那么这个资源还是会被离线存储，也就是说CACHE的优先级更高。

3.FALLBACK:表示如果访问第一个资源失败，那么就使用第二个资源来替换他，比如上面这个文件表示的就是如果访问根目录下任何一个资源失败了，那么就去访问offline.html

三、在离线状态时，操作window.applicationCache进行需求实现。

TML本地存储有cookies、 localStorage 、sessionStorage、Web SQL、IndexedDB。

以下是它们的区别

1. cookies： 在HTML5标准前本地储存的主要方式，优点是兼容性好，请求头自带cookie方便，缺点是大小只有4k，自动请求头加入cookie浪费流量，每个domain限制20个cookie，使用起来麻烦需要自行封装
2. localStorage：HTML5加入的以键值对(Key-Value)为标准的方式，优点是操作方便，永久性储存（除非手动删除），大小为5M，兼容IE8+
3. sessionStorage：与localStorage基本类似，区别是sessionStorage当页面关闭后会被清理，而且与cookie、localStorage不同，他不能在所有同源窗口中共享，是会话级别的储存方式
4. Web SQL：2010年被W3C废弃的本地数据库数据存储方案，但是主流浏览器（火狐除外）都已经有了相关的实现，web sql类似于SQLite，是真正意义上的关系型数据库，用sql进行操作，当我们用JavaScript时要进行转换，较为繁琐。
5. IndexedDB： 是被正式纳入HTML5标准的数据库储存方案，它是NoSQL数据库，用键值对进行储存，可以进行快速读取操作，非常适合web场景，同时用JavaScript进行操作会非常方便。