hadoop的map-reduce的实现原理？node
首先map task会从本地文件系统读取数据，转换成key-value形式的键值对集合，使用的是hadoop内置的数据类型，好比longwritable、text等，将键值对集合输入mapper进行业务处理过程，将其转换成须要的key-value在输出以后会进行一个partition分区操做，默认使用的是hashpartitioner，能够经过重写hashpartitioner的getpartition方法来自定义分区规则，以后会对key进行进行sort排序，grouping分组操做将相同key的value合并分组输出，在这里可使用自定义的数据类型，重写WritableComparator的Comparator方法来自定义排序规则，重写RawComparator的compara方法来自定义分组规则。 以后进行一个combiner归约操做，其实就是一个本地段的reduce预处理，以减少后面shuffle和reduce的工做量，reduce task会经过网络将各个数据收集进行reduce处理，最后将数据保存或者显示，结束整个job
hadoop和spark的都是并行计算，那么他们有什么相同和区别git
二者都是用mr模型来进行并行计算，hadoop的一个做业称为job，job里面分为map task和reduce task，每一个task都是在本身的进程中运行的，当task结束时，进程也会结束 spark用户提交的任务成为application，一个application对应一个sparkcontext，app中存在多个job，每触发一次action操做就会产生一个job 这些job能够并行或串行执行，每一个job中有多个stage，stage是shuffle过程当中DAGSchaduler经过RDD之间的依赖关系划分job而来的，每一个stage里面有多个task，组成taskset有TaskSchaduler分发到各个executor中执行，executor的生命周期是和app同样的，即便没有job运行也是存在的，因此task能够快速启动读取内存进行计算 hadoop的job只有map和reduce操做，表达能力比较欠缺并且在mr过程当中会重复的读写hdfs，形成大量的io操做，多个job须要本身管理关系 spark的迭代计算都是在内存中进行的，API中提供了大量的RDD操做如join，groupby等，并且经过DAG图能够实现良好的容错
工做中，map-reduce程序运行的时候会有什么比较常见的问题？如何解决？github
好比说做业中大部分都完成了，可是总有几个reduce一直在运行。这是由于这几个reduce中的处理的数据要远远大于其余的reduce，多是由于对键值对任务划分的不均匀形成的数据倾斜。 解决的方法能够在分区的时候从新定义分区规则对于value数据不少的key能够进行拆分、均匀打散等处理，或者是在map端的combiner中进行数据预处理的操做
hadoop的TextInputFormat做用是什么，如何自定义实现算法
InputFormat会在map操做以前对数据进行两方面的预处理 1.是getSplits，返回的是InputSplit数组，对数据进行split分片，每片交给map操做一次 2.是getRecordReader，返回的是RecordReader对象，对每一个split分片进行转换为key-value键值对格式传递给map 经常使用的InputFormat是TextInputFormat，使用的是LineRecordReader对每一个分片进行键值对的转换，以行偏移量做为键，行内容做为值 自定义类继承InputFormat接口，重写createRecordReader和isSplitable方法 在createRecordReader中能够自定义分隔符
为何要用flume导入hdfs，hdfs的构架是怎样的sql
flume能够实时的导入数据到hdfs中，当hdfs上的文件达到一个指定大小的时候会造成一个文件，或者超过指定时间的话也造成一个文件 文件都是存储在datanode上面的，namenode记录着datanode的元数据信息，而namenode的元数据信息是存在内存中的，因此当文件切片很小或者不少的时候会卡死
简单说一下hadoop和spark的shuffle过程数据库
hadoop：map端保存分片数据，经过网络收集到reduce端 spark：spark的shuffle是在DAGSchedular划分Stage的时候产生的，TaskSchedule要分发Stage到各个worker的executor 减小shuffle能够提升性能
hbase由哪几部分组成数组
hbase 插入一条数据，内部是如何处理的？缓存
1. 首先，Client经过访问ZK来请求目标数据的地址。 2. ZK中保存了-ROOT-表的地址，因此ZK经过访问-ROOT-表来请求数据地址。 3. 一样，-ROOT-表中保存的是.META.的信息，经过访问.META.表来获取具体的RS。 4. .META.表查询到具体RS信息后返回具体RS地址给Client。 5. Client端获取到目标地址后，而后直接向该地址发送数据请求。
hbase某台机器宕机了，会不会丢失数据，为何？安全
HBase的RegionServer宕机超过必定时间后，HMaster会将其所管理的region从新分布到其余活动的RegionServer上，因为数据和日志都持久在HDFS中，该操做不会致使数据丢失。因此数据的一致性和安全性是有保障的。 可是从新分配的region须要根据日志（LogFile）恢复原RegionServer中的内存MemoryStore表，这会致使宕机的region在这段时间内没法对外提供服务。 而一旦重分布，宕机的节点从新启动后就至关于一个新的RegionServer加入集群，为了平衡，须要再次将某些region分布到该server。 所以，Region Server的内存表memstore如何在节点间作到更高的可用，是HBase的一个较大的挑战。
rowkey的设计原则网络
hbase 过滤器有哪些？你经常使用哪一个？什么功能？
Hbase的过滤器有：RowFilter、PrefixFilter、KeyOnlyFilter、RandomRowFilter、InclusiveStopFilter、FirstKeyOnlyFilter、ColumnPrefixFilter、ValueFilter、ColumnCountGetFilter、SingleColumnValueFilter、SingleColumnValueExcludeFilter、WhileMatchFilter、FilterList 比较经常使用的过滤器有：RowFilter 用来对rowkey进行过滤的。 http://blog.csdn.net/xugen12/article/details/44747465
hbase 中cell的结构
cell中的数据是没有类型的，所有是字节码形式存贮。
hbase 中region 太大问题
Hbase的region会自动split
Hive中存放是什么？
表。 存的是和hdfs的映射关系，hive是逻辑上的数据仓库，实际操做的都是hdfs上的文件，HQL就是用sql语法来写的mr程序。
Hive与关系型数据库的关系？
没有关系，hive是数据仓库，不能和数据库同样进行实时的CURD操做。 是一次写入屡次读取的操做，能够当作是ETL工具。
spark有哪些组件？
（1）master：管理集群和节点，不参与计算。 （2）worker：计算节点，进程自己不参与计算，和master汇报。 （3）Driver：运行程序的main方法，建立spark context对象。 一个驱动程序能够在spark集群上启动一个或多个做业。 （4）spark context：控制整个application的生命周期，包括dagsheduler和task scheduler等组件。 （5）client：用户提交程序的入口。
spark工做机制？
用户在client端提交做业后，会由Driver运行main方法并建立spark context上下文。 执行add算子，造成dag图输入dagscheduler，按照add之间的依赖关系划分stage输入task scheduler。 task scheduler会将stage划分为task set分发到各个节点的executor中执行。
spark的优化怎么作？
经过spark-env文件、程序中sparkconf和set property设置。 （1）计算量大，造成的lineage过大应该给已经缓存了的rdd添加checkpoint，以减小容错带来的开销。 （2）小分区合并，太小的分区形成过多的切换任务开销，使用repartition。
spark sql比hive快至少10倍，缘由是什么？
mr 和 spark 区别，怎么理解 spark-rdd
Mr 是文件方式的分布式计算框架，是将中间结果和最终结果记录在文件中，map 和 reduce的数据分发也是在文件中。 spark 是内存迭代式的计算框架，计算的中间结果能够缓存内存，也能够缓存硬盘，可是不是每一步计算都须要缓存的。 Spark-rdd 是一个数据的分区记录集合，是利用内存来计算的，spark之因此快是由于有内存的模式
Spark程序的性能和调优方面有什么须要注意的
首先，对于大部分数据处理应用程序，磁盘I/O都是影响应用程序执行速度的决定性因素。Spark可让用户在内存中建立数据，请尽可能利用这一特性。将数据缓存在内存中可让应用程序提速100倍以上。固然这也意味着最好使用具备大量内存的计算机搭建Spark集群。 其次，请避免须要进行数据重排（Data shuffling）的操做。跨越网络进行数据重排是一种开销很高的操做，在编写数据处理逻辑时必定要注意这一点。有时候相同的逻辑也能够经过更高效的操做实现，例如不要使用groupByKey操做，而是可使用reduceByKey操做。 第三，优化数据中的分区数量。若是数据还没有分区，就没法充分利用Spark在并行数据处理方面的优点。例如，假设有一个100内核的Spark集群，但若是数据只有2个分区，此时将没法充分运用全部计算能力。 第四，经过共置的数据节点和计算节点能够得到更好的性能。举例来讲，若是数据在HDFS中，请在同一个HDFS集群中安装Spark。Spark会在距离数据尽量近的位置处理这些数据。例如，它首先会尝试在数据所在计算机上执行任务。若是该计算机没法执行任务，随后会尝试使用同一机机柜的其余计算机。若是依然不可行，最后才会选择使用任意一台计算机。请尽可能将磁盘和网络I/O降至最低。
Spark会取代Hadoop吗？为何？
不会。今天的Hadoop表明了多个产品组成的生态系统，Spark也是这个生态系统的成员。就算最核心的Hadoop也包含三个组件：一个集群管理器，一个分布式计算框架，以及一个分布式文件系统。其中集群管理器是YARN，计算框架是MapReduce，分布式文件系统是HDFS。Spark是Hadoop MapReduce组件的继任者。 不少人在使用Spark做业取代原有的MapReduce做业，或在Spark中编写新的做业。所以能够说Spark会取代MapReduce，但没法取代Hadoop。 另外有个重要的事情须要注意，Spark能够配合Hadoop使用，但也能够在不具有Hadoop的状况下使用。例如，可使用Mesos或独立集群管理器替代YARN，同理也可使用S3或其余数据源代替HDFS。所以使用Spark并不是必需要同时使用Hadoop。
为何有人使用Spark代替MapReduce？
相比MapReduce，Spark能够提供更多优点。 首先，Spark比MapReduce速度快不少。取决于具体应用，可能会比MapReduce快100倍。Spark如此之快的一个缘由在于其先进的做业执行引擎。Spark做业能够划分为任意数量的阶段（Stage），而MapReduce做业只能分为两个阶段。另外Spark可让应用程序将数据缓存在内存中。缓存机制可极大改进应用程序性能。磁盘I/O会大幅影响数据处理应用程序的执行速度，Spark则能将磁盘I/O降至最低。 其次，Spark很易用。Spark提供了丰富的API和超过80种操做，MapReduce只能提供两种操做：Map和Reduce。Spark API能够经过Scala、Python、Java和R四种语言使用。相比在MapReduce中编写的做业，相同数据处理做业使用Scala/Spark编写时代码量能够减小5-10倍。所以Spark也能大幅提升开发者的生产力。 第三，Spark针对不一样类型的数据处理任务提供了统一的工具。该产品内置了用于批处理、交互式分析、机器学习、流处理，以及图表分析的集成库，用户再也不须要学习多种工具。也不须要将代码和数据复制到多个位置。另外从运营的角度来讲，一个集群的管理，无疑要比针对不一样类型做业建立多个专用集群管理起来更简单。
如何解决数据倾斜问题？
Spark Streaming和Storm有何区别？
一个实时毫秒一个准实时亚秒，不过storm的吞吐率比较低。
mllib支持的算法？
大致分为四大类，分类、聚类、回归、协同过滤。
给定a、b两个文件，各存放50亿个url，每一个url各占64字节，内存限制是4G，让你找出a、b文件共同的url?
每一个url大小为64 bytes，那么能够估计每一个文件的大小为50G×64=320G，远远大于内存限制的4G，因此不可能将其彻底加载到内存中处理，能够采用分治的思想来解决。 Step1：遍历文件a，对每一个url求取hash(url)%1000，而后根据所取得的值将url分别存储到1000个小文件(记为a0,a1,...,a999，每一个小文件约300M); Step2:遍历文件b，采起和a相同的方式将url分别存储到1000个小文件(记为b0,b1,...,b999); 巧妙之处：这样处理后，全部可能相同的url都被保存在对应的小文件(a0vsb0,a1vsb1,...,a999vsb999)中，不对应的小文件不可能有相同的url。而后咱们只要求出这个1000对小文件中相同的url便可。 Step3：求每对小文件ai和bi中相同的url时，能够把ai的url存储到hash_set/hash_map中。而后遍历bi的每一个url，看其是否在刚才构建的hash_set中，若是是，那么就是共同的url，存到文件里面就能够了。
有一个1G大小的一个文件，里面每一行是一个词，词的大小不超过16字节，内存限制大小是1M，要求返回频数最高的100个词。
Step1：顺序读文件中，对于每一个词x，取hash(x)%5000，而后按照该值存到5000个小文件(记为f0,f1,...,f4999)中，这样每一个文件大概是200k左右，若是其中的有的文件超过了1M大小，还能够按照相似的方法继续往下分，直到分解获得的小文件的大小都不超过1M; Step2：对每一个小文件，统计每一个文件中出现的词以及相应的频率(能够采用trie树/hash_map等)，并取出出现频率最大的100个词(能够用含100个结点的最小堆)，并把100词及相应的频率存入文件，这样又获得了5000个文件; Step3：把这5000个文件进行归并(相似与归并排序);
现有海量日志数据保存在一个超级大的文件中，该文件没法直接读入内存，要求从中提取某天出访问百度次数最多的那个IP
须要更多大数据开发相关学习资料（Hadoop，spark，kafka，MapReduce，scala，，推荐算法，实时交易监控系统，用户分析行为，推荐系统）加圈免费获取：792133408 大数据开发交流圈
问题解法同上，算法思想：分而治之+Hash 1)IP地址最多有2^32=4G种取值状况，因此不能彻底加载到内存中处理; 2)能够考虑采用“分而治之”的思想，按照IP地址的Hash(IP)%1024值，把海量IP日志分别存储到1024个小文件中。这样，每一个小文件最多包含4MB个IP地址; 3)对于每个小文件，能够构建一个IP为key，出现次数为value的Hashmap，同时记录当前出现次数最多的那个IP地址; 4)能够获得1024个小文件中的出现次数最多的IP，再依据常规的排序算法获得整体上出现次数最多的IP;
https://github.com/devuser/spark-notes