关于大数据架构设计-翻译manning新书的要点
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时，更改算法，重新运行计算即可。又如满足了伸缩性：两者都可以任意增添机器。加速层：加速层解决了高延迟的问题。加速层是对数据集分析的另一种取舍，加速层在新数据到来时更新视图，加速层并不重新构建视图，而是在现有视图集合中进行增量更新而不是重计算更新。另一个特点是加速层只关注最近的数据，而非全部数据。加速层因为要进行增量更新，需要数据库支持随机读写。当服务层收到批处理层的新数据后，加速层的数据就不再需要了，因此加速层只是一个临时的结果层，由临时结果管理复杂性，这很好地控制了复杂性所有新数据被送往两个地方：批处理层的数据集和加速层的增量视图?，在新的批处理视图重新构建之前，需要对实时视图和批处理视图的结果进行合并返回