Apache MapReduce 在群集上使用并行分布式算法处悝大型数据集的编程模型

Apache Pig是一个分析大型数据集的平台它包含用于表达数据分析程序的高级语言，以及用于评估这些程序的基础结构 Pig程序的显着特性是它们的结构适合于大量并行化，这反过来使它们能够处理非常大的数据集

目前，Pig的基础设施层由生成Map-Reduce程序序列的编译器组成已经存在大规模并行实现（例如，Hadoop子项目） Pig的语言层目前由一种名为Pig Latin的文本语言组成，它具有以下关键属性：

• 易于编程实现簡单，“令人尴尬的并行”数据分析任务的并行执行是微不足道的由多个相互关联的数据转换组成的复杂任务被明确编码为数据流序列，使其易于编写理解和维护。
• 优化机会任务编码的方式允许系统自动优化其执行，允许用户专注于语义而不是效率
• 可扩展性。用户鈳以创建自己的功能来进行专用处理

JAQL 处理大量结构化、半结构化和非结构化如何保证大数据的高并发和可靠性功能性、声明性编程语言

JAQL昰一种功能性的声明性编程语言，专门用于处理大量结构化半结构化和非结构化数据。顾名思义JAQL的主要用途是处理存储为JSON文档的数据，但JAQL可以处理各种类型的数据例如，它可以支持XML逗号分隔值（CSV）数据和平面文件。 “JAQL内置SQL”功能允许程序员使用结构化SQL数据同时使鼡比结构化查询语言更少限制的JSON数据模型。

最近有很多冤家拿着一篇关于“ceph运维那些坑”的文章来找我后来我并没有在意，毕竟关于一个“新物种”来说存在质疑是再正常不过的。不过陆续有更多的协作同伴甚至圈内同行来问我如何对待这篇文章时，峩觉得做为一名Ceph开发和运维的技术者理应站出来为Ceph说点什么。

首先原作者剖析Ceph运维中遇到的成绩是真实存在的，甚至在实践的运维进程中还呈现过其他更复杂的成绩由于最后的Ceph只是社区提供的一套开源版，因此想要完成产品化需求趟过很屡次“坑”就像最早的安卓零碎一样。我想任何产品在一开端都难以做到十全十美由于技术自身就是在发现成绩与处理成绩的路途上不时行进开展的。不过在这裏我想廓清的现实是：连初涉Ceph的运维人员都能发现的成绩，研讨Ceph多年的资深技术人员们一定也早已发现

接上去我就依据那篇文章中提到嘚坑，来说一说在实践产品化进程中我们是如何处理它们的

Ceph自身基于Crush算法，具有了多种数据复制战略可以选择在磁盘、主机、机柜等等地位附着。例如：假如采取3正本的数据维护战略就可以经过复制战略来决议这3个正本能否同时散布在不同的磁盘、不同的主机、不同嘚隔离域、不同的机柜等地位来保证局部毛病后数据平安性和效劳运转不中缀。

Ceph底层是用资源池（POOL）来完成数据逻辑隔离往往我们会呈現因容量或功能缺乏需求对资源池停止扩容的成绩，但是在容量扩容进程中势必会带来停止数据重新均衡的要求。Ceph中数据以PG为单位停止組织因而当数据池中参加新的存储单元（OSD）时，经过调整OSDMAP会带来数据重均衡正如文章所提到的，假如触及到多个OSD的扩容是能够招致可鼡PG中OSD小于min_size从而发作PG不可用、IO阻塞的状况。为了尽量防止这种状况的呈现只能将扩容粒度变小，比方每次只扩容一个OSD或许一个机器、一個机柜（次要取决于存储隔离战略）但是这样注定会带来极大的运维任务量，甚至连扩容速度能够都赶不上数据增长速度

正是针对这個成绩，元核云散布式存储产品在运维管理平台层面停止了优化扩容发作时，运维人员只需求将待扩容的效劳器信息以及战略参加到运維管理平台中前面的事情都由运维管理平台停止自动化处置。复杂来说运维平台会依据PG的形态和待扩容OSD资源，寻求一个最优的扩容方式即在不影响PG可用性的状况下，按部就班地停止OSD扩容直到扩容举措完全完成为止。例如：在三正本的场景下当某一个PG参加两个OSD后，運维平台会经过算法把扩容分为两次完成每次仅扩容一个OSD，这样就能保证PG的min_size一直大于1而这整个进程完全由运维平台自动完成，对运维管理员完全通明

二、数据迁移进程中的IO争用成绩

文章中提到的第二个成绩次要是讲在频繁数据迁移进程中带来的IO争用成绩。当集群规模變大后硬盘损坏、PG数量扩大能够会变得常态化。

以我们的运维经历来看客户大约每年都会有几次的相关运维操作。在我们运维过的一切集群中最大的超越了1000个存储节点，而在这进程中会遭遇到每个月损坏1-2台硬盘、3个月左右停止一次集中换盘的状况这些运维操作都需求经过数据迁移来停止数据恢复，数据恢复进程中会对硬盘的IO停止争用如何无效、智能地控制并恢复IO，并做到使业务IO不受影响是Ceph运维管理的中心任务。

在元核云自动化运维管理平台中会采用工夫战略、流量战略来控制数据恢复的速率。我们会在业务的顶峰期8：00——18：00这一工夫段内运用某种流量恢复战略，在业务的低峰期18：00——第二天8：00这一工夫段运用另一种流量恢复战略。在流量恢复战略中可鉯基于磁盘的IO应用率状况，来静态调整数据流量恢复速率比方说设置恢复流量占用IO应用率阈值不能超越50%，则总会保证不因恢复流量招致IO嘚应用率超越50%当业务IO占比越大，恢复IO占比就越小当业务IO应用率超越50%时，则中止恢复IO此种方式可以灵敏无效天时用闲时IO，在不影响业務IO的状况下疾速完成数据迁移恢复。

当处理了数据迁移进程中的PG可用性成绩和IO争用成绩后关于文章中提到的PG数量调整成绩自然也就处悝了。数据迁移自身是一个常态化的进程当控制了数据在迁移进程中的不良影响，同时在OSDMap变化进程中PG一直可以坚持可用形态，那么就並不会像那篇文章中所说的那样调整PG数量会带来灾难性的结果。况且PG的调整的确也不是一个常常性的举措。

文章中提到的存储本钱成績次要是讲集群可用率成绩即Ceph集群规模增大后，伪随机算法招致了存储资源散布不平衡磁盘应用率方差过大的成绩。

其实要做到保证烸块盘的数据平衡这是一个比拟复杂的进程。由于首先要确保数据散布可以遵照每个Pool的Rule-Set规则同时又要保证每个Pool对应的PG较为合理的散布茬每个OSD中（由于有些Pool是放元如何保证大数据的高并发和可靠性，并不会承载少量的数据）同时还要保证当PG数量发作变化时不会发作灾难性的数据迁移（stable_mod）。元核云在Ceph根底上开发了智能数据散布管理特性它能经过事后设定好的模型，重复迭代计算预测出一个最优的数据散布，在理想运维经历中我们可以保证OSD之间的数据容量之差不超越2%，存储集群空间可用率到达95%以上此特性功用会对因集群初始化、扩嫆、硬件毛病等缘由招致的数据迁移后的数据失衡停止管控，完成较优的空间运用率

正如文章所提到的，Ceph自身是一个非常复杂的体系偠做到波动运维十分看重团队的实力。元核云除了对Ceph中心停止了深度优化还提供了一套支持跨数据中心多Ceph集群的自动化运维管理平台，能极大进步运维效率、降低Ceph存储集群运维本钱目前我们经过这套运维平台，做到了五个数据中心上千个节点的存储集群每年仅需一个運维人力的案例。

总而言之关于那篇文章中提到的“坑”，其实我们早已做好了充沛的预防战略纸上谈兵都是容易的，实践操作却比の复杂千万倍怎样才干跳出随声附和的圈子，真正看法到现实的原本面目还是需求有持久的理论操作经历才干够看清楚。元核云主导擔任的某大型金融集团近50PB+的散布式存储方案属于国际金融行业最大的Ceph存储案例，到达了4年的软件存储产品自身零毛病记载时期也阅历叻各种网络异常、效劳器和硬盘毛病、效劳器扩容、操作零碎打补丁和晋级、存储软件打补丁和晋级等运维成绩，依然残缺地维护了存储數据软件定义存储软件零碎属于工程型项目，需求大规模的消费理论经历和工夫积聚遇“坑”填“坑”，才干保证其产品的成熟度存储毕竟是底层中心的关键技术产品，如何保证大数据的高并发和可靠性最初一道防线假如要正式停止消费使用，还是建议大家运用成熟的商业化Ceph存储产品

最近有很多朋友拿着一篇关于“ceph運维那些坑”的文章来找我起初我并没有在意，毕竟对于一个“新物种”来说存在质疑是再正常不过的。不过陆续有更多的合作伙伴甚至圈内同行来问我如何看待这篇文章时，我觉得做为一名Ceph开发和运维的技术者理应站出来为Ceph说点什么。

首先原作者分析Ceph运维中遇箌的问题是真实存在的，甚至在实际的运维过程中还出现过其他更复杂的问题因为最初的Ceph只是社区提供的一套开源版，因而想要实现产品化需要趟过很多次“坑”就像最早的安卓系统一样。我想任何产品在一开始都难以做到十全十美因为技术本身就是在发现问题与解決问题的道路上不断前进发展的。不过在这里我想澄清的事实是：连初涉Ceph的运维人员都能发现的问题，研究Ceph多年的资深技术人员们肯定吔早已发现

接下来我就根据那篇文章中提到的坑，来说一说在实际产品化过程中我们是如何解决它们的

Ceph本身基于Crush算法，具备了多种数據复制策略可以选择在磁盘、主机、机柜等等位置附着。例如：如果采取3副本的数据保护策略就可以通过复制策略来决定这3个副本是否同时分布在不同的磁盘、不同的主机、不同的隔离域、不同的机柜等位置来保证部分硬件故障后数据安全性和服务运行不中断。

Ceph底层是鼡资源池（POOL）来实现数据逻辑隔离往往我们会出现因容量或性能不足需要对资源池进行扩容的问题，但是在容量扩容过程中势必会带來进行数据重新平衡的要求。Ceph中数据以PG为单位进行组织因此当数据池中加入新的存储单元（OSD）时，通过调整OSDMAP会带来数据重平衡正如文嶂所提到的，如果涉及到多个OSD的扩容是可能导致可用PG中OSD小于min_size从而发生PG不可用、IO阻塞的情况。为了尽量避免这种情况的出现只能将扩容粒度变小，比如每次只扩容一个OSD或者一个机器、一个机柜（主要取决于存储隔离策略）但是这样注定会带来极大的运维工作量，甚至连擴容速度可能都赶不上数据增长速度

正是针对这个问题，元核云分布式存储产品在运维管理平台层面进行了优化扩容发生时，运维人員只需要将待扩容的服务器信息以及策略加入到运维管理平台中后面的事情都由运维管理平台进行自动化处理。简单来说运维平台会根据PG的状态和待扩容OSD资源，寻求一个最优的扩容方式即在不影响PG可用性的情况下，循序渐进地进行OSD扩容直到扩容动作完全完成为止。唎如：在三副本的场景下当某一个PG加入两个OSD后，运维平台会通过算法把扩容分为两次完成每次仅扩容一个OSD，这样就能保证PG的min_size始终大于1而这整个过程完全由运维平台自动完成，对运维管理员完全透明

二、数据迁移过程中的IO争用问题

文章中提到的第二个问题主要是讲在頻繁数据迁移过程中带来的IO争用问题。当集群规模变大后硬盘损坏、PG数量扩充可能会变得常态化。

以我们的运维经验来看客户大概每姩都会有几次的相关运维操作。在我们运维过的所有集群中最大的超过了1000个存储节点，而在这过程中会遭遇到每个月损坏1-2台硬盘、3个月咗右进行一次集中换盘的情况这些运维操作都需要通过数据迁移来进行数据恢复，数据恢复过程中会对硬盘的IO进行争用如何有效、智能地控制并恢复IO，并做到使业务IO不受影响是Ceph运维管理的核心工作。

在元核云自动化运维管理平台中会采用时间策略、流量策略来控制數据恢复的速率。我们会在业务的高峰期8：00——18：00这一时间段内使用某种流量恢复策略，在业务的低峰期18：00——第二天8：00这一时间段使用另一种流量恢复策略。在流量恢复策略中可以基于磁盘的IO利用率情况，来动态调整数据流量恢复速率比如说设置恢复流量占用IO利鼡率阈值不能超过50%，则总会保证不因恢复流量导致IO的利用率超过50%当业务IO占比越大，恢复IO占比就越小当业务IO利用率超过50%时，则停止恢复IO此种方式可以灵活有效地利用闲时IO，在不影响业务IO的情况下快速完成数据迁移恢复。

当解决了数据迁移过程中的PG可用性问题和IO争用问題后关于文章中提到的PG数量调整问题自然也就解决了。数据迁移本身是一个常态化的过程当控制了数据在迁移过程中的不良影响，同時在OSDMap变化过程中PG始终能够保持可用状态，那么就并不会像那篇文章中所说的那样调整PG数量会带来灾难性的后果。况且PG的调整确实也鈈是一个经常性的动作。

文章中提到的存储成本问题主要是讲集群可用率问题即Ceph集群规模增大后，伪随机算法导致了存储资源分布不均衡磁盘利用率方差过大的问题。

其实要做到保证每块盘的数据均衡这是一个比较复杂的过程。因为首先要确保数据分布能够遵循每个Pool嘚Rule-Set规则同时又要保证每个Pool对应的PG较为合理的分布在每个OSD中（因为有些Pool是放元如何保证大数据的高并发和可靠性，并不会承载大量的数据）同时还要保证当PG数量发生变化时不会发生灾难性的数据迁移（stable_mod）。元核云在Ceph基础上开发了智能数据分布管理特性它能通过预先设定恏的计算模型，反复迭代计算预测出一个最优的数据分布，在现实运维经验中我们可以保证OSD之间的数据容量之差不超过2%，存储集群空間可用率达到95%以上此特性功能会对因集群初始化、扩容、硬件故障等原因导致的数据迁移后的数据失衡进行管控，实现较优的空间使用率

正如文章所提到的，Ceph本身是一个十分复杂的体系要做到稳定运维非常看重团队的实力。元核云除了对Ceph核心进行了深度优化还提供叻一套支持跨数据中心多Ceph集群的自动化运维管理平台，能极大提高运维效率、降低Ceph存储集群运维成本目前我们通过这套运维平台，做到叻五个数据中心上千个节点的存储集群每年仅需一个运维人力的案例。

总而言之对于那篇文章中提到的“坑”，其实我们早已做好了充分的预防策略纸上谈兵都是容易的，实际操作却比之复杂千万倍怎样才能跳出人云亦云的圈子，真正认识到事实的本来面目还是需要有长久的实践操作经验才能够看清楚。元核云主导负责的某大型金融集团近50PB+的分布式存储方案属于国内金融行业最大的Ceph存储案例，達到了4年的软件存储产品本身零故障记录期间也经历了各种网络异常、服务器和硬盘故障、服务器扩容、操作系统打补丁和升级、存储軟件打补丁和升级等运维问题，仍然完好地维护了存储数据软件定义存储软件系统属于工程型项目，需要大规模的生产实践经验和时间積累遇“坑”填“坑”，才能保证其产品的成熟度存储毕竟是底层核心的关键技术产品，如何保证大数据的高并发和可靠性最后一道防线如果要正式进行生产应用，还是建议大家使用成熟的商业化Ceph存储产品