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