大数据分析工具有：
①.、R-编程
R 编程是对所有人免费的最好的大数据分析工具之一.它是一种领先的统计编程语言,可用于统计分析、科学计算、数据可视化等.R 编程语言还可以扩展自身以执行各种大数据分析操作.
在这个强大的帮助下；语言,数据科学家可以轻松创建统计引擎,根据相关和准确的数据收集提供更好、更精确的数据洞察力.它具有类数据处理和存储.我们还可以在 R 编程中集成其他数据分析工具.
除此之外,您还可以与任何编程语言（例如 Java、C、Python）集成,以提供更快的数据传输和准确的分析.R 提供了大量可用于任何数据集的绘图和图形.
Apache Hadoop 是领先的大数据分析工具开源.它是一个软件框架,用于在商品硬件的集群上存储数据和运行应用程序.它是由软件生态系统组成的领先框架.
Hadoop 使用其 Hadoop 分布式文件系统或 HDFS 和 MapReduce.它被认为是大数据分析的顶级数据仓库.它具有在数百台廉价服务器上存储和分发大数据集的惊人能力.
这意味着您无需任何额外费用即可执行大数据分析.您还可以根据您的要求向其添加新节点,它永远不会让您失望.
MongoDB 是世界领先的数据库软件.它基于 NoSQL 数据库,可用于存储比基于 RDBMS 的数据库软件更多的数据量.MongoDB 功能强大,是最好的大数据分析工具之一.
它使用集合和文档,而不是使用行和列.文档由键值对组成,即MongoDB 中的一个基本数据单元.文档可以包含各种单元.但是大小、内容和字段数量因 MongoDB 中的文档而异.
MongoDB 最好的部分是它允许开发人员更改文档结构.文档结构可以基于程序员在各自的编程语言中定义的类和对象.
MongoDB 有一个内置的数据模型,使程序员能够理想地表示层次关系来存储数组和其他元素.
RapidMiner 是分析师集成数据准备、机器学习、预测模型部署等的领先平台之一.它是最好的免费大数据分析工具,可用于数据分析和文本挖掘.
它是最强大的工具,具有用于分析过程设计的一流图形用户界面.它独立于平台,适用于 Windows、Linux、Unix 和 macOS.它提供各种功能,例如安全控制,在可视化工作流设计器工具的帮助下减少编写冗长代码的需要.
它使用户能够采用大型数据集在 Hadoop 中进行训练.除此之外,它还允许团队协作、集中工作流管理、Hadoop 模拟等.
它还组装请求并重用 Spark 容器以对流程进行智能优化.RapidMiner有五种数据分析产品,即RapidMiner Studio Auto Model、Auto Model、RapidMiner Turbo Prep、RapidMiner Server和RapidMiner Radoop.
Apache Spark 是最好、最强大的开源大数据分析工具之一.借助其数据处理框架,它可以处理大量数据集.通过结合或其他分布式计算工具,在多台计算机上分发数据处理任务非常容易.
它具有用于流式 SQL、机器学习和图形处理支持的内置功能.它还使该站点成为大数据转换的最快速和通用的生成器.我们可以在内存中以快 100 倍的速度处理数据,而在磁盘中则快 10 倍.
Microsoft Azure 是领先的大数据分析工具之一.Microsoft Azure 也称为 Windows Azure.它是 Microsoft 处理的公共云计算平台,是提供包括计算、分析、存储和网络在内的广泛服务的领先平台.
Windows Azure 提供两类标准和高级的大数据云产品.它可以无缝处理大量数据工作负载.
除此之外,Microsoft Azure 还拥有一流的分析能力和行业领先的 SLA 以及企业级安全和监控.它也是开发人员和数据科学家的最佳和高效平台.它提供了在最先进的应用程序中很容易制作的实时数据.
无需 IT 基础架构或虚拟服务器进行处理.它可以轻松嵌入其他编程语言,如 JavaScript 和 C#.
Zoho Analytics 是最可靠的大数据分析工具之一.它是一种 BI 工具,可以无缝地用于数据分析,并帮助我们直观地分析数据以更好地理解原始数据.
同样,任何其他分析工具都允许我们集成多个数据源,例如业务应用程序、数据库软件、云存储、CRM 等等.我们还可以在方便时自定义报告,因为它允许我们生成动态且高度自定义的可操作报告.
在 Zoho 分析中上传数据也非常灵活和容易.我们还可以在其中创建自定义仪表板,因为它易于部署和实施.世界各地的用户广泛使用该平台.此外,它还使我们能够在应用程序中生成评论威胁,以促进员工和团队之间的协作.
它是最好的大数据分析工具,与上述任何其他工具相比,它需要的知识和培训更少.所以呢,它是初创企业和入门级企业的最佳选择.
以上内容参考 百度百科——大数据分析
关系数据库经过几十年的发展,已经非常成熟,但同时也存在不足：
表结构是强约束的,业务变更时扩充很麻烦.
如果对大数据量的表进行统计运算,I/O会很高,因为即使只针对某列进行运算,也需要将整行数据读入内存.
全文搜索只能使用 Like 进行整表扫描,性能非常低.
针对这些不足,产生了不同的 NoSQL 解决方案,在某些场景下比关系数据库更有优势,但同时也牺牲了某些特性,所以不能片面的迷信某种方案,应将其作为 SQL 的有利补充.
NoSQL != No SQL,而是：
NoSQL = Not Only SQL
Redis 是典型,其 value 是具体的数据结构,包括 string, hash, list, set, sorted set, bitmap, hyperloglog,常被称为数据结构服务器.
以 list 为例：
LPOP key 是移除并返回队列左边的第一个元素.
如果用关系数据库就比较麻烦了,需要操作：
Redis 的缺点主要体现在不支持完成的ACID事务,只能保证隔离性和一致性,无法保证原子性和持久性.
最大的特点是 no-schema,无需在使用前定义字段,读取一个不存在的字段也不会导致语法错误.
特点：
以电商为例,不同商品的属性差异很大,如冰箱和电脑,这种差异性在关系数据库中会有很大的麻烦,而使用文档数据库则非常方便.
文档数据库的主要缺点：
关系数据库是按行来存储的,列式数据库是按照列来存储数据.
按行存储的优势：
在某些场景下,这些优势就成为劣势了,例如,计算超重人员的数据,只需要读取体重这一列进行统计即可,但行式存储会将整行数据读取到内存中,很浪费.
而列式存储中,只需要读取体重这列的数据即可,I/O 将大大减少.
列式存储的随机写效率远低于行式存储,因为行式存储时同一行多个列都存储在连续空间中,而列式存储将不同列存储在不连续的空间.
一般将列式存储应用在离线大数据分析统计场景,因为这时主要针对部分列进行操作,而且数据写入后无须更新.
关系数据库通过索引进行快速查询,但在全文搜索的情景下,索引就不够了,因为：
假设有一个交友网站,信息表如下：
需要匹配性别、地点、语言列.
需要匹配性别、地点、爱好列.
实际搜索中,各种排列组合非常多,关系数据库很难支持.
全文搜索引擎是使用 倒排索引 技术,建立单词到文档的索引,例如上面的表信息建立倒排索引：
所以特别适合根据关键词来查询文档内容.
上面介绍了几种典型的NoSQL方案,及各自的适用场景和特点,您可以根据实际需求进行选择.
本质是因为：随着互联网的进一步发展与各行业信息化建设进程加快、参与者的增多,人们对软件有了更多更新的要求,需要软件不仅能实现功能,而且要求保证许多人可以共同参与使用,因而软件所需承载的数据量和吞吐量必须达到相应的需求.而目前的关系型数据库在某些方面有一些缺点,导致不能满足需要.
具体则需要对比关系型数据库与Nosql之间的区别可以得出
关系型数据库
关系型数据库把所有的数据都通过行和列的二元表现形式表示出来.
关系型数据库的优势：
①?保持数据的一致性（事务处理）
其中能够保持数据的一致性是关系型数据库的最大优势.
关系型数据库的不足：
不擅长的处理
①?大量数据的写入处理（这点尤为重要）
--大量数据的写入处理
读写集中在一个数据库上让数据库不堪重负,大部分网站已使用主从复制技术实现读写分离,以提高读写性能和读库的可扩展性.
所以在进行大量数据操作时,会使用数据库主从模式.数据的写入由主数据库负责,数据的读入由从数据库负责,可以比较简单地通过增加从数据库来实现规模化,但是数据的写入却完全没有简单的方法来解决规模化问题.
第一,要想将数据的写入规模化,可以考虑把主数据库从一台增加到两台,作为互相关联复制的二元主数据库使用,确实这样可以把每台主数据库的负荷减少一半,但是更新处理会发生冲突,可能会造成数据的不一致,为了避免这样的问题,需要把对每个表的请求分别分配给合适的主数据库来处理.
第二,可以考虑把数据库分割开来,分别放在不同的数据库服务器上,比如将不同的表放在不同的数据库服务器上,数据库分割可以减少每台数据库服务器上的数据量,以便减少硬盘IO的输入、输出处理,实现内存上的高速处理.但是由于分别存储字不同服务器上的表之间无法进行Join处理,数据库分割的时候就需要预先考虑这些问题,数据库分割之后,如果一定要进行Join处理,就必须要在程序中进行关联,这是非常困难的.
--为有数据更新的表做索引或表结构变更
在使用关系型数据库时,为了加快查询速度需要创建索引,为了增加必要的字段就一定要改变表结构,为了进行这些处理,需要对表进行共享锁定,这期间数据变更、更新、插入、删除等都是无法进行的.如果需要进行一些耗时操作,例如为数据量比较大的表创建索引或是变更其表结构,就需要特别注意,长时间内数据可能无法进行更新.
--字段不固定时的应用
如果字段不固定,利用关系型数据库也是比较困难的,有人会说,需要的时候加个字段就可以了,这样的方法也不是不可以,但在实际运用中每次都进行反复的表结构变更是非常痛苦的.你也可以预先设定大量的预备字段,但这样的话,时间一长很容易弄不清除字段和数据的对应状态,即哪个字段保存有哪些数据.
--对简单查询需要快速返回结果的处理? （这里的"简单"指的是没有复杂的查询条件）
这一点称不上是缺点,但不管怎样,关系型数据库并不擅长对简单的查询快速返回结果,因为关系型数据库是使用专门的sql语言进行数据读取的,它需要对sql与越南进行解析,同时还有对表的锁定和解锁等这样的额外开销,这里并不是说关系型数据库的速度太慢,而只是想告诉大家若希望对简单查询进行高速处理,则没有必要非使用关系型数据库不可.
NoSQL数据库
关系型数据库应用广泛,能进行事务处理和表连接等复杂查询.相对地,NoSQL数据库只应用在特定领域,基本上不进行复杂的处理,但它恰恰弥补了之前所列举的关系型数据库的不足之处.
优点：
易于数据的分散
各个数据之间存在关联是关系型数据库得名的主要原因,为了进行join处理,关系型数据库不得不把数据存储在同一个服务器内,这不利于数据的分散,这也是关系型数据库并不擅长大数据量的写入处理的原因.相反NoSQL数据库原本就不支持Join处理,各个数据都是独立设计的,很容易把数据分散在多个服务器上,故减少了每个服务器上的数据量,即使要处理大量数据的写入,也变得更加容易,数据的读入操作当然也同样容易.
典型的NoSQL数据库
临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase）
第一段： 键值存储
它的数据是以键值的形式存储的,虽然它的速度非常快,但基本上只能通过键的完全一致查询获取数据,根据数据的保存方式可以分为临时性、永久性和两者兼具 三种.
（1）临时性
所谓临时性就是数据有可能丢失,memcached把所有数据都保存在内存中,这样保存和读取的速度非常快,但是当memcached停止时,数据就不存在了.由于数据保存在内存中,所以无法操作超出内存容量的数据,旧数据会丢失.总结来说：
.在内存中保存数据
.可以进行非常快速的保存和读取处理
.数据有可能丢失
所谓永久性就是数据不会丢失,这里的键值存储是把数据保存在硬盘上,与临时性比起来,由于必然要发生对硬盘的IO操作,所以性能上还是有差距的,但数据不会丢失是它最大的优势.总结来说：
.在硬盘上保存数据
.可以进行非常快速的保存和读取处理（但无法与memcached相比）
.数据不会丢失
.同时在内存和硬盘上保存数据
.保存在硬盘上的数据不会消失（可以恢复）
.适合于处理数组类型的数据
第二段：面向文档的数据库
MongoDB、CouchDB属于这种类型,它们属于NoSQL数据库,但与键值存储相异.
（1）不定义表结构
即使不定义表结构,也可以像定义了表结构一样使用,还省去了变更表结构的麻烦.
跟键值存储不同的是,面向文档的数据库可以通过复杂的查询条件来获取数据,虽然不具备事务处理和Join这些关系型数据库所具有的处理能力,但初次以外的其他处理基本上都能实现.
第三段：?面向列的数据库
Cassandra、HBae、HyperTable属于这种类型,由于近年来数据量出现爆发性增长,这种类型的NoSQL数据库尤其引入注目.
普通的关系型数据库都是以行为单位来存储数据的,擅长以行为单位的读入处理,比如特定条件数据的获取.所以呢,关系型数据库也被成为面向行的数据库.相反,面向列的数据库是以列为单位来存储数据的,擅长以列为单位读入数据.
面向列的数据库具有搞扩展性,即使数据增加也不会降低相应的处理速度（特别是写入速度）,所以它主要应用于需要处理大量数据的情况.另外,把它作为批处理程序的存储器来对大量数据进行更新也是非常有用的.但由于面向列的数据库跟现行数据库存储的思维方式有很大不同,故应用起来十分困难.
总结：关系型数据库与NoSQL数据库并非对立而是互补的关系,即通常情况下使用关系型数据库,在适合使用NoSQL的时候使用NoSQL数据库,让NoSQL数据库对关系型数据库的不足进行弥补.
NoSQL不像传统关系型库那样有统一的标准,也不具有普适性.所以要根据应用和数据的存取特征来选择适合的NoSQL.如果以前没有接触过NoSQL,MongoDB是一个比较好的选择,他支持的所以和查询能力是所有NoSQL中最强大的,缺点是索引的成本和文档大小限制.如果是使用Hadoop大数据分析,数据基本上不存在修改,只是插入和查询,并且需要配合Hadoop的MR任务,HBase会是很好的选择.如果要求有很强的扩展能力,高并发读写和维护方便,Casaandra则是不错的选择.当然除了上面三个流行的NoSQL,还有很多优秀的NoSQL数据库,而且他们都有各自擅长领域,所以需要了解你们产品自身的特点然后分析选择哪种才是最适合的,往往在大型系统中不是单一的数据库,而是使用多种数据库组合.