服务热线

0750-33113349
网站导航
主营产品:
技术文章
当前位置:主页 > 技术文章 >

稳定和性能如何兼顾?58大数据平台的技术演进与实践

时间:2021-04-09 00:32 点击次数:
 本文摘要:作者|赵健博编辑|尚剑·本文将与您分享58个数据平台在过去一年半内技术发展的过程,包括:58个数据平台目前的总体结构。在过去的一年半里,我们面临的问题、挑战和技术发展过程;以及未来的计划。前面写的赵健博,来自58集,本文分享58大数据的经验。 本科和研究生分别在北京邮电大学和中国科学院计算技术研究所,以前在百度和360工作,现在是58名高级架构师、58名数据平台负责人。

亚博网站信誉有保障的

作者|赵健博编辑|尚剑·本文将与您分享58个数据平台在过去一年半内技术发展的过程,包括:58个数据平台目前的总体结构。在过去的一年半里,我们面临的问题、挑战和技术发展过程;以及未来的计划。前面写的赵健博,来自58集,本文分享58大数据的经验。

本科和研究生分别在北京邮电大学和中国科学院计算技术研究所,以前在百度和360工作,现在是58名高级架构师、58名数据平台负责人。多年分布式系统(存储、计算)的实践和研究开发经验,在工作多年中运营大小集团,仅次于单集团也超过4、5千台,在此过程中实现了大量的功能开发、系统优化,流出了大量的漏洞,本文不能说明最重要的经验。首先,让我们看看58个数据平台的结构。

大方面分为数据基础平台层、数据应用于平台层、数据应用层,还有两列监视和警报和平台管理。数据基础平台层分为4个子层:终端层,包括Canal/Sqoop(主要解决问题数据库数据终端问题)、大量数据使用Flume解决方案的存储层、典型的系统HDFS(文件存储)、HBase(KV存储)、Kafka(信息存储)的北上通常是调度层,在这个层面上使用Yarn的统一调度和Kubernernetes基于容器的管理和调度的技术,包括典型的计算层,包括Sarnern的统一调度等。

数据应用于平台主要包括以下功能。此外,还包括计算发动机、计算发动机job的作业管理,以及交互分析、多维分析、数据可视化的功能。北上是58集团的数据业务,如流量统计数据、用户不道德分析、用户图像、搜索、广告等。

业务、数据、服务、硬件需要完善的检测和警报系统。在平台管理方面,流程、权限、配额、升级、版本、机器需要全面的管理平台。这是目前58大数据平台的总体框架图。

本图展示了框架图中包含的系统数据流动。分为两部分:首先是动态流,是黄箭标志的这条路线。数据动态收集后,首先不转入Kafka平台,可以实现内存。动态计算引擎,如Sparkstreaming或storm,将想计算的数据从Kafka中加入。

动态处理后,结果可能会写下返回Kafka或构成最后一个数据存储在MySQL或HBase,并获得业务系统。这是一条动态路径。

关于离线路径,通过终端层的收集和收集,数据最终不会落入HDFS,通过Spark、MR批量计算发动机处理和机械学习发动机处理。其中大部分数据进入数据仓库,数据仓库的部分通过数据提取、清除、过滤器、同构、分割总结、最后单体建模等几个部分的处理,构成数据仓库的数据。然后,通过HIVE、Kylin、SparkSQL等模块,将数据获取到各业务系统和我们内部的数据产品中,有些不会流向MySQL。

以上就是数据在大数据平台上的流量情况。除了数据流之外,还有一个管理平台。元信息管理(云窗)、作业管理平台(58dp)、权限审查和流程自动化管理平台。

我们的规模可能比较大,和BAT相比有点小,但是过了一千台,现在有1200台机器。我们的数据规模目前为27PB,每日增量为50TB。

作业规模每天约为80000个job,核心job(产生公司核心指标的job)为20000个,每天处理80000个job的数据量为2.5PB。技术平台技术进化与建设,重点说明最近一年半我们大数据平台的技术进化过程,分为稳定性、平台管理、性能、异构计算四个部分。

第一部分关于稳定性的改良,稳定性是最基本的工作,我们做了很多工作。第二部分是平台管理的内容。第三方面,我们也优化了性能。

第四,我们对于机械的异构、作业的异构等异构环境,在这样的环境下如何合理地用于资源。稳定性的改良,首先要看稳定性的改良。这个我推荐几个例子来说明。稳定性包括几个方面,第一个方面是系统的可用性,可以使用社区获得的HDFSHA、YarnHA、StormHA来解决问题。

另一方面,关于Flume、HDFS、Yarn、Storm的扩展性。在此主要说明Flume和HDFS的扩展性。另外,如果有可用性和扩展性,系统会稳定吗?实质上并非如此。

因为还有很多脑溢血问题。即使解决了问题的可用性和可扩展性,脑溢血的问题也有可能无法使用系统。

例如,由于某些问题,两台NameNode全部停机。首先,让我们看看Flume的可扩展性。

我们人为地定义了两层。一个是FlumeLocal(主要解决问题的机器日志收集问题,全称Local),另一个是FlumeCenter(主要从Local收集数据,将数据写在HDFS上,全称Center),Local和Center之间有HA的想法,Local必须在配置文件中登录两个Center,一个Center经常出现问题,数据就会从另一个Center流向HDFS。另外,我们开发了低可靠的Agent。业务系统将数据生产日志写在磁盘上,Agent保证数据从磁盘上动态可靠地收集到当地的Local中,使用检查点的技术解决问题数据的可靠性问题。

这是Flume的典型架构。Local必须在配置文件中登录杀戮连接哪个Center。如果说10台的话,OK,100台也有可能OK。如果是千台呢?如果发现两台FlumeCenter已经超过机械资源的下限,如何实现紧急辅助?因此,从这个看Flume的扩展性有问题。

我们解决问题的方法是在Local和Center之间特别是Zookeeper,Local通过ZK动态找到Center,动态找到下游有什么,可以超过Center自动组合的目标。本公司Local有2000台以上,组合Center只需1分钟。这个结构实质上可以反对超过万台的规模。

这是Flume扩展性的改良。接下来,让我们看看HDFS的可扩展性。上图显示了hdfsfederation的结构,左侧为单个namespace结构,即目录整体的根在namespace中,集团整体的文件数量受到单个内存的允许。

federation的思想是合并目录的根部,构成不同的namespace,不同的namespace由不同的namenode管理,超过单一资源的允许,超过可扩展的目标,如右侧图。但是,这个方案有隐藏的问题。例如,这里的每个Datanode都和所有的NameNode跳跃,Datanode的数量达到数万台,第一,从主节点之间的跳跃、块报告成为瓶颈,第二,如果单个部门的数据规模太大,该怎么办呢?对于主节点之间的交互问题,我们可以开展合并,控制NameNode管理的DateNode数量,防止主节点交互支出过大的问题。

如果单个部门的数据太大,可以进一步粗略地分解部门内的数据。或者可以考虑到百度以前获得的方案,抽象目录的根和inode信息,分层管理和存储。当然,我们现在正在使用社区federation的方案。如果你只想计划,你也可以去万台。

在自己的运营集团过程中是否遇到过问题,如何解决问题,有些问题可能很麻烦。脑溢血问题非常紧急,最重要,必须在短时间内处理。接下来分享三个例子。第一个例子是HDFS的ActiveNN不定期解散异常,启动时HA转换,就像不定期炸弹一样。

该图显示了HDFS的HA结构图,如果客户更改操作者(例如创建文件),则不会向namenode请求。namenode催促处理结束后,不会进行长期工作,也不会在当地磁盘上留下一个,也不会在共享存储的同时,共享存储是为了active和standby之间的实时状态,standby不会周期从共享存储中提取的改版数据应用于自己的存储和目录树根中,所有的Datanode都是双重报告,因此两个namende最近的信息都会出现。

最上面是两个Checker,是为了仲裁谁是Active。另一个过程是,StandbyNameNode不定期执行checkpoint工作,checkpoint完成后,最近的fsimage不会发送给active,最后留在active的磁盘上,配置文件时,发送过程中不会引起大量的网络和磁盘压力,active当地磁盘的Util超过100%磁盘Util100%的持续时间长的话,用户不会催促超时,Checher的检查催促也会因为排队过长而超时,最后开始的时候Checker仲裁HA转换。在转换过程中,设计中最重要的是不能同时有两个Active,所以要成为新的ActiveNameNode,必须暂停原ActiveNameNode。

亚博APP

首先友好关系暂停,什么是友好关系?放置RPC,顺利就是友好关系,结束后ssh就不会过去,原本active丢弃了namenode的kill,这就是activenamenode异常放弃的原因。理解这个原因后,解决问题也很简单。第一,分离editlog和fsimage保留的当地目录并配备。这种分离是磁盘的分离,是物理的分离。

二是checkpoint后fsimage传输速度。分离editlog和fsimage两个磁盘,fsimage输送的io压力会影响客户的催促,另外,输送速度后也可以允许io压力。这是一个更棘手的问题。

原因看起来很简单,但从现象中寻找原因并不容易。第二个案例也是一样的,ActiveNN出现异常解散,发生了HA转换。这次与网络连接数有关,这张图是Active的NameNode所在机器的网络连接数,平时很长,从20000到30000之间,突然碰到60000以上,平手,最后下降,下降的原因显着,服务过程放弃了。

为什么这种情况不经常发生?在以前的分析过程中,我们在NameNode日志上发现了空指针的异常。顺藤摸瓜发现了JDK1.7的错误,看了上面的照片右图,在javaselect库函数调整路径的过程中,最后不调整该函数(setUpdateevents),如果fd的个数达到MAX_UPDATE_ARRAY_SIZE(65535)的话,就不会跑到else路径。

该路径在if展开平均表现式识别时,无法到达空指针。接下来的问题是,为什么不产生这么多链接?经过分析,在问题频繁发生的情况下,大目录的DU操作者不存在,DU不会锁定整个namespace,以前的写作催促被堵塞,最后催促被清洗,催促的清洗大量清洗连接数,连接数在一定程度上被清洗解决这个问题,从两个方面来看,首先将JDK升级到1.8。其次,调整参数dfs.content-summary.limit,允许du操作者持锁时间。

该参数配置文件参数为0。我们现在重建了10000,请参考。

这是第二个非常棘手的问题。第三个案例关于YARN的主节点,有一天中午,我们接到通报,发现ActiveRM发生异常过程解散,开始时HA的转换,但转换后,新的ActiveRM节点也没有异常解散,这是悲剧之后,我们从当时的日志中找到了原因。

:一个用户将1万份文件写入分布式存储器,分布式存储器的数据不会实时存储在ZK上,当RM长期工作状态达到ZK时,Znode的单节点仅次于下限,发生异常,最后ResourceManager进程异常解散。只是,解决问题的方法也非常简单,我们减少了允许逻辑,序列化数据量小于Znode节点大小的Job,需要在异常启动时抛出Job的结束。此外,还需要提高Znode节点的大小。以上是稳定性方面的工作,这三个案例与大家共享,如果有类似的问题,请试试。

这些方案是我们检查的OK。平台管理,接下来说明平台管理。

包括一些问题,第一个问题是关于数据。另一方面,大家开发数据后,经常去找附近,在小组里喊什么数据,谁能告诉我,这个效率很低。另一方面,以前的管理数据是共享的,不安全,谁都可以采访别人的数据。

第二个问题是关于资源,以前是大锅饭模式,大家共享计算资源,竞争,不吃的承认不吃,核心任务不能按时完成,上司看数据很可怕。另外,集体资源整体用于情况没有感觉,明显不告诉资源如何分配,是否充分。第三个问题就是关于作业的问题,开发商在开发了大量的作业之后,这些作业怎么管理,实质上他们可能不会告诉你。另外,关于作业之间的依赖,经常用一个指标计算经历多项作业,作业之间的依赖是怎样考虑的,完全靠时间的依赖是非常弱的,如果前期的job延迟的话,以前的job一定会结束。

最后一个问题是,数据开发商的效率不低,需要做的步骤太多。我们对这四个问题做了一些改进,首先是数据和资源管理。

数据应引进安全战略、元信息管理和基础仓库建设。我们自己开发了安全控制战略,主要减少了白名单和权限控制战略。

HDFS的催促过程,首先客户不会向NameNode催促,NameNode收到催促后,首先要进行连接分析,读书放入催促相关内容进行催促处理,然后将结果返回系统,然后客户向适当的DataNode从上述流程可以看出,所有HDFS操作者都必须通过NameNode这一层。安全战略在NameNode的两的两个方面进行控制接分析后,不检查催促者的IP和用户是否合法配置。检验结束后,拒绝请求。

如果检测合格,我们在催促处理过程中不会进一步检测用户访谈的目录和用户是否合法配置。例如,如果用户a想采访用户b的数据,在允许的情况下不启动连接,通过非常简单的战略调整可以超过灵活的数据安全控制和数据共享的方式。其次,对于数据寻找附近的问题,我们开发了全公司水平的基础数据仓库和只有公司水平的数据管理平台。

该图显示了基础数据仓库的复盖度,复盖了集团各公司,复盖了手机、App终端、PC终端、微信终端等多个平台。数据水平是数据仓库水平、数据市场水平还是数据应用水平,属于哪个事业群,最后对数据展开分类标签,例如投稿数据、用户数据等可以用标签寻找。想明确数据的时候,通过这个界面,点击标签,检查数据表,在检索框中检索数据的关键词。检测数据表时,右侧按钮显示表格结构、表格信息、表格信息指出该表格有多少佩,该表格的负责人是什么,数据质量、表格数据量的变化等,如果申请人想开通页面最右侧的权限。

整个开通过程也是自动化的。这是对数据寻找近似问题的一些改进。

为了防止资源问题中的大锅饭,必须引进账户的概念,资源必须根据账户腾出和隔绝。我们区分了不同的额度,根据开支、业务市场的需要去申请人的额度,调整额度。对于队列,我们区分多个队列,每个业务线都有自己的队列,不同的业务线不能跨越队列提交任务,每个队列区分不同的资源,资源主要取决于业务线市场的需求。

通过这些改进,可以超过资源的隔绝和有用的共享。有了账户的概念,我们可以统计数据的各业务线资源用于情况。我们每天都有报表。

业务线的计算和存储资源的使用表明了Job的细节。接下来,我将解释业务线研发效率下降的改进。事实上,我们在易用性方面也做了很多改进。首先,我们开发了云窗平台,主要解决了元信息查询、数据搜索、但化展示和多维分析这些市场需求。

然后,我们开发了58DP,解决了元信息开发、作业管理和统计数据等问题。我们对动态多维分析开发飞行,动态作业开发全部配置化,同时反对多种统计数据算子、自动图表分解等。还有NightFury,流程自动化管理平台。

这是云窗界面,上面是SQL搜索界面,下面是可视化产品界面,这是我们数据可视化的结果。然后,关于任务的开发,我们用58DP开发任务,可以反对的任务包括现在的主流作业和作业依赖等管理。这是一个58DP的页面,可以设置基本信息、调度、依赖等。飞流是反对周期性的统计资料、全天总计性的统计资料,可以定义统计资料的方法、定义任务的基本信息,设定维度、设定度,设定结束后显示图形,与昨天的比较状况也得到了。

在图中点击任何一点时,可以看到不同维度的人在这一点上的数据分布,页面的两点可以看到不同维度下两点的产生比较。比较历史数据,我们可以延长时间,不是一天,而是调查不同周围的动态统计数据结果。这是NightFury的界面,这是我们运输的自动化管理平台,可以看到很多流程和权限的开通申请人,表格的填写、工作单的审查、审查后的流程都是自动化的。性能主要分为四个方面:小米MR操作性能、数据收集性能、SQL搜索性能和多维分析性能。

针对MR作业性能,提到多租户功能,资源腾出,核心作业继续实行。第二,小文件的分割处理可以提高任务的持续执行效率,增加调度本身的支出。

第三,我们可以优化Shuffle阶段的参数,提高发行度,减少IO消耗。经过三个方面的改进,我们整个任务的运行时间实质上翻了一番。

在数据传输优化方面,我们通过信息分割改善了数据传输性能,提高了20倍。在SQL优化方面,我们提到内存继续实施引擎和列存储方案的融合,在同等资源的情况下,对在线100多个SQL进行测试,整体性能提高约80%。

通过多维计算,引进Kylin,多维搜索的95%以上可以控制在2s以内。异构计算在异构计算方面面面临着两个主要问题。

一个是作业的异构,我们有很多类型的作业。例如,动态作业特别强调低延迟,离线作业特别强调低突然,这本身是对立的,如何解决问题是对立的。第二,机械异构,CPU、内存、网络、磁盘配置不同,这种异构环境该怎么办?从上图可以看出,如果动态操作的task和批量操作的task被安排在一台机器上,如果批量操作充满资源(如网络带宽),动态操作的task将受到影响。

因此,必须隔绝动态作业和批量处理作业。实现资源的隔绝,我们的想法是使用标签化,向每个NodeManager表现不同的标签,不同的机器分配不同的标签的资源队列也表现出不同的标签,在RM调整时,确保完全相同标签的队列容器资源不能从完全相同标签的NodeManager分配。这样,标签可以通过不同的物理资源隔绝目标。

这张图是构图。首先,NodeManager分为两个子集,一个是动态的,另一个是离线的,不同的队列也表现出动态或离线的标签,用户提交job时可以登录队列,提交离线队列是离线任务,ResourceManager不会将该作业所需的资源分配给离线标签的NodeManager未来的计划主要说明了我们最近一年半做的工作。接下来,我将解释未来的计划。首先,深入自学。

这个概念今年非常疯狂,即使爆炸,深度自学在58个市场的需求也令酋长国反感。现在深度自学工具这么多,caffe、theano、torch等非常多,如何整合,如何降低成本是第一个问题。第二个问题,机器是有限的,如何有效利用资源,必须将机器分配模式转变为资源分配模式。

另外,单机的机器学习和深度自学工具太差,性能太差,必须分布深度自学训练。我们进行了可行性测试,比较了caffe和Tensorflow工具的分布式训练,4卡比单卡模型的训练性能提高了100%~170%,因此分布式简化的工作本身意义也非常大。

该图展示的是工具融合方案。我们这里利用的是Kubernetes,反对主流的深度自学工具,每个工具制作镜像组成POD,用户需要的话就需要把POD分发给他,用户在训练时需要从HDFS中采样,把训练的参数写在HDFS上,也就是HDFS另外,我们不能进行深度自学工具分布式的改建。

对于caffe,我们使用CaffeOnSpark,也就是说,将分布式的整个方案制作成模板供用户使用。首先启动多个POD,通过POD启动Spark集团,然后提到Sparkjob进行训练,最后在整个训练结束后停止集团。

Tensorflow也一样,首先开始tensorflow集团,提交任务,任务训练结束后停止集团。其他工具分布式化也不采用类似的构想解决问题。

以上是我们目前深入自学的一些工作。其次,关于空间资源利用率。现在我们有一千多台机器,存储成本相当高。

我们属于花钱的部门,压力很大。如何节约成本是最重要的问题。

除了传统传输,还能做什么?HDFSRAID是一个更好的解决方案。HDFSRAID使用RC代码,类似于RAID6。例如,文件有m块,根据m块分解k块,确保k块丢失的情况下,数据可以回收。

例如,文件的2.5G大小、256M块可以分为10个,根据RC算法可以分解4个检查,确保扔掉4个。在这个例子中,3个复印件一共需要30个,使用HDFSRAID只需要14个。但是,他们的可靠性相同,空间的闲置状况下降了57%。

具体实施时,第一步是对集群数据进行冷却分析,但RAID是一些性能问题,如果数据有问题,必须计算完全恢复,性能必然会下降,因此同意冷冻数据的风险低于。第二步是传输archiveRAID,通过三方面的技术融合节省文件数量和空间。文件本质上不转换目录。

亚博APP买球

为了兼容,我们通过硬连接功能使用户半透明。最后,在加载数据时,如果是RAID数据,则必须具备动态RAID修理功能,以免在数据缺陷的情况下影响数据采访。

以前,我们不会进一步提高计算资源利用率。此外,Storm和YARN的可扩展性也没有考虑。

Kubernetes调度优化,如GPU资源管理功能。以上是我今天想说明的内容。结束前请允许我总结。首先,我说明了58现在的大数据平台结构是什么样的。

非常简单的是342,三个层次,细分为四个子层,旁边两列。因此,要实现大数据平台的建设,这些方面是必不可少的。

第二方面,我重点说明了58年半内技术改良。第一,关于稳定性,主要从Flume和HDFS的扩展性方面重点说明了我们的解决方案,推荐了3个案例来说明脑溢血问题,不是说有可用性和扩展性就一切都OK,而是要解决脑溢血问题。关于平台管理,首先说明了数据和资源的管理方法,然后说明了易用性的改良。取得一系列平台提高开发人员的研发效率。

第三,从性能上说明了我们在这里进行的最佳化工作和最佳化的结果是怎样的,第四,在异构环境下如何反对不同特征的作业展开合理的计划。最后,我解释了58深度自学平台建设和资源空间利用率优化的内容。以上是我今天的所有内容,希望对大家有所帮助。

今天的动态推荐微软公司的开源软件列表,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,还是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册,是命中注册。


本文关键词:稳定,和,性能,如何,兼顾,大,数据,平台,的,亚博APP

本文来源:亚博网站信誉有保障的-www.doksh.com

Copyright © 2009-2021 www.doksh.com. 亚博网站信誉有保障的科技 版权所有  备案号:ICP备74724720号-6

地址:湖南省岳阳市朔城区建明大楼92号 电话:0750-33113349 邮箱:admin@doksh.com

关注我们

服务热线

0750-33113349

扫一扫,关注我们