這一標(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)檢測指定路徑的新文件，跳過已經(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)控、欺詐檢測和游戲?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和集群模式的交互式讀寫測試，體驗(yàn)極佳），對(duì)Redshift中的數(shù)據(jù)進(jìn)行處理。如果客戶的數(shù)據(jù)分析工作負(fù)載以Spark為主，也可以通過Spark統(tǒng)一對(duì)各種數(shù)據(jù)源的分析。