應該何時把大數(shù)據(jù)遷移到云上
云對每個人來說都是又大、又白、又輕柔的夢境。當有人說他們的大數(shù)據(jù)戰(zhàn)略是“把全部投入云端”時,你無法確定他們是否是一個有遠見的人,或僅僅是重復一個專家在一次行業(yè)會議上告訴他們的事。
大數(shù)據(jù)和云范例之間實際的重復非常廣泛,你可以宣稱你正在一個內部部署的Hadoop、NoSQL、或企業(yè)數(shù)據(jù)倉庫環(huán)境下處理基于云的大數(shù)據(jù)。請記住云被廣泛理解為包含“私有”部署以補充或代替公共云、SaaS、和多租戶托管環(huán)境。
但是如果你把云的實際定義限制于公共訂購服務內,你就能找到問題的核心:識別哪些大數(shù)據(jù)應用相對于內部部署更適合公共云/SaaS 部署(比如那些涉及提前優(yōu)化的硬件設備或虛擬服務器集群的應用)。
換句話說:你什么時候可以通過引進一個外部服務供應商為你管理它們,從而提高大數(shù)據(jù)的可擴展性、靈活性、性能、成本效益、可靠性、以及可管理性?以下是一些明確的大數(shù)據(jù)在公共云中的使用實例。
已經在云中托管的企業(yè)應用程序:如果和許多企業(yè)一樣——尤其是中小型企業(yè)——你使用了一個外部服務供應商提供的基于云的應用程序,許多你的源交易數(shù)據(jù)已經被置于公共云之上。如果你在這個云平臺上有更深入的歷史數(shù)據(jù),那么它可能已經積累至大數(shù)據(jù)級。如果外部服務供應商或它的合作伙伴之一提供了一個增值的分析服務——如客戶流失分析、營銷優(yōu)化、或客戶數(shù)據(jù)的異地備份和歸檔——那么利用這些服務會比將這些數(shù)據(jù)置于內部來得有意義。
需要相當大的預處理能力的大容量外部數(shù)據(jù)源:例如,如果你打算通過監(jiān)測社交媒體數(shù)據(jù)的聚合輸入來分析客戶的情感,內部的服務器、存儲、或帶寬容量可能無法很好地為你完成這項任務。這是一個明顯的關于應用程序的例子,在這里你會希望利用一個基于公共云的、大數(shù)據(jù)驅動的服務所提供的社交媒體過濾服務解決問題。
超過你內部部署的大數(shù)據(jù)處理能力的策略型應用程序:如果你已經有一個專門為某個應用程序內部部署的大數(shù)據(jù)平臺(比如高容量非結構化數(shù)據(jù)源ETL專用的Hadoop集群),那么使用一個公共云來處理當前平臺所不適用的、或是按需服務會更健壯或劃算的新的應用程序(例如多渠道營銷、社交媒體分析、地理空間分析、可查詢歸檔、彈性數(shù)據(jù)沙盒技術)可能會更行得通。事實上,如果你需要盡快獲得PB級規(guī)模的、流媒體的、多結構的大數(shù)據(jù)處理能力,那么一個公共云產品可能是唯一可行的選擇。
非常大但只是短暫存在的沙盒的彈性供應:如果你有一個短期周轉的短期數(shù)據(jù)科學項目,而這個項目需要比慣常大一個數(shù)量級的探索型數(shù)據(jù)集市(又名沙盒),那么云可能是你唯一可行或可以支付的選擇。你能夠很快在項目期間運作基于云的存儲和處理能力,然后當項目結束時又可以很快的取消之前配置的一切。我稱之為“泡沫集市”部署模型,它是為云量身定制的。
如果你已經有過這其中任一的經歷,那么基于云的大數(shù)據(jù)的戰(zhàn)略問題就不是你該從何開始。隨著基于云的大數(shù)據(jù)服務逐漸成熟以及性價比(包括性能、可擴展性、靈活性和可管理性)不斷提高,這個問題將會是你該在哪結束。到本個十年的末期,隨著越來越多的應用程序和數(shù)據(jù)遷移到公共云上,建立和運作你自己的大數(shù)據(jù)部署的想法似乎如同現(xiàn)在你想設計自己的服務器一般不切實際。





