先安利一波，历史上发过几篇围绕数据分析的文章：
对此，做一次review，列举一下在数据分析过程中需要注意和反思的问题。
1、数据不能给你答案
在大数据成“疯”那阵子，“数据给我答案”几乎成了每个大数据参与者的信仰。
但实际上，数据带来的问题应该是远多于答案的。
对于数据，我向来倡导脑子里有模糊的思路便可动手。
真正的数据高度敏感者，是在每一次操作之后都能够面向数据的去提出质疑并解决疑问。
在一次次的问题和数据的迭代中建立了完整的分析过程和无限接近终极答案的结果。
CASE Study
引用杂谈态势感知第6部分的案例（点我回忆案例），当时用来忽悠用户的结论是：少数的黑客干了更多的坏事，如果我尝试学习那619个人的手法，大概我就可以避免88.5%被黑问题，而处理619个的代价要远小于6150个；
但实际上，这看似轻松而且充满希望的结论中，却隐藏着很多潜在的问题，其中最为明显的挑战就是 —— 那619个人，是如何黑掉了大量的站点？？？
针对这个问题，在拿到数据时我就已经有了这个质疑，只是当时在写文章时因为剧情需要而没有进一步去展开而已。
在面对619人黑掉54万网站的这一结论，虽然我没有办法完全验证，但在当时我对大几百个被黑站点做了扫描分析，其实结论并不算出乎意料：
首先，被黑站点多为GOV，并且技术栈相近；
其次，很多站点在被黑时间段上呈现了集中特性，也就是说，这些网站并不是以每天一个或N个的速度被平均黑掉的，而是在某个时间段内被大量集中黑掉；
最后，这个时间段内，主要是某个漏洞爆发并大规模应用期间；
然而，也有一些特例，就是时间分布比较零散的，仔细检查了几个零散分布的情况，通过搜索引擎cache就发现，这些时间分布零散的情况多是网站刚刚上线后不久的某个时间；
至此，一个不用数据去统计也显而易见的结论就出现了。
而后我们就会发现，在数据上绕了一大圈，所做的无非就是“虚构”出了一个我们想看而距离真实结果还有那么一段距离的结论而已。
那么，到底是因为什么才无法让数据无法给出真实的答案呢？
一个是分析人员对知识掌握的全面性与视角的高度。另一个则是数据背后的元素过多而造成的混沌。
第一种情况可能还有办法避免，如果遇到了第二种情况，就只能等待上帝在梦中显灵来给你答案了。
-------------------------------------------------
2、思考的严谨与数据的证伪
一次面试过程中我听闻了一个关于内网入侵事件响应的全过程分析。
抛开磕磕绊绊的语言组织能力不说，整个故事梳理下来算的上完整甚至有一点精彩。
但应聘者依然很不幸的被我抓到了一个纰漏 —— 在一个关键节点的跳转分析时，他提到了“我当时猜测是使用XX漏洞过去的”，随后就简单带过了。
在故事之后我再次确认这个环节的时候，他依然在坚持是他猜中了。
然而，在这个分析过程中，却没有任何一个动作是对这次猜测负责的，也就是说，当他认为从A到B可以使用某个漏洞、并且他也使用某个漏洞成功的实现了从A到B的过程时，他就认为猜测是正确的。
在数据中，很多情况都是证实要难于证伪。
所以很多我们在脑子中构建出来并自以为合理的逻辑，在数据计算过程中可能往往是成立的，但当我们去从另一个差异化的视角或更高的层面去验证这个逻辑时，也许他就不成立了。
就好像上例中，A到B可能存在了多种可能性，而某个漏洞只是其中的一种。而这时，这个漏洞的成功利用就只能归结为巧合而非事实了。
在复杂的数据分析过程中，链条往往极长且异常复杂。
如果在某一个环节只是对逻辑做了正向的想象而没有做反向的验证，可能最终的结果就谬之千里了。
CASE Study
以前曾经做过一套以时间为维度的程序运行记录系统，用来弥补实时告警的不足。
简单来说，就是记录每个程序的具体运行时间，然后画图，用图片做横向比对，来发现异常，最初，在我想象中，横向比对的情况应该是这样的：
（特定的计划任务程序，平稳运转）
然后在真实的跑起来之后，发现经常会出现这样的（第二张图断了一块）：
有时候还会出现这样的（后来追查才知道机房出了点问题）：
在数据中，经常无法得到与想象中那般美好的情况匹配的结果。
而在一些无法用简单逻辑证伪或复杂逻辑证实的数据环境中，这样的数据分析工作无疑就是巨大的坑。
就好像我这个程序监控一样，图片横向比对想象的是非常美好，但却无法用一个简单有效的逻辑证实其真伪（不仅仅是例举中的机房问题，还有更多复杂的问题无法证实或证伪），最终精力就陷落到不断的沟通中去了。
-------------------------------------------------
3、数据关联与规则的独立性
关联分析是在数据分析中谈及最多的。
而很多关联分析的失败之处在于，关联和分析，这两件事做成了一件事。
关联，是对事实的描述 —— _小张早上8点出门上班_与 隔壁老王9点去了小张家 ，这两个事情，因“小张和老王都出现在同一个住址”而关联；
分析，是对关联的二次发现 —— 调查发现，小张的老婆在家待业、老王进门超过一小时才出来 …… 等等条件，与上述关联放到一起，就是分析。
如果把关联和分析，分开来看，并分开处理，很多事情就会变的简单。
关联是基于人或物的关系，这种关系在真实的世界中是相对可穷举的，而且也是在数据中比较容易完成的。
而分析规则，与场景相关，不同的关联关系在不同的场景之中，会产生各种交叉的可能性，规则被拓展出来的可能性也就随之增多。
CASE Study
A与B在同一个位置（甚至是设备）上登陆过；
B向C有过资金的划转行为；
关联的结果就是：A-->B / B==>C（-- 和 == 被定义为不同类别的关联关系，在分析过程中可用tag标识，在这里就用不同类别的线来标识）；
在某些场景里，A和B可能是在薅羊毛，而C则可能是B的上家，由此而推论，C为A和B提供了薅羊毛的能力；
继续追查的方向则是：追查A和C是否有资金往来，如果确定则以上场景规则为实锤，进而可对C进行线索扩展，发现更多薅羊毛的。
-------------------------------------------------
4、面对大数据束手无策时，不如试试小数据
很多数据分析是为了使用大数据而使用。
其实，少量的小数据样本往往更能带来惊喜。
在单机分析最担心的问题就是性能，规则稍一复杂，就死的彻彻底底。所以，一般我会采用几个环节：
分类/分片：以最简化的规则进行分类，例如：时间、命中某个字符串、或是多列文件切掉一些只剩下两三列。如果实在都没有什么可用的分类维度，就直接按照百万行进行split操作，切出多个文本；
再分类/再分片：每个分出来的小片数据，基本到达了规则可用的状态。这时候就尽量用复杂规则去进行精细化的分类，而且这种规则要在多个分片数据上进行验证，以确认规则的通用性；
观察小数据：完成两次分片数据之后（也有可能是多次分片），就开始启动人肉环节，上眼观察 —— 当然，也并非是鼠标翻滚的一行行去看，总是要配合一些简单脚本工具的；
制定规则：根据人肉观察结果制定规则，并在不同的分片数据中反复验证；
持续验证：将规则上到平台上在大数据中进行验证，并根据数据新增情况进行反复验证，如果出现问题，则将包含问题环节的数据拖到本地，继续重复上面几个环节；
迄今为止，我在单机上最高分析的数据大概是380GB+，都是采用这样的思路。
为什么小样本能解决大数据的问题？
因为任何数据规律都会落到某些小数据中，只要在小数据切片过程中经验丰富，就很容易获取到精确的规律化的小数据样本。
所以，虽然前两次分类/分片我描述的比较简单，却是因为这两个过程复杂到无法展开去讲。总之，这两次分类/分片工作做好了，整体的工作就成功了80%以上了。
为什么需要小样本解决大数据的问题？
即便大数据平台性能足够强悍，我依然建议不在数据平台上进行分析工作，而是先放到本地取小样本做规则，再放到平台上进行计算。
简单来说，大数据平台利于计算，本地的小数据样本更利于分析。至于原因，其实很难讲清楚，只有真正实操过多的人才会懂得其中的苦楚。
CASE Study
没想到什么好的case，不写了。
-------------------------------------------------
其实数据的分析过程中，还有很多坑，而很多坑是基于特定场景的。使用通用的描述手法实在是很难逐一列举，所以只能写到这里。
另，昨晚想到了五条，但睡太晚，今天起床发现只记得这四条了 …… （赶紧写出来，免得再睡一觉这几条也忘了）
- END -
