從圖中可以看到，無論是數(shù)據(jù)庫，還是數(shù)據(jù)分析，在AWS，我們都有很多的產(chǎn)品選擇。
以數(shù)據(jù)庫為例，有Aurora、RDS、RDS on VMware，有DynamoDB、ElastiCache和Neptune等，與數(shù)據(jù)分析相關，有Redshift、EMR、Athena、Elasticsearch Service和Kinesis Data Analytics。
不要說我，一個區(qū)區(qū)的記者，我想即使對于專業(yè)技術人員，恐怕也難面面俱到，把這些技術都搞清楚。
不就是數(shù)據(jù)庫、數(shù)據(jù)分析嗎？為什么要搞的這樣復雜？
其實道理也很簡單。
不同的應用場景，有其適合產(chǎn)品，張冠李戴是不行的。
以前，計算能力有限且昂貴，好鋼需要刀刃上。那個時候，數(shù)據(jù)庫和數(shù)據(jù)分析應用以關系型數(shù)據(jù)為主，其數(shù)據(jù)量的占比是10%～15%，但數(shù)據(jù)價值高達85%；其余85%的數(shù)據(jù)并不被存儲、分析。
但是隨著計算能力的提升，特別是Intel x86服務器的廣泛應用，計算成本不再是稀缺的資源；與此同時，用戶行為等大數(shù)據(jù)應用備受重視。在這種情況下，各種數(shù)據(jù)存儲和分析工具應運而生，開源技術發(fā)展，也發(fā)揮了推波助瀾的作用。
同樣是數(shù)據(jù)分析，數(shù)據(jù)類型不同，使用的手段和工具也不盡相同。如數(shù)據(jù)倉庫可以用Redshift，Hadoop+Spark應用可以使用EMR，交互式數(shù)據(jù)分析使用Athena，實時數(shù)據(jù)分析使用Kinesis Data Analytics，運營數(shù)據(jù)分析使用Elasticsearch Service。
數(shù)據(jù)庫也是如此，有關系型數(shù)據(jù)庫，如Aurora、RDS，有鍵值文檔數(shù)據(jù)庫DynamoDB，有圖形數(shù)據(jù)庫Neptune，以及ElastiCache等。
互聯(lián)網(wǎng)用戶如Epic Games，這是一家游戲公司，全球都非常知名的“吃雞”游戲，就是所說《堡壘之夜》就是這家公司的杰作，非常流行的。Epic會把所有用戶在線玩游戲中的數(shù)據(jù)導入到S3中，并利用各種定制化工具，分析用戶在游戲中的行為。
可以說，新工具的廣泛應用讓互聯(lián)網(wǎng)、網(wǎng)游企業(yè)占據(jù)了先發(fā)的優(yōu)勢，對于傳統(tǒng)企業(yè)級客戶而言，也需要以數(shù)據(jù)湖為基礎，更好地分析數(shù)據(jù)。
相比于傳統(tǒng)的數(shù)據(jù)庫、數(shù)據(jù)倉庫，新的開源軟件以及互聯(lián)網(wǎng)SaaS服務，在性能、成本上都占據(jù)優(yōu)勢。
以Redshift為例。傳統(tǒng)數(shù)據(jù)倉庫只能夠處理GB級、TB級的數(shù)據(jù)，還沒有達到PB級，TB級數(shù)據(jù)處理就需要大約1萬～5萬美元。有數(shù)據(jù)表明，傳統(tǒng)數(shù)據(jù)倉庫僅能夠處理企業(yè)10%左右的數(shù)據(jù)。為獲得更加深遠的洞見，企業(yè)用戶希望能夠分析處理100%的數(shù)據(jù)。依靠傳統(tǒng)數(shù)據(jù)倉庫產(chǎn)品，這是不可能的事情。
Redshift的出現(xiàn)彌補了傳統(tǒng)應用的不足，它能夠處理PB、EB級的數(shù)據(jù)，處理性能是傳統(tǒng)數(shù)據(jù)倉庫的10倍。同樣TB級數(shù)據(jù)處理，所需要的成本僅為1000美元，是傳統(tǒng)方法的1/10。
因此，新技術的出現(xiàn)，為企業(yè)級用戶提供了新的選擇。
不同于傳統(tǒng)交鑰匙的方案，新時期，需要用戶有更加廣闊的視野，需要具備DIY的能力。在開源、SaaS云服務的世界中，新的技術、功能，無時不刻涌現(xiàn)，將這些技術不斷運用到業(yè)務創(chuàng)新中，這個是新事情用戶必須具備的能力。
“一慢、二看、三通過”已經(jīng)不符合時代的步伐。
到了需要改變的時候了！加油！
