Nathan Marz的书还是要看一看的，毕竟那个墙外的网站经受住了美国大选结果出炉的考验
为什么要讨论大数据设计
- 电子数据已成为每天生活的一部分，不论是网络上，还是科学实验的记录上
- 数据的增长影响到业务的开展，引发了传统关系型数据库的性能瓶颈，传统的设计管理方式很难扩展到大数据上
- 为解决大数据带来的问题，不同的软件开发领域以NoSQL的名义引入了很多新的技术，这些新技术可以在某种程度上支撑数据的扩展，但是没有一个一致的设计方式，即需要根据具体的业务和技术架构灵活处理
- 这些技术的领导者包括：Google，Amazon和开源社区。技术包括：分布式文件系统，分布式计算框架，分布式锁框架，Key-Value数据库，分布式队列等
- 所以大数据包含两个层面：复杂性和伸缩性。这和传统的数据库设计有很大不同，举例：一个最简单的关系数据库需求都可能很难在大数据上实现。因此大数据的设计需要作为一个独立的范式进行讨论
传统数据库设计的变迁和问题
- 一个统计用户访问数量的程序，有字段user_id, page_views, url. 压力大后无法向数据库写入数据
- 解决办法：引入队列，当队列满时批量写入数据库而不是每次有点击就写入数据库
- 数据继续增长，加入更多队列，缓存更多数据，减小数据库负载。数据继续增长，数据库服务器成为瓶颈
- 这是要对数据库进行水平分区/数据分片（Sharding），这时要对旧的数据进行迁移和重新切割，并且需要找到合适的切割键，而且当负载进一步加大时，需要重新进行更加细致的切割。这时迁移脚本需要多线程运行，以达到最大效率。同时应用程序也要进行相应的调整。
- 最终因为分片过多，当某台硬件设备故障时，这时需要中间件队列缓冲数据，同时数据库服务器也要有主备机制
- 另一方面，当程序引入bug时，海量的数据导致难以做到故障恢复。总之，大量时间将花在后台程序的设计和维护上
大数据的优势
- 自动具备切片和复制功能，对于切片的访问是透明的。伸缩性体现在只需要增加机器就可以，水平切割数据会自动重新平衡到新的负载
- 另一个特点是维护不变数据，这个是大数据的一个优势。因为存储是廉价的，我们不需要对数据进行聚合，只保存原始数据。这样坏的数据不会影响到历史上好的数据。传统数据库的快速数据增长是噩梦，但是对于大数据不是这样。
大数据概念和特性
- 过去几年在NoSQL的名义下涌现出一些新的技术，这些技术充满了技术上的取舍。比如MapReduce在获得分布式大数据分析的好处时，是高延时的。NoSQL数据库提供了伸缩性，但是增加了复杂性。这些工具需要小心地叠加使用才能达到最理想的效果，这种叠加被称为Lambda架构
- Terms:非衍生的数据在大数据范式中称为数据，管理这些数据的程序，称为数据系统，采用的是分析方法，针对的是数据集 query = function(all data)
- 大数据系统的目标是应用分析方法对数据进行分析
- 大数据系统应该具备的特性：健壮/容错;低延迟读写;伸缩性;通用性;可扩展性;支持数据查询和挖掘;易于维护;可调试;
Lambda架构
- 层次划分：批处理层；服务层；加速层
- 理想的数据分析是实时查询，但在大数据面前，只能通过预计算查询方法（类似Oracle物化视图）。即对大数据从不同维度的预分析，由批处理层负责。这种方式具备一定延迟。
- 批处理层：批处理层做两件事：保存一份完整的不变数据集并运行预计算查询方法
- Hadoop就是批处理层的典型，定时的不断刷新计算查询方法，批处理层以单线程的代码方式运行多线程的程序完成
- 服务层：批处理层的产出是可以被查询的视图，这些视图保存在服务层里，因为批处理层的产出常常是普通的文本文件，服务层以方便查询的方式将这些聚合结果加载，并根据批处理层的更新频率定期重新加载。
- 服务层支持批量更新和随机读，但是不需要支持随机写
- 除去低延迟性，其他特性都被批处理层和服务层满足，比如满足了健壮性：批处理层失败后自动重新构建，服务层用内置的复制机制保证无故障运行，当程序出现bug时，更改算法，重新运行计算即可。又如满足了伸缩性：两者都可以任意增添机器。
- 加速层：加速层解决了高延迟的问题。加速层是对数据集分析的另一种取舍，加速层在新数据到来时更新视图，加速层并不重新构建视图，而是在现有视图集合中进行增量更新而不是重计算更新。另一个特点是加速层只关注最近的数据，而非全部数据。
- 加速层因为要进行增量更新，需要数据库支持随机读写。
- 当服务层收到批处理层的新数据后，加速层的数据就不再需要了，因此加速层只是一个临时的结果层，由临时结果管理复杂性，这很好地控制了复杂性
- 所有新数据被送往两个地方：批处理层的数据集和加速层的增量视图 ，在新的批处理视图重新构建之前，需要对实时视图和批处理视图的结果进行合并返回