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

本文摘要：作者｜赵健博 编辑｜尚剑 本文将为你共享58大数据平台在最近一年半内技术演变的过程，还包括：58大数据平台目前的整体架构是怎么样的；最近一年半的时间内我们面对的问题、挑战以及技术演变过程；以及未来的规划。 写出在前面 赵健博，来自58赶集，本文将为大家共享58大数据这块的经验。 本科和研究生分别是在北京邮电大学和中国科学院计算技术研究所，之前在百度和360工作，现在是58赶集高级架构师、58大数据平台负责人。

作者｜赵健博 　　编辑｜尚剑 　　本文将为你共享58大数据平台在最近一年半内技术演变的过程，还包括：58大数据平台目前的整体架构是怎么样的；最近一年半的时间内我们面对的问题、挑战以及技术演变过程；以及未来的规划。　　写出在前面　　赵健博，来自58赶集，本文将为大家共享58大数据这块的经验。

本科和研究生分别是在北京邮电大学和中国科学院计算技术研究所，之前在百度和360工作，现在是58赶集高级架构师、58大数据平台负责人。多年的分布式系统（存储、计算出来）的实践中和研发经验，在工作的这些年中运营了大大小小的集群，仅次于单集群也超过了四五千台，在这个过程中做到了大量的功能研发、系统优化，也流下了大量的坑，本文不会给大家讲解一些自指出较为最重要的经验。　　首先看一下58大数据平台架构。

大的方面来说分成三层：数据基础平台层、数据应用于平台层、数据应用层，还有两列监控与报警和平台管理。　　数据基础平台层又分成四个子层：　　终端层，还包括了Canal/Sqoop（主要解决问题数据库数据终端问题）、还有大量的数据使用Flume解决方案；　　存储层，典型的系统HDFS（文件存储）、HBase（KV存储）、Kafka（消息内存）；　　往北上就是调度层，这个层次上我们使用了Yarn的统一调度以及Kubernetes的基于容器的管理和调度的技术；　　往北上是计算出来层，包括了典型的所有计算出来模型的计算出来引擎，包括了MR、HIVE、Storm、Spark、Kylin以及深度自学平台比如Caffe、Tensorflow等等。　　数据应用于平台主要还包括以下功能：　　元信息管理，还有针对所有计算出来引擎、计算出来引擎job的作业管理，之后就是交互分析、多维分析以及数据可视化的功能。

　　往北上是承托58集团的数据业务，比如说流量统计资料、用户不道德分析、用户画像、搜寻、广告等等。针对业务、数据、服务、硬件要有完善的检测与报警体系。　　平台管理方面，必须对流程、权限、配额、升级、版本、机器要有很全面的管理平台。

　　这个就是目前58大数据平台的整体架构图：　　这个图展出的是架构图中所包括的系统数据流动的情况。分成两个部分：　　首先是动态流，就是黄色箭头标识的这个路径。数据动态收集过来之后首先不会转入到Kafka平台，再行做到内存。

动态计算出来引擎比如Spark streaming或storm不会动态的从Kafka中放入它们想计算出来的数据。经过动态的处置之后结果可能会写出返回Kafka或者是构成最后的数据存到MySQL或者HBase，获取给业务系统，这是一个动态路径。

　　对于离线路径，通过终端层的收集和搜集，数据最后不会落在HDFS上，然后经过Spark、MR批量计算出来引擎处置甚至是机器学习引擎的处置。其中大部分的数据要进来数据仓库中，在数据仓库这部分是要经过数据提取、清除、过滤器、同构、拆分汇总，最后单体建模等等几部分的处置，构成数据仓库的数据。然后通过HIVE、Kylin、SparkSQL这种模块将数据获取给各个业务系统或者我们内部的数据产品，有一部分还不会流向MySQL。

以上是数据在大数据平台上的流动情况。　　在数据流之外还有一套管理平台。还包括元信息管理（云窗）、作业管理平台（58dp）、权限审核和流程自动化管理平台（NightFury）。

　　我们的规模有可能远比大，跟BAT比一起有些小，但是也过了一千台，目前有1200台的机器。我们的数据规模目前有27PB，每天增量有50TB。作业规模每天大约有80000个job，核心job（产生公司核心指标的job）有20000个，每天80000个job要处置数据量是2.5PB。　　技术平台技术演变与构建　　接下来我会重点讲解一下在最近一年半时间内我们大数据平台的技术演变过程，共分四个部分：稳定性、平台管理、性能以及异构计算。

第一个部分关于稳定性的改良，稳定性是最基础的工作，我们做到了较为多的工作。第二个部分是在平台管理方面的内容。第三个方面我们针对性能也做到了一些优化。第四个方面，我们针对异构环境，比如说机器的异构、作业的异构，在这种环境下怎么合理地用于资源。

　　稳定性改良　　首先看一下稳定性的改良。这块我会荐一些例子展开解释。稳定性包括了几个方面，其中第一个方面就是系统的可用性，大家可以使用社区获取的HDFS HA、Yarn HA，Storm HA来解决问题。另外一个方面是关于扩展性，例如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，如果一千台呢？如果找到两台Flume Center早已超过机器资源的下限，如何做到应急的配套呢？所以从这个看作Flume的扩展性是有问题的。　　我们的解决问题方法是在Local和Center中间特了一个ZooKeeper，Local通过ZK动态找到Center，动态的找到下游有什么，就可以超过Center自动配套的目标了。我们公司Local有两千多台，配套一台Center仅有须要一分钟，这种架构实质上可以反对超过万台规模的，这是Flume扩展性的一些改良。

　　接下来看一下HDFS扩展性的问题。上面这张图展出了hdfs federation的架构，左侧是一个单namespace架构，即整个目录树根在一个namespace中，整个集群的文件数规模受限制于单机内存的容许。federation的思想是把目录树根合并，构成有所不同的namespace，有所不同namespace由有所不同namenode管理，这样就超越了单机资源容许，从而超过了可拓展的目标，如右侧图。

　　但这个方案有一些隐蔽的问题，不告诉大家是不是注意到，比如这里每个Datanode都会与所有的NameNode去跳动，如果DataNode数量上万台，那么就可能会经常出现两个问题：第一，从主节点之间的跳动、块汇报沦为瓶颈，第二，如果单个部门的数据规模过大那该怎么办？　　针对从主节点之间交互的问题，我们可以展开合并，掌控一个NameNode管理的DateNode的数量，这样就可以防止主从节点交互支出过大的问题。针对单部门数据过大的话可以针对部门内数据展开更进一步粗拆卸，就OK了。或者可以考虑到百度之前获取的一个方案，即把目录树根和inode信息展开抽象化，然后分层管理和存储。

当然我们目前使用社区federation的方案。如果只想规划的话，也是可以到万台了。

　　不告诉大家是不是在自己运营集群过程中遇上过一些问题，你们是怎么解决问题的，有些问题有可能非常的棘手。脑溢血问题是十分应急而且最重要的，必须在短时间内搞定。

接下来我会共享三个例子。　　第一个例子是HDFS的Active NN不会定期出现异常解散，启动时HA转换，这就样子一个不定时炸弹一样。这个图展出了HDFS的HA的架构图，客户端展开更改操作者（如创立文件）的话不会发出请求给namenode，namenode催促处置完了之后不会展开长久化工作，不会在本地磁盘遗一份，同时不会在分享遗储存一份，分享存储是为了active和standby之间实时状态的，standby不会周期从分享存储中拉所取改版的数据应用于到自己的内存和目录树根当中，所有的DataNode都是双汇报的，这样两个namenode都会有近期的块信息。最上面的是两个Checker，是为了仲裁到底谁是Active的。

　　还有一个过程，Standby NameNode不会定期做到checkpoint工作，然后在checkpoint做完之后不会传送近期的fsimage给active，最后留存在active的磁盘中，配置文件情况下在传送过程不会导致大量的网络和磁盘的压力，造成active的本地磁盘的Util超过100%，此时用户更改催促延后就不会变高。如果磁盘的Util100%持续时间很长就不会导致用户催促超时，甚至Checher的检测催促也因排队过长而超时，最后然后启动时Checker仲裁HA转换。　　转换的过程中在设计下有很最重要一点考虑到，无法同时有两个Active，所以要沦为新的Active NameNode，要把原本的Active NameNode暂停掉。

先会很友好关系地暂停，什么是友好关系呢？就是放一个RPC，如果顺利了就是友好关系的，如果告终了，就不会ssh过去，把原本active namenode进程kill丢弃，这就是Active NameNode出现异常弃的原因。　　当这个原因理解了之后，只不过要解决问题这个问题也非常简单。

　　第一点要把editlog与fsimage留存的本地目录分离出来配备，这种分离出来是磁盘上的分离出来，物理分离出来。　　第二是checkpoint之后fsimage传送车速。把editlog与fsimage两个磁盘分离出来，fsimage传送的io压力会对客户端催促导致影响，另外，传送车速后，也能容许io压力。

这是较为棘手的问题。原因看上去很非常简单，但是从现象寻找原因，这个过程并没那么更容易。　　第二个案例也是一样，Active NN又出现异常解散，产生HA转换。这次和网络连接数有关，这张图是Active NameNode的所在机器的网络连接数，平时都一挺长时间，20000到30000之间，突然有一个点一下碰到60000多，然后就打成平手了，最后降下来，降下来的原因很显著，是服务进程弃了。

　　为什么不会经常出现这个情况呢？在先前分析的过程中我们找到了一个线索，在NameNode日志里报了一个空指针的出现异常。就顺藤摸瓜找到了一个JDK1.7的BUG，参看上面图片右图，在java select库函数调度路径过程中最后不会调用这个函数（setUpdateEvents），大家可以看见，如果fd的个数多达了MAX_UPDATE_ARRAY_SIZE（65535）这个数的话，将不会跑到else路径，这个路径在if展开平均表达式辨别时，将不会抵达空指针出现异常。　　接下来的问题是，为什么不会产生这么多的链接呢？经过分析我们找到，在问题经常出现的时候，不存在一次大目录的DU操作者，而DU不会锁整个namespace，这样就造成先前的写出催促被堵塞，最后造成催促的冲刷，催促的冲刷造成了连接数大量冲刷，连接数冲刷到一定程度就启动时JDK1.7的这个BUG。

这个问题的解决问题，从两个方面看，首先我们再行把JDK升级到1.8。其次，调整参数dfs.content-summary.limit，容许du操作者的持锁时间。

该参数配置文件参数是0。我们现在是重设10000了，大家可以参照。这是第二个十分棘手的问题。　　第三个案例关于YARN主节点的，有一天中午，我们接到报警，找到Active RM出现异常进程解散，启动时HA的转换，然而转换后一会新的Active RM节点也不会出现异常解散，这就较为悲剧，我们再行展开了完全恢复。

　　之后我们从当时的日志中找到了原因：一个用户写出了一万个文件到分布式内存里，分布式内存里数据不会实时到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优化方面我们提到内存继续执行引擎与列存储方案的融合，在同等资源情况下针对线上一百多条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集群，然后再提一个Spark job来做到训练，最后在整个训练完结之后再行把集群停掉。Tensorflow也是一样的，首先启动tensorflow集群，然后递交任务，任务训练完了以后再行把集群停掉。其他工具分布式化我们也不会采行类似于的思路解决问题。

以上是关于深度自学这块我们目前的一些工作。　　其次，是关于空间资源利用率的。

目前我们有一千多台机器，存储是相当大的成本。之前也提及了，我们是归属于花钱的部门，所以压力十分大。那怎么节省成本是一个很最重要的问题。

除了传统传输之外，还能做到什么？HDFS RAID是一个较为好的解决方案。　　HDFS RAID使用是RC编码，类似于RAID6，比如一个文件有m个块，根据m个块分解k个校验块，然后能确保k个块遗失的情况下数据还能去找回去，荐个例子来说，比如文件2.5G大小，256M一个块，可以分为10个块，根据RC算法再行分解4个校验块，可以确保扔了4个块情况下，数据都能去找回去。在这个例子中，3副本情况下，一共必须30个块，而使用HDFS RAID，仅有必须14个块。

但他们的可靠性一样，空间闲置情况却劣了57%。　　具体实施时，第一步对集群数据展开冷分析，RAID却是有些性能问题，一旦数据有问题，你要通过计算出来才能完全恢复，势必会导致性能低落，所以针对冻数据做到认同是风险低于的。第二步就是传输+archive+RAID，通过三方面技术融合把文件数和空间全部节省出来。

文档实质上是不会转换目录的，为了做到兼容，我们通过硬连接功能，做对用户半透明。最后在数据加载时，如果是RAID数据，就要不具备动态RAID修缮功能才能确保在数据缺陷的情况下不影响数据的采访。　　先前我们不会对计算资源利用率再行做到更进一步提高。另外也不会考虑到Storm和YARN扩展性。

还有Kubernetes调度优化，比如针对GPU资源管理功能。　　以上就是我今天想要讲解的全部内容。在完结之前请求容许我再行做到一下总结。　　首先我讲解了58目前的大数据平台架构是怎么样的，非常简单来说就是“342”，三个层次、细分为四个子层、旁边两列。

所以大家要做到大数据平台建设工作，这几个方面是不可或缺的。　　第二个方面我重点的讲解了58在一年半的时间内的技术改良。第一点是关于稳定性，主要从Flume和HDFS扩展性方面重点讲解了我们的解决方案，荐了三个案例来解释脑溢血问题，不是说道有了可用性和扩展性就万事OK了，还要解决问题脑溢血问题。

针对平台管理首先讲解了一下数据和资源的管理方法，接着又讲解了关于易用性方面的改良，我们获取了一系列平台来提升开发人员的研发效率。　　第三方面从性能上讲解了我们这边做到的优化工作以及优化的结果是怎么样的；　　第四方面讲解了在异构环境下如何反对有所不同特征的作业展开合理调度。　　最后我讲解了58深度自学平台建设方面以及存储资源空间利用率优化方面的内容。

以上就是我今天的全部内容，期望对大家有协助。　　今日荐文 　　微软公司开源软件列表 涉及读者:《王者荣耀》女帝武则天COS：要叫我女王大人2017-03-27 王者荣耀S7新的赛季打开 王者荣耀S7赛季强势英雄2017-03-28 动画版《复活》？。

本文来源：98开元游戏官方网站-www.qqhejss6.com