格存儲: 數據存儲和數據消費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進行操作會非常方便。