创业之前2

初创–前世2

标签（空格分隔）： 感悟

第二年，开始接触大数据、nosql：mongo、hbase、hdfs、mapreduce、数据收集、实时计算（规则引擎）

大数据

1.日志的采集订阅

先开始接触大数据的收集和处理，现在一般的数据都是日志（量非常大的系统写日志也是挑战，量非常小的业务也可以纯走网络）。

2.日志的处理

日志的处理和消息系统类似，日志的收集要求尽可能实时（一个小的点是能够支持日志滚动等），另外数据的订阅（处理）也应该是多种多样的，能够直接输出到存储，也能够通过订阅的形式一行一行处理日志。消息系统还有比较头疼的堆积问题，所以说仅仅是一个收集处理的架构也是不小的挑战，当时收集依赖于其他外部系统，并且订阅日志，当时认为已经比较牛B了

3.日志的存储

带存储的模块（日志的存储），空间的管理也是一个比较重要的问题，mongo慢慢暴露了内存大户的问题，一超过最大内存就会变得超级慢，数据的清理也很麻烦，后来在整个TB都抛弃了，确实没啥优势，文档模型很容易让架构更混乱。hbase确实是适合大量写少量的系统，那时候的写还没现在这么牛B，compact或者full gc之类的经常间歇性的卡，并且设计上也遇到很多坑，key不够分散，手动balance等。

做上面的系统，一下接触了大量的东西，所以搞了半年以后，已经达到我的瓶颈，或者说在当时认知下，已经达到了我认为的最优，所以又做甩手掌柜去做另一个新东西，就是规则引擎。这个东西在现在一位非常实干的架构师下已经非常强大了，但是当时真的是一坨屎。

规则引擎

简单的规则引擎其实就是数据流+动态脚本（groovy、mvel等）+工具函数，这样基本可以给技术人员使用了，作为完整的系统来说，还需要数据接入、脚本测试、上线流程、结果记录审批等非常重要的部分，我们的系统牛B的地方就是让业务人员也可以使用规则引擎,通过在页面上配置的方式就组装成一段规则代码，这把系统的接入面扩大了好多，本来只能开发人员用的东西，变成了一个运营的规则平台

要让业务人员也能使用，这需要一个变量模块，比如userNick能让运营人看到是会员名；另外还需要一个时间维度的指标模块，比如这个会员X天内购买了多少件商品，X是可以任意指定的。当时这个系统的时间算法是不错的，就是存储的时候性能上不去，现在想想可以使用类似mapreduce的方式，中间再加一层缓存，这样可以减少直接存储的压力，方便数据的累计和更新