spark,neo4j

Spark内存计算体现它可以将RDD常驻内存（内存不足也会溢写到磁盘的），这样可以减少磁盘IO。缺点的话我觉得在于1.资源调度方面，Spark和Hadoop不同，执行时采用的是多线程模式，Hadoop是多进程，多线程模式会减少启动时间，但也带来了无法细粒度资源分配的问题。但本质上讲其实这也不能算是Spark的缺点，只不过是tradeoff之后的结果而已。2.其实Spark这种利用内存计算的思想的分布式系统你想要最大发挥其性能优势的话对集群资源配置要求较高，比如内存（当然内存不足也能用），通俗地说就是比较烧钱。其余的坑以后再填

 

1.Spark的内存计算 主要体现在哪里？
(a) spark, 相比与map reduce最大的速度提升在于做重复计算时，spark可以重复使用相关的缓存数据，而M/R则会笨拙的不断进行disk i/o. (b) 为了提高容错性，M/R所有的中间结果都会persist到disk， 而M/R 则默认保存在内存。

2.目前Spark主要存在哪些缺点？
(a) JVM的内存overhead太大，1G的数据通常需要消耗5G的内存 -> Project Tungsten 正试图解决这个问题；
(b) 不同的spark app之间缺乏有效的共享内存机制 -> Project Tachyon 在试图引入分布式的内存管理，这样不同的spark app可以共享缓存的数据

 

缺点吧。
1. 不稳定，集群偶尔会挂掉。只适合做计算，不适合直接提供服务。
2. 数据的partition不够好，会导致集群中的各台机器上计算任务分配不平均。
3. 任务调度不够好

 

1.对象关系的不匹配使得把面向对象的“圆的对象”挤到面向关系的“方的表”中是那么的困难和费劲，而这一切是可以避免的。

2.关系模型静态、刚性、不灵活的本质使得改变schemas以满足不断变化的业务需求是非常困难的。由于同样的原因，当开发小组想应用敏捷软件开发时，数据库经常拖后腿。

3.关系模型很不适合表达半结构化的数据——而业界的分析家和研究者都认为半结构化数据是信息管理中的下一个重头戏。

4.网络是一种非常高效的数据存储结构。人脑是一个巨大的网络，万维网也同样构造成网状，这些都不是巧合。关系模型可以表达面向网络的数据，但是在遍历网络并抽取信息的能力上关系模型是非常弱的。

虽然Neo是一个比较新的开源项目，但它已经在具有1亿多个节点、关系和属性的产品中得到了应用，并且能满足企业的健壮性和性能的需求：

完全支持JTA和JTS、2PC分布式ACID事务、可配置的隔离级别和大规模、可测试的事务恢复。这些不仅仅是口头上的承诺：Neo已经应用在高请求的24/7环境下超过3年了。它是成熟、健壮的，完全达到了部署的门槛。

图：是指数据原理里的树集合成的网络。

Neo4j是一个嵌入式，基于磁盘的，支持完整事务的Java持久化引擎，它在图(网络)中而不是表中存储数据。Neo4j提供了大规模可扩展性，在一台机器上可以处理数十亿节点/关系/属性的图，可以扩展到多台机器并行运行。相对于关系数据库来说，图数据库善于处理大量复杂、互连接、低结构化的数据，这些数据变化迅速，需要频繁的查询——在关系数据库中，这些查询会导致大量的表连接，因此会产生性能上的问题。Neo4j重点解决了拥有大量连接的传统RDBMS在查询时出现的性能衰退问题。通过围绕图进行数据建模，Neo4j会以相同的速度遍历节点与边，其遍历速度与构成图的数据量没有任何关系。此外，Neo4j还提供了非常快的图算法、推荐系统和OLAP风格的分析，而这一切在目前的RDBMS系统中都是无法实现的。

由于使用了“面向网络的数据库”，人们对Neo充满了好奇。在该模型中，以“节点空间”来表达领域数据——相对于传统的模型表、行和列来说，节点空间是很多节点、关系和属性（键值对）构成的网络。关系是第一级对象，可以由属性来注解，而属性则表明了节点交互的上下文。网络模型完美的匹配了本质上就是继承关系的问题域，例如语义Web应用。Neo的创建者发现继承和结构化数据并不适合传统的关系数据库模型

首先，Hadoop和Apache Spark两者都是大数据框架，但是各自存在的目的不尽相同。Hadoop实质上更多是一个分布式数据基础设施: 它将巨大的数据集分派到一个由普通计算机组成的集群中的多个节点进行存储，意味着您不需要购买和维护昂贵的服务器硬件。

同时，Hadoop还会索引和跟踪这些数据，让大数据处理和分析效率达到前所未有的高度。Spark，则是那么一个专门用来对那些分布式存储的大数据进行处理的工具，它并不会进行分布式数据的存储。

两者可合可分

Hadoop除了提供为大家所共识的HDFS分布式数据存储功能之外，还提供了叫做MapReduce的数据处理功能。所以这里我们完全可以抛开Spark，使用Hadoop自身的MapReduce来完成数据的处理。

相反，Spark也不是非要依附在Hadoop身上才能生存。但如上所述，毕竟它没有提供文件管理系统，所以，它必须和其他的分布式文件系统进行集成才能运作。这里我们可以选择Hadoop的HDFS,也可以选择其他的基于云的数据系统平台。但Spark默认来说还是被用在Hadoop上面的，毕竟，大家都认为它们的结合是最好的。

以下是从网上摘录的对MapReduce的最简洁明了的解析:

  我们要数图书馆中的所有书。你数1号书架，我数2号书架。这就是“Map”。我们人越多，数书就更快。

现在我们到一起，把所有人的统计数加在一起。这就是“Reduce”。

Spark数据处理速度秒杀MapReduce

Spark因为其处理数据的方式不一样，会比MapReduce快上很多。MapReduce是分步对数据进行处理的: ”从集群中读取数据，进行一次处理，将结果写到集群，从集群中读取更新后的数据，进行下一次的处理，将结果写到集群，等等…“ Booz Allen Hamilton的数据科学家Kirk Borne如此解析。

反观Spark，它会在内存中以接近“实时”的时间完成所有的数据分析：“从集群中读取数据，完成所有必须的分析处理，将结果写回集群，完成，” Born说道。Spark的批处理速度比MapReduce快近10倍，内存中的数据分析速度则快近100倍。

如果需要处理的数据和结果需求大部分情况下是静态的，且你也有耐心等待批处理的完成的话，MapReduce的处理方式也是完全可以接受的。

但如果你需要对流数据进行分析，比如那些来自于工厂的传感器收集回来的数据，又或者说你的应用是需要多重数据处理的，那么你也许更应该使用Spark进行处理。

大部分机器学习算法都是需要多重数据处理的。此外，通常会用到Spark的应用场景有以下方面：实时的市场活动，在线产品推荐，网络安全分析，机器日记监控等。

灾难恢复

两者的灾难恢复方式迥异，但是都很不错。因为Hadoop将每次处理后的数据都写入到磁盘上，所以其天生就能很有弹性的对系统错误进行处理。

Spark的数据对象存储在分布于数据集群中的叫做弹性分布式数据集(RDD: Resilient Distributed Dataset)中。“这些数据对象既可以放在内存，也可以放在磁盘，所以RDD同样也可以提供完成的灾难恢复功能，”Borne指出