如果你深入了解了要遷移到云的數據以及用來管理數據的云原生目錄的就緒情況，你就有把握加快遷移速度。

我在最近的“賭場之夜”活動中，在21點上押上了所有籌碼，并在最后一手牌大獲全勝。同事對我的勇氣大加贊賞，我還贏得了獎勵(我們不是為了錢而賭博)，他們問我為什么冒險下注，我回答說：“沒有什么危險的。”  

規劃云遷移的大型企業也是如此。按需容量，低成本存儲以及豐富的開源和商業工具生態系統的前景十分激動人心。但是風險是真實存在的，特別是在數據遷移方面。數百家公司現在已經證明，單一數據泄露可能會造成長期的經濟，法律和品牌上的損失。除了數據保護之外，僅僅管理云中的數據是不同的，如果做法不當，成本，復雜性和風險會使一切毀于一旦。  

將數據倉庫或數據湖泊簡單地“提升并轉移”到云中將不會產生成本節省來證明這其中付出的合理性。對總擁有成本(TCO)和規模都有顯著影響的云技術是低成本的對象存儲(例如Amazon S3，ADLS)和彈性數據處理(EMR，Spark)。事實上，利用這些措施來建立一個彈性的(而不是固定的)數據管理云環境，這可以將總擁有成本降低85%之多。  

管理云中的數據需要多少成本?  

需要注意的是，降低數據存儲成本的技術提供的數據管理功能要少得多。Hadoop比Teradata便宜很多，但它不提供成熟的RDBMS(Relational Database Management System，關系數據庫管理系統)所具備的數據完整性控制、負載平衡和自動化。同樣，S3比Hadoop數據節點上的存儲更便宜，但它只是一個文件系統。沒有表，字段或數據類型。如果你要在S3上查詢或處理數據，你需要使用商業或開源工具(例如AWS Glue、EMR)或編寫自定義程序。為了管理和更新S3中的數據，你需要一個數據管理工具(Redshift、Snowflake、Podium)。數據保護僅限于加密文件——當你想要分析在某些字段中具有PII的數據集時，數據保護功能不是很有用。盡管對象存儲可擴展，價格低廉且靈活，但它使數據管理倒退了幾十年。  

與很多不成熟的技術一樣，對象存儲的局限性也被鼓吹為功能特性。它們“允許”程序員處理任意大小，形狀或質量的數據，并解釋其結構和內容。這種“讀取模式(schema on read)”方法適于處理非結構化數據或頻繁更改結構的數據。但它妨礙了自動化、標準化和規模化，這對于協作和重用來說至關重要，因為數據的含義隱藏在代碼中。這聽起來是不是很熟悉?是的。關系數據庫的口號就是要使數據的結構和含義成為聲明式的，而不是嵌入在COBOL重定義中(你可以去查)。  

根據目錄優先策略建立的紐帶  

高度結構化的數據庫和“為所欲為”的對象存儲之間的紐帶是數據目錄。目錄是一個共享數據庫，為對象庫中的數據提供結構和含義。Hadoop目錄包括HIVE、Atlas和Navigator，它們定義了HDFS文件如何構成表和字段。通過API，程序可以查詢目錄來查找邏輯數據對象的結構，其技術和業務屬性，訪問權限以及數據文件的位置。然后這些程序可以將洞察和結果推回到目錄中以豐富它。  

但是，很多云目錄都是被動的——它們掃描文件和日志，歐洲服務器租用 云服務器，在數據得到處理后推斷數據的結構和使用。然而，數據管理必須是主動的，以確保敏感數據不會暴露，重要的數據標準得到了遵守，圖謀不軌者不會實施不牢靠的計劃。所有云遷移都應采用以目錄為中心的策略：  

•所有共享和敏感數據都在一個通用目錄中注冊  

•所有程序都將通過目錄訪問數據并記錄其活動  

這使得公司可以提供支持各種快速發展的技術的基本數據管理。S3上的數據湖泊可以支持Hadoop處理、自定義PySpark代碼、R分析，Amazon Glue等，同時維護(并豐富)共享數據資產。此外，人們還可以制定一個如何存儲，更新和檢查數據質量的標準，從而實現這些任務的自動化。  

目錄還支持彈性，免備案空間 香港服務器，這對云經濟至關重要。目錄可以在一臺服務器上全天候提供使用，它支持業務用戶購買數據，開發人員設計新數據產品，管理員檢查質量并添加業務定義。只有數據處理任務(如數據加載、刷新、準備和分析)需要并行處理能力。關系數據庫和Hadoop習慣上將存儲，處理和目錄結合在一個固定的系統中，隨著數據的增長，成本會全線上升。在新的世界里，目錄又是處理能力和廉價存儲之間的橋梁。大量的數據可以通過目錄進行合理管理，并且可以控制處理成本。實際上，如果目錄具有分析統計信息(例如基數、最小值、最大值)，那么它就可以優化數據的處理。