盡管AI、物聯(lián)網以及GDPR(一般數(shù)據保護條例)持續(xù)占據頭條，但也不要忘記在大數(shù)據的實現(xiàn)性應用方面，云遷移與流分析所產生的劃時代影響。

　　誠然，AI所產生的影響已然無法忽視，其影響所覆蓋的范圍從地緣政治到市井瑣事，甚至還參與了一些舉世聞名的事件。此外，物聯(lián)網在當今社會中日益增長的影響也是不容忽視的，具體包括家庭、醫(yī)院提供醫(yī)療服務的方式、自動駕駛汽車的驅動、工廠的運營以及智能化城市管理等方面。爾后，GDPR將在2018年生效，這將迫使各組織著力解決將涉及隱私與國家主權影響的數(shù)據從現(xiàn)有數(shù)據庫轉移到數(shù)據湖與云存儲的過程中所要面臨的問題。

　　透過表面看本質，我們發(fā)現(xiàn)構造性轉變已經開始，具體包括企業(yè)在云領域的管理方式、流數(shù)據分析與數(shù)據湖戰(zhàn)略等。

　　目前，已有27.5%的大數(shù)據工作負載運行在云端(來源：Ovum ICT Enterprise Insights)

　　關于未來展望，我們將著眼于數(shù)據的管理方式?；仡欉^去的一年，我們曾表示“大數(shù)據——無論其來自于物聯(lián)網還是更為傳統(tǒng)的資源——將會逐步實現(xiàn)在云中完成存儲與處理。”去年，我們預計會有35—40%的新生大數(shù)據工作負載將在云端完成部署，而到2018年底，新的部署將超過50%。

　　我們的預測并非不切實際;Ovum針對所有大數(shù)據工作負載的最新全球調查研究顯示，在此之中的27.5%已經完成了云端部署。另外，根據Ovum的報告，企業(yè)云應用很難將大數(shù)據拒之門外，而在各式各樣的工作負載中，企業(yè)云應用所占據的比例在26—30%之間。

　　由于慣性使然，大多數(shù)組織已經不再堅持立足云環(huán)境復制與其自有數(shù)據中心相關的種種功能特性。此外，大多數(shù)組織會選擇使用多個家云供應商，這看似是為了取各家之所長。然而，正如以往的類似教訓一樣，這其實只是自上而下的企業(yè)標準政策與部門針對相關政策權衡之后所做出的妥協(xié)性決策產物。

　　因此，如同您所在的組織可能面臨SAP的使用成本一樣，不同部門可能同樣面臨著與人力資源相關的日常開銷或CRM銷售壓力，抑或擁有多種尚未與企業(yè)遺留方案相融合的ERP系統(tǒng)。在云端，企業(yè)電子郵件系統(tǒng)可能通過Office 365實現(xiàn)，而部門IT團隊則將使用AWS進行開發(fā)與測試; 與此同時，企業(yè)營銷團隊使用的則是Google Analytics。

　　隨著云從運行獨立工作負載的目標發(fā)展至企業(yè)關鍵型應用，我們預計在2018年初期，大多數(shù)公司將開始正式實施多云策略——正如在2017年，我們將云端部署視為大數(shù)據的隱患一般——多云也因此將成為2018年亟待解決的問題。也正因為如此，甲骨文方面決定將運行在亞馬遜RDS服務上的數(shù)據庫產品的使用價格進行翻倍; 這也是為何Aurora OLTP數(shù)據庫目前能夠成為亞馬遜公司中增長速度最快的服務(在此之前的冠軍為Redshift)。

　　這不僅僅是云供應商對于此類擔憂的反應性決策，多云的決策將影響有關平臺的選擇。當您選擇在EC 2上運行一套甲骨文的數(shù)據庫或Hadoop集群時——若Azure或Google Cloud調整其定價——這同時也成為了一項值得重新審視的抉擇。

　　當您選擇在IBM云端運行Aurora、Cosmos DB、谷歌BigQuery、甲骨文Autonomous數(shù)據庫18c或IBM分析系統(tǒng)時，這不僅意味著需要選擇云，還需要選擇數(shù)據平臺。現(xiàn)在，您對于這一選擇是否能夠讓運行一套特定云的數(shù)據平臺增值的關注度已經遠勝于是否選擇依賴一家特定的云供應商——這就如同讓您再一次面對甲骨文公司或SQL Server平臺做出決策。

　　誠然，這也是亞馬遜公司與微軟方面正在以幾乎免費的方式提供數(shù)據庫遷移服務的原因——毫無疑問的是這兩家公司想要占領您的企業(yè)數(shù)據庫。同樣，我們預計Google Cloud、甲骨文與IBM將會在2018年積極以虧損方式搶占數(shù)據庫遷移服務份額，并且越來越多的企業(yè)會在這一領域拼盡全力。

　　多云戰(zhàn)略也將在混合云的管理方面發(fā)揮至關重要的作用。正如鮮有組織——無論其規(guī)模如何——傾向于依賴單一云供應商一般，也很少有組織(除了初創(chuàng)企業(yè)之外)會將全部的工作負載轉移至云端。在云計算平臺運行分析時，無論是在設計抑或是數(shù)據主權的問題上，維護敏感客戶記錄的透明度將會成為影響云計算平臺選擇的主要因素。

　　數(shù)據管道改變了實時處理的重心

　　去年，我們預測“物聯(lián)網將成為把實時流數(shù)據推向前端的應用實例?！苯衲?，谷歌方面的Anadiotis預測，不僅流數(shù)據將成為主流，“并且還將逐步實現(xiàn)即時分析?！?/p>

　　流數(shù)據分析并非是新鮮術語;在此之前，我們已經投入了大量精力以讓其重拾關注。在進行數(shù)據存儲之前，流數(shù)據處理可被用于數(shù)據的解析與過濾以及模式或事件的檢測。物聯(lián)網數(shù)據的爆炸式增長自然催生了難題——所有數(shù)據是否都需要存儲以及在哪里完成數(shù)據的處理。

　　隨著我們日益增長的技術需求，我們希望能夠在數(shù)據運行的同時完成更多的工作負載。這不僅解釋了用于隊列處理的Kafka與分發(fā)數(shù)據技術的萌生，還表明了數(shù)據平臺供應商——諸如SAP、 Hortonworks、MapR與 Teradata——正在采取相關行動的原因。 Amazon Kinesis、 Azure Data Factory以及 Google Cloud Dataflow的崛起亦是這類即時需求的直接產物。數(shù)據管道能夠將實時處理從基礎過濾與轉換擴展為協(xié)調進程，從而支持高級預測分析與機器學習。因此，我們預計數(shù)據管道將在2018年成為流式分析的關鍵性支柱。此外，我們還將在這個領域聽到來自于IBM與甲骨文等供應商所帶來的更多消息。

　　云存儲已在客觀層面扮演數(shù)據湖角色

　　因為數(shù)據湖是專為保存那些不適合于其它位置且易丟失的數(shù)據而設計，所以當您想到數(shù)據湖時，您可能自然就會想到Hadoop。我們已經將數(shù)據湖定義為受管理的存儲庫，并致力于讓其成為數(shù)據的默認提取點。但是，我們現(xiàn)在發(fā)現(xiàn)數(shù)據湖的安裝啟用超過了Hadoop。或者正如Mike Olson在2014年所預言的一般——Hadoop終將消失。

　　數(shù)據湖以聯(lián)動查詢工具作為起點，現(xiàn)已成為每個分析數(shù)據庫的配套項目。我們已經見證了JSON數(shù)據庫通過Spark進行擴展，從而實現(xiàn)分析查詢。此外，我們還目睹了各Hadoop供應商(例如Cloudera 與 Hortonworks)將其數(shù)據管理服務與HDFS分離。所以，現(xiàn)在數(shù)據湖即是數(shù)據存儲的位置所在。

　　毫無疑問，云供應商享有最后的發(fā)言權：在云端，云存儲顯然已成為數(shù)據的默認攝取點。所以，云供應商正在致力于讓其云對象存儲配備直接查詢功能。亞馬遜方面現(xiàn)在已可通過S3直接訪問配有Athena 的SQL 實際查詢，并可作為Redshift Spectrum數(shù)據倉庫的擴展。Google Cloud早已將其云存儲作為BigQuery的默認來源，而Snowflake——第三方云數(shù)據倉庫——也是如此。

　　此外，頗為諷刺的是，云存儲最初其實專為存儲需求而設計。然而，在云對象存儲占據了大部分數(shù)據的世界里，催生了企業(yè)要優(yōu)化訪問需求。所以在2018年，我們預計幾乎所有的數(shù)據倉庫與分析數(shù)據庫都將對接當下流行的云對象存儲方案，具體包括S3、Azure BLOB Storage與Google Cloud Storage等支持目標。