一、Big Data

首先现在很多大公司都在搞云平台和大数据，个人认为在未来的一段时间里这也是一个不错的市场，著名的hadoop 是开源的适合做海量数据处理的分布式软件框架，是根据google发表的三篇文章中的两张MapReduce和档案系统设计而成的，(跟Storm 的产品级的框架来说，研究者还是适合从开源的框架学比较好--演讲人说)，经过演讲者的share,我大致对云平台的设计框架有了了解。

（1）框架

首先云平台由并行的数据运算+并行的数据存储两大部分组成（个人理解）， 其中的并行数据运算由 mapreduce 的一个并行计算框架支撑，而并行的数据存储是由分布式存储的数据库（如HDFS,Hbase）等完成，下面细说下详细的hadoop的设计框架，硬件部分是需要一台主服务器（root host）和一些分布式节点（server node） 组成，看似一个典型的C/S架构，但是关键一点是：分布节点服务器不再向根主机进一步提交他获得的所有数据（可能只传过来索引），根主机反过来向分布主机节点发送的是运算算法，这样节省了根主机的负载，节省数据传输的时间，并且分化了任务达到了并行处理数据的目的，这个应用特别适合密集型的数据处理，一般视频网站多用此技术,（以前听X留的服务器负载均衡是做的最好的，上千PB/d的流量都稳稳的，一直不知道原理，今天才大致清楚了些）当然像淘宝的TFS框架就是读了hadoop的源码设计的。

（2）设计细节（MapReduce）

上面只是简单说下一般密集型云平台的设计框架，下面说下简单设计细节： 首先是MapReduce的计算框架，不要被框架二字吓到，其实听了之后觉得也不是很复杂的原理，根据英文翻译就是减少数据量和序列化的意思，

其实实际也就是这意思，呵呵，大家都知道”数据大“和”大数据“是两码事，没有规律的数据可以等同于无用数据，所以功能需求就有了，就是把海量的无序数据序列化，那对付这个的计算框架也就是最初提到的MapReduce, 看到演讲者提供的java代码很少，我本身又不太懂java代码，但是从他举的例子我还是很轻松的知道代码的原理和为什么要这样做，原理是就是两点：先排序再重映射，呵呵，为啥要这样做？ 排序的原因我就重复了吧，只说重映射的原因，因为可能是同一台客户端请求的大量（不要把客户端都想成你的PC，呵呵），他可能是要把它分在不同的 节点服务器上去运算的，这要是不重新映射还了得，运算回来都不知道咋重组，所以算法设计的原因也有了。

（3）设计细节（HDFS、Hbase） 

还有第二大块就是一个支持分布式存取的数据库（如果只是为了实时运算，那这块也可以没有），说个典型的例子就是Hbase,演讲者说这个数据库这个非关系型型数据库，说白了就是键值对数据库吧，并且他不支持级联查询，这很明显对于要查询某条数据来说不是很高效，这也是演讲者基于大量数据测试过了，因此演讲者本人提出了使用另外一个solr的框架来存储那些数据库的索引，这样就弥补了非关系型数据库的缺点.

（4）设计细节（根主机和节点主机的管理）

其实这里原始的了框架还是C/S ，没错，就是在互联网上被星型拓扑取代的CS，简单说下，根主机就是一个记账的和记录、分配任务的功能，类似于包工头，节点主机就是真正做活的，呵呵，不要以为这里的根主机会比节点主机轻松多少，实际这你错了，你要时刻记住这可是密集型数据奥，所以这里实际仅仅记账和分配任务就够根主机忙的了，这样一个完整的活就可以整块的进来，分块的处理，然后整块的输出了，呵呵，其中在节点主机上还有点问题就是一次吞吐量的设计（Buffer）,大家都清楚为了运算快捷，数据肯定是直接丢在内存的，读写盘的次数越少越好，假如每次分过来处理的任务量是200M，而hadoop默认开的缓冲区才100M，这不得不把一半的任务暂时丢到后台硬盘，这样对于实时处理系统来说时间是不允许的，咋办？很简单评估一下一个分布式系统的节点服务器平均的负载量修改缓冲区大小就OK了（当然是在硬件支持的情况下）

（5）关于大型服务器集群的容错处理

一般一个客户端数据过来后会被备份成多个数据块，默认是备份三个，一个备份会在同一个机架上的不同节点服务器上，另一个会备份在不同机架上的一台服务器，这样三台机器同时宕机的可能性是很小的，这样就利用了硬件的优势降低了数据的错误性概率。

（6）关于数据存取

在海量的数据库中，其实一个完整的数据库早就被分成了不同的region(要考虑海量数据是不可能存在一台服务器上了，就算是为了做备份，做镜像服务器等等)，google其实是用MapReduce来计算PageRank的，试想这个例子，google全球这么多台服务器，存的又是不同的数据，咋能快速查找？其实就是采取了分级的数据分类方法，首先把数据分在不同的数据块上，然后在不同的数据块又有对本数据块的索引，呵呵，这样类推，一个由数据块节点组成的庞大服务器集群就这样健康的开始工作了。

（4）总结

这里的大数据是针对实时密集型系统来说的，通过特定组织服务器集群把并行化运算的瓶颈解决，这就是我理解的实时大数据处理框架

二、Andriod insight

简单的说下就是移动平台上的动态行为检测技术，这里是三个哥们儿开发的，感觉他们很牛，说的他们的项目名字好像叫Prowler,这个名字没记太清，只关注过程去了。这个项目的产品功能就是告诉用户那些APP是malicious(因为大部分的用户都只是单纯的用户！呵呵，这里自我检讨，)，那哥们儿公布的一个近期他们系统现在检测过了八百多万个安卓APP，在系统中测试合格的只有30%多，这个数字直接吓尿了我，这以后安卓机可咋用？这里有人提问题，问了sample的来源，本来这问题我也怀疑，这八百多万个例子是样本堆里捡的吗？据回答样本来源主要有三方面，一个是google play里抓取的，一个是厂商交换的（还说这个的量很大，我觉得这个双赢的做法很不错），还有一个是自己的产品Upload的，呵呵，这些跟PC端的软件设计原理基本一致，没有多少亮点，但是值得一提的是：同样的设计理念，能够移动到另一个平台上也是很有价值的，至少公司用了最捷径的方法登上了安卓平台（这里是我对以前的公司移动产品不是很了解的情况下说的哈），试想这项技术如果是在没有公司前导的情况下出现在安卓平台上，那会怎样？（广阔的市场，没有稳定的运营模式，没有知名度），现在这些似乎已经晚了，因为市场上早已狼烟四起，呵呵，但是至少永不过时的是那个统一的方法论，其实这里都是扯淡，呵呵。

（1）框架

简单概括下我认为的原理： 后端大量的数据->提取有价值规律->对比前端获取的行为记录->结果；当然真正的动态启发式肯定不是简单的这几个字，其中的每一个环节都是基于详细可行的解决方案来支撑的，我这里是站着说话不腰疼，呵呵。

（2）关于移动终端和APP的一点细节

就拿安卓来说的话，原生系统是提供了一套完整的permission的机制，这个相信大家都见过，但是估计很少会关注他，那就是在安装新的APP的时候，在预安装（自己起的过程名，你懂得是哪个时期）时，安卓虚拟机的安装器（类似于 windows的PE loader）会对该APP请求的各种权限做一个汇总（其实这个细节是我猜的，对错有待考究），并会提示用户该APP安装后拥有的读写、运行权限等等（反正本屌丝的小米1s是有的，只用过小米其他的就没有确认过了），比方一个手机上的单机游戏APP，具有发送短信的权限，这就要注意了，呵呵，你懂得不赘述；其实安卓救活了java，一段时间内，这还是个不错的市场嘛，那哥们儿设计的prowler项目其中一项就是用了安卓本身的permission机制外加一些Hook,说着简单，好

吧，这个就扯到这。

三、Malheur 静态启发

本组的coworker 讲的，本屌丝一直没发现原来在我做的这些小活后面隐藏着这样一座绚丽的宫殿，之所以这样说是因为听老师说过这样一句话：大家多学了数据结构，但是很多人会认为他没用；（这里其实在提醒我自己，以后敲代码一定要用

下数据结构，呵呵，一个屌丝的小的可以被鄙视的理想），下面还是说下根据自己理解的静态启发技术，说错了大家可以笑我，但是同时要给我纠正，呵呵。

（1）框架

简单说就是：后台大数据->训练提取规律->对比PE文件信息(静态文件撞树的过程)->结果。据说是一共会提取PE文件的287个静态文件属性（这个数字谁出来纠正一下，有木有？？？反正我想破脑袋也想不出有这样多的文件属性，他们都在哪里藏着？，哎，笨脑袋想不懂）根据确定已知样本好坏的样本来提取的奥（其实就是基于一个相对可信的结论在支持的）,举个例子，我们手上已经有1百万个样本，其中有A，B，C...特征的是坏的，并且A特征对判定结果的贡献度是40%，B是30%，C是小于10%，那我们就是把这些规则信息（枚举或判断）放到树中，当然放置的方法当然是对结果贡献度最高的放在靠树根的地方，原因你懂的， 然后根据某一条分支一直走到树叶，然后出结果或打个分供别人参考，下面说下细节：

（2）设计细节（关于树/森林的训练）

这里又是大数据不用说了，第一步眼前有海量已知好坏的样本，然后我们要做的是在这些样本中找到n个属性来说明他是坏的，说白了就是就是给一群已知是杀人、偷窃犯的人找共同点，首先发现他们都是孤儿、都出没在一些红灯区等等吧，然后根据贝叶斯算法（一个很多人说有用的算法，应用范围很广，就是由果致因的过程，比如根据四川这几年已经发生的地震，推想将来中国发生地震了，八成会是在四川；四川的同事请无视这句话，我是在扯淡，已经掌嘴了）算出这些因素中概率比较大的几个因素（貌似实际是几百个因素，但是实际各因素的权重不一样），用这些因素作为下次文件好坏判断的依据，具体措施就是把敏感因素编成树，方便数据匹配（猪撞树），并且对于不经常被猪撞上的树就要考虑是否砍掉，对于经常被猪撞上的树就可以考虑这棵树太有价值了，我们可以考虑不做其他活，完全听信这棵树的结果,这里两个极端，不一定现实。

（3）设计细节（树规则的匹配）

假如这头猪连续撞了三棵树（死定了），一般是以第一棵树的结果为准，树的匹配有些注意的地方，比如树的深度不能过长，当这样的事情发生时，一般处理办法是：把树裁剪若干成小树，平衡整个森林，还有就是当在分支里走到认为后面的判断结果都已经无关紧要的时候可以输出结果了（一些权重相对比较大的规则应该尽量放在不同的大分支，或者不同的树，这样既减小树的高度又将树的耦合度降低些，我猜是这样做的，甚至比这细化的多），那个 具体的ClasssFilter 4.5的算法具体不知道对应在哪块上（写到这里大脑已经迷糊了），反正树的节点是在动态的调整的，目的是降低FP，放大TP，（想到这，发现自己数学已弱爆），作为静态检测的最后一项技术，当然希望尽可能为后面的工作减轻负担或者为后面的判断多提供依据，目测因为以后样本的变种还是会不断添加，所以这边的森林也得茁壮成长才能不断的抵御风沙，不被吞噬（技术替代）。

（4）关于静态启发我似乎只说了1%，其他的都忘了或者不知道，以后需要学的也是Big data很多,弄清楚技术细节差远了呐。