1、简答说一下hadoop的map-reduce编程模型
首先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预处理，以减小后面shufle和reducer的工作量
reduce task会通过网络将各个数据收集进行reduce处理，最后将数据保存或者显示，结束整个job
2、hadoop的TextInputFormat作用是什么，如何自定义实现
InputFormat会在map操作之前对数据进行两方面的预处理
1是getSplits，返回的是InputSplit数组，对数据进行split分片，每片交给map操作一次
2是getRecordReader，返回的是RecordReader对象，对每个split分片进行转换为key-value键值对格式传递给map常用的InputFormat是TextInputFormat，使用的是LineRecordReader对每个分片进行键值对的转换，以行偏移量作为键，行内容作为值
自定义类继承InputFormat接口，重写createRecordReader和isSplitable方法
在createRecordReader中可以自定义分隔符
3、hadoop和spark的都是并行计算，那么他们有什么相同和区别
两者都是用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图可以实现良好的容错
4、为什么要用flume导入hdfs，hdfs的构架是怎样的
flume可以实时的导入数据到hdfs中，当hdfs上的文件达到一个指定大小的时候会形成一个文件，或者超过指定时间的话也形成一个文件
文件都是存储在datanode上面的，namenode记录着datanode的元数据信息，而namenode的元数据信息是存在内存中的，所以当文件切片很小或者很多的时候会卡死
5、map-reduce程序运行的时候会有什么比较常见的问题
比如说作业中大部分都完成了，但是总有几个reduce一直在运行
这是因为这几个reduce中的处理的数据要远远大于其他的reduce，可能是因为对键值对任务划分的不均匀造成的数据倾斜
解决的方法可以在分区的时候重新定义分区规则对于value数据很多的key可以进行拆分、均匀打散等处理，或者是在map端的combiner中进行数据预处理的操作
6、简单说一下hadoop和spark的shuffle过程
hadoop：map端保存分片数据，通过网络收集到reduce端
spark：spark的shuffle是在DAGSchedular划分Stage的时候产生的，TaskSchedule要分发Stage到各个worker的executor减少shuffle可以提高性能部分答案不是十分准确欢迎补充:-)
7、Hive中存放是什么？
存的是和hdfs的映射关系，hive是逻辑上的数据仓库，实际操作的都是hdfs上的文件，HQL就是用sql语法来写的mr程序。
8、Hive与关系型数据库的关系？
没有关系，hive是数据仓库，不能和数据库一样进行实时的CURD操作。
是一次写入多次读取的操作，可以看成是ETL工具。
9、Flume工作机制是什么？
核心概念是agent，里面包括source、chanel和sink三个组件。
source运行在日志收集节点进行日志采集，之后临时存储在chanel中，sink负责将chanel中的数据发送到目的地。
只有成功发送之后chanel中的数据才会被删除。
首先书写flume配置文件，定义agent、source、chanel和sink然后将其组装，执行flume-ng命令。
10、Sqoop工作原理是什么？
hadoop生态圈上的数据传输工具。
可以将关系型数据库的数据导入非结构化的hdfs、hive或者bbase中，也可以将hdfs中的数据导出到关系型数据库或者文本文件中。
使用的是mr程序来执行任务，使用jdbc和关系型数据库进行交互。
import原理：通过指定的分隔符进行数据切分，将分片传入各个map中，在map任务中在每行数据进行写入处理没有reduce
export原理：根据要操作的表名生成一个java类，并读取其元数据信息和分隔符对非结构化的数据进行匹配，多个map作业同时执行写入关系型数据库
11、Hbase行健列族的概念，物理模型，表的设计原则？
行健：是hbase表自带的，每个行健对应一条数据。
列族：是创建表时指定的，为列的集合，每个列族作为一个文件单独存储，存储的数据都是字节数组，其中的数据可以有很多，通过时间戳来区分。
物理模型：整个hbase表会拆分为多个region，每个region记录着行健的起始点保存在不同的节点上，查询时就是对各个节点的并行查询，当region很大时使用.META表存储各个region的起始点，-ROOT又可以存储.META的起始点。
rowkey的设计原则：一定要有规则并且有序，常用的一些 rowkey 一定要连续连续，并且 rowkey的设计规则最好加入以后要查询的规则在里面方便日后校对查询。
列族的设计原则： 尽可能少，经常和不经常使用的两类数据放入不同列簇中，列族名字尽可能短。
1.列族对于内存的影响,因为一个列族对应一个MemStore,如果列族过多,MemStore会占用RegionServer大量内存资源
2.列族对于flush的影响,MemStore里的数据进行flush,如果列族数据比较稀疏,分布不均衡,每次flush数据量小的列族会产生大量小文件,列族越多,小文件越多
3.列族数对 Compaction 的影响，与 Flush 操作一样，目前 HBase 的 Compaction 操作也是 Region 级别的，过多的列族也会产生不必要的 IO。
4.列族对于region的split的影响,当某个region下的某个StoreFile需要切分时,因为切分时针对整个region的,数据量小的列族也会被切分,会产生更多的小文件
表的设计原则：各个列簇数据平衡，长度原则、相邻原则，创建表的时候设置表放入regionserver缓存中，避免自动增长和时间，使用字节数组代替string，最大长度64kb，最好16字节以内，按天分表，两个字节散列，四个字节存储时分毫秒。
12、Spark Streaming和Storm和Flink有何区别？
| 对比项 | spark-streaming | storm | flink |
|---|---|---|---|
| 流模式 | 微批处理 | 行处理 / 或者微批处理 | 行处理/或者微批处理 |
| 可靠性 | Exactly-Once | At-Least-Once | Exactly-Once |
| 延迟 | 秒级 | 毫秒级 | 毫秒级 |
| 吞吐量 | 比较高 | 非常高 | 非常高 |
| 容错机制 | Recourd ACKs机制 | 基于RDD的 CheckPoint | CheckPoint |
| 是否有状态 | 是 | 否 | 是 |
| 支持SQL | 支持 | 不支持 | 支持 |
| 与Hadoop兼容性 | 支持HDFS、HBase等数据源 | 不支持 | 支持HDFS、HBase等数据源 |
由于spark 和Flink都可以基于YARN的方式部署，共用了hadoop生态的HDFS，YARN组件，降低了基础平台的运维工作量。同时Flink的毫秒级延迟实时计算能力和spark秒级延迟实时计算能力是一种相互补充。Flink和spark形成互补且竞争关系。
Flink 在 Mlib，SQL 支持方面都有支持，功能方面和spark竞争关系，都是朝着生态方向发展。不过都可以基于相同的底层平台，大家切换和相互替换的成本都不高。
虽然storm的也可以基于yarn部署，但这不是其主流使用场景，所以在大数据基础平台方案中Flink可以最终替换的storm平台。
13、Hadoop平台集群配置、环境变量设置？
zookeeper：修改zoo.cfg文件，配置dataDir，和各个zk节点的server地址端口，tickTime心跳时间默认是2000ms，其他超时的时间都是以这个为基础的整数倍，之后再dataDir对应目录下写入myid文件和zoo.cfg中的server相对应。
hadoop：修改
hadoop-env.sh配置java环境变量
core-site.xml配置zk地址，临时目录等
hdfs-site.xml配置nn信息，rpc和http通信地址，nn自动切换、zk连接超时时间等
yarn-site.xml配置resourcemanager地址
mapred-site.xml配置使用yarn
slaves配置节点信息
格式化nn和zk。hbase：修改
hbase-env.sh配置java环境变量和是否使用自带的zk
hbase-site.xml配置hdfs上数据存放路径，zk地址和通讯超时时间、master节点
regionservers配置各个region节点
zoo.cfg拷贝到conf目录下spark：
安装Scala
修改spark-env.sh配置环境变量和master和worker节点配置信息环境变量的设置：直接在/etc/profile中配置安装的路径即可，或者在当前用户的宿主目录下，配置在.bashrc文件中，该文件不用source重新打开shell窗口即可，配置在.bash_profile的话只对当前用户有效。
14、Hadoop性能调优？
调优可以通过系统配置、程序编写和作业调度算法来进行。
hdfs的block.size可以调到128/256（网络很好的情况下，默认为64）
调优的大头：mapred.map.tasks、mapred.reduce.tasks设置mr任务数（默认都是1）
mapred.tasktracker.map.tasks.maximum每台机器上的最大map任务数
mapred.tasktracker.reduce.tasks.maximum每台机器上的最大reduce任务数
mapred.reduce.slowstart.completed.maps配置reduce任务在map任务完成到百分之几的时候开始进入
这个几个参数要看实际节点的情况进行配置，reduce任务是在33%的时候完成copy，要在这之前完成map任务，（map可以提前完成）
mapred.compress.map.output,mapred.output.compress配置压缩项，消耗cpu提升网络和磁盘io
合理利用combiner
注意重用writable对象
15、Hadoop高并发？
首先肯定要保证集群的高可靠性，在高并发的情况下不会挂掉，支撑不住可以通过横向扩展。
datanode挂掉了使用hadoop脚本重新启动。
16、RDD机制？
rdd分布式弹性数据集，简单的理解成一种数据结构，是spark框架上的通用货币。
所有算子都是基于rdd来执行的，不同的场景会有不同的rdd实现类，但是都可以进行互相转换。
rdd执行过程中会形成dag图，然后形成lineage保证容错性等。
从物理的角度来看rdd存储的是block和node之间的映射。
17、spark有哪些组件？
（1）master：管理集群和节点，不参与计算。
（2）worker：计算节点，进程本身不参与计算，和master汇报。
（3）Driver：运行程序的main方法，创建spark context对象。
（4）spark context：控制整个application的生命周期，包括dagsheduler和task scheduler等组件。
（5）client：用户提交程序的入口。
18、spark工作机制？
用户在client端提交作业后，会由Driver运行main方法并创建spark context上下文。
执行rdd算子，形成dag图输入dagscheduler，按照rdd之间的依赖关系划分stage输入task scheduler。
task scheduler会将stage划分为task set分发到各个节点的executor中执行。
19、spark的优化怎么做？
通过spark-env文件、程序中sparkconf和set property设置。
（1）计算量大，形成的lineage过大应该给已经缓存了的rdd添加checkpoint，以减少容错带来的开销。
（2）小分区合并，过小的分区造成过多的切换任务开销，使用repartition。
20、kafka工作原理？
producer向broker发送事件，consumer从broker消费事件。
事件由topic区分开，每个consumer都会属于一个group。
相同group中的consumer不能重复消费事件，而同一事件将会发送给每个不同group的consumer。
21、hive跟hbase的区别是？
共同点：
hbase与hive都是架构在hadoop之上的。都是用hadoop作为底层存储
区别：
1.Hive是建立在Hadoop之上为了减少MapReduce jobs编写工作的批处理系统，HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。2.hive需要用到hdfs存储文件，需要用到MapReduce计算框架。
3.想象你在操作RMDB数据库，如果是全表扫描，就用Hive+Hadoop,如果是索引访问，就用HBase+Hadoop 。
4.Hive query就是MapReduce jobs可以从5分钟到数小时不止，HBase是非常高效的，肯定比Hive高效的多。
5.Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑。
6.hive借用hadoop的MapReduce来完成一些hive中的命令的执行
7.hbase是物理表，不是逻辑表，提供一个超大的内存hash表，搜索引擎通过它来存储索引，方便查询操作。
8.hbase是列存储。
9.hdfs作为底层存储，hdfs是存放文件的系统，而Hbase负责组织文件。
22.fsimage和edit的区别
fsimage保存来最新的元数据检查点，包含来整个hdfs文件系统的所有目录和文件的信息。对于文件来说包括了数据块描述信息，修改时间，访问时间等，对于目录老说包括修改时间，访问权限控制信息（目录所属用户，所在组）等。Fimage就是在某一时刻，整个hdfs的快照，就是这个时刻的hdfs上所有的文件块和目录，分别的状态，位于哪些个datanode，各自的权限，各自的副本个数。
editlog主要是在Namenode已经启动情况下对hdfs进行的各种更新操作进行记录，hdfs客户端执行所有的写操作都会被记录到editlog中。客户端对hdfs所有的更新操作，比如说移动数据，或者删除数据，都会记录在editlog中。为了避免editlog不断增大，secondary namenode 会周期性合并fsimage和edits 合并成新的fsimage。新的操作记录会写入新的editlog中，这个周期可以自己设置（editlog到达一定大小或者定时）
23.数仓分层思想
- ODS层(数据接入层)：主要存放原始数据信息。该层数据原则上和源系统数据保持一致
- DW层(数据明细层)：对数据进行清洗和规范整合后的明细数据
- DM层(数据集市层)：DM层存放的是轻度汇总的数据，以业务分析应用为出发点，但不面向具体的应用和需求
- DA层(数据应用层): DA层存放的是高度汇总的数据，面向具体的应用需求来进行加工汇总，可用于报表展示
- DIM层(数据维度层)：维度层,包括业务领域内公共的维度表
24.什么是拉链表
流水表存放的是一个用户的变更记录，比如在一张流水表中，一天的数据中，会存放一个用户的每条修改记录，但是在拉链表中只有一条记录。
25、元数据如何管理
第一步是采集元数据，第二步是利用采集到的元数据建设元数据管理平台
- · 实现对技术元数据抽取、汇集、梳理，注释相关库表、列信息。支持查看完整数据链路和关联图谱。
- · 梳理业务元数据，将相关的指标、流程在平台中建立起来，固化并传播企业专业知识。
- · 将业务元数据同技术元数据联系起来，联通业务与技术，给业务管理人员和技术维护人员提供更详尽的指导
在元数据管理平台中，可以搜索：
数据源搜索范围：数据源名称、数据源类型、创建人、负责人、标签
表搜索范围：表名称、负责人、Comment、标签
视图搜索范围：视图名称、负责人、Comment、标签
字段搜索范围：字段名称、标签、别名、描述
26、数仓建模方法
1）范式建模法
从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模，在某些时候反而限制了整个数据仓库模型的灵活性，性能等
2）维度建模法（最常用）
紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余
3）实体建模法
https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0803zhousb/index.html
27、埋点的码表如何设计
1. 确认事件与变量
2. 明确事件的触发时机
3. 规范命名
4.明确优先级
https://www.douban.com/note/733876053/
27、数据漂移的概念和解决方案
概念：数据漂移是 ODS 数据的一个顽疾，通常是指 ODS 表的同一个业务日期数据中包含前一天或后凌晨附近的数据或者丢失当天的变更数据。
解决方案 ：
（1）既然取一天的数据会有数据漂移现象且多半发生在凌晨（因为凌晨是一天的分隔，这不是废话么），那么自然而然就有一种方式：我们多向前一天要一部分数据，也向后一天多要一部分数据。根据一些经验，一般是15分钟。保证数据只多不少，切分时按照需要的业务时间再过滤。是这种方式会有一些数据误差，例如 个订单是当天支付的，但是第二天凌晨申请退款关闭了该订单，那么这条记录的订单状态会被更新，下游在统计支付订单状态时会出现错误。
( 2）通过多个时间戳字段限制时间来获取相对准确的数据
- 首先根据 log_time 分别冗余前一天最后 15 分钟的数据，并用 modified time 过滤非当天数据，并按modified_time升序排序，取第一条
- 然后根据 log_time 获取后一天 15 分钟的数据 针对此数据，按照主键根据 log_time 做升序排列去重。因为我们需要获取的是最接近当天记录变化的数据（数据库日志将保留所有变化的数据，但是落地到 DS 表的是根据主键去重获取最后状态变化的数据）。
- 最后将前两步的结果数据做全外连接，通过限制业务时间proc_time 来获取我们所需要的数据。
时间戳字段分类：
- 数据库表中用来标识数据记录更新时间的时间戳字段（假设这类字段叫 modified time ）。
- binlog日志时间戳字段·（假设这类宇段叫 log_time）。
- 数据库表中用来记录具体业务过程发生时间的时间戳字段 （假设这类字段叫 proc_time）。
正常proc_time<log_time<modified_time
https://www.jianshu.com/p/3a0d7229e8c5
28、你们公司数据开发是需求驱动还是业务驱动，如何使用数据促进业务增长？
就怕数据存在数据仓库，需求方不动，数据开发就不动。如果你们数据部门只是简单的提数，没有其他应用，可以主动做一下用户画像，再做推荐系统，或者运营平台，促进业务增长
有业务才有需求，业务才是真真切切的资金流原动力，原动力有了才能流动起来，至于数据如何促进业务增长，那肯定需要看到需求，提取数据，净化细化数据，确定目标方向，计算极端值方案，细化业务方案，最后出执行方案，将历史数据优化找到业务增长点，数据跟业务也是相辅相成的
