从 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，用户能够进行交互式查问和剖析。大数据培训他们也能够应用 Databricks 笔记本对存储在云存储中的数据进行数据工程和机器学习性能。Hadoop 中的 HBase 映射到 Azure CosmosDB，或 AWS DynamoDB/Keyspaces，能够作为上游利用的服务层加以利用。
第二步：数据迁徙
在 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 的数据转换和探索性剖析，而无需将其转移到上游的数据仓库或其余平台。