一出上云大戲，一曲數(shù)據(jù)倉庫的悲歌？

對于一家自身組織運(yùn)行歷史數(shù)十年的公司來說，數(shù)據(jù)倉庫會是一種有效幫助其報告和理解相關(guān)操作的方式。在數(shù)據(jù)倉庫出現(xiàn)之前，對來自不同系統(tǒng)的數(shù)據(jù)進(jìn)行報告與收集是一項昂貴、耗時而且常常徒勞無功的嘗試，而數(shù)據(jù)倉庫保證了來自單個存儲庫數(shù)據(jù)的干凈與集成性。

將多種報表工具連接到單個數(shù)據(jù)模型的能力催生了一個我們目前很數(shù)據(jù)的行業(yè): 商業(yè)智能(BI)。然而，由于復(fù)雜的方法和設(shè)計、不適當(dāng)?shù)墓ぞ咭约案叩拈_發(fā)、維護(hù)和基礎(chǔ)設(shè)施成本所拖累，傳統(tǒng)數(shù)據(jù)倉庫體系結(jié)構(gòu)和方法的原始概念應(yīng)用在今天也變得不再那么易于接受。

可以說，不久前，計算依然是一個非常昂貴的資源，數(shù)據(jù)倉庫還受到“稀缺性管理（managing from scarcity）”觀念的限制。相反，各類方案數(shù)據(jù)設(shè)計也在盡量減少數(shù)據(jù)庫的規(guī)模，比如通過聚合數(shù)據(jù)、創(chuàng)建復(fù)雜的子數(shù)據(jù)庫設(shè)計和密切監(jiān)測資源的使用等。

但是在今天，似乎數(shù)據(jù)倉庫不再那么受到媒體們的重視。

數(shù)據(jù)倉庫，已涼？

隨著大數(shù)據(jù)，尤其是Hadoop的崛起，我們經(jīng)常會聽到供應(yīng)商、分析師和大咖們說數(shù)據(jù)倉庫已經(jīng)死了。畢竟，它們昂貴、僵硬、緩慢。

人們常說，大數(shù)據(jù)是游戲規(guī)則改變者和數(shù)據(jù)倉庫的繼承者。但它其實(shí)不是，如果說有什么區(qū)別的話，那就是大數(shù)據(jù)為數(shù)據(jù)倉庫提供了一個實(shí)現(xiàn)自我價值(或者至少是將其延伸到更接近其原始目地的地方)的機(jī)會:成為有用的、可操作的分析數(shù)據(jù)來源。

但數(shù)據(jù)倉庫的思考者必須放棄對物理結(jié)構(gòu)的執(zhí)著才能做到這一點(diǎn)。相反，未來的數(shù)據(jù)倉庫將不得不與許多不同的數(shù)據(jù)源合作。它將充當(dāng)一種虛擬結(jié)構(gòu)，運(yùn)行一種“安靜的”歷史數(shù)據(jù)倉庫，并進(jìn)行極致化、不受約束的分析數(shù)據(jù)庫以提供實(shí)時更新和實(shí)時響應(yīng)，此外它還將運(yùn)行其他非關(guān)系型大數(shù)據(jù)集群(如Hadoop)的包圍策略。這樣，大數(shù)據(jù)會迫使組織擴(kuò)大其分析業(yè)務(wù)的規(guī)模，無論是在數(shù)量上還是在投入的種類上。而同樣重要的是，企業(yè)還要擴(kuò)展其關(guān)于如何在組織內(nèi)外擴(kuò)展和加強(qiáng)技術(shù)使用的愿景。

本地部署？云？混合？

以下是目前部分(但不完整)的數(shù)據(jù)倉庫平臺列表:

傳統(tǒng)數(shù)據(jù)倉庫“幸存者”，他們最初是本地部署支持者，現(xiàn)在是混合玩家：

?   

IBM

?   

Microsoft

?   

Teradata

?   

Pivotal/Greeenplum

?   

Oracle

純云：

?   

Redshift

?   

Snowflake

?   

Incorta

?   

Google

一般來說，關(guān)系型數(shù)據(jù)庫（RDB）的數(shù)據(jù)倉庫繼承了上述這些模式的所有優(yōu)點(diǎn)和缺點(diǎn)，特別是對于那些專為事務(wù)處理而設(shè)計的RDB而言，但是后者的設(shè)計初衷其實(shí)是為了數(shù)據(jù)倉庫和它們用以支持分析的特別處理需求。

微軟，IBM和Oracle便是其中的代表。在數(shù)據(jù)倉庫的早期階段，這三家產(chǎn)品的性能非常差，這促使客戶尋求了那些專為數(shù)據(jù)倉庫運(yùn)營而設(shè)計的產(chǎn)品，例如Teradata，Red Brick，Pivotal / Greemplum，Vertica以及Paraccel，后者的來源代碼由亞馬遜授權(quán)并重新命名為Redshift。

后來，廠商們在改進(jìn)他們數(shù)據(jù)倉庫產(chǎn)品方面取得了一定的進(jìn)展。如微軟授權(quán)Sybase為SQLServer提供代碼，IBM和Oracle也不斷改進(jìn)和改進(jìn)他們的產(chǎn)品。

就目前而言，所有五個“幸存者”都擁有完整的云，本地部署和混合云解決方案。問題是，“純云計算”產(chǎn)品和“幸存者”的云產(chǎn)品真的有什么不同嗎？

每個產(chǎn)品都有一系列重疊的功能，但核心問題是：

基于云的數(shù)據(jù)倉庫有哪些優(yōu)勢？

與純云產(chǎn)品相比，“幸存者”是否提供了足夠的優(yōu)勢？

大數(shù)據(jù)服務(wù)公司Alooma 指出：

“每個云倉庫都有自己的結(jié)構(gòu)，而不是遵循特定的結(jié)構(gòu)。例如，Amazon Redshift模仿傳統(tǒng)數(shù)據(jù)倉庫的結(jié)構(gòu)，而谷歌BigQuery根本不使用服務(wù)器，它允許用戶查詢和共享數(shù)據(jù)，而無需設(shè)置和支付存儲費(fèi)用。”

那么，云數(shù)據(jù)倉庫會帶來些什么？

規(guī)模/擴(kuò)展性: 通常，計算資源是數(shù)據(jù)倉庫中比數(shù)據(jù)存儲更昂貴的組件。通過將計算資源從存儲中分離出來，數(shù)據(jù)倉庫可以存儲大量數(shù)據(jù)，并按要求處理信息。在本地方案中，所有這些數(shù)據(jù)都需要以高得多的成本進(jìn)行本地存儲。

靈活性:通過將數(shù)據(jù)從計算流程中分離出來，用戶可以創(chuàng)建所需的任意數(shù)量的虛擬數(shù)據(jù)倉庫。

性能: 這仍然是一個一目了然的事情，在數(shù)據(jù)倉庫/分析查詢中，僅僅多運(yùn)行幾個服務(wù)器并不意味著性能的提升。讓Teradata這樣專門的廠商如此成功的原因是，幾十年的工程設(shè)計，大規(guī)模的并行處理優(yōu)化和工作負(fù)載的管理技術(shù)，或許最重要的是，Teradata提供軟件引擎與用戶所運(yùn)行的專有硬件之間的鏈接，并且性能還在不斷改善。

成本: 每個人都在說云改變了定價模式，但是沒人確定實(shí)施的成本是多少。廉價存儲的誘惑可能會導(dǎo)致事情失控，因?yàn)樗赡苁窍鄬Ρ阋说?，但終歸不是免費(fèi)的。所有的傳統(tǒng)廠商都轉(zhuǎn)向了訂閱定價方案，但每個合同都非常復(fù)雜。這里建議是聘請一位合同和定價細(xì)節(jié)方面的專家(我們在ERP領(lǐng)域中經(jīng)?？吹竭@一點(diǎn))。

安全性:這是一個棘手的問題，因?yàn)橛刑嗟慕尤朦c(diǎn)，尤其是在混合解決方案中。大多數(shù)數(shù)據(jù)庫產(chǎn)品會實(shí)施針對內(nèi)部威脅的安全性，但是近些年來自外部威脅的激增。

一個數(shù)據(jù)倉庫應(yīng)具有哪些能力？

?支持任何數(shù)據(jù)局部性(本地磁盤、Hadoop、私有和公有云數(shù)據(jù))。

?數(shù)據(jù)庫內(nèi)高級分析。

?能夠處理本地各類型數(shù)據(jù)，如空間、時間序列和/或文本。

?能夠運(yùn)行新的分析工作負(fù)載，包括機(jī)器學(xué)習(xí)、地理空間、圖形和文本分析。

?靈活部署，包括在本地、私有和公有云上。

?大數(shù)據(jù)查詢優(yōu)化。

?復(fù)雜的查詢形式。

?基于模型的大規(guī)模并行處理，而不僅僅是分片處理。

?工作負(fù)載管理。

?負(fù)載平衡。

?可擴(kuò)展到數(shù)千個并發(fā)查詢。

?完整的ANSI SQL及更多。

寫在最后

原生云數(shù)據(jù)倉庫數(shù)據(jù)庫可能提供以前的“幸存者”數(shù)據(jù)庫所沒有的功能和優(yōu)勢，但是它們有多健壯呢? 我們目前不好妄下評論，但是，一些純云產(chǎn)品在滿足用戶的許多需求方面都相對較差。它們是數(shù)據(jù)倉庫產(chǎn)品，還是現(xiàn)有模塊的集合，并將其綁定在PowerPoint幻燈片上?例如，Cloudera的數(shù)據(jù)倉庫中沒有增加任何在他們開始稱之為數(shù)據(jù)倉庫之前不存在的東西。這就像把不同物種的不同細(xì)胞系扔進(jìn)培養(yǎng)皿里，就稱其為有機(jī)體一樣。

這里，或許還是那句老話“不管黑貓白貓，抓到老鼠就是好貓”。大數(shù)據(jù)吹們總是試圖拋棄掉傳統(tǒng)數(shù)據(jù)倉庫，只是強(qiáng)調(diào)它實(shí)施和技術(shù)問題，而沒有理會它對于組織的價值。所謂的“數(shù)據(jù)湖”可能并不是一個好方案。

生成海報

免責(zé)聲明：此文內(nèi)容為第三方自媒體作者發(fā)布的觀察或評論性文章，所有文字和圖片版權(quán)歸作者所有，且僅代表作者個人觀點(diǎn)，與極客網(wǎng)無關(guān)。文章僅供讀者參考，并請自行核實(shí)相關(guān)內(nèi)容。投訴郵箱：editor@fromgeek.com。

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。