一 為什么要使用流數(shù)據(jù)架構(gòu)

• 以原生形式處理永無(wú)止境的事件流,，避免批處理事件的開銷和延遲。 
• 實(shí)時(shí)或近實(shí)時(shí)處理最新的數(shù)據(jù)分析和洞察力——例如,，顯示機(jī)器性能的儀表板,，或微目標(biāo)廣告或即時(shí)服務(wù)，或檢測(cè)欺詐或網(wǎng)絡(luò)安全漏洞,。
• 檢測(cè)時(shí)間序列數(shù)據(jù)中的模式,， 例如突出顯示網(wǎng)站流量數(shù)據(jù)的趨勢(shì)。這很難用傳統(tǒng)的批處理來(lái)完成,，因?yàn)檫B續(xù)的時(shí)間相鄰事件可以跨多個(gè)批次中斷,。

二 流式架構(gòu)的組件

流數(shù)據(jù)架構(gòu)是一個(gè)軟件組件框架，用于從多個(gè)來(lái)源攝取和處理大量原始數(shù)據(jù)流,。 

從廣義上講,，它由四個(gè)部分組成：

1. 流處理器或消息代理，用于收集數(shù)據(jù)并重新分發(fā)它

2. 數(shù)據(jù)轉(zhuǎn)換工具（ETL,、ELT 等）,，為查詢準(zhǔn)備好數(shù)據(jù)

3. 查詢引擎，提取商業(yè)價(jià)值

4. 大量流數(shù)據(jù)的經(jīng)濟(jì)高效存儲(chǔ)——文件存儲(chǔ)和對(duì)象存儲(chǔ)

下面我們回顧一下每種組件類型在流式架構(gòu)中的位置和方式,。

流處理器/消息代理 

流處理器從其來(lái)源收集數(shù)據(jù)，將其轉(zhuǎn)換為標(biāo)準(zhǔn)消息格式,，然后連續(xù)流式傳輸以供其他組件使用,。（此類組件可以是存儲(chǔ)組件，例如數(shù)據(jù)湖,、ETL 工具或其他類型的組件,。）流處理器具有高容量（>1 Gb/秒）,，但不執(zhí)行其他數(shù)據(jù)轉(zhuǎn)換或任務(wù)調(diào)度,。

作為數(shù)據(jù)管道的流處理器（來(lái)源：Wikimedia Commons）

例子：

• Apache Kafka

•  Amazon Kinesis Data Streams

• Azure Event Hub

• Google Cloud PubSub

流處理工具

在消息代理存儲(chǔ)數(shù)據(jù)后，您必須聚合,、轉(zhuǎn)換和構(gòu)建數(shù)據(jù)以使其可以查詢,。您可以通過 ETL 執(zhí)行此操作,，在其中您在暫存區(qū)域或流工具中準(zhǔn)備數(shù)據(jù)，然后再將其移動(dòng)到查詢位置,，或者通過 ELT,，在同一位置轉(zhuǎn)換和查詢數(shù)據(jù),。此類轉(zhuǎn)換包括規(guī)范化；將相關(guān)字段映射到列,；加入來(lái)自多個(gè)來(lái)源的數(shù)據(jù),；文件壓縮；分區(qū),；基于時(shí)間的聚合,；等等。

例子：

• Apache Spark Streaming (SQL querying possible, mostly via complex Java or Scala)

• Amazon Web Services – Kinesis

• Google Cloud – Dataflow

• Microsoft Azure – Stream Analytics

• Apache Flink

• Upsolver

請(qǐng)注意,，根據(jù)您的需求和您創(chuàng)建的架構(gòu),，數(shù)據(jù)轉(zhuǎn)換可能會(huì)直接發(fā)生在數(shù)據(jù)流入和存儲(chǔ)在數(shù)據(jù)湖或其他存儲(chǔ)庫(kù)之前，或者在數(shù)據(jù)被攝取和存儲(chǔ)之后,。

查詢引擎

數(shù)據(jù)現(xiàn)在已準(zhǔn)備好進(jìn)行分析,。工具和技術(shù)差異很大，具體取決于用例,。 

示例（并非詳盡無(wú)遺）：

• 查詢引擎——Athena,、Presto、Hive,、Redshift Spectrum 

• 文本搜索引擎——Elasticsearch,、OpenSearch、Solr,、Kusto

• 云數(shù)據(jù)倉(cāng)庫(kù)——AWS Redshift,、Snowflake、Google BigQuery,、Synapse Analytics (Azure)

• NOSQL 存儲(chǔ) – Cassandra,、Amazon DynamoDB、CosmosDB,、Google BigTable

• 圖形分析——Neo4j,、Amazon Neptune

• 關(guān)系數(shù)據(jù)庫(kù)——RDS、SingleStore,、CockroachDB

• 實(shí)時(shí)數(shù)據(jù)庫(kù)——Imply,、Clickhouse

• TSDB——InfluxDB，AWS TimeSeries

流式數(shù)據(jù)存儲(chǔ)

由于事件流的龐大數(shù)量和多結(jié)構(gòu)性質(zhì),，組織通常將其流事件數(shù)據(jù)存儲(chǔ)在云對(duì)象存儲(chǔ)中以用作數(shù)據(jù)湖,。它們提供了一種經(jīng)濟(jì)高效且持久的方法來(lái)存儲(chǔ)大量事件數(shù)據(jù)。它們是一個(gè)靈活的集成點(diǎn),，因此流媒體生態(tài)系統(tǒng)之外的工具可以訪問流媒體數(shù)據(jù),。

例子：

• 亞馬遜 S3

• 微軟 Azure 存儲(chǔ)

• 谷歌云存儲(chǔ)

三 流式架構(gòu)最佳實(shí)踐

在構(gòu)建流架構(gòu)時(shí)，請(qǐng)牢記這些技術(shù)：

• 部署讀取模式模型

• 分離實(shí)時(shí)和歷史數(shù)據(jù)

• 維護(hù)所有傳入事件的不可變?nèi)罩?/p>

• 分層數(shù)據(jù)湖

• 保持架構(gòu)開放

• 優(yōu)化查詢性能

部署讀取模式模型

應(yīng)該了解正在攝取的數(shù)據(jù)——每個(gè)數(shù)據(jù)源的架構(gòu)、稀疏填充的字段,、數(shù)據(jù)基數(shù)等,。在讀取時(shí)獲得這種可見性而不是在寫入時(shí)嘗試推斷它可以省去很多麻煩，因?yàn)殡S著架構(gòu)變化的發(fā)生（意外的新的,、刪除的和更改的字段）,，可以基于最準(zhǔn)確和可用的數(shù)據(jù)構(gòu)建 ETL 管道。

 將用于實(shí)時(shí)分析的數(shù)據(jù)與歷史數(shù)據(jù)分開

優(yōu)化用于實(shí)時(shí)或近實(shí)時(shí)分析的數(shù)據(jù)以確?？焖僮x取,。以原始形式保留歷史數(shù)據(jù)以供臨時(shí)查詢使用，用于：

• “回放”過去的事態(tài)

• 錯(cuò)誤恢復(fù)

• 追蹤數(shù)據(jù)沿襲

• 探索性分析

維護(hù)所有傳入事件的不可變?nèi)罩?/strong>

在這里,，實(shí)質(zhì)上是在存儲(chǔ)整個(gè)事件轉(zhuǎn)換鏈,，而不僅僅是轉(zhuǎn)換的最終（或最近）結(jié)果。通過這種方式,，可以將任何事件恢復(fù)到某個(gè)時(shí)間點(diǎn)的狀態(tài),。這種“事件溯源”方法有很多好處： 

• 使數(shù)據(jù)團(tuán)隊(duì)能夠追溯驗(yàn)證他們的假設(shè)

• 使運(yùn)營(yíng)團(tuán)隊(duì)能夠跟蹤已處理數(shù)據(jù)的問題并快速修復(fù)它們

• 在發(fā)生故障或數(shù)據(jù)損壞的情況下提高容錯(cuò)能力；可以通過將整個(gè)事件序列應(yīng)用于損壞的實(shí)體來(lái)恢復(fù)數(shù)據(jù)的當(dāng)前狀態(tài),。

為了降低成本,，將日志存儲(chǔ)在對(duì)象存儲(chǔ)中。當(dāng)收到分析師或研究人員的請(qǐng)求時(shí),，創(chuàng)建一個(gè) ETL 作業(yè)以將數(shù)據(jù)從不可變?nèi)罩玖魇絺鬏數(shù)椒治銎脚_(tái),，并從那里回放。 

根據(jù)用戶的技能對(duì)數(shù)據(jù)湖進(jìn)行分層

在數(shù)據(jù)湖中存儲(chǔ)多個(gè)數(shù)據(jù)副本,，以服務(wù)于范圍廣泛的消費(fèi)者,。理想的數(shù)據(jù)管道讓這些消費(fèi)者中的每一個(gè)都能使用他們已知的工具訪問他們想要的數(shù)據(jù)——例如，完整（或接近完整）的數(shù)據(jù)科學(xué)家或機(jī)器學(xué)習(xí)算法的原始數(shù)據(jù),，或者聚合的,、更薄的和結(jié)構(gòu)化的版本BI 分析師可以使用它來(lái)快速創(chuàng)建報(bào)告?？梢宰詣?dòng)化提取原始數(shù)據(jù)的 ETL 管道,，并根據(jù)用例執(zhí)行相關(guān)轉(zhuǎn)換。然后,，可以避免依賴數(shù)據(jù)提供者（DevOps、數(shù)據(jù)工程）手動(dòng)工作的瓶頸,，例如為每個(gè)新請(qǐng)求編寫 Apache Spark 等 ETL 框架,。

針對(duì)不同用戶組配置的云數(shù)據(jù)湖

保持架構(gòu)開放

鑒于分析行業(yè)的快速變化，保持對(duì)“面向未來(lái)”的架構(gòu)的開放性至關(guān)重要,。避免供應(yīng)商鎖定或過度依賴單一工具或數(shù)據(jù)庫(kù),。當(dāng)可以通過廣泛的服務(wù)使用各種工具提供無(wú)處不在的數(shù)據(jù)訪問時(shí)，將獲得最大的價(jià)值。

要?jiǎng)?chuàng)建一個(gè)開放式架構(gòu)：

• 以開放的列式文件格式（例如 Avro 和 Parquet）存儲(chǔ)數(shù)據(jù),，這些格式是標(biāo)準(zhǔn)的,、眾所周知的并得到廣泛支持（與為特定數(shù)據(jù)庫(kù)構(gòu)建的專有文件格式（例如Databricks Delta Lake ）相反），這也提高了查詢性能,。

• 將原始?xì)v史數(shù)據(jù)保留在廉價(jià)的對(duì)象存儲(chǔ)中,，例如 Amazon S3。無(wú)論使用什么平臺(tái)來(lái)管理數(shù)據(jù)湖和運(yùn)行 ETL,，保障數(shù)據(jù)始終可用,。

• 使用支持良好的中央元數(shù)據(jù)存儲(chǔ)庫(kù)，例如 AWS Glue 或 Hive 元存儲(chǔ),?？梢栽谝粋€(gè)位置集中管理所有元數(shù)據(jù)，在此過程中降低基礎(chǔ)架構(gòu),、IT 資源和工程時(shí)間方面的運(yùn)營(yíng)成本,。

優(yōu)化查詢性能

以下最佳實(shí)踐可提高大多數(shù)業(yè)務(wù)案例的查詢性能：

• 適當(dāng)?shù)胤謪^(qū)數(shù)據(jù)以供您使用

• 轉(zhuǎn)換為高效的列式文件格式

• 經(jīng)常壓縮（合并）小文件

分區(qū)數(shù)據(jù)

如何對(duì)數(shù)據(jù)進(jìn)行分區(qū)對(duì)查詢成本和速度有重大影響。查詢運(yùn)行更高效,、成本更低,，因?yàn)檫m當(dāng)?shù)姆謪^(qū)限制了Amazon Athena 等查詢引擎為回答特定分析問題而必須掃描的數(shù)據(jù)量。

數(shù)據(jù)通常按時(shí)間戳進(jìn)行分區(qū),。但是,，根據(jù)查詢，數(shù)據(jù)可能會(huì)被其他字段分區(qū),，例如地理或與記錄時(shí)間戳不同的基于時(shí)間的字段,。如果可能，根據(jù)可能運(yùn)行的查詢類型和分析系統(tǒng)的建議來(lái)配置分區(qū)的大小,。例如,，如果大部分查詢都需要過去 12 小時(shí)的數(shù)據(jù)，考慮按小時(shí)而不是按天進(jìn)行分區(qū),，以減少要掃描的數(shù)據(jù)量,。

轉(zhuǎn)換為高效的列式文件格式

另一種減少掃描數(shù)據(jù)量的方法。將計(jì)劃用于分析的數(shù)據(jù)存儲(chǔ)在列式文件格式中,，例如 Apache Parquet 或 ORC,。使用列式格式，可以僅查詢所需的列,，從而減少所需的計(jì)算量,，從而加快查詢速度并降低成本。

經(jīng)常壓縮以解決“小文件問題”

數(shù)據(jù)流每天定期產(chǎn)生數(shù)百萬(wàn)個(gè)小事件文件,。小文件提供更新鮮的數(shù)據(jù),，但如果直接查詢這些小文件,，隨著時(shí)間的推移會(huì)降低性能。將小文件合并為大小合適的文件的過程稱為壓縮,。

權(quán)衡數(shù)據(jù)流通的價(jià)值與高性能的價(jià)值,，并根據(jù)需要盡可能頻繁地壓縮文件，以使數(shù)據(jù)保持最佳文件大小,。 

三 工具比較：流處理/事件流工具

到目前為止,，最常見的事件流工具是 Amazon Kinesis 和 Apache Kafka。

亞馬遜Kinesis

Amazon Kinesis 是一種發(fā)布-訂閱 (pub-sub) 消息傳遞解決方案,。它是 AWS 云中的一項(xiàng)托管服務(wù),；配置有限，無(wú)法在本地運(yùn)行 Kinesis,。

• 設(shè)置/配置：AWS 代表管理流式傳輸數(shù)據(jù)所需的基礎(chǔ)設(shè)施,、存儲(chǔ)、網(wǎng)絡(luò)和配置,。AWS 還處理硬件,、軟件和其他數(shù)據(jù)流服務(wù)的配置、部署和持續(xù)維護(hù),。

• 成本：沒有前期設(shè)置成本,。收費(fèi)取決于：

• 所需吞吐量所需的分片（分區(qū)）數(shù)量 每個(gè)分片本質(zhì)上是一個(gè)包含數(shù)據(jù)子集的單獨(dú)流；Kinesis 每個(gè)流有多個(gè)分片）,。

• 生產(chǎn)者傳輸?shù)綌?shù)據(jù)流的數(shù)據(jù)量,，因此對(duì)于大量數(shù)據(jù)，成本可能很高,。

• 用于：鑒于 Amazon 的高可用性承諾,，如果沒有用于 24/7 監(jiān)控、警報(bào)和 DevOps 團(tuán)隊(duì)從故障中恢復(fù)的資源,，Kinesis 可能是一個(gè)不錯(cuò)的選擇,。

阿帕奇Kafka

Apache Kafka 是一個(gè)開源的 pub-sub 系統(tǒng)，已經(jīng)發(fā)展成為一個(gè)成熟的水平可擴(kuò)展和容錯(cuò)系統(tǒng),，用于高吞吐量數(shù)據(jù)重放和流,。

• 設(shè)置/配置：優(yōu)化 Apache Kafka 的吞吐量和延遲需要同時(shí)調(diào)整生產(chǎn)者和消費(fèi)者。服務(wù)器端配置——例如,，復(fù)制因子和分區(qū)數(shù)——對(duì)于通過并行性實(shí)現(xiàn)最佳性能也至關(guān)重要,。為了獲得高可用性，必須將 Kafka 配置為盡快從故障中恢復(fù),。

• 在 Kafka 中構(gòu)建 ETL 管道存在挑戰(zhàn),；除了數(shù)據(jù)轉(zhuǎn)換的基本任務(wù)外，還必須考慮事件流數(shù)據(jù)的獨(dú)特特征,。

• 成本：Kafka 需要自己的集群,。設(shè)置 Kafka 集群需要學(xué)習(xí)和分布式系統(tǒng)工程實(shí)踐以及集群管理、供應(yīng),、自動(dòng)縮放,、負(fù)載平衡、配置管理和重要的 DevOps 參與的能力,。還需要大量節(jié)點(diǎn)（代理）,、復(fù)制和分區(qū)以實(shí)現(xiàn)系統(tǒng)的容錯(cuò)和高可用性。 

• 用于：實(shí)時(shí)數(shù)據(jù)處理,；應(yīng)用程序活動(dòng)跟蹤,；日志記錄和/或監(jiān)控系統(tǒng)。

托管Kafka服務(wù)

Confluent KSQL和Amazon MSK（Kafka 托管流）都提供部署在云中的離散托管 Kafka 服務(wù),。 他們的目標(biāo)是利用 Kafka 的靈活性和近乎無(wú)處不在的特性,，同時(shí)管理其內(nèi)在的大部分復(fù)雜性。   

Confluent Cloud是 Kafka 的完全托管云服務(wù),，可加速事件驅(qū)動(dòng)服務(wù)和實(shí)時(shí)應(yīng)用程序的開發(fā),，而無(wú)需您管理 Kafka 集群。 

• 設(shè)置/配置：需要 Java 運(yùn)行時(shí)環(huán)境和訪問 Kafka 集群以實(shí)時(shí)讀取和寫入數(shù)據(jù),。集群可以在本地或云端,。需要為 ksqlDB 服務(wù)器和查詢?cè)O(shè)置配置參數(shù)，以及底層 Kafka 流和 Kafka 客戶端（生產(chǎn)者和消費(fèi)者）,。

• 成本：多種定價(jià)模型：每 Gb（數(shù)據(jù)輸入,、數(shù)據(jù)輸出、數(shù)據(jù)存儲(chǔ)）,；每小時(shí)計(jì)算,；每小時(shí)分區(qū)。

• 用于：用于在云中托管 Kafka,。也可用作消息代理,，促進(jìn)企業(yè)級(jí)系統(tǒng)之間的通信，并將每個(gè)系統(tǒng)生成的數(shù)據(jù)集成到中央位置,，例如 Amazon S3,。

Amazon MSK是一項(xiàng)完全托管的服務(wù)，可簡(jiǎn)化使用 Apache Kafka 管理消息隊(duì)列和處理流數(shù)據(jù)的生產(chǎn)應(yīng)用程序的構(gòu)建和運(yùn)行,。  

• 設(shè)置/配置：MSK 簡(jiǎn)化了設(shè)置和維護(hù),。設(shè)置和配置基于 Apache Kafka 的部署最佳實(shí)踐。自動(dòng)配置并運(yùn)行您的 Apache Kafka 集群,。 

• 成本：基于使用情況,。需要為代理實(shí)例的運(yùn)行時(shí)間、每月使用的存儲(chǔ)空間以及集群內(nèi)外數(shù)據(jù)的標(biāo)準(zhǔn)數(shù)據(jù)傳輸費(fèi)用付費(fèi),。

• 用于：維護(hù)和擴(kuò)展 Kafka 集群,，啟用由完全托管服務(wù)支持的端到端攝取管道,。還用作不同微服務(wù)之間的實(shí)時(shí)消息代理。

四 工具比較：批處理和實(shí)時(shí) ETL 工具

在此類別中,，可以選擇開源工具,、托管服務(wù)或完全托管的自助服務(wù)引擎。

阿帕奇Spark

Spark是一種分布式通用集群計(jì)算框架,。Spark 引擎在攝取數(shù)據(jù)時(shí)計(jì)算并優(yōu)化有向無(wú)環(huán)圖 (DAG),。（DAG 是一種單向前進(jìn)的數(shù)據(jù)流，沒有循環(huán)）,。Spark 的內(nèi)存數(shù)據(jù)處理引擎對(duì)動(dòng)態(tài)或靜止數(shù)據(jù)執(zhí)行分析,、ETL、機(jī)器學(xué)習(xí)和圖形處理,。它為某些編程語(yǔ)言提供高級(jí) API：Python,、Java、Scala,、R 和 SQL,。

優(yōu)點(diǎn)：

• 具有大型企業(yè)應(yīng)用的成熟產(chǎn)品，已在許多用例的生產(chǎn)中得到驗(yàn)證

• 隨時(shí)支持SQL查詢,。

缺點(diǎn)：

• 實(shí)施和維護(hù)復(fù)雜且勞動(dòng)密集

• 幾秒鐘的延遲,，消除了一些實(shí)時(shí)分析用例

亞馬遜Glue

Amazon Glue 是一種完全托管的 ETL 和數(shù)據(jù)發(fā)現(xiàn)服務(wù)，構(gòu)建于 Apache Spark 之上,。Glue 提供了一個(gè)無(wú)服務(wù)器環(huán)境,，可以使用它自動(dòng)配置的虛擬資源來(lái)運(yùn)行 Spark ETL 作業(yè)。使用 Glue,，可以針對(duì) S3 執(zhí)行 ETL 作業(yè)以轉(zhuǎn)換流數(shù)據(jù),，包括各種轉(zhuǎn)換和轉(zhuǎn)換為 Apache Parquet。

優(yōu)點(diǎn)

•  可以減少正在進(jìn)行的集群管理的麻煩

缺點(diǎn)

• 仍在作為服務(wù)發(fā)展

• 限于 Spark 的批處理性質(zhì),，這會(huì)帶來(lái)一定的延遲和限制

• 必須在存儲(chǔ)層做很多優(yōu)化（例如在 S3 上壓縮小文件）以提高查詢性能 

阿帕奇Flink

還處理批任務(wù)的流處理框架,。Flink 也是一個(gè)聲明式引擎。它將批處理視為具有有限邊界的數(shù)據(jù)流,。數(shù)據(jù)通過源進(jìn)入并通過匯離開,。它基于流和轉(zhuǎn)換的概念。 

優(yōu)點(diǎn)：

• 流優(yōu)先方法提供低延遲,、高吞吐量

• 真正的逐條處理

• 不需要對(duì)其處理的數(shù)據(jù)進(jìn)行手動(dòng)優(yōu)化和調(diào)整

• 動(dòng)態(tài)分析和優(yōu)化任務(wù)

缺點(diǎn)：

• 一些縮放限制

• 比較新,；與其他框架相比，生產(chǎn)中的部署更少

阿帕 Flume

用于聚合,、收集和移動(dòng)大量日志數(shù)據(jù)的可靠分布式服務(wù),。它具有靈活的基本架構(gòu)。從 Web 服務(wù)器捕獲流數(shù)據(jù)到 Hadoop 分布式文件系統(tǒng) (HDFS),。

優(yōu)點(diǎn)：

• 中央主服務(wù)器控制所有節(jié)點(diǎn)

• 容錯(cuò),、故障轉(zhuǎn)移以及高級(jí)恢復(fù)和可靠性功能

缺點(diǎn)：

• 難以理解和配置復(fù)雜的邏輯/物理映射

• 占用空間大——>50,000 行 Java 代碼

阿帕奇Storm

Apache Storm 處理大量數(shù)據(jù)并以比許多其他解決方案更低的延遲提供結(jié)果,。適用于近乎實(shí)時(shí)的處理工作負(fù)載。Storm 是一個(gè)組合引擎,，開發(fā)者預(yù)先定義 DAG,，然后處理數(shù)據(jù)。這可能會(huì)簡(jiǎn)化代碼,。但這也意味著開發(fā)人員必須仔細(xì)規(guī)劃他們的架構(gòu)以避免低效的處理。

Apache Storm 架構(gòu)建立在 spouts 和 bolts 之上,。Spouts 是信息的來(lái)源,。它們將信息傳輸?shù)揭粋€(gè)或多個(gè)螺栓。整個(gè)拓?fù)湫纬梢粋€(gè)DAG,。

優(yōu)點(diǎn)：

• 非常適合實(shí)時(shí)處理

• 使用微批次可以靈活地調(diào)整工具以適應(yīng)不同的用例

• 廣泛的語(yǔ)言支持

缺點(diǎn)：

• 可能會(huì)降低可靠性,，因?yàn)樗荒鼙ＷC消息的順序

• 實(shí)施起來(lái)非常復(fù)雜

阿帕奇Samza

Samza 使用發(fā)布-訂閱模型來(lái)攝取數(shù)據(jù)流、處理消息并將結(jié)果輸出到另一個(gè)流,。這是一個(gè)合成引擎,。Samza 依賴于 Apache Kafka 消息系統(tǒng)、架構(gòu),，并保證提供緩沖,、容錯(cuò)和狀態(tài)存儲(chǔ)。

優(yōu)點(diǎn)：

• 提供復(fù)制存儲(chǔ),，以低延遲提供可靠的持久性

• 簡(jiǎn)單且具有成本效益的多用戶模型

• 可以消除背壓,，持久化數(shù)據(jù)供以后處理

缺點(diǎn)：

• 不支持非常低的延遲

• 僅支持 JVM 語(yǔ)言

• 不支持恰好一次語(yǔ)義

亞馬遜Kinesis Streams

由 AWS 作為托管服務(wù)提供的專有事件流工具。每秒從數(shù)十萬(wàn)個(gè)來(lái)源收集千兆字節(jié)的數(shù)據(jù),。以毫秒為單位捕獲實(shí)時(shí)分析用例的數(shù)據(jù),。與 Kafka 的 pub-sub 模型非常相似，包括彈性縮放,、持久性和低延遲消息傳輸（根據(jù)亞馬遜的說(shuō)法,，在 70 毫秒內(nèi)收集數(shù)據(jù)）。

優(yōu)點(diǎn)：

• 易于設(shè)置和維護(hù)的托管服務(wù)

• 與亞馬遜廣泛的大數(shù)據(jù)工具集集成

缺點(diǎn)：

• 商業(yè)云服務(wù),，每個(gè)分片按小時(shí)收費(fèi),；處理大量數(shù)據(jù)時(shí)可能會(huì)很昂貴

• 需要犧牲一定程度的控制和定制，以換取易用性和減少對(duì)基礎(chǔ)設(shè)施的關(guān)注

五 工具比較——分析引擎

數(shù)據(jù)從業(yè)者使用越來(lái)越多的工具從存儲(chǔ)和流式數(shù)據(jù)中獲取洞察力和價(jià)值,。這些工具反過來(lái)與商業(yè)智能應(yīng)用程序一起工作,，以可視化和探索數(shù)據(jù)、數(shù)據(jù)建模和其他用于機(jī)器學(xué)習(xí)和人工智能的預(yù)測(cè)分析應(yīng)用程序,。

今天使用的常見分析工具包括：

• 大數(shù)據(jù)查詢引擎：

• Amazon Athena

• Presto

• Trino / Starburst

• Redshift Spectrum

• Hive

• 其他

• 專用文本搜索引擎

• ElasticSearch

• Amazon OpenSearch

• Apache Solr (open source, based on the same library as ES, but much less prevalent)

• Kusto – managed MS offering

• 存儲(chǔ)層

• 數(shù)據(jù)倉(cāng)庫(kù)

大數(shù)據(jù)查詢引擎

顧名思義,，這些技術(shù)旨在或已經(jīng)發(fā)展為針對(duì)從 GB 到 PB 的各種規(guī)模的數(shù)據(jù)源運(yùn)行交互式分析查詢。它們可以搜索任何形式的數(shù)據(jù)——結(jié)構(gòu)化,、半結(jié)構(gòu)化,、非結(jié)構(gòu)化——并且可以運(yùn)行許多同時(shí)查詢,，如果可能的話實(shí)時(shí)。他們可以查詢存儲(chǔ)在任何地方的數(shù)據(jù),，而無(wú)需將數(shù)據(jù)移動(dòng)到單獨(dú)的結(jié)構(gòu)化系統(tǒng)中,，例如關(guān)系數(shù)據(jù)庫(kù)或數(shù)據(jù)倉(cāng)庫(kù)。

亞馬遜Athena

Athena 是一個(gè)分布式查詢引擎,，使用 S3 作為其底層存儲(chǔ)層,。它的性能很大程度上取決于數(shù)據(jù)在 S3 中的組織方式，因?yàn)闆]有數(shù)據(jù)庫(kù)可以代替 ETL 工具進(jìn)行轉(zhuǎn)換,。ETL 到 Athena 必須優(yōu)化 S3 存儲(chǔ)以實(shí)現(xiàn)快速查詢和處理有狀態(tài)操作,。  

Athena 執(zhí)行全表掃描而不是使用索引。這意味著某些操作（例如大表之間的連接）可能會(huì)非常慢,。

Presto

Presto（或 PrestoDB）是一個(gè)依賴于 Hive 元存儲(chǔ)的開源分布式 SQL 查詢引擎,。它專為對(duì)任何數(shù)量的數(shù)據(jù)進(jìn)行快速分析查詢而設(shè)計(jì)。它是亞馬遜基于 Athena 的基礎(chǔ)服務(wù),。與 Athena 一樣,，您可以使用 Presto 查詢?cè)茖?duì)象存儲(chǔ)中的數(shù)據(jù)；您不必先將數(shù)據(jù)移動(dòng)到單獨(dú)的分析系統(tǒng)中,。查詢執(zhí)行在可擴(kuò)展的純內(nèi)存架構(gòu)上并行運(yùn)行,。

Presto 具有通過其連接器直接連接 S3 之外的各種數(shù)據(jù)源的功能，包括 HDFS 數(shù)據(jù)塊和關(guān)系數(shù)據(jù)庫(kù),。

Trino / Starburst

Trino 是一種分布式 SQL 查詢引擎,，旨在查詢分布在一個(gè)或多個(gè)異構(gòu)數(shù)據(jù)源上的大型數(shù)據(jù)集。Trino 最初名為 PrestoSQL,，是原始 prestoDB 開源項(xiàng)目的一個(gè)分支,。它由 Trino Software Foundation 的大型貢獻(xiàn)者和用戶社區(qū)維護(hù)。

Starburst 是 Presto 基金會(huì)管理委員會(huì)的成員,，維護(hù)著一個(gè)名為 Starburst Enterprise 的企業(yè)級(jí) Trino 商業(yè)發(fā)行版,。Starburst Enterprise 包括額外的安全功能、更多連接器,、基于成本的查詢優(yōu)化器,、對(duì)運(yùn)行額外部署平臺(tái)的支持等。它旨在幫助大公司安全地從他們的 Trino 部署中提取更多價(jià)值,。

Redshift Spectrum

Redshift 是一個(gè)關(guān)系數(shù)據(jù)庫(kù),；Redshift Spectrum 是一個(gè)查詢引擎，駐留在專用的 Redshift 服務(wù)器上并訪問 S3 中的數(shù)據(jù),。

與 Athena 相比,，Redshift 是：

• 快點(diǎn)

• 更健壯（具有額外的計(jì)算能力）

• 更貴

• 管理起來(lái)更復(fù)雜，需要大量的集群管理專業(yè)知識(shí)

亞馬遜向 Redshift 引入了 RA3 節(jié)點(diǎn)類型，以提高性能并增加存儲(chǔ)容量,。Amazon 的 Redshift 高級(jí)查詢加速器 (AQUA) 位于 Amazon Redshift RA3 集群的計(jì)算和存儲(chǔ)之間,，并與 Amazon Redshift RA3 實(shí)例一起運(yùn)行。它不適用于數(shù)據(jù)湖,。

Hive

Apache Hive 是一個(gè)開源數(shù)據(jù)倉(cāng)庫(kù)應(yīng)用程序,，用于讀取,、寫入和管理大型數(shù)據(jù)集,。它與 Apache Hadoop 分布式文件系統(tǒng) (HDFS) 或其他數(shù)據(jù)存儲(chǔ)系統(tǒng)（如 Apache HBase）配合使用,。您通過命令行工具和 JDBC 驅(qū)動(dòng)程序連接到 Hive,。使用 Hive 的 SQL-like 接口查詢存儲(chǔ)在與 Hadoop 集成的各種數(shù)據(jù)庫(kù)和文件系統(tǒng)中的數(shù)據(jù),。

專用文本搜索引擎

顧名思義,，專用文本（或全文）搜索引擎檢查文檔和數(shù)據(jù)庫(kù)記錄中的所有單詞,。（元數(shù)據(jù)搜索方法僅分析文檔的描述,。）它們承諾通過高級(jí)索引和基于相關(guān)性的更直觀的搜索結(jié)果快速檢索數(shù)據(jù)。

Elasticsearch

Elasticsearch 是一個(gè)基于 Lucene 的開源可伸縮搜索引擎,。它通常用于日志搜索,、日志分析以及 BI 和報(bào)告,。您可以在任何地方運(yùn)行它。  

將 Elasticsearch 包含在流式架構(gòu)中以明確查詢?nèi)罩疚募那闆r并不少見,。為此,，將所有原始數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)湖中以供重放和臨時(shí)分析,。然后對(duì)其進(jìn)行去重,，過濾掉不相關(guān)的事件，并將該子集發(fā)送到 Elasticsearch,。

可以使用 Kafka Connect 將主題直接流式傳輸?shù)?Elasticsearch,。 

將所有日志存儲(chǔ)在 Elasticsearch 中不需要自定義編碼,。但由于 Elasticsearch 日志通常包含大量文本，因此相對(duì)較大，存儲(chǔ)成本高昂

亞馬遜OpenSearch

OpenSearch 項(xiàng)目由亞馬遜創(chuàng)建,，是一個(gè)基于 Elasticsearch 和 Kibana 的分叉搜索項(xiàng)目,。（亞馬遜沒有計(jì)劃 Elasticsearch 和 Kibana 的當(dāng)前或未來(lái)版本。）它與 Elasticsearch 相同,，但隨著時(shí)間的推移會(huì)有所不同。

阿帕奇Solr

Apache Solr 是一個(gè)基于 Apache Lucene? 構(gòu)建的開源企業(yè)搜索平臺(tái)。它提供分布式索引,、復(fù)制和負(fù)載平衡查詢,、自動(dòng)故障轉(zhuǎn)移和恢復(fù)以及集中配置。它被設(shè)計(jì)為可靠的,、可擴(kuò)展的和容錯(cuò)的,。  

Microsoft Azure 數(shù)據(jù)資源管理器

Azure 數(shù)據(jù)資源管理器是一項(xiàng)用于存儲(chǔ)和運(yùn)行大量數(shù)據(jù)的交互式分析的服務(wù),。它基于 RDMS,，支持?jǐn)?shù)據(jù)庫(kù),、表和列等實(shí)體,。您可以通過 Kusto 查詢語(yǔ)言創(chuàng)建復(fù)雜的分析查詢,。

Kusto 補(bǔ)充但不替代傳統(tǒng) RDBMS 系統(tǒng)，用于 OLTP 和數(shù)據(jù)倉(cāng)庫(kù)等場(chǎng)景,。它對(duì)所有形式的數(shù)據(jù)（結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化）表現(xiàn)同樣出色,。Kusto 不執(zhí)行單個(gè)行和跨表約束或事務(wù)的就地更新,。 

存儲(chǔ)層

與其他類型的流架構(gòu)組件一樣,，存儲(chǔ)層也在不斷發(fā)展,，充分利用它們的策略也在不斷發(fā)展通常，可以選擇文件存儲(chǔ)、對(duì)象存儲(chǔ)（數(shù)據(jù)湖,，主要是mostly0 和數(shù)據(jù)倉(cāng)庫(kù)）,。

文件存儲(chǔ)——Hadoop 旨在處理大量數(shù)據(jù),。相對(duì)而言,對(duì)于中小型文件,，它仍然足夠簡(jiǎn)單和有效。但是元數(shù)據(jù)是有限的,，并且只能通過整個(gè)文件進(jìn)行搜索,，因此隨著容量的增加，使用 HDFS 作為主要存儲(chǔ)層的成本,、復(fù)雜性和延遲變得不合適,。

對(duì)象存儲(chǔ)——通常是指數(shù)據(jù)湖，其中最突出的是 Amazon S3,；微軟 Azure 數(shù)據(jù)湖和谷歌云存儲(chǔ),。文件位置被標(biāo)記，元數(shù)據(jù)是可靠的,。因此縮放是無(wú)限的,，搜索比文件存儲(chǔ)快得多。但數(shù)據(jù)必須經(jīng)過轉(zhuǎn)換和優(yōu)化才能使其可查詢,。

數(shù)據(jù)倉(cāng)庫(kù)——這些最適合結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù),，數(shù)據(jù)必須在存儲(chǔ)在倉(cāng)庫(kù)中之前進(jìn)行預(yù)處理（讀取模式）。倉(cāng)庫(kù)可以提供簡(jiǎn)單的數(shù)據(jù)訪問和快速查詢,，但不能以經(jīng)濟(jì)高效的方式擴(kuò)展,，也不能很好地處理非結(jié)構(gòu)化數(shù)據(jù)。它們通常還需要一個(gè)封閉的架構(gòu)——也就是說(shuō),，它們實(shí)際上只適用于各自供應(yīng)商的工具集,。有許多可用的數(shù)據(jù)倉(cāng)庫(kù)；最著名的是 Snowflake 和 Amazon Redshift,。

六 流數(shù)據(jù)常見用例

流式數(shù)據(jù)處理使實(shí)時(shí)或近實(shí)時(shí)獲得可操作的洞察成為可能,。特別適合流式傳輸?shù)挠美ǎ?/p>

• 欺詐檢測(cè)——將復(fù)雜的機(jī)器學(xué)習(xí)算法與實(shí)時(shí)交易分析相結(jié)合，以識(shí)別模式并實(shí)時(shí)檢測(cè)表明欺詐的異常情況,。

• 網(wǎng)絡(luò)安全——數(shù)據(jù)流中的異常有助于數(shù)據(jù)安全從業(yè)者隔離或消除威脅,，例如來(lái)自單個(gè) IP 地址的可疑流量,。

• 物聯(lián)網(wǎng)傳感器數(shù)據(jù)——實(shí)時(shí)計(jì)算數(shù)據(jù)流，例如監(jiān)控機(jī)械或環(huán)境條件或庫(kù)存水平并幾乎立即做出響應(yīng),。

• 在線廣告和營(yíng)銷情報(bào)——跟蹤用戶行為,、點(diǎn)擊次數(shù)和興趣，然后為每個(gè)用戶推廣個(gè)性化的贊助廣告,。實(shí)時(shí)衡量觀眾對(duì)內(nèi)容的反應(yīng),，以快速、有針對(duì)性地決定為訪客和客戶提供哪些服務(wù)并吸引潛在客戶,。

• 產(chǎn)品分析——跟蹤數(shù)字產(chǎn)品中的行為以了解功能使用,、評(píng)估用戶體驗(yàn)變化、增加使用并減少放棄,。

• 日志分析——IT 部門可以將日志文件轉(zhuǎn)化為集中的易于使用的消息流,，以從日志文件中提取意義；通常與可視化工具和開箱即用的過濾器結(jié)合使用,。

• 云數(shù)據(jù)庫(kù)復(fù)制——使用變更數(shù)據(jù)捕獲 (CDC) 在云中維護(hù)事務(wù)數(shù)據(jù)庫(kù)的同步副本,，以支持?jǐn)?shù)據(jù)科學(xué)家使用高級(jí)分析。

七 流處理常見陷阱

流處理是從海量數(shù)據(jù)流中獲取商業(yè)價(jià)值的最佳方法,。但路徑不一定是直截了當(dāng)?shù)?。在設(shè)計(jì)流式傳輸架構(gòu)時(shí)，請(qǐng)牢記這些陷阱：

• Apache Spark 的復(fù)雜性

• 過度依賴數(shù)據(jù)庫(kù)

• 小文件的激增

Apache Spark 的復(fù)雜性

Spark 是一個(gè)強(qiáng)大的開源流處理器,，并且被廣泛使用,。但是，與 Hadoop 一樣,，它是一個(gè)復(fù)雜的框架,，需要大量的專業(yè)知識(shí)。 它功能強(qiáng)大且用途廣泛 – 但它不易使用,、部署簡(jiǎn)單或運(yùn)行成本低廉,。那是因?yàn)椋?/p>

• 專為大數(shù)據(jù)和 Scala 工程師打造，而非分析團(tuán)隊(duì),。在 Spark 中構(gòu)建數(shù)據(jù)轉(zhuǎn)換需要在 Scala 中進(jìn)行冗長(zhǎng)的編碼,，并具備在對(duì)象存儲(chǔ)、分區(qū)和合并小文件方面實(shí)施數(shù)十種 Hadoop 最佳實(shí)踐的專業(yè)知識(shí),。

• 不是一個(gè)獨(dú)立的解決方案,。Spark 只是更大的大數(shù)據(jù)框架的一部分,。對(duì)于流處理,、工作流編排和狀態(tài)管理，需要組裝相當(dāng)多的額外工具,，每個(gè)工具都有自己的專業(yè)技能集,，從而增加了更多的復(fù)雜性和成本,。

• 需要很長(zhǎng)時(shí)間才能實(shí)現(xiàn)價(jià)值。Spark 的大規(guī)模實(shí)施是一個(gè)復(fù)雜的編碼項(xiàng)目,。隨著雇用或培訓(xùn)專家,、定制開發(fā)和手動(dòng)調(diào)整以優(yōu)化和擴(kuò)展 Spark 所需的時(shí)間，從開始到生產(chǎn)需要幾個(gè)月或更長(zhǎng)時(shí)間,。

• 造成技術(shù)債務(wù)并扼殺敏捷性,。對(duì)數(shù)據(jù)或分析要求的任何更改都需要一個(gè)編碼周期，包括回歸測(cè)試/QA,。  

• 造成數(shù)據(jù)工程瓶頸,。數(shù)據(jù)團(tuán)隊(duì)必須實(shí)施任何需要新 ETL 流程或管道更改的新儀表板或報(bào)告。因此,，每個(gè)變更請(qǐng)求都必須符合工程團(tuán)隊(duì)的 Sprint 計(jì)劃,。這可能會(huì)很痛苦，并最終會(huì)減少整個(gè)組織對(duì)數(shù)據(jù)的訪問,。

• 是昂貴的,。 的確，沒有直接的許可費(fèi)用（盡管通過托管 Spark 服務(wù)可能會(huì)產(chǎn)生高昂的訂閱費(fèi)用）,。但是,，將額外硬件的成本添加到專業(yè)知識(shí)的成本中，Apache 部署很容易超過大多數(shù)軟件許可的價(jià)格,。當(dāng)使用高端開發(fā)人員進(jìn)行普通的數(shù)據(jù)管道構(gòu)建和維護(hù)時(shí),，也會(huì)產(chǎn)生機(jī)會(huì)成本。

過度依賴數(shù)據(jù)庫(kù)

如果已經(jīng)在管理大量數(shù)據(jù)流,，這可能是顯而易見的——但將流數(shù)據(jù)保存在關(guān)系數(shù)據(jù)庫(kù)中是站不住腳的：

• 事務(wù)數(shù)據(jù)庫(kù)必須保留用于操作,。任何額外報(bào)告或處理都會(huì)妨礙表現(xiàn)。

• 基于事件的數(shù)據(jù)存儲(chǔ)為對(duì)象而不是表,。但是關(guān)系數(shù)據(jù)庫(kù)是建立在表格存儲(chǔ)之上的,；使用它們來(lái)存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)需要冗長(zhǎng)的清理和轉(zhuǎn)換過程，并在攝取時(shí)造成工程瓶頸,。

• 存儲(chǔ)成本很容易使所有其他項(xiàng)目成本相形見絀,，尤其是當(dāng)將大數(shù)據(jù)存儲(chǔ)在存儲(chǔ)和計(jì)算緊密耦合的數(shù)據(jù)庫(kù)中時(shí)。

• 操作型數(shù)據(jù)庫(kù)只包含相對(duì)較新的數(shù)據(jù),，而且通常只包含數(shù)據(jù)點(diǎn)的最新狀態(tài),。挖掘模式和趨勢(shì)或跟蹤數(shù)據(jù)沿襲以從錯(cuò)誤中恢復(fù)是非常具有挑戰(zhàn)性的。

• 流數(shù)據(jù)的價(jià)值通過探索技術(shù),、預(yù)測(cè)建模和機(jī)器學(xué)習(xí)得到釋放,。與傳統(tǒng)數(shù)據(jù)庫(kù)相比，這些分析需要更廣泛,、更靈活的數(shù)據(jù)訪問,。

小文件的激增

將小文件寫入對(duì)象存儲(chǔ)非常簡(jiǎn)單,。但無(wú)論是在云端還是本地使用 Hadoop 或 Spark，小文件都會(huì)破壞性能,。打開每個(gè)文件,、讀取元數(shù)據(jù)和關(guān)閉文件都需要幾毫秒的時(shí)間，這在處理數(shù)百萬(wàn)個(gè)文件時(shí)變得有意義,。此外,，許多文件會(huì)導(dǎo)致許多不連續(xù)的磁盤尋道，而對(duì)象存儲(chǔ)并未為此進(jìn)行優(yōu)化,。

為了緩解這種情況,，請(qǐng)?jiān)跀?shù)據(jù)架構(gòu)中使用壓縮——定期將較小的事件文件合并到較大的檔案中——以提高查詢性能。最好的方法是：

• 地定義壓縮窗口,。過于頻繁地壓縮是一種浪費(fèi),，因?yàn)槲募匀环浅Ｐ。魏涡阅芨倪M(jìn)都是微不足道的,。當(dāng)系統(tǒng)等待壓縮作業(yè)完成時(shí),，壓縮太少會(huì)導(dǎo)致處理時(shí)間過長(zhǎng)和查詢速度變慢。

• 刪除未壓縮的字段以節(jié)省空間和存儲(chǔ)成本,。當(dāng)然,，始終保留原始狀態(tài)的數(shù)據(jù)副本以用于重放和事件溯源。

• 壓縮完成后重新配置 Athena 表分區(qū),，這樣 Athena 將讀取壓縮后的分區(qū)而不是原始文件,。

• 保持文件大小盡可能大，但仍然足夠小以適應(yīng)未壓縮的內(nèi)存,。

同時(shí),，遵循一些最佳實(shí)踐可以確保在構(gòu)建流式架構(gòu)時(shí)更快地獲得更多價(jià)值。

八 綜述

隨著流數(shù)據(jù)的規(guī)模持續(xù)增長(zhǎng),，組織可以通過構(gòu)建或升級(jí)數(shù)據(jù)架構(gòu)來(lái)保持競(jìng)爭(zhēng)力,，使他們能夠?qū)崟r(shí)或接近實(shí)時(shí)地處理和分析數(shù)據(jù)。該過程的每個(gè)步驟都有多種方法,、技術(shù)和工具,。通過采用有限數(shù)量的最佳實(shí)踐并堅(jiān)持開放數(shù)據(jù)架構(gòu)以最大限度地增加選擇，數(shù)據(jù)堆棧不僅具有成本效益,，而且在可預(yù)見的未來(lái)具有足夠的靈活性和可擴(kuò)展性,。