精华内容
下载资源
问答
  • 分类模型、预测模型关联分析、聚类分析、异常值分析、协同过滤、社会网络
    千次阅读
    2020-03-10 11:00:39

    1、分类模型

    2、预测模型

    预测模型是在采用定量预测法进行预测时,最重要的工作是建立预测数学模型。预测模型是指用于预测的,用数学语言或公式所描述的事物间的数量关系。它在一定程度上揭示了事物间的内在规律性,预测时把它作为计算预测值的直接依据。因此,它对预测准确度有极大的影响。任何一种具体的预测方法都是以其特定的数学模型为特征。预测方法的种类很多,各有相应的预测模型。

    3、关联分析

    预测模型是在采用定量预测法进行预测时,最重要的工作是建立预测数学模型。预测模型是指用于预测的,用数学语言或公式所描述的事物间的数量关系。它在一定程度上揭示了事物间的内在规律性,预测时把它作为计算预测值的直接依据。因此,它对预测准确度有极大的影响。任何一种具体的预测方法都是以其特定的数学模型为特征。预测方法的种类很多,各有相应的预测模型。

    4、聚类分析

    聚类分析(cluster analysis)是一组将研究对象分为相对同质的群组(clusters)的统计分析技术,无监督学习。 聚类分析区别于分类分析(classification analysis) ,后者是有监督的学习。

    5、异常值分析

    异常值(outlier)是指一组测定值中与平均值的偏差超过两倍标准差的测定值,与平均值的偏差超过三倍标准差的测定值,称为高度异常的异常值。

    6、协同过滤

    协同过滤简单来说是利用某兴趣相投、拥有共同经验之群体的喜好来推荐用户感兴趣的信息,个人通过合作的机制给予信息相当程度的回应(如评分)并记录下来以达到过滤的目的进而帮助别人筛选信息,回应不一定局限于特别感兴趣的,特别不感兴趣信息的纪录也相当重要。
    协同过滤又可分为评比(rating)或者群体过滤(social filtering)协同过滤以其出色的速度和健壮性,在全球互联网领域炙手可热。

    7、社会网络

    社会网络(social network)是一种基于“网络”(节点之间的相互连接)而非“群体”(明确的边界和秩序)的社会组织形式,也是西方社会学从 1960 年代兴起的一种分析视角。随着工业化、城市化的进行和新的通讯技术的兴起,社会呈现越来越网络化的趋势,发生“社会网络革命”(social network revolution),与移动革命(mobile revolution)、互联网革命(internet revolution)并列为新时期影响人类社会的三大革命.

    更多相关内容
  • 针对卷积神经网络巨大的计算量和存储量导致其难以应用于嵌入式终端设备的难题,提出了一基于灰色关联分析的模型裁剪方法。利用基于灰色关联分析的裁剪方法处理经过数据训练后的权重模型文件,获得每个卷积核重要性的...
  • 引言 在很多安全分析类产品建设的过程中都会涉及到关联分析,比如日志分析,soc,态势感知,风控等产品。...有很多公司在自己的产品介绍中说自己的产品有多少内置规则等等,仔细分析就会发现很多是一个模型

    引言

    在很多安全分析类产品建设的过程中都会涉及到关联分析,比如日志分析,soc,态势感知,风控等产品。关联分析可以认为是这类产品中最核心的能力之一。这个东西从名字上看就知道,千人千面,每个人的想法和理解都不一样。很多甲方都会提关联分析,但你要在细问要做什么样的关联分析,估计大多数甲方都不太能详细说出来,很多乙方对此也是藏着掖着,可能也是核心机密不愿意细说。下面就来聊一下我对关联分析模型的一点思考。

    一、概述

    有很多公司在自己的产品介绍中说自己的产品有多少种内置规则等等,仔细分析就会发现很多是一个模型出来的,比如主机密码猜测,数据库密码猜测,网络设备密码猜测等,这些规则背后可以理解为一个模型。所以评价一个产品分析规则好坏的关键点我认为不全是内置多少种有效的规则,对关联规则模型支持的多少也可以作为一个重要指标,正如道生一,一生二,二生三,三生万物。当然分析规则的分析能力还要依托于日志解析的准确度和广度,日志解析的越准确,广度越广,对分析的支撑能力就越强。

     

    关联分析模型从大的分类看大概有以下 5种:

    1、基于规则的关联分析

    2、基于统计的关联分析

    3、基于威胁情报的关联分析

    4、基于情境的关联分析

    5、基于大数据的关联分析

    这些模型大概是业内提的最多的,但仔细分析,其实里面的内容并不是完全在一个维度上,里面还会有一些些交叉和关联。下面就对这5种常见的关联分析方法进行介绍:

    二、基于规则的关联分析

    基于规则的关联分析是目前是最常用的一种关联分析模型,这种关联分析模型是指按平台预先内置关联规则,或者用户自定义维护的关联规则对安全事件进行分析。平台接收到经过范式化的安全事件以后,通过事件维度与告警规则进行匹配,一旦匹配到符合条件的规则,规则就会被触发。在规则设定的时间窗口内,平台会将多条成功匹配规则的安全事件进行关联,并按规则设定进行告警。

    关联规则主要模拟攻击者攻击的行为,将平台采集的范式化后的日志,通过有效的字段组合,进行规则模型匹配分析,基于规则的关联分析主要针对于已知安全事件的分析,还要基于企业实际网络结构,业务场景进行调整,满足企业实际环境的需求。

    基于规则的关联分析的特点是准确,可理解,只要规则没有问题得出的结论就是没有问题的,但规则如何去做,这就是规则模型的内容。下面就介绍下一些常用的规则模型:

    2.1单条日志关联规则

    单条关联分析模型是基于规则的模型中最简单的一种方式,它的主要思想就是根据一条日志中的内容进行分析,比如linux下一条常用的登录日志:

    May 22 17:13:01 10-9-83-151 sshd[17422]: Accepted password for secisland from 129.74.226.122 port 64485 ssh2

    从这个日志中就有很多的信息,比如直接时间,主机名,进程名,事件类型,用户,源ip,端口;间接信息包括资产信息,账号信息,源ip地理信信息等。当这些丰富的信息解析出来后。我们可以很多的分析模型:

    ·非上班时间登录:

    这个就是说在非上班时间进行了登录行为,主要判断标准就是时间和登录成功事件。

    ·非上班地点登录:

    这个就是说在非上班地点进行了登录行为,主要判断标准就是登录IP和登录成功事件。这个场景在很多风控中也会应用,比如出差登录QQ邮箱,QQ可能会发个异地登录提醒,如果在网上第一次用信用卡进行美金支付,客服会打电话确认这个操作是不是你本人所为等。

    ·绕堡垒机登录:

    这个就是说在不在堡垒机上进行了登录行为,主要判断标准就是登录IP是否是堡垒机IP和登录成功事件。

    ·越权登录:

    这个根据业务逻辑比如某些账号不能登录某些服务器。主要判断标准就是登录账号,登录目标IP和登录成功事件。

    ·国外登录:

    这个就是说在登录的IP地址不是国内的IP进行了登录行为,主要判断标准就是登录IP是否是国内IP和登录成功事件。

    通过上面实例可以发现根据一条日志结合事件类型和业务等可以分析出非常多的告警行为。

    2.2 事件数量告警

    在很多攻击场景中,仅靠一条事件是不能发现攻击行为的,比如密码猜测行为,当有一条密码登录事件发生的时候,我们不能说这个是密码猜测行为,只有在一个短时间内发生了超过阈值数量的登录失败行为时,我们才能初步界定为这次行为是密码猜测行为。这种行为就是事件数量告警。这种模型主要有几个部分:

    ·时间维度,就是一段时间内;

    ·阈值维度,达到阈值的数量;

    ·条件维度,满足某些条件。

    比如刚才说的密码猜测,在三分钟内,登录失败的阈值达到6次以上,我们可以认为是一个密码猜测攻击行为。

    当然还有很多这种模型的类似规则,比如账号猜测,病毒爆发,CC攻击等行为。

    经常有些甲方提出来的跨设备的关联分析其实也可以归于这种模型,比如同一个IP在短时间内有多个产品发生了包含这个IP的日志。

    文章属于赛克蓝德原创,如需转载请完整保留作者公司信息。

    2.3 多值事件数量告警

    在有些情况下,事件数量告警是不能满足某些攻击场景,比如端口扫描,主机扫描等行为,这种行为的特性也是通过多条事件来判断,但仅仅通过数量是没有办法确定是否是攻击。比如端口扫描,你不能说短时间端口访问了100次就算是扫描行为,但是如果短时间不同端口访问了100一次以上,大概率应该是一个端口扫描行为。这种模型主要有几个部分:

    ·时间维度,就是一段时间内;

    ·阈值维度,达到阈值的数量;

    ·不同维度,类型相同但内容是不相同的;

    ·条件维度,满足某些条件。

    通过这些内容进行分析组合,可以分析出更多的场景,比如主机扫描就是1分钟同一个源IP访问不同主机的同一个端口数量超过100个就可以初步判断为主机扫描;比如分布式账号猜测,同一个账号登录失败的源IP地址在一分钟内出现了20个不一样的可以判断为分布式账号猜测等等。

    2.4 时序告警

    这是一种比之前更复杂模型的一种告警模型,这种模型在很多更复杂的场景中用到,比如:非上班时间登录ftp服务器,上传了一个脚本,然后下载了敏感文件行为。这种情况从大概率上看应该是一次违规行为,当然条件和内容可以演变。这种行为具有明显的特征就是时间顺序。比如“杀伤链”模型的六个阶段“发现-定位-跟踪-瞄准-打击-达成目标”也具有时间顺序的特征,只是这种时间序列的来源是告警而不是原始的事件。

     

     

    三、基于统计的关联分析

    基于统计模型的关联规则和之前的模型有些不太一样,有的公司用动态基线、基于行为的分析等的叫法,本质上应该都可以归于这一类模型。这种模型在用户行为异常分析中也大量使用(用户异常行为分析目前也有很多用机器学习算法来实现的)。

    具体来说就是阈值没有办法提前知道,需要通过计算前面的一段时间得到阈值,然后根据阈值进行计算偏离的方法。比如流量异常模型,很多的客户不一定知道平时的流量到底是多少才是正常的,这个时候就需要进行动态计算,比如今天9点到10的流量比前一周9点到10点流量的平均值大80%。这个情况就可以理解为流量异常模型。DDOS就是一种常用的统计异常模型:

     

    在异常行为分析中可以大量使用这种模型,比如访问异常,操作异常,下载异常等。

    还有种比较特殊的统计关联分析是低频行为分析,低频分析本质上也是一种统计行为分析,只是这种统计指标平时比较少,有可能在大量的数据中被淹没。这种情况下选择指标就比较重要。

    四、基于威胁情报的关联分析

    基于威胁情报数据的关联分析,是企业安全管理平台未来的主要发展趋势,它可以大大提升安全事件分析效率和对威胁行为的检测能力和响应速度。

    情报数据包括IP指纹、web指纹、IP信息、域名信息、漏洞库、样本库、IP信誉、域名信誉、URL信誉、文件信誉、C&C信誉等。

    通常情况下,企业安全管理平台与部署在云端的威胁情报平台互联或者把第三方情报数据定期导入到内网。经过安全管理平台的关联分析引擎生成的本地安全告警,与得到的威胁情报数据进行关联,通过对IP信誉、域名信誉、URL信誉、文件信誉、C&C信誉等多个维度的匹配,分析出安全告警的可信程度,过滤掉告警中的噪音事件,从而增加了本地安全告警的精准度,使得企业安全管理人员可以迅速定位威胁来源和相关联的资产和业务,并及时通过工单和处置流程进行快速响应;同时,利用威胁情报可以对攻击者进行深入分析和溯源取证。

    从模型来看,基于情报的关联分析并不是一种新的模型,它可以算是一种新的数据维度,比如以前没有没有情报的时候并不知道一个IP是否是恶意IP,一个URL是否是恶意URL,当有了情报后,可以拿这个数据和情况数据对比来确定是否是恶意行为。这种模型可以理解为单条事件模型的一个扩展,比如源IP使用就是判断源IP维度是否在情报的黑名单内,sourceIP in(情报)。

    五、基于情境的关联分析

    基于情境的关联分析是指将安全事件与当前的实际运行的环境进行关联,根据更多业务信息,环境信息进行相关性分析,识别安全威胁。比如基于资产的关联,根据事件中的IP地址与资产的信息进行关联;比如基于漏洞的关联,将安全事件与该事件所针对的目标资产当前具有的漏洞信息进行关联;基于其他告警的关联,将安全事件与该事件所针对的目标资产当前发生的其他告警信息进行关联;基于拓扑的关联,结合网络拓扑中网络区域内的告警进行关联。

    从模型来看,基于情境的关联分析也不是一种新的模型,它也可以算是一种新的数据维度的分析,比如在日志范式化中增加资产信息,漏洞信息,网络结构信息等。和其他高级关联可以归于事件数量告警的一个升级,只是事件告警的来源是事件,这个告警的来源是已经产生的告警,这个模型依然可以归于事件数量告警。整体上看,情境分析的模型基本上还是之前的模型,但分析的难度还是比较大的,因为这些情景很多都是动态变化的,目前大多数分析模型还是基于已经范式化后的事件,当这些情景发生变化或者事前没有进行范式化补充这些信息的时候。这种情况会大大增加分析的难度。

    六、基于大数据的关联分析

    目前我们已经进入了大数据时代。人类的生产生活每天都在产生大量的数据,并且产生的速度越来越快。而安全事件的数量也是类似的,每天产生的数据越来越多。其实大数据早就存在,只是一直没有足够的基础架构和技术来对这些数据进行有价值的挖据。随着科技的不断进步,对大数据的处理分析能力也越来越强。

    从模型来看,基于大数据的关联分析也不是一种新的模型,它主要的特点是利用了大数据技术去处理分析数据,比如存储,检索,聚合等。利用大数据平台的能力可以分析以前由于数据太大不能分析的场景。但在大数据分析领域也有很多数据关联性分析算法:相关性分析、回归分析、交叉表卡方分析等,但这些模型在安全分析的过程有多大的作用和效果,目前没有太大的研究,目前我这边还是用传统的分析模型利用大数据架构的能力进行安全分析。

    七、小结

    前面介绍的是目前传统的一些分析模型方法,可以作为对安全分析产品中关联分析是否灵活的一个参考。当然安全分析的前提是日志解析的准确,日志解析的准确也是一个非常复杂的内容,这块也分预处理和后处理等内容,后面有时间也会介绍下此部分的内容。安全攻防对抗一直在不停的进行演变,目前也出现了一些新的模型,比如基于预测模型的关联分析,基于机器学习的分析等,这部分目前还没有太多的心得。关联分析模型本身是一个比较复杂的内容,我尽量保证内容观点正确,但本人毕竟才学疏浅,文中若有不足之处欢迎大家批评指正。

    备注:文章属于赛克蓝德原创,赛克蓝德是专注于数据分析、安全分析、分析服务的提供商。如需转载请完整保留作者公司信息。

    展开全文
  • 为提高道路交通事故的预测精度以及建模速度,在分析道路交通事故影响因素基础上,提出了基于灰色关联分析的LS-SVM道路交通事故预测模型。该模型采用灰色关联分析完成影响因素的相关性分析,结合关联度值,筛选最小...
  • 全文检索领域的关键问题是索引模型以及该模型之上的高效搜索...优秀的全文索引模型关联后继树提出了基于后继区间的搜索算法,大大提升了全文的检索速度,从而更加充分地体现了互关联后继树模型在全文领域的优势。
  • 为了提高关联规则挖掘算法处理大数据集的性能,提出一新的模糊加权关联规则挖掘算法――FWAR算法。通过建立模糊加权关联规则模型生成候选项目集,并进行剪枝,新建的模型按权值对项目进行排序,符合向下封闭性,并...
  • Java IO篇:什么是 Reactor 网络模型

    千次阅读 2022-01-24 01:25:54
    Reactor 模式也叫做反应器设计模式,是一为处理服务请求并发提交到一个或者多个服务处理器的事件设计模式。当请求抵达后,通过服务处理器将这些请求采用多路分离的方式分发给相应的请求处理器。Reactor 模式主要由...

    一、什么是 Reactor 模型:

    The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers.

            Reactor 模式也叫做反应器设计模式,是一种为处理服务请求并发提交到一个或者多个服务处理器的事件设计模式。当请求抵达后,通过服务处理器将这些请求采用多路分离的方式分发给相应的请求处理器。Reactor 模式主要由 Reactor 和处理器 Handler 这两个核心部分组成,如下图所示,它俩负责的事情如下:

    • Reactor:负责监听和分发事件,事件类型包含连接事件、读写事件;
    • Handler :负责处理事件,如 read -> 业务逻辑 (decode + compute + encode)-> send;

    在绝大多数场景下,处理一个网络请求有如下几个步骤:

    • ① read:从 socket 读取数据。
    • ② decode:解码,网络上的数据都是以 byte 的形式进行传输的,要想获取真正的请求,必需解码
    • ③ compute:计算,也就是业务处理。
    • ④ encode:编码,网络上的数据都是以 byte 的形式进行传输的,也就是 socket 只接收 byte,所以必需编码。
    • ⑤ send:发送应答数据

            对于Reactor模式来说,每当有一个 Event 输入到 Server 端时,Service Handler 会将其转发(dispatch)相对应的 Handler 进行处理。Reactor 模型中定义的三种角色:

    • Reactor:派发器,负责监听和分配事件,并将事件分派给对应的 Handler。新的事件包含连接建立就绪、读就绪、写就绪等。
    • Acceptor:请求连接器,处理客户端新连接。Reactor 接收到 client 端的连接事件后,会将其转发给 Acceptor,由 Acceptor 接收 Client 的连接,创建对应的 Handler,并向 Reactor 注册此 Handler。
    • Handler:请求处理器,负责事件的处理,将自身与事件绑定,执行非阻塞读/写任务,完成 channel 的读入,完成处理业务逻辑后,负责将结果写出 channel。可用资源池来管理。

    模型大致如下图所示:

     对于读/写请求,Reactor 模型是按照以下流程处理的:

    • (1)应用程序注册读/写就绪事件和相关联的事件处理器
    • (2)事件分离器等待事件的发生
    • (3)当发生读/写就绪事件的时候,事件分离器调用第一步注册的事件处理器

    二、Reactor 模型的分类:

            Reactor 模型中的 Reactor 可以是单个也可以是多个,Handler 同样可以是单线程也可以是多线程,所以组合的模式大致有如下三种:

    • 单 Reactor 单线程模型
    • 单 Reactor 多线程模型
    • 主从 Reactor 单线程模型
    • 主从 Reactor 多线程模型

    其中第三种的主从Reactor单线程模型没什么实际意义,所以下文就着重介绍其他三种模型

    1、单 Reactor 单线程模型:

    1.1、处理流程:

    (1)Reactor 线程通过 select 监听事件,收到事件后通过 Dispatch 进行分发

    (2)如果是连接建立事件,则将事件分发给 Acceptor,Acceptor 会通过 accept() 方法获取连接,并创建一个Handler 对象来处理后续的响应事件

    (3)如果是IO读写事件,则 Reactor 会将该事件交由当前连接的 Handler 来处理

    (4)Handler 会完成 read -> 业务处理 -> send 的完整业务流程

    1.2、优缺点:

            单 Reactor 单线程模型的优点在于将所有处理逻辑放在一个线程中实现,没有多线程、进程通信、竞争的问题。但该模型在性能与可靠性方面存在比较严重的问题:

    • ① 性能:只在代码上进行组件的区分,整体操作还是单线程,无法充分利用 CPU 资源,并且 Handler 业务处理部分没有异步,一个 Reactor 既要负责处理连接请求,又要负责处理读写请求,一般来说处理连接请求是很快的,但处理读写请求时涉及到业务逻辑处理,相对慢很多。所以 Reactor 在处理读写请求时,其他请求只能等着,容易造成系统的性能瓶颈
    • ② 可靠性:一旦 Reactor 线程意外中断或者进入死循环,会导致整个系统通信模块不可用,不能接收和处理外部消息,造成节点故障

            所以该单Reactor单进程模型不适用于计算密集型的场景,只适用于业务处理非常快速的场景。Redis的线程模型就是基于单 Reactor 单线程模型实现的,因为 Redis 业务处理主要是在内存中完成,操作的速度是很快的,性能瓶颈不在 CPU 上,所以 Redis 对于命令的处理是单进程的。

    2、单 Reactor 多线程模型:

            为了解决单Reactor单线程模型存在的性能问题,就演进出了单 Reactor 多线程模型,该模型在事件处理器部分采用了多线程(线程池)

    2.1、处理流程:

     (1)Reactor 线程通过 select 监听事件,收到事件后通过 Dispatch 进行分发

    (2)如果是连接建立事件,则将事件分发给 Acceptor,Acceptor 会通过 accept() 方法获取连接,并创建一个Handler 对象来处理后续的响应事件

    (3)如果是IO读写事件,则 Reactor 会将该事件交由当前连接对应的 Handler 来处理

    (4)与单Reactor单线程不同的是,Handler 不再做具体业务处理,只负责接收和响应事件,通过 read 接收数据后,将数据发送给后面的 Worker 线程池进行业务处理。

    (5)Worker 线程池再分配线程进行业务处理,完成后将响应结果发给 Handler 进行处理。

    (6)Handler 收到响应结果后通过 send 将响应结果返回给 Client。

    2.2、优缺点:

            相对于第一种模型来说,在处理业务逻辑,也就是获取到 IO读写事件之后,交由线程池来处理,Handler 收到响应后通过 send 将响应结果返回给客户端。这样可以降低 Reactor 的性能开销,从而更专注的做事件分发工作了,提升整个应用的吞吐,并且 Handler 使用了多线程模式,可以充分利用 CPU 的性能。但是这个模型存在的问题:

    (1)Handler 使用多线程模式,自然带来了多线程竞争资源的开销,同时涉及共享数据的互斥和保护机制,实现比较复杂

    (2)单个 Reactor 承担所有事件的监听、分发和响应,对于高并发场景,容易造成性能瓶颈。

    3、主从 Reactor 多线程模型:

            单Reactor多线程模型解决了 Handler 单线程的性能问题,但是 Reactor 还是单线程的,对于高并发场景还是会有性能瓶颈,所以需要将 Reactor 调整为多线程模式,也就是接下来要介绍的主从 Reactor 多线程模型。主从 Reactor 多线程模型将 Reactor 分成两部分:

    (1)MainReactor:只负责处理连接建立事件,通过 select 监听 server socket,将建立的 socketChannel 指定注册给 subReactor,通常一个线程就可以了

    (2)SubReactor:负责读写事件,维护自己的 selector,基于 MainReactor 注册的 SocketChannel 进行多路分离 IO 读写事件,读写网络数据,并将业务处理交由 worker 线程池来完成。SubReactor 的个数一般和 CPU 个数相同

    3.1、处理流程: 

    (1)主线程中的 MainReactor 对象通过 select 监听事件,接收到事件后通过 Dispatch 进行分发,如果事件类型为连接建立事件则分发给 Acceptor 进行连接建立

    连接建立:

    • ① 从主线程池中随机选择一个 Reactor 线程作为 Acceptor 线程,用于绑定监听端口,接收客户端连接
    • ② Acceptor 线程接收客户端连接请求之后创建新的 SocketChannel,将其注册到主线程池的其它 Reactor 线程上,由其负责接入认证、IP黑白名单过滤、握手等操作。
    • ③ 步骤② 完成之后,业务层的链路正式建立,将 SocketChannel 从主线程池的 Reactor 线程的多路复用器上摘除,重新注册到 SubReactor 线程池的线程上,并创建一个 Handler 用于处理各种连接事件

    (2)如果接收到的不是连接建立事件,则分发给 SubReactor,SubReactor 调用当前连接对应的 Handler 进行处理

    (3)Handler 通过 read 读取数据后,将数据分发给 Worker 线程池进行业务处理,Worker 线程池则分配线程进行业务处理,完成后将响应结果发给 Handler

    (4)Handler 收到响应结果后通过 send 将响应结果返回给 Client

    3.2、优缺点:

            主从 Reactor 多线程模型的优点在于主线程和子线程分工明确,主线程只负责接收新连接,子线程负责完成后续的业务处理,同时主线程和子线程的交互也很简单,子线程接收主线程的连接后,只管业务处理即可,无须关注主线程,可以直接在子线程将处理结果发送给客户端。

            该 Reactor 模型适用于高并发场景,并且 Netty 网络通信框架也是采用这种实现

    4、Reactor 优缺点:

    (1)响应快,不必为单个同步时间所阻塞,虽然 Reactor 本身依然是同步的;

    (2)可以最大程度的避免复杂的多线程及同步问题,并且避免了多线程/进程的切换开销

    (3)可扩展性,可以方便地通过增加 Reactor 实例个数来充分利用 CPU 资源;

    (4)可复用性,Reactor 模型本身与具体事件处理逻辑无关,具有很高的复用性。

    Reacotr 模型是一种非阻塞同步网络模型,除此之外,还有一种 Proactor 的异步网络模型,对 Proactor 感兴趣的读者可以阅读这篇文章:https://blog.csdn.net/a745233700/article/details/122390285

    参考文章:

    彻底搞懂Reactor模型和Proactor模型 - 云+社区 - 腾讯云

    【死磕 NIO】— Reactor 模式就一定意味着高性能吗?

    展开全文
  • 机器学习模型部署的三种方法

    千次阅读 2020-08-13 10:49:29
    “企业机器学习需要从数据工程和数据平台的角度看待大局[...],”贾斯汀·诺曼(Justin Norman)在今年巴塞罗那的DataWorks峰会上关于机器学习模型的部署的演讲中说。实际上,工业机器学习系统是庞大数据基础架构的...

    “企业机器学习需要从数据工程和数据平台的角度看待大局[...],”贾斯汀·诺曼(Justin Norman)在今年巴塞罗那DataWorks峰会上关于机器学习模型的部署的演讲中说

    实际上,工业机器学习系统是庞大数据基础架构的一部分,这使得端到端ML工作流变得特别复杂。当我们追求最好的机器学习算法时,与现实世界机器学习系统的开发,部署和维护相关的挑战不容忽视。

     

    机器学习并不一定要取代人类的决策,它主要是关于帮助人们做出复杂的基于判断的决策。

    我参加的演讲是Cloudera的专家Justin Norman和Sagar Kewalramani进行的“ 机器学习模型部署:实施战略”。他们就端到端ML工作流遇到的挑战作了演讲,重点介绍了将机器学习交付到生产环境。

    需求的AI金字塔

    越来越多的企业使用机器学习和AI来改善他们的服务并在竞争中领先。不幸的是,许多企业在没有适当的数据平台的情况下进行了AI转换,也没有对部署ML模型的理解。首先应满足几个大数据和数据科学技术需求:

    • 大数据基础架构,用于在通常由数据工程师处理的系统的不同部分之间收集,提取,存储,清理和移动数据
    • 分析策略,用于探索,可视化,转换和预处理数据为有用的ML输入变量
    • 一个框架,用于试验算法,对其进行协作并在跟踪所有模型的参数,准确性和性能的同时进行部署
    • 用最简单的数据科学算法建立基准

    除此之外,您还需要牢记ML平台的一些重要特征:

    • 与业务流程的深度集成
    • 连续交付(CI / CD像任何经典代码一样
    • 闭环反馈

    在演示中,这些需求用金字塔表示,类似于马斯洛的需求层次结构。上面列表中的点被视为金字塔的级别,从金字塔的第一个点开始。这个概念,也称为“需求的AI层次结构”,有助于理解以下要点:

    没有用于计算(食物,水,温暖)的基本基础设施,就没有人工智能(与自我实现相对应)。在成功使用机器学习算法之前,您必须能够对过去进行推理并对未来有基本的了解。如果所使用的数据集被误解且未准备好,您将无法期望神经网络会产生出色的结果。

    通常,将精力放在基本系统方面可以比调整当前的预测算法更多地提高预测的准确性。例如,与调整ML模型相比,处理输入数据的表示形式可以产生更好的结果。当满足了所有基本工程需求并且准确性不足时,则应该将精力放在更复杂的算法上。

    机器学习系统中隐藏的技术债务

    考虑到Google题为“机器学习系统中的隐藏技术债务”(pdf)的论文,企业ML系统中软件工程工作的重要性显而易见。作者在其中辩称,现实世界中的ML系统只有一小部分由ML代码组成。ML代码可能甚至不到整个ML系统的10%。

    1

     

    尽管ML代码决定了所有决策,但从整个软件系统的角度来看,这几乎是无关紧要的,而整个软件系统必须为解决最终用户的问题而开发。提供决策的微小ML部分很重要,但是系统中还有许多其他重要组件。花时间在系统架构的设计,模型强化,部署,监视等上至少与花在ML上一样有价值。

    端到端ML工作流程的挑战

    ML工作流应解决金字塔所有层次的问题,以确保它不会招致潜在的技术债务。为了总结演讲的前半部分,可以确定端到端ML工作流中的三个主要挑战:复杂性,规模和试验。挑战不是排他的,它们都是相互关联的。

    复杂

    企业机器学习工作流程要求:

    • 数据基础架构和大量数据处理为ML模型提供了准备好的数据
    • 通过多次实验构建ML模型
    • 将ML模型部署到生产中并进行监视的大量工作

    上面列出的点可以与三个不同的专业相关:数据工程师,数据科学家和DevOps工程师。他们对项目有不同的看法,对输出有不同的期望,并使用不同的工具。ML系统中存在的示例技术是HadoopKafkaSparkTensorflowxgboostDockerKubernetes。这些工具必须集成,并且必须实现在它们之间安全移动数据的机制。

    人们的推理和工具集之间的差异可能导致可能破坏整个项目的问题。例如,数据科学家倾向于使用无法并行化且不能在生产环境中使用的笔记本和软件包来生成代码,因为它们无法部署在分布式系统上。笔记本就像是所需输出模型(蛋糕)的规格(配方))。由于数据工程师和DevOps并不是数据科学领域的专家,因此他们可能会误解该食谱,并烤出另一块蛋糕。仅仅由于团队之间的错误解释,生产中的ML模型可能会导致与预期产品不匹配,并且无法满足用例。由于每个用例需要不同的特定ML模型,不同的数据准备以及部署的特殊考虑因素,因此增加了复杂性。

    规模

    大规模是工业机器学习的重要特征。机器学习解决方案可能需要扩展才能为数百万个客户提供服务,这意味着需要庞大的数据集。预处理这些大数据集并将其用于训练ML模型需要大量的计算能力。大数据技术通常用于在安全集群环境中通过并行计算来提供该计算能力。将训练有素的机器学习模型大规模部署到生产中也意味着需要DevOps策略和工具。

    实验性

    创建ML模型是一个涉及许多实验的渐进过程。ML面临的一个独特挑战是跟踪这些实验。必须向数据科学家提供一种手段,用于预订模型每次训练的信息:模型参数,使用的库,版本等。

    CI工具和系统必须足够健壮,才能为不同的ML模型(每个都有特定的依赖性)提供灵活性,并具有兼容性,以在生产中快速扩展,升级和降级ML模型。然后,必须监视和管理许多ML模型。

    端到端ML工作流程的策略和生命周期

    具有ML功能的产品必须将ML管道视为数据基础结构的一部分。同样,机器学习输出必须视为在较大系统中获得的结果的子集。如果没有集成,将ML模型投入生产将需要很长时间才能保持竞争力。

    ML工作流的三个部分将得到解决:

    • 版本化和可复制的ML模型训练
    • ML模型部署
    • 生产中的ML模型管理

    重要的一点是,无论使用什么工具来开发ML模型,最好避免移动数据。处理数据所在的位置。无需跨多个平台发送数据,而是选择单个可扩展的分布式解决方案,例如在内部部署环境或环境中。

    最好避免移动数据,例如在数据驻留的内部部署环境或云环境内部。

    版本化和可复制的ML模型训练

    机器学习模型是在迭代过程中创建的。通过许多实验获得了最终投入生产的ML模型,其中以反复试验的方式逐步调整模型的参数和超参数。

    不幸的是,跟踪这些实验并不是一种常见的做法,导致最终模型的中间版本往往会迷失方向。ML工作流应提供一种轻松跟踪和管理新兴ML模型的方法。

    最终模型之前应有一系列先前模型元信息的快照,例如创建模型的人员和时间,模型的代码,依赖项配置,参数,注释等。

    专门解决版本化,可再现的ML模型训练的项目的两个示例是:

    • DVC-机器学习项目的开源版本控制系统
    • 彗星 -专有解决方案

    ML模型部署

    部署应快速并适应业务需求。部署的模型应该受到监控并且易于管理。根据业务用例,可以采用三种主要的部署模式:

    • 批处理部署-ML模型以脱机方式使用。例如,生成带有预测的每日报告,以帮助管理人员做出决策
    • 实时部署-ML模型用于自动执行对时间敏感的决策。例如,在推荐系统和欺诈检测系统中
    • 边缘部署-ML模型用于对时间要求严格的系统中,需要立即做出决策。先前的两种部署类型都有一个运行ML模型的中央单元,而边缘部署的模型则直接在外部系统上执行。例如,在自主无人机中

    ML模型可以部署为例如Java / C ++ / Python应用程序,Spark应用程序或REST API。与基于API的模型部署相比,将模型作为应用程序进行部署的成本更高且速度较慢,但​​可提供更高的可靠性,更高的速度和更好的安全性。部署格式仍然是很大程度上取决于用例的决定。

    用例确定哪种模式部署适用,这又决定了部署格式和使用的工具。例如,在批处理部署方案中,可以选择在Hadoop集群上运行的Scala Spark作业。在实时场景中,需要一种流处理引擎,例如FlinkKafka Stream。最后,在边缘部署可能需要重写为C / C ++和特定的处理器体系结构。

    生产中的ML模型管理

    与在训练阶段跟踪实验类似,应在生产ML中跟踪ML模型。

    • 在部署时,应收集所有元数据:模型的部署者和部署时间,模型是什么,模型的版本,参数等。
    • 必须监视已部署模型的性能,并收集各种度量标准,例如准确性,F1分数(用于衡量测试的准确性),业务KPI,资源使用,响应时间等。需要确定降级模型并分析其性能度量标准。哪个指标发生了漂移,出现了多少,何时出现等情况。

    在生产中对ML模型的跟踪使数据科学家可以重新评估模型并重新考虑所选的学习算法。同样,可以部署模型的一些变体并进行比较。应该根据用例的性能,统计意义和实际意义进行比较。

    有一些工具专门针对ML模型管理(例如Datmo),但是更常见的是这是整个机器学习平台的功能。

    货柜化

    如前所述,每种模型部署格式都对应于特定的用例,并具有许多特定的要求:语言,框架,库,包。通常,这些依赖项必须具有特定版本。这创建了许多不同的软件先决条件,通常是相互冲突的。由于依赖性和其他软件冲突之间的版本不匹配,因此在群集的节点上安装不同的软件可能是一个障碍。容器化可以是一种解决方案。我们可以利用容器化在已打包所有必需软件的隔离Docker环境中托管ML模型。可以将不同版本的项目代码打包到具有不同Docker映像的多个Docker容器中。

    Kubernetes是部署和管理可伸缩容器化应用程序的绝佳工具。它通常用于编排Docker容器。或者,Hadoop 3可以编排Docker容器

    机器学习平台

    仅仅几年前,还没有大规模构建ML系统的工具。大公司必须创建自己的平台,例如Uber的机器学习平台Michelangelo。在某种程度上,这种专有平台为ML工作流创建了标准,然后在开源生态系统中采用了这些标准。

    如今,有几种机器学习平台/工具包可用于帮助ML工作流。演讲中提出的最引人注目的选择是Cloudera Data Science Workbench(CDSW),它与常用的数据平台CDHHDP集成在一起。

    Hadoop集群上的ML项目的一个有趣选项是Apache的Hadoop Submarine,我在另一个演讲中发现了Hadoop {Submarine}项目: Sunil Govindan和Zhankun Tang给出的在YARN上运行深度学习工作负载。潜艇允许在Hadoop集群上计算未修改的Tensorflow应用程序。Submarine利用Hadoop YARN编排ML工作负载,并利用Hadoop HDFS收集和存储系统中的数据。由于Hadoop 3支持YARN以及Docker容器上的GPU调度和隔离,因此该解决方案成为可能。

    MLflow平台似乎是一个有前途的选择。还有两个替代方案是PolyaxonKubeflow,它们适用于Kubernetes

    结论

    人工智能和机器学习正在进入工业化阶段。训练ML模型的大规模,复杂性和实验性是企业ML工作流程中的主要挑战。正在创建新的工具和平台,以在行业中开发,训练和部署ML模型。

    原文:https://www.adaltas.com/en/2019/09/30/machine-learning-model-deployment/

    展开全文
  • 最近写个人项目,遇到个小坑——Thinkphp关联模型使用field函数时必须包含relation_foreign_key,否则无法关联
  • 最近也快到年底了,老李就整理了15常用/常见的数据分析方法和模型,并将其分为两大类,方便大家理解记忆,话不多话,直接开盘! 对外部用户分析模型 1、RFM分析 以往文章:数据分析初学者必备!10分钟搭建RFM客户...
  • 关于thinkphp关联模型的效率问题

    千次阅读 2014-08-22 15:45:07
    以前听说过thinkphp关联模型效率比较低,但是一直没去kan yuan dai ma
  • 条件随机场(Conditional random fields),是一判别式图模型,因为其强大的表达能力和出色的性能,得到了广泛的应用。从最通用角度来看,CRF本质上是给定了观察值集合 (observations)的马尔可夫随机场(MRF)。在...
  • **灰色关联以及灰色预测GM(1,n),GM(1,1)模型** 简介:本篇文章简单的介绍灰色关联以及灰色预测模型,并且使用python代码进行实现。 1. 灰色系统的概论 2. 关于灰色关联度那些事 3. GM(1,1)模型简介以及相关实现...
  • laravel hasOne hasMany模型关联查询

    千次阅读 2019-01-18 19:25:21
    hasOne public function findByRandAll() { return $this->where("status", '<>', '0') ->inRandomOrder() ->with(['userinfo:uid,nickname,avatar']) ...
  • 今天帆软君就来给大家分享18常用的数据分析模型和方法,并附上用FineBI分析的步骤教程,希望对大家有所帮助! 1、RFM模型 RFM 用于对用户进行分类,并判断每类细分用户的价值。 个关键指标: 最近一次消费时间...
  • 全面理解Java内存模型(JMM)及volatile关键字

    万次阅读 多人点赞 2017-06-12 11:25:05
    【版权申明】未经博主同意,谢绝转载!(请尊重原创,博主保留追究权) ...关联文章: 深入理解Java类型信息(Class对象)与反射机制 深入理解Java枚举类型(enum) 深入理解Java注解类型(@Annotation) 深...
  • Cesium bim模型加载并与模型关联(分层加载)

    千次阅读 多人点赞 2019-10-21 17:24:57
    最近没事儿写了个模型树和模型关联的功能,处理工具是用的cesiumlab。 说明一下为什么要用cesiumlab: 网上现在有很多的模型转换工具,如obj23dtiles等均可以对非3dtiles的模型进行处理,为何非得用cesiumlab呢?...
  • ####使用with时 with()方法是用作“渴求式加载”的,那主要意味着,laravel将会伴随着主要模型预加载出确切的的关联关系。这就对那些如果你想加在一个模型的所有关联关系非常有帮助。因为“渴求式加载”缓解了1+N的...
  • RabbitMQ消息模型详解

    千次阅读 2022-03-03 15:03:32
    RabbitMQ消息模型详解,原理详解,代码展示。其中包括简单消息模型,工作模型,订阅发布模型,订阅模型-Fanout,订阅模型-Direct。
  • 维空间建模方法之LOD模型算法

    千次阅读 2019-05-14 22:10:00
    LOD也称为层次细节模型,是一实时维计算机图形技术,最先由Clark于1976年提出,其工作原理是: 视点离物体近时,能观察到的模型细节丰富;视点远离模型时,观察到的细节逐渐模糊。系统绘图程序根据一定的判断...
  • 彻底搞懂Reactor模型和Proactor模型

    千次阅读 2019-08-05 08:00:00
    在高性能的I/O设计中,有两个著名的模型:Reactor模型和Proactor模型,其中Reactor模型用于...无论是Reactor模型还是Proactor模型,对于支持多连接的服务器,一般可以总结为2fd和3事件,如下图: 2fd l...
  • 数学建模笔记——评价类模型

    千次阅读 多人点赞 2020-08-22 08:37:24
    最近回到老家养生,逗逗鸡遛遛狗看看小说,就没怎么更新,当然也没怎么学习,不知不觉都一周了……嗯,这样确实不太好,接下来会恢复更新的频率,一周两篇。由于就我一个人写,效率也不太高,还请谅解。 由于这几...
  • ansys 定义变量(关联模型

    千次阅读 2018-06-06 14:25:33
    ug,proe,solidworks等模型转化后格式后(通常格式为stp,igs,iges,.x_t等)可以导入ansys中分析这是没问题的,但是在拓扑优化分析设定变量时,转化为通用格式导入ansys的模型不能识别变量。 ...
  • IFC文件几何模型

    万次阅读 多人点赞 2018-06-04 09:03:43
    简单IFC文件的基本结构包括: (1)项目的基本内容,主要 ... #1021表示构成模型的三角形网格的集合,每个三角网格由个坐标点形成的线段构成,坐标点通过索引#1022。  #1022表示点的有序集合。  
  • 数据数仓的三种建模方式

    千次阅读 2020-08-20 18:28:21
    不同的行业,有不同行业的特点,因此,从业务角度看,其相应的数据模型是千差万别的。目前业界较为主流的是数据仓库厂商主要是 IBM 和 NCR,这两家公司的除了能够提供较为强大的数据仓库平台之外,也有各自的针对...
  • 本节简单回归一下时间序列任务的几方向以及有哪些比较优秀的开源算法。1 时序预测时序预测从不同角度看有不同分类。从实现原理的角度,可以分为传统统计学、机器学习(又分非深度学习和深度学习)...
  • 【数学建模】灰色预测模型(预测)

    万次阅读 多人点赞 2020-08-02 16:43:07
    GM(1,1)模型推导精度检验精度检验等级参照表二、适用问题、算法总结1. 步骤四、应用场景举例1. 累加生成2. 建立GM(1,1)模型3. 检验预测值五、MATLAB代码六、实际案例七、论文案例片段(待完善) 灰色预测...
  •  基本映射是对一个实体进行映射,关联映射就是处理多个实体之间的关系,将关联关系映射到数据库中,所谓的关联关系在对象模型中有一个或多个引用。   分类      关联关系分为上述七,但是...
  • 航迹关联--目标跟踪

    千次阅读 2020-09-06 16:36:33
    在这种滤波方法中,仅将在统计意义上与被跟踪目标预测位置最近的量测作为与目标关联的回波信号。而事实上,与被跟踪目标预测位置最近的量测值并不一定来源于被跟踪目标,特别当滤波器工作在干扰密集的环境中的情况下...
  • 在理论上,LP技术得到进一步发展,动态时间归正技术(DTW)基本成熟,特别是提出了矢量量化(VQ)和隐马尔可夫模型(HMM)理论。在实践上,实现了基于线性预测倒谱和DTW技术的特定人孤立语音识别系统。80年代,语音...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 140,903
精华内容 56,361
关键字:

关联速度的三种模型