首页天道酬勤dellemc待遇怎么样,vega 解析

dellemc待遇怎么样,vega 解析

张世龙 05-12 14:31 118次浏览

当今的大数据处理系统无论是什么架构都面临着共同的问题。 这意味着“计算是本机流计算,而存储不是本机流存储”。 Pravega团队重新考虑了这一基本数据处理和存储吉鲁,并为此场景重新设计了一种名为“Pravega”的本机流存储类型,它意味着梵语“Good Speed” 这篇文章是《分布式streamsstoragepravega系列文章》中的第二篇,第一篇评论了《为什么你需要开源分布式流存储 Pravega?》。

流行大数据存储存在的三大问题

图1是当前大数据处理平台中最常见的Lambda架构,具有满足实时处理和批处理需要的优点,但从存储的角度来看,其缺点也是显而易见的,如前一篇文章《实时流处理统一批处理的最后一块拼图:Pravega》所示

实时处理、批处理不统一,每个处理路径都采用不同的存储组件,增加了系统复杂性,增加了开发人员的学习成本和工作量。

数据存储是多组件化、多份数化的。 如下图所示,相同的数据存储在许多异构系统中,如Elastic Search、S3对象存储系统和Kafka。 另外,考虑到数据的可靠性,由于数据具有多个冗馀,因此用户的存储成本将大幅增加。 对于企业用户来说,0.1%的存储冗馀通常意味着丢失。

系统中存储的组件太多、太复杂,使用的运输成本也在增加。 此外,大部分现有的开源项目还处于“强运维”产品阶段,对企业用户来说是一笔巨大的支出。

图1. Lambda体系结构

在本文中,为了解决三个问题:降低开发成本、降低存储成本、降低运输成本,我们从主动ga体系结构的角度挖掘了流存储的具体需求,并通过体系结构设计解决了这三个问题

第四种存储类型:流存储

从存储的角度来说,在存储体系结构设计中,首先需要明确存储的特点。 每种类型的数据都有其自己的属性和常规访问模式,它们对应于最佳场景和最佳存储系统。

在物联网、金融等实时APP应用场景中,需要存储的数据一般称为“流数据”,流数据一般定义如下:

流数据是一系列连续、大量、高速、连续到达的数据,通常可以将数据流视为随时间无限增长的动态数据集合。

图2.4大存储类型

如上图所示,将流数据定义为第四种数据类型。 从左到右分布着四种最常见的存储类型,它们从传统的批处理数据依次转换为流数据。 基于事务的程序(如传统数据库)适用于块存储系统。 在文件共享场景中,分布式文件(NAS )存储系统非常适合,因为用户之间需要共享和读写文件。 需要无限扩展和支持REST接口读写的非结构化图像、音频和视频文件非常适合对象存储系统。

在流式数据存储区流式数据的APP应用程序场景中,必须满足以下要求:

低延迟:高同时条件下10ms的读写延迟。

只处理一次—确保在客户端、服务器或网络出现故障时,所有事件都将被处理并只处理一次。

保证顺序:可提供严格有序的数据访问模式

检查点:确保每个读取客户机/顶级APP应用程序都可以存储和恢复原始使用情况

从访问模式的角度看,Pravega需要统一传统的批处理数据和流数据,因此不仅需要实时到达数据的低延迟读取和写入,还需要满足对历史数据的高吞吐量读取

技术在某种程度上,一定是来自以往现有技术的新组合。 -- 《技术的本质》、hxsdsg

Pravega也不是凭空发明的,是以前成熟的技术和新技术的结合。 Pravega团队拥有基于日志存储的设计经验和Apache ZooKeeper/BookKeeper的项目历史记录。 此外,大量实时系统也同样希望采用日志存储方式完成实时APP应用的消息队列,满足这三种数据访问模式。

自然想到了使用仅附加 (Append only) 的日志作为存储原语。

 

 

图 3. 日志结构的三种数据访问机制

如图 3 所示:在 Pravega 里,日志是作为共享存储原语而存在的,数据以事件 (event) 的形式以仅附加的方式写入日志当中。

所有写入操作以及大部分读取操作都发生在日志的尾部 (tail read/write)。写操作将事件附加到日志中,而大量读客户端希望以到达日志的速度读取数据。这两种数据访问机制主要是需要低延迟。

对于历史数据的处理,读客户端不从日志的尾部读取,而是从日志中的任意位置开始读。这些读取称为追赶读 (catch-up read)。我们可以采用和尾部数据一样的高性能存储(例如 SSD)来存储历史数据,但这会非常昂贵并迫使用户通过删除历史数据来节省成本。这就需要 Pravega 架构提供一种机制,允许客户在日志的历史部分使用经济高效,高度可扩展的高吞吐量存储,这样他们就能够保留所有的历史数据,来完成对一个完整数据集的读取。

Pravega 逻辑架构

 

 

图 4. Pravega 架构

为了实现上述的三种访问模式的性能需求,Pravega 采用了如上图所示的分层存储架构。事件可以存储在低延迟 / 高 IOPS 的存储(第一层存储)和更高吞吐量的存储(第二层存储)中。通过这种方式,冷热数据分离有效降低了数据存储成本。上层使用 Apache ZooKeeper 作为分布式协调器,并提供统一的 Stream 抽象。

第一层存储用于快速持久地将数据写入 stream,并确保从 stream 的尾读尽可能快。第一层存储基于开源 Apache BookKeeper 项目。BookKeeper 是一种底层的日志服务,具有高扩展、强容错、低延迟等特性。许多 Apache 开源项目,例如 Apache Pulsar,Apache DistributedLog 都是基于这一项目实现。BookKeeper 对于复制、持久性、一致性、可用性、低延时的承诺也正是 Pravega 所需要的第一层存储的需求。为达到高性能的读写延迟需求,我们建议第一层存储通常在更快的 SSD 或甚至非易失性存储 (non-volatile RAM) 上实现。

第二层存储考虑到经济效益,选用高度可扩展,高吞吐量的云存储,目前 Pravega 支持 HDFS,NFS 和 S3 协议的二级存储,用户可以选用支持这些协议的大规模存储进行扩展。Pravega 提供了两种数据降层 (retention) 的模式,一种基于数据在 stream 中保留的时间,另一种基于数据在 stream 中存储的容量大小。Pravega 会异步将事件从第一层迁移到第二层,而读写客户端将不会感知到数据存储层级的变化,依然使用同样的 Stream 抽象操作数据的读写。

正是基于这样的分层模型,文章开头提到的三大问题被一次性解决。

对于开发者而言,只需要关心 Stream 抽象的读写客户端的操作。实时处理和批处理不再区分对数据访问方式。

数据仅在第一层存储有三份拷贝,在第二层存储则可以通过商业分布式 / 云存储自身拥有的高可用、分布式数据恢复机制(如 Erasure Coding)进一步降低存储系数,达到比公有云存储更便宜的总拥有成本 (TCO)。

所有的存储组件归结为统一的 Pravega,组件仅包括 Apache ZooKeeper,Apache BookKeeper 以及可托管的第二层存储,运维复杂程度大大降低。Pravega 还提供了额外的“零运维”自动弹性伸缩特性,进一步减轻了数据高峰期的运维压力。

Pravega 的基本概念

本章节将简要介绍一些 Pravega 的基本概念。

Stream:Pravega 存储的抽象,类似于 Kafka 的 topic,是一种可持久化、可伸缩、仅附加、字节大小无限制的序列,具有高性能和强一致性的特性。在同一个 scope 内 stream 具有命名唯一性,stream 由一个或多个 segment 组成。用户可以在创建 stream 时配置降层策略 (RetentionPolicy) 和伸缩策略 (ScalingPolicy)。

Scope:scope 是 stream 的命名空间,将 stream 进行分类和隔离。在多租户场景下,每一个租户拥有一个 scope。例如,具体应用、商业部门等可以划分 scope。

Segment:Pravega 最底层的存储单元,对应 BookKeeper 中的 ledger。stream 由 segment 组成,segment 是 stream 的分片,类似但不局限于 Kafka 的 partition。事件 (event) 存储在 segment 里。一个 stream 的 segment 的数量可以根据到达数据量和伸缩策略改变,同时也是该 stream 读取时的最大并行度。

事件(event):Pravega IO 操作的最小单位,类似于 Kafka 的 message。事件是 stream 中的可以表示为一组字节的任何事物。例如:来自温度传感器的读数,网站点击和日志数据等。

Stream,segment 和事件的关系如下图所示。

 

 

图 5 Stream, segment, event 关系示意图

xsdlb(Routing key):事件所拥有的属性,xsdlb会通过一致性散列算法(consistent hashing)将事件读写到对应的 segment,因此相同的xsdlb会将事件路由到相同的 segment,由相同的读客户端读取。xsdlb是 Pravega 许多读写语义特性的基础。

写客户端(Writer):写客户端是一个可以创建事件并将事件写入一个或多个 stream 中的应用,所有的事件数据都通过附加到 stream 的尾部来写入。

读客户端(Reader):读客户端是一个可以从一个或多个 stream 中读取事件的应用。Pravega 会以负载均衡方式分配 stream 中的 segment 给指定的 Reader。读客户端可以从 stream 中的任何一点读取,比如头部、尾部、中间任何一点。

读者组(Reader Group):读者组由读客户端组成,读者组本质上是为了实现同一个组内读客户端的并行化以及不同组的 stream 读取扇出,类似于 Kafka 的 Consumer Group。同一个读者组内的读客户端可以一起并行读取给定的一组 segment 内的事件。读者组由name字符串唯一标识。

Pravega 产品定位和与 kafka 的对比

前面我们已经提到过 Pravega 是从存储的视角来看待流数据,而 Kafka 本身的定位是消息系统而不是存储系统,它是从消息的视角来看待流数据。消息系统与存储系统的定位是不同的,简单来说,消息系统是消息的传输系统,关注的是数据传输与生产消费的过程。Pravega 的定位就是企业级的分布式流存储产品,除了满足流的属性之外,还需要满足数据存储的持久化、安全、可靠性、一致性、隔离等属性,关注数据的生产、传输、存放、访问等整个数据的生命周期。作为企业级的产品,一些额外的特性也有支持,例如:数据安全、多租户、自动扩缩容、状态同步器、事务支持等,部分特性将在后续文章详述。

这里我们把 Pravega 与 Kafka 做了对比,大体在功能上的差异如下表所示。功能上的差异也只是说明各个产品针对的业务场景不同,看待数据的视角不同,并不是说明这个产品不好,另外每个产品自身也在演进,因此本对比仅供参考。

 

 

总结

本文从商业痛点出发,分析了分布式流存储 Pravega 的需求,重点介绍了 Pravega 的关键架构以及关键特性,另外还与 Kafka 做了简要对比。有关 Pravega 的更多详细信息,请参阅官方网站以及关注我们的后续文章。

作者简介

zzdcg:就职于 DellEMC 非结构化数据存储部门 (Unstructured Data Storage) 团队并担任软件开发总监。2007 年加入 DellEMC 以后一直专注于分布式存储领域。参加并领导了中国研发团队参与两代 DellEMC 对象存储产品的研发工作并取得商业上成功。从 2017 年开始,兼任 Streaming 存储和实时计算系统的设计开发与领导工作。

hsdlz,现就职于 DellEMC,10 年 + 存储、分布式、云计算开发以及架构设计经验,现从事流存储和实时计算系统的设计与开发工作;

kydyt,复旦大学计算机专业研究生,从本科起就参与 DellEMC 分布式对象存储的实习工作。现参与 Flink 相关领域研发工作。

作者:zzdcg、hsdlz、kydyt

参考链接

https://www.pravega.io

2021分布式存储中国峰会,dealer