开源项目 基于 Mongoid/ActiveRecord 的 statlysis 统计分析引擎
对《statlysis 统计分析引擎 线下培训策划》感兴趣的 请移步 http://ruby-china.org/topics/16643
项目地址在 https://github.com/mvj3/statlysis
统计分析在线演示，拿 showterm 录制的， http://mvj3.github.io/statlysis/showterm.html
两个已经部署在生产环境的使用案例：
@mvj3 的确，业务部门会有各种各样的数据需要统计，计算。我这边主要是通过 Ruby 脚本将数据周期性 (我们对实时性要求不高) 导入 ElasticSearch, 然后根据 ES 提供的 Aggregation 的相关功能去进行分析处理。
对进入 ES 的 document 是需要根据业务进行整理的，也就是你所提到的 "解析引擎" 部分，我这边设计好相关业务所需要的信息组织成为一个 document, 然后挨个压入 ES 中。
看完你的 Blog 后感觉，对不同的统计功能，现在最难的不是存储与数据提取，因为现在有 Mongodb, ElasticSearch 这些针对较大数据量设计的项目，并且都有良好的集群支持，难的是如何设计好用于处理这些数据的 document 以及你的库所提供的 DSL 查询。
我选择 ES 的考虑是，他提供的 Restful 接口好好用，哈哈。
ElasticSearch 确实很强大，它提供的 facets，让我想起以前用 Sphinx 里面提到的 facets，只是没想到可以这样活用！你的分析很对，良好的 DSL 查询是必杀技。
我说一下 ElasticSearch 对于写 Ruby 的我和 statlysis 来说的三点不足吧，可能有失偏颇：）
- 语言层面。相对于 Java 社区项目，我更偏向 Ruby, JavaScript, C/C++ 等社区的项目，毕竟 Java 社区自成一个体系，想进去能使用上大部分工具门槛比较高，于是我就放弃 Hadoop 了，不过理念可以借鉴。我会采用的解决方案是 MySQL，MongoDB，Redis，PostgreSQL，Sphinx 等。
- 只能通过 HTTP 沟通。几乎所有统计需求都要一一在 ElasticSearch 重新生成一份，而 statlysis 可以很好的复用现成 Model 的，简单来说，更接近 ORM 操作。包括在展现数据时的条件查询和遍历。
- DSL 集成。statlysis 是可以直接通过 DSL 查询配置语句的，只需要一行非常接近业务的代码即可。而 ElasticSearch 拆成不同的类，得自己去组织 ETL 和统计分析。
个人觉得 ElasticSearch 最大的好处是它是独立的应用程序和解决方案，在稳定性上很好。而 statlysis 的目标就是面向用 Ruby on Rails 开发的中小型网站，当然 MongoDB 能 Hold 住的数据量，它也能 Hold 住，我目前的经验是十亿级别。
你能用 MySQL 可以 Handler 的数据量，Sphinx 一定可以，而且它也是分布式的，见 用 sphinx 轻松搞定方便管理的多节点过亿级数据搜索 。
如果要用 ElasticSearch 的还是问 @wppurking 这些有经验的人吧：）
Sphinx 是个独立的程序，它本身没有问题。但是提供给 Sphinx 数据源时可能要注意 MySQL 查询的索引了，或者你发个贴和大家一起讨论下吧：）
@small_fish__ 其实我比较好奇为什么如果有 Sphinx 经验，是什么理由促使你想使用 ElasticSearch ... 因为在全文搜索上 ElasticSearch 并不占 Sphinx 啥便宜，Sphinx 的搜索速度还是比 ES 快的，同时他们都有对应的分布式解决方案。
@mvj3 如你所说，我是当 ElasticSearch 为一个独立的服务或者应用在使用他，所以在已有的系统与其交互的时候，也是脱离现有的 Model 去设计存入 ES 中的 document 的，要这样思考解决问题，也是因为历史项目问题 - -|| 一个是历史的 Java 项目，一个是新上的 Rails 项目，Rails 项目要用 Java 项目中的数据，为了分析数据的性能也为了独立开两个项目的联系，所以就通过 ES 作为中间数据的转换中心，用 Ruby 脚本处理 Java 项目 DB 中的数据，然后再通过 ES 的 Query DSL 想外提供服务。
十亿级别已经很大了啦~ 然后我们是解决分析问题使用的两种思路，一种是重用现有 Model, 一种是独立设计业务相关 document , 最终都把问题解决了 
#8 楼 @wppurking 嗯，能顺利解决问题的技术都是好技术。
混合语言是好事情，Ruby 这种脚本语言做数据处理肯定比 Java 方便多了。不过直接用 ElasticSearch 的 API 提供对外服务感觉像是把 MySQL 直接暴露在外网一样。。。不知道是否做了一层包装，还是我理解错了？
对于数据源来说，statlysis 其实是包括了"复用现有 Model"和"独立设计业务相关 document"两种 ETL 方案的，这个可以见 README 的两个案例，ETL::LessonLog 和 ETL::ProblemLog 两个 Mongoid Model 就是类似于你这里的"独立设计业务相关 document"。
我觉得 statlysis 采用 数据库 ORM，和 ElasticSearch 采用 Restful HTTP ，才是两种方案在 ETL 上的最大区别。
。。。本来是想和大家讨论 statlysis 的，意想不到的是抛砖引玉出了与其他成熟方案的对比，很有收获：）
