【数据湖专题2】云原生给对象存储和数据湖带来的变化

【数据湖专题2】云原生给对象存储和数据湖带来的变化

云原生不是单项技术，而是构建和运行应用程序的设计思想，是一套技术体系和方法论。云原生英文是“Cloud Native”，它是组合词表示“Cloud + Native”，其中Cloud 是云平台，Native表示应用程序从设计之初即使用云环境、天生为云而设计，充分利用和发挥云平台的弹性+分布式优势。

对象存储作为最早的云服务，已广泛支持各种云业务，现在又进入到数据湖领域，在云原生的新趋势下也会迎来新的变化。

一、云原生介绍

1.1 云原生定义

随着技术发展，云原生定义也在不断演进，如下是云原生计算基金会 (CNCF，Cloud Native Computing Foundation)目前的云原生定义：

根据此描述，前一句描述云原生的应用场景和目标，后一句介绍云原生会使用到的相关技术。

1.2云原生技术

根据图（A）所示的云原生技术，它可以广泛部署到公共云、私有云、混合云等云环境，通过CI/CD持续集成实现敏捷应用开发。

采用容器的轻量化运行环境降低资源开销、优化成本，基于服务网格（例如Istio）来管控应用的各模块、实现灵活调度，通过微服务架构理念将应用切分多个模块化服务，基于分而治之的方法让多团队快速迭代开发。

不可变基础设施，则是通过容器镜像（Docker Images）来交付软件，将软件和运行环境打包发布，减少环境适配的复杂度；而提供软件包，再到客户环境部署、调试、运行的方案，则需要考虑各种兼容情况，非常复杂。某些场景下，基于镜像的部署时间只有基于软件包部署时间的1/10，极大优化软件交付。

​

1.3云原生对存储的需求

容器的安全性。不管是CI/CD，还是容器、微服务，通常都运行在虚拟网络（VPC）环境中，如何实现VPC容器下的安全数据访问是基础要求。微服务的隔离性。基于服务网格、微服务架构，应用需要划分为众多的子服务，降低子服务间的干扰、实现子服务间的数据访问隔离至关重要。弹性扩展能力。微服务架构中的子服务模块会引入突发流量，例如10,000+的容器并发访问数据将会带来访问洪峰。而不可变基础设施的容器镜像批量启动风暴，也会带来集中的瞬时流量，因此需要存储提供弹性扩展能力。高可用、高可靠。微服务架构会产生大量的子服务，它们都需要高可用、高可靠的底层存储，从而实现企业级应用要求的5个9可用性。单位存储密度的性能，可预期的带宽、时延、OPS。容器化的细粒度运行环境，在公共云上实现了秒级计费能力，比弹性计算服务器的小时级更精细。所以，存储提供单位密度的带宽规格（每TB的Gbps带宽能力）、稳定的请求时延和OPS（99.99%的请求在指定时间T内完成），可以有效的帮助微服务评估使用存储的时长，从而可以按需释放容器，获得最合适的性价比。

二、对象存储如何支持云原生

2.1 对象存储符合云原生定义

对象存储作为数据存放的平台，天然支持构建和运行可弹性扩展的应用。而且容器、服务网格、微服务在设计开发的早期就使用对象存储来存放数据，容器镜像数据存放的常用技术也是对象存储。

2.2 云原生给对象存储带来的挑战

对象存储应用到云原生，是典型的存算分离架构；同时对象存储作为数据底座，它的高可靠、高可用以及弹性扩展能力，已在云上得到广泛认可。

安全性、隔离性、单位密度的性能，却是云原生给对象存储的新挑战，需要集中解决。

2.3对象存储该做些什么

针对VPC环境的容器访问对象存储安全加强

实现VPC运行环境和对象存储桶的安全访问绑定能力。限定在VPC内只能访问指定的对象存储桶，避免内鬼从企业VPC将企业的对象存储数据拷贝到个人的对象数据桶，这需要对象存储提供VPC Endpoint功能；也需要限定对象存储桶只能被指定的VPC访问能力，避免外部黑客盗取密钥后导致数据泄漏，需要对象存储提供Bucket Policy功能。微服务的PoD级访问对象存储桶的灵活权限。类似云计算服务器绑定访问存储的Access Token，需要为PoD绑定访问存储的Access Token，通过Token的临时性，避免Access Key这样的长期密钥被盗取，从而带来影响巨大的安全风险。

面向微服务的隔离性

访问隔离。应用的不同子服务，可以使用同一个数据存储桶，但需要为每个子服务提供不同的访问域名，并绑定不同的访问策略，控制访问路径、权限，实现访问隔离，需要对象存储提供Access Point功能。流控隔离。为应用的子服务，提供用户级、子用户级、对象存储桶级的流量控制能力，限制子服务能使用的带宽，避免应用被异常流量冲垮。

提供单位存储密度性能的规格

通过不同存储类型，提供差异化的单位存储密度性能。例如高性能存储类型，为每TB容量提供不容带宽能力，带宽性能规格越强价格越高。从而应用能够根据性能需求，选择不同的存储类型。保证稳定可预期的时延和OPS。存储的数据访问时延存在波动，即使大部分是低时延，少量的长尾高时延，也会让云原生应用的运行时长不可预期，只能按照最坏的长尾高时延设计。所以，对象存储的各种存储类型都应该提供稳定的时延和QPS，而不是一味追求极致低时延。热点数据性能加速。容器批量启动风暴和并行计算框架，都会带来大量热点数据的重复读。提供靠近容器可用区（AZ）部署的对象存储热点数据加速器，可以提高容器加载速度和快速完成并行计算任务。

三、如何做好云原生下的数据湖

3.1 数据湖支撑云原生计算的接口适配

随着云原生理念被广泛接受，大量数据分析计算引擎都在基于云原生架构构建。而基于对象存储的数据湖，要支持丰富的计算引擎，包括存量的历史引擎（如Hadoop生态）、以及新的引擎（如Spark、Iceberg、Hudi、Delta Lake等）。数据湖要支持额这些引擎，就必须要适配数据访问接口，特别是历史的Hadoop生态访问的HDFS接口。

3.2 数据湖支撑云原生计算的功能满足

同时，随着云原生架构的应用拓展到更多的领域，会有越来越多的新需求，需要数据湖提供新的功能来满足，例如提供流式访问能力。

四、总结和思考

通过上述分析，云原生给对象存储、数据湖带来诸多变化，如图（B）所示。除了更强的高可靠性、高可用、弹性扩展需求外，还需要在安全性、隔离性、支持计算引擎的接口和功能上提供更强的功能。为了更好的利用云原生容器的细粒度运行环境，还需要单位存储密度的性能，实现可预期的带宽、时延和OPS，以及性能加速能力，从而让微服务的数据访问时长可建模计算，使得应用可以精确申请和释放容器，达到成本优化。除了这些变化外，还需要关注如下的点：

可观测的运维。由于云原生采用微服务架构，应用通常有多个微服务组成，它简化了部署难度，但随着数据链路增加，也增大了排查问题、分析性能、度量系统的运维难度。因此云原生需要架构相关模块提供可观测的运维，对象存储作为数据存储也需要提供可观测运维的Log/Metric/Trace能力，被云原生应用集成。可编排和调度的資源。众所周知，云原生通过编排和调度实现应用的灵活部署和管理，对象存储需要提供编排和调度的接口，并整合到云原生平台中，从而让存储資源按需快速可用。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。