簡(jiǎn)介：?隨著互聯(lián)網(wǎng)技術(shù)的日漸發(fā)展、數(shù)據(jù)規(guī)模的擴(kuò)大與復(fù)雜的需求場(chǎng)景的產(chǎn)生，傳統(tǒng)的大數(shù)據(jù)架構(gòu)無(wú)法承載。

作者 | 志羽
來(lái)源 | 阿里技術(shù)公眾號(hào)

一 前言

傳統(tǒng)的大數(shù)據(jù)技術(shù)起源于 Google 三架馬車(chē) GFS、MapReduce、Bigtable，以及其衍生的開(kāi)源分布式文件系統(tǒng) HDFS，分布式計(jì)算引擎 MapReduce，以及分布式數(shù)據(jù)庫(kù) HBase。最初的大數(shù)據(jù)技術(shù)與需求往往集中在超大規(guī)模數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)處理、在線查詢(xún)等。在這個(gè)階段，很多公司會(huì)選擇自建機(jī)房部署 Hadoop 的方式，大數(shù)據(jù)技術(shù)與需求集中在離線計(jì)算與大規(guī)模存儲(chǔ)上，常見(jiàn)的體現(xiàn)方式有 T+1 報(bào)表，大規(guī)模數(shù)據(jù)在線查詢(xún)等。

隨著互聯(lián)網(wǎng)技術(shù)的日漸發(fā)展、數(shù)據(jù)規(guī)模的擴(kuò)大與復(fù)雜的需求場(chǎng)景的產(chǎn)生，傳統(tǒng)的大數(shù)據(jù)架構(gòu)無(wú)法承載。大數(shù)據(jù)架構(gòu)在近些年的演進(jìn)主要體現(xiàn)下以下幾方面：

規(guī)模化：這里的規(guī)模化主要體現(xiàn)在大數(shù)據(jù)技術(shù)的使用規(guī)模上和數(shù)據(jù)規(guī)模的增長(zhǎng)。大數(shù)據(jù)技術(shù)的使用規(guī)模增長(zhǎng)代表越來(lái)越多的復(fù)雜需求產(chǎn)生，而數(shù)據(jù)規(guī)模的增長(zhǎng)決定了傳統(tǒng)的準(zhǔn)大數(shù)據(jù)技術(shù)（如 MySQL）無(wú)法解決所有問(wèn)題。因此，拿存儲(chǔ)組件舉例來(lái)說(shuō)，通常會(huì)劃分到不同的數(shù)據(jù)分層，面向規(guī)模、成本、查詢(xún)和分析性能等不同維度的優(yōu)化偏向，以滿足多樣性的需求。

實(shí)時(shí)化：傳統(tǒng)的 T+1 的離線大數(shù)據(jù)技術(shù)無(wú)法滿足推薦、監(jiān)控類(lèi)近實(shí)時(shí)的需求，整個(gè)大數(shù)據(jù)生態(tài)和技術(shù)架構(gòu)在過(guò)去十年發(fā)生了很大的升級(jí)換代。就存儲(chǔ)上來(lái)說(shuō)，傳統(tǒng)的 HDFS 文件存儲(chǔ)、Hive 數(shù)倉(cāng)無(wú)法滿足低成本，可更新迭代的需求，因此滋生出 Hudi 等數(shù)據(jù)方案。就計(jì)算上來(lái)說(shuō)，傳統(tǒng)的 MapReduce 批處理的能力無(wú)法做到秒級(jí)的數(shù)據(jù)處理，先后出現(xiàn) Storm 較原始的實(shí)時(shí)處理和 Spark Streaming 的微批處理，目前由 Flink 基于 Dataflow 模型的實(shí)時(shí)計(jì)算框架在實(shí)時(shí)計(jì)算領(lǐng)域占據(jù)絕對(duì)主導(dǎo)地位。

云原生化：傳統(tǒng)的公司往往會(huì)選擇自建機(jī)房，或者在云上購(gòu)買(mǎi)機(jī)器部署實(shí)例這種云托管的形式，但這種架構(gòu)存在低谷期利用率低，存儲(chǔ)計(jì)算不分離導(dǎo)致的存儲(chǔ)和計(jì)算彈性差，以及升級(jí)靈活度低等各種問(wèn)題。云原生大數(shù)據(jù)架構(gòu)就是所謂的數(shù)據(jù)湖，其本質(zhì)就是充分利用云上的彈性資源來(lái)實(shí)現(xiàn)一個(gè)統(tǒng)一管理、統(tǒng)一存儲(chǔ)、彈性計(jì)算的大數(shù)據(jù)架構(gòu)，變革了傳統(tǒng)大數(shù)據(jù)架構(gòu)基于物理集群和本地磁盤(pán)的計(jì)算存儲(chǔ)架構(gòu)。其主要技術(shù)特征是存儲(chǔ)和計(jì)算分離和 Serverless。在云原生大數(shù)據(jù)架構(gòu)中，每一層架構(gòu)都在往服務(wù)化的趨勢(shì)演進(jìn)，存儲(chǔ)服務(wù)化、計(jì)算服務(wù)化、元數(shù)據(jù)管理服務(wù)化等。每個(gè)組件都被要求拆分成不同的單元，具備獨(dú)立擴(kuò)展的能力，更開(kāi)放、更靈活、更彈性。

本篇文章將基于云原生大數(shù)據(jù)架構(gòu)的場(chǎng)景，詳細(xì)討論實(shí)時(shí)計(jì)算中的維表和結(jié)果表的架構(gòu)選型。

二 大數(shù)據(jù)架構(gòu)中的實(shí)時(shí)計(jì)算

1 實(shí)時(shí)計(jì)算場(chǎng)景

大數(shù)據(jù)的高速發(fā)展已經(jīng)超過(guò) 10 年，大數(shù)據(jù)也正在從計(jì)算規(guī)模化向更加實(shí)時(shí)化的趨勢(shì)演進(jìn)。實(shí)時(shí)計(jì)算場(chǎng)景主要有以下幾種最常見(jiàn)的場(chǎng)景：

實(shí)時(shí)數(shù)倉(cāng)：實(shí)時(shí)數(shù)倉(cāng)主要應(yīng)用在網(wǎng)站 PV / UV 統(tǒng)計(jì)、交易數(shù)據(jù)統(tǒng)計(jì)、商品銷(xiāo)量統(tǒng)計(jì)等各類(lèi)交易型數(shù)據(jù)場(chǎng)景中。在這種場(chǎng)景下，實(shí)時(shí)計(jì)算任務(wù)通過(guò)訂閱業(yè)務(wù)實(shí)時(shí)數(shù)據(jù)源，將信息實(shí)時(shí)秒級(jí)分析，最終呈現(xiàn)在業(yè)務(wù)大屏中給決策者使用，方便判斷企業(yè)運(yùn)營(yíng)狀況和活動(dòng)促銷(xiāo)的情況。

實(shí)時(shí)推薦：實(shí)時(shí)推薦主要是基于 AI 技術(shù)，根據(jù)用戶喜好進(jìn)行個(gè)性化推薦。常見(jiàn)于短視頻場(chǎng)景、內(nèi)容資訊場(chǎng)景、電商購(gòu)物等場(chǎng)景。在這種場(chǎng)景下，通過(guò)用戶的歷史點(diǎn)擊情況實(shí)時(shí)判斷用戶喜好，從而進(jìn)行針對(duì)性推薦，以達(dá)到增加用戶粘性的效果。

數(shù)據(jù) ETL：實(shí)時(shí)的 ETL 場(chǎng)景常見(jiàn)于數(shù)據(jù)同步任務(wù)中。比如數(shù)據(jù)庫(kù)中不同表的同步、轉(zhuǎn)化，或者是不同數(shù)據(jù)庫(kù)的同步，或者是進(jìn)行數(shù)據(jù)聚合預(yù)處理等操作，最終將結(jié)果寫(xiě)入數(shù)據(jù)倉(cāng)庫(kù)或者數(shù)據(jù)湖進(jìn)行歸檔沉淀。這種場(chǎng)景主要是為后續(xù)的業(yè)務(wù)深度分析進(jìn)行前期準(zhǔn)備工作。

實(shí)時(shí)診斷：這種常見(jiàn)于金融類(lèi)或者是交易類(lèi)業(yè)務(wù)場(chǎng)景。在這些場(chǎng)景中，針對(duì)行業(yè)的獨(dú)特性，需要有反作弊監(jiān)管，根據(jù)實(shí)時(shí)短時(shí)間之內(nèi)的行為，判定用戶是否為作弊用戶，做到及時(shí)止損。該場(chǎng)景對(duì)時(shí)效性要求極高，通過(guò)實(shí)時(shí)計(jì)算任務(wù)對(duì)異常數(shù)據(jù)檢測(cè)，實(shí)時(shí)發(fā)現(xiàn)異常并進(jìn)行及時(shí)止損。

2 Flink SQL 實(shí)時(shí)計(jì)算

實(shí)時(shí)計(jì)算需要后臺(tái)有一套極其強(qiáng)大的大數(shù)據(jù)計(jì)算能力，Apache Flink 作為一款開(kāi)源大數(shù)據(jù)實(shí)時(shí)計(jì)算技術(shù)應(yīng)運(yùn)而生。由于傳統(tǒng)的 Hadoop、Spark 等計(jì)算引擎，本質(zhì)上是批計(jì)算引擎，通過(guò)對(duì)有限的數(shù)據(jù)集進(jìn)行數(shù)據(jù)處理，其處理時(shí)效性是不能保證的。而 Apache Flink ，從設(shè)計(jì)之初就以定位為流式計(jì)算引擎，它可以實(shí)時(shí)訂閱實(shí)時(shí)產(chǎn)生的流式數(shù)據(jù)，對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)分析處理并產(chǎn)生結(jié)果，讓數(shù)據(jù)在第一時(shí)間發(fā)揮價(jià)值。

Flink 選擇了 SQL 這種聲明式語(yǔ)言作為頂層 API，方便用戶使用，也符合云原生大數(shù)據(jù)架構(gòu)的趨勢(shì)：

大數(shù)據(jù)普惠，規(guī)模生產(chǎn)：Flink SQL 能夠根據(jù)查詢(xún)語(yǔ)句自動(dòng)優(yōu)化，生成最優(yōu)的物理執(zhí)行計(jì)劃，屏蔽大數(shù)據(jù)計(jì)算中的復(fù)雜性，大幅降低用戶使用門(mén)檻，以達(dá)到大數(shù)據(jù)普惠的效果。

流批一體：Flink SQL 具備流批統(tǒng)一的特性，無(wú)論是流任務(wù)還是批處理任務(wù)都給用戶提供相同的語(yǔ)義和統(tǒng)一的開(kāi)發(fā)體驗(yàn)，方便業(yè)務(wù)離線任務(wù)轉(zhuǎn)實(shí)時(shí)。

屏蔽底層存儲(chǔ)差異：Flink 通過(guò)提供 SQL 統(tǒng)一查詢(xún)語(yǔ)言，屏蔽底層數(shù)據(jù)存儲(chǔ)的差異，方便業(yè)務(wù)在多樣性的大數(shù)據(jù)存儲(chǔ)中進(jìn)行靈活切換，對(duì)云上大數(shù)據(jù)架構(gòu)進(jìn)行更開(kāi)放、靈活的調(diào)整。

上圖是 Flink SQL 的一些基本操作。可以看到 SQL 的語(yǔ)法和標(biāo)準(zhǔn) SQL 非常類(lèi)似，示例中包括了基本的 SELECT、FILTER 操作，可以使用內(nèi)置函數(shù)（如日期的格式化），也可以在注冊(cè)函數(shù)后使用自定義函數(shù)。

Flink SQL 將實(shí)時(shí)計(jì)算拆分成源表，結(jié)果表和維表三種，將這三種表的 DDL 語(yǔ)句（比如 CREATE TABLE）注冊(cè)各類(lèi)輸入、輸出的數(shù)據(jù)源，通過(guò) SQL 的 DML（比如 INSERT INTO）表示實(shí)時(shí)計(jì)算任務(wù)的拓?fù)潢P(guān)系，以達(dá)到通過(guò) SQL 完成實(shí)時(shí)計(jì)算任務(wù)開(kāi)發(fā)的效果。

源表：主要代表消息系統(tǒng)類(lèi)的輸入，比如 Kafka，MQ（Message Queue），或者 CDC（Change Data Capture，例如將 MySQL binlog 轉(zhuǎn)換成實(shí)時(shí)流）輸入。

結(jié)果表：主要代表 Flink 將每條實(shí)時(shí)處理完的數(shù)據(jù)寫(xiě)入的目標(biāo)存儲(chǔ)，如 MySQL，HBase 等數(shù)據(jù)庫(kù)。

維表：主要代表存儲(chǔ)數(shù)據(jù)維度信息的數(shù)據(jù)源。在實(shí)時(shí)計(jì)算中，因?yàn)閿?shù)據(jù)采集端采集到的數(shù)據(jù)往往比較有限，在做數(shù)據(jù)分析之前，就要先將所需的維度信息補(bǔ)全，而維表就是代表存儲(chǔ)數(shù)據(jù)維度信息的數(shù)據(jù)源。常見(jiàn)的用戶維表有 MySQL，Redis 等。

下圖是一個(gè)完整的實(shí)時(shí)計(jì)算示例，示例中的 Flink SQL 任務(wù)，這個(gè)任務(wù)的目標(biāo)是計(jì)算每分鐘不同商品分類(lèi)的 GMV (Gross Merchandise Volume，即商品交易總額)。在這個(gè)任務(wù)中，Flink 實(shí)時(shí)消費(fèi)用戶訂單數(shù)據(jù)的 Kafka 源表，通過(guò) Redis 維表將商品 id 關(guān)聯(lián)起來(lái)獲取到商品分類(lèi)，按照 1 分鐘間隔的滾動(dòng)窗口按商品分類(lèi)將總計(jì)的交易金額計(jì)算出來(lái)，將最后的結(jié)果寫(xiě)入 RDS（Relational Database Service，如 MySQL） 結(jié)果表中。

# 源表 - 用戶訂單數(shù)據(jù)，代表某個(gè)用戶（user_id）在 timestamp 時(shí)按 price 的價(jià)格購(gòu)買(mǎi)了商品（item_id） CREATE TEMPORARY TABLE user_action_source (`timestamp` BIGINT,`user_id` BIGINT,`item_id` BIGINT,`price` DOUBLE,SQs ) WITH ('connector' = 'kafka','topic' = '<your_topic>','properties.bootstrap.servers' = 'your_kafka_server:9092','properties.group.id' = '<your_consumer_group>''format' = 'json','scan.startup.mode' = 'latest-offset' );# 維表 - 物品詳情 CREATE TEMPORARY TABLE item_detail_dim (id STRING,catagory STRING,PRIMARY KEY (id) NOT ENFORCED ) WITH ('connector' = 'redis','host' = '<your_redis_host>','port' = '<your_redis_port>','password' = '<your_redis_password>','dbNum' = '<your_db_num>' );# 結(jié)果表 - 按時(shí)間（分鐘）和分類(lèi)的 GMV 輸出 CREATE TEMPORARY TABLE gmv_output (time_minute STRING,catagory STRING,gmv DOUBLE,PRIMARY KEY (time_minute, catagory) ) WITH (type='rds',url='<your_jdbc_mysql_url_with_database>',tableName='<your_table>',userName='<your_mysql_database_username>',password='<your_mysql_database_password>' );# 處理過(guò)程 INSERT INTO gmv_output SELECT TUMBLE_START(s.timestamp, INTERVAL '1' MINUTES) as time_minute,d.catagory,SUM(d.price) as gmv FROMuser_action_source sJOIN item_detail_dim FOR SYSTEM_TIME AS OF PROCTIME() as dON s.item_id = d.id GROUP BY TUMBLE(s.timestamp, INTERVAL '1' MINUTES), d.catagory;

這是一個(gè)很常見(jiàn)的實(shí)時(shí)計(jì)算的處理鏈路。后續(xù)章節(jié)中，我們將針對(duì)實(shí)時(shí)計(jì)算的維表和結(jié)果表的關(guān)鍵能力進(jìn)行展開(kāi)分析，并分別進(jìn)行架構(gòu)選型的討論。

三 實(shí)時(shí)計(jì)算維表

1 關(guān)鍵需求

在數(shù)據(jù)倉(cāng)庫(kù)的建設(shè)中，一般都會(huì)圍繞著星型模型和雪花模型來(lái)設(shè)計(jì)表關(guān)系或者結(jié)構(gòu)。實(shí)時(shí)計(jì)算也不例外，一種常見(jiàn)的需求就是為數(shù)據(jù)流補(bǔ)齊字段。因?yàn)閿?shù)據(jù)采集端采集到的數(shù)據(jù)往往比較有限，在做數(shù)據(jù)分析之前，就要先將所需的維度信息補(bǔ)全。比如采集到的交易日志中只記錄了商品 id，但是在做業(yè)務(wù)時(shí)需要根據(jù)店鋪維度或者行業(yè)緯度進(jìn)行聚合，這就需要先將交易日志與商品維表進(jìn)行關(guān)聯(lián)，補(bǔ)全所需的維度信息。這里所說(shuō)的維表與數(shù)據(jù)倉(cāng)庫(kù)中的概念類(lèi)似，是維度屬性的集合，比如商品維度、用戶度、地點(diǎn)維度等等。

作為保存用戶維度信息的數(shù)據(jù)存儲(chǔ)，需要應(yīng)對(duì)實(shí)時(shí)計(jì)算場(chǎng)景下的海量低延時(shí)訪問(wèn)。根據(jù)這樣的定位，我們總結(jié)下對(duì)結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)的幾個(gè)關(guān)鍵需求：

1. 高吞吐與低延時(shí)的讀取能力

首當(dāng)其沖，在不考慮開(kāi)源引擎 Flink 自身維表的優(yōu)化外，維表必須能承擔(dān)實(shí)時(shí)計(jì)算場(chǎng)景下的海量（上萬(wàn) QPS）的數(shù)據(jù)訪問(wèn)，也能在極低（毫秒級(jí)別）的延時(shí)下返回查詢(xún)數(shù)據(jù)。

2. 與計(jì)算引擎的高整合能力

在維表自身的能力之外，出于性能、穩(wěn)定性和成本的考慮，計(jì)算引擎自身往往也會(huì)有些流量卸載的能力，在一些情況下無(wú)需每次請(qǐng)求都需要去訪問(wèn)下游維表。例如，Flink 在維表場(chǎng)景下支持 Async IO 和緩存策略等優(yōu)化特性。一個(gè)比較好的維表需要和開(kāi)源計(jì)算引擎有著較高程度的對(duì)接，一方面可以提升計(jì)算層的性能，一方面也可以有效的卸載部分流量，保障維表不被過(guò)多訪問(wèn)擊穿，并降低維表的計(jì)算成本。

3. 輕存儲(chǔ)下的計(jì)算能力的彈性

維表通常是一張共享表，存儲(chǔ)維度屬性等元數(shù)據(jù)信息，訪問(wèn)規(guī)模往往較大，而存儲(chǔ)規(guī)模往往不會(huì)特別大。對(duì)維表的訪問(wèn)規(guī)模極大地依賴(lài)實(shí)時(shí)數(shù)據(jù)流的數(shù)據(jù)量。比如，如果實(shí)時(shí)流的數(shù)據(jù)規(guī)模擴(kuò)大了數(shù)十倍，此時(shí)對(duì)維表的訪問(wèn)次數(shù)會(huì)大大提升；又比如，如果新增了多個(gè)實(shí)時(shí)計(jì)算任務(wù)訪問(wèn)該維表，該維表的查詢(xún)壓力會(huì)激增。在這些場(chǎng)景下，存儲(chǔ)規(guī)模往往不會(huì)顯著增加。

所以，計(jì)算最好是按需的，是彈性的。無(wú)論是新增或者下線實(shí)時(shí)計(jì)算任務(wù)，或者增加訪問(wèn)流量，都不會(huì)影響訪問(wèn)性能。同時(shí)，計(jì)算和存儲(chǔ)是應(yīng)該分離的，不會(huì)單純因?yàn)樵L問(wèn)計(jì)算量的激增就增加存儲(chǔ)成本。

2 架構(gòu)選型

MySQL

大數(shù)據(jù)和實(shí)時(shí)計(jì)算技術(shù)起步之初，互聯(lián)網(wǎng)早期大量流行 LAMP （Linux + Apache + MySQL + PHP）架構(gòu)快速開(kāi)發(fā)站點(diǎn)。因此，由于業(yè)務(wù)歷史數(shù)據(jù)已經(jīng)存在 MySQL 中，在最初的實(shí)時(shí)計(jì)算維表選型中大量使用 MySQL 作為維表。

隨著大數(shù)據(jù)架構(gòu)的更新，MySQL 云上架構(gòu)也在不斷改進(jìn)，但在維表的應(yīng)用場(chǎng)景下仍然存在以下問(wèn)題：

存儲(chǔ)側(cè)擴(kuò)展靈活性差，擴(kuò)展成本較高：MySQL 在存儲(chǔ)側(cè)的擴(kuò)展需要進(jìn)行數(shù)據(jù)復(fù)制遷移，擴(kuò)展周期長(zhǎng)且靈活性差。同時(shí) MySQL 的分庫(kù)分表每次擴(kuò)展需要雙倍資源，擴(kuò)展成本較高。

存儲(chǔ)成本高：關(guān)系數(shù)據(jù)庫(kù)是結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)單位成本最高的存儲(chǔ)系統(tǒng)，所以對(duì)于大數(shù)據(jù)場(chǎng)景來(lái)說(shuō)，關(guān)系型數(shù)據(jù)庫(kù)存儲(chǔ)成本較高。

以上這些限制使 MySQL 在大數(shù)據(jù)維表場(chǎng)景下存在性能瓶頸，成本也比較高。但總體來(lái)說(shuō)，MySQL 是非常優(yōu)秀的數(shù)據(jù)庫(kù)產(chǎn)品，在數(shù)據(jù)規(guī)模不怎么大的場(chǎng)景下，MySQL 絕對(duì)是個(gè)不錯(cuò)的選擇。

Redis

在云上應(yīng)用架構(gòu)中，由于 MySQL 難以承載不斷增加的業(yè)務(wù)負(fù)載，往往會(huì)使用 Redis 作為 MySQL 的查詢(xún)結(jié)果集緩存，幫助 MySQL 來(lái)抵御大部分的查詢(xún)流量。

在這種架構(gòu)中，MySQL 作為主存儲(chǔ)服務(wù)器，Redis 作為輔助存儲(chǔ)，MySQL 到 Redis 的同步可以通過(guò) binlog 實(shí)時(shí)同步或者 MySQL UDF + 觸發(fā)器的方式實(shí)現(xiàn)。在這種架構(gòu)中，Redis 可以用來(lái)緩存提高查詢(xún)性能，同時(shí)降低 MySQL 被擊穿的風(fēng)險(xiǎn)。

由于在 Redis 中緩存了一份弱一致性的用戶數(shù)據(jù)，Redis 也常常用來(lái)作為實(shí)時(shí)計(jì)算的維表。相比于 MySQL 作為維表，Redis 有著獨(dú)特的優(yōu)勢(shì)：

查詢(xún)性能極高：數(shù)據(jù)高速緩存在內(nèi)存中，可以通過(guò)高速 Key-Value 形式進(jìn)行結(jié)果數(shù)據(jù)查詢(xún)，非常符合維表高性能查詢(xún)的需求。

存儲(chǔ)層擴(kuò)展靈活性高：Redis 可以非常方便的擴(kuò)展分片集群，進(jìn)行橫向擴(kuò)展，支持?jǐn)?shù)據(jù)多副本的持久化。

Redis 有其突出的優(yōu)點(diǎn)，但也有一個(gè)不可忽視的缺陷：雖然 Redis 有著不錯(cuò)的擴(kuò)展方案，但由于高速緩存的數(shù)據(jù)存在內(nèi)存中，成本較高，如果遇到業(yè)務(wù)數(shù)據(jù)的維度屬性較大（比如用戶維度、商品維度）時(shí)，使用 Redis 作為維表存儲(chǔ)時(shí)成本極高。

Tablestore

Tablestore是阿里云自研的結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)產(chǎn)品，具體產(chǎn)品介紹可以參考官網(wǎng)以及權(quán)威指南。在大數(shù)據(jù)維表的場(chǎng)景下，Tablestore 有著獨(dú)特的優(yōu)勢(shì)：

高吞吐訪問(wèn)：Tablestore 采用了存儲(chǔ)計(jì)算分離架構(gòu)，可以彈性擴(kuò)展計(jì)算資源，支持高吞吐下的數(shù)據(jù)查詢(xún)。

低延時(shí)查詢(xún)：Tablestore 按照 LSM 存儲(chǔ)引擎實(shí)現(xiàn)，支持 Block Cache 加速查詢(xún)，用戶也通過(guò)配置豐富的索引，優(yōu)化業(yè)務(wù)查詢(xún)。

低成本存儲(chǔ)和彈性計(jì)算成本：在存儲(chǔ)成本上，Tablestore 屬于結(jié)構(gòu)化 NoSQL 存儲(chǔ)類(lèi)型，數(shù)據(jù)存儲(chǔ)成本比起關(guān)系型數(shù)據(jù)庫(kù)或者高速緩存要低很多；在計(jì)算成本上，Tablestore 采用了存儲(chǔ)計(jì)算架構(gòu)，可以按需彈性擴(kuò)展計(jì)算資源。

與 Flink 維表優(yōu)化的高度對(duì)接：Tablestore 支持 Flink 維表優(yōu)化的所有策略，包括 Async IO 和不同緩存策略。

方案對(duì)比

上面是前文提到的幾個(gè)維表方案在各個(gè)維度的對(duì)比。接下來(lái)，將舉幾個(gè)具體的場(chǎng)景細(xì)致對(duì)比下成本：

1.高存儲(chǔ)高計(jì)算：維表需要存 100 億條訂單維度的數(shù)據(jù)，總計(jì)存儲(chǔ)量需要 1T，盡管業(yè)務(wù)在 Flink 任務(wù)端配置了緩存策略，但仍然有較高的 KV 查詢(xún)下沉到維表，到維表的 QPS 峰值 10 萬(wàn)，均值 2.5 萬(wàn)。不同維表所需的配置要求和購(gòu)買(mǎi)成本如下：

2.低存儲(chǔ)低計(jì)算：維表需要存 100 萬(wàn)條地域維度的數(shù)據(jù)，總計(jì)存儲(chǔ)量需要 10M，業(yè)務(wù)端在 Flink 任務(wù)中的維表配置了 LRU 緩存策略抵御了絕大部分的流量，到維表的 QPS 峰值 1000 均值 250。不同維表所需的配置要求和購(gòu)買(mǎi)成本如下：

3.高存儲(chǔ)低計(jì)算：維表需要存 100 億條訂單維度的數(shù)據(jù)，總計(jì)存儲(chǔ)量需要 1T，業(yè)務(wù)端在 Flink 任務(wù)中的維表配置了 LRU 緩存策略抵御了絕大部分的流量，到維表的 QPS 峰值 1000 均值 250。不同維表所需的配置要求和購(gòu)買(mǎi)成本如下：

4.低存儲(chǔ)高計(jì)算：Redis 作為內(nèi)存數(shù)據(jù)庫(kù)，具有超高頻的數(shù)據(jù) KV 查詢(xún)能力，僅 4 核 8G 內(nèi)存的 Redis集群，即可支持 16 萬(wàn) QPS的并發(fā)訪問(wèn)，成本預(yù)計(jì) 1600 元 / 月，在低存儲(chǔ)高計(jì)算場(chǎng)景有著鮮明的成本優(yōu)勢(shì)。

從上面的成本對(duì)比報(bào)告中可見(jiàn)：

1）MySQL 由于缺乏存儲(chǔ)和計(jì)算的彈性，以及關(guān)系型數(shù)據(jù)庫(kù)固有的缺點(diǎn)，在不同程度的存儲(chǔ)和計(jì)算規(guī)模下成本均較高。

2）Redis 作為內(nèi)存數(shù)據(jù)庫(kù)，在低存儲(chǔ)（約 128G 以下）高計(jì)算場(chǎng)景有著鮮明的成本優(yōu)勢(shì)，但由于內(nèi)存存儲(chǔ)成本很高、缺乏彈性，隨著數(shù)據(jù)規(guī)模的提升，成本呈指數(shù)增長(zhǎng)。

3）Tablestore 基于云原生架構(gòu)可以按量對(duì)存儲(chǔ)和計(jì)算進(jìn)行彈性，在數(shù)據(jù)存儲(chǔ)和訪問(wèn)規(guī)模不大時(shí)成本較低。

4）Tablestore 作為 NoSQL 數(shù)據(jù)庫(kù)存儲(chǔ)成本很低，在高存儲(chǔ)（128G 以上）場(chǎng)景下有著鮮明的成本優(yōu)勢(shì)。

四 實(shí)時(shí)計(jì)算結(jié)果表

1 需求分析

結(jié)果表作為實(shí)時(shí)計(jì)算完成后數(shù)據(jù)導(dǎo)入的存儲(chǔ)系統(tǒng)，主要可分為關(guān)系數(shù)據(jù)庫(kù)、搜索引擎、結(jié)構(gòu)化大數(shù)據(jù)離線存儲(chǔ)、結(jié)構(gòu)化大數(shù)據(jù)在線存儲(chǔ)幾種分類(lèi)，具體差異通過(guò)以下表格進(jìn)行了歸納。

對(duì)于這幾種數(shù)據(jù)產(chǎn)品，在各自場(chǎng)景下各有優(yōu)勢(shì)，起源的先后也各有不同。為了方便探究，我們將問(wèn)題域縮小，僅僅考慮實(shí)時(shí)計(jì)算的場(chǎng)景下，一個(gè)更好的結(jié)果表存儲(chǔ)需要承擔(dān)什么樣的角色。

上文提到了實(shí)時(shí)計(jì)算的主要幾個(gè)場(chǎng)景中，實(shí)時(shí)數(shù)倉(cāng)，實(shí)時(shí)推薦，實(shí)時(shí)監(jiān)控三個(gè)場(chǎng)景需要考慮結(jié)果表的選型。我們一一分析。

實(shí)時(shí)數(shù)倉(cāng)：實(shí)時(shí)數(shù)倉(cāng)主要應(yīng)用在網(wǎng)站實(shí)時(shí) PV / UV 統(tǒng)計(jì)、交易數(shù)據(jù)統(tǒng)計(jì)等實(shí)時(shí)分析場(chǎng)景。實(shí)時(shí)分析（即OLAP）場(chǎng)景分為預(yù)聚合、搜索引擎和 MPP（Massively Parallel Processing，即大規(guī)模并行處理）三種 OLAP 模型。對(duì)于預(yù)聚合模型來(lái)說(shuō)，可以通過(guò) Flink 計(jì)算層進(jìn)行數(shù)據(jù)聚合寫(xiě)入結(jié)果表，也可以全量寫(xiě)入結(jié)果表中，通過(guò)結(jié)果表自身的預(yù)聚合能力進(jìn)行數(shù)據(jù)存儲(chǔ)，在這種形態(tài)中極大地依賴(lài)結(jié)果表數(shù)據(jù)查詢(xún)與分析能力的支撐。對(duì)于搜索引擎模型來(lái)說(shuō)，數(shù)據(jù)將全量寫(xiě)入結(jié)果表中，通過(guò)搜索引擎的倒排索引和列存特性進(jìn)行數(shù)據(jù)分析，在這種形態(tài)中需要結(jié)果表有高吞吐的數(shù)據(jù)寫(xiě)入能力和大規(guī)模數(shù)據(jù)存儲(chǔ)能力。MPP 模型是計(jì)算引擎，如果訪問(wèn)的是列式存儲(chǔ)，可以更好地發(fā)揮分析查詢(xún)特性。實(shí)時(shí) OLAP 存儲(chǔ)和計(jì)算引擎眾多，在一個(gè)完整的數(shù)據(jù)系統(tǒng)架構(gòu)下，需要有多個(gè)存儲(chǔ)組件并存。并且根據(jù)對(duì)查詢(xún)和分析能力的不同要求，需要數(shù)據(jù)派生派生能力在必要時(shí)擴(kuò)展到其他類(lèi)型存儲(chǔ)。另外，實(shí)時(shí)數(shù)倉(cāng)中隨著業(yè)務(wù)規(guī)模的擴(kuò)大，存儲(chǔ)量會(huì)大幅增長(zhǎng)，相較來(lái)說(shuō)數(shù)據(jù)查詢(xún)等計(jì)算規(guī)模變化一般不會(huì)特別明顯，所以結(jié)果表需要做到存儲(chǔ)和計(jì)算成本分離，極大地控制資源成本。

實(shí)時(shí)推薦：實(shí)時(shí)推薦主要是根據(jù)用戶喜好進(jìn)行個(gè)性化推薦，在常見(jiàn)的用戶商品個(gè)性化推薦場(chǎng)景下，一種常見(jiàn)的做法是將用戶的特征寫(xiě)入結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)（如 HBase ）中，而該存儲(chǔ)將作為維表另一條用戶點(diǎn)擊消費(fèi)行為數(shù)據(jù)進(jìn)行關(guān)聯(lián)，提取出用戶特征與行為關(guān)聯(lián)輸入，作為推薦算法的輸入。這里的存儲(chǔ)既需要作為結(jié)果表提供高吞吐的數(shù)據(jù)寫(xiě)入能力，也需要作為維表提供高吞吐低延時(shí)的數(shù)據(jù)在線查詢(xún)能力。

實(shí)時(shí)監(jiān)控：應(yīng)用的實(shí)時(shí)監(jiān)控常見(jiàn)于金融類(lèi)或者是交易類(lèi)業(yè)務(wù)場(chǎng)景，該場(chǎng)景對(duì)時(shí)效性要求極高，通過(guò)對(duì)異常數(shù)據(jù)檢測(cè)，可以實(shí)時(shí)發(fā)現(xiàn)異常情況而做出一個(gè)止損的行為。在這種場(chǎng)景下無(wú)論是通過(guò)閾值進(jìn)行判斷還是通過(guò)異常檢測(cè)算法，都需要實(shí)時(shí)低延時(shí)的數(shù)據(jù)聚合查詢(xún)能力。

2 關(guān)鍵能力

通過(guò)以上的需求分析，我們可以總結(jié)出幾項(xiàng)實(shí)時(shí)大數(shù)據(jù)結(jié)果表的關(guān)鍵能力：

1.大規(guī)模數(shù)據(jù)存儲(chǔ)

結(jié)果表存儲(chǔ)的定位是集中式的大規(guī)模存儲(chǔ)，作為在線數(shù)據(jù)庫(kù)的匯總，或者是實(shí)時(shí)計(jì)算（或者是離線）的輸入和輸出，必須要能支撐 PB 級(jí)規(guī)模數(shù)據(jù)存儲(chǔ)。

2.豐富的數(shù)據(jù)查詢(xún)與聚合分析能力

結(jié)果表需要擁有豐富的數(shù)據(jù)查詢(xún)與聚合分析能力，需要為支撐高效在線查詢(xún)做優(yōu)化。常見(jiàn)的查詢(xún)優(yōu)化包括高速緩存、高并發(fā)低延遲的隨機(jī)查詢(xún)、復(fù)雜的任意字段條件組合查詢(xún)以及數(shù)據(jù)檢索。這些查詢(xún)優(yōu)化的技術(shù)手段就是緩存和索引，其中索引的支持是多元化的，面向不同的查詢(xún)場(chǎng)景提供不同類(lèi)型的索引。例如面向固定組合查詢(xún)的基于 B+tree 的二級(jí)索引，面向地理位置查詢(xún)的基于 R-tree 或 BKD-tree 的空間索引或者是面向多條件組合查詢(xún)和全文檢索的倒排索引。

3.高吞吐寫(xiě)入能力

實(shí)時(shí)計(jì)算的數(shù)據(jù)表需要能承受大數(shù)據(jù)計(jì)算引擎的海量結(jié)果數(shù)據(jù)集導(dǎo)出。所以必須能支撐高吞吐的數(shù)據(jù)寫(xiě)入，通常會(huì)采用一個(gè)為寫(xiě)入而優(yōu)化的存儲(chǔ)引擎。

4.數(shù)據(jù)派生能力

一個(gè)完整的數(shù)據(jù)系統(tǒng)架構(gòu)下，需要有多個(gè)存儲(chǔ)組件并存。并且根據(jù)對(duì)查詢(xún)和分析能力的不同要求，需要在數(shù)據(jù)派生體系下對(duì)存儲(chǔ)進(jìn)行動(dòng)態(tài)擴(kuò)展。所以對(duì)于大數(shù)據(jù)存儲(chǔ)來(lái)說(shuō)，也需要有能擴(kuò)展存儲(chǔ)的派生能力，來(lái)擴(kuò)展數(shù)據(jù)處理能力。而判斷一個(gè)存儲(chǔ)組件是否具備更好的數(shù)據(jù)派生能力，就看是否具備成熟的 CDC 技術(shù)。

5.云原生架構(gòu)：存儲(chǔ)與計(jì)算成本分離

在云原生大數(shù)據(jù)架構(gòu)中，每一層架構(gòu)都在往服務(wù)化的趨勢(shì)演進(jìn)，存儲(chǔ)服務(wù)化、計(jì)算服務(wù)化、元數(shù)據(jù)管理服務(wù)化等。每個(gè)組件都被要求拆分成不同的單元，作為結(jié)果表也不例外，需要具備獨(dú)立擴(kuò)展的能力，更開(kāi)放、更靈活、更彈性。

單就從結(jié)果表來(lái)說(shuō)，只有符合云原生架構(gòu)的組件，即基于存儲(chǔ)計(jì)算分離架構(gòu)實(shí)現(xiàn)的產(chǎn)品，才能做到存儲(chǔ)和計(jì)算成本的分離，以及獨(dú)立擴(kuò)展。存儲(chǔ)和計(jì)算分離的優(yōu)勢(shì)，在大數(shù)據(jù)系統(tǒng)下會(huì)更加明顯。舉一個(gè)簡(jiǎn)單的例子，結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)的存儲(chǔ)量會(huì)隨著數(shù)據(jù)的積累越來(lái)越大，但是數(shù)據(jù)寫(xiě)入量是相對(duì)平穩(wěn)的。所以存儲(chǔ)需要不斷的擴(kuò)大，但是為了支撐數(shù)據(jù)寫(xiě)入或臨時(shí)的數(shù)據(jù)分析而所需的計(jì)算資源，則相對(duì)來(lái)說(shuō)比較固定，是按需的。

3 架構(gòu)選型

MySQL

和維表一樣，大數(shù)據(jù)和實(shí)時(shí)計(jì)算技術(shù)起步之初，MySQL 是一個(gè)萬(wàn)能存儲(chǔ)，幾乎所有需求都可以通過(guò) MySQL 來(lái)完成，因此應(yīng)用規(guī)模非常廣，結(jié)果表也不例外。隨著數(shù)據(jù)規(guī)模的不斷擴(kuò)展和需求場(chǎng)景的日漸復(fù)雜，MySQL 有點(diǎn)難以承載，就結(jié)果表的場(chǎng)景下主要存在以下問(wèn)題：

大數(shù)據(jù)存儲(chǔ)成本高：這個(gè)在之前討論維表時(shí)已經(jīng)提到，關(guān)系數(shù)據(jù)庫(kù)單位存儲(chǔ)成本非常高。

單一存儲(chǔ)系統(tǒng)，提供的查詢(xún)能力有限：隨著數(shù)據(jù)規(guī)模的擴(kuò)大，MySQL 讀寫(xiě)性能的不足問(wèn)題逐漸顯現(xiàn)了出來(lái)。另外，隨著分析類(lèi) AP 需求的產(chǎn)生，更適合 TP 場(chǎng)景的 MySQL 查詢(xún)能力比較有限。

高吞吐數(shù)據(jù)寫(xiě)入能力較差：作為 TP 類(lèi)的關(guān)系型數(shù)據(jù)庫(kù)，并不是特別擅長(zhǎng)高吞吐的數(shù)據(jù)寫(xiě)入。

擴(kuò)展性差，擴(kuò)展成本較高：這個(gè)在之前討論維表時(shí)已經(jīng)提到，MySQL 在存儲(chǔ)側(cè)的擴(kuò)展需要進(jìn)行數(shù)據(jù)復(fù)制遷移，且需要雙倍資源，因此擴(kuò)展靈活性差，成本也比較高。

以上這些限制使 MySQL 在大數(shù)據(jù)結(jié)果表場(chǎng)景下存在性能瓶頸，成本也比較高，但作為關(guān)系型數(shù)據(jù)庫(kù)，不是特別適合作為大數(shù)據(jù)的結(jié)果表使用。

HBase

由于關(guān)系型數(shù)據(jù)庫(kù)的天然瓶頸，基于 BigTable 概念的分布式 NoSQL 結(jié)構(gòu)化數(shù)據(jù)庫(kù)應(yīng)運(yùn)而生。目前開(kāi)源界比較知名的結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)是 Cassandra 和 HBase，Cassandra 是 WideColumn 模型 NoSQL 類(lèi)別下排名 Top-1 的產(chǎn)品，在國(guó)外應(yīng)用比較廣泛。這篇文章中，我們重點(diǎn)提下在國(guó)內(nèi)應(yīng)用更多的 HBase。 HBase 是基于 HDFS 的存儲(chǔ)計(jì)算分離架構(gòu)的 WideColumn 模型數(shù)據(jù)庫(kù)，擁有非常好的擴(kuò)展性，能支撐大規(guī)模數(shù)據(jù)存儲(chǔ)，它的優(yōu)點(diǎn)為：

大數(shù)據(jù)規(guī)模存儲(chǔ)，支持高吞吐寫(xiě)入：基于 LSM 實(shí)現(xiàn)的存儲(chǔ)引擎，支持大規(guī)模數(shù)據(jù)存儲(chǔ)，并為寫(xiě)入優(yōu)化設(shè)計(jì)，能提供高吞吐的數(shù)據(jù)寫(xiě)入。

存儲(chǔ)計(jì)算分離架構(gòu)：底層基于 HDFS，分離的架構(gòu)可以按需對(duì)存存儲(chǔ)和計(jì)算分別進(jìn)行彈性擴(kuò)展。

開(kāi)發(fā)者生態(tài)成熟，與其他開(kāi)源生態(tài)整合較好：作為發(fā)展多年的開(kāi)源產(chǎn)品，在國(guó)內(nèi)也有比較多的應(yīng)用，開(kāi)發(fā)者社區(qū)很成熟，與其他開(kāi)源生態(tài)如 Hadoop，Spark 整合較好。

HBase有其突出的優(yōu)點(diǎn)，但也有幾大不可忽視的缺陷：

查詢(xún)能力弱，幾乎不支持?jǐn)?shù)據(jù)分析：提供高效的單行隨機(jī)查詢(xún)以及范圍掃描，復(fù)雜的組合條件查詢(xún)必須使用 Scan + Filter 的方式，稍不注意就是全表掃描，效率極低。HBase 的 Phoenix 提供了二級(jí)索引來(lái)優(yōu)化查詢(xún)，但和 MySQL 的二級(jí)索引一樣，只有符合最左匹配的查詢(xún)條件才能做索引優(yōu)化，可被優(yōu)化的查詢(xún)條件非常有限。

數(shù)據(jù)派生能力弱：前面章節(jié)提到 CDC 技術(shù)是支撐數(shù)據(jù)派生體系的核心技術(shù)，HBase 不具備 CDC 技術(shù)。

非云原生 Serverless 服務(wù)模式，成本高：前面提到結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)的關(guān)鍵需求之一是存儲(chǔ)與計(jì)算的成本分離，HBase 的成本取決于計(jì)算所需 CPU 核數(shù)成本以及磁盤(pán)的存儲(chǔ)成本，基于固定配比物理資源的部署模式下 CPU 和存儲(chǔ)永遠(yuǎn)會(huì)有一個(gè)無(wú)法降低的最小比例關(guān)系。即隨著存儲(chǔ)空間的增大，CPU 核數(shù)成本也會(huì)相應(yīng)變大，而不是按實(shí)際所需計(jì)算資源來(lái)計(jì)算成本。因此，只有云原生的 Serverless 服務(wù)模式，才要達(dá)到完全的存儲(chǔ)與計(jì)算成本分離。

運(yùn)維復(fù)雜：HBase 是標(biāo)準(zhǔn)的 Hadoop 組件，最核心依賴(lài)是 Zookeeper 和 HDFS，沒(méi)有專(zhuān)業(yè)的運(yùn)維團(tuán)隊(duì)幾乎無(wú)法運(yùn)維。

國(guó)內(nèi)的高級(jí)玩家大多會(huì)基于 HBase 做二次開(kāi)發(fā)，基本都是在做各種方案來(lái)彌補(bǔ) HBase 查詢(xún)能力弱的問(wèn)題，根據(jù)自身業(yè)務(wù)查詢(xún)特色研發(fā)自己的索引方案，例如自研二級(jí)索引方案、對(duì)接 Solr 做全文索引或者是針對(duì)區(qū)分度小的數(shù)據(jù)集的 bitmap 索引方案等等。總的來(lái)說(shuō)，HBase 是一個(gè)優(yōu)秀的開(kāi)源產(chǎn)品，有很多優(yōu)秀的設(shè)計(jì)思路值得借鑒。

HBase + Elasticsearch

為了解決 HBase 查詢(xún)能力弱的問(wèn)題，國(guó)內(nèi)很多公司通過(guò) Elasticsearch 來(lái)加速數(shù)據(jù)檢索，按照 HBase + Elasticsearch 的方案實(shí)現(xiàn)他們的架構(gòu)。其中，HBase 用于做大數(shù)據(jù)存儲(chǔ)和歷史冷數(shù)據(jù)查詢(xún)，Elasticsearch 用于數(shù)據(jù)檢索，其中，由于 HBase 不具備 CDC 技術(shù)，所以需要業(yè)務(wù)方應(yīng)用層雙寫(xiě) HBase 和 Elasticsearch，或者啟動(dòng)數(shù)據(jù)同步任務(wù)將 HBase 同步至 Elasticsearch。

這個(gè)方案能通過(guò) Elasticsearch 極大地補(bǔ)足 HBase 查詢(xún)能力弱的問(wèn)題，但由于 HBase 和 Elasticsearch 本身的一些能力不足，會(huì)存在以下幾個(gè)問(wèn)題：

開(kāi)發(fā)成本高，運(yùn)維更加復(fù)雜：客戶要維護(hù)至少兩套集群，以及需要完成 HBase 到 Elasticsearch 的數(shù)據(jù)同步。如果要保證 HBase 和 Elasticsearch 的一致性，需要通過(guò)前文提到的應(yīng)用層多寫(xiě)的方式，這不是解耦的架構(gòu)擴(kuò)展起來(lái)比較復(fù)雜。另外整體架構(gòu)比較復(fù)雜，涉及的模塊和技術(shù)較多，運(yùn)維成本也很高。

成本很高：客戶需要購(gòu)買(mǎi)兩套集群，以及維護(hù) HBase 和 Elasticsearch 的數(shù)據(jù)同步，資源成本很高。

仍沒(méi)有數(shù)據(jù)派生能力：這套架構(gòu)中，只是將數(shù)據(jù)分別寫(xiě)入 HBase 和 Elasticsearch 中，而 HBase 和 Elasticsearch 均沒(méi)有 CDC 技術(shù)，仍然無(wú)法靈活的將數(shù)據(jù)派生到其他系統(tǒng)中。

Tablestore

Tablestore 是阿里云自研的結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)產(chǎn)品，具體產(chǎn)品介紹可以參考官網(wǎng)以及權(quán)威指南。Tablestore 的設(shè)計(jì)理念很大程度上顧及了數(shù)據(jù)系統(tǒng)內(nèi)對(duì)結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)的需求，并且基于派生數(shù)據(jù)體系這個(gè)設(shè)計(jì)理念專(zhuān)門(mén)設(shè)計(jì)和實(shí)現(xiàn)了一些特色的功能。簡(jiǎn)單概括下 Tablestore 的技術(shù)理念：

大規(guī)模數(shù)據(jù)存儲(chǔ)，支持高吞吐寫(xiě)入：LSM 和 B+ tree 是主流的兩個(gè)存儲(chǔ)引擎實(shí)現(xiàn)，其中 Tablestore 基于 LSM 實(shí)現(xiàn)，支持大規(guī)模數(shù)據(jù)存儲(chǔ)，專(zhuān)為高吞吐數(shù)據(jù)寫(xiě)入優(yōu)化。

通過(guò)多元化索引，提供豐富的查詢(xún)能力：LSM 引擎特性決定了查詢(xún)能力的短板，需要索引來(lái)優(yōu)化查詢(xún)。而不同的查詢(xún)場(chǎng)景需要不同類(lèi)型的索引，所以 Tablestore 提供多元化的索引來(lái)滿足不同類(lèi)型場(chǎng)景下的數(shù)據(jù)查詢(xún)需求。

支持 CDC 技術(shù)，提供數(shù)據(jù)派生能力：Tablestore 的 CDC 技術(shù)名為 Tunnel Service，支持全量和增量的實(shí)時(shí)數(shù)據(jù)訂閱，并且能無(wú)縫對(duì)接 Flink 流計(jì)算引擎來(lái)實(shí)現(xiàn)表內(nèi)數(shù)據(jù)的實(shí)時(shí)流計(jì)算。

存儲(chǔ)計(jì)算分離架構(gòu)：采用存儲(chǔ)計(jì)算分離架構(gòu)，底層基于飛天盤(pán)古分布式文件系統(tǒng)，這是實(shí)現(xiàn)存儲(chǔ)計(jì)算成本分離的基礎(chǔ)。

云原生架構(gòu)，Serverless 產(chǎn)品形態(tài)，免運(yùn)維：云原生架構(gòu)的最關(guān)鍵因素是存儲(chǔ)計(jì)算分離和 Serverless 服務(wù)化，只有存儲(chǔ)計(jì)算分離和 Serverless 服務(wù)才能實(shí)現(xiàn)一個(gè)統(tǒng)一管理、統(tǒng)一存儲(chǔ)、彈性計(jì)算的云原生架構(gòu)。由于是 Serverless 產(chǎn)品形態(tài)，業(yè)務(wù)方無(wú)需部署和維護(hù) Tablestore，極大地降低用戶的運(yùn)維成本。

方案對(duì)比

舉一個(gè)具體的場(chǎng)景，結(jié)果表需要存千億級(jí)別的電商訂單交易數(shù)據(jù)，總計(jì)存儲(chǔ)量需要 1T，用戶需要對(duì)于這類(lèi)數(shù)據(jù)進(jìn)行查詢(xún)與靈活的分析。日常訂單查詢(xún)與數(shù)據(jù)檢索頻率為 1000 次/秒，數(shù)據(jù)分析約每分鐘查詢(xún) 10 次左右。

以下是不同架構(gòu)達(dá)到要求所需的配置，以及在阿里云上的購(gòu)買(mǎi)成本：

五 總結(jié)

本篇文章談了云原生大數(shù)據(jù)架構(gòu)下的實(shí)時(shí)計(jì)算維表和結(jié)果表場(chǎng)景下的架構(gòu)設(shè)計(jì)與選型。其中，阿里云 Tablestore 在這些場(chǎng)景下有一些特色功能，希望能通過(guò)本篇文章對(duì)我們有一個(gè)更深刻的了解。后續(xù)，我們會(huì)推出從零構(gòu)建 Flink on Tablestore 系列文章，并針對(duì)維表和結(jié)果表場(chǎng)景推出最佳實(shí)踐文章。

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的云原生大数据架构中实时计算维表和结果表的选型实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。