Hadoop
成都创新互联公司自2013年创立以来，是专业互联网技术服务公司，拥有项目成都网站设计、成都做网站、外贸网站建设网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元府谷做网站,已为上家服务,为府谷各地企业和个人服务,联系电话:18980820575
文件系统：文件系统是用来存储和管理文件，并且提供文件的查询、增加、删除等操作。
直观上的体验：在shell窗口输入 ls 命令，就可以看到当前目录下的文件夹、文件。
文件存储在哪里？硬盘
一台只有250G硬盘的电脑，如果需要存储500G的文件可以怎么办？先将电脑硬盘扩容至少250G，再将文件分割成多块，放到多块硬盘上储存。
通过 hdfs dfs -ls 命令可以查看分布式文件系统中的文件，就像本地的ls命令一样。
HDFS在客户端上提供了查询、新增和删除的指令，可以实现将分布在多台机器上的文件系统进行统一的管理。
在分布式文件系统中，一个大文件会被切分成块，分别存储到几台机器上。结合上文中提到的那个存储500G大文件的那个例子，这500G的文件会按照一定的大小被切分成若干块，然后分别存储在若干台机器上，然后提供统一的操作接口。
看到这里，不少人可能会觉得，分布式文件系统不过如此，很简单嘛。事实真的是这样的么？
潜在问题
假如我有一个1000台机器组成的分布式系统，一台机器每天出现故障的概率是0.1%，那么整个系统每天出现故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一个容错机制来保证发生差错时文件依然可以读出，这里暂时先不展开介绍。
如果要存储PB级或者EB级的数据，成千上万台机器组成的集群是很常见的，所以说分布式系统比单机系统要复杂得多呀。
这是一张HDFS的架构简图：
client通过nameNode了解数据在哪些DataNode上，从而发起查询。此外，不仅是查询文件，写入文件的时候也是先去请教NameNode，看看应该往哪个DateNode中去写。
为了某一份数据只写入到一个Datanode中，而这个Datanode因为某些原因出错无法读取的问题，需要通过冗余备份的方式来进行容错处理。因此，HDFS在写入一个数据块的时候，不会仅仅写入一个DataNode，而是会写入到多个DataNode中，这样，如果其中一个DataNode坏了，还可以从其余的DataNode中拿到数据，保证了数据不丢失。
实际上，每个数据块在HDFS上都会保存多份，保存在不同的DataNode上。这种是牺牲一定存储空间换取可靠性的做法。
接下来我们来看一下完整的文件写入的流程：
大文件要写入HDFS，client端根据配置将大文件分成固定大小的块，然后再上传到HDFS。
读取文件的流程：
1、client询问NameNode，我要读取某个路径下的文件，麻烦告诉我这个文件都在哪些DataNode上？
2、NameNode回复client，这个路径下的文件被切成了3块，分别在DataNode1、DataNode3和DataNode4上
3、client去找DataNode1、DataNode3和DataNode4，拿到3个文件块，通过stream读取并且整合起来
文件写入的流程：
1、client先将文件分块，然后询问NameNode，我要写入一个文件到某个路径下，文件有3块，应该怎么写？
2、NameNode回复client，可以分别写到DataNode1、DataNode2、DataNode3、DataNode4上，记住，每个块重复写3份，总共是9份
3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把数据写到他们上面
出于容错的考虑，每个数据块有3个备份，但是3个备份快都直接由client端直接写入势必会带来client端过重的写入压力，这个点是否有更好的解决方案呢？回忆一下mysql主备之间是通过binlog文件进行同步的，HDFS当然也可以借鉴这个思想，数据其实只需要写入到一个datanode上，然后由datanode之间相互进行备份同步，减少了client端的写入压力，那么至于是一个datanode写入成功即成功，还是需要所有的参与备份的datanode返回写入成功才算成功，是可靠性配置的策略，当然这个设置会影响到数据写入的吞吐率，我们可以看到可靠性和效率永远是“鱼和熊掌不可兼得”的。
潜在问题
NameNode确实会回放editlog，但是不是每次都从头回放，它会先加载一个fsimage，这个文件是之前某一个时刻整个NameNode的文件元数据的内存快照，然后再在这个基础上回放editlog，完成后，会清空editlog，再把当前文件元数据的内存状态写入fsimage，方便下一次加载。
这样，全量回放就变成了增量回放，但是如果NameNode长时间未重启过，editlog依然会比较大，恢复的时间依然比较长，这个问题怎么解呢？
SecondNameNode是一个NameNode内的定时任务线程，它会定期地将editlog写入fsimage，然后情况原来的editlog，从而保证editlog的文件大小维持在一定大小。
NameNode挂了， SecondNameNode并不能替代NameNode，所以如果集群中只有一个NameNode，它挂了，整个系统就挂了。hadoop2.x之前，整个集群只能有一个NameNode，是有可能发生单点故障的，所以hadoop1.x有本身的不稳定性。但是hadoop2.x之后，我们可以在集群中配置多个NameNode，就不会有这个问题了，但是配置多个NameNode，需要注意的地方就更多了，系统就更加复杂了。
俗话说“一山不容二虎”，两个NameNode只能有一个是活跃状态active，另一个是备份状态standby，我们看一下两个NameNode的架构图。
两个NameNode通过JournalNode实现同步editlog，保持状态一致可以相互替换。
因为active的NameNode挂了之后，standby的NameNode要马上接替它，所以它们的数据要时刻保持一致，在写入数据的时候，两个NameNode内存中都要记录数据的元信息，并保持一致。这个JournalNode就是用来在两个NameNode中同步数据的，并且standby NameNode实现了SecondNameNode的功能。
进行数据同步操作的过程如下：
active NameNode有操作之后，它的editlog会被记录到JournalNode中，standby NameNode会从JournalNode中读取到变化并进行同步，同时standby NameNode会监听记录的变化。这样做的话就是实时同步了，并且standby NameNode就实现了SecondNameNode的功能。
优点：
缺点：
现在的互联网+，不过是练了个吸星大法，但吸进来的内力，如果不消化好，就很快会反噬，您说呢，令狐少侠
据株洲日报报道，近年来，株洲水电气、公交等公用事业单位纷纷推出自己的App应用。尽管在报道中亦提到，部分此类App仍不支持移动支付功能，或仅支持银行卡额，不支持微信或支付宝之类的第三方支付，距离老百姓还有“最后一公里”的问题。
但即使解决移动支付这个便捷性问题，就算是解决了最后一公里吗？愚以为不然，这恰恰是包括公用事业在内的许多消费类App们的认知上的瓶颈所在，即在他们看来，互联网+的核心要义，就是解决一个排队难的问题。
当然，不得不承认，这样的互联网思维，已经比只是简单地让自己的产品、服务展示在网络上，把互联网+看做是联网要强上许多。而且低段位的互联网+确实也是用这种方式来捞取第一波用户的。
毕竟排队在中国一直都是个难题，这里面涉及到一个时间成本的问题，通过互联网，让用户不用到线下的窗口，直接可以网上支付了“门票”，然后按照约定的时间来吃饭、看电影、逛景点，或者如水电煤气之类的服务，足不出户就把事情给办了，自然是皆大欢喜。
但这其实只是互联网+的起手式，只是通过互联网，拉近了和用户之间的交易距离，说白了，就是缴费方便了，但心与心的距离，还是很遥远。
接下来的事情更重要，通过网络能够减少双方的时间成本和各种空耗没了，但互联网+最后的落实之处还是在线下，而不是仅仅一个网上快捷缴费。线下比拼的是什么？服务二字而已。
对于那些做独家生意的App来说，或许这样的感觉还不明显。但对于其他竞争压力颇大的互联网+项目来说，比如外卖、电影、美容美发之类，则颇为鲜明，客人最终决定是否长期光顾，还是要在线下体验了你的服务确实不错之后，才会形成黏性。线上付费也好、各种折扣也罢，不过是一个最初用来招揽客人入口罢了，何况同样的入口还有很多。为何选择你，用户体验好、服务有特色，依然是不二法门。
尤其是在同行们都互联网+之后，其实比拼又回到了服务这个原始起点之上。再多问一句然后呢？其实互联网+的另一层深意也就在此体现，比如早前在网约车和出租车的比拼中，出租车为何频频落于下风？除了网约车多了个更精准的网上揽客手段，在服务上也颇为个性化之外。网约车平台也在憋大招，比如通过大数据，根据地图和约车热度对用户群体进行画像，然后给网约车们更多的揽客建议；又如百度外卖，甚至整出了个智能物流调度系统，用人工智能为平台里的商户们送餐，合理规划最佳路线，而且还是根据路况来实时制定的……
网上缴费没变、基础服务也未必立刻得到了升级，比如菜的口味总不是一朝一夕改变的，但互联网+里面其实还可以纳入更多技术元素，来让服务变得“不一样”起来。
或许，对于苦于找不到风口的众创企业们来说，为App们提供支付之外的技术服务，也是个商机。
随着 MySQL 被 Oracle 收购，MySQL 的用户和开发者开始质疑开源数据库的命运，与此同时他们开始寻找替代品。
有文章写到了放弃 MySQL 的五大理由： MySQL 不如其它关系型数据库管理系统那样成熟； MySQL 是开源的...但只有近似而已； MySQL 的性能无法与竞争对手相提并论； MySQL 是 Oracle 所有的，而不是社区驱动的； 越来越多的强劲对手。 从 MySQL 转向 MariaDB的代表厂家：谷歌（2013年9月）、RedHat（2013年6月）、维基百科（2013年4月）
MySQL 在 2008 年被Sun以10亿美金所收购，MySQL 创始人 Michael Widenius 则不满 Sun 开发团队脚步过慢，愤而离职成立开源数据库联盟，另外从现有 MySQL 程序代码中，开发出另一个延伸分支版本，也就是名为玛莉亚数据库的企业级开源数据库 。
玛莉亚数据库如同 MySQL 的影子版本，玛莉亚数据库是 MySQL 的一个分支版本（branch），而不是衍生版本（folk），提供的功能可和 MySQL 完全兼容。 从 MySQL 转向 PostgreSQL的代表厂家：苹果（2011年）
PostgreSQL是一个自由的对象-关系数据库服务器(数据库管理系统)。PostgreSQL支持大部分 SQL标准并且提供了许多其他现代特性：复杂查询、外键、触发器、视图、事务完整性、MVCC。同样，PostgreSQL 可以用许多方法扩展，比如， 通过增加新的数据类型、函数、操作符、聚集函数、索引方法、过程语言。并且，因为许可证的灵活，任何人都可以以任何目的免费使用、修改、和分发 PostgreSQL，不管是私用、商用、还是学术研究使用。
PostgreSQL 也受 NoSQL 思想的启发，希望能够在今后可以给使用者更多可定制可调节的功能（不是说这个成熟的关系性数据库系统要向 NoSQL 转变）。 NoSQL(NoSQL = Not Only SQL)，意即“不仅仅是 SQL”，是一项全新的数据库革命性运动。NoSQL指的是非关系型的数据库。随着互联网 web2.0网站的兴起，传统的关系数据库在应付 web2.0 网站，特别是超大规模和高并发的 SNS 类型的 web2.0 纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。
其代表的开源软件如：Membase、MongoDB、Hypertable、Apache Cassandra、CouchDB等。 Oracle自 Oracle 10g 后推出对应的免费版。
关系是客观存在的自然规律，摆脱就是在修改事实模型。
用NOSQL，我觉得可以理解成关系模型的变化，而不是另起炉灶。
Lambda架构的核心理念是“流批一体化”，因为随着机器性能和数据框架的不断完善，用户其实不关心底层是如何运行的，批处理也好，流式处理也罢，能按照统一的模型返回结果就可以了，这就是Lambda架构诞生的原因。现在很多应用，例如Spark和Flink，都支持这种结构，也就是数据进入平台后，可以选择批处理运行，也可以选择流式处理运行，但不管怎样，一致性都是相同的。
Kylin
Kylin的主要特点是预计算，提前计算好各个cube，这样的优点是查询快速，秒级延迟；缺点也非常明显，灵活性不足，无法做一些 探索 式的，关联性的数据分析。
适合的场景也是比较固定的，场景清晰的地方。
ClickHouse
Clickhouse由俄罗斯yandex公司开发。专为在线数据分析而设计。
Clickhouse最大的特点首先是快 ，为了快采用了列式储存，列式储存更好的支持压缩，压缩后的数据传输量变小，所以更快；同时支持分片，支持分布式执行，支持SQL。
ClickHouse很轻量级，支持数据压缩和最终数据一致性，其数据量级在PB级别。
另外Clickhouse不是为关联分析而生，所以多表关联支持的不太好。
同样Clickhouse不能修改或者删除数据，仅能用于批量删除或修改。没有完整的事务支持，不支持二级索引等等，缺点也非常明显。
与Kylin相比ClickHouse更加的灵活，sql支持的更好，但是相比Kylin，ClickHouse不支持大并发，也就是不能很多访问同时在线。
总之ClickHouse用于在线数据分析，支持功能简单。CPU 利用率高，速度极快。最好的场景用于行为统计分析。
Hive
Hive这个工具，大家一定很熟悉，大数据仓库的首选工具。可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能。
主要功能是可以将sql语句转换为相对应的MapReduce任务进行运行，这样可能处理海量的数据批量，
Hive与HDFS结合紧密，在大数据开始初期，提供一种直接使用sql就能访问HDFS的方案，摆脱了写MapReduce任务的方式，极大的降低了大数据的门槛。
当然Hive的缺点非常明显，定义的是分钟级别的查询延迟，估计都是在比较理想的情况。 但是作为数据仓库的每日批量工具，的确是一个稳定合格的产品。
Presto
Presto极大的改进了Hive的查询速度，而且Presto 本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询，支持包括复杂查询、聚合、连接等等。
Presto没有使用MapReduce，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。
Presto由于是基于内存的，缺点可能是多张大表关联操作时易引起内存溢出错误。
另外Presto不支持OLTP的场景，所以不要把Presto当做数据库来使用。
Presto相比ClickHouse优点主要是多表join效果好。相比ClickHouse的支持功能简单，场景支持单一，Presto支持复杂的查询，应用范围更广。
Impala
Impala是Cloudera 公司推出，提供对 HDFS、Hbase 数据的高性能、低延迟的交互式 SQL 查询功能。
Impala 使用 Hive的元数据, 完全在内存中计算。是CDH 平台首选的 PB 级大数据实时查询分析引擎。
Impala 的缺点也很明显，首先严重依赖Hive，而且稳定性也稍差，元数据需要单独的mysql/pgsql来存储，对数据源的支持比较少，很多nosql是不支持的。但是，估计是cloudera的国内市场推广做的不错，Impala在国内的市场不错。
SparkSQL
SparkSQL的前身是Shark，它将 SQL 查询与 Spark 程序无缝集成，可以将结构化数据作为 Spark 的 RDD 进行查询。
SparkSQL后续不再受限于Hive，只是兼容Hive。
SparkSQL提供了sql访问和API访问的接口。
支持访问各式各样的数据源，包括Hive, Avro, Parquet, ORC, JSON, and JDBC。
Drill
Drill好像国内使用的很少，根据定义，Drill是一个低延迟的分布式海量数据交互式查询引擎，支持多种数据源，包括hadoop，NoSQL存储等等。
除了支持多种的数据源，Drill跟BI工具集成比较好。
Druid
Druid是专为海量数据集上的做高性能 OLAP而设计的数据存储和分析系统。
Druid 的架构是 Lambda 架构，分成实时层和批处理层。
Druid的核心设计结合了数据仓库，时间序列数据库和搜索系统的思想，以创建一个统一的系统，用于针对各种用例的实时分析。Druid将这三个系统中每个系统的关键特征合并到其接收层，存储格式，查询层和核心体系结构中。
目前 Druid 的去重都是非精确的，Druid 适合处理星型模型的数据，不支持关联操作。也不支持数据的更新。
Druid最大的优点还是支持实时与查询功能，解约了很多开发工作。
Kudu
kudu是一套完全独立的分布式存储引擎，很多设计概念上借鉴了HBase，但是又跟HBase不同，不需要HDFS，通过raft做数据复制；分片策略支持keyrange和hash等多种。
数据格式在parquet基础上做了些修改，支持二级索引，更像一个列式存储，而不是HBase schema-free的kv方式。
kudu也是cloudera主导的项目，跟Impala结合比较好，通过impala可以支持update操作。
kudu相对于原有parquet和ORC格式主要还是做增量更新的。
Hbase
Hbase使用的很广,更多的是作为一个KV数据库来使用，查询的速度很快。
Hawq
Hawq是一个Hadoop原生大规模并行SQL分析引擎，Hawq采用 MPP 架构，改进了针对 Hadoop 的基于成本的查询优化器。
除了能高效处理本身的内部数据，还可通过 PXF 访问 HDFS、Hive、HBase、JSON 等外部数据源。HAWQ全面兼容 SQL 标准，还可用 SQL 完成简单的数据挖掘和机器学习。无论是功能特性，还是性能表现，HAWQ 都比较适用于构建 Hadoop 分析型数据仓库应用。
数据库一体机与大数据技术区别何在
作为近期信息管理领域最为热门的两项技术，数据库一体机与大数据技术的硬件架构基本相同，但软件体系有着本质的区别，这也导致了两者拥有不同的特征表现。
随着企业数据量的快速增长，以及用户对服务水平要求的不断提高，相当长的一段时间以来，传统关系数据库技术在生产实践中表现出明显的能力不足。如何以合理的成本获得海量数据的高可用性已经成为现代IT领域的重大挑战。为了应对这一挑战，近年来，IT市场中相继出现了许多新的技术手段，其中最为引人注目的便是由主流数据库厂商主导的数据库一体机（例如Oracle ExaData以及IBM Netezza等），以及以开源力量为主的大数据技术。
不过，虽然数据库一体机与大数据技术都是当今的热门话题，并都已经被广泛应用，但却有相当一部分用户仍然无法深入了解两者之间的本质区别与关系。同时，很多用户也在为如何在企业内部对这两者进行正确定位而感到困惑。为此，本文特别对数据库一体机（也可称新一代主流关系型数据库）和大数据技术（例如Hadoop，主要指MapReduce与NoSQL）的相关技术特点进行对比。
硬件与软件
从本质上来讲，数据库一体机与大数据技术的硬件架构基本相同，同样是采用x86服务器集群的分布式并行模式，以应对大规模的数据与计算。但是，数据库一体机的卖家们通常会对其产品的硬件体系进行面向产品化的、系统性的整体调优，同时也会有各自的特色手段。比方说Oracle ExaData的Infiniband、Flash Cache，IBM Nettezza的FPGA（现场可编程逻辑门阵）等。[page] 数据库一体机与大数据技术最为核心的区别是在软件体系上。数据库一体机的核心是SQL体系，这不只是指SQL解析，更重要的是指包括SQL优化引擎、索引、锁、事务、日志、安全以及管理等在内的完整而庞大的技术体系。这一体系是成熟的、面向产品的。
大数据技术软件体系中的MapReduce则提供了一个面向海量数据处理的分布式编程框架，使用者需要自行编制所需要的计算逻辑。MapReduce对数据的读写是批量连续的，而不是随机的。而大数据技术的另一体系NoSQL则大都只是提供了海量数据的分布式存储，以及基于索引的快速读取机制，为使用者提供的大多是编程API（虽然也有类SQL的语言，但其本质并不是完整的SQL体系）。
由于SQL体系的复杂性与处理逻辑的整体关联性，导致数据库一体机在扩展性上远不及大数据技术体系，虽然前者已经在很大程度上改善了传统关系数据库垂直扩展的瓶颈。MapReduce与NoSQL的单个集群往往可以扩展到数千个节点，而数据库一体机如果在硬件上扩展到这个规模，从软件上来讲，已经是没有意义的了。
特征与本质
基于软件体系的不同，导致了数据库一体机和大数据技术有着不同的特征表现。数据库一体机往往适合于存储关系复杂的数据模型（例如企业核心业务数据），并且需要限制为基于二维表的关系模型。同时，数据库一体机适合进行一致性与事务性要求高的计算，以及复杂的BI计算。
大数据技术则更适合于存储较简单的数据模型，并且可以不受模式的约束。因而其可存储管理的数据类型更加丰富。大数据技术还适合进行一致性与事务性要求不高的计算（主要是指NoSQL的查询操作），以及对超大规模海量数据的、批量的分布式并行计算（基于MapReduce）。
需要注意的是，NoSQL数据库由于摆脱了繁琐的SQL体系约束，其查询与插入的效率比数据库一体机更高。大数据技术比数据库一体机所能处理的数据量也相对大些，这主要是因为其集群可以扩展得更大。
从本质上讲，MapReduce是对海量数据分布式计算领域的一个重要创新，但也只是在适合于并行处理的大规模批量处理问题上更占优势，而对一些复杂操作，则不一定具有优势。NoSQL则可以看作是对传统关系数据库进行简化的结果。由于NoSQL数据库的设计思想只是提取出关系型数据库的索引机制，并加了上分布式存储，把SQL体系中那些对“某些特殊问题”而言并不需要的东西统统删去，由此实现了更优秀的效率、扩展性与灵活性。[page] 因此，我们可以明显地看到，在实践中，有很多问题（特别是流行的大数据问题），关系数据库中的许多设计并不需要，这才是NoSQL发展壮大的根本立足点。
关系与协作
通过前面的分析，我们不难得出这样的结论：大数据技术与数据库一体机应该是相辅相成，并非互相替代的。它们针对不同的应用场景设计，并相互补充与合作。具体来说，大数据技术可以实现：
■处理企业内海量的、模型简单、类型多样的非结构化与半结构化数据（例如社会化数据、各种日志甚至图片、视频等），其处理结果可以被直接使用；
■以上处理结果也同时可以被当成是新的输入存储到企业级数据仓库中，这时大数据机相当于是面向大数据源的、新的ETL（提取-转换-加载）手段；
■面向海量数据的、不太适合SQL的存储或计算。
而数据库一体机则应该还是作为企业数据仓库的主流技术，至少在很长一段时间内应该是这样。它负责存储与计算最主要的、有重大价值的企业关键业务数据。
现存的误区
有些人认为，虽然大数据技术的原始开源状态还不适合充当企业级数据仓库主平台的要求，但经过开发、补充，应该是可以的。其实这个观点没有错。但实际上，对开源的大数据技术进行补充开发，所要补充的正是大数据技术在原始设计上就去除了的、那些本属于关系型数据库体系的东西。
如果进行这样的补充开发，企业不仅会面临庞大的、难于估计的开发工作量，同时也难以像专业数据库厂商那样实现这些工作的理论化、产品化与体系化。虽然从纯技术的角度上讲，开发什么都有可能。但是如果企业真的准备这样做，是要开发另一个商业化的关系数据库吗？很明显，这违背了大数据技术的设计初衷。