2022年12月,在拉斯維加斯舉辦的2022亞馬遜云科技re:Invent全球大會(huì)完美落幕,這一標(biāo)志性的技術(shù)盛宴再一次給人們留下了無限的想象空間,等待大家在新的一年去持續(xù)探索和發(fā)掘。
而最讓人關(guān)注的,應(yīng)該就是各類新服務(wù)了,今年無論是Adam還是Swami博士的Keynote很多篇幅都是和數(shù)據(jù)相關(guān)的新服務(wù)和新特性,尤其是Swami博士關(guān)于數(shù)據(jù)創(chuàng)新起源的表述以及新的端到端云原生數(shù)據(jù)戰(zhàn)略。所以,接下來將目光切回今天這篇文章關(guān)注的對(duì)象——數(shù)據(jù),更具體地說是眾多新發(fā)布中占據(jù)高位的Amazon Redshift云數(shù)據(jù)倉庫。
簡化數(shù)據(jù)攝入工作
最好是沒有
要想數(shù)據(jù)分析到位,首先要保證有穩(wěn)定、可靠的數(shù)據(jù)攝入通道,來實(shí)現(xiàn)端到端的第一環(huán)(其實(shí)還有第零環(huán),是業(yè)務(wù)在數(shù)據(jù)源側(cè)的規(guī)劃),而這一塊也是大部分?jǐn)?shù)據(jù)工程中遇到最頭疼的問題之一。首先,數(shù)據(jù)源就包含很多種,最常見的數(shù)據(jù)源包括關(guān)系型數(shù)據(jù)庫、數(shù)據(jù)湖和實(shí)時(shí)的流數(shù)據(jù)。其次,不管是手動(dòng)還是自動(dòng)的ETL流水線,都需要專業(yè)的數(shù)據(jù)工程團(tuán)隊(duì)來構(gòu)建和維護(hù),并且經(jīng)常要處理或介入數(shù)據(jù)結(jié)構(gòu)的變更等情況。這次,Redshift連發(fā)多個(gè)功能特性來幫助客戶解決或者消除這類問題。
首先是最常見的關(guān)系型數(shù)據(jù)庫,也就是經(jīng)典的OLTP向OLAP的數(shù)據(jù)傳遞。如果是為了更快或者更實(shí)時(shí)地獲取線上業(yè)務(wù)的事務(wù)數(shù)據(jù)來做分析,通??梢酝ㄟ^開啟數(shù)據(jù)庫的binlog來捕捉CDC變更,然后再使用解析CDC的工具如Amazon DMS、Debezium等來實(shí)現(xiàn),這些都需要客戶進(jìn)行不斷的監(jiān)控、配置和優(yōu)化。此外,不同的數(shù)據(jù)庫和數(shù)據(jù)表可能會(huì)有不同的需求,這樣就再加倍了數(shù)量級(jí)的維護(hù)成本。
相信大家對(duì)Redshift印象最深的一個(gè)功能就是Zero ETL,幫助客戶完成從1到0的過程!Redshift通過與Amazon Aurora數(shù)據(jù)庫深度集成,在事務(wù)型數(shù)據(jù)寫入Aurora后,數(shù)據(jù)在底層被持續(xù)地復(fù)制到Redshift,完成行式數(shù)據(jù)存儲(chǔ)到列式數(shù)據(jù)存儲(chǔ)的轉(zhuǎn)換,徹底消除了自己構(gòu)建和維護(hù)復(fù)雜數(shù)據(jù)管道的工作。沒有Hybrid OLTP和OLAP,仍然是熟悉的Amazon Purpose-Build(Aurora還是 Aurora,Redshift還是Redshift)各司其職解決最實(shí)際的問題。同時(shí),客戶的應(yīng)用程序架構(gòu)保持不變,讀寫端點(diǎn)指向Aurora,分析端點(diǎn)指向Redshift,但是底層已經(jīng)不再是一大串接一大串的數(shù)據(jù)抽取、轉(zhuǎn)換和加載,直接無縫銜接并且達(dá)到近實(shí)時(shí)的效果。
然后是數(shù)據(jù)湖S3,Redshift開始支持從S3數(shù)據(jù)湖中自動(dòng)復(fù)制,手動(dòng)擋升級(jí)自動(dòng)擋。之前,如果想要拷貝數(shù)據(jù)都需要手動(dòng)或者定時(shí)執(zhí)行COPY命令,現(xiàn)在Redshift新添加了COPY JOB命令自動(dòng)檢測(cè)指定路徑的新文件,跳過已經(jīng)加載完畢的舊文件。以前編寫的定時(shí)任務(wù)腳本可以退役了,而且再也不用擔(dān)心手抖重復(fù)執(zhí)行,生活變得更美好了。
如果業(yè)務(wù)需求是實(shí)時(shí)的,那么通過S3作為Staging存儲(chǔ)再COPY的方式就跟不上節(jié)奏了,所以,流數(shù)據(jù)也要拿下。re:Invent之前,Redshift流式攝入已經(jīng)開始支持Amazon Kinesis Data Streams,這次發(fā)布更是添加了Amazon Managed Streaming for Apache Kafka(MSK),同時(shí)流式攝入也正式推出,告別預(yù)覽。從上面的圖中可以看出,流式攝入合并了數(shù)據(jù)消費(fèi)的過程,直接在Redshift中實(shí)現(xiàn)并持續(xù)加載到數(shù)據(jù)倉庫。在Redshift中,流式攝入是通過物化視圖的方式實(shí)現(xiàn)的(查找官方文檔是在物化視圖章節(jié)),用戶還可以在這個(gè)物化視圖基礎(chǔ)上再配合其他數(shù)據(jù)疊加物化視圖提高查詢效率。另外,別忘了還可以給流式攝入開啟自動(dòng)刷新功能。從此,客戶可以更簡單地完成實(shí)時(shí)數(shù)據(jù)分析,包括IoT物聯(lián)網(wǎng)設(shè)備、點(diǎn)擊流、應(yīng)用程序監(jiān)控、欺詐檢測(cè)和游戲?qū)崟r(shí)排行榜等。
以上,Redshift簡化了各種最經(jīng)典的數(shù)據(jù)源ETL方式,數(shù)據(jù)坐等分析。
更多數(shù)據(jù)分析的利器
來點(diǎn)火花
數(shù)據(jù)已經(jīng)妥妥地進(jìn)到了數(shù)據(jù)倉庫的碗里來,接下來就請(qǐng)開始它的表演了。此時(shí),數(shù)據(jù)工程師表示Redshift SQL很好,但是還有些更復(fù)雜業(yè)務(wù)數(shù)據(jù)邏輯更適合通過代碼的方式進(jìn)行操作和處理(而不是通過UDF)。開源大數(shù)據(jù)生態(tài)體系下有非常豐富的軟件供組織采用了,其中功能完善、發(fā)展穩(wěn)定的Apache Spark往往是一個(gè)優(yōu)先的選擇。在亞馬遜云科技平臺(tái)上使用Spark并不復(fù)雜,有托管服務(wù)EMR和Glue保駕護(hù)航,還有新發(fā)布的Amazon Athena for Apache Spark可以極速啟動(dòng)交互。但是,說到Spark和Redshift之間進(jìn)行數(shù)據(jù)分析還是需要折騰一下的,或者是通過將Redshift中的數(shù)據(jù)導(dǎo)出到S3中,或者是使用各種第三方的Spark連接器,前者需要多走一步浪費(fèi)時(shí)間和資源,后者沒有多少人維護(hù)不說,性能和安全性都令人堪憂。因此,Amazon Redshift integration for Apache Spark應(yīng)運(yùn)而生。
這個(gè)內(nèi)置集成模式基于一個(gè)之前的開源項(xiàng)目,提升了性能和安全性,相信后續(xù)亞馬遜云科技仍將繼續(xù)跟進(jìn)這個(gè)開源項(xiàng)目,并將各種升級(jí)改造的好東西貢獻(xiàn)給社區(qū)。目前,EMR、EMR on EKS、EMR Serverless和Glue(限定版本)都預(yù)置了打包好的連接器和JDBC驅(qū)動(dòng)程序,客戶完全可以直接開始編寫代碼(有愛好者迫不及待連夜在EMR Studio中使用EMR on EKS完成了對(duì)Redshift Serverless和集群模式的交互式讀寫測(cè)試,體驗(yàn)極佳),對(duì)Redshift中的數(shù)據(jù)進(jìn)行處理。如果客戶的數(shù)據(jù)分析工作負(fù)載以Spark為主,也可以通過Spark統(tǒng)一對(duì)各種數(shù)據(jù)源的分析。