数据挖掘主要是基于Hadoop集群。豌豆荚有一个数据挖掘团队专门做产品研发（主要是面向内部），而豌豆荚这个团队则提供硬件资源和底层的Hive、HBase等基础设施的支撑和维护。整体的数据量、计算量一直都在增长，一开始的几年增长极快，最近几年稍微慢一些，也有每年几倍的增长。

差不多在2011年左右，豌豆荚开始尝试做海外版的豌豆荚Snappea。当时评估过在海外自建机房的可行性，在考察过各个地方不同位置、不同IDC、不同运营商的选项之后，豌豆荚发现即使在进展顺利的情况下，也至少需要两三个月才能建成，这个时间成本太高。如果不自建，那就只有公有云这一个选择，正好当时豌豆荚很多工程师都自己用过亚马逊的AWS，出于时间、知识门槛、成本的考量，就决定在海外使用AWS作为豌豆荚的基础支撑。

团队

EP团队的目标很明确：在主要产品的完整生命周期内，实现一流的效率、质量和服务稳定性；至于具体用什么技术或者方法，则并不做限制。一开始豌豆荚团队比较关注流程、开发工具等方面，现在豌豆荚对CI、代码库、自动化测试、运维、基础设施建设等各个方面都做了很多工作，有时候工程师要引入一些新的基础设施相关的技术或框架，豌豆荚也会进行review它们是不是靠谱，总的目标就是让产品从开始开发到线上生产环境运行这整条路径下，其稳定性和质量都有所保证。

现在整个团队的全职工程师有不到三十人，其中运维团队有十个人，而且他们也都会承担开发任务（豌豆荚叫做SRE，网站可靠性工程师），运维过程中需要什么工具、支持系统，都是由他们自己开发。运维团队的主要工作都在维护豌豆荚自建的机房系统上，AWS上面现在平均投入的维护人力差不多只有三分之一个人。这一方面是因为AWS的维护成本确实低，另一方面也是因为豌豆荚在AWS上面的规模还不是太大。

从代码库到生产环境

豌豆荚的产品发布流程还是相对成形的。不同的产品线有不同的发布频率，比较稳定的在一周两次，有些比较早期的项目可能一天一次，没有太大的压力。

产品下一个release要发布哪些feature、发布周期设置成多久间隔，主要是由产品经理和设计师来决定，工程师实现需求。到了发布日期截止之前，从代码库的主干拉一支发布分支出来做feature freeze和最后的验收测试，到发布分支上只能做bug修复，不再接受新的feature。

有的产品线有统一的测试机制，有的产品线则主要靠工程师自己做测试。无论是哪种测试模式，在进入CI做集成之前和之后都会统一进行静态检查和已有的单米测试用例，然后才上到staging环境。从staging环境开始就属于运维负责的领域了，豌豆荚的staging没有真实的流量，但是环境跟线上是一模一样的，可以说是一直处在最新版本的服务，然后staging再跟线上环境同步代码。

这一套自动发布、部署的流程虽然也不是很完善，比如持续集成的检查点还不够多，单米测试率还比较低，不过还算跑的不错。现在AWS上也是同样的一套部署过程，当时适配起来也很快，大概做了一个星期就跑上去了。

监控

豌豆荚的监控系统要实现的目的无非是两个：实时的报警，以及可以追溯的历史数据，其他都是衍生的功能。跟大部分互联网公司一样，豌豆荚一开始做监控也都是用开源软件搭起来的，不过开源的监控软件现在越来越不能满足豌豆荚的需求。