從 Hadoop 遷移到 Lakehouse 架構的 5 個關鍵步驟
從 Hadoop 遷移到基於雲的現代架構（比如 Lakehouse 架構）的決定是業務決策，而非技術決策。我們在之前的文章中探討了每一個組織都必須重新評估他們與 Hadoop 的關係的原因。當來自技術、資料和業務的利害關係方決定將企業從 Hadoop 轉移出去之後，在開始真正的轉變之前，需要考慮Top Considerations When Planning Your Migration Off of Hadoop - The Databricks Blog。本文中，我們將特別關注實際的遷移過程本身。你將學習成功遷移的關鍵步驟，以及 Lakehouse 架構在激發下一輪資料驅動創新中所扮演的角色。
遷移步驟
坦白的說吧，遷移從來不是一件簡單的事情。不過，可以對遷移進行結構化，從而最大限度地減少不利影響，確保業務連續性，並有效地管理成本。為此，我們建議將你從 Hadoop 的遷移分解成以下五個關鍵步驟：
-
管理
-
資料遷移
-
資料處理
-
安全及管治
-
SQL 和 BI 層
第一步：管理
讓我們從管理的角度回顧一下 Hadoop 中的一些基本概念，以及它們與 Databricks 的對比。
Hadoop 本質上是一個單體分散式儲存和計算平臺。它由多個節點和伺服器組成，每個節點都有自己的儲存、CPU 和記憶體。任務被分配到所有這些節點。通過 YARN 來實現資源管理，它力圖確保工作負載能夠獲得其計算份額。
Hadoop 也包括元資料資訊。有一個 Hive 元儲存，它包含了儲存在 HDFS 中的資產的結構化資訊。你可以使用 Sentry 或 Ranger 來控制對資料的訪問。從資料訪問的角度來看，使用者和應用程式可以直接通過 HDFS（或相應的 CLI/API）或通過 SQL 型別的介面訪問資料。另外，SQL 介面可以通過 JDBC/ODBC 連線，使用 Hive 來執行通用 SQL（或在某些情況下使用 ETL 指令碼），或者在 Impala 或 Tez 上使用 Hive 進行互動式查詢。Hadoop 還提供了一個 HBase API 和相關的資料來源服務。
接下來，我們來討論如何在 Databricks Lakehouse 平臺中對映或處理這些服務。在 Databricks 中，首先要注意的一個區別是，你在 Databricks 環境中看到的是多個叢集。每個叢集可以用於特定的用例、特定的專案、業務部門、團隊或開發小組。更重要的是，這些叢集都是短暫的。對於作業叢集來說，叢集的存在時間可以在工作流程的持續期間保持。這將執行工作流程，並且在完成後，環境將自動拆毀。同樣，如果你考慮一個互動式用例，即你有一個可供開發者共享的計算環境，這樣的環境可以在工作日開始，並且開發者全天執行他們的程式碼。在非活動期間，Databricks 會通過平臺內建的（可配置的）自動終止功能自動關閉它。
不同於 Hadoop，Databricks 並不提供諸如 HBase 或 SOLR 那樣的資料儲存服務。你的資料駐留在物件儲存中的檔案儲存。許多類似 HBase 或 SOLR 這樣的服務都可以在雲中找到與之相當的替代品。這可以是雲原生或 ISV 解決方案。
從上圖可以看出，Databricks 中的每個叢集節點都對應於 Spark 驅動或工作器。關鍵在於，不同的 Databricks 叢集彼此完全隔離，這樣，你就可以確保在特定的專案和用例中符合嚴格的 SLA。你可以將流媒體或實時用例與其他以批處理為導向的工作負載隔離，並且你不必擔心手工隔離可能會佔用叢集資源的長期執行作業。你只需要為不同的用例派生新的叢集作為計算。Databricks 還將儲存與計算解耦，使你能夠利用現有的雲端儲存，如 AWS S3、Azure Blob Storage 和 Azure Data Lake Store（ADLS）。
Databricks 也有一個預設的管理型 Hive 元儲存，用於儲存駐留在雲端儲存中的資料資產的結構化資訊。同時，它也支援外部元儲存，比如 AWS Glue、Azure SQL Server 或 Azure Purview。你還可以在 Databricks 內指定安全控制，如表 ACL，以及物件儲存許可權。
當涉及到資料訪問時，Databricks 提供了類似於 Hadoop 的功能，它可以處理使用者如何處理資料。你可以通過 Databricks 環境中多種路徑訪問儲存在雲端儲存的資料。使用 SQL Endpoints 和 Databricks SQL，使用者可以進行互動式查詢和分析。
第二步：資料遷移
在 Hadoop 的背景下，我認為大部分讀者已經對 HDFS 很熟悉。HDFS 是儲存檔案系統，用於 Hadoop 部署，它利用了 Hadoop 叢集節點上的磁碟。所以，當你擴充套件 HDFS 時，你需要增加整個叢集的容量（也就是說，你需要同時擴充套件計算和儲存）。若要購買和安裝額外的軟體，可能要花費很多時間和精力。
在雲中，你擁有幾乎無限的儲存容量，比如 AWS S3、Azure 資料湖儲存或 Blob 儲存或谷歌儲存等形式的雲端儲存。無需維護或健康檢查，從部署開始，它就提供了內建的冗餘和高水平的永續性和可用性。我們建議使用原生雲服務來遷移你的資料，為了方便遷移，有幾個合作伙伴/ISVs。
那麼，你該如何開始呢？最常見的推薦路線是從雙攝取策略開始（也就是，在你的內部環境之外，新增一個源來上傳資料到雲端儲存）。這樣你就可以在不影響你現有設定的情況下開始使用雲中的新用例（利用新資料）。如果你在組織中尋求其他團隊的支援，你可以將其作為一項備份策略。因為 HDFS 的龐大規模和相關的工作，傳統上對備份提出了挑戰，所以把資料備份到雲端是一種有效的舉措。
在大多數情況下，你可以利用現有的資料交付工具來複刻（fork）Feed，不僅寫到 Hadoop，也寫到雲端儲存。舉例來說，如果你正在使用 Informatica 和 Talend 這樣的工具/框架處理資料並向 Hadoop 寫入資料，那麼可以輕鬆地新增一些附加步驟，以便將資料寫入雲端儲存。一旦資料在雲中，就有許多辦法來處理資料。
就資料方向而言，資料要麼從內部拉取到雲端，要麼從內部推送到雲端。可用於將資料推送到雲端的工具有云原生解決方案（Azure Data Box、AWS Snow Family 等）、DistCP（一種 Hadoop 工具）、其他第三方工具以及任何內部框架。推送選項通常更容易得到安全團隊的必要批准。
對於將資料拉取到雲端，你可以使用 Spark/Kafka Streaming 或 Batch 從雲端觸發攝取管道。對於批處理，你可以直接攝取檔案，或者通過 JDBC 聯結器連線到相關的上游技術平臺，並提取資料。當然，還有一些第三方工具可以實現這一目的。在這兩個選項中，推送選項是一個被廣泛接受和理解的選擇，因此，讓我們來深入研究一下拉取方法。
你首先要做的是在你的企業內部環境與雲端之間建立連線。可通過網際網路連線和閘道器來實現。你還可以使用 AWS Direct Connect、Azure ExpressRoute 等專用連線選項。有些情況下，如果你的組織對雲端計算並不陌生，那麼這些設定已經就緒，因此你可以為你的 Hadoop 遷移專案重新使用它。
要考慮的另一個問題是 Hadoop 環境中的安全性。若為 Kerberized 環境，則可以從 Databricks 方面進行調整。你可以配置 Databricks 初始化指令碼在叢集啟動時執行，安裝並配置必要的 kerberos 客戶端，訪問儲存在雲端儲存位置的 krb5.conf 和 keytab 檔案，並最終執行 kinit() 函式，從而允許 Databricks 叢集與你的 Hadoop 環境直接互動。
最後，你還需要一個外部共享的元儲存。儘管 Databricks 的確有一個預設部署的元儲存服務，但是它也支援一個外部的。Hadoop 和 Databricks 將共享外部元儲存，並可以部署到企業內（在 Hadoop 環境中）或雲中。舉例來說，如果你在 Hadoop 中執行已有 ETL 流程，但你無法將它們遷移到 Databricks，則可以利用此設定和現有的企業內部元儲存，讓 Databricks 使用 Hadoop 的最終規劃資料集。
第三步：資料處理
首先要記住的是，從資料處理的角度來看，Databricks 的一切都在利用 Apache Spark。所有的 Hadoop 程式語言，如 MapReduce、Pig、Hive QL 和 Java，都可以轉換為在 Spark 上執行，無論是通過 Pyspark、Scala、Spark SQL 甚至 R。在程式碼和 IDE 方面，Apache Zeppelin 和 Jupyter 筆記本都可以轉換為 Databricks 筆記本，但是匯入 Jupyter 筆記本要簡單一些。匯入之前，Zeppelin 筆記本需要轉換為 Jupyter 或 Ipython。如果你的資料科學團隊希望繼續使用 Zeppelin 或 Jupyter 進行編碼，則可以使用 Databricks Connect，這樣你能夠在 Databricks 上執行本地 IDE（Jupyter、Zeppelin 甚至 IntelliJ、VScode、RStudio 等）來執行程式碼。
當涉及到遷移 Apache Spark™ 作業時，需要考慮的主要問題是 Spark 版本。你的內部 Hadoop 叢集可能執行的是較老版本的 Spark，你可以使用 Spark 遷移指南確定所做的更改，以檢視對程式碼的影響。要考慮的另一個方面是將 RDD 轉換為資料框（DataFrame）。RDD 通常用於 Spark 的 2.x 版本，儘管它們仍可用於 Spark 3.x，但是這樣做會妨礙你充分利用 Spark 優化器的功能。我們建議你將 RDD 轉換為資料框。
最後但並非最不重要的是，在遷移過程中，我們和客戶一起遇到的一個常見問題就是本地 Hadoop 環境的硬編碼引用。當然，這些都需要更新，否則程式碼將在新的設定中出現中斷。
接下來，讓我們看看轉換非 Spark 工作負載的問題，在大多數情況下，這涉及重寫程式碼。對 MapReduce 來說，在某些情況下，如果你以 Java 庫的形式使用共享邏輯，那麼這些程式碼就可以被 Spark 利用。然而，你可能仍然需要重寫程式碼的某些部分，以便在 Spark 環境中執行，而不是 MapReduce。Sqoop 的遷移相對容易一些，因為在新的環境中，你使用 JDBC 源執行一組 Spark 命令（相對於 MapReduce 命令）。如同在 Sqoop 中指定引數一樣，你可以在 Spark 程式碼中指定引數。在 Flume 中，我們看到的大部分用例都是圍繞著從 Kafka 消耗資料並寫入 HDFS。使用 Spark 流媒體可以很容易地完成這個任務。在 Spark 中遷移 Flume 的主要任務是將一個基於配置檔案的方法轉換成 Spark 中更多的程式化方法。最後，我們有 Nifi，它主要用於 Hadoop 之外，主要用作拖放、自我服務的攝取工具。Nifi 也可以用於雲，但是我們看到很多客戶正在利用遷移到雲中的機會，用雲中的其他較新的工具取代 Nifi。
遷移 HiveQL 可能是最簡單的任務。Hive 和 Spark SQL 之間具有高度相容性，並且大多數查詢都可以在 Spark SQL 上正常執行。在 HiveQL 和 Spark SQL 之間，DDL 有一些微小的變化，例如 Spark SQL 使用 “USING”子句，HiveQL 使用 “FORMAT” 子句。我們建議對程式碼進行修改，使其使用 Spark SQL 格式，因為它允許優化器為你的程式碼在 Databricks 中準備最佳的執行計劃。你仍可以利用 Hive Serdes 和 UDF 的優勢，使你在將 HiveQL 遷移到 Databricks 時更加容易。
對於工作流編排，你必須考慮可能改變提交作業的方式。你可以繼續利用 Spark 提交語義，但是還有其他更快、更無縫整合的選擇。你可以使用 Databricks 作業和 Delta Live Tables 進行無程式碼 ETL，以取代 Oozie 作業，並在 Databricks 內定義端到端的資料管道。為了實現自動化/排程，對於涉及外部處理依賴的工作流，你必須在 Apache Airflow、Azure Data Factory 等技術中建立相應的工作流/管道。利用 Databricks 的 REST API，可以使用 Databricks 整合並配置所有的排程平臺。
還有一種叫做 MLens 的自動化工具（由 KnowledgeLens 建立），它可以幫助你將工作負載從 Hadoop 遷移到 Databricks。MLens 可以幫助遷移 PySpark 程式碼和 HiveQL，包括把一些 Hive 細節轉換成 Spark SQL，這樣你就可以充分利用 Spark SQL 優化器的功能和效能優勢。它們還計劃很快支援 Oozie 工作流向 Airflow、Azure Data Factory 等等的遷移。
第四步：安全及管治
讓我們來看看安全和管治。在 Hadoop 世界中，我們有用來連線到諸如 Ambari 或 Cloudera Manager 這樣的管理控制檯的 LDAP 整合，甚至 Impala 或 Solr。Hadoop 還擁有 Kerberos 認證其他服務。在授權方面，Ranger 和 Sentry 是使用最多的工具。
有了 Databricks，單一登入（Single Sign On，SSO）可以整合到任何支援 SAML 2.0 的身份提供器。其中包括 Azure Active Directory、Google Workspace SSO、AWS SSO 和 Microsoft Active Directory。為了進行授權，Databricks 向 Databricks 物件提供 ACL（訪問控制列表），允許你設定筆記本、作業、叢集等實體的許可權。有了資料許可權和訪問控制，你可以定義表的 ACL 和檢視，以限制列和行的訪問，並利用類似的憑據傳遞等方式，Databricks 將你的工作空間登入憑據傳遞到儲存層（S3、ADLS、Blob 儲存），以確定你是否獲得訪問資料的授權。如果你需要基於屬性的控制或資料遮蔽等功能，你可以利用 Immuta 和 Privacera 等合作伙伴工具。從企業管治的角度來看，你可以將 Databricks 連線到企業資料目錄，如 AWS Glue、Informatica Data Catalog、Alation 和 Collibra。
第五步：SQL 和 BI 層
在 Hadoop 中，正如前面所討論的，你有 Hive 和 Impala 作為介面來執行 ETL 以及特別的查詢和分析。在 Databricks 中，你通過 Databricks SQL 實現類似的功能。Databricks SQL 還通過 Delta 引擎提供了極高的效能，並支援自動擴充套件叢集的高併發使用案例。Delta 引擎也包括了 Photon，這是一種用 C++ 重構的新的 MPP 引擎，並向量化以利用資料級和指令級並行性。
Databricks 提供了與 Tableau、PowerBI、Qlik 和 looker 等 BI 工具的原生整合，以及高度優化的 JDBC/ODBC 聯結器，這些工具可以使用。新型 JDBC/ODBC 驅動程式的開銷非常小（¼秒），使用 Apache Arrow 的傳輸率提高了 50%，以及一些元資料操作，可以顯著加快元資料的檢索操作。Databricks 也支援 PowerBI 的 SSO，對其他 BI/儀表盤工具的 SSO 支援也即將推出。
Databricks 除了上述的筆記本體驗外，還具有內建的 SQL 使用者體驗，為 SQL 使用者提供了 SQL 工作臺的鏡頭，還提供了輕量指示板和警報功能。這樣就可以對資料湖內的資料進行基於 SQL 的資料轉換和探索性分析，而無需將其轉移到下游的資料倉庫或其他平臺。