如何实现CDH到云原生大数据平台的快速平滑迁移？-Toy模板网

这篇具有很好参考价值的文章主要介绍了如何实现CDH到云原生大数据平台的快速平滑迁移？。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

在大数据发展的初期，以Hadoop为中心的大数据生态技术框架，是能基本满足企业和机构建设大数据平台的需要的。

当时，以Cloudera为代表的Hadoop发行商，所提供的Hadoop发行版，以降低企业使用Hadoop难度，其中代表产品Cloudera Data Hub（简称CDH）。所以，从那时起，基于CDH运行的大数据平台不在少数。

如何实现CDH到云原生大数据平台的快速平滑迁移？,云原生,大数据

传统大数据平台困难重重，CDH落伍了？

随着时代的发展，大数据技术使用逐步地深入，大数据开发需求变得越来越旺盛，企业对多租户环境下大数据开发的效率、大数据集群资源利用率、新的计算存储引擎、人工智能和机器学习技术的集成速度提出了越来越高的要求，而传统大数据平台在面对这些需求时则显得有点束手无策，出现了无法依靠自身的发展来克服这些困难的困境。我们仔细分析一下，就可以看到传统大数据平台的技术架构决定了依靠它本身的发展是无法克服这些困难的：

困难一：传统大数据平台难以实现资源的隔离。多租户环境下的数据开发效率提升，需要以资源隔离的方式来保证租户之间的计算作业互相不影响，特别是不能出现某一个或几个租户独占集群资源的情况。但Hadoop系统本身的出发点就不是为了多租户环境而设计的，其目前的资源隔离实现也不完善。在最近的Hadoop版本中，在一定程度上实现了内存资源和文件资源的隔离，但是不够完整，而磁盘I/O和网络I/O的隔离还在社区讨论的过程中，短期内看不到解决的希望。
困难二：传统大数据平台难以集成新的计算和存储技术。Hadoop系统在部署其他组件的时候，对这些组件与HDFS和Yarn的版本适配是有严格要求的。很多新的大数据组件是不适配老版本的Hadoop的，而升级Hadoop又会造成其他组件的失效。另外，部署新的组件还要考虑到Linux不同操作系统的兼容性所带来的额外复杂度。所以引入一个新的计算和存储组件的难度是非常高的，往往需要几天甚至是几周的时间。
困难三：Hadoop存算合一的紧耦合架构决定了它的资源利用率无法提高。在一个Hadoop集群中，一个节点既是存储节点（data node），也是计算节点。当存储资源不够的时候，增加节点可以进行存储扩容，但会造成计算资源的利用率下降；同样，当计算资源不够而进行扩容的时候，存储资源利用率就会下降。同时，因为对于Yarn的依赖，不使用Yarn调度的其它组件很难集成到Hadoop的计算框架中。所以Hadoop的这种耦合架构决定了它的资源利用率不高。
困难四：Hadoop集群资源无法做到快速的弹性扩容和缩容。弹性的扩容和缩容是提高集群资源利用率的有效方法。很遗憾，Hadoop的节点扩容和缩容流程，导致这个动作无法在很快的时间内完成，尤其是缩容过程，只有当一个data node的所有数据块都在其他节点完成了备份以后，该节点才能被移出集群，而由于数据备份是以较小的传输率运行在后台，往往要持续几个小时以上。

传统大数据平台因为其结构性的缺陷导致了多租户环境下数据开发效率低、集群资源利用率不高、以及集成新技术很复杂等问题，依靠Hadoop生态技术框架本身的发展解决这些问题是比较困难的。

总而言之，很多企业基于CDH的大数据平台已经运行很多年了，现在没办法很好地满足企业的业务需求。这也就不难理解，为什么CDH落伍了。

被困在CDH的客户，必须要迁移了

很多被困在CDH的客户，长期无法得到组件升级和技术更新，严重影响大数据平台的使用。所以，不少企业必须做出这样的决定，即将自己的大数据平台迁移至云原生大数据平台上。那么，如何能够快速且平滑地将CDH迁移到云原生大数据平台，又迁移到什么样的云原生大数据平台上呢？

如何实现CDH到云原生大数据平台的快速平滑迁移？,云原生,大数据

BDOS Kubernets Data Platform（以下简称：KDP）是智领云研发团队基于容器、K8s和大数据技术研发的大数据平台产品。这一产品的诞生，是要利用云原生的资源隔离、作业混排、存算分离、标准化部署运维等技术优势，解决传统大数据平台因本身技术局限性而无法解决的资源利用率低、部署运维复杂、难以弹性扩容等技术难题，帮助用户花更少时间、用更少的资源去进行大数据平台的部署、配置和运维，投入更多的时间和精力去进行大数据开发和分析，更高效、更稳定地从海量数据当中挖掘数据的价值并提升企业的数字化能力。

KDP支持主流的大数据计算和存储引擎，强化了这些大数据组件在生产环境下的安全性、稳定性和运行性能。同时，平台的大数据集成基座实现大数据组件的标准化部署和运维，统一了所有大数据组件与可观测性服务的适配，并且支持了在K8s调度机制之上的更精细化的作业调度机制。平台支持在公有云和私有云部署，支持社区版的K8s和主流的商业版K8s，适用于不同的企业环境。

以CDH为代表的传统大数据平台，迁移到KDP的案例实践

智领云云原生大数据平台KDP，能够帮助企业快速平滑的进行迁移，这也是企业选择我们的原因。

大数据组件及服务，与Kubernetes的版本适配

大数据组件（如Hadoop、Spark、Flink、Hive等）有自己的发布版本。不同的版本对 Kubernetes 的特定版本有不同的支持程度，或者需要一些调整才能适应新的 Kubernetes 版本。Kubernetes 是一个不断发展的开源项目，每个版本都会引入新的功能、改进和修复。因此，大数据组件需要与特定版本的 Kubernetes 保持兼容。大数据组件及服务，与Kuberentes的版本适配，需要考虑：

API兼容性：API大数据组件和服务通常需要与 Kubernetes API 进行交互，不同版本的 Kubernetes 可能会引入 API 的变更，因此，确保大数据组件能够与目标 Kubernetes 版本的 API 兼容。
网络策略：Kubernetes 的网络模型和策略因版本升级而发生变化。大数据组件通常需要特定的网络配置，包括服务发现、通信端口等。
Pod调度和亲和性：大数据工作负载对节点资源和亲和性有特殊要求，需要确保大数据组件能够在 Kubernetes 版本中正确调度和执行。
存储和持久卷：大数据组件通常需要持久化存储，而 Kubernetes 的持久卷机制会因不同版本而有变更，需要确保大数据组件对于存储的要求与目标 Kubernetes 版本的持久卷机制相兼容。
安全机制：Kubernetes 引入了许多安全机制，如 RBAC（Role-Based Access Control）、Pod 安全策略等，需要确保大数据组件的安全配置与目标 Kubernetes 版本的最佳实践相符。
资源管理：大数据工作负载对资源的需求往往较大，需要确保 Kubernetes 版本的资源管理机制与大数据组件的需求相匹配。
Kubelet版本：大数据组件依赖于运行在每个节点上的 Kubelet 进程，需要确保目标 Kubernetes 版本中的 Kubelet 版本与大数据组件的版本兼容。
调度器的变更：大数据组件需要特定的调度策略，而 Kubernetes 的调度器在版本之间会进行改进或调整，需要确保在大数据组件能够被正确调度。
监控和日志：大数据组件的监控和日志集成通常依赖于 Kubernetes 的相关功能，需要确保监控和日志系统的配置与目标 Kubernetes 版本兼容。
Operator 或 Helm Chart 的更新：如果使用 Operator 或 Helm Chart 管理大数据组件，需要确保这些工具版本可以支持目标 Kubernetes 版本。

KDP 产品能力之一是可以对接社区最新版本大数据组件

快速响应社区创新：KDP 能快速响应社区中新版本的大数据组件发布，具备足够的灵活性和可扩展性，能够在短时间内适配、集成并支持社区的创新。
支持多种大数据组件： KDP 支持多种不同类型的大数据组件，如分布式存储系统（如HDFS）、计算框架（如Spark、Flink）、数据处理引擎（如Hive、Kylin）等，能够满足用户多样化的大数据处理需求。
版本兼容性：与社区最新版本的大数据组件具有良好的版本兼容性，对组件的API、配置文件和数据格式有深入了解，确保在升级时不会引入不稳定性或不一致性。
自动化集成和测试：实施自动化的集成和测试流程，确保对接最新版本的大数据组件时不会引入严重的问题。包括构建自动化测试套件，模拟真实环境中的使用情景，并在对接前后执行全面的验证。
版本管理和回滚机制：实现版本管理和回滚机制，在对接新版本时，KDP 能够方便地切换回之前的版本，以应对意外情况或兼容性问题。

安全性和身份验证系统对接

IAM对接关键考虑因素

对接客户 IAM（身份和访问管理）系统是一个涉及到安全性和合规性的重要任务，需要考虑关键因素：

协议和标准：确保系统与客户 IAM 系统使用相同的身份验证和授权协议，如OAuth、SAML（Security Assertion Markup Language）、OpenID Connect等。
用户身份映射：确定客户 IAM 系统中的用户身份如何映射到系统中。涉及到用户标识符（如用户名、电子邮件地址）、用户组（Group）信息等。
单点登录（SSO）：如果客户 IAM 系统支持单点登录，考虑集成以提供无缝的用户体验。这样用户只需要一次登录，即可访问多个系统。
权限和角色映射：确定客户 IAM 系统中的权限和角色如何映射到系统中，包括访问资源的权限和可执行的操作。
安全传输：通过使用安全协议和加密手段，确保身份验证信息在传输过程中的安全性。
用户同步和 Provisioning：确保用户信息在客户 IAM 系统和你的系统之间的同步和 Provisioning 是关键的，涉及到用户的创建、更新、删除等操作的同步。
令牌管理：确保客户 IAM 系统生成的令牌可以被你的系统有效地验证，并在适当的时候进行刷新。
审计和监控：在对接过程中集成审计和监控机制，以便能够跟踪用户活动并检测任何异常行为。
合规性和法规：遵循适用的合规性标准和法规，确保身份验证和访问控制的实施符合相关要求。

IAM对接注意事项

确认用户规模，考虑是否支持用户增量变更查询，辅助评估可行性
同步原则上是单向，只会在IAM定义，修改
沟通确定权限变更之后的生效时间

KDP 在对接客户IAM系统的优势

通过 KDP 和客户IAM 系统对接，可以满足应用级别的访问控制、菜单级别的访问控制、创建KDP用户的同步。

统一身份管理：通过对接客户 IAM 系统，KDP 可以实现将目标用户进行同步，并可访问云原生大数据系统中的各个组件和服务。
权限精确控制：支持用户粒度的权限控制和菜单基本的访问控制，用户可以在自己的IAM系统中定义对 KDP 系统中的应用及功能菜单的权限控制，并通过配置权限访问和使用系统功能。
集中化访问控制：在整个云原生大数据系统中，可以通过系统进行一致性的权限管理，简化了权限配置和维护的复杂性。
单点登录（SSO）：用户只需在系统中进行一次身份验证，即可访问多个云原生大数据系统中的组件和服务，提高用户体验。
弹性适应多云环境：在多云环境中运行的 KDP 云原生大数据系统，对接客户 IAM 系统可以使得跨云的身份验证和授权更加灵活，适应多云战略。
安全性提升： KDP 云原生大数据系统可结合客户 IAM 系统先进的安全性功能，如多因素身份验证（MFA）等，提升整体安全性措施。

监控告警系统的对接

将CDH（Cloudera Distribution for Hadoop）大数据组件迁移到云原生大数据系统时，涉及监控和告警的对接需要考虑以下内容：

监控体系的兼容性：确保CDH中使用的监控体系和工具与目标云原生大数据系统兼容。不同的大数据组件可能使用不同的监控系统，而云原生环境可能有自己的监控和观测解决方案（如Prometheus、Grafana等）。
指标和日志的收集：确保CDH大数据组件的关键指标（Metrics）和日志能够被正确地收集和导入到目标云原生环境的监控系统中。
告警规则的转换：将CDH中的告警规则映射到云原生大数据系统的告警规则，需要重新配置告警阈值、触发条件等信息，以适应目标系统的告警体系。
权限和认证：确保在监控和告警的对接过程中考虑到权限和认证的问题，保障监控数据的安全性。

KDP在进行大数据组件的监控告警系统对接的优势

KDP 可提供大数据组件以及其执行的workload的日志，性能/稳定性的指标监控和报警，计费以及审计功能。除了提供接口和SDK方便大数据组件接入可观测性服务，KDP可观测性服务和通用PaaS平台最大的区别在于可以支持：批处理任务，二级调度任务，各种数据层面的指标。

全面的监控和报警功能： KDP 提供了全面的监控和报警功能，覆盖大数据组件的执行工作负载、日志、性能/稳定性指标等多个方面。用户能够全面了解系统运行状况，并在有异常情况时及时采取措施。
大数据组件日志记录： KDP 不仅提供了对大数据组件执行的工作负载的日志记录，还能够深入到大数据组件本身的日志，有助于用户在问题发生时快速定位和排查。
性能/稳定性指标监控：KDP可观测性服务提供了对大数据组件执行性能和稳定性的详细指标监控。用户可以实时了解任务的执行时间、资源利用率、数据处理速度等信息，有助于优化系统性能。
灵活的告警规则配置：用户可以根据自身需求配置灵活的告警规则。一旦触发告警条件，系统会及时通知用户，使得用户能够快速响应和处理问题。
计费功能集成： KDP 集成了计费功能，通过监控大数据组件的使用情况，为用户提供了精确的计费信息。有助于用户优化资源利用和控制成本。
审计功能：通过KDP可观测性服务，用户可以进行审计，记录大数据组件的执行历史、配置变更、访问控制等信息。这有助于确保系统的安全性和合规性。
支持批处理和二级调度任务：与通用PaaS平台相比，KDP可观测性服务专注于大数据领域，能够深度支持批处理任务和二级调度任务，用户能够更灵活地管理和监控各类任务。
数据层面指标监控： KDP可观测性服务提供了对数据层面的详细指标监控，包括吞吐量、延迟等，有助于用户全面了解数据处理过程的质量和效率。
接口和SDK支持：为方便大数据组件接入可观测性服务，KDP提供了友好的接口和SDK，使大数据组件能够轻松地集成到监控和告警系统中。

数据迁移

迁移CDH Hive数据到 KDP 系统时，需要考虑一系列因素，以确保顺利迁移并最大程度地保留数据完整性和性能。

版本兼容性：确保云原生大数据系统的组件和版本与CDH中使用的Hive版本兼容。有时候，不同版本之间可能存在语法差异或特性变化，需要仔细检查和调整。
数据格式和存储：验证CDH Hive中使用的数据格式（如Parquet、ORC等）是否与云原生大数据系统的Hive兼容。如果存在不同的数据格式，可能需要进行格式转换。
元数据迁移： Hive表的元数据包括表结构、分区信息等，确保将这些元数据迁移到云原生大数据系统的Hive元数据存储中。这可以通过使用元数据导出工具、Hive元数据复制工具等来实现。
存储位置和权限： CDH中的Hive表可能依赖于特定的HDFS路径和权限设置。在迁移过程中，确保目标云原生大数据系统中有相应的存储位置，并设置正确的访问权限。
UDFs和自定义函数：如果CDH Hive中使用了自定义的用户定义函数（UDFs）或其他自定义函数，确保这些函数在云原生大数据系统中也可用，或者进行相应的调整和迁移。
配置调整：云原生大数据系统和CDH的Hive可能有不同的配置参数和默认设置。审查和调整这些配置，以满足目标系统的性能和需求。
性能调优：迁移后，可能需要对表和查询进行性能调优。这可能包括重新分析表、优化数据分区、重新设计查询等步骤。
数据迁移策略：选择合适的数据迁移策略，可以是全量迁移，也可以是增量迁移。全量迁移适用于数据规模较小的情况，而增量迁移则适用于大规模数据的情况。

通过 KDP 迁移 CDH Hive 数据原生大数据系统的优势

可通过 KDP 创建一个与CDH上相同的Hive元数据库。通过执行Hive DDL语句或使用元数据库备份进行恢复来完成。
可灵活使用Hadoop DistCp工具，将Hive表的数据复制到新的KDP大数据平台。确保数据完整性和一致性。
快速实现从CDH HDFS到KDP的HDFS复制。

迁移 CDH Hive 数据原生大数据系统的注意事项

【1】Hive Reader：

使用 hivereader 作为读取插件。
指定源 Hive 的连接信息，包括用户名、密码、JDBC URL。
指定源表的名称、字段等信息。

【2】Hive Writer：

使用 hivewriter 作为写入插件。
指定目标 Hive 的连接信息，包括用户名、密码、JDBC URL。
指定目标表的名称。

【3】其他配置：

可以配置速度等其他任务级别的参数。

Sentry到Ranger数据迁移

Sentry和Ranger都是用于权限管理和访问控制的工具，它们通常与大数据平台（如Hadoop生态系统）一起使用。将Sentry的权限数据迁移到Ranger，需要执行以下步骤：

备份数据：在进行任何数据迁移之前，首先确保对Sentry的数据进行备份。这包括权限、角色、策略等信息。确保备份是完整的且可恢复。
理解Sentry和Ranger的模型差异：Sentry和Ranger有不同的权限模型和概念。在迁移之前，确保了解两者之间的差异，以便正确映射权限。
创建Ranger Repository：在Ranger中，首先需要配置一个Repository来存储权限信息。这可以是基于数据库的，如MySQL或PostgreSQL。根据你的需求选择并配置相应的Repository。
创建Ranger策略：在Ranger中，权限通过策略（policy）来管理。你需要为每个Sentry的权限创建相应的Ranger策略。确保正确映射用户、组、资源和权限。
编写脚本或工具进行数据迁移：编写脚本或使用工具来从Sentry的备份数据中提取信息，并将其转换为Ranger Repository和策略。这可能涉及到对权限和用户映射进行适当的转换。
测试迁移：在生产环境之前，先在一个测试环境中进行数据迁移。确保权限迁移正确，用户能够按预期访问资源。
执行迁移：一切准备就绪后，执行迁移过程，并确保在生产环境中保留备份。
验证和监控：验证Ranger中的权限和策略是否与Sentry中的一致。设置监控机制来追踪权限的使用和变更。

通过 KDP 将 Sentry 数据迁移到 Ranger 的优势

版本兼容性：KDP 会完成统一的版本适配，可确保目标版本支持CDH Sentry的数据迁移。
元数据迁移：KDP 可将Sentry中元数据准确地迁移到Ranger中，以确保权限设置的一致性。
角色和权限映射：在Sentry和Ranger之间存在不同的角色和权限模型，通过KDP可快速实现将Sentry中的角色和权限正确地映射到Ranger的对应概念上，并进行新的Ranger策略在大数据组件上的应用。
资源和策略映射：可通过 KDP 应用Ranger管理界面或API，创建新的资源，并进行快速验证与应用。

将Sentry数据迁移到Ranger的注意事项