原文链接：通过MATLAB处理大数据

大数据指的是创建的数据和供分析的数据的数量与速率迅速增加。大数据使分析师和数据专家有机会获得更好的见解，进行更明智的决策，但是它同时也会带来许多的挑战：可用的内存可能无法足以处理大数据集，可能需要花太久的时间进行处理或可能流动太快而无法存储标准算法通常不能以合理的时间或内存来处理大数据集等等。

目前没有任何一种单一方法可以处理大数据。为此，MATLAB提供了许多工具来解决这些挑战。

在MATLAB中处理大数据

1. 64位计算。

64位版本的MATLAB可快速增加内存中可保留的数据量 - 通常可达到任意32位程序的2000倍.32位程序限制您只能使用2 GB的内存，而64位MATLAB的内存可以达到操作系统的物理内存限制。对于Windows 8，台式机内存为500 GB，Windows Server内存为4 TB。

2.内存映射的变量。

借助MATLAB中的memmapfile函数，您可以将文件或文件的一部分映射到内存中的MATLAB变量。这样，您就可以高效访问磁盘上由于太大而无法保留在内存中或需要花太长时间而无法加载的大数据集。

磁盘变量。

matfile函数使您可以直接从磁盘上的MAT文件访问MATLAB变量（使用MATLAB索引命令），无需将全部变量加载到内存。这使您可以在大数据集上进行块处理，这些大数据集因为太大而无法保存在内存中。

4.内在的多核数学。

MATLAB中的许多内置数学函数，如fft，inv和eig都是多线程的。通过并行运行，这些函数充分利用计算机的多核，提供高性能的大数据集计算。

5. GPU计算。

如果您正在使用GPU，并行计算工具箱中的GPU优化的数学函数可以为大数据集提供更高的性能。

6.并行计算。

并行计算工具箱提供并行用于循环，该循环在多核计算机上并行运行您的MATLAB代码和算法。如果您使用MATLAB Distributed Computing Server，则可以在机器群集上并行执行，这些机器可扩展到数千台计算机。

7.云计算。

对于数百或数千台计算机的按需并行处理，您可以在Amazon Elastic Computing Cloud（亚马逊弹性计算云）（EC2）上使用MATLAB Distributed Computing Server并行运行MATLAB计算。借助云计算，您无需购买或维护您自己的群集或数据中心就可以处理大数据。

8.分布式阵列。

使用并行计算工具箱和MATLAB DistributedComputing Server，您可以处理分布在计算机群集内存中的矩阵和**数组。使用此方法，您可以针对因太大而无法由单台计算机内存处理的大数据集，进行存储和执行计算。

9.流式算法。

使用系统对象，您可以对因太大或太快而无法保留在内存中的数据传入流执行流式处理。此外，您还可以使用MATLAB编码器通过MATLAB算法生成嵌入式C / C ++代码，并针对高性能实时系统运行产生的代码。

10.图像块处理。

使用图像处理工具箱中的blockproc函数，您可以处理特别大的图像，方法是每次以模块的形式高效处理它们。与并行计算工具箱一起使用时，在多核和GPU上并行运行计算。

11. 机器学习。

机器学习有助于通过大数据集提取见解和开发预测性模型。广泛的机器学习算法，包括 Statistics and Machine Learning Toolbox 和 Neural Network Toolbox 中提供的促进式 (boosted) 。袋装 (bagged) 决策树、K 均值和分层聚类、k-最近邻搜索、高斯混合、期望最大化算法、隐马尔可夫模型和神经网络。

原文链接：3 simple ways to handle large data with
Pandas
作者 | George Seif
译者 | jojoa

易上手， 文档丰富的Pandas 已经成为时下最火的数据处理库。此外，Pandas数据处理能力也一流。

其实无论你使用什么库，大量的数据处理起来往往回遇到新的挑战。
数据处理时，往往会遇到没有足够内存（RAM）这个硬件问题。 企业往往需要能够存够数百， 乃至数千 的GB 数据。
即便你的计算机恰好有足够的内存来存储这些数据， 但是读取数据到硬盘依旧非常耗时。
别担心！ Pandas 数据库会帮我们摆脱这种困境。 这篇文章包含3种方法来减少数据大小，并且加快数据读取速度。 我用这些方法，把超过100GB 的数据， 压缩到了64GB 甚至32GB 的内存大小。

快来看看这三个妙招吧。

数据分块

csv 格式是一种易储存， 易更改并且用户易读取的格式。 pandas 有read_csv ()方法来上传数据，存储为CSV 格式。当遇到CSV 文件过大，导致内存不足的问题该怎么办呢？试试强大的pandas 工具吧！我们先把整个文件拆分成小块。这里，我们把拆分的小块称为chunk。

一个chunk 就是我们数据的一个小组。 Chunk 的大小主要依据我们内存的大小，自行决定。

过程如下：

1.读取一块数据。
2.分析数据。
3.保存该块数据的分析结果。
4.重复1-3步骤，直到所有chunk 分析完毕。
5.把所有的chunk 合并在一起。

我们可以通过read_csv()方法Chunksize来完成上述步骤。 Chunksize是指pandas 一次能读取到多少行csv文件。这个当然也是建立在RAM 内存容量的基础上。
假如我们认为数据呈现高斯分布时， 我们可以在一个chunk 上， 进行数据处理和视觉化， 这样会提高准确率。

当数据稍微复杂时， 例如呈现泊松分布时， 我们最好能一块块筛选，然后把每一小块整合在一起。 然后再进行分析。很多时候， 我们往往删除太多的不相关列，或者删除有值行。 我们可以在每个chunk 上，删除不相关数据， 然后再把数据整合在一起，最后再进行数据分析。

代码如下：

删除数据

有时候， 我们一眼就能看到需要分析的列。事实上， 通常名字，账号等列，我们是不做分析的。

读取数据前， 先跳过这些无用的列，可以帮我们节省很多内存。 Pandas 可以允许我们选择想要读取的列。

把包含无用信息的列删除掉， 往往给我们节省了大量内存。

此外，我们还可以把有缺失值的行，或者是包含“NA” 的行删除掉。 通过dropna()方法可以实现：

有几个非常有用的参数，可以传给dropna():

• how: 可选项：“any”(该行的任意一列如果出现”NA”， 删除该行)
• “all” (只有某行所有数数据全部是”NA” 时才删除)
• thresh: 设定某行最多包含多少个NA 时，才进行删除
• subset: 选定某个子集，进行NA 查找

可以通过这些参数， 尤其是thresh 和 subset 两个参数可以决定某行是否被删除掉。

Pandas 在读取信息的时候，无法删除列。但是我们可以在每个chunk 上，进行上述操作。

为列设定不同的数据类型

数据科学家新手往往不会对数据类型考虑太多。 当处理数据越来越多时， 就非常有必要考虑数据类型了。

行业常用的解决方法是从数据文件中，读取数据， 然后一列列设置数据类型。 但当数据量非常大时， 我们往往担心内存空间不够用。

在CSV 文件中，例如某列是浮点数， 它往往会占据更多的存储空间。 例如， 当我们下载数据来预测股票信息时， 价格往往以32位浮点数形式存储。

但是，我们真的需要32位浮点数码？ 大多数情况下， 股票价格以小数点后保留两位数据进行交易。 即便我们想看到更精确的数据， 16位浮点数已经足够了。

我们往往会在读取数据的时候， 设置数据类型，而不是保留数据原类型。 那样的话，会浪费掉部分内存。

通过read_csv() 中设置dtype参数来完成数据类型设置。还可以设置字典类型，设置该列是键， 设置某列是字典的值。

请看下面的pandas 例子：

文章到这里结束了！ 希望上述三个方法可以帮你节省时间和内存。

为什么使用Hadoop生态系统处理大数据而不是高性能关系型数据库

    面对这样的问题，不知道大家会什么样的思考，建议大家先思考一下然后带着自己的答案，在来看看我的看法。当然，这只是我个人的见解并非绝对的标准，其实这也没有一个固定的答案。

     在设计使用分布式Hadoop生态系统，如使用HDFS进行冗余、高容错地存储大数据、使用MapReduce分布式并行离线处理大数据等。而没有使用高效性能的关系型数据库，尽管关系型数据库可以快速处理用户事务数据，可以实现较为复杂的表间关联操作等。首先，是因为考虑磁盘瓶颈的原因，磁盘读写最大的瓶颈就是处理速度，如今的磁盘一般可能在100MB/S或者可能再好一些，但是就是这样的读取速度，如果要读取1TB的数据大约要2.5小时。那么面对如今动辄几百TB，有时甚至是更加庞大的PB级数据（随着数据量增大，更加大级也必然到来）。因为磁盘是寻址读取方式，而且通常是要读取所有的数据才能进行操作，可想如果是几百TB的数据，那么可能就读取就需要几百上千个小时。那么如果能把数据分散在多台机器上并行读取那么理论上其速度必然是大幅度提升，如1TB存放在100个磁盘上，那么每个存放10GB的数据，读取完1TB数据大约需要100S。而且HDFS提供的是流式数据处理，也就是数据读取部分即可处理而并非读取所有数据。可能会问这样怎么对数据做整体操作，这个问题被考虑在MapReduce框架中，因为MapReduce计算框架天生就是key-value形式，然后对数据块不到merge的过程。所以最终经过MapReduce的数据会完成整体性的。所以在当前大数据如此盛行、需求量如此大的情况下，考虑磁盘因素应该是使用Hadoop等生态系统的首要因素。

       再有大家应该了解，一般提升性能的方式可能有两种，一种是垂直提升也就是通过不断地加大内存、cpu、硬盘等方式来提高单独服务器的性能，还有一种是水平提升也就是通过利用分布式不断添加机器到集群的方式。通过使用垂直提升方式，必然会达到一定的极限，就抛开这个硬件的极限认为它可以根据需要不断地提升，那么这样提升的费用也是昂贵的。而且对于存储数据仓库信息，这里还存在着单点故障的问题。而如果使用分布式形式，那么扩展通常就是简单的添加机器附上平台软件即可，操作十分简便。而且设计也可以利用其一些相对报废的机器组成集群，而且这样的分布式系统一般都会存储多份数据形成高容错。

        再者，是关系型数据库在针对处理数据表直接复杂的关联操作等便利，而Hadoop生态系统中的HBase数据库则不可以做这样的复杂关联操作。如果说Hive可以实现，那么Hive的一般延迟是不符合数据库要求的，它是数据仓库。但是一般对大数据处理通常是不需要进行复杂的关联操作，基本上都是行列的分析与处理。所以Hadoop平台就是考虑了大数据的特性而诞生的产品。当然，不能说Hadoop就比关系型数据库强了，应该说是具体问题具体对待、各有千秋，在处理事务和用户交互等数据方面，关系型数据库占据了不可动摇的地位。而且关系型数据库产品多样，技术也相对十分成熟。还有一点在使用关系型数据库时，一般分为两层sql level 和 读取数据，而其中sql层就是实现把查询语句分解、优化、形成搜索树等，这一套逻辑十分耗时。而NoSQL就是弱化了sql 层，只留下了提取数据层，所以相对的在处理大数据上HBase会更加快速。

         随着Hadoop的不断发展，其家族产品也陆续登场，如Hive、HBase、Spark、Storm、Mahout等等，这些都是为了满足特定的大数据场景需求而产生的。所以相对于使用场景已基本固化的关系型数据库，Hadoop就显得更加合理、适用。而且Hadoop等都是开源项目，有开源社区和大多技术者的支持，所以其发展和维护等也在向着越来越好的方向发展。而且在做数据仓库等时，关系型数据主要基于SQL语言，而Hadoop有SQL型、Java、Python等，融入的技术人才多样性，也必然会推导项目业务的多样化健康化发展。

以上即为为个人看法，如果认为有误的或者有遗漏的，欢迎大家留言补充。