基本信息
编辑推荐
1、《程序员2013精华本》内容涉及产品设计、大数据、前端、云计算、深度学习、SDN、移动互联网、硬件、游戏、高性能网站架构、微信、智能硬件、运维等，一本书尽览IT热点和最新技术，内容饱满程度前所未有。
2、《程序员2013精华本》由《程序员》编辑部精心打造，对《程序员》杂志2013年的内容再次进行了优化整合，内容更加聚焦，是一份浓缩的饕餮盛宴，值得阅读。
内容简介
书籍
计算机书籍
《程序员2013精华本》紧紧围绕云计算、大数据、移动、智能硬件、产品设计等热门话题，进行了全面而深入的解析和讨论。内容包括：产品设计、大数据、前端、中国云计算大势图、Mobile GO!、Deep Learnning、SDN、硬件、Game Go Mobile!、高性能网站架构、微信、智能硬件、运维、回顾·展望等专题，《程序员》记者直接采访软件业大师级人物以及知名公司CEO、CTO、技术负责人，在思想、实践等方面进行的深刻碰撞；软件方法、研发实践、个人成长等方面的真知灼见；产品设计方面的方法和理念；移动开发领域的观点和技术；云计算热门技术和观点；编程语言、开发工具、技术实战等。
《程序员2013精华本》适合开发者、项目经理、CTO&CIO、编程爱好者阅读和收藏。
计算机书籍
《程序员2013精华本》紧紧围绕云计算、大数据、移动、智能硬件、产品设计等热门话题，进行了全面而深入的解析和讨论。内容包括：产品设计、大数据、前端、中国云计算大势图、Mobile GO!、Deep Learnning、SDN、硬件、Game Go Mobile!、高性能网站架构、微信、智能硬件、运维、回顾·展望等专题，《程序员》记者直接采访软件业大师级人物以及知名公司CEO、CTO、技术负责人，在思想、实践等方面进行的深刻碰撞；软件方法、研发实践、个人成长等方面的真知灼见；产品设计方面的方法和理念；移动开发领域的观点和技术；云计算热门技术和观点；编程语言、开发工具、技术实战等。
《程序员2013精华本》适合开发者、项目经理、CTO&CIO、编程爱好者阅读和收藏。
作译者
《程序员》是中国影响力最大的开发者专业期刊，创办于2000年10月，以产业化、专业化、人文化、个性化的独特定位来关注程序员专业群体，同CSDN网站形成良好的资源互补。其读者群包括开发者、项目经理、技术总监(CTO&CIO)、IT专业人士、编程爱好者等。《程序员》创刊以来，以其高质量的内容受到广大读者的好评。第一期至今，每期读者调查满意度都超过90%。
目录
《程序员2013精华本》
专题篇
产品设计 1
产品设计 1
创新中国——中国设计体验谈 1
由点到面的用户体验设计 4
从产品设计流程中寻找好的设计 5
以痛点为中心的设计 7
Weico 背后的故事 8
大数据 10
大数据，且行且思 10
腾讯数据银行TDBank 11
海量数据存储优化实践 14
基于Trident 构建大规模实时流数据处理系统 16
从存储、计算和数据挖掘谈流式处理 18
浅析腾讯TDW 对Hive 的应用和优化 20
百分点大数据与个性化实践 22
生命科学中的大数据 25
前端 28
开源前端框架纵横谈 28
专题篇
产品设计 1
产品设计 1
创新中国——中国设计体验谈 1
由点到面的用户体验设计 4
从产品设计流程中寻找好的设计 5
以痛点为中心的设计 7
Weico 背后的故事 8
大数据 10
大数据，且行且思 10
腾讯数据银行TDBank 11
海量数据存储优化实践 14
基于Trident 构建大规模实时流数据处理系统 16
从存储、计算和数据挖掘谈流式处理 18
浅析腾讯TDW 对Hive 的应用和优化 20
百分点大数据与个性化实践 22
生命科学中的大数据 25
前端 28
开源前端框架纵横谈 28
前言
马年新春，《程序员2013精华本》如期而至。这期精华本紧紧围绕云计算、大数据、移动、智能硬件、产品设计等热门话题，进行了全面而深入的解析和讨论。
基于原有栏目和本年度热点，《程序员2013精华本》的结构分为以下七个篇章。
专题篇：综合了2013年1-12月刊《程序员》封面报道，内容包括产品设计、大数据、前端、中国云计算大势图、Mobile GO!、Deep Learnning、SDN、硬件、Game Go Mobile!、高性能网站架构、微信、智能硬件、运维、回顾·展望等14个主题。
对话篇：由《程序员》记者直接采访软件业大师级人物以及知名公司CEO、CTO、技术负责人，在思想、实践等方面进行深刻碰撞。
管理篇：主要是来自软件方法、研发实践、个人成长等方面的真知灼见。
产品篇：主要分享产品设计方面的方法和理念。
移动篇：汇聚移动开发领域的观点和技术。
云计算篇：云计算热门技术和观点，包括推荐技术、Hadoop与大数据、架构等。
技术篇：包括编程语言、开发工具、技术实战等几方面内容。
《程序员2013精华本》内容饱满程度前所未有，希望您能喜欢。顺祝2014年马到功成！
《程序员》编辑部
2014年1月
基于原有栏目和本年度热点，《程序员2013精华本》的结构分为以下七个篇章。
专题篇：综合了2013年1-12月刊《程序员》封面报道，内容包括产品设计、大数据、前端、中国云计算大势图、Mobile GO!、Deep Learnning、SDN、硬件、Game Go Mobile!、高性能网站架构、微信、智能硬件、运维、回顾·展望等14个主题。
对话篇：由《程序员》记者直接采访软件业大师级人物以及知名公司CEO、CTO、技术负责人，在思想、实践等方面进行深刻碰撞。
管理篇：主要是来自软件方法、研发实践、个人成长等方面的真知灼见。
产品篇：主要分享产品设计方面的方法和理念。
移动篇：汇聚移动开发领域的观点和技术。
云计算篇：云计算热门技术和观点，包括推荐技术、Hadoop与大数据、架构等。
技术篇：包括编程语言、开发工具、技术实战等几方面内容。
《程序员2013精华本》内容饱满程度前所未有，希望您能喜欢。顺祝2014年马到功成！
《程序员》编辑部
2014年1月
书摘
对2013 年大数据技术的五个体会
文/ 吴甘沙
2012年写大数据文章，必先谈互联网的一分钟、过去两年数据占90%、一天数据产生量等于数万年、IDC的多少ZB，很唬人；2013年初拿舍恩伯格的三大思维说事，有品位；后来人人都说全量数据、相关性!=因果性时，意兴阑珊。所以转而专心关注技术文章。这一年接触了不少大数据的新技术，也形成了一些新的认识和体会，总结为五个方面：范式、舍得、安全、人机、价值。
范式
托马斯·库恩指出科学革命的结构起始于前科学，而范式的诞生使其进入常规科学。范式是一系列公认模型的集合体。大数据经过多年的积累和发展，现已存在一些模式、抽象和范型。我们从高层抽象、计算模型到底层架构，来看这些范式。
在高层抽象上，是数据管理与数据分析的融合。前大数据时代两者是分开的，事务型RDBMS（OLTP）与分析型RDBMS（OLAP）各行其道，打通两边还需ETL。EDW有数据管理但分析能力有限；R、SAS、SPSS这样的工具分析强，但能处理的数据通常为单节点的内存容量所限。大数据时代融合成为趋势，SAP ANA和NewSQL为代表的内存数据库平台采用列存储，在一套数据上实现OLTP和OLAP。所谓的Big SQL或SQL-on-Hadoop集大数据管理和简单分析能力于一身。对于更复杂的分析，以线性代数计算为代表，R、SAS、SPSS这样的分析工具纷纷寄生在大数据管理和处理平台上（如Hadoop）。Stonebraker等在英特尔大数据科学技术中心搞起了SciDB，称为数组DBMS，可以在数据库上原生地跑线性代数运算。
在计算模型上，以数据流为代表的范式大行其道。其中包括数据动、计算不动的流式计算，和数据不动、计算动的批量计算。对于后者，又分为二阶段的MapReduce、三阶段的BSP和DOT、更复杂的DAG和多迭代计算（如Spark和Tez）。另一个维度是并行特性，数据并行最容易、应用最广，而流式计算是任务并行、流水线并行。流式计算又分单记录和小批量，其中小批量又引入了数据
并行。
数据流表现为计算图，节点之间有数据依赖，同节点的数据间独立运算；而图计算工作于具有图结构的数据之上，数据间有局部的计算依赖，同时多迭代又呈现计算步之间的数据依赖。大数据为图计算带来的机会是图并行：因为图结构的稀疏性，多数顶点只有较小的邻域，这样，在一个迭代中整个图可以划分为很多并行处理的邻域。图并行中的复杂依赖必须有一致性保证，如GraphLab的多种一致性模型。其在分布式计算中的挑战是计算跨服务器的划分，具体来说：划分尽量均匀，应用哈希划分和图的边切割时注意data skew；通过镜像、最小切割等机制减少跨服务器依赖和通信；通过轻量级的任务调度和通信，例如U.T.Austin的
Galois可高效实现图计算。另外，计算模型的不同颗粒度和同步/异步模型也会影响性能。较之BSP的粗粒度、同步模型，GraphLab的异步、细粒度显著加速多迭代算法的收敛。单记录流式计算同样是异步、细粒度，延迟也低于同步、粗粒度的小批量流式计算。最近细粒度任务作为一种底层实现机制颇受青睐，例如伯克利的Tiny Tasks（可能会用在Spark上）和上述Galois。
流式、批量和迭代计算模型之间形成融合，如T w i t t e r ummingbird在编程接口层面融合，Lambda架构在应用框架层面通过增量计算和批量缓存实现融合，而Spark在实现框架层面完成融合，在这一层面微软也提出了Naiad和REEF来支持多计算模型。
在最底层的架构上，最热的范式是数据在存储层次上的上移，即内存计算。无论是分布式内存缓存、内存文件系统（如Tachyon）、内存数据库，还是内存计算框架（如Spark），内存是获得低延迟的主要途径。目前内存计算主要的问题是容量、容错和低延迟互联。未来三年，下一代非易失内存将登上舞台，与DRAM相近的性能、字节寻址、更大的容量和可持久性，预计将引发大数据软件栈的大变革，很多中间层将会被拿掉，容错更简单，虚拟内存、文件系统等都可能发生巨变。基于硅光的互联也将根本性改变大数据架构的风景，英特尔与康宁合作的MXC技术已经实现了单个lane 1.6Tb/s的带宽，结合英特尔的Rack Scale Architecture，有望实现计算、通信、存储和内存的完全分散化（disaggregated）架构，灵活地适配前文中不同高层范型。同时，新的互联结构也将改变目前过深的软件栈。希捷的Kinetic存储已经预示了这一方向，将原有架构中的操作系统层和存储层软件大幅简化；将硬盘设备IP化，置于以太网的另一端，在客户端直接呈现K/V式的对象存储接口。
架构的舍得
天下没有免费的午餐，突然偌大的数据洪流奔涌而来，原有的架构无法通过渐进优化应对。因此必须大胆舍，才能得。舍得的一种体现是舍大得小，例如以下几个方面。
数据压缩已成为所有大数据架构的标配，除Hadoop采用的几种压缩算法，2013年初Google开源的Zopfli以2-3个数量级的计算增量使压缩率提升3%~8%，更适合变化性较小的数据（压一次就行）。对多数系统，压缩解压缩发生在内存和I/O之间，内存里已是解压的数据。也有少数系统，如IBM的Netezza，数据在内存中仍保持压缩状态，在CPU读取时经由FPGA实时地流式解压，进一步提升了内存空间效率。
数据的列存储能够使压缩率获得数量级的提升，而它本身也是舍大得小的办法，因为往往查询并不需要访问所有列，所以数据加载时无需读入不相干的列。好的SQL优化器也对行存储做pruning。
采样和近似在精确度要求不高的情况下很有效。例如，BlinkDB通过离线和在线的两重采样，在100个节点的集群上对数十TB的数据进行查询，获得小于2秒的延迟，但同时误差率达到2%~10%。Shark和Facebook的Presto都有望集成BlinkDB。另一个例子是Druid采用HyperLogLog算法加速count distinct。
缓存机制也是天然的舍大得小。例如，分布式缓存根据数据的活性和局部性识别出活跃数据，并将其置于内存中。
为了得到计算的实时性，常常要舍旧数据、冷数据和静态数据。流式处理便是这样。2013年应该说是流式计算大热的一年，除老将Storm之外，Google的MillWheel、LinkedIn的Samza、伯克利的Spark Streaming和Twitter的Summingbird相继进入视野。此处的舍可以通过增量计算弥补，早几年有Google的Percolator，今年百度大数据首席架构师林仕鼎在《架构设计与架构师》中揭示百度存储中类似的实现，Storm作者Nathan Marz的书虽然跳票，但Lambda架构已经名满天下。反过来，舍实时的更新数据，只专注于较旧的惰性数据，也是得低延迟的办法。例如Google的Dremel，对只读的PB级数据实现秒级的即席查询。
以NoSQL数据库为代表的大数据架构多采用舍一致性来获得响应性和扩展性的设计。基于CAP理论，分布式系统既然不能舍P（分区容错），就必须在A（可用性）和C（一致性）有所取舍。七八十种NoSQL数据库，多数采用弱一致性获得高扩展性下的快速响应。典型的如BASE（英文意思为“碱”），舍严格一致性，得最终一致性，与ACID（英文意思为“酸”）针锋相对。在具体实现上，也有不同的选择。BigTable类对于读是强一致性，对查询是最终一致性。而Amazon的DynamoDB提供可选择的一致性，根据服务/价格水平提供强一致性或最终一致性。Google的Megastore采用分层的一致性，在Entity Group内部采取满足ACID语义的强一致性，在Group之间则选择弱一致性。
文/ 吴甘沙
2012年写大数据文章，必先谈互联网的一分钟、过去两年数据占90%、一天数据产生量等于数万年、IDC的多少ZB，很唬人；2013年初拿舍恩伯格的三大思维说事，有品位；后来人人都说全量数据、相关性!=因果性时，意兴阑珊。所以转而专心关注技术文章。这一年接触了不少大数据的新技术，也形成了一些新的认识和体会，总结为五个方面：范式、舍得、安全、人机、价值。
范式
托马斯·库恩指出科学革命的结构起始于前科学，而范式的诞生使其进入常规科学。范式是一系列公认模型的集合体。大数据经过多年的积累和发展，现已存在一些模式、抽象和范型。我们从高层抽象、计算模型到底层架构，来看这些范式。
在高层抽象上，是数据管理与数据分析的融合。前大数据时代两者是分开的，事务型RDBMS（OLTP）与分析型RDBMS（OLAP）各行其道，打通两边还需ETL。EDW有数据管理但分析能力有限；R、SAS、SPSS这样的工具分析强，但能处理的数据通常为单节点的内存容量所限。大数据时代融合成为趋势，SAP ANA和NewSQL为代表的内存数据库平台采用列存储，在一套数据上实现OLTP和OLAP。所谓的Big SQL或SQL-on-Hadoop集大数据管理和简单分析能力于一身。对于更复杂的分析，以线性代数计算为代表，R、SAS、SPSS这样的分析工具纷纷寄生在大数据管理和处理平台上（如Hadoop）。Stonebraker等在英特尔大数据科学技术中心搞起了SciDB，称为数组DBMS，可以在数据库上原生地跑线性代数运算。
在计算模型上，以数据流为代表的范式大行其道。其中包括数据动、计算不动的流式计算，和数据不动、计算动的批量计算。对于后者，又分为二阶段的MapReduce、三阶段的BSP和DOT、更复杂的DAG和多迭代计算（如Spark和Tez）。另一个维度是并行特性，数据并行最容易、应用最广，而流式计算是任务并行、流水线并行。流式计算又分单记录和小批量，其中小批量又引入了数据
并行。
数据流表现为计算图，节点之间有数据依赖，同节点的数据间独立运算；而图计算工作于具有图结构的数据之上，数据间有局部的计算依赖，同时多迭代又呈现计算步之间的数据依赖。大数据为图计算带来的机会是图并行：因为图结构的稀疏性，多数顶点只有较小的邻域，这样，在一个迭代中整个图可以划分为很多并行处理的邻域。图并行中的复杂依赖必须有一致性保证，如GraphLab的多种一致性模型。其在分布式计算中的挑战是计算跨服务器的划分，具体来说：划分尽量均匀，应用哈希划分和图的边切割时注意data skew；通过镜像、最小切割等机制减少跨服务器依赖和通信；通过轻量级的任务调度和通信，例如U.T.Austin的
Galois可高效实现图计算。另外，计算模型的不同颗粒度和同步/异步模型也会影响性能。较之BSP的粗粒度、同步模型，GraphLab的异步、细粒度显著加速多迭代算法的收敛。单记录流式计算同样是异步、细粒度，延迟也低于同步、粗粒度的小批量流式计算。最近细粒度任务作为一种底层实现机制颇受青睐，例如伯克利的Tiny Tasks（可能会用在Spark上）和上述Galois。
流式、批量和迭代计算模型之间形成融合，如T w i t t e r ummingbird在编程接口层面融合，Lambda架构在应用框架层面通过增量计算和批量缓存实现融合，而Spark在实现框架层面完成融合，在这一层面微软也提出了Naiad和REEF来支持多计算模型。
在最底层的架构上，最热的范式是数据在存储层次上的上移，即内存计算。无论是分布式内存缓存、内存文件系统（如Tachyon）、内存数据库，还是内存计算框架（如Spark），内存是获得低延迟的主要途径。目前内存计算主要的问题是容量、容错和低延迟互联。未来三年，下一代非易失内存将登上舞台，与DRAM相近的性能、字节寻址、更大的容量和可持久性，预计将引发大数据软件栈的大变革，很多中间层将会被拿掉，容错更简单，虚拟内存、文件系统等都可能发生巨变。基于硅光的互联也将根本性改变大数据架构的风景，英特尔与康宁合作的MXC技术已经实现了单个lane 1.6Tb/s的带宽，结合英特尔的Rack Scale Architecture，有望实现计算、通信、存储和内存的完全分散化（disaggregated）架构，灵活地适配前文中不同高层范型。同时，新的互联结构也将改变目前过深的软件栈。希捷的Kinetic存储已经预示了这一方向，将原有架构中的操作系统层和存储层软件大幅简化；将硬盘设备IP化，置于以太网的另一端，在客户端直接呈现K/V式的对象存储接口。
架构的舍得
天下没有免费的午餐，突然偌大的数据洪流奔涌而来，原有的架构无法通过渐进优化应对。因此必须大胆舍，才能得。舍得的一种体现是舍大得小，例如以下几个方面。
数据压缩已成为所有大数据架构的标配，除Hadoop采用的几种压缩算法，2013年初Google开源的Zopfli以2-3个数量级的计算增量使压缩率提升3%~8%，更适合变化性较小的数据（压一次就行）。对多数系统，压缩解压缩发生在内存和I/O之间，内存里已是解压的数据。也有少数系统，如IBM的Netezza，数据在内存中仍保持压缩状态，在CPU读取时经由FPGA实时地流式解压，进一步提升了内存空间效率。
数据的列存储能够使压缩率获得数量级的提升，而它本身也是舍大得小的办法，因为往往查询并不需要访问所有列，所以数据加载时无需读入不相干的列。好的SQL优化器也对行存储做pruning。
采样和近似在精确度要求不高的情况下很有效。例如，BlinkDB通过离线和在线的两重采样，在100个节点的集群上对数十TB的数据进行查询，获得小于2秒的延迟，但同时误差率达到2%~10%。Shark和Facebook的Presto都有望集成BlinkDB。另一个例子是Druid采用HyperLogLog算法加速count distinct。
缓存机制也是天然的舍大得小。例如，分布式缓存根据数据的活性和局部性识别出活跃数据，并将其置于内存中。
为了得到计算的实时性，常常要舍旧数据、冷数据和静态数据。流式处理便是这样。2013年应该说是流式计算大热的一年，除老将Storm之外，Google的MillWheel、LinkedIn的Samza、伯克利的Spark Streaming和Twitter的Summingbird相继进入视野。此处的舍可以通过增量计算弥补，早几年有Google的Percolator，今年百度大数据首席架构师林仕鼎在《架构设计与架构师》中揭示百度存储中类似的实现，Storm作者Nathan Marz的书虽然跳票，但Lambda架构已经名满天下。反过来，舍实时的更新数据，只专注于较旧的惰性数据，也是得低延迟的办法。例如Google的Dremel，对只读的PB级数据实现秒级的即席查询。
以NoSQL数据库为代表的大数据架构多采用舍一致性来获得响应性和扩展性的设计。基于CAP理论，分布式系统既然不能舍P（分区容错），就必须在A（可用性）和C（一致性）有所取舍。七八十种NoSQL数据库，多数采用弱一致性获得高扩展性下的快速响应。典型的如BASE（英文意思为“碱”），舍严格一致性，得最终一致性，与ACID（英文意思为“酸”）针锋相对。在具体实现上，也有不同的选择。BigTable类对于读是强一致性，对查询是最终一致性。而Amazon的DynamoDB提供可选择的一致性，根据服务/价格水平提供强一致性或最终一致性。Google的Megastore采用分层的一致性，在Entity Group内部采取满足ACID语义的强一致性，在Group之间则选择弱一致性。
