精华内容
下载资源
问答
  • Logstash概念原理、与Flume的对比

    万次阅读 多人点赞 2019-07-01 20:59:44
    Logstash概念 Logstash是一款开源的数据收集引擎,具备实时管道处理能力。简单来说,logstash作为数据源与数据存储分析工具之间的桥梁,结合ElasticSearch以及Kibana,能够极大方便数据的处理与分析。通过200多个...

    Logstash概念

    Logstash是一款开源的数据收集引擎,具备实时管道处理能力。简单来说,logstash作为数据源与数据存储分析工具之间的桥梁,结合ElasticSearch以及Kibana,能够极大方便数据的处理与分析。通过200多个插件,logstash可以接受几乎各种各样的数据。包括日志、网络请求、关系型数据库、传感器或物联网等等。

    Logstash工作过程

    在这里插入图片描述

    如上图,Logstash的数据处理过程主要包括:Inputs,Filters,Outputs 三部分,另外在Inputs和Outputs中可以使用Codecs对数据格式进行处理。这四个部分均以插件形式存在,用户通过定义pipeline配置文件,设置需要使用的input,filter,output,codec插件,以实现特定的数据采集,数据处理,数据输出等功能 。

    1. Inputs:用于从数据源获取数据,常见的插件如file, syslog, redis, beats 等
    2. Filters:用于处理数据如格式转换,数据派生等,常见的插件如grok, mutate, drop, clone, geoip等
    3. Outputs:用于数据输出,常见的插件如elastcisearch,file, graphite, statsd等
    4. Codecs:Codecs(编码插件)不是一个单独的流程,而是在输入和输出等插件中用于数据转换的模块,用于对数据进行编码处理,常见的插件如json,multiline。Logstash不只是一个input | filter | output 的数据流,而是一个 input | decode | filter | encode | output 的数据流!codec 就是用来 decode、encode 事件的。

    Logstash简单实践

    我们使用Logstash输出一个 “hello world” 。在终端中,像下面这样运行命令来启动 Logstash 进程:

     # bin/logstash -e 'input{stdin{}}output{stdout{codec=>rubydebug}}'
    

    以上命令表示从控制台输入,然后通过Codec插件从控制台输出。然后终端在等待你的输入。敲入 Hello World,回车,查看结果:

    {
    	"@version" => "1",
    	"host" => "sdn-253",
    	"message" => "Hello World",
    	"@timestamp" => 2019-07-01T12:28:07.207Z
    }
    

    Logstash 就像管道符一样!你输入(就像命令行的 cat )数据,然后处理过滤(就像 awk 或者 uniq之类)数据,最后输出(就像 tee )到其他地方。数据在线程之间以 事件 的形式流传。Logstash会给事件添加一些额外信息。最重要的就是 @timestamp,用来标记事件的发生时间。 大多数时候,还可以见到另外几个:

    • host 标记事件发生在哪里。
    • type 标记事件的唯一类型。
    • tags 标记事件的某方面属性。这是一个数组,一个事件可以有多个标签。
      你可以随意给事件添加字段或者从事件里删除字段。

    小贴士:每个 logstash 过滤插件,都会有四个方法叫 add_tag, remove_tag, add_field 和remove_field。它们在插件过滤匹配成功时生效。

    Logstash配置语法

    数据类型

    Logstash 支持少量的数据值类型:
    bool

    debug => true
    

    string

    host => "hostname"
    

    number

    port => 514
    

    array

    match => ["datetime", "UNIX", "ISO8601"]
    

    hash

    options => {
        key1 => "value1",
        key2 => "value2"
    }
    

    条件判断

    表达式支持下面这些操作符:
    相等: ==, !=, <, >, <=, >=
    正则: =~(匹配正则), !~(不匹配正则)
    包含: in(包含), not in(不包含)
    布尔操作: and(与), or(或), nand(非与), xor(非或)
    一元运算符:!(取反) ,()(复合表达式), !()(对复合表达式结果取反)
    通常来说,你都会在表达式里用到字段引用。比如:

    if "_grokparsefailure" not in [tags] {
    	...
    } else if [status] !~ /^2\d\d/ and [url] == "/noc.gif" {
    	...
    } else {
    	...
    }
    

    Logstash插件

    logstash插件功能很强大,下面会根据每个模块的情况,对常用插件进行分析。

    Input模块

    标准输入

    我们已经使用 stdin 输入Hello World了。这也应该是 logstash 里最简单和基础的插件了。 input { stdin { } }表示从控制台输入

    File插件

    从文件读取数据,如常见的日志文件。文件读取通常要解决几个问题:
    在这里插入图片描述
    logstash-input-file配置:
    在这里插入图片描述

    其中path匹配规则如下,路径必须使用绝对路径,不支持相对路径:
    /var/log/.log:匹配/var/log目录下以.log结尾的所有文件
    /var/log/**/
    .log:匹配/var/log所有子目录下以.log结尾的文件
    /var/log/{app1,app2,app3}/*.log:匹配/var/log目录下app1,app2,app3子目录中以.log结尾的文件

    file插件作为input例子如下:

    input {
        # file为常用文件插件,插件内选项很多,可根据需求自行判断
        file {
    	   # 要导入的文件的位置,可以使用*,例如/var/log/nginx/*.log
            path => "/var/lib/mysql/slow.log"
            # 要排除的文件
            exclude =>”*.gz”
            # 从文件开始的位置开始读,end表示从结尾开始读
            start_position => "beginning"
            # 多久之内没修改过的文件不读取,0为无限制,单位为秒
            ignore_older => 0  
            # 记录文件上次读取位置,输出到null表示每次都从文件首行开始解析
            sincedb_path => "/dev/null"
            # type字段,可表明导入的日志类型
            type => "mysql-slow"
        }
    }
    

    Http插件

    input {
    	http { port => 端口号 }
    }
    

    Redis插件

    input {
        # redis插件为常用插件,插件内选项很多,可根据需求自行判断
        redis {
            # EVAL命令返回的事件数目,设置为5表示一次请求返回5条日志信息
    	   batch_count => 1 
            # logstash redis插件工作方式
            data_type => "list" 
            # 监听的键值
            key => "logstash-test-list" 
            # redis地址
            host => "127.0.0.1" 
            # redis端口号
            port => 6379 
            # 如果有安全认证,此项为认证密码
            password => "123qwe" 
            # 如果应用使用了不同的数据库,此为redis数据库的编号,默认为0。
            db => 0 
            # 启用线程数量
            threads => 1
          }
    }
    

    Filter模块

    Filter是Logstash功能强大的主要原因,它可以对Logstash Event进行丰富的处理,比如解析数据、删除字段、类型转换等等,常见的有如下几个:
    在这里插入图片描述

    Date插件

    date插件可以将日期字符串解析为日期类型,然后替换@timestamp字段或者指定其他字段:

    filter{
    	date {
    	    match => ["timestamp","dd/MMM/yyyy:HH:mm:ss Z"] 
             # 记录@timestamp时间,可以设置日志中自定的时间字段,如果日志中没有时间字段,也可以自己生成
             target=>“@timestamp”
             # 将匹配的timestamp字段放在指定的字段 默认是@timestamp
        }
    }
    

    Grok插件

    grok是filter最重要的插件,grok使用正则表达式来生成grok语法,grok支持许多默认的正则表达式规则,grok中常用patterns的配置路径:

    [logstash安装路径]\vendor\bundle\jruby\x.x\gems\logstash-patterns-core-x.x.x\patterns\grok-patterns
    

    grok语法

    %{SYNTAX:SEMANTIC}
    

    SYNTAX为grok pattern的名称,SEMANTIC为赋值字段名称。%{NUMBER:duration}可以匹配数值类型,但是grok匹配出的内容都是字符串类型,可以通过在最后指定为int或者float来强转类型:%{NUMBER:duration:int}

    自定义正则表达式
    例如,如下定义一个关键字为version的参数,内容为两位的数字。

    (?<version>[0-9]{2})
    

    自定义grok pattern
    我们通过pattern_definitions参数,以键值对的方式定义pattern名称和内容。也可以通过pattern_dir参数,以文件的形式读取pattern。

    filter {
    	grok {
    		match => {
    			"message" => "%{SERVICE:service}"
    		}
    		pattern_definitions => {
    			"SERVICE" => "[a-z0-9]{10,11}"
    		}
    	}
    }
    

    Dissect插件

    基于分隔符原理解析数据,解决grok解析时消耗过多cpu资源的问题。dissect语法简单,能处理的场景比较有限。它只能处理格式相似,且有分隔符的字符串。它的语法如下:

    1、%{}里面是字段
    2、两个%{}之间是分隔符。

    例如,有以下日志:

    Apr 26 12:20:02 localhost systemd[1]: Starting system activity accounting tool
    

    我想要把前面的日期和时间解析到同一个字段中,那么就可以这样来做:

    filter {
        dissect {
            mapping => {
            	"message" => "%{ts} %{+ts} %{+ts} %{src} %{prog}[%{pid}]: %{msg}"
            }
        }
    }
    

    Mutate插件

    mutate是使用最频繁的插件,可以对字段进行各种操作,比如重命名、删除、替换、更新等,主要操作如下:

    1、convert类型转换
    2、gsub字符串替换
    3、split、join、merge字符串切割、数组合并为字符串、数组合并为数组
    4、rename字段重命名
    5、update、replace字段内容更新或替换。它们都可以更新字段的内容,区别在于update只在字段存在时生效,而replace在字段不存在时会执行新增字段的操作
    6、remove_field删除字段

    Json插件

    将字段内容为json格式的数据解析出来,如果不指定target的话,那么filter会把解析出来的json数据直接放到根级别。配置实例如下:

    filter {
    	json {
    		source => "message"
    		target => "msg_json"
    	}
    }
    

    运行结果:

    {
        "@version": "1",
        "@timestamp": "2014-11-18T08:11:33.000Z",
        "host": "web121.mweibo.tc.sinanode.com",
        "message": "{\"uid\":3081609001,\"type\":\"signal\"}",
        "jsoncontent": {
            "uid": 3081609001,
            "type": "signal"
        }
    }
    

    Geoip插件

    GeoIP 库可以根据 IP 地址提供对应的地域信息,包括国别,省市,经纬度等,对于可视化地图和区域统计非常有用。语法如下:

    filter {
    	geoip {
    		source => "message"
    	}
    }
    

    运行结果:

    {
           "message" => "183.60.92.253",
          "@version" => "1",
        "@timestamp" => "2014-08-07T10:32:55.610Z",
              "host" => "raochenlindeMacBook-Air.local",
             "geoip" => {
                          "ip" => "183.60.92.253",
               "country_code2" => "CN",
               "country_code3" => "CHN",
                "country_name" => "China",
              "continent_code" => "AS",
                 "region_name" => "30",
                   "city_name" => "Guangzhou",
                    "latitude" => 23.11670000000001,
                   "longitude" => 113.25,
                    "timezone" => "Asia/Chongqing",
            "real_region_name" => "Guangdong",
                    "location" => [
                [0] 113.25,
                [1] 23.11670000000001
            ]
        }
    }
    

    Output模块

    标准输出

    标准输出多用于调试,配置示例:

    output {
        stdout {
            codec => rubydebug
        }
    }
    

    redis插件

    output {
         redis{  # 输出到redis的插件,下面选项根据需求使用
             batch => true
             # 设为false,一次rpush,发一条数据,true为发送一批
             batch_events => 50
             # 一次rpush发送多少数据
             batch_timeout => 5
             # 一次rpush消耗多少时间
             codec => plain
             # 对输出数据进行codec,避免使用logstash的separate filter
             congestion_interval => 1
             # 多长时间进项一次拥塞检查
             congestion_threshold => 5
             # 限制一个list中可以存在多少个item,当数量足够时,就会阻塞直到有其他消费者消费list中的数据
             data_type => list
             # 使用list还是publish
             db => 0
             # 使用redis的那个数据库,默认为0号
             host => ["127.0.0.1:6379"]
             # redis 的地址和端口,会覆盖全局端口
             key => xxx
             # list或channel的名字
             password => xxx
             # redis的密码,默认不使用
             port => 6379
             # 全局端口,默认6379,如果host已指定,本条失效
             reconnect_interval => 1
             # 失败重连的间隔,默认为1s
             timeout => 5
             # 连接超时的时间
             workers => 1
             # 工作进程
         }
    }
    

    elasticsearch插件

    output {
        # stdout { codec => "rubydebug" }
        # 筛选过滤后的内容输出到终端显示
        elasticsearch {  # 导出到es,最常用的插件
            codec => "json"
            # 导出格式为json
            hosts => ["127.0.0.1:9200"]
            # ES地址+端口
            index => "logstash-slow-%{+YYYY.MM.dd}"
            # 导出到index内,可以使用时间变量
            user => "admin"
            password => "xxxxxx"
            # ES如果有安全认证就使用账号密码验证,无安全认证就不需要
            flush_size => 500
            # 默认500,logstash一次性攒够500条的数据在向es发送
            idle_flush_time => 1
            # 默认1s,如果1s内没攒够500,还是会一次性把数据发给ES
        }   
    }
    

    Logstash配置实例

    logstash配置的时候,input和output都可以配置多个不同的入参。filter可以针对input里面的每个数据源做不一样的过滤,通过各自定义的type来匹配。配置示例如下:

    input{
          kafka{
            bootstrap_servers => ["192.168.110.31:9092,192.168.110.31:9093,192.168.110.31:9094"]
            client_id => "test"
            group_id => "test"
            auto_offset_reset => "latest" //从最新的偏移量开始消费
            consumer_threads => 5
            decorate_events => true //此属性会将当前topic、offset、group、partition等信息也带到message中
            topics => ["logq","loge"] //数组类型,可配置多个topic
            type => "bhy" //所有插件通用属性,尤其在input里面配置多个数据源时很有用
          }
    	file {
    	   # 要导入的文件的位置,可以使用*,例如/var/log/nginx/*.log
            path => "/var/lib/mysql/slow.log"
            # 记录文件上次读取位置,输出到null表示每次都从文件首行开始解析
            sincedb_path => "/dev/null"
            # type字段,可表明导入的日志类型
            type => "mysql-slow"
        }
    }
    filter{
            if[type] == "bhy"{
                grok{
                   ........
                }
            }
            if[type] == "mysql-slow"{
                mutate{
                   ........
                }
            }
    }
    output {
            if[type] == "bhy"{
              elasticsearch{
                   hosts => ["192.168.110.31:9200"]
                   index => "school"
                   timeout => 300
                   user => "elastic"
                   password => "changeme"
              }
    
            }
            if[type] == "mysql-slow"{
                ........
            }
     }
    

    1、针对如下类型的log:

    Apr 26 12:20:02 localhost systemd[1]: Starting system activity accounting tool
    

    logstash的配置如下:

    input {
        file {
            path => "/home/songfeihu/logstash-6.2.3/config/test.log"
            # 要导入的文件的位置,可以使用*,例如/var/log/nginx/*.log
            start_position => "beginning"
            # 从文件开始的位置开始读,end表示从结尾开始读
            ignore_older => 0
            # 多久之内没修改过的文件不读取,0为无限制,单位为秒
            sincedb_path => "/dev/null"
            # 记录文件上次读取位置,输出到null表示每次都从文件首行开始解析
        }
    }
    filter {
            dissect {
                    mapping => {
                            "message" => "%{ts} %{+ts} %{+ts} %{src} %{prog}[%{pid}]: %{msg}"
                    }
            }
            if "Starting" in [msg]{
                    grok{
                            match => {"msg" => "(?<test1>[a-zA-Z0-9]+).*"}
                    }
            }
           mutate {
                   remove_field => ["message"]
           }
    }
    output {
    	stdout{codec=>rubydebug}
    }
    

    output返回值:

    {
              "host" => "sdn-253",
          "@version" => "1",
        "@timestamp" => 2019-06-28T08:08:58.062Z,
               "msg" => "Starting system activity accounting tool",
             "test1" => "Starting",
                "ts" => "Apr 26 12:20:02",
              "path" => "/home/songfeihu/logstash-6.2.3/config/test.log",
               "src" => "localhost",
              "prog" => "systemd",
               "pid" => "1",
           "message" => "Apr 26 12:20:02 localhost systemd[1]: Starting system activity accounting tool"
    }
    

    2、针对如下log:

    <188>Mar 29 2019 16:57:30 BJQ-219-A1-ITCloud-FW-E8000E-1 %%01SEC/4/POLICYPERMIT(l)[1976979]:VSYS=public;
    

    logstash配置如下:

    input {
        stdin {    }
    }
    filter {
        grok {
            match => {
    	"message" => "\<(?<id>[0-9]+)\>(?<timestamp>([a-zA-Z]+)\s[0-9]{1,2}\s[0-9]{1,4}\s[0-9]{1,2}:[0-9]{1,2}:[0-9]{1,2})\s%{HOSTNAME:hostname} \%\%(?<version>[0-9]{2})(?<model>[a-zA-Z0-9]+)\/(?<severity>[0-9])\/(?<brief>[a-zA-Z0-9]+)\S+:(?<description>.*)"
    	}
        }
    }
    output {
    stdout{codec=>rubydebug}
    }
    

    output输出如下:

    {
               "host" => "sdn-253",
                 "id" => "188",
          "timestamp" => "Mar 29 2019 16:57:30",
           "hostname" => "BJQ-219-A1-ITCloud-FW-E8000E-1",
              "brief" => "POLICYPERMIT",
         "@timestamp" => 2019-06-28T09:54:01.987Z,
           "severity" => "4",
           "@version" => "1",
            "version" => "01",
              "model" => "SEC",
            "message" => "<188>Mar 29 2019 16:57:30 BJQ-219-A1-ITCloud-FW-E8000E-1 %%01SEC/4/POLICYPERMIT(l)[1976979]:VSYS=public;",
        "description" => "VSYS=public;"
    }
    

    Flume

    Apache Flume是Cloudera提供的一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统,Flume支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。Flume有两个版本,分别是Flume OG和Flume NG,目前用的都是FlumeNG。
    Flume具有高可用,分布式,配置工具,其设计的原理也是基于将数据流,如日志数据从各种网站服务器上汇集起来存储到HDFS,HBase等集中存储器中。

    Flume的外部结构

    在这里插入图片描述

    如上图所示,数据发生器(如:facebook,twitter)产生的数据被服务器上的agent所收集,之后数据收容器从各个agent上汇集数据并将采集到的数据存入到HDFS或者HBase中。

    Flume事件

    事件作为Flume内部数据传输的最基本单元.它是由一个转载数据的字节数组(该数据组是从数据源接入点传入,并传输给传输器,也就是HDFS/HBase)和一个可选头部构成。
    典型的Flume 事件如下面结构所示:

    在这里插入图片描述

    Flume agent

    对于每一个Agent来说,它就是一共独立的守护进程(JVM),它从客户端哪儿接收收集,或者从其他的Agent哪儿接收,然后迅速的将获取的数据传给下一个目的节点sink,或者agent. 如下图所示flume的基本模型:

    在这里插入图片描述
    Source

    从数据发生器接收数据,并将接收的数据以Flume的event格式传递给一个或者多个通道channal,Flume提供多种数据接收的方式,比如Avro,Thrift,twitter1%等。

    Channel

    channal是一种短暂的存储容器,它将从source处接收到的event格式的数据缓存起来,直到它们被sinks消费掉,它在source和sink间起着一共桥梁的作用,channal是一个完整的事务,这一点保证了数据在收发的时候的一致性.并且它可以和任意数量的source和sink链接. 支持的类型有: JDBC channel , File System channel ,Memort channel等.

    Sink

    sink将数据存储到集中存储器比如Hbase和HDFS,它从channals消费数据(events)并将其传递给目标地.目标地可能是另一个sink,也可能HDFS,HBase。当Sink写出event成功后,就会向Channel提交事务。Sink事务提交成功,处理完成的event将会被Channel删除。否则Channel会等待Sink重新消费处理失败的event。

    Interceptor

    拦截器是简单的插件式组件,设置在source和channel之间。source接收到的事件event,在写入channel之前,拦截器都可以进行转换或者删除这些事件。每个拦截器只处理同一个source接收到的事件。可以自定义拦截器。预定义的拦截器包含时间戳拦截器TimestampInterceptor、主机拦截器HostInterceptor、静态拦截器StaticInterceptor、正则过滤拦截器RegexExtractorInterceptor,通过使用不同的拦截器,实现不同的功能。
    但是以上的这些拦截器,不能改变原有日志数据的内容或者对日志信息添加一定的处理逻辑,当一条日志信息有几十个甚至上百个字段的时候,在传统的Flume处理下,收集到的日志还是会有对应这么多的字段,也不能对你想要的字段进行对应的处理。根据实际业务的需求,为了更好的满足数据在应用层的处理,通过自定义Flume拦截器,过滤掉不需要的字段,并对指定字段加密处理,将源数据进行预处理。减少了数据的传输量,降低了存储的开销。

    在这里插入图片描述

    Logstash和Flume对比

    1、Logstash比较偏重于字段的预处理,在异常情况下可能会出现数据丢失,只是在运维日志场景下,一般认为这个可能不重要;而Flume偏重数据的传输,几乎没有数据的预处理,仅仅是数据的产生,封装成event然后传输;传输的时候flume比logstash多考虑了一些可靠性。因为数据会持久化在channel中,数据只有存储在下一个存储位置(可能是最终的存储位置,如HDFS;也可能是下一个Flume节点的channel),数据才会从当前的channel中删除。这个过程是通过事务来控制的,这样就保证了数据的可靠性。
    2、Logstash有几十个插件,配置比较灵活,flume强调用户自定义开发;
    3、Logstash的input和filter还有output之间都存在buffer,进行缓冲;Flume直接使用channel做持久化
    4、Logstash性能以及资源消耗比较严重,且不支持缓存;

    在这里插入图片描述

    参考

    ELK logstash 配置语法(24th)
    ELK 之 Logstash
    使用logstash的logstash-input-kafka插件读取kafka中的数据
    logstash过滤器filter grok多种日志匹配使用心得
    一文快速上手Logstash
    logstash的各个场景应用(配置文件均已实践过)
    Logstash配置详解(不断更新)
    Logstash 最佳实践
    Logstash的介绍、原理、优缺点、使用、持久化到磁盘、性能测试
    数据采集:Flume和Logstash的工作原理和应用场景
    Flume日志采集系统与Logstash对比
    Flume概念与原理、与Kafka优势对比
    Flume构建日志采集系统
    大数据学习——flume拦截器
    日志采集系统flume和kafka有什么区别及联系,它们分别在什么时候使用,什么时候又可以结合?

    展开全文
  • Flume概念原理、与Kafka优势对比

    万次阅读 多人点赞 2018-03-27 11:30:15
    flume具有高可用,分布式,配置工具,其设计的原理也是基于将数据流,如日志数据从各种网站服务器上汇集起来存储到HDFS,HBase等集中存储器中。其结构如下图所示:    2.应用场景  比如我们在做一个电子商务网站...

    1 .背景

          flume是由cloudera软件公司产出的可分布式日志收集系统,后与2009年被捐赠了apache软件基金会,为hadoop相关组件之一。尤其近几年随着flume的不断被完善以及升级版本的逐一推出,特别是flume-ng;同时flume内部的各种组件不断丰富,用户在开发的过程中使用的便利性得到很大的改善,现已成为apache top项目之一.

    2 .概述

       1.  什么是flume?

           apache Flume 是一个从可以收集例如日志,事件等数据资源,并将这些数量庞大的数据从各项数据资源中集中起来存储的工具/服务,或者数集中机制。flume具有高可用,分布式,配置工具,其设计的原理也是基于将数据流,如日志数据从各种网站服务器上汇集起来存储到HDFS,HBase等集中存储器中。其结构如下图所示:

          

      2.应用场景

          比如我们在做一个电子商务网站,然后我们想从消费用户中访问点特定的节点区域来分析消费者的行为或者购买意图. 这样我们就可以更加快速的将他想要的推送到界面上,实现这一点,我们需要将获取到的她访问的页面以及点击的产品数据等日志数据信息收集并移交给Hadoop平台上去分析.而Flume正是帮我们做到这一点。现在流行的内容推送,比如广告定点投放以及新闻私人定制也是基于次,不过不一定是使用FLume,毕竟优秀的产品很多,比如facebook的Scribe,还有Apache新出的另一个明星项目chukwa,还有淘宝Time Tunnel。

    3.Flume的优势

          1.  Flume可以将应用产生的数据存储到任何集中存储器中,比如HDFS,HBase

          2.  当收集数据的速度超过将写入数据的时候,也就是当收集信息遇到峰值时,这时候收集的信息非常大,甚至超过了系统的写入数据能力,这时候,Flume会在数据生产者和数据收容器间做出调整,保证其能够在两者之间提供一共平稳的数据.

         3.   提供上下文路由特征

         4.   Flume的管道是基于事务,保证了数据在传送和接收时的一致性.

         5.   Flume是可靠的,容错性高的,可升级的,易管理的,并且可定制的。 

    4. Flume具有的特征:

        1. Flume可以高效率的将多个网站服务器中收集的日志信息存入HDFS/HBase中

        2. 使用Flume,我们可以将从多个服务器中获取的数据迅速的移交给Hadoop中

        3. 除了日志信息,Flume同时也可以用来接入收集规模宏大的社交网络节点事件数据,比如facebook,twitter,电商网站如亚马逊,flipkart等

        4. 支持各种接入资源数据的类型以及接出数据类型

        5. 支持多路径流量,多管道接入流量,多管道接出流量,上下文路由等

        6. 可以被水平扩展

     3. Flume的结构

        1. flume的外部结构:

     

        

         如上图所示,数据发生器(如:facebook,twitter)产生的数据被被单个的运行在数据发生器所在服务器上的agent所收集,之后数据收容器从各个agent上汇集数据并将采集到的数据存入到HDFS或者HBase中

     2. Flume 事件

      事件作为Flume内部数据传输的最基本单元.它是由一个转载数据的字节数组(该数据组是从数据源接入点传入,并传输给传输器,也就是HDFS/HBase)和一个可选头部构成.

    典型的Flume 事件如下面结构所示:

    我们在将event在私人定制插件时比如:flume-hbase-sink插件是,获取的就是event然后对其解析,并依据情况做过滤等,然后在传输给HBase或者HDFS.

    3.Flume Agent

      我们在了解了Flume的外部结构之后,知道了Flume内部有一个或者多个Agent,然而对于每一个Agent来说,它就是一共独立的守护进程(JVM),它从客户端哪儿接收收集,或者从其他的 Agent哪儿接收,然后迅速的将获取的数据传给下一个目的节点sink,或者agent. 如下图所示flume的基本模型

    Agent主要由:source,channel,sink三个组件组成.

    Source:

       从数据发生器接收数据,并将接收的数据以Flume的event格式传递给一个或者多个通道channal,Flume提供多种数据接收的方式,比如Avro,Thrift,twitter1%等

    Channel:

     channal是一种短暂的存储容器,它将从source处接收到的event格式的数据缓存起来,直到它们被sinks消费掉,它在source和sink间起着一共桥梁的作用,channal是一个完整的事务,这一点保证了数据在收发的时候的一致性. 并且它可以和任意数量的source和sink链接. 支持的类型有: JDBC channel , File System channel , Memort channel等.

    sink:

      sink将数据存储到集中存储器比如Hbase和HDFS,它从channals消费数据(events)并将其传递给目标地. 目标地可能是另一个sink,也可能HDFS,HBase.

    它的组合形式举例:

    以上介绍的flume的主要组件,下面介绍一下Flume插件:

    1. Interceptors拦截器

       用于source和channel之间,用来更改或者检查Flume的events数据

    2. 管道选择器 channels Selectors

       在多管道是被用来选择使用那一条管道来传递数据(events). 管道选择器又分为如下两种:

       默认管道选择器:  每一个管道传递的都是相同的events

      多路复用通道选择器:  依据每一个event的头部header的地址选择管道.

    3.sink线程

       用于激活被选择的sinks群中特定的sink,用于负载均衡.
    4.Flume与Kafka对比

    1. kafka和flume都是日志系统,kafka是分布式消息中间件,自带存储,提供push和pull存取数据功能。flume分为agent(数据采集器),collector(数据简单处理和写入),storage(存储器)三部分,每一部分都是可以定制的。比如agent采用RPC(Thrift-RPC)、text(文件)等,storage指定用hdfs做。
    2. kafka做日志缓存应该是更为合适的,但是 flume的数据采集部分做的很好,可以定制很多数据源,减少开发量。所以比较流行flume+kafka模式,如果为了利用flume写hdfs的能力,也可以采用kafka+flume的方式。


    采集层 主要可以使用Flume, Kafka两种技术。

    FlumeFlume 是管道流方式,提供了很多的默认实现,让用户通过参数部署,及扩展API.

    KafkaKafka是一个可持久化的分布式的消息队列。

    • Kafka 是一个非常通用的系统。你可以有许多生产者和很多的消费者共享多个主题Topics。相比之下,Flume是一个专用工具被设计为旨在往HDFS,HBase发送数据。它对HDFS有特殊的优化,并且集成了Hadoop的安全特性。所以,Cloudera 建议如果数据被多个系统消费的话,使用kafka;如果数据被设计给Hadoop使用,使用Flume

     

    • 正如你们所知Flume内置很多的sourcesink组件。然而,Kafka明显有一个更小的生产消费者生态系统,并且Kafka的社区支持不好。希望将来这种情况会得到改善,但是目前:使用Kafka意味着你准备好了编写你自己的生产者和消费者代码。如果已经存在的Flume SourcesSinks满足你的需求,并且你更喜欢不需要任何开发的系统,请使用Flume

     

    • Flume可以使用拦截器实时处理数据。这些对数据屏蔽或者过量是很有用的。Kafka需要外部的流处理系统才能做到。

     

    • KafkaFlume都是可靠的系统,通过适当的配置能保证零数据丢失。然而,Flume不支持副本事件。于是,如果Flume代理的一个节点崩溃了,即使使用了可靠的文件管道方式,你也将丢失这些事件直到你恢复这些磁盘。如果你需要一个高可靠行的管道,那么使用Kafka是个更好的选择。

     

    • FlumeKafka可以很好地结合起来使用。如果你的设计需要从KafkaHadoop的流数据,使用Flume代理并配置KafkaSource读取数据也是可行的:你没有必要实现自己的消费者。你可以直接利用FlumeHDFSHBase的结合的所有好处。你可以使用Cloudera Manager对消费者的监控,并且你甚至可以添加拦截器进行一些流处理。

    FlumeKafka可以结合起来使用。通常会使用Flume + Kafka的方式。其实如果为了利用Flume已有的写HDFS功能,也可以使用Kafka + Flume的方式。

    ----------------------------------------------------<END>-------------------------------------------------------


    展开全文
  • 【Kubernetes】浅析基本概念原理

    万次阅读 2021-05-30 12:44:12
    摘要:本文从 Kubernetes (K8S) 的几个核心概念入手,对 K8S 的整体架构设计进行了概括性分析,进而对 K8S 的认证、授权、准入控制的相关内容进行了介绍。 1 核心概念和架构设计 1.1 概念与层级关系 Image 镜像的...

    摘要:本文从 Kubernetes (K8S) 的几个核心概念入手,对 K8S 的整体架构设计进行了概括性分析,进而对 K8S 的认证、授权、准入控制的相关内容进行了介绍。

    1 核心概念和架构设计

    1.1 概念与层级关系

    Image 镜像的运行得到 Container 容器。

    Pod 内可以有一个或者多个容器,Pod 中的容器运行在一台机器上且共享网络,有一个唯一的 IP,每个 Pod 中会有一个 Pause 容器,Pause 容器作为根容器,将 Pod 中的其他容器连接在一起。Pod 会负责内部容器的健康检查,几个关系紧密的容器可以放在一个 Pod 中。

    ReplicaSet 是 Pod 的上级,是 K8S 中的一种副本控制器,负责多个 Pod 的管理。K8S 官方推荐不要直接使用 ReplicaSet,用 Deployment 取而代之。

    Deployment 是 ReplicaSet 的上级,负责 ReplicaSet 的创建和销毁,管理 ReplicaSet 并提供很多有用的特性,最重要的是 Deployment 支持声明式更新,声明式对比命令式更新的优势在于不会丢失历史变更,可以通过 Deployment 实现滚动部署。

    Service 可以使用 Selector 找到指定 label 的 Pod,Service 对外有一个 ClusterIP,客户端/其他服务可以通过 ClusterIP 访问到 Pod 服务。
    在这里插入图片描述
    1.2 架构设计

    K8S 使用主从架构,内部的节点分别主节点 Master 和从节点 Worker ,Master 负责管理 Worker 节点,K8S 使用 ETCD 做存储,用于节点和服务信息的管理,持久化地存储这些信息,保证数据不丢失,可以进行服务的恢复。

    服务 API Servser 接到客户端的请求后,调度器 Scheduler 会收集每一个 Worker 的详细信息(资源、内存、GPU、服务),根据预选策略或优选策略选择一个最优节点和 Pod 建立联系,告诉 API Server 该 Pod 可以运行在某个节点上,并将信息存放到 ETCD 中。

    Controller Manager 是集群控制中心,负责维护 K8S 对象,内部有 Service Controller 管理服务,Pod Controller 管理 Pod 列表,Replication Controller 管理副本,ResourceQuota 管理资源的配额。Controller Manager 通过 Api Server 获取 ETCD 中一些节点的变化(例如Pod和Node的绑定关系)

    每个 Worker 都有 Kubelet 服务,负责维护 Pod 的生命周期,管理容器的 Volume 和网络。 Kubelet 会调用本地的 Docker 去实现 Pod 中容器的运行。
    在这里插入图片描述
    2 K8S的认证和授权

    2.1 前置知识

    在 K8S 中,当客户端发起 API Server 调用时,API Server 会先认证 (Authentication) 用户,再给用户授权 (Authorization),最后执行准入控制 (Admission Control)

    • 认证:确认请求方是否合法
    • 授权:授予请求方 API 请求权限,并鉴别请求方访问的 API 请求是否合法
    • 准入控制:在认证和授权后补充额外的检查机制,用于做最后的拦截

    对称加密:双方都使用相同私钥进行加密和解密。性能损耗小。

    非对称加密:使用公钥对数据加密,使用私钥对数据解密。性能损耗大。

    组合加密:第一次通过公钥加密一个密钥,将密钥安全的传送到另一方,另一方通过私钥获得密钥,之后使用对称加密的密钥进行通信。

    组合加密的安全隐患:中间人截获公钥,发送一个伪造的公钥。可以通过CA验证公钥的真伪。

    2.2 认证

    客户端证书认证(TLS双向认证)

    Kubectl 在访问 API Server 的时候会验证 API Server 的真伪,API Server 会验证 Kubectl 是否是合法的客户端。

    首先 K8S 会通过 CA 判断和保证证书的合法性,K8S 使用的是自己的认证中心,CA 会给各个组件办法证书。组件间通信通过这个证书判断双方的合法性。

    Bearer Token认证

    Bearer Token认证是生成一个长串 Token ,并放入 Header 发起 HTTP 请求,API Server 依据 Token 识别用户,通过–token-auth-file=XXXXX加载所有用户 Token ,请求的时候 Header加上 Token即可,这种方式操作简单,但是需要重启 API Server才能更新,灵活性和安全性较弱。

    Service Account认证

    Service Account认证是 Pod 内部访问 API Server 的鉴权方式。

    Controller Manager 和 API Server 会利用 Server 端的私钥为每个 Pod 创建一个 Token,通过目录挂载的方式挂载在 Pod 的目录系统中,应用通过读取指定目录的文件获取到这些信息,拿到这些信息后就可以和 API Server 进行交互。

    2.3 授权

    Attribute-based access control (ABAC)

    通过使用将属性组合在一起的策略来向用户授予访问权限。可以通过–authorization-policy-file=SOME_FILENAME指定策略文件,策略文件是 JSON 格式的,每一行代表一个策略对象。

    当用户发送请求到 API Server 时,用户识别用户所拥有的权限策略信息,并与策略文件中的策略对象进行匹配,如果至少一行匹配成功,该请求就通过了授权。

    WebHook

    WebHook 是一种 HTTP 回调:某些条件下触发的 HTTP POST 请求;通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。

    当判断用户权限时,WebHook 模式会让 K8S 查询外部的 REST 服务。

    Role Based Access Control (RBAC)

    RBAC是K8S中比较推荐的授权方式,RBAC是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。RBAC 鉴权机制使用 rbac.authorization.k8s.io API 组 来驱动鉴权决定,允许通过 Kubernetes API 动态配置策略。要启用 RBAC,在启动API Server时设置 --authorization-mode=RBAC 。

    使用RBAC可以对集群资源和非资源权限都有完整的覆盖,可以通过kubectl或者api来操作,可以运行时调整,无需重启API Server

    RBAC包括四个资源对象:

    1. Role:一个角色就是一组权限的集合,拥有某个 namespace 下的权限
    2. ClusterRole:集群角色,拥有整个 cluster 下的权限。如果希望在名字空间内定义角色,应该使用 Role; 如果希望定义集群范围的角色,应该使用 ClusterRole。
    3. RoleBinding:将Role绑定目标 (user、group、service account),K8S 没有数据库,通过 RoleBinding 记录。
    4. ClusterRoleBinding:将ClusterRole绑定目标。

    2.4 准入控制

    经过认证和授权后,还需要经过多个准入控制器的审核,用户向 API Server 的请求才能成功得到相应。

    准入控制器包括:AlwaysAdmit(允许所有请求)、AlwaysDeny(禁止所有请求)、ServiceAccount(让ServiceAccount实现自动化)、DenyEscolatingExec(拦截所有exec和attach到特权pod上的请求)等。

    3 集群搭建方案

    社区方案:杂乱、不可靠、升级困难。

    Kubeadm:安装过程简单、支持高可用、升级方便、不易维护、文档简陋。

    Binary:易于维护,Binary通过进程直接运行,手动配置和运行,可以轻松的理解组件间调用关系。灵活性好、升级方便。没有文档、安装过程复杂。

    展开全文
  • 人脸支付技术原理和基本概念介绍

    千次阅读 2019-06-04 08:25:24
    2019-06-02 21:31:57 ...近日,支付宝蜻蜓、微信青蛙以及人行牵头银联和各商业银行推进落地的刷脸支付系统陆续开始推向市场,笔者近期分别对相关产业各方采用的技术原理和基本概念进行了一些学习和研...

    https://www.toutiao.com/a6697925553745297923/

     

    2019-06-02 21:31:57

    人脸支付技术原理和基本概念介绍

     

    从2015年,马云在德国展示人脸支付技术以来,经过几年发展,人脸支付已经开始走向商用。近日,支付宝蜻蜓、微信青蛙以及人行牵头银联和各商业银行推进落地的刷脸支付系统陆续开始推向市场,笔者近期分别对相关产业各方采用的技术原理和基本概念进行了一些学习和研究,在此做一下记录和分享。

    什么是人脸支付技术

    人脸支付技术是利用受理终端的人脸采集能力,通过人脸识别技术(1:1 or 1:N)获取持卡人支付账户信息,结合Token技术、PIN加密技术、大数据分析等形成的新型支付技术。人脸支付技术通常涉及两个方面,一方面是人脸支付受理终端,一方面是人脸支付受理平台。

    从人脸支付受理终端侧来看,主要涉及:人脸图像采集及检测技术、人脸图像预处理技术、活体检测等。从平台侧来看,主要涉及:人脸图像特征提取技术、人脸图像匹配与识别技术。

    人脸支付技术原理和基本概念介绍

     

    人脸支付技术中涉及的一些关键技术概念和原理

    从上述的几项技术中,我们需要首先了解下面的这些关键技术概念和原理。

    什么是双目摄像头

    人脸支付技术原理和基本概念介绍

     

    支付宝蜻蜓采用的摄像头

    我们通常使用的在手机上用于拍照的前置摄像头,都是普通的可见光VGA摄像头,也叫单目摄像头,所以单目摄像头一般需要通过动作配合、行为分析等模式实现活体检测。而双目摄像头是指设备上除了一个可见光VGA的摄像头外,还有另外一个或多个用于采集视觉的部件(如黑白摄像头、长焦/定焦摄像头、近红外摄像头、结构光组件、TOF组件等)。这也是我们看到在我们一些高端手机、支付宝蜻蜓和微信青蛙提供的摄像头中采用的一些技术。

    一般人脸识别中用到的是近红外摄像头、结构光组件、TOF组件等。具体的形式上可能有多个部件组成。双目摄像头通过采集物体的深度数据,与VGA摄像头采集的2D平面照片数据组合成物体的3D模型,所以又称之为3D摄像头。双目摄像头在满足基本人像信息采集的同时,还能提供快速(<1s)、高精度的活体检测能力,判断采集的物体是否是真人活体。

    为什么人脸支付首次需要输入手机号

    人脸支付技术原理和基本概念介绍

     

    这其实就是我们人脸识别中的一个经典问题,也就是1:1模式和1:N模式。1:1的模式是指用现场采集的某客户的图像与之前系统中留存的该客户图像直接进行对比,这样就需要用一个索引在后台留存的数据中先找到该客户的图像,比如手机号或者PIN等。而1:N的模式是指用现场采集的某客户的图像与在系统中留存的N个人照片里逐一比对,找到库里那个当前客户的图像,并且获得相应的关联信息,如捆绑的卡号或者支付账号,这就好比大海捞针,在茫茫人海中去找到这一张图像。在N的规模如果达到比较大的程度时(一般像微信支付宝后台都是亿级用户),识别的准确度会急剧下降,识别的效率也会大受影响。

    所以通常情况下,首次支付会采用手机号或者PIN作为图像的索引,采用1:1模式,快速索引出人脸,而在再次到店支付时,可以使用1:N模式,在本地不多的缓存客户图像中直接匹配,提高客户体验度。

    人脸支付应用于支付场景的特殊性

    这其实也是很多专家在评论人脸支付时谈到的问题,首先,人脸识别是一种相似度识别,跟采用的算法以及设定的阈值有很大关系,单纯靠人脸识别这一项技术是不能完全满足支付主体唯一性的要求的,所以势必还得添加其他辅助手段;其次,人脸特征一方面可以随身携带并且易于获取,本身就是一种非常好的支付载体,但是与传统的密码和卡不一样的是,人脸特征如果作为支付中的一个重要因素,一旦出现风险,无法进行作废、挂失、更换等操作。

    人脸支付的欺诈手段和防范措施

    欺诈手段-照片、视频、3D面具

    这方面技术从低到高,有照片、视频、3D面具。照片和视频都可以通过合法途径获取,比如可通过网上个人主页、微信朋友圈、街边偷拍等途径获得。而另据报道,日本有公司已经能生产3D打印面具,如下图所示。

    人脸支付技术原理和基本概念介绍

     

    防范措施-活体检测

    通常的防范措施就是采用活体检测技术,大家在日常生活中已经有所体验。简单来讲,跟进行活体检测的摄像头有关。如果是单目摄像头,一般采用指令动作配合的方式,如人脸左转、右转、张嘴、眨眼等,指令配合错误则认为是伪造欺骗,这种方式由于其负责性一般只能用于一些绑卡环节而不适用于支付环节。如果是双目摄像头,一般是利用双目摄像头得到的深度数据进行3D模型分析, 最终判断出这个人脸是来自活体还是非活体。采用这种方式对于2D攻击也就是照片和视频有较好的防范效果,但对于3D模型攻击,例如上面这种3D面具或者头套的防范效果还需要进一步优化。特别是对于精度较高的3D头套或蜡像的攻击,目前很难进行分辨。

    总结

    相信大家看了本文,对人脸支付技术原理和概念有了一个初步的认识和理解。后续我们将展开为大家分别来分享支付宝蜻蜓、微信青蛙以及银联系的人脸支付的具体方案。

    展开全文
  • Hbase原理、基本概念、基本架构

    万次阅读 多人点赞 2013-12-26 16:36:37
    Hbase基本概念 RowKey:是Byte array,是表中每条记录的“主键”,方便快速查找,Rowkey的设计非常重要。 Column Family:列族,拥有一个名称(string),包含一个或者多个相关列 Column:属于某一个columnfamily...
  • Elasticsearch最佳实践之核心概念原理

    万次阅读 多人点赞 2018-12-03 22:29:58
    作为专栏文章的第二篇,本文从数据组织、数据分布、集群角色、数据写入与存储结构多个方面对Elasticsearch的核心概念进行整理,尽可能由浅入深的交代清楚每个概念
  • 数据库系统原理概念整理(备考)

    千次阅读 2019-01-01 11:52:43
    基本概念 数据模型 描述数据的概念和工具 关系数据模型 用关系描述数据 数据模型 包含三个方面 结构 操作 约束 对应于 关系数据模型 关系(表) 关系代数 主外键约束,断言 逻辑数据模型:详尽的描述数据,不关心...
  • 虚拟DOM的实现原理和优劣对比

    千次阅读 2019-12-24 17:28:39
    虚拟DOM的实现原理和优劣对比
  • 数据库原理的基本概念

    千次阅读 多人点赞 2020-02-28 18:16:02
    数据库原理这门课已经学了一周多了,基础概念知识比较多,也比较杂,下面整理一下,也算是增加一点记忆。 ** 数据库的四个基本概念 ** 数据(Data):数据是描述事物的符号记录,数字,文字,图像,音频,视频,学生...
  • Spring和SpringBoot的对比概念

    千次阅读 2019-09-01 11:03:37
    1.首先说一下Sprig的优缺点分析: 优点: Spring是Java企业版(Java Enterprise Edition,JEE,也称为J2EE)的轻量替代品。不需要开发重量级的Enterprise ...后面会写一下对起步依赖和自动配置的原理做一下剖析。
  • 常见加密算法原理概念

    千次阅读 2018-12-22 16:20:17
    一、概述 在安全领域,利用密钥加密算法来对通信的过程进行加密是一种常见的安全手段。利用该手段能够保障数据安全通信的三个目标: 1、数据的保密性,防止...下面我们来了解下相关的算法原理及其常见的算法。...
  • 文章目录TCP协议和UDP协议的对比?TCP协议的优点:TCP协议的缺点:各种攻击的名词解释阻塞调用和同步调用的区别?关于同步异步I/O 和 阻塞非阻塞I/O 更深刻的理解http与https的区别?session与cookie的对比?输入一个...
  • (若干细节不清,只能说从概念上大致如此,请原谅)。各种相关的软件都是如此,例如TeamViewer、Oray向日葵乃至QQ远程协助等。就说这个ngrok,其实也是需要通讯双方连接ngrok中心服务器,甚至中心服务器的某些高级...
  • 我们在上篇文章已经对比了不同的存储系统之间的区别,本章开始逐步深入记录Ceph的学习和运用。 开源分布式存储系统的对比 Ceph简介 Ceph是一个分布式存储系统,提供对象,块和文件存储,是一个免费开源软件的存储...
  • Android 三大图片缓存原理、特性对比

    千次阅读 2016-09-13 15:43:48
    Android 三大图片缓存原理、特性对比
  • CMOS工作原理概念

    千次阅读 2019-05-05 16:55:12
    而讨论清楚的概念原理会从正在讨论的原理概念中移到有定论的概念原理中,作为继续讨论的出发点。 在待探讨的概念原理中,有一些是我认为有问题或存在歧义的观点,还有一些是我根据有定论的概念原理推理...
  • storm简介、原理概念

    万次阅读 多人点赞 2018-09-05 11:35:22
    5.storm工作原理  Nimbus 负责在集群分发的代码, topo 只能在 nimbus 机器上提交,将任务分配给其他机器,和故障监测。  Supervisor,监听分配给它的节点,根据Nimbus 的委派在必要时启动和关闭工作进程...
  • 01.MongoDB基本概念原理

    千次阅读 2019-04-02 12:37:59
    一、MongoDB概述 1、mongoDB概述 MongoDB 是一个基于分布式文件存储的数据库。由C++语言编写 2、NoSQL概述 ...NoSQL,指的是非关系型的数据库。...3、关系数据库对比非关系数据库 关系型数据库 ...
  • ospf原理及基本概念

    千次阅读 2020-08-17 16:06:25
    1.OSPF的基本原理 当路由器开启OSPF后,路由器之间就会相互发送HELLO报文,HELLO报文中包含一些路由器和链路的相关信息,发送HELLO报文的目的是为了形成邻居表,然后,路由器之间就会发送LSA(LINK STATE ...
  • ORACLE rac集群概念原理

    万次阅读 2019-04-17 15:21:35
    Oracle集群概念原理 Oracle的三种高可用集群方案 1 RAC(Real Application Clusters) 多个Oracle服务器组成一个共享的Cache,而这些Oracle服务器共享一个基于网络的存储。这个系统可以容忍单机/或是多机失败...
  • CDN概念和基本原理

    千次阅读 2019-05-28 16:45:46
    1. 什么是CDN? CDN的全称是Content Delivery Network,即内容分发网络。CDN是构建在网络之上的内容分发网络,依靠部署在各地的边缘服务器,通过中心平台的...CDN的基本原理是广泛采用各种缓存服务器,将这些缓存服...
  • Vmware虚拟化概念原理

    万次阅读 多人点赞 2018-05-18 23:08:26
    快照的工作原理:当为虚拟机拍摄快照时,回生成快照的状态文件,保留拍摄快照时虚拟机运行的状态信息,同时,将元虚拟机的磁盘变为只读磁盘,并且新建一块新的增量虚拟磁盘,拍摄快照后的变更数据,写入增量虚拟磁盘...
  • 马上就要编译原理的考试了,看了看去年试卷,做几道题,发现自己对文法的概念都很模糊,下面整理了一下四种文法的基本概念:  那么什么是文法呢? 乔姆斯基把文法分成四种类型,即0型、1型、2型和3型。这几类...
  • kafka的作用 原理 对比

    千次阅读 2018-02-03 21:31:27
    而RocketMQ所有的消息是保存在同一个物理文件中的,Topic和分区数对RocketMQ也只是逻辑概念上的划分,所以Topic数的增加对RocketMQ的性能不会造成太大的影响。 https://yq.aliyun.com/articles/25379   为什么...
  • 计算机网络原理之RIP以及OSPF对比

    千次阅读 2015-11-28 16:09:44
    RIP以及OSPF对比 RIP (1)基本定义:路由信息协议(RIP) 是内部网关协议IGP中最先得到广泛使用的协议。RIP是一种分布式的基于距离矢量的路由选择协议,是因特网的标准协议,其最大优点就是实现简单,开销较小; ...
  • [深度学习概念]·主流声学模型对比

    千次阅读 2019-03-07 12:05:25
    主流声学模型对比 目录 概述 基础概念 语音帧 语音识别系统 主流声学建模技术 HMM DNN-HMM FFDNN CNN RNN及LSTM CTC 其他建模技术 语言建模技术 语音唤醒技术 关于未来 概述 语音识别建模对语音...
  • 参考文章:8位, 16位,24位,32位图片显示原理对比
  • 各种GAN原理总结及对比

    万次阅读 多人点赞 2018-04-21 15:00:19
    最近试着玩了多种GAN,今天我们主要总结下常用的GAN包括DCGAN,WGAN,WGAN-GP,LSGAN-BEGAN,SRGAN的详细原理介绍以及他们对GAN的主要改进,并推荐了一些Github代码复现链接。 本文旨在对GAN的变种做一些梳理工作,...
  • 语音识别技术简述(概念->原理

    万次阅读 2019-04-12 10:21:44
    语音识别技术简述(概念->原理) 目录 语音识别技术简述(概念->原理) 语音识别概念 语音识别原理 语音识别技术简介 1.动态时间规整(DTW) 2.支持向量机(SVM) 3.矢量量化(VQ) 4.隐马尔科夫...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 118,754
精华内容 47,501
关键字:

对比原理概念