本文是Twitter Analytics on the Cloud项目的介绍及分析总结。小组作业当时做的匆忙，现在再思考下可以优化的地方很多。感谢队友@shuangshuang 和 @烟酱。
项目介绍
目标：
- 在云上建立一个高性能又可靠的web服务。
- 设计，开发和部署并优化服务器以能够处理每秒上万次请求的高负载。
- 在一个1TB的数据集上完成ETL并载入到Mysql和HBase中。
- 设计MySQL和HBase并优化配置，提高性能。
- 探索基于云的web服务存在瓶颈的方法，并提高性能。
基本结构：

前端：
- 通过HTTP GET请求访问web服务，不同的请求有不同的地址，后面有不同参数。
- 返回相应的响应时，必须要在持续若干个小时的测试中正常运行。
- web服务不能拒绝请求，要能承受高负载。
后端：
- 保存用来查询的数据文件
- 比较SQL(MySQL)和NoSQL(HBase)
- 比较不同数据集不同查询类型的表现，来决定如何实现后端。
数据集：
Twitter数据集，大于1T，JSON格式存储。
项目实战
搭建前端：
在搭建前端之前，需要慎重选择框架。对比主流web框架，参考Techempower,我们最终选择用vertx和undertow进行开发。 具体可以参考一些比较好的配置指南：
Vertx:
vertx Document My first Vert.x 3 Application
前端优化：
- 运用Cache，每次得到请求先check是否有缓存。当缓存满了的时候，就把最不常用的缓存踢出去。
ETL:
根据request设计好数据库的schema以后，要好好设计ETL。因为我们这里用EMR把twitter数据集载入到数据仓库中，每次需要10-20个小时，而EMR特别贵，所以最好不要重复劳动。最初，用小数据及来测试。
这一阶段我们要处理两类请求，从存储系统中获取数据，搭建好的web service 需要能够连接到两个不同的后端存储系统(MySQL 和 HBase)，前端需要通过端口 80 接收 HTTP GET 请求。
操作过程：
这里主要要写一个Map和一个Reduce文件来处理数据。原始数据的格式是JSON，我们需要处理成需要的数据格式：
请求格式
userid+hashtag
GET /q2?userid=uid&hashtag=hashtag
响应格式 (如果Tweet存在)
- tweet 的 sentiment density
- tweet 的发布时间
- tweet id
- 审查修改过的的 tweet 内容，这里有很多可能出问题的地方，比如 emoji 表情、反斜杠、其他语言的字符等等
TEAMID,TEAM_AWS_ACCOUNT_ID\n Sentiment_density1:Tweet_time1:Tweet_id1:Cencored_text1\n Sentiment_density2:Tweet_time2:Tweet_id2:Cencored_text2\n Sentiment_density3:Tweet_time3:Tweet_id3:Cencored_text3\n
响应格式 (如果Tweet不存在)
TEAMID,TEAM_AWS_ACCOUNT_ID\n \n
map和reduce程序写完后，到EMR上面跑，要注意：
- 现用小数据集测试。
- 注意各种小细节
- 关于EMR的操作，步骤之后有空总结下之前云计算的EMR project。
Query 文本清理和分析
目标吞吐量： 10000 rps 不允许用现用的缓存设备，可以自己写缓存。 会查询某个用户用指定的 hashtag 发的 tweet，主要考察如何设计一个高效的后端来处理大量的请求。
后端数据库
ETL结束以后，我们需要导入数据库。在这个过程中，我们纠结于replication和sharding的选择。 Replication是指将完整的数据库存在每一台机器上，而Sharding是指分成几个部分分别存在每一台机器上。最终，选择了Sharding模式。
数据库设计：
按照我们刚刚说过的请求格式和响应格式，我们对MySQL和HBase进行设计：
MySQL：
设计模式：
（这里参照了Yuki组的赢家设计模式，非常简单粗暴） 原来的schema是每一列都很清晰，但是这样row相比后面的设计模式多了很多，导致数据库的读取速度慢了很多。 所以新的schema就选择只存取id，读取所有的tweets以后，让前端进行相应的解析。
优化方法：
- 建立索引Index
- mysql有两个存储引擎，MyISAM和InnoDB，MyISAM适用于大量查寻，对写并不是非常友好，updata时会整表锁住。而InnoDB使用的是“行锁"。 设置Key_buffer_size以及Query_cache_size到更高的值，可以增加缓冲容量。
- 设置所有column为not null，这样mysql不用预留空间检查null值。会提高读取速度。
HBase:
鉴于HBase是key-value存储模式，我们在这里只要考虑key里怎么放，剩下的数据全都放到column family里面就可以了。 我们采用tweet_id + user_id + hashtag作为rowkey。
优化方法（摘自小土刀博客）：
1.分配合适的内存给 RegionServer 服务: 例如在 HBase 的 conf 目录下的 hbase-env.sh 的最后添加 export HBASE_REGIONSERVER_OPTS=”-Xmx16000m $HBASE_REGIONSERVER_OPTS” 其中 16000m 为分配给 RegionServer 的内存大小。
2.RegionServer 的请求处理 IO 线程数: 较少的 IO 线程适用于处理单次请求内存消耗较高的 Big Put 场景 (大容量单次 Put 或设置了较大 cache 的 Scan，均属于 Big Put) 或 ReigonServer 的内存比较紧张的场景。 较多的 IO 线程，适用于单次请求内存消耗低，TPS 要求 (每秒事务处理量 (TransactionPerSecond)) 非常高的场景。设置该值的时候，以监控内存为主要参考。 在 hbase-site.xml 配置文件中配置项为 hbase.regionserver.handler.count 200
3.调整 Block Cache: hfile.block.cache.size：RS的block cache的内存大小限制，默认值0.25，在偏向读的业务中，可以适当调大该值，具体配置时需试hbase集群服务的业务特征，结合memstore的内存占比进行综合考虑。
总结：
Team Project过去挺久了，很多细节记不得了，清洗数据的部分有很多细节需要注意，并不像这里写的一两句话就讲清楚了。还有数据库优化是一条不归路，盲目优化会导致反向优化，其实根据后来赢家的报告来看，优化并起不到多少作用，好的schema设计才是提高performance的最根本。 云计算这门课的精华，都在这个Project，覆盖了大部分这门课的所实验的知识。从load balance到sharding和replication，再到SQL和NoSQL数据库，再到EMR的应用，就差并行并发那部分的内容了。 学习是不难的，有指导来做project也不难，真正到了实际应用中，没有人知道正确答案，靠的都是思考和经验了。
References：
- 小土刀云计算语料分析&反思课
- 小Yuki的Report