化繁為簡(jiǎn)，亞馬遜云科技Amazon Redshift開(kāi)啟云原生數倉新篇章

這一標志性的技術(shù)盛宴再一次給人們留下了無(wú)限的想象空間，等待大家在新的一年去持續探索和發(fā)掘。

 而最讓人關(guān)注的，應該就是各類(lèi)新服務(wù)了，今年無(wú)論是Adam還是Swami博士的Keynote很多篇幅都是和數據相關(guān)的新服務(wù)和新特性，尤其是Swami博士關(guān)于數據創(chuàng )新起源的表述以及新的端到端云原生數據戰略。所以，接下來(lái)將目光切回今天這篇文章關(guān)注的對象——數據，更具體地說(shuō)是眾多新發(fā)布中占據高位的Amazon Redshift云數據倉庫。

簡(jiǎn)化數據攝入工作

最好是沒(méi)有

 要想數據分析到位，首先要保證有穩定、可靠的數據攝入通道，來(lái)實(shí)現端到端的第一環(huán)（其實(shí)還有第零環(huán)，是業(yè)務(wù)在數據源側的規劃），而這一塊也是大部分數據工程中遇到最頭疼的問(wèn)題之一。首先，數據源就包含很多種，最常見(jiàn)的數據源包括關(guān)系型數據庫、數據湖和實(shí)時(shí)的流數據。其次，不管是手動(dòng)還是自動(dòng)的ETL流水線(xiàn)，都需要專(zhuān)業(yè)的數據工程團隊來(lái)構建和維護，并且經(jīng)常要處理或介入數據結構的變更等情況。這次，Redshift連發(fā)多個(gè)功能特性來(lái)幫助客戶(hù)解決或者消除這類(lèi)問(wèn)題。

 首先是最常見(jiàn)的關(guān)系型數據庫，也就是經(jīng)典的OLTP向OLAP的數據傳遞。如果是為了更快或者更實(shí)時(shí)地獲取線(xiàn)上業(yè)務(wù)的事務(wù)數據來(lái)做分析，通�？梢酝ㄟ^(guò)開(kāi)啟數據庫的binlog來(lái)捕捉CDC變更，然后再使用解析CDC的工具如Amazon DMS、Debezium等來(lái)實(shí)現，這些都需要客戶(hù)進(jìn)行不斷的監控、配置和優(yōu)化。此外，不同的數據庫和數據表可能會(huì )有不同的需求，這樣就再加倍了數量級的維護成本。

 相信大家對Redshift印象最深的一個(gè)功能就是Zero ETL，幫助客戶(hù)完成從1到0的過(guò)程！Redshift通過(guò)與Amazon Aurora數據庫深度集成，在事務(wù)型數據寫(xiě)入Aurora后，數據在底層被持續地復制到Redshift，完成行式數據存儲到列式數據存儲的轉換，徹底消除了自己構建和維護復雜數據管道的工作。沒(méi)有Hybrid OLTP和OLAP，仍然是熟悉的Amazon Purpose-Build（Aurora還是 Aurora，Redshift還是Redshift）各司其職解決最實(shí)際的問(wèn)題。同時(shí)，客戶(hù)的應用程序架構保持不變，讀寫(xiě)端點(diǎn)指向Aurora，分析端點(diǎn)指向Redshift，但是底層已經(jīng)不再是一大串接一大串的數據抽取、轉換和加載，直接無(wú)縫銜接并且達到近實(shí)時(shí)的效果。

 然后是數據湖S3，Redshift開(kāi)始支持從S3數據湖中自動(dòng)復制，手動(dòng)擋升級自動(dòng)擋。之前，如果想要拷貝數據都需要手動(dòng)或者定時(shí)執行COPY命令，現在Redshift新添加了COPY JOB命令自動(dòng)檢測指定路徑的新文件，跳過(guò)已經(jīng)加載完畢的舊文件。以前編寫(xiě)的定時(shí)任務(wù)腳本可以退役了，而且再也不用擔心手抖重復執行，生活變得更美好了。

 如果業(yè)務(wù)需求是實(shí)時(shí)的，那么通過(guò)S3作為Staging存儲再COPY的方式就跟不上節奏了，所以，流數據也要拿下。re:Invent之前，Redshift流式攝入已經(jīng)開(kāi)始支持Amazon Kinesis Data Streams，這次發(fā)布更是添加了Amazon Managed Streaming for Apache Kafka（MSK），同時(shí)流式攝入也正式推出，告別預覽。從上面的圖中可以看出，流式攝入合并了數據消費的過(guò)程，直接在Redshift中實(shí)現并持續加載到數據倉庫。在Redshift中，流式攝入是通過(guò)物化視圖的方式實(shí)現的（查找官方文檔是在物化視圖章節），用戶(hù)還可以在這個(gè)物化視圖基礎上再配合其他數據疊加物化視圖提高查詢(xún)效率。另外，別忘了還可以給流式攝入開(kāi)啟自動(dòng)刷新功能。從此，客戶(hù)可以更簡(jiǎn)單地完成實(shí)時(shí)數據分析，包括IoT物聯(lián)網(wǎng)設備、點(diǎn)擊流、應用程序監控、欺詐檢測和游戲實(shí)時(shí)排行榜等。

 以上，Redshift簡(jiǎn)化了各種最經(jīng)典的數據源ETL方式，數據坐等分析。

 更多數據分析的利器

 來(lái)點(diǎn)火花

 數據已經(jīng)妥妥地進(jìn)到了數據倉庫的碗里來(lái)，接下來(lái)就請開(kāi)始它的表演了。此時(shí)，數據工程師表示Redshift SQL很好，但是還有些更復雜業(yè)務(wù)數據邏輯更適合通過(guò)代碼的方式進(jìn)行操作和處理（而不是通過(guò)UDF）。開(kāi)源大數據生態(tài)體系下有非常豐富的軟件供組織采用了，其中功能完善、發(fā)展穩定的Apache Spark往往是一個(gè)優(yōu)先的選擇。在亞馬遜云科技平臺上使用Spark并不復雜，有托管服務(wù)EMR和Glue保駕護航，還有新發(fā)布的Amazon Athena for Apache Spark可以極速啟動(dòng)交互。但是，說(shuō)到Spark和Redshift之間進(jìn)行數據分析還是需要折騰一下的，或者是通過(guò)將Redshift中的數據導出到S3中，或者是使用各種第三方的Spark連接器，前者需要多走一步浪費時(shí)間和資源，后者沒(méi)有多少人維護不說(shuō)，性能和安全性都令人堪憂(yōu)。因此，Amazon Redshift integration for Apache Spark應運而生。

 這個(gè)內置集成模式基于一個(gè)之前的開(kāi)源項目，提升了性能和安全性，相信后續亞馬遜云科技仍將繼續跟進(jìn)這個(gè)開(kāi)源項目，并將各種升級改造的好東西貢獻給社區。目前，EMR、EMR on EKS、EMR Serverless和Glue（限定版本）都預置了打包好的連接器和JDBC驅動(dòng)程序，客戶(hù)完全可以直接開(kāi)始編寫(xiě)代碼（有愛(ài)好者迫不及待連夜在EMR Studio中使用EMR on EKS完成了對Redshift Serverless和集群模式的交互式讀寫(xiě)測試，體驗極佳），對Redshift中的數據進(jìn)行處理。如果客戶(hù)的數據分析工作負載以Spark為主，也可以通過(guò)Spark統一對各種數據源的分析。