我想做一个日志分析系统，它的想法是，数据挖掘 ＝ 大家一起来做数据分析，这是这个系统的理念。 现在我在一个日志分析群里进行的讨论，对我有一定启发。 而，最多的动力还是来自于前几年做数据分析的经历。
首先有个“案例”的定义，案例是你的想法，准确的说，是你对数据的感觉、把控。比如抽出某一接口的数据，对其分析，即可看到全体。另一个例子（这个经常用），只分析一部分数据，但是选另外2个维度（也是较少数据）辅助验证我的选择。很像文件的crc校验。
这些“案例”，要的是巧，活，快。
“巧”指，用现在开会的话说，群众的智慧，集体的力量。“活”指，是一个生态，案例是很容易被分享，能够自我完善和淘汰。可能一个做运营的人员，不懂技术，他也可以提出想法，做数据分析。这些案例可以被评选，就是 star，可以分享。“快”指，响应快，数据能够很快的响应回来，供分析师（就是你自己）进行调整。
综上，提出想法，实时分析，及时验证，集体分享，是这个系统的运作方式。
小趣闻：
昨晚，我和同事讨论了一个小型分析，如何找出一个开源程序中最能体现作者意图的那个文件，也就是找出开源程序中的 core。我用了自己屡试不爽的方法，比较文件类型和大小的方法。亚宇提出了另一种方法，对 git 提交的次数进行统计，这个方法会更准。很可能两种方法的结果“惊人的一致”。这就是分析的多个角度，它们都能看到“冰山”，只不过角度不同。
数据挖掘，由一个金字塔式的中间结果，向上汇总。数据分析师，提出自己的想法、需求。然后，程序员提取数据，结构化数据，编写程序，给出报告。这个过程当中，因网络原因，配置原因，或者人为出错，频繁的补数已经是常态了。随便一次计算都要要一周，然后又要反复的重算，折腾。
以前，有一个数据挖掘er 跟我说，实际上，他做的数据挖掘也都是去计算那些已有的公式，那些
未知的规律则计算不出来。另一个数据分析er 跟我说，其实她只是拿我的数据验证她的想法，如果这些
数据对不上是不行的，需要调整后重算（恐怖）。
这里面有五个问题
一是数据分析师可能想验证自己的想法，但是因为数据量大，无法得到及时的验证。这就像你写 JS，却无法用 console 面板调试。程序员实际上在不停的调试过程中完成程序的。同样是构建一个复杂的盒子，可惜数据分析师没有这个福利。
四是这种常规流程，限制了数据分析师，他几乎一上来就要四大指标。殊不知四大指标的运算就占到总运算的一半以上。这很像现在去买车，不管你要不要，套餐就是这样，顶多给你个低配高配。数据分析师的思维被限制在了一个套路上。
五是结构化数据。结构化是高级技术，但是它不灵活。如同上面的情况限制了数据分析师的思维，这里则限制了程序猿的思维。一上来就是id time url duration pv uv，建立的表是结构化了，但是结构也死了。
关键是我们想要什么，准确的统计吗？不是，它们已发生，数据已经在那儿，我是要的是对事情、业务产生的效果，进行把握。
话说回来，继续说我们的分析系统。