传统大数据平台交付运维成本高、资源利用低效、迭代兼容性及安全性问题等关键痛点。
传统大数据平台的建设和维护目前是一个重要且复杂的任务。这些平台通常包括多种不同的组件，它们在技术栈、功能和架构上存在显著差异。这种多样性不仅使得平台的部署和配置变得极为复杂，也大幅增加了整体的运维成本。 组件多样性导致较高的人力需求： 大数据平台包含多种组件，这些组件在技术栈（如Java、C++）、功能（如流处理、批处理，OLAP）和架构（如C/S、MPP）方面各不相同。部署，配置和维护如此多样的技术栈需要大量的专业人力，特别是在部署和交付新的大数据平台时，人力资源的需求和成本会显著增加。
运维专业性与效率： 大数据组件的复杂性，具有较高的运维知识门槛。这不仅增加了运维团队的工作负担，还可能导致效率低下和更频繁的解决问题需求，从而增加成本。 工具与管理挑战： 许多大数据组件缺乏开箱即用的日志、监控和告警功能，导致运维团队需要为每个组件单独开发和适配这些工具。
每个组件可能有各自的集群和管理界面，使得整个平台的统一管理和问题排查变得困难。这种分散性不仅降低了运维效率，还可能导致问题解决的延迟，增加了管理成本。云原生技术可以有效缓解传统大数据平台的运维挑战。容器化通过屏蔽不同组件间的技术栈和基础设施差异，简化了运维流程。工具如 Operator 实现了服务部署和运维的标准化与自动化，降低了复杂性和人力成本。在云原生架构下，应用和组件的更新仅需拉取新镜像并重启容器，确保环境一致性，加速应用发布。此外，云原生环境提供统一管理界面，集中处理不同服务的发布和运维，提高问题监测和定位的效率。集成在Kubernetes Pods 和节点的监控与告警工具，使得运维团队可以通过统一界面清晰监控基础设施和服务状态，有效跟踪系统性能和健康状况。
组件混部困难：传统的大数据平台，为了避免组件间的相互影响，组件的集群往往是相互独立部署的。这样虽然对于整体的编排来说相对简单，但是会降低资源利用率。 业务波动性：由于大数据业务的特点，大数据组件在高峰期的资源利用率可以很高，但是在业务低峰期则会有较多闲置，此时集群整体资源利用率可能只有 20%-30%，综合平均起来集群整体的资源利用率偏低。
弹性扩缩容难度高：在业务高峰期时，如果现有的资源已经无法支撑业务，这个时候可能需要通过较为繁琐的运维流程扩容节点。到了业务低谷期时，这部分机器又很难通过运维流程快速下线，扩缩容的效率不高。 云原生领域在基础资源基础上抽象出了“资源池（计算、存储、网络等的组合）”的概念，资源池被所有的大数据组件公用，按需申请，可以避免重复规划造成的资源浪费。资源池可以承载不同类型的大数据集群，可以是批处理、也可以是流处理、MPP 等，得益于容器化较好的隔离性，不同的业务可以在一起混部，形成资源的分时复用；同时云原生领域有着丰富的工具来对资源池进行弹性扩缩容，甚至当业务不存在的时候降到零副本，做到随需启停，做到Serverless化。
传统的大数据平台，组件开发迭代不敏捷，周期长。组件版本往往比较固定，版本升级难度比较大。在部署新的大数据组件到现有的Hadoop 集群时。首先，必须确保这些新组件与现有的HDFS和Yarn版本兼容。由于许多新的大数据组件不支持旧版本的Hadoop，升级Hadoop 可能导致现有组件失效。其次，部署时还需考虑到不同Linux操作系统间的兼容性问题，这增加了额外的复杂性。因此，整合一个新的计算和存储组件到现有架构中通常是一个耗时的过程，可能需要几天甚至几周的时间。
云原生的定义中先天具有 DevOps、CI/CD 的思想，可以比较容易地做到IaC(Infrastructure as Code)和CaaS(Configuration as a Service)。组件的配置或代码在 Git 中进行保管，一旦发生变化，就会经过CI 的环节进行质量验证，然后通过 CD 的管道打包成容器镜像发布到运行环境中。由于云原生中都是微服务架构，你可以只单独发布组件的一部分，不必整体组件一起发布；在组件的发布过程中，也可以更方便地实现 A/B Test、灰度发布、发布回滚等操作。同时云原生中都是容器，启停容器是轻量级动作，效率高。
传统大数据平台，在安全方面面临着一系列挑战。包括数据隔离、综合访问控制、数据加密和保护、审计与合规性、网络安全、灾难恢复与数据备份等。针对这些挑战，大数据开源社区已经有一些解决方案，如使用 Kerberos 进行认证、Ranger 或Sentry 进行访问控制等，但这些解决方案往往伴随着配置复杂、灵活性不足、自动化程度低等缺点。 相比之下，云原生技术社区也提供了面对安全问题更全面、灵活且自动化的安全解决方案。可以做到更好的网络隔离，数据隔离，权限隔离，灾备等。
