内存计算

阿里云数据事业部强琦为大家带来内存计算方面的内容，本文主要从软硬件趋势、分布式计算简史与内存计算开始谈起，包括HIVE、ADS的介绍，接着分析了统一的计算框架，最后讲解了Spark和Flink经典的系统技术分析。一起来了解下吧。



软硬件趋势

我们现在使用的主流硬件从多核CPU 32核/56核，内存192G /384G，以及定制机型下更大的内存，存储层级可以做到三T的SSD/11×6T的SATA硬盘，而网络拓扑和带宽从IDC内的万兆网卡到IDC间的专线光缆，还有大数据和它的复用程度，读写比比较高的数据是业务价值极高的数据，我们可以针对不同的读写比的数据进行不同的系统优化，随之而来会有相应的问题：

从小型机到分布式到单机能力提升，矛盾么？
是否单机能力越强越好？
构建在虚拟机上的分布式?
数据密集型的计算可能会根据不同的计算平台选定不同的机型号，这就需要看计算任务到底 短板和瓶颈在哪里，比如瓶颈在CPU，那我们适当的增加CPU核心，把混合存储和内存降下来，这样可以有效的提高整个的资源利用率。

从现在的软硬件趋势可以看到，无疑CPU越来越快、memory越来越大、存储层级越来越丰富。



分布式计算简史与内存计算

经典的DataBase（DB）和现在比较火的BigData（BD）有哪些异同点呢？

从DataBase来看，数据是业务用户产生的，数据都必须schema化，而且保证强一致性，支持随机访问，数据实时的insert要能实时的查询，数据的访问按照CIUD集中的范式，机房是分散的，注重延时，还有一些其他显著特征，这是经典的OLTP的类似功能。

现在涌现的BigData技术体系，它的数据源是业务db或者log等，强调宽表，注重扫描，它是离线数据，侧重于数据计算，机房集中，BD重吞吐，最经典的领域就是数据仓库 OLAP。

DB势必要影响BD，而BD的一些技术最终也会推进DB领域的技术演进。

BigData

BD的数据有什么特点如下：

Volume、Velocity、Variety。

它的数据量是极其巨大的，对成本的要求非常苛刻；速度方面，数据不再以天、小时为单位，数据入口的吞吐、整个的时效性和用户的体验都有非常高的要求；多样性方面，数据怎么融合，数据源采集非常广泛，格式也是五花八门，对质量的把控也完全不一样。

今天BigData所面临的情况与DataBase不可同日而语，面临着巨大的复杂性和难度。

BD数据量有扩展性、有成本问题，BD的技术栈表示能力也是从支持机器学习到非SQL领域， 从半结构化到非结构化，它的计算模式以扫描为主。

GFS

分布式计算作为软件系统，也有着它与之匹配的演进。

在工业界、产业界，分布式计算蓬勃发展有赖于GFS，很快就对应着开源实现，HDFS开源社区的蓬勃发展，在某种程度上，也给国内的技术从业者提供了很大的学习机会。

GFS主要是进行大文件或者快文件的存储，在GFS之上的系统可以把小文件合并成大文件，然后进行存储，流式文件同样根据它写入的特征特点和它读取的特点，在大文件上可以封装出流式文件；
GFS具备不可修改性，在这种情况下，可以封装出Mutable的功能特性，比如说LSM可以支持随机读写；
GFS扩展性可以达到跨核心、跨IDC、跨国；
GFS使用廉价的服务器降低成本，通过replication来增加它的可靠性。
编程模型

在此之前，普通的技术开发者很难在集群上编写分布式程序和并行程序，编程模型在其表达能力方面，从RPC到MPI到SQL，它的表达能力是在不断的降弱，但是它的应用型是在不断的增强。

要在分布式上编程，程序怎么能做到扩展性？

如何根据网络拓扑来切分任务，怎么利用数据存储的本地化来避免不必要的网络传输和网络带宽？
如何去容错？1000台服务器的集群，只要有任意一个有故障，都算做整个集群有故障。
长尾效应。
无论是异构机型还是异构的网络拓普，或是根据数据分布的data scale，都会造成长尾效应，计算会被其中最慢的那个节点拖后腿，长尾会对整个用户提交任务的延时和对雪崩造成非常大的伤害。

计算逻辑和编程模型表示方面，ETL的工程师大多希望使用SQL建模的工程师，也会使用OLAP，而机器学习由于其对性能的极致要求，用户会希望系统开放最底层接口。

表示能力和自由度其实是一对treadoff，表示能力越强约束就越少，如果对原语进行约束，系统就会做很多failover。

MapReduce
全文连接http://click.aliyun.com/m/22540/