本文主要是总结一些云计算的应用实例，是否要用云计算这个问题是个很复杂的问题，大多数时候需要根据需求和预算才能得到确切的答案，云计算是趋势，但如何利用是个值得仔细考虑的问题。
云计算应用实例：Obama For America
Obama For America（OFA）是云计算一个经典实例，云计算被运用在筹集竞选资金、分析竞争对手、有效使用竞选资金等都为奥巴马的连任成功提供了极大的保障。
OFA是什么？
OFA利用数据集成和预测分析使奥巴马赢得了选举，主要通过数据挖掘来确定及影响摇摆州的投票目标。OFA的数据来源包含：人口数据，投票历史数据，筹款数据，志愿者数据，社交网络数据以及投票数据，得到相关数据后，通过上门拜访，打电话，邮件，信件，网络广告，社交媒体，付费电视和网站等方式来影响投票人的决定。
OFA的一些数据
根据DevOps的负责人透露，OFA的一些关键数据包括：
- 4Gbps带宽
- 每秒10,000条请求
- 2,000个数据节点
- 3个数据中心
- 180TB数据量
- 共约85亿条请求
- 从设计到部署到应用共用了583天
- 最多30分钟的宕机时间
- 技术团队共40人
核心应用
Obama For America团队一共构建了200个应用，包括：
Narwhal
Narwhal是一个python写的REST API，可调用存放的所有数据。在OFA中，大多数数据存放在MySQL为主的关系型数据库中，但也使用了PostgresDB, MS SQL Server, MongoDB, Vertica, LevelDB, S3, DynamoDB, SimpleDB数据库。除数据存储之外，主要应用了AWS EMR(Elastic MapReduce service)和Vertica来处理大量的数据建模和分析的工作。
CallTool
CallTool可以用来让志愿者给投票人打电话。在选举的最后四天里，这个工具被1000多个志愿者给超过百万的投票人打了电话。工具可以将志愿者和投票人进行配对。团队在其中应用了AWS的auto-scalling功能在需求高峰能够快速增加云资源。
DashBoard
一个用来登记志愿者信息，并允许志愿者查看相应进度和收集到的信息的Rails线上应用工具。
Dreamcatcher
Dreamcatcher可以通过处理社交网络上的政治舆情，精确确定目标投票人，并赢得投票人。
GOTV
GOTV即Get out the vote，这个应用用来动员支持者将支持转化为投票。
AWS如何帮助了OFA?
OFA所有的应用几乎都部署在AWS云端，他们应用了分布消息队列，NoSQL和SQL数据库，虚拟私有云服务，负载均衡，内容传输网络等服务。 除了能够应对大规模数据处理需求之外，还能够在需求高峰通过自动增加云计算资源保证响应速度。另外，团队在数据备份上也充分利用了云计算的优势。
Reference:
- How Obama’s tech team helped deliver the 2012 election
- Wikipedia:Organizing for America
- CMU 15719 slides
- 6 Ways Amazon Cloud Helped Obama Win
云计算应用实例：Start-ups
背景
对于Start-up来说，计算要求往往各种各样，需求量不大，变化却很快。在有限的预算下，还存在着硬件采购周期长，部署周期长，负担不起系统管理，数据中心能量供应，利用率低，灾难响应速度低等问题。
所以，云计算成为了Start-up的一种选择。举个栗子：
GoSquared
GoSquared是一家提供线上实时数据网站分析的企业，被TechCrunch报道后，使用量忽然增加，没有足够的资源应对增长，最终把网站搬到了AWS上，可以迅速得到更多资源，快速拓展。
Reference
云计算应用实例：Data Analytics
如今企业决策都讲究数据驱动，层出不穷的多媒体数据往往有不同的数据来源，从text到图片到音频和视频。数据处理还分为批处理和流处理。如今，传统的数据处理流程也慢慢转向了云端。
数据处理流程图
Lambda架构
Lambda架构定义了一套明确的架构原则，同时利用批处理和流处理对大规模的数据进行处理。此框架的提出主要是为了解决这样的一个问题：如何实时地在任意大数据集上进行查询？
Lambda架构包含三层layer：
- 批处理层：写一次，批量读取多次
主要有Hadoop实现，负责数据存储和产生试图数据。当新数据到达时，会用MapReduce迭代地讲数据聚集到视图中。根据数据大小和集群的规模，迭代转换计算时间大约需要几小时。 - 服务层：随机读取，不支持随机写入，批量计算和批量写入
这层由Cloudera Impala实现，对于上一层输出的一些列包含预计算视图的原始文件，服务层在Hive元数据层中创建一个表，元数据都指向HDFS中的文件，随后用户可以通过Impala查询到视图。这里服务层用Impala就是为了快速而且交互地查询到Hadoop存储和处理的数据。但是由于MapReduce在实时数据处理中的高延迟，我们还需要加速层。 在这一层中，需要合并处理Batch views和Real-time views得到最终user需要的query结果。 - 加速层：随机读取，随机写入，增量计算
本层利用Strom框架计算实时视图，使用增量模型，将实时视图作为临时量，只要数据被传送到批处理层中，服务层相应的实时视图就会被丢掉。由于应用了增量模型，往往会比较复杂。
所以，整个流程为，当数据进来时，会并行地进入到批处理层与加速层，当两者查询都完成在服务层整合好后，才算完成一次完整的查询。
但是这样令人激动的模型，还存在着一些争议，比如
- 代码维护需要在两个复杂的分布式系统中进行，需要对不同的框架进行不同的编程。
- 在两个分布式系统中运行和维护程序任然很难，比如跨数据库系统中进行ORM（对象关系映射）就会比较难。
关于Lambda框架的具体细节可参考这本书：《Big data: Principles and best practices of scalable realtime data systems》 其中除了介绍Lambda框架外，还重点放在了一些重要的地方：
- 分布式思想
- 避免增量架构
- 创建再计算算法
- 数据相关性
- 关注数据不可变
这张图很好诠释了Lambda是如何处理query的：
随着发展，后来，Spark被认为是Lambda框架的合理实现。所以在这一部分，感觉写Lambda框架有点过时呢，但老师提到了就再理解一下。时代发展就是这样的，Lambda框架这种临时解决方案，会被更完美的方案取代。不过，不管怎样，人类的进步是令人欣喜的。关于Spark有空可以再写一篇具体一点的，amazing。
References：
云计算应用实例：云迁移 （究竟是否应该选择Cloud？）
对研究室来说，是应该使用预置的硬件，还是迁移到云端？ 回答当然是，“It depends.”。
比如需求是这样：
如果我们选择预置的机器，按照五年来算：
有以下两种云计算的方案：
方案1：
方案2：
所以我们可以针对不同的需求、不同的云计算选择、不同的费用模型、不同的权限要求等来选择是否迁移到云端。
另外，在对比时，我们还需要考虑：
- 对于本地预置机器：供电、散热、安全性等
- 对于云端：迁移到/迁出云端的成本等