RDD、DataFrame、Dataset全都是spark平台下的分布式弹性数据集，为处理超大型数据提供便利都有惰性机制，在进行创建、转换，如map方法时，不会立即执行，只有在遇到Action如foreach时，才会开始遍历运算，极端情况下，如果代码里面有创建、转换，但是后面没有在Action中使用对应的结果，在执行时会被直接跳过，DataFrame与Dataset均支持sparksql的操作，rdd不支持。
‘hadoop/spark/scala’ 类别下的博文
当表数据以文本文件的形势，存放在hdfs上，不管是内部表，还是外部表，导入数据都是比较好操作的。直接通过hdfs命令直接copy到文件服务器上的对应目录就好了，注意hdfs目录的访问权限。
parquet也是可以这样操作的
parquet是面向分析型业务的列式存储格式，由Twitter和Cloudera合作开发， Parquet的灵感来自于2010年Google发表的Dremel论文，文中介绍了一种支持嵌套结构的存储格式，并且使用了列式存储的方式提升查询性能，在Dremel论文中还介绍了Google如何使用这种存储格式实现并行查询的。
csv，txt是行式存储，转换过后，在查询速度提高了不少，特别是存储空间，减少了90%多。
Cloudera Manager还是比较耗资源的，想把Cloudera Manager，移动到比较好的机器上。
cdh的安装请参考：cloudera cdh 6.3 安装配置
在这篇文章中，Cloudera Manager安装在bigserver1上面，bigserver1是奔腾双核的CPU。
数据量的增加，增加datanode是必然，独立hadoop增加数据节点，请参考：hadoop 动态增加节点
cloudera后台，显示，存在隐患 : 以下网络接口似乎未以全速运行：enp4s0。1 主机网络接口似乎以全速运行。
cloudera cdh6的测试机，都是公司淘汰下来的员工使用过的台式机，很差。硬件达不到要求。才会有上面的问题。然后不影响系统的使用，但是看着不舒服。
namenode ha肯定是要去做的。如果调度节点挂掉了，又没有备用节点的话，那整个大数据系统就等于挂掉了。
这个问题是由什么引起的呢？如果集群中，有二个datanode，而有3个副本的话，就会出现这样的问题。
cdh在国内用的比较多。不管是cloudera+cdh或者是ambari+hdp，建议初学者不要用，还是从原生的开始。网上说原生的不稳定，配置复杂。
我用的hadoop2.7.7稳定，以及以hadoop2.7.7为基础构建的生态圈很稳定，在线率100%，到目前为止还没有出现过突发故障。
以hadoop为基础构建一套生态圈，是很复杂。但是拆分开了，采取蚂蚁搬家的方式，就简单多了。并且能了解各组件间是怎么协同工作的。