基于决策函数模型的hbase故障预测方法、系统、设备和介质
技术领域：
：1.本技术涉及分布式存储
技术领域：
：，特别是涉及基于决策函数模型的hbase故障预测方法、系统、设备和介质。
背景技术：
：：2.hbase是一种开源分布式数据存储系统，基于谷歌bigtable论文开发，其需要运行在hdfs(一种开源分布式文件系统)之上。hbase是大数据生态中使用最广泛的分布式存储软件之一，国内就有很多大中型企业使用hbase存储各种海量的离线和实时数据。然而，hbase的异常、故障已成为使用hbase的公司的运维难题，比如国内就有某金融互联网公司曾因为hbase异常造成业务大面积中断。3.因此，hbase的故障监控非常重要，所以每个公司都有针对hbase的监控方案。但是，因为hbase产品的复杂性、部署的复杂性，目前对各种异常的感知、故障的分析并没有成熟的解决方案，绝大部分公司都依赖于开发运维人员的前期经验，对各种数据进行查看、分析诊断再干预。整个查看、诊断的过程经常要消耗大量时间，效率低，导致故障不能被尽早干预或者确认，进一步拖延了后续的优化处理过程。技术实现要素：4.本技术实施例提供了一种基于决策函数模型的hbase故障预测方法、系统、设备和介质，以至少解决相关技术中通过人为分析hbase故障，具有滞后性且效率低的问题。5.第一方面，本技术实施例提供一种基于决策函数模型的hbase故障预测方法，包括：采集hbase在各种故障场景下发生的监控项数据，根据各故障场景对所述监控项数据进行分类，确定每个故障场景对应的多个监控项；基于所述每个故障场景对应的多个监控项，分别建立每个故障场景对应的决策函数模型，其中，各所述决策函数模型的预测结论与各所述故障场景对应的多个监控项的阈值范围关联；获取hbase环境下各监控项的值，将各所述故障场景对应的多个监控项的值相应的输入各所述故障场景对应的决策函数模型，得出各所述故障场景对应的预测结论。6.在其中一些实施例中，所述采集hbase在各种故障场景下发生的监控项数据包括：采集硬件和操作系统的压力数据、hbase进程内部运行任务的压力数据以及对所述hbase进程产生影响的上游进程的状态数据。7.在其中一些实施例中，所述硬件和操作系统的压力数据包括cpu负载，cpuiowait，网卡入口流量，网卡出口流量，内存使用量，磁盘iops和磁盘iowait中的至少一项。8.在其中一些实施例中，所述hbase进程内部运行任务的压力数据包括：get读请求返回时间，scan读请求返回时间，写请求返回时间，get读请求并发度，scan读并发度，写并发度，hbase进程active线程数目，hbase进程处理队列积压数目，hbase进程优先active线程数目，hbase进程优先处理队列积压数目，hbaseyounggc时间，hbaseoldgc时间和hbasecompaction队列数目中的至少一项。9.在其中一些实施例中，所述对所述hbase进程产生影响的上游进程的状态数据包括：hdfsnamenodegc时间，hdfsnamenoderpc请求返回时间，hdfsnamenoderpc并发度和zookeeper健康数据中的至少一项。10.在其中一些实施例中，在所述监控项包括日志的情况下，所述获取hbase环境下各监控项的值包括：定时扫描日志数据，统计预设时间段内出现指定信息的频次。11.在其中一些实施例中，所述根据各故障场景对所述监控项数据进行分类，确定每个故障场景对应的多个监控项包括：根据分类后的监控项数据，对每个故障场景选取关联性最大的多个监控项数据作为各故障场景所对应的多个监控项数据。12.第二方面，本技术实施例提供一种基于决策函数模型的hbase故障预测系统，包括：采集模块、分类模块、建立模块和预测模块，其中，采集模块用于采集hbase在各种故障场景下发生的监控项数据；分类模块用于根据各故障场景对所述监控项数据进行分类，确定每个故障场景对应的多个监控项；建立模块用于基于所述每个故障场景对应的多个监控项，分别建立每个故障场景对应的决策函数模型，其中，各所述决策函数模型的预测结论与各所述故障场景对应的多个监控项的阈值范围关联；预测模块用于获取hbase环境下各监控项的值，将各所述故障场景对应的多个监控项的值相应的输入各所述故障场景对应的决策函数模型，得出各所述故障场景对应的预测结论。13.第三方面，本技术实施例提供一种电子设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项所述的方法。14.第四方面，本技术实施例提供一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项所述的方法。15.相比于相关技术，本技术实施例提供的基于决策函数模型的hbase故障预测方法，采集hbase在各种故障场景下发生的监控项数据，基于不同的故障场景对监控项数据进行分类，得到每个故障场景下的多个监控项数据，并且，针对每个故障场景建立决策函数模型，使得各决策函数模型的预测结论与各故障场景下的多个监控项的阈值范围关联，实现了不同故障的分类整理，基于此，获取hbase环境下各监控项的值，可以通过各故障场景对应的决策函数模型得出预测结论。因此，本技术实施例不仅实现了故障结论的自动分析，能快速分析数据，给出确切的故障结论，极大的提高了故障分析效率，提高了故障判断的及时性，有利于及时优化，能够极大程度的保证hbase系统的稳定运行；而且，对各种故障场景实现了分类处理，数据分析的针对性强，能够提高预测结果的准确性。另外，本技术实施例使用的监控项数据不仅包括hbase进程内部运行任务的压力数据，还包括采集硬件和操作系统的压力数据和对hbase进程产生影响的上游进程的状态数据，还可进一步使用日志数据，数据全面，变量因素考虑全面，能够进一步提高预测结论的准确性。进一步的，本技术实施例根据分类后的监控项数据，对每个故障场景选取关联性最大的多个监控项数据作为各故障场景所对应的多个监控项数据，由于每个故障场景的预测结论是依据与其关联性最大的的监控项来判断，避免在预测过程中无关联的监控项的干扰，能够保证预测结果的准确性，同时，在预测过程中，每个故障场景的预测判断并不依据所有监控项，而是依据选取的监控项来判断，能够降低计算量，从而提高预测速度，所以，本技术实施例能够在保证预测结果准确的前提下提高预测的速度。附图说明16.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：17.图1是根据本技术实施例的基于决策函数模型的hbase故障预测方法的流程图；18.图2是根据本技术实施例举例的基于决策函数模型的hbase故障预测方法的流程示意图；19.图3是根据本技术实施例的基于决策函数模型的hbase故障预测系统的结构框图20.图4是根据本技术实施例的电子设备的内部结构示意图。具体实施方式21.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。基于本技术提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本技术公开的内容相关的本领域的普通技术人员而言，在本技术揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本技术公开的内容不充分。22.在本技术中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本技术所描述的实施例在不冲突的情况下，可以与其它实施例相结合。23.除非另作定义，本技术所涉及的技术术语或者科学术语应当为本技术所属
技术领域：
：内具有一般技能的人士所理解的通常意义。本技术所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本技术所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块(单元)的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本技术所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本技术所涉及的“多个”是指大于或者等于两个。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“a和/或b”可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。本技术所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。24.针对hbase的监控，相关技术的一种方式是：依赖开发运维人员，在收到某些业务软件告警信息后，对hbase系统的各种数据进行查看，依据历史运维经验，对故障原因进行分析判断，严重依赖操作人员熟悉程度，具有明显的滞后性，对故障的预警、故障原因的分析、故障的止损、后续的优化都无法达到实时性。而当开发运维人员流动时，已有的处理经验无法完整顺利的被继承，在新老故障发生时对上层业务产生恶劣影响，降低规避和优化的效率。25.相关技术的另一种方式是：通过数据存储块服务器在服务层进行域的读写请求统计，在通过数据源端对域的读写请求统计进行数据采集，以及数据汇集端对数据源端采集的数据进行汇总获得表级监控数据并公布，实现对hbase系统的表级监控，该方式仅采集部分监控数据，且对故障场景下监控数据之间的关联没有分析，对各种不同故障场景也没有分类整理，无法给出确切的故障分析结果，只能作为辅助工具。26.另外，相关技术还涉及一种基于hadoop的任务优化调度方法，然而，hbase架构和hadoop大不相同，碰到的故障场景也完全不同，进行问题分析的技术依据完全不同，不能作为hbase故障分析的实施方案。27.所以，亟待提出一种技术方案，能协助开发运维人员在问题出现的早期发现问题进行干预，或者故障发生后实时分析出关键问题所在，从而能快速有效的缓解问题后果，或者快速解决故障原因，优化当前配置或者硬件软件环境，保证hbase系统的稳定运行。28.对此，本技术实施例提供一种基于决策函数模型的hbase故障预测方法，图1是根据本技术实施例的基于决策函数模型的hbase故障预测方法的流程图，如图1所示，该方法包括以下步骤：29.s101：采集hbase在各种故障场景下发生的监控项数据，根据各故障场景对监控项数据进行分类，确定每个故障场景对应的多个监控项；30.s102：基于每个故障场景对应的多个监控项，分别建立每个故障场景对应的决策函数模型，其中，各决策函数模型的预测结论与各故障场景对应的多个监控项的阈值范围关联；31.s103：获取hbase环境下各监控项的值，将各故障场景对应的多个监控项的值相应的输入各故障场景对应的决策函数模型，得出各故障场景对应的预测结论。32.根据以上内容，本技术实施例采集hbase在各种故障场景下发生的监控项数据，基于不同的故障场景对监控项数据进行分类，得到每个故障场景下的多个监控项数据，并且，针对每个故障场景建立决策函数模型，使得各决策函数模型的预测结论与各故障场景下的多个监控项的阈值范围关联，实现了不同故障的分类整理，基于此，获取hbase环境下各监控项的值，可以通过各故障场景对应的决策函数模型得出预测结论。因此，本技术实施例不仅实现了故障结论的自动分析，能快速分析数据，给出确切的故障结论，极大的提高了故障分析效率，提高了故障判断的及时性，有利于及时优化，能够极大程度的保证hbase系统的稳定运行；而且，对各种故障场景实现了分类处理，数据分析的针对性强，能够提高预测结果的准确性。33.为了对本技术实施例进行更清楚的说明，下文举例对上述的各步骤进行详述。34.s101，采集hbase在各种故障场景下发生的监控项数据，根据各故障场景对监控项数据进行分类，确定每个故障场景对应的多个监控项。优选的，考虑到监控的全面性，上述监控项数据包括硬件和操作系统的压力数据、hbase进程内部运行任务的压力数据以及对hbase进程产生影响的上游进程的状态数据。35.进一步的，上述硬件和操作系统的压力数据包括：cpu负载，cpuiowait，网卡入口流量，网卡出口流量，内存使用量，磁盘iops(input/outputoperationspersecond)和磁盘iowait；36.进一步的，上述hbase进程内部运行任务的压力数据包括：get读请求返回时间，scan读请求返回时间，写请求返回时间，get读请求并发度，scan读并发度(get读和scan读是hbase两种不同读请求方式)，写并发度，hbase进程active线程数目(也即hbase进程activehandler数)，hbase进程处理队列积压数目，hbase进程优先active线程数目，hbase进程优先处理队列积压数目，hbaseyounggc(garbagecollection)时间，hbaseoldgc时间，hbasecompaction队列数目。37.进一步的，上述对hbase进程产生影响的上游进程的状态数据主要包括：hdfsnamenodegc时间，hdfsnamenoderpc(remoteprocedurecall)请求返回时间，hdfsnamenoderpc并发度，zookeeper健康数据。38.基于上述内容，本技术实施例使用的监控项数据不仅包括hbase进程内部运行任务的压力数据，还包括采集硬件和操作系统的压力数据和对hbase进程产生影响的上游进程的状态数据，数据全面，变量因素考虑全面，能够进一步提高预测结论的准确性。39.为了进一步提高数据的全面性，上述监控项还可包括日志，即监控项数据还包括日志数据，该日志数据包括hbase进程的日志数据和操作系统的日志数据。主要是因为，在hbase进程、系统产生一定压力或异常故障时，会在hbase进程日志、系统日志中出现一些特殊日志数据，比如，当hbase进程发生严重(即达到预设值)gc(garbagecollection)时会打印jvm严重gc耗时信息；再比如，当磁盘故障时，系统日志会打印某磁盘error日志，这些日志对定位问题有明确的指导。40.上述各监控项通过特征变量来赋值，对日志数据来说，需要进行量化处理，将量化后的数值作为特征变量的值。例如，量化步骤包括：定时扫描日志数据，统计预设时间段内出现指定信息的频次，将频次作为用于决策分析的特征变量的值。举例来说，可在hbase进程机器部署监控进程，定时扫描hbaseregionserver进程日志，采集每分钟内日志数据中出现“util.jvmpausemonitor:detectedpauseinjvmorhostmachine(eggc):pauseofapproximately”信息的频次，作为严重gc的特征变量的值；再比如，部署监控程序，实时采集系统日志/var/log/messages中出现“kernel:blk_update_request:i/oerror”的频次，作为磁盘异常场景的特征变量的值。41.可选的，为了方便存储和计算，特征变量的值通过简写字母表示，比如，按照表1所示，将特征变量用简写字母表示：42.表1表示各特征变量与简写字母的对应关系43.特征变量简写字母磁盘iowaitx1系统日志中出现磁盘error的频次x2hbase节点读请求返回时间(单位为毫秒)x3hbase节点写请求返回时间(单位为毫秒)x4hbaseoldgc时间(单位为毫秒)x5日志数据中出现jvm严重gc的频次x6hbase进程activehandler数x7网卡出口流量(单位为兆)x8。44.根据表1，比如磁盘iowait的值为90，则x1＝90；再比如hbase节点读请求返回时间为400ms，则x3＝400。45.优选的，本技术实施例根据分类后的监控项数据，对每个故障场景选取关联性最大的多个监控项数据作为各故障场景所对应的多个监控项数据。具体的，可搜集真实情况下发生各种故障的监控项数据作为样本，分析出发生故障时监控项数据的规律，比如发生某种故障时，某几个(通常是多个)监控项的数值总是落在某极端值区间内，那么可以认为这几个监控项与该故障场景的关联性最大。为了保证监控项选取的准确性，技术人员可基于选取的监控项进行验证。另外，值得说明的是，上述极端值区间可以作为下文设置监控项的阈值范围的依据。基于此，由于每个故障场景的预测结论是依据与其关联性最大的监控项来判断，避免在预测过程中无关联的监控项数值干扰，能够保证预测结果的准确性，同时，在预测过程中，每个故障场景的预测判断并不依据所有监控项，而是依据选取的监控项来判断，能够降低计算量，从而提高预测速度，所以，本技术实施例能够在保证预测结果准确的前提下提高预测的速度。46.s102，基于每个故障场景对应的多个监控项，分别建立每个故障场景对应的决策函数模型，其中，各决策函数模型的预测结论与各故障场景对应的多个监控项的阈值范围关联。例如，hbase常见的异常结论主要有：1.内存故障；2.磁盘故障；3.cpu故障；4.hbase进程故障；5.zookeeper服务异常；6.hbase进程配置不合理；7.hbase进程严重gc；8.集群整体执行majorcompaction；9.底层hdfs流量暴涨；10.hdfsnamenode节点异常；11.hbase集群配置不合理。47.可以将异常结论用简写字母表示，用sderr表示磁盘故障，用ssgc表示hbase进程严重gc，用fsnof表示底层hdfs流量暴涨，用zkerr表示zookeeper服务异常，用mjcp表示集群整体执行majorcompaction。48.针对场景1：单机磁盘故障引起hbase异常49.构建决策函数模型1：若满足(x1》100)and(x2》0)and(x3》500orx4》500)，则sderr＝true，否则sderr＝false。50.针对场景2:某hbase进程严重gc51.构建决策函数模型2：若满足(x5》800)and(x6》0)and(x3》500orx4》500)and(x7》20)，则ssgc＝true，否则ssgc＝false。52.针对场景3:底层hdfs流量暴涨导致hbase进程卡顿53.构建决策函数模型3：若满足(x8》500)and！(x7》5)and(x3》500orx4》500)，则fsnof＝true，否则fsnof＝false。54.s103，在预测阶段，获取hbase环境下各监控项的值，由于各决策函数模型的预测结论与各故障场景对应的多个监控项的阈值范围关联，所以，将各故障场景对应的多个监控项的值相应的输入各故障场景对应的决策函数模型，可以得出各故障场景对应的预测结论。55.需要说明的是，当出现极端场景时，会导致多种决策函数模型同时判断生效，从而给出多个预测结果，这属于正常情况，为了方便查看和管理，可以将多个预测结论进行汇总，将汇总后的结论输出。56.另外，对于决策函数模型的有效性验证，本技术实施例采取以下措施：在测试环境部署hbase集群，选择多种异常场景构建测试数据、测试场景，部署监控环境，对不同的监控环境可以部署不同的决策软件，不同的决策软件可以预置不同的决策函数模型，从而确认不同场景下异常原因识别的有效性。57.进一步的，为了保证分析的实时性，可以在一定的时间窗口实时分析hbase状态，例如可设置过去1分钟内，基于实时监控项数据进行分析，并将所有决策函数模型的预测结果汇总。另外，在系统性能允许的情况下，可以缩小采集和分析粒度，例如每15秒分析一次，能够更大程度的保证分析的实时性。58.根据上文，在其中一些实施例中，图2是根据本技术实施例举例的基于决策函数模型的hbase故障预测方法的流程示意图，如图2所示，通过监控系统可以采集硬件和操作系统的压力数据、hbase进程内部运行任务的压力数据以及对该hbase进程产生影响的上游进程的状态数据；监控系统还采集hbase进程日志和操作系统日志经量化处理后的数据，从而得到特征变量的值，然后，读取这些特征变量的值，再根据n个决策函数模型，得到最终的预测结论，其中，n为正整数。因此，在hbase异常和故障时，能够根据预置的决策函数模型依次判断，给出清晰的结论，然后输出给相关人员。59.通过本技术实施例的方案，提高了故障发现的实时性、故障分析的实时性、后续优化的指导性，协助相关人员快速发现、快速解决或者止损，最小程度的降低hbase故障带来的危害，并且给出一定的结论指导，让不熟悉hbase系统和故障场景的运维开发人员能快速学习并处理hbase故障和配置优化问题。60.本技术实施例还提供一种基于决策函数模型的hbase故障预测系统，图3是根据本技术实施例的基于决策函数模型的hbase故障预测系统的结构框图，如图3所示，该系统包括采集模块1、分类模块2、建立模块3和预测模块4，其中，采集模块1用于采集hbase在各种故障场景下发生的监控项数据；分类模块2用于根据各故障场景对监控项数据进行分类，得到每个故障场景对应的多个监控项数据；建立模块3用于基于每个故障场景对应的多个监控项数据，分别建立每个故障场景对应的决策函数模型，其中，各决策函数模型的预测结论与各故障场景对应的多个监控项的阈值范围关联；预测模块4用于获取hbase环境下各监控项的值，将各故障场景对应的多个监控项的值相应的输入各故障场景对应的决策函数模型，得出各故障场景对应的预测结论。61.上述基于决策函数模型的hbase故障预测系统中，采集hbase在各种故障场景下发生的监控项数据，基于不同的故障场景对监控项数据进行分类，得到每个故障场景下的多个监控项数据，并且，针对每个故障场景建立决策函数模型，使得各决策函数模型的预测结论与各故障场景下的多个监控项的阈值范围关联，实现了不同故障的分类整理，基于此，获取hbase环境下各监控项的值，可以通过各故障场景对应的决策函数模型得出预测结论。因此，本技术实施例不仅实现了故障结论的自动分析，能快速分析数据，给出确切的故障结论，极大的提高了故障分析效率，提高了故障判断的及时性，有利于及时优化，能够极大程度的保证hbase系统的稳定运行；而且，对各种故障场景实现了分类处理，数据分析的针对性强，能够提高预测结果的准确性。62.需要说明的是，上述各个模块可以是功能模块也可以是程序模块，既可以通过软件来实现，也可以通过硬件来实现。对于通过硬件来实现的模块而言，上述各个模块可以位于同一处理器中；或者上述各个模块还可以按照任意组合的形式分别位于不同的处理器中。63.本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。64.另外，结合上述实施例中的基于决策函数模型的hbase故障预测方法，本技术实施例可提供一种存储介质来实现。该存储介质上存储有计算机程序；该计算机程序被处理器执行时实现上述实施例中的任意一种基于决策函数模型的hbase故障预测方法。65.本技术的一个实施例中还提供了一种电子设备，该电子设备可以是终端。该电子设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于决策函数模型的hbase故障预测方法。该电子设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该电子设备的输入装置可以是显示屏上覆盖的触摸层，也可以是电子设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。66.在一个实施例中，图4是根据本技术实施例的电子设备的内部结构示意图，如图4所示，提供了一种电子设备，该电子设备可以是服务器，其内部结构图可以如图4所示。该电子设备包括通过内部总线连接的处理器、网络接口、内存储器和非易失性存储器，其中，该非易失性存储器存储有操作系统、计算机程序和数据库。处理器用于提供计算和控制能力，网络接口用于与外部的终端通过网络连接通信，内存储器用于为操作系统和计算机程序的运行提供环境，计算机程序被处理器执行时以实现一种基于决策函数模型的hbase故障预测方法，数据库用于存储数据。67.本领域技术人员可以理解，图4中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。68.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。69.本领域的技术人员应该明白，以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。70.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。当前第1页12当前第1页12
技术领域：
：1.本技术涉及分布式存储
技术领域：
：，特别是涉及基于决策函数模型的hbase故障预测方法、系统、设备和介质。
背景技术：
：：2.hbase是一种开源分布式数据存储系统，基于谷歌bigtable论文开发，其需要运行在hdfs(一种开源分布式文件系统)之上。hbase是大数据生态中使用最广泛的分布式存储软件之一，国内就有很多大中型企业使用hbase存储各种海量的离线和实时数据。然而，hbase的异常、故障已成为使用hbase的公司的运维难题，比如国内就有某金融互联网公司曾因为hbase异常造成业务大面积中断。3.因此，hbase的故障监控非常重要，所以每个公司都有针对hbase的监控方案。但是，因为hbase产品的复杂性、部署的复杂性，目前对各种异常的感知、故障的分析并没有成熟的解决方案，绝大部分公司都依赖于开发运维人员的前期经验，对各种数据进行查看、分析诊断再干预。整个查看、诊断的过程经常要消耗大量时间，效率低，导致故障不能被尽早干预或者确认，进一步拖延了后续的优化处理过程。技术实现要素：4.本技术实施例提供了一种基于决策函数模型的hbase故障预测方法、系统、设备和介质，以至少解决相关技术中通过人为分析hbase故障，具有滞后性且效率低的问题。5.第一方面，本技术实施例提供一种基于决策函数模型的hbase故障预测方法，包括：采集hbase在各种故障场景下发生的监控项数据，根据各故障场景对所述监控项数据进行分类，确定每个故障场景对应的多个监控项；基于所述每个故障场景对应的多个监控项，分别建立每个故障场景对应的决策函数模型，其中，各所述决策函数模型的预测结论与各所述故障场景对应的多个监控项的阈值范围关联；获取hbase环境下各监控项的值，将各所述故障场景对应的多个监控项的值相应的输入各所述故障场景对应的决策函数模型，得出各所述故障场景对应的预测结论。6.在其中一些实施例中，所述采集hbase在各种故障场景下发生的监控项数据包括：采集硬件和操作系统的压力数据、hbase进程内部运行任务的压力数据以及对所述hbase进程产生影响的上游进程的状态数据。7.在其中一些实施例中，所述硬件和操作系统的压力数据包括cpu负载，cpuiowait，网卡入口流量，网卡出口流量，内存使用量，磁盘iops和磁盘iowait中的至少一项。8.在其中一些实施例中，所述hbase进程内部运行任务的压力数据包括：get读请求返回时间，scan读请求返回时间，写请求返回时间，get读请求并发度，scan读并发度，写并发度，hbase进程active线程数目，hbase进程处理队列积压数目，hbase进程优先active线程数目，hbase进程优先处理队列积压数目，hbaseyounggc时间，hbaseoldgc时间和hbasecompaction队列数目中的至少一项。9.在其中一些实施例中，所述对所述hbase进程产生影响的上游进程的状态数据包括：hdfsnamenodegc时间，hdfsnamenoderpc请求返回时间，hdfsnamenoderpc并发度和zookeeper健康数据中的至少一项。10.在其中一些实施例中，在所述监控项包括日志的情况下，所述获取hbase环境下各监控项的值包括：定时扫描日志数据，统计预设时间段内出现指定信息的频次。11.在其中一些实施例中，所述根据各故障场景对所述监控项数据进行分类，确定每个故障场景对应的多个监控项包括：根据分类后的监控项数据，对每个故障场景选取关联性最大的多个监控项数据作为各故障场景所对应的多个监控项数据。12.第二方面，本技术实施例提供一种基于决策函数模型的hbase故障预测系统，包括：采集模块、分类模块、建立模块和预测模块，其中，采集模块用于采集hbase在各种故障场景下发生的监控项数据；分类模块用于根据各故障场景对所述监控项数据进行分类，确定每个故障场景对应的多个监控项；建立模块用于基于所述每个故障场景对应的多个监控项，分别建立每个故障场景对应的决策函数模型，其中，各所述决策函数模型的预测结论与各所述故障场景对应的多个监控项的阈值范围关联；预测模块用于获取hbase环境下各监控项的值，将各所述故障场景对应的多个监控项的值相应的输入各所述故障场景对应的决策函数模型，得出各所述故障场景对应的预测结论。13.第三方面，本技术实施例提供一种电子设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项所述的方法。14.第四方面，本技术实施例提供一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项所述的方法。15.相比于相关技术，本技术实施例提供的基于决策函数模型的hbase故障预测方法，采集hbase在各种故障场景下发生的监控项数据，基于不同的故障场景对监控项数据进行分类，得到每个故障场景下的多个监控项数据，并且，针对每个故障场景建立决策函数模型，使得各决策函数模型的预测结论与各故障场景下的多个监控项的阈值范围关联，实现了不同故障的分类整理，基于此，获取hbase环境下各监控项的值，可以通过各故障场景对应的决策函数模型得出预测结论。因此，本技术实施例不仅实现了故障结论的自动分析，能快速分析数据，给出确切的故障结论，极大的提高了故障分析效率，提高了故障判断的及时性，有利于及时优化，能够极大程度的保证hbase系统的稳定运行；而且，对各种故障场景实现了分类处理，数据分析的针对性强，能够提高预测结果的准确性。另外，本技术实施例使用的监控项数据不仅包括hbase进程内部运行任务的压力数据，还包括采集硬件和操作系统的压力数据和对hbase进程产生影响的上游进程的状态数据，还可进一步使用日志数据，数据全面，变量因素考虑全面，能够进一步提高预测结论的准确性。进一步的，本技术实施例根据分类后的监控项数据，对每个故障场景选取关联性最大的多个监控项数据作为各故障场景所对应的多个监控项数据，由于每个故障场景的预测结论是依据与其关联性最大的的监控项来判断，避免在预测过程中无关联的监控项的干扰，能够保证预测结果的准确性，同时，在预测过程中，每个故障场景的预测判断并不依据所有监控项，而是依据选取的监控项来判断，能够降低计算量，从而提高预测速度，所以，本技术实施例能够在保证预测结果准确的前提下提高预测的速度。附图说明16.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：17.图1是根据本技术实施例的基于决策函数模型的hbase故障预测方法的流程图；18.图2是根据本技术实施例举例的基于决策函数模型的hbase故障预测方法的流程示意图；19.图3是根据本技术实施例的基于决策函数模型的hbase故障预测系统的结构框图20.图4是根据本技术实施例的电子设备的内部结构示意图。具体实施方式21.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。基于本技术提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本技术公开的内容相关的本领域的普通技术人员而言，在本技术揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本技术公开的内容不充分。22.在本技术中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本技术所描述的实施例在不冲突的情况下，可以与其它实施例相结合。23.除非另作定义，本技术所涉及的技术术语或者科学术语应当为本技术所属
技术领域：
：内具有一般技能的人士所理解的通常意义。本技术所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本技术所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块(单元)的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本技术所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本技术所涉及的“多个”是指大于或者等于两个。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“a和/或b”可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。本技术所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。24.针对hbase的监控，相关技术的一种方式是：依赖开发运维人员，在收到某些业务软件告警信息后，对hbase系统的各种数据进行查看，依据历史运维经验，对故障原因进行分析判断，严重依赖操作人员熟悉程度，具有明显的滞后性，对故障的预警、故障原因的分析、故障的止损、后续的优化都无法达到实时性。而当开发运维人员流动时，已有的处理经验无法完整顺利的被继承，在新老故障发生时对上层业务产生恶劣影响，降低规避和优化的效率。25.相关技术的另一种方式是：通过数据存储块服务器在服务层进行域的读写请求统计，在通过数据源端对域的读写请求统计进行数据采集，以及数据汇集端对数据源端采集的数据进行汇总获得表级监控数据并公布，实现对hbase系统的表级监控，该方式仅采集部分监控数据，且对故障场景下监控数据之间的关联没有分析，对各种不同故障场景也没有分类整理，无法给出确切的故障分析结果，只能作为辅助工具。26.另外，相关技术还涉及一种基于hadoop的任务优化调度方法，然而，hbase架构和hadoop大不相同，碰到的故障场景也完全不同，进行问题分析的技术依据完全不同，不能作为hbase故障分析的实施方案。27.所以，亟待提出一种技术方案，能协助开发运维人员在问题出现的早期发现问题进行干预，或者故障发生后实时分析出关键问题所在，从而能快速有效的缓解问题后果，或者快速解决故障原因，优化当前配置或者硬件软件环境，保证hbase系统的稳定运行。28.对此，本技术实施例提供一种基于决策函数模型的hbase故障预测方法，图1是根据本技术实施例的基于决策函数模型的hbase故障预测方法的流程图，如图1所示，该方法包括以下步骤：29.s101：采集hbase在各种故障场景下发生的监控项数据，根据各故障场景对监控项数据进行分类，确定每个故障场景对应的多个监控项；30.s102：基于每个故障场景对应的多个监控项，分别建立每个故障场景对应的决策函数模型，其中，各决策函数模型的预测结论与各故障场景对应的多个监控项的阈值范围关联；31.s103：获取hbase环境下各监控项的值，将各故障场景对应的多个监控项的值相应的输入各故障场景对应的决策函数模型，得出各故障场景对应的预测结论。32.根据以上内容，本技术实施例采集hbase在各种故障场景下发生的监控项数据，基于不同的故障场景对监控项数据进行分类，得到每个故障场景下的多个监控项数据，并且，针对每个故障场景建立决策函数模型，使得各决策函数模型的预测结论与各故障场景下的多个监控项的阈值范围关联，实现了不同故障的分类整理，基于此，获取hbase环境下各监控项的值，可以通过各故障场景对应的决策函数模型得出预测结论。因此，本技术实施例不仅实现了故障结论的自动分析，能快速分析数据，给出确切的故障结论，极大的提高了故障分析效率，提高了故障判断的及时性，有利于及时优化，能够极大程度的保证hbase系统的稳定运行；而且，对各种故障场景实现了分类处理，数据分析的针对性强，能够提高预测结果的准确性。33.为了对本技术实施例进行更清楚的说明，下文举例对上述的各步骤进行详述。34.s101，采集hbase在各种故障场景下发生的监控项数据，根据各故障场景对监控项数据进行分类，确定每个故障场景对应的多个监控项。优选的，考虑到监控的全面性，上述监控项数据包括硬件和操作系统的压力数据、hbase进程内部运行任务的压力数据以及对hbase进程产生影响的上游进程的状态数据。35.进一步的，上述硬件和操作系统的压力数据包括：cpu负载，cpuiowait，网卡入口流量，网卡出口流量，内存使用量，磁盘iops(input/outputoperationspersecond)和磁盘iowait；36.进一步的，上述hbase进程内部运行任务的压力数据包括：get读请求返回时间，scan读请求返回时间，写请求返回时间，get读请求并发度，scan读并发度(get读和scan读是hbase两种不同读请求方式)，写并发度，hbase进程active线程数目(也即hbase进程activehandler数)，hbase进程处理队列积压数目，hbase进程优先active线程数目，hbase进程优先处理队列积压数目，hbaseyounggc(garbagecollection)时间，hbaseoldgc时间，hbasecompaction队列数目。37.进一步的，上述对hbase进程产生影响的上游进程的状态数据主要包括：hdfsnamenodegc时间，hdfsnamenoderpc(remoteprocedurecall)请求返回时间，hdfsnamenoderpc并发度，zookeeper健康数据。38.基于上述内容，本技术实施例使用的监控项数据不仅包括hbase进程内部运行任务的压力数据，还包括采集硬件和操作系统的压力数据和对hbase进程产生影响的上游进程的状态数据，数据全面，变量因素考虑全面，能够进一步提高预测结论的准确性。39.为了进一步提高数据的全面性，上述监控项还可包括日志，即监控项数据还包括日志数据，该日志数据包括hbase进程的日志数据和操作系统的日志数据。主要是因为，在hbase进程、系统产生一定压力或异常故障时，会在hbase进程日志、系统日志中出现一些特殊日志数据，比如，当hbase进程发生严重(即达到预设值)gc(garbagecollection)时会打印jvm严重gc耗时信息；再比如，当磁盘故障时，系统日志会打印某磁盘error日志，这些日志对定位问题有明确的指导。40.上述各监控项通过特征变量来赋值，对日志数据来说，需要进行量化处理，将量化后的数值作为特征变量的值。例如，量化步骤包括：定时扫描日志数据，统计预设时间段内出现指定信息的频次，将频次作为用于决策分析的特征变量的值。举例来说，可在hbase进程机器部署监控进程，定时扫描hbaseregionserver进程日志，采集每分钟内日志数据中出现“util.jvmpausemonitor:detectedpauseinjvmorhostmachine(eggc):pauseofapproximately”信息的频次，作为严重gc的特征变量的值；再比如，部署监控程序，实时采集系统日志/var/log/messages中出现“kernel:blk_update_request:i/oerror”的频次，作为磁盘异常场景的特征变量的值。41.可选的，为了方便存储和计算，特征变量的值通过简写字母表示，比如，按照表1所示，将特征变量用简写字母表示：42.表1表示各特征变量与简写字母的对应关系43.特征变量简写字母磁盘iowaitx1系统日志中出现磁盘error的频次x2hbase节点读请求返回时间(单位为毫秒)x3hbase节点写请求返回时间(单位为毫秒)x4hbaseoldgc时间(单位为毫秒)x5日志数据中出现jvm严重gc的频次x6hbase进程activehandler数x7网卡出口流量(单位为兆)x8。44.根据表1，比如磁盘iowait的值为90，则x1＝90；再比如hbase节点读请求返回时间为400ms，则x3＝400。45.优选的，本技术实施例根据分类后的监控项数据，对每个故障场景选取关联性最大的多个监控项数据作为各故障场景所对应的多个监控项数据。具体的，可搜集真实情况下发生各种故障的监控项数据作为样本，分析出发生故障时监控项数据的规律，比如发生某种故障时，某几个(通常是多个)监控项的数值总是落在某极端值区间内，那么可以认为这几个监控项与该故障场景的关联性最大。为了保证监控项选取的准确性，技术人员可基于选取的监控项进行验证。另外，值得说明的是，上述极端值区间可以作为下文设置监控项的阈值范围的依据。基于此，由于每个故障场景的预测结论是依据与其关联性最大的监控项来判断，避免在预测过程中无关联的监控项数值干扰，能够保证预测结果的准确性，同时，在预测过程中，每个故障场景的预测判断并不依据所有监控项，而是依据选取的监控项来判断，能够降低计算量，从而提高预测速度，所以，本技术实施例能够在保证预测结果准确的前提下提高预测的速度。46.s102，基于每个故障场景对应的多个监控项，分别建立每个故障场景对应的决策函数模型，其中，各决策函数模型的预测结论与各故障场景对应的多个监控项的阈值范围关联。例如，hbase常见的异常结论主要有：1.内存故障；2.磁盘故障；3.cpu故障；4.hbase进程故障；5.zookeeper服务异常；6.hbase进程配置不合理；7.hbase进程严重gc；8.集群整体执行majorcompaction；9.底层hdfs流量暴涨；10.hdfsnamenode节点异常；11.hbase集群配置不合理。47.可以将异常结论用简写字母表示，用sderr表示磁盘故障，用ssgc表示hbase进程严重gc，用fsnof表示底层hdfs流量暴涨，用zkerr表示zookeeper服务异常，用mjcp表示集群整体执行majorcompaction。48.针对场景1：单机磁盘故障引起hbase异常49.构建决策函数模型1：若满足(x1》100)and(x2》0)and(x3》500orx4》500)，则sderr＝true，否则sderr＝false。50.针对场景2:某hbase进程严重gc51.构建决策函数模型2：若满足(x5》800)and(x6》0)and(x3》500orx4》500)and(x7》20)，则ssgc＝true，否则ssgc＝false。52.针对场景3:底层hdfs流量暴涨导致hbase进程卡顿53.构建决策函数模型3：若满足(x8》500)and！(x7》5)and(x3》500orx4》500)，则fsnof＝true，否则fsnof＝false。54.s103，在预测阶段，获取hbase环境下各监控项的值，由于各决策函数模型的预测结论与各故障场景对应的多个监控项的阈值范围关联，所以，将各故障场景对应的多个监控项的值相应的输入各故障场景对应的决策函数模型，可以得出各故障场景对应的预测结论。55.需要说明的是，当出现极端场景时，会导致多种决策函数模型同时判断生效，从而给出多个预测结果，这属于正常情况，为了方便查看和管理，可以将多个预测结论进行汇总，将汇总后的结论输出。56.另外，对于决策函数模型的有效性验证，本技术实施例采取以下措施：在测试环境部署hbase集群，选择多种异常场景构建测试数据、测试场景，部署监控环境，对不同的监控环境可以部署不同的决策软件，不同的决策软件可以预置不同的决策函数模型，从而确认不同场景下异常原因识别的有效性。57.进一步的，为了保证分析的实时性，可以在一定的时间窗口实时分析hbase状态，例如可设置过去1分钟内，基于实时监控项数据进行分析，并将所有决策函数模型的预测结果汇总。另外，在系统性能允许的情况下，可以缩小采集和分析粒度，例如每15秒分析一次，能够更大程度的保证分析的实时性。58.根据上文，在其中一些实施例中，图2是根据本技术实施例举例的基于决策函数模型的hbase故障预测方法的流程示意图，如图2所示，通过监控系统可以采集硬件和操作系统的压力数据、hbase进程内部运行任务的压力数据以及对该hbase进程产生影响的上游进程的状态数据；监控系统还采集hbase进程日志和操作系统日志经量化处理后的数据，从而得到特征变量的值，然后，读取这些特征变量的值，再根据n个决策函数模型，得到最终的预测结论，其中，n为正整数。因此，在hbase异常和故障时，能够根据预置的决策函数模型依次判断，给出清晰的结论，然后输出给相关人员。59.通过本技术实施例的方案，提高了故障发现的实时性、故障分析的实时性、后续优化的指导性，协助相关人员快速发现、快速解决或者止损，最小程度的降低hbase故障带来的危害，并且给出一定的结论指导，让不熟悉hbase系统和故障场景的运维开发人员能快速学习并处理hbase故障和配置优化问题。60.本技术实施例还提供一种基于决策函数模型的hbase故障预测系统，图3是根据本技术实施例的基于决策函数模型的hbase故障预测系统的结构框图，如图3所示，该系统包括采集模块1、分类模块2、建立模块3和预测模块4，其中，采集模块1用于采集hbase在各种故障场景下发生的监控项数据；分类模块2用于根据各故障场景对监控项数据进行分类，得到每个故障场景对应的多个监控项数据；建立模块3用于基于每个故障场景对应的多个监控项数据，分别建立每个故障场景对应的决策函数模型，其中，各决策函数模型的预测结论与各故障场景对应的多个监控项的阈值范围关联；预测模块4用于获取hbase环境下各监控项的值，将各故障场景对应的多个监控项的值相应的输入各故障场景对应的决策函数模型，得出各故障场景对应的预测结论。61.上述基于决策函数模型的hbase故障预测系统中，采集hbase在各种故障场景下发生的监控项数据，基于不同的故障场景对监控项数据进行分类，得到每个故障场景下的多个监控项数据，并且，针对每个故障场景建立决策函数模型，使得各决策函数模型的预测结论与各故障场景下的多个监控项的阈值范围关联，实现了不同故障的分类整理，基于此，获取hbase环境下各监控项的值，可以通过各故障场景对应的决策函数模型得出预测结论。因此，本技术实施例不仅实现了故障结论的自动分析，能快速分析数据，给出确切的故障结论，极大的提高了故障分析效率，提高了故障判断的及时性，有利于及时优化，能够极大程度的保证hbase系统的稳定运行；而且，对各种故障场景实现了分类处理，数据分析的针对性强，能够提高预测结果的准确性。62.需要说明的是，上述各个模块可以是功能模块也可以是程序模块，既可以通过软件来实现，也可以通过硬件来实现。对于通过硬件来实现的模块而言，上述各个模块可以位于同一处理器中；或者上述各个模块还可以按照任意组合的形式分别位于不同的处理器中。63.本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。64.另外，结合上述实施例中的基于决策函数模型的hbase故障预测方法，本技术实施例可提供一种存储介质来实现。该存储介质上存储有计算机程序；该计算机程序被处理器执行时实现上述实施例中的任意一种基于决策函数模型的hbase故障预测方法。65.本技术的一个实施例中还提供了一种电子设备，该电子设备可以是终端。该电子设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于决策函数模型的hbase故障预测方法。该电子设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该电子设备的输入装置可以是显示屏上覆盖的触摸层，也可以是电子设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。66.在一个实施例中，图4是根据本技术实施例的电子设备的内部结构示意图，如图4所示，提供了一种电子设备，该电子设备可以是服务器，其内部结构图可以如图4所示。该电子设备包括通过内部总线连接的处理器、网络接口、内存储器和非易失性存储器，其中，该非易失性存储器存储有操作系统、计算机程序和数据库。处理器用于提供计算和控制能力，网络接口用于与外部的终端通过网络连接通信，内存储器用于为操作系统和计算机程序的运行提供环境，计算机程序被处理器执行时以实现一种基于决策函数模型的hbase故障预测方法，数据库用于存储数据。67.本领域技术人员可以理解，图4中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。68.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。69.本领域的技术人员应该明白，以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。70.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
