大数据常见面试题
2022-03-01 10:26:42 38 举报AI智能生成
ElasticSearchHBase-22 Hive-73 Java-29 Kafka-57 Kylin-12 Linux-11 Mysql-4 Redis-6 Spark-76 Sqoop-6 数据仓库DataWareHouse-181 数据结构-13 Flink flume hadoop 后续更新答案
作者其他创作
大纲/内容
Redis-6
Spark-76
创建rdd的几种方式
1.集合并行化创建(有数据) val arr = Array(1,2,3,4,5) val rdd = sc.parallelize(arr) val rdd = sc.makeRDD(arr) //底层调用了parallelize方法 2.读取外部文件系统，如hdfs，或者读取本地文件(最常用的方式)(没数据) val rdd2 = sc.textFile("hdfs://hdp-01:9000/words.txt") // 读取本地文件 val rdd2 = sc.textFile(“file:///root/words.txt”) 3.从父RDD转换成新的子RDD 调用Transformation类的方法，生成新的RDD
spark运行流程
主要考察对spark内部原理的掌握度 角色： Worker的功能：定时和master通信；调度并管理自身的executor executor：由Worker启动的，程序最终在executor中运行，（程序运行的一个容器） 流程： 1:spark-submit命令执行时，会根据指定的master地址去向 Master发送请求，Master接收到Driver端(具体根据提交模式来判断Driver启动的地方)的任务请求之后，根据任务的请求资源进行调度，（采用打散的策略），尽可能的把任务资源平均分配，然后向WOrker发送指令 2:Worker收到Master的指令之后，就根据相应的资源，启动executor（cores,memory） 3:executor会向dirver端建立请求，通知driver，任务已经可以运行了 4:driver运行任务的时候，会把任务发送到executor中去运行。
Spark中coalesce与repartition的区别
1）关系： 两者都是用来改变 RDD 的 partition 数量的，repartition 底层调用的就是 coalesce 方法：coalesce(numPartitions, shuffle = true) 2）区别： repartition 一定会发生 shuffle，coalesce 根据传入的参数来判断是否发生 shuffle 一般情况下增大 rdd 的 partition 数量使用 repartition，减少 partition 数量时使用coalesce
数据存入Redis 优先使用map mapPartitions foreach foreachPartions哪个
使用 foreachPartition 原因一：map，mapPartition 是转换类的算子， 有返回值 原因二：写mysql,redis的连接数资源会少，例如： 当有100w条元素时那么对于foreach操作会有100w次连接。 对于foreachPartitions来说，是针对rdd分区进行迭代操作的。例如当有200个分区，那么只需要创建200次连接即可。一个分区的数据共用一个连接。 操作层面： 1.foreachParititon 每次迭代一个分区 2.foreach每次迭代一个元素。 对于foreach,foreachPartitions来说，该方法没有返回值，或者Unit。 主要作用于，没有返回值类型的操作（打印结果，写入到mysql数据库中） 在写入到redis,mysql的时候，优先使用foreachPartititon
reduceByKey和groupBykey的区别
reduceByKey会传一个聚合函数， 相当于 groupByKey+ mapValues reduceByKey 会有一个分区内聚合，而groupByKey没有 最核心的区别 结论：reduceByKey有分区内聚合，更高效，优先选择使用reduceByKey。
cache和checkPoint的比较
相同点：都是做 RDD 持久化的 比较： 1.cache:是在触发action之后，把数据写入到内存或者磁盘中。不会截断血缘关系 （设置缓存级别为memory_only：内存不足，只会部分缓存或者没有缓存，缓存会丢失,memory_and_disk :内存不足，会使用磁盘） 2.checkpoint 也是在触发action之后，执行任务。单独再启动一个job，负责写入数据到hdfs中。（把rdd中的数据，以二进制文本的方式写入到hdfs中，有几个分区，就有几个二进制文件） 3.某一个RDD被checkpoint之后，他的父依赖关系会被删除，血缘关系被截断，该RDD转换成了CheckPointRDD，以后再对该rdd的所有操作，都是从hdfs中的checkpoint的具体目录来读取数据。缓存之后，rdd的依赖关系还是存在的。 4.Cache在程序结束后会被清除，Checkpoint的RDD在程序结束后依然存在，不会被删除
spark应用程序的执行命令是什么？
/usr/local/spark-current2.3/bin/spark-submit \ --class com.wedoctor.Application \ --master yarn \ --deploy-mode client \ --driver-memory 1g \ --executor-memory 2g \ --queue root.wedw \ --num-executors 200 \ --jars \ /home/pgxl/liuzc/config-1.3.0.jar,/home/pgxl/liuzc/hadoop-lzo-0.4.20.jar,/home/pgxl/liuzc/elasticsearch-hadoop-hive-2.3.4.jar\ /home/pgxl/liuzc/sen.jar
Spark应用执行有哪些模式，其中哪几种是集群模式
最好把每种模式区别也说一下
1、本地local模式：一般用来调试
2、standalone模式：一般用来调试
3、spark on yarn模式：生产环境（这里又细分yarn-client和yarn-cluster模式需要知道这两种模式的区别:最大的区别是Driver的启动位置） spark on mesos模式 其中，standalone模式，spark on yarn模式，spark on mesos模式是集群模式
请说明spark中广播变量的用途
首先要知道广播变量是用来减少网络传输的一种优化方案，即在每个 Executor 的内存中，只驻留一份变量副本，而不是对 每个 task 都传输一次大变量，省了很多的网络传输， 对性能提升具有很大帮助， 而且会通过高效的广播算法来减少传输代价。
注意：要广播的变量值不能过大！
shuffle什么原因引起的？
当计算不仅仅需要本地数据的时候，那么就会需要把其他机器的数据拉取过来进行，这里就会引起shuffle，也就是所谓的洗牌
哪一些算子会引起shuffle？
1：大部分含有byKey的算子都会发生shuffle，如reduceByKey、groupByKey、sortByKey,combineByKey等
2：重分区类的算子:如repartition（其底层调用的是coalesce(shuffle=true)），coalesce等
3：join类的算子:比如join、cogroup等
4：去重类算子，如distinct
stage的划分依据？
这里不仅需要说明划分的本质，还要知道为什么要划分，划分有什么好处？
1、首先stage的划分根据宽依赖来决定，说白了就是当遇到会发生shuffle算子的时候就会开始切分stage。
同一个Stage可以有多个task并行执行。
2、那么这里需要知道宽窄依赖的区分：
宽依赖：父RDD的一个分区被子RDD的多个分区所依赖；且必须等到上一个阶段的计算完成后才能计算下一个阶段
窄依赖：父RDD的一个分区只能被一个子RDD的一个分区所依赖，因此多个分区可以并行计算，而且当一个分区的数据如果丢失，那么只需要重新计算对应的分区即可。
划分的核心算法就是回溯，反向解析，从触发action操作的那个rdd开始从后往前推,遇到窄依赖就加入到本Stage中，遇到宽依赖就进行划分
3、划分的好处：并行执行计算；当发生容错时不需要全部重新计算，基于rdd血缘依赖只需重新计算相关分区进行回溯即可
简述宽依赖和窄依赖概念，groupByKey,reduceByKey,map,filter,union五种操作哪些会导致宽依赖，哪些会导致窄依赖
宽依赖：父RDD的一个分区被子RDD的多个分区所依赖；且必须等到上一个阶段的计算完成后才能计算下一个阶段。 窄依赖：父RDD的一个分区只能被一个子RDD的一个分区所依赖，因此多个分区可以并行计算，而且当一个分区的数据如果丢失，那么只需要重新计算对应的分区即可。 其中groupByKey,reduceByKey是会发生shuffle的，会导致宽依赖进行划分stage. map,filter,union不会发生shuffle,属于窄依赖
当 Spark 涉及到数据库的操作时，如何减少 Spark 运行中数据库连接数？
使用 foreachPartition 代替 foreach，在 foreachPartition 内获取数据库的连接。
rdd的属性
主要考察对rdd的理解。先看下源码中的注释 * - A list of partitions * - A function for computing each split * - A list of dependencies on other RDDs * - Optionally, a Partitioner for key-value RDDs (e.g. to say that the RDD is hash-partitioned) * - Optionally, a list of preferred locations to compute each split on (e.g. block locations for * an HDFS file) 一组分片（Partition），即数据集的基本组成单位。对于RDD来说，每个分片都会被一个计算任务处理，并决定并行计算的粒度。用户可以在创建RDD时指定RDD的分片个数，如果没有指定，那么就会采用默认值。默认值就是程序所分配到的CPU Core的数目。 一个计算每个分区的函数。Spark中RDD的计算是以分片为单位的，每个RDD都会实现compute函数以达到这个目的。compute函数会对迭代器进行复合，不需要保存每次计算的结果。 RDD之间的依赖关系。RDD的每次转换都会生成一个新的RDD，所以RDD之间就会形成类似于流水线一样的前后依赖关系。在部分分区数据丢失时，Spark可以通过这个依赖关系重新计算丢失的分区数据，而不是对RDD的所有分区进行重新计算。 一个Partitioner，即RDD的分片函数。当前Spark中实现了两种类型的分片函数，一个是基于哈希的HashPartitioner，另外一个是基于范围的RangePartitioner。只有对于于key-value的RDD，才会有Partitioner，非key-value的RDD的Parititioner的值是None。Partitioner函数不但决定了RDD本身的分片数量，也决定了parent RDD Shuffle输出时的分片数量。 一个列表，存储存取每个Partition的优先位置（preferred location）。对于一个HDFS文件来说，这个列表保存的就是每个Partition所在的块的位置。按照“移动数据不如移动计算”的理念，Spark在进行任务调度的时候，会尽可能地将计算任务分配到其所要处理数据块的存储位置。
主要考察对rdd的理解。先看下源码中的注释 * - A list of partitions * - A function for computing each split * - A list of dependencies on other RDDs * - Optionally, a Partitioner for key-value RDDs (e.g. to say that the RDD is hash-partitioned) * - Optionally, a list of preferred locations to compute each split on (e.g. block locations for * an HDFS file) 一组分片（Partition），即数据集的基本组成单位。对于RDD来说，每个分片都会被一个计算任务处理，并决定并行计算的粒度。用户可以在创建RDD时指定RDD的分片个数，如果没有指定，那么就会采用默认值。默认值就是程序所分配到的CPU Core的数目。 一个计算每个分区的函数。Spark中RDD的计算是以分片为单位的，每个RDD都会实现compute函数以达到这个目的。compute函数会对迭代器进行复合，不需要保存每次计算的结果。 RDD之间的依赖关系。RDD的每次转换都会生成一个新的RDD，所以RDD之间就会形成类似于流水线一样的前后依赖关系。在部分分区数据丢失时，Spark可以通过这个依赖关系重新计算丢失的分区数据，而不是对RDD的所有分区进行重新计算。 一个Partitioner，即RDD的分片函数。当前Spark中实现了两种类型的分片函数，一个是基于哈希的HashPartitioner，另外一个是基于范围的RangePartitioner。只有对于于key-value的RDD，才会有Partitioner，非key-value的RDD的Parititioner的值是None。Partitioner函数不但决定了RDD本身的分片数量，也决定了parent RDD Shuffle输出时的分片数量。 一个列表，存储存取每个Partition的优先位置（preferred location）。对于一个HDFS文件来说，这个列表保存的就是每个Partition所在的块的位置。按照“移动数据不如移动计算”的理念，Spark在进行任务调度的时候，会尽可能地将计算任务分配到其所要处理数据块的存储位置。
算子分为哪几类(RDD支持哪几种类型的操作)
主要考察对算子的使用掌握程度 转换（Transformation): 现有的RDD通过转换生成一个新的RDD。lazy模式，延迟执行。 转换函数包括：map，filter，flatMap，groupByKey，reduceByKey，aggregateByKey，union,join, coalesce等等。 动作（Action） :在RDD上运行计算，并返回结果给驱动程序(Driver)或写入文件系统。 动作操作包括：reduce，collect，count，first，take，countByKey以及foreach等等。 collect：该方法把数据收集到driver端 Array数组类型。 注意： 1：所有的transformation只有遇到action才能被执行。当触发执行action之后，数据类型不再是rdd了，数据就会存储到指定文件系统中，或者直接打印结果或者收集起来。 2：RDD并不存储真正的数据，而是记录数据的存储位置信息以及数据的转换关系
主要考察对算子的使用掌握程度 转换（Transformation): 现有的RDD通过转换生成一个新的RDD。lazy模式，延迟执行。 转换函数包括：map，filter，flatMap，groupByKey，reduceByKey，aggregateByKey，union,join, coalesce等等。 动作（Action） :在RDD上运行计算，并返回结果给驱动程序(Driver)或写入文件系统。 动作操作包括：reduce，collect，count，first，take，countByKey以及foreach等等。 collect：该方法把数据收集到driver端 Array数组类型。 注意： 1：所有的transformation只有遇到action才能被执行。当触发执行action之后，数据类型不再是rdd了，数据就会存储到指定文件系统中，或者直接打印结果或者收集起来。 2：RDD并不存储真正的数据，而是记录数据的存储位置信息以及数据的转换关系
创建rdd的几种方式
1.集合并行化创建(有数据) val arr = Array(1,2,3,4,5) val rdd = sc.parallelize(arr) val rdd = sc.makeRDD(arr) //底层调用了parallelize方法 2.读取外部文件系统，如hdfs，或者读取本地文件(最常用的方式)(没数据) val rdd2 = sc.textFile("hdfs://hdp-01:9000/words.txt") // 读取本地文件 val rdd2 = sc.textFile(“file:///root/words.txt”) 3.从父RDD转换成新的子RDD 调用Transformation类的方法，生成新的RDD
spark运行流程
主要考察对spark内部原理的掌握度 角色： Worker的功能：定时和master通信；调度并管理自身的executor executor：由Worker启动的，程序最终在executor中运行，（程序运行的一个容器） 流程： 1:spark-submit命令执行时，会根据指定的master地址去向 Master发送请求，Master接收到Driver端(具体根据提交模式来判断Driver启动的地方)的任务请求之后，根据任务的请求资源进行调度，（采用打散的策略），尽可能的把任务资源平均分配，然后向WOrker发送指令 2:Worker收到Master的指令之后，就根据相应的资源，启动executor（cores,memory） 3:executor会向dirver端建立请求，通知driver，任务已经可以运行了 4:driver运行任务的时候，会把任务发送到executor中去运行。
Spark中coalesce与repartition的区别
1）关系： 两者都是用来改变 RDD 的 partition 数量的，repartition 底层调用的就是 coalesce 方法：coalesce(numPartitions, shuffle = true) 2）区别： repartition 一定会发生 shuffle，coalesce 根据传入的参数来判断是否发生 shuffle 一般情况下增大 rdd 的 partition 数量使用 repartition，减少 partition 数量时使用coalesce
sortBy 和 sortByKey的区别
sortBy既可以作用于RDD[K] ，还可以作用于RDD[(k,v)],底层会调用sortByKey sortByKey 只能作用于 RDD[K,V] 类型上。
sortBy既可以作用于RDD[K] ，还可以作用于RDD[(k,v)],底层会调用sortByKey sortByKey 只能作用于 RDD[K,V] 类型上。
map和mapPartitions的区别
map操作是对rdd中的每个元素进行处理 mapPartitions是对rdd中每个分区的迭代器进行操作 在生产环境中，使用mapPartitions代替map.因为mapPartitions比map的效率要高很多，
map操作是对rdd中的每个元素进行处理 mapPartitions是对rdd中每个分区的迭代器进行操作 在生产环境中，使用mapPartitions代替map.因为mapPartitions比map的效率要高很多，
数据存入Redis 优先使用map mapPartitions foreach foreachPartions哪个
使用 foreachPartition 原因一：map，mapPartition 是转换类的算子， 有返回值 原因二：写mysql,redis的连接数资源会少，例如： 当有100w条元素时那么对于foreach操作会有100w次连接。 对于foreachPartitions来说，是针对rdd分区进行迭代操作的。例如当有200个分区，那么只需要创建200次连接即可。一个分区的数据共用一个连接。 操作层面： 1.foreachParititon 每次迭代一个分区 2.foreach每次迭代一个元素。 对于foreach,foreachPartitions来说，该方法没有返回值，或者Unit。 主要作用于，没有返回值类型的操作（打印结果，写入到mysql数据库中） 在写入到redis,mysql的时候，优先使用foreachPartititon
reduceByKey和groupBykey的区别
reduceByKey会传一个聚合函数， 相当于 groupByKey+ mapValues reduceByKey 会有一个分区内聚合，而groupByKey没有 最核心的区别 结论：reduceByKey有分区内聚合，更高效，优先选择使用reduceByKey。
cache和checkPoint的比较
相同点：都是做 RDD 持久化的 比较： 1.cache:是在触发action之后，把数据写入到内存或者磁盘中。不会截断血缘关系 （设置缓存级别为memory_only：内存不足，只会部分缓存或者没有缓存，缓存会丢失,memory_and_disk :内存不足，会使用磁盘） 2.checkpoint 也是在触发action之后，执行任务。单独再启动一个job，负责写入数据到hdfs中。（把rdd中的数据，以二进制文本的方式写入到hdfs中，有几个分区，就有几个二进制文件） 3.某一个RDD被checkpoint之后，他的父依赖关系会被删除，血缘关系被截断，该RDD转换成了CheckPointRDD，以后再对该rdd的所有操作，都是从hdfs中的checkpoint的具体目录来读取数据。缓存之后，rdd的依赖关系还是存在的。 4.Cache在程序结束后会被清除，Checkpoint的RDD在程序结束后依然存在，不会被删除
spark streaming流式统计单词数量代码
JavaReceiverInputDStream localhost = javaStreamingContext.socketTextStream("localhost", 9999); JavaPairDStream stringIntegerJavaPairDStream = localhost.flatMap(x -> Arrays.asList(x.split(" ")).iterator()) .mapToPair(x -> new Tuple2<>(x, 1)) .reduceByKey((i1, i2) -> i1 + i2); stringIntegerJavaPairDStream.print(); stringIntegerJavaPairDStream.start(); stringIntegerJavaPairDStream.awaitTermination();
JavaReceiverInputDStream localhost = javaStreamingContext.socketTextStream("localhost", 9999); JavaPairDStream stringIntegerJavaPairDStream = localhost.flatMap(x -> Arrays.asList(x.split(" ")).iterator()) .mapToPair(x -> new Tuple2<>(x, 1)) .reduceByKey((i1, i2) -> i1 + i2); stringIntegerJavaPairDStream.print(); stringIntegerJavaPairDStream.start(); stringIntegerJavaPairDStream.awaitTermination();
简述map和flatMap的区别和应用场景
map是对每一个元素进行操作，常用于简单转换操作 flatmap是对每一个元素操作后并压平,常用于如词频统计等场景。 示例对以下语句进行拆分： “hello world"," how are you” map操作对上面的元素做单词切分会得到[hello,world],[how,are you] flatmap操作对上面的元素做切分会得到[hello,world,how,are,you]
map是对每一个元素进行操作，常用于简单转换操作 flatmap是对每一个元素操作后并压平,常用于如词频统计等场景。 示例对以下语句进行拆分： “hello world"," how are you” map操作对上面的元素做单词切分会得到[hello,world],[how,are you] flatmap操作对上面的元素做切分会得到[hello,world,how,are,you]
计算曝光数和点击数(该题目为笔试题，待后续上传图片)
答案完善中，请耐心等待
答案完善中，请耐心等待
分别列出几个常用的transformation和action算子
主要考察对算子的使用程度 转换算子：map,map,filter,reduceByKey,groupByKey,groupBy等 行动算子： foreach，foreachpartition,collect,collectAsMap,take,top,first,count,countByKey等
主要考察对算子的使用程度 转换算子：map,map,filter,reduceByKey,groupByKey,groupBy等 行动算子： foreach，foreachpartition,collect,collectAsMap,take,top,first,count,countByKey等
按照需求使用spark编写以下程序，要求使用scala语言
当前文件a.txt的格式，请统计每个单词出现的次数 A,b,c B,b,f,e
当前文件a.txt的格式，请统计每个单词出现的次数 A,b,c B,b,f,e
spark应用程序的执行命令是什么？
/usr/local/spark-current2.3/bin/spark-submit \ --class com.wedoctor.Application \ --master yarn \ --deploy-mode client \ --driver-memory 1g \ --executor-memory 2g \ --queue root.wedw \ --num-executors 200 \ --jars \ /home/pgxl/liuzc/config-1.3.0.jar,/home/pgxl/liuzc/hadoop-lzo-0.4.20.jar,/home/pgxl/liuzc/elasticsearch-hadoop-hive-2.3.4.jar\ /home/pgxl/liuzc/sen.jar
Spark应用执行有哪些模式，其中哪几种是集群模式
最好把每种模式区别也说一下
1、本地local模式：一般用来调试
2、standalone模式：一般用来调试
3、spark on yarn模式：生产环境（这里又细分yarn-client和yarn-cluster模式需要知道这两种模式的区别:最大的区别是Driver的启动位置） spark on mesos模式 其中，standalone模式，spark on yarn模式，spark on mesos模式是集群模式
请说明spark中广播变量的用途
首先要知道广播变量是用来减少网络传输的一种优化方案，即在每个 Executor 的内存中，只驻留一份变量副本，而不是对 每个 task 都传输一次大变量，省了很多的网络传输， 对性能提升具有很大帮助， 而且会通过高效的广播算法来减少传输代价。
注意：要广播的变量值不能过大！
以下代码会报错吗？如果会怎么解决 val arr = new ArrayList[String]; arr.foreach(println)
val arr = new ArrayList[String]; 这里会报错，需要改成 val arr: Array[String] = new Array[String](10) arr.foreach(println)打印不会报空指针
val arr = new ArrayList[String]; 这里会报错，需要改成 val arr: Array[String] = new Array[String](10) arr.foreach(println)打印不会报空指针
写出你用过的spark中的算子，其中哪些会产生shuffle过程
算子分为两大类：转换和触发 转换操作如：map,filter,flatmap,union,distinct,reduce,reduceByKey,groupByKey等 触发操作如：count,max,sum,take,first,collect,saveAs...等 会触发shuffle的算子有以下几大类: 1：大部分含有ByKey的算子都会发生shuffle，如reduceByKey、groupByKey、sortByKey,combineByKey等 2：重分区类的算子:如repartition（其底层调用的是coalesce(shuffle=true)），coalesce等 3：join类的算子:比如join、cogroup等 4：去重类算子，如distinct
算子分为两大类：转换和触发 转换操作如：map,filter,flatmap,union,distinct,reduce,reduceByKey,groupByKey等 触发操作如：count,max,sum,take,first,collect,saveAs...等 会触发shuffle的算子有以下几大类: 1：大部分含有ByKey的算子都会发生shuffle，如reduceByKey、groupByKey、sortByKey,combineByKey等 2：重分区类的算子:如repartition（其底层调用的是coalesce(shuffle=true)），coalesce等 3：join类的算子:比如join、cogroup等 4：去重类算子，如distinct
Spark中rdd与partition的区别
主要考察还是对rdd的理解 partition是rdd中最小的数据单元。当对rdd操作时，实际上是对每个分区进行操作。 需要注意的是： 只有KV类型的RDD才会有分区,而非KV类型的RDD对应的分区值是None
主要考察还是对rdd的理解 partition是rdd中最小的数据单元。当对rdd操作时，实际上是对每个分区进行操作。 需要注意的是： 只有KV类型的RDD才会有分区,而非KV类型的RDD对应的分区值是None
请写出创建Dateset的几种方式
Java版本： 1.外部数据加载生成DataFrame（底层也是DataSet的封装） Dataset json = sparkSession.read().json(""); 2.调用SparkSession.createDataSet方法获取 Encoder encoder = Encoders.bean(Person.class); Dataset dataset = sparkSession.createDataset(Collections.singletonList(person), encoder); 3.RDD转换DataSet &&DataFrame转DataSet JavaRDD map = sparkSession.read() .textFile("") .javaRDD() .map(line -> { String[] split = line.split(","); Person person = null; if(split.length==2){ person = new Person(); person.setName(split[0]); person.setAge(Integer.valueOf(split[1])); } return person; }); Dataset dataFrame = sparkSession.createDataFrame(map, Person.class); Encoder string = Encoders.STRING(); Dataset map1 = dataFrame.map((MapFunction) row -> "name:" + row.getString(1), string); Scala版本: 1.调用createDataSet val seq1 = Seq(Person("test", 24, 183)) val ds1 = spark.createDataset(seq1) 2.RDD转换DataSet,调用toDS val ds2 = rdd1.toDS() 3.调用range生成序列DataSet spark.range(5, 100, 5) 4.DataFrame转换为DataSet val df = spark.createDataFrame(List(Person("Test",34,"Test")).toDF("name","age","job"); val ds = df.as[Person];
Java版本： 1.外部数据加载生成DataFrame（底层也是DataSet的封装） Dataset json = sparkSession.read().json(""); 2.调用SparkSession.createDataSet方法获取 Encoder encoder = Encoders.bean(Person.class); Dataset dataset = sparkSession.createDataset(Collections.singletonList(person), encoder); 3.RDD转换DataSet &&DataFrame转DataSet JavaRDD map = sparkSession.read() .textFile("") .javaRDD() .map(line -> { String[] split = line.split(","); Person person = null; if(split.length==2){ person = new Person(); person.setName(split[0]); person.setAge(Integer.valueOf(split[1])); } return person; }); Dataset dataFrame = sparkSession.createDataFrame(map, Person.class); Encoder string = Encoders.STRING(); Dataset map1 = dataFrame.map((MapFunction) row -> "name:" + row.getString(1), string); Scala版本: 1.调用createDataSet val seq1 = Seq(Person("test", 24, 183)) val ds1 = spark.createDataset(seq1) 2.RDD转换DataSet,调用toDS val ds2 = rdd1.toDS() 3.调用range生成序列DataSet spark.range(5, 100, 5) 4.DataFrame转换为DataSet val df = spark.createDataFrame(List(Person("Test",34,"Test")).toDF("name","age","job"); val ds = df.as[Person];
描述一下RDD，DataFrame，DataSet的区别？
- RDD:分布式Java对象集合
优点:
1、编译时类型安全，编译时就能检查出类型错误
2、面向对象的编程风格，直接通过类名点的方式来操作数据
缺点:
1、序列化和反序列化的性能开销，无论是集群间的通信, 还是 IO 操作都需要对对象的结构和数据进行序列化和反序列化。
2、GC 的性能开销，频繁的创建和销毁对象, 势必会增加 GC
3、无法得知其对象的详细模式信息，不能在sparksql中直接使用
DataFrame:分布式Row对象集合
优点：
1、DataFrame 引入了 schema 和 off-heap schema : RDD 每一行的数据, 结构都是一样的，可以理解为一行就是一个通用无类型的JVM对象，这个结构就存储在 schema 中。 Spark 通过 schema 就能够读懂数据, 因此在通信和 IO 时就只需要序列化和反序列化数据, 而结构的部分就可以省略了。
2、由于spark理解schema,对执行计划有所优化,能够减少数据的读取,提升执行效率
缺点：
1、不是类型安全的，有部分类型不是在编译期检测，而是在运行期检测。如当使用一个不存在的字段时，编译期不会抛出错误，只有当执行的时候才会抛出
2、不是面向对象编程 DataSet
优点：
1、 DataSet 结合了 RDD 和 DataFrame 的优点，并带来的一个新的概念 Encoder。 当序列化数据时，Encoder 产生字节码与 off-heap 进行交互，能够达到按需访问数据的效果，而不用反序列化整个对象。Spark 还没有提供自定义 Encoder 的 API，但是未来会加入。
2、强类型支持，增加类型约束，编译期就可以检测 三
者之间的转换：
- RDD:分布式Java对象集合
优点:
1、编译时类型安全，编译时就能检查出类型错误
2、面向对象的编程风格，直接通过类名点的方式来操作数据
缺点:
1、序列化和反序列化的性能开销，无论是集群间的通信, 还是 IO 操作都需要对对象的结构和数据进行序列化和反序列化。
2、GC 的性能开销，频繁的创建和销毁对象, 势必会增加 GC
3、无法得知其对象的详细模式信息，不能在sparksql中直接使用
DataFrame:分布式Row对象集合
优点：
1、DataFrame 引入了 schema 和 off-heap schema : RDD 每一行的数据, 结构都是一样的，可以理解为一行就是一个通用无类型的JVM对象，这个结构就存储在 schema 中。 Spark 通过 schema 就能够读懂数据, 因此在通信和 IO 时就只需要序列化和反序列化数据, 而结构的部分就可以省略了。
2、由于spark理解schema,对执行计划有所优化,能够减少数据的读取,提升执行效率
缺点：
1、不是类型安全的，有部分类型不是在编译期检测，而是在运行期检测。如当使用一个不存在的字段时，编译期不会抛出错误，只有当执行的时候才会抛出
2、不是面向对象编程 DataSet
优点：
1、 DataSet 结合了 RDD 和 DataFrame 的优点，并带来的一个新的概念 Encoder。 当序列化数据时，Encoder 产生字节码与 off-heap 进行交互，能够达到按需访问数据的效果，而不用反序列化整个对象。Spark 还没有提供自定义 Encoder 的 API，但是未来会加入。
2、强类型支持，增加类型约束，编译期就可以检测 三
者之间的转换：
描述一下Spark中stage是如何划分的？描述一下shuffle的概念
Stage的划分是根据宽依赖，当触发action算子时，按照从后往前的回溯算法，当遇到会发生shuffle算子的时候，就会切分stage. Stage的划分本质是shuffle,即当遇到会发生shuffle算子的时候划分Stage Shuffle又称洗牌，即将相同key按照一定的分配策略划分到同一个task中进行计算。当不同的节点上存在相同key的时候，这里会发生网络IO传输。 在大数据各种计算引擎技术中，一般都会遵循“移动数据不同移动计算”的原则。所以尽量减少shuffle的发生，因为会涉及到网络传输、序列和反序列等耗时操作，降低处理效率
Stage的划分是根据宽依赖，当触发action算子时，按照从后往前的回溯算法，当遇到会发生shuffle算子的时候，就会切分stage. Stage的划分本质是shuffle,即当遇到会发生shuffle算子的时候划分Stage Shuffle又称洗牌，即将相同key按照一定的分配策略划分到同一个task中进行计算。当不同的节点上存在相同key的时候，这里会发生网络IO传输。 在大数据各种计算引擎技术中，一般都会遵循“移动数据不同移动计算”的原则。所以尽量减少shuffle的发生，因为会涉及到网络传输、序列和反序列等耗时操作，降低处理效率
RDD中的数据在哪？
RDD中的数据在数据源，RDD只是一个抽象的数据集，我们通过对RDD的操作就相当于对数据进行操作。
RDD中的数据在数据源，RDD只是一个抽象的数据集，我们通过对RDD的操作就相当于对数据进行操作。
如果对RDD进行cache操作后，数据在哪里？
数据在第一执行cache算子时会被加载到各个Executor进程的内存中，第二次就会直接从内存中读取而不会区磁盘。
数据在第一执行cache算子时会被加载到各个Executor进程的内存中，第二次就会直接从内存中读取而不会区磁盘。
Spark中Partition的数量由什么决定
和Mr一样，但是Spark默认最少有两个分区。
和Mr一样，但是Spark默认最少有两个分区。
shuffle什么原因引起的？
当计算不仅仅需要本地数据的时候，那么就会需要把其他机器的数据拉取过来进行，这里就会引起shuffle，也就是所谓的洗牌
哪一些算子会引起shuffle？
1：大部分含有byKey的算子都会发生shuffle，如reduceByKey、groupByKey、sortByKey,combineByKey等
2：重分区类的算子:如repartition（其底层调用的是coalesce(shuffle=true)），coalesce等
3：join类的算子:比如join、cogroup等
4：去重类算子，如distinct
Spark判断Shuffle的依据?
父RDD的一个分区中的数据有可能被分配到子RDD的多个分区中
父RDD的一个分区中的数据有可能被分配到子RDD的多个分区中
stage的划分依据？
这里不仅需要说明划分的本质，还要知道为什么要划分，划分有什么好处？
1、首先stage的划分根据宽依赖来决定，说白了就是当遇到会发生shuffle算子的时候就会开始切分stage。
同一个Stage可以有多个task并行执行。
2、那么这里需要知道宽窄依赖的区分：
宽依赖：父RDD的一个分区被子RDD的多个分区所依赖；且必须等到上一个阶段的计算完成后才能计算下一个阶段
窄依赖：父RDD的一个分区只能被一个子RDD的一个分区所依赖，因此多个分区可以并行计算，而且当一个分区的数据如果丢失，那么只需要重新计算对应的分区即可。
划分的核心算法就是回溯，反向解析，从触发action操作的那个rdd开始从后往前推,遇到窄依赖就加入到本Stage中，遇到宽依赖就进行划分
3、划分的好处：并行执行计算；当发生容错时不需要全部重新计算，基于rdd血缘依赖只需重新计算相关分区进行回溯即可
简述宽依赖和窄依赖概念，groupByKey,reduceByKey,map,filter,union五种操作哪些会导致宽依赖，哪些会导致窄依赖
宽依赖：父RDD的一个分区被子RDD的多个分区所依赖；且必须等到上一个阶段的计算完成后才能计算下一个阶段。 窄依赖：父RDD的一个分区只能被一个子RDD的一个分区所依赖，因此多个分区可以并行计算，而且当一个分区的数据如果丢失，那么只需要重新计算对应的分区即可。 其中groupByKey,reduceByKey是会发生shuffle的，会导致宽依赖进行划分stage. map,filter,union不会发生shuffle,属于窄依赖
spark streaming如何保证7*24小时运行机制？
1、事前保证： 首先要考虑的是SparkStreaming内部容错，如Driver容错、Worker容错、Master高可用、断点续传等机制。 然后再考虑程序的鲁棒性和扩展性，集群组件的稳定性
2、事中监控： 程序上线运行后，需要时刻监测活跃状态以及处理的情况，做到及时告警。如在程序中嵌入StreamListener时刻监控程序的异常情况。
3、事后修复： 程序重试机制，如当遇到系统崩溃或者对接组件挂掉导致程序不可用，那么需要及时进行切换重试，留出恢复时间
1、事前保证： 首先要考虑的是SparkStreaming内部容错，如Driver容错、Worker容错、Master高可用、断点续传等机制。 然后再考虑程序的鲁棒性和扩展性，集群组件的稳定性
2、事中监控： 程序上线运行后，需要时刻监测活跃状态以及处理的情况，做到及时告警。如在程序中嵌入StreamListener时刻监控程序的异常情况。
3、事后修复： 程序重试机制，如当遇到系统崩溃或者对接组件挂掉导致程序不可用，那么需要及时进行切换重试，留出恢复时间
共享变量和累加器
1、累加器（accumulator）是 Spark 中提供的一种分布式的变量机制，其原理类似于mapreduce，即分布式的改变，然后聚合这些改变。
2、累加器的一个常见用途是在调试时对作业执行过程中的事件进行计数。而广播变量用来高效分发较大的对象。 共享变量出现的原因： 通常在向 Spark 传递函数时，比如使用 map() 函数或者用 filter() 传条件时，可以使用驱动器程序中定义的变量，但是集群中运行的每个任务都会得到这些变量的一份新的副本，更新这些副本的值也不会影响驱动器中的对应变量。
3、Spark 的两个共享变量，累加器与广播变量，分别为结果聚合与广播这两种常见的通信模式突破了这一限制。
1、累加器（accumulator）是 Spark 中提供的一种分布式的变量机制，其原理类似于mapreduce，即分布式的改变，然后聚合这些改变。
2、累加器的一个常见用途是在调试时对作业执行过程中的事件进行计数。而广播变量用来高效分发较大的对象。 共享变量出现的原因： 通常在向 Spark 传递函数时，比如使用 map() 函数或者用 filter() 传条件时，可以使用驱动器程序中定义的变量，但是集群中运行的每个任务都会得到这些变量的一份新的副本，更新这些副本的值也不会影响驱动器中的对应变量。
3、Spark 的两个共享变量，累加器与广播变量，分别为结果聚合与广播这两种常见的通信模式突破了这一限制。
当 Spark 涉及到数据库的操作时，如何减少 Spark 运行中数据库连接数？
使用 foreachPartition 代替 foreach，在 foreachPartition 内获取数据库的连接。
Flatmap底层编码实现？
flatMap其实就是将RDD里的每一个元素执行自定义函数f，这时这个元素的结果转换成iterator，最后将这些再拼接成一个 新的RDD，也可以理解成原本的每个元素由横向执行函数f后再变为纵向。画红部分一直在回调，当RDD内没有元素为止。
flatMap其实就是将RDD里的每一个元素执行自定义函数f，这时这个元素的结果转换成iterator，最后将这些再拼接成一个 新的RDD，也可以理解成原本的每个元素由横向执行函数f后再变为纵向。画红部分一直在回调，当RDD内没有元素为止。
特别大的数据，怎么发送到excutor中？
答案完善中，请耐心等待
答案完善中，请耐心等待
Sqoop-6
数据仓库DataWareHouse-181
数仓技术架构体系
根据实际情况回答 离线：datax，hive，hadoop，spark，kylin 实时：lotstash，kafka，sparkstreaming，flink，hbase，es
datax 源码有改造过吗
改造过 解决datax抽hdfs数据到mysql之null值变成 \N 或者 转换错误 的问题
全量表(df),增量表(di),追加表(da)，拉链表(dz)的区别及使用场景
全量表 每天的所有的最新状态的数据。 1、全量表，有无变化，都要报 2、每次上报的数据都是所有的数据（变化的 + 没有变化的） 增量表 增量表：新增数据，增量数据是上次导出之后的新数据。 1、记录每次增加的量，而不是总量； 2、增量表，只报变化量，无变化不用报 3、业务库表中需有主键及创建时间，修改时间 拉链表： 维护历史状态，以及最新状态数据 适用情况： 1.数据量比较大 2.表中的部分字段会被更新 3.需要查看某一个时间点或者时间段的历史快照信息 查看某一个订单在历史某一个时间点的状态 某一个用户在过去某一段时间，下单次数 4.更新的比例和频率不是很大 如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费 优点 1、满足反应数据的历史状态 2、最大程度节省存储
什么是事实表，什么是维表
事实表： 事实表（Fact Table）是指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。 事实表作为数据仓库建模的核心，需要根据业务过程来设计，包含了引用的维度和业务过程有关的度量。 维表： 维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。维度是维度建模的基础和灵魂
datax与sqoop的优缺点
datax： 缺点： 单进程多线程 单机压力大 不支持分布式 社区开源不久，不太活跃 优点： 能显示运行信息，包括运行时间，数据量，消耗资源，脏数据稽核等 支持流量控制 sqoop： 优点： 运行模式是mr 扩展性好 支持分布式 社区活跃 缺点： 不支持运行信息显示 不支持流量控制
datax抽数碰到emoji表情怎么解决
我记得datax抽取碰到表情是能正常抽过来并展示的，在同步到Mysql的时候需要修改编码
需求驱动和业务驱动，数据开发和ETL开发，实战型和博客型
根据实际情况回答
如何用数据实现业务增长？
了解一下增长黑客
什么是大数据？千万级别的数据完全可以用传统的关系型数据库集群解决，为什么要用到大数据平台。
大数据（big data），IT行业术语，是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。 传统关系型数据库很难做数据治理，而且需要考虑到业务发展带来数据的海量增长，所以需要搭建大数据平台来支撑。
什么是数仓,建设数仓时碰到过什么问题
业务梳理，主题划分，模型建设，开发规范等方面回答
hdfs为什么会比较厌恶小文件
文件越多，maptask起的就越多
埋点的码表如何设计；
埋点管理平台输入，存储在msql，字段页面ID，点位规则唯一ID，点位名称，点位事件，私有参数等
集市层和公共层的区别；
数据公共层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD,DW和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标 数据集市（Data Mart）,也叫数据市场，是数据仓库的一个访问层，是按主题域组织的数据集合，用于支持部门级的决策。 数据集市是数据仓库的一个子集，通常面向特定的业务线。 在Kimball数据仓库架构中，数据集市是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，也可以说是虚拟的数据集市。 所以通俗一点，数据仓库包含了很多主题域，数据集市是主题域中的一个。
说说你从0-1搭建数仓都做了什么？你觉得最有挑战的是什么？
业务梳理，主题划分，模型建设，开发规范，指标体系建设，数据治理等方面回答
数据模型如何构建，星型、雪花、星座的区别和工作中如何使用；
l星形模型中有一张事实表，以及零个或多个维度表，事实表与维度表通过主键外键相关联，维度表之间没有关联，当所有维表都直接连接到“事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。星形模型是最简单，也是最常用的模型。由于星形模型只有一张大表，因此它相比于其他模型更适合于大数据处理。其他模型可以通过一定的转换，变为星形模型。 l当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的维度表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。如图，将地域维表又分解为国家，省份，城市等维表。它的优点是 :通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。 l星座模型是由星型模型延伸而来，星型模型是基于一张事实表而星座模式是基于多张事实表，并且共享维度表信息，这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型
数据倾斜，遇到哪些倾斜，怎么发现的？怎么处理的？；
表现：任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。 原因：某个reduce的数据输入量远远大于其他reduce数据的输入量 Sql本身存在倾斜 热点数据 Key分布不均 空值分布
数据仓库你做过什么优化
sql优化 模型优化 开发规范优化 ...
如何保证指标一致性；
指标体系建设
数据漂移如何解决；
既然很难解决数据漂移的问题，那么就在ODS 每个时间分区中向 前、向后多冗余 些数据，保障数据只会多不会少，而具体的数据切分 让下游根据自身不同的业务场景用不同的业务时间 proc time 来限制 但是这种方式会有一些数据误差，例如 个订单是当天支付的，但是第二天凌晨申请退款关闭了该订单，那么这条记录的订单状态会被更新，下游在统计支付订单状态时会出现错误。
任务延迟如何优化（SLA）？
l任务优化 l集群扩容 l任务下线 l...
聊一下数据资产。
l维度 l指标 l数据源 l词根 l字典 l词典 l数据表 l...
数据仓库主题的划分
参考Teradata的LDM模型；
Kimball和Inmon的相同和不同；
1.流程 Inmon架构是自顶向下，即从数据抽取-->数据仓库-->数据集市，以数据源为导向，是一种瀑布流开发方法，模型偏向于3NF， Kimball:架构是自下向上，即从数据集市(主题划分)-->数据仓库-->数据抽取，是以需求为导向的，一般使用星型模型 2事实表和维表 Inmon架构下，不强调事实表和维表的概念，因为数据源变化可能会比较大，更加强调的是数据清洗的工作 kimball架构强调模型由事实表和维表组成，注重事实表与维表的设计 3数据集市 Inmon架构中，数据集市有自己的物理存储，是真实存在的。 Kimball数据仓库架构中，数据集市是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，也可以说是虚拟的数据集市。是数据仓库的一个访问层，是按主题域组织的数据集合，用于支持部门级的决策。 4中心 Inmon架构是以部门为中心，而Kimball架构是以业务过程为中心 5EDW的访问 Inmon架构中用户可以直接访问企业数据仓库(EDW) Kimball架构中用户不可以直接访问企业数据仓库(EDW)，只能访问展现区数据
实时数据是否有了解，过程是什么
可以说一下实时计算或者实时数仓
业务库2亿数据入仓的策略
全量初始化，之后每次增量；
什么场景会出现数据倾斜，怎么解决？比如select user_id,count(1) from table group by user_id,其中某些user_id的访问量很大，查询不出结果该怎么办？
null值join： 加随机数 热点数据：单独join 某些user_id访问量很大，可以分两阶段聚合
聊一下技术架构，整个项目每个环节用的什么技术这个样子；
根据实际情况回答 离线：datax，hive，hadoop，spark，kylin 实时：lotstash，kafka，sparkstreaming，flink，hbase，es
你对当前的项目组有没有什么自己的看法、意见或者需要改进的地方，这个改进对你有没有什么影响
根据个人实际情况从人员配置，架构调整等方向回答即可
脏数据怎么处理？
根据公司实际情况作答
对了中间还有问数仓数据的输出主要是哪些还有数仓的分层；
ODS层 贴源层，与业务库保持一致，不做任何处理 CDM层 数据公共层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD,DW和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标 公共维度层（DIM）：基于维度建模理念思想，建立企业一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。 明细粒度事实层（DWD）：对数据进行规范化编码转换，清洗，统一格式，脱敏等，不做横向整合 主题宽表层(DW)对dwd各种信息进行整合，输出主题宽表(面向业务过 程，不同业务过程的信息不冗余建设，采用外键形式) 公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。 公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。 ADS层 数据应用层ADS（Application Data Service）：面向业务需求定制开发，存放数据产品个性化的统计指标数据。
你们需求的开发流程是什么样的
l需求分析调研(数据调研，需求调研，业务调研)：明确口径，评估排期，需求正规流程提交 l指标管理：完善指标命名规范，指标同名同义，指标与业务强相关，明确指标构成要素 l模型设计：完善开发流程规范，标准化业务调研，知识库文档集中管理，建立模型评审机制 lETL开发：ODS->DWD->DW->DWS->ADS l数据验证：制定数据测试标准 l任务调度：规范化调度参数配置 l上线管理
数据仓库模型建设可以使用范式建模吗，你是怎么看的？
Ods层是复合三范式的，但是在之后的建模过程中一般使用星型模型，以空间换时间
你们业务库怎么同步到数仓的
datax增量或者全量同步的
大宽表的优点与缺点？
优点 l提高查询性能 l快速响应 l方便使用，降低使用成本 l提高用户满意度 三缺点 l由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余 l另外就是灵活性差，就比如说线上业务表结构变更，宽表模式改造量也比较大 l开发宽表为了避免宽表重复迭代，我们应该去了解业务全流程，得需要知道需扩展哪些维度，沉淀哪些指标，这样就流程会比较长，特别是有些业务快速迭代的话，就有点捉襟见肘
dwd的表是全量的吗？为什么？
是的，我们公司dwd层的数据每个分区都是全量快照表
日志采集有没做过？
做过，logstash/flume采集
流量域一般怎么做？
日志采集，清洗，建模，指标统计
核心指标都有哪些？
根据实际情况回答
离线方面碰到什么困难
数据倾斜，开发规范，指标口径不统一等
null值怎么打散，打散的伪代码或者sql
rand()函数
每天的数据量
根据实际情况回答
一天多少任务，多少表
根据实际情况回答
列式存储是什么？行数比较大的情况，比如说上亿，那么列式存储是怎么做的？列式存储是为了解决什么问题？
列存储不同于传统的关系型数据库，其数据在表中是按列存储的。
列方式所带来的重要好处之一就是，由于查询中的选择规则是通过列来定义的，因此整个数据库是自动索引化的。
按列存储每个字段的数据聚集存储，在查询只需要少数几个字段的时候，能大大减少读取的数据量，一个字段的数据聚集存储，那就更容易为这种聚集存储设计更好的压缩/解压算法。
列式数据库在分析需求（获取特点——每次查询几个维度，通常是）时候，不仅搜索时间效率占优势，其空间效率也是很明显的。
特别是针对动辄按T计算的数据量来说，在分布式环境中能进行压缩处理能节省宝贵的内部带宽，从而提高整个计算任务性能。
维度建模和范式建模的区别；
范式建模常见于业务库 维度建模一般用于数仓建模，以空间换时间
数据仓库数据源都有哪些
爬虫数据 业务库数据 埋点日志
判断数仓搭建的好坏，怎么评价
数仓搭建的好坏，个人认为应该从以下几个方面思考：
1、数仓应用范围-即价值体现
2、数仓内部建设-即能力成熟度
首先价值体现主要围绕着“提效降本”，首先数仓建设的最终目的就是为了服务于业务，那么有没有为业务赋能这是一方面考虑；同时数仓建设也是服务于用户，即用户满意度也是可以用来评判数仓建设好坏的一项指标。
其次数仓内部能力成熟度，也就是主要围绕着规范度、及时性、稳定性、性能和成本、业务覆盖度、数据质量、复用扩展性这几个方面来衡量。
可以参考下面这篇文章：
https://mp.weixin.qq.com/s?__biz=MzU4MDkzMDE4Nw==&mid=2247489491&idx=1&sn=e2888bd70bdcbce3e0b4e4df2e2b965b&chksm=fd4e0837ca3981210a23d616d191e21a1cc16c0e6af9bb58ef95d236899f7dda5b77ce8a5c43&token=456993617&lang=zh_CN#rd
数据血缘你们怎么做的
答案完善中，请耐心等待
假设上游业务系统说业务数据出错了，你会怎么办？在生产中有实际出现吗？没有，那你有思考过怎么办吗？
答案完善中，请耐心等待
你们ads层怎么划分的
答案完善中，请耐心等待
1 维表和宽表的考查（主要考察维表的使用及维度退化手法）
维表数据一般根据ods层数据加工生成，在设计宽表的时候，可以适当的用一些维度退化手法，将维度退化到事实表中，减少事实表和维表的关联。 宽表的缺点在于数据冗余
维表数据一般根据ods层数据加工生成，在设计宽表的时候，可以适当的用一些维度退化手法，将维度退化到事实表中，减少事实表和维表的关联。 宽表的缺点在于数据冗余
数仓表命名规范
ods dwd层 l建表表名一律小写 l表名命名规则： [层次].[业务]_[表内容]_[周期+处理方式] dw dws层 l建表表名一律小写 l表名命名规则： [层次].[主题]_[表内容]_[周期+处理方式] 主题在dw层以后，表内容 参考业务系统表名，做适当处理，分表规则可以没有 如：wedw_ods.test_order_info_df wedw_ods表示层次，test表示主题，order_info表示表内容，d表示周期(天)，f表示处理方式(全量抽取) l临时表命名规则：[层次].tb_目标表名_程序开始执行时间_序号
ods dwd层 l建表表名一律小写 l表名命名规则： [层次].[业务]_[表内容]_[周期+处理方式] dw dws层 l建表表名一律小写 l表名命名规则： [层次].[主题]_[表内容]_[周期+处理方式] 主题在dw层以后，表内容 参考业务系统表名，做适当处理，分表规则可以没有 如：wedw_ods.test_order_info_df wedw_ods表示层次，test表示主题，order_info表示表内容，d表示周期(天)，f表示处理方式(全量抽取) l临时表命名规则：[层次].tb_目标表名_程序开始执行时间_序号
拉链表的使用场景
维护历史状态，以及最新状态数据 适用情况： 1.数据量比较大 2.表中的部分字段会被更新 3.需要查看某一个时间点或者时间段的历史快照信息 查看某一个订单在历史某一个时间点的状态 某一个用户在过去某一段时间，下单次数 4.更新的比例和频率不是很大 如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费 优点 1、满足反应数据的历史状态 2、最大程度节省存储
维护历史状态，以及最新状态数据 适用情况： 1.数据量比较大 2.表中的部分字段会被更新 3.需要查看某一个时间点或者时间段的历史快照信息 查看某一个订单在历史某一个时间点的状态 某一个用户在过去某一段时间，下单次数 4.更新的比例和频率不是很大 如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费 优点 1、满足反应数据的历史状态 2、最大程度节省存储
数据库和数据仓库有什么区别
l数据库是一种逻辑概念，用来存放数据的仓库，通过数据库软件来实现，数据库由许多表组成，表是二维的，一张表里面可以有很多字段，数据库的表，在与能够用二维表现多维关系。 l数据仓库是数据库概念的升级。从逻辑上理解，数据库和数据仓库没有区别，都是通过数据库软件实现的存放数据的地方，只不过从数据量来说，数据仓库要比数据库更庞大得多。数据仓库主要用于数据挖掘和数据分析，辅助领导做决策。 l数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。 l操作型处理，叫联机事务处理OLTP（On-Line Transaction Processing，），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。 l分析型处理，叫联机分析处理OLAP（On-Line Analytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。
l数据库是一种逻辑概念，用来存放数据的仓库，通过数据库软件来实现，数据库由许多表组成，表是二维的，一张表里面可以有很多字段，数据库的表，在与能够用二维表现多维关系。 l数据仓库是数据库概念的升级。从逻辑上理解，数据库和数据仓库没有区别，都是通过数据库软件实现的存放数据的地方，只不过从数据量来说，数据仓库要比数据库更庞大得多。数据仓库主要用于数据挖掘和数据分析，辅助领导做决策。 l数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。 l操作型处理，叫联机事务处理OLTP（On-Line Transaction Processing，），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。 l分析型处理，叫联机分析处理OLAP（On-Line Analytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。
有什么维表
时间维表、用户维表、产品维表、合同维表、地理维表等
时间维表、用户维表、产品维表、合同维表、地理维表等
数据源都有哪些
从大体上分为内部数据和外部数据： 内部数据又分为 业务库数据源:mysql,oracle,mongo 日志数据：ng日志，埋点日志 外部数据分为：爬虫数据
从大体上分为内部数据和外部数据： 内部数据又分为 业务库数据源:mysql,oracle,mongo 日志数据：ng日志，埋点日志 外部数据分为：爬虫数据
你们最大的表是什么表,数据量多少
ng日志表，三端(app,web,h5)中app端日志量最大，清洗入库后的数据一天大概xxxxW
ng日志表，三端(app,web,h5)中app端日志量最大，清洗入库后的数据一天大概xxxxW
数仓技术架构体系
根据实际情况回答 离线：datax，hive，hadoop，spark，kylin 实时：lotstash，kafka，sparkstreaming，flink，hbase，es
数据平台是怎样的，用到了阿里的那一套吗？
没用到阿里那一套，数据平台为自研产品
没用到阿里那一套，数据平台为自研产品
你了解的调度系统有那些？，你们公司用的是哪种调度系统
airflow，azkaban，ooize，我们公司使用的是airflow
airflow，azkaban，ooize，我们公司使用的是airflow
你们公司数仓底层是怎么抽数据的？
业务数据用的是datax 日志数据用的是logstash
业务数据用的是datax 日志数据用的是logstash
为什么datax抽数据要比sqoop 快？
datax单进程多线程
datax单进程多线程
埋点数据你们是怎样接入的
logstash-->kafka-->logstash-->hdfs
logstash-->kafka-->logstash-->hdfs
如果你们业务库的表有更新，你们数仓怎么处理的？
增量抽取
增量抽取
能独立搭建数仓吗
可以，这里需要描述数仓建设的流程
可以，这里需要描述数仓建设的流程
搭建过CDH 集群吗
搭建过
搭建过
说一下你们公司的大数据平台架构？你有参与吗？
根据实际情况回答 离线：datax，hive，hadoop，spark，kylin 实时：lotstash，kafka，sparkstreaming，flink，hbase，es
根据实际情况回答 离线：datax，hive，hadoop，spark，kylin 实时：lotstash，kafka，sparkstreaming，flink，hbase，es
介绍一下你自己的项目和所用的技术
这个根据实际情况回答
这个根据实际情况回答
对目前的流和批处理的认识？就是谈谈自己的感受
目前流处理和批处理共存，主要是看业务需求，批处理相对于流处理来说更稳定一点，但是未来肯定是流批一体的状态
目前流处理和批处理共存，主要是看业务需求，批处理相对于流处理来说更稳定一点，但是未来肯定是流批一体的状态
你了解那些OLAP 引擎，MPP 知道一些吗？clickHouse 了解一些吗？
Olap:Kylin mpp:GREENPLUM Clickhouse了解并且使用过
Olap:Kylin mpp:GREENPLUM Clickhouse了解并且使用过
Kylin 有了解吗？介绍一下原理
主要是做预计算，默认使用mr引擎，存储在hbase中
主要是做预计算，默认使用mr引擎，存储在hbase中
datax 源码有改造过吗
改造过 解决datax抽hdfs数据到mysql之null值变成 \N 或者 转换错误 的问题
你们数仓的APP 层是怎么对外提供服务的？
l直接存入mysql业务库，业务方直接读取 l数据存入mysql，以接口的形式提供数据 l数据存入kylin，需求方通过jdbc读取数据
l直接存入mysql业务库，业务方直接读取 l数据存入mysql，以接口的形式提供数据 l数据存入kylin，需求方通过jdbc读取数据
数据接入进来，你们是怎样规划的，有考虑数据的膨胀问题吗
会根据表数据量及后续业务的发展来选择数据抽取方案，会考虑数据膨胀问题，所以一般选用增量抽取的方式
会根据表数据量及后续业务的发展来选择数据抽取方案，会考虑数据膨胀问题，所以一般选用增量抽取的方式
简述拉链表，流水表以及快照表的含义和特点
拉链表： 维护历史状态，以及最新状态数据 适用情况： 1.数据量比较大 2.表中的部分字段会被更新 3.需要查看某一个时间点或者时间段的历史快照信息 查看某一个订单在历史某一个时间点的状态 某一个用户在过去某一段时间，下单次数 4.更新的比例和频率不是很大 如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费 优点 1、满足反应数据的历史状态 2、最大程度节省存储 流水表： 对于表的每一个修改都会记录，可以用于反映实际记录的变更 快照表： l按日分区，记录截止数据日期的全量数据 l快照表，有无变化都要报 l每次上报的数据都是所有的数据(变化的+没有变化的) l一天一个分区
拉链表： 维护历史状态，以及最新状态数据 适用情况： 1.数据量比较大 2.表中的部分字段会被更新 3.需要查看某一个时间点或者时间段的历史快照信息 查看某一个订单在历史某一个时间点的状态 某一个用户在过去某一段时间，下单次数 4.更新的比例和频率不是很大 如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费 优点 1、满足反应数据的历史状态 2、最大程度节省存储 流水表： 对于表的每一个修改都会记录，可以用于反映实际记录的变更 快照表： l按日分区，记录截止数据日期的全量数据 l快照表，有无变化都要报 l每次上报的数据都是所有的数据(变化的+没有变化的) l一天一个分区
全量表(df),增量表(di),追加表(da)，拉链表(dz)的区别及使用场景
全量表 每天的所有的最新状态的数据。 1、全量表，有无变化，都要报 2、每次上报的数据都是所有的数据（变化的 + 没有变化的） 增量表 增量表：新增数据，增量数据是上次导出之后的新数据。 1、记录每次增加的量，而不是总量； 2、增量表，只报变化量，无变化不用报 3、业务库表中需有主键及创建时间，修改时间 拉链表： 维护历史状态，以及最新状态数据 适用情况： 1.数据量比较大 2.表中的部分字段会被更新 3.需要查看某一个时间点或者时间段的历史快照信息 查看某一个订单在历史某一个时间点的状态 某一个用户在过去某一段时间，下单次数 4.更新的比例和频率不是很大 如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费 优点 1、满足反应数据的历史状态 2、最大程度节省存储
数仓建模的方式？
l选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。 l选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。 l识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。 l选择事实。确定分析需要衡量的指标
l选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。 l选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。 l识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。 l选择事实。确定分析需要衡量的指标
什么是事实表，什么是维表
事实表： 事实表（Fact Table）是指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。 事实表作为数据仓库建模的核心，需要根据业务过程来设计，包含了引用的维度和业务过程有关的度量。 维表： 维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。维度是维度建模的基础和灵魂
如果业务库修改了数据，但是更新时间没用修改，这个数据能抽过来吗？应该怎么处理
抽取不过来，只能通过监听binlog实时采集
抽取不过来，只能通过监听binlog实时采集
缓慢变化维如何处理，几种方式
l直接更新字段 l加一行 l加一列 l拉链表处理
l直接更新字段 l加一行 l加一列 l拉链表处理
datax与sqoop的优缺点
datax： 缺点： 单进程多线程 单机压力大 不支持分布式 社区开源不久，不太活跃 优点： 能显示运行信息，包括运行时间，数据量，消耗资源，脏数据稽核等 支持流量控制 sqoop： 优点： 运行模式是mr 扩展性好 支持分布式 社区活跃 缺点： 不支持运行信息显示 不支持流量控制
datax抽数碰到emoji表情怎么解决
我记得datax抽取碰到表情是能正常抽过来并展示的，在同步到Mysql的时候需要修改编码
工作中碰到什么困难，怎么解决的
可以从业务理解，团队协作和技术难度上回答
可以从业务理解，团队协作和技术难度上回答
如何用数据给公司带来收益
用户画像，运营平台，精准营销，推荐系统等
用户画像，运营平台，精准营销，推荐系统等
需求驱动和业务驱动，数据开发和ETL开发，实战型和博客型
根据实际情况回答
如何用数据实现业务增长？
了解一下增长黑客
什么是大数据？千万级别的数据完全可以用传统的关系型数据库集群解决，为什么要用到大数据平台。
大数据（big data），IT行业术语，是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。 传统关系型数据库很难做数据治理，而且需要考虑到业务发展带来数据的海量增长，所以需要搭建大数据平台来支撑。
数据质量管理和元数据管理怎么做的？
数据质量： 完整性 一致性 准确性 唯一性 关联性 真实性 及时性 逻辑检查 离群值检查 自定义规则 波动稽核 元数据管理： l技术元数据 l存储元数据 l运行元数据 l计算元数据 l调度元数据 l运维元数据 业务元数据 l维度 l指标
数据质量： 完整性 一致性 准确性 唯一性 关联性 真实性 及时性 逻辑检查 离群值检查 自定义规则 波动稽核 元数据管理： l技术元数据 l存储元数据 l运行元数据 l计算元数据 l调度元数据 l运维元数据 业务元数据 l维度 l指标
什么是数仓,建设数仓时碰到过什么问题
业务梳理，主题划分，模型建设，开发规范等方面回答
hdfs为什么会比较厌恶小文件
文件越多，maptask起的就越多
数据源是来自于哪里
业务库，日志数据
业务库，日志数据
埋点的码表如何设计；
埋点管理平台输入，存储在msql，字段页面ID，点位规则唯一ID，点位名称，点位事件，私有参数等
集市层和公共层的区别；
数据公共层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD,DW和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标 数据集市（Data Mart）,也叫数据市场，是数据仓库的一个访问层，是按主题域组织的数据集合，用于支持部门级的决策。 数据集市是数据仓库的一个子集，通常面向特定的业务线。 在Kimball数据仓库架构中，数据集市是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，也可以说是虚拟的数据集市。 所以通俗一点，数据仓库包含了很多主题域，数据集市是主题域中的一个。
缓慢变化维的处理方式
l直接更新字段 l加一行 l加一列 l拉链表处理
l直接更新字段 l加一行 l加一列 l拉链表处理
告警平台你们怎么做的，说一下
基础架构组和数据平台开发组做的
基础架构组和数据平台开发组做的
说说你从0-1搭建数仓都做了什么？你觉得最有挑战的是什么？
业务梳理，主题划分，模型建设，开发规范，指标体系建设，数据治理等方面回答
数据模型如何构建，星型、雪花、星座的区别和工作中如何使用；
l星形模型中有一张事实表，以及零个或多个维度表，事实表与维度表通过主键外键相关联，维度表之间没有关联，当所有维表都直接连接到“事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。星形模型是最简单，也是最常用的模型。由于星形模型只有一张大表，因此它相比于其他模型更适合于大数据处理。其他模型可以通过一定的转换，变为星形模型。 l当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的维度表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。如图，将地域维表又分解为国家，省份，城市等维表。它的优点是 :通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。 l星座模型是由星型模型延伸而来，星型模型是基于一张事实表而星座模式是基于多张事实表，并且共享维度表信息，这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型
如何优化整个数仓的执行时长，比如7点所有任务跑完，如何优化到5点；
l任务优化 l任务下线 l模型优化 l集群扩容
l任务优化 l任务下线 l模型优化 l集群扩容
数据倾斜，遇到哪些倾斜，怎么发现的？怎么处理的？；
表现：任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。 原因：某个reduce的数据输入量远远大于其他reduce数据的输入量 Sql本身存在倾斜 热点数据 Key分布不均 空值分布
数据仓库你做过什么优化
sql优化 模型优化 开发规范优化 ...
如何保证指标一致性；
指标体系建设
了解onedata吗，说说你的理解；
l统一指标管理，保证了指标定义、计算口径、数据来源的一致性。 l统一维度管理，保证了维度定义、维度值的一致性。 l统一维表管理，保证了维表及维表主键编码的唯一性。 l统一数据出口，实现了维度和指标元数据信息的唯一出口，维值和指标数据的唯一出口。
l统一指标管理，保证了指标定义、计算口径、数据来源的一致性。 l统一维度管理，保证了维度定义、维度值的一致性。 l统一维表管理，保证了维表及维表主键编码的唯一性。 l统一数据出口，实现了维度和指标元数据信息的唯一出口，维值和指标数据的唯一出口。
数据漂移如何解决；
既然很难解决数据漂移的问题，那么就在ODS 每个时间分区中向 前、向后多冗余 些数据，保障数据只会多不会少，而具体的数据切分 让下游根据自身不同的业务场景用不同的业务时间 proc time 来限制 但是这种方式会有一些数据误差，例如 个订单是当天支付的，但是第二天凌晨申请退款关闭了该订单，那么这条记录的订单状态会被更新，下游在统计支付订单状态时会出现错误。
实时场景如何解决的；
实时计算
实时计算
拉链表如何设计，拉链表实现逻辑及拉链表如何回滚？
维护历史状态，以及最新状态数据 适用情况： 1.数据量比较大 2.表中的部分字段会被更新 3.需要查看某一个时间点或者时间段的历史快照信息 查看某一个订单在历史某一个时间点的状态 某一个用户在过去某一段时间，下单次数 4.更新的比例和频率不是很大 如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费 优点 1、满足反应数据的历史状态 2、最大程度节省存储 增加两个字段： start_dt(表示该条记录的生命周期开始时间——周期快照时的状态) end_dt(该条记录的生命周期结束时间) end_dt= ‘9999-12-31’ 表示该条记录目前处于有效状态 拉链表回滚 修正拉链表回滚问题本质就是： 其实目的就是找到历史的快照。 历史的快照可以根据起始更新时间，那你就找endtime小于你出错的数据就行了，出错日期的数据就行了。 重新导入数据，将原始拉链表数据过滤到指定日期之前即可。 举例： 拉链表dwd_userinfo_db,目前时间是2020-12-15，想回滚到2020-11-27,那么拉链表的状态得是2020-11-26 userid starttime endtime 1 2020-11-12 2020-11-26 1 2020-11-27 9999-99-99 2 2020-11-16 2020-12-13 2 2020-12-14 9999-99-99 拉链表回滚：过滤starttime<=2020-11-26的数据，将endtime>=2020-11-26的修改为9999-99-99 insert overwrite table dwd_userinfo_db select userid, starttime, if(endtime>=2020-11-26,'9999-99-99',endtime) from dwd_userinfo_db where starttime<=2020-11-26
维护历史状态，以及最新状态数据 适用情况： 1.数据量比较大 2.表中的部分字段会被更新 3.需要查看某一个时间点或者时间段的历史快照信息 查看某一个订单在历史某一个时间点的状态 某一个用户在过去某一段时间，下单次数 4.更新的比例和频率不是很大 如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费 优点 1、满足反应数据的历史状态 2、最大程度节省存储 增加两个字段： start_dt(表示该条记录的生命周期开始时间——周期快照时的状态) end_dt(该条记录的生命周期结束时间) end_dt= ‘9999-12-31’ 表示该条记录目前处于有效状态 拉链表回滚 修正拉链表回滚问题本质就是： 其实目的就是找到历史的快照。 历史的快照可以根据起始更新时间，那你就找endtime小于你出错的数据就行了，出错日期的数据就行了。 重新导入数据，将原始拉链表数据过滤到指定日期之前即可。 举例： 拉链表dwd_userinfo_db,目前时间是2020-12-15，想回滚到2020-11-27,那么拉链表的状态得是2020-11-26 userid starttime endtime 1 2020-11-12 2020-11-26 1 2020-11-27 9999-99-99 2 2020-11-16 2020-12-13 2 2020-12-14 9999-99-99 拉链表回滚：过滤starttime<=2020-11-26的数据，将endtime>=2020-11-26的修改为9999-99-99 insert overwrite table dwd_userinfo_db select userid, starttime, if(endtime>=2020-11-26,'9999-99-99',endtime) from dwd_userinfo_db where starttime<=2020-11-26
平台选型依据
根据业务及需求
根据业务及需求
数仓分层、模型、每层都是做什么的？为什么这么做？
ODS层 贴源层，与业务库保持一致，不做任何处理 CDM层 数据公共层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD,DW和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标 公共维度层（DIM）：基于维度建模理念思想，建立企业一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。 明细粒度事实层（DWD）：对数据进行规范化编码转换，清洗，统一格式，脱敏等，不做横向整合 主题宽表层(DW)对dwd各种信息进行整合，输出主题宽表(面向业务过 程，不同业务过程的信息不冗余建设，采用外键形式) 公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。 公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。 ADS层 数据应用层ADS（Application Data Service）：面向业务需求定制开发，存放数据产品个性化的统计指标数据。 为什么要分层？ l清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。 l数据血缘追踪：简单来讲可以这样理解，我们最终给业务呈现的是一张能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。 l减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。 l把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
ODS层 贴源层，与业务库保持一致，不做任何处理 CDM层 数据公共层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD,DW和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标 公共维度层（DIM）：基于维度建模理念思想，建立企业一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。 明细粒度事实层（DWD）：对数据进行规范化编码转换，清洗，统一格式，脱敏等，不做横向整合 主题宽表层(DW)对dwd各种信息进行整合，输出主题宽表(面向业务过 程，不同业务过程的信息不冗余建设，采用外键形式) 公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。 公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。 ADS层 数据应用层ADS（Application Data Service）：面向业务需求定制开发，存放数据产品个性化的统计指标数据。 为什么要分层？ l清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。 l数据血缘追踪：简单来讲可以这样理解，我们最终给业务呈现的是一张能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。 l减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。 l把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
交叉维度的解决方案？
处理多值维度最好的办法是降低事实表的粒度。这种处理方式也是维度建模的一个原则，即事实表应该建立在最细粒度上。这样的处理，需要对事实表的事实进行分摊。 但是有些时候，事实表的粒度是不能降低的，多值维度的出现是无法避免的。如上述交叉维度，事实表与用户维度没有直接的关系，不能将数据粒度进行细分，即使细分的话帐户余额也很难分摊。这时，可以采用桥接表技术进行处理。在帐户维度表和用户维度表之间建立个帐户-用户桥接表。这个桥接表可以解决掉帐户维度和用户维度之间的多对多关系，也解决掉的帐户维度表的多值维度问题。
处理多值维度最好的办法是降低事实表的粒度。这种处理方式也是维度建模的一个原则，即事实表应该建立在最细粒度上。这样的处理，需要对事实表的事实进行分摊。 但是有些时候，事实表的粒度是不能降低的，多值维度的出现是无法避免的。如上述交叉维度，事实表与用户维度没有直接的关系，不能将数据粒度进行细分，即使细分的话帐户余额也很难分摊。这时，可以采用桥接表技术进行处理。在帐户维度表和用户维度表之间建立个帐户-用户桥接表。这个桥接表可以解决掉帐户维度和用户维度之间的多对多关系，也解决掉的帐户维度表的多值维度问题。
增量处理的逻辑说一下
初始化，全量抽取 根据更新时间增量抽取业务库修改或者新增的数据 和之前的全量数据进行merge去重插入到最新的分区
初始化，全量抽取 根据更新时间增量抽取业务库修改或者新增的数据 和之前的全量数据进行merge去重插入到最新的分区
任务延迟如何优化（SLA）？
l任务优化 l集群扩容 l任务下线 l...
聊一下数据资产。
l维度 l指标 l数据源 l词根 l字典 l词典 l数据表 l...
数仓的搭建
业务梳理，主题划分，模型建设，开发规范，数据治理等方面回答
业务梳理，主题划分，模型建设，开发规范，数据治理等方面回答
分工 角色
数据开发，数据分析师，产品经理，项目经理等
数据开发，数据分析师，产品经理，项目经理等
sql问题：连续活跃n天用户的获取；
连续登录 假设我们的字段有 id 和 登录日期 dt 我们以连续登录3天为例 select id,diffdt from ( select id, sortdt - dt as diffdt from (select id, dt, rownumber() over(partition by id order by dt) as sortdt from employee )t1 )t2 group by id,diffdt having count(*) = 3;
连续登录 假设我们的字段有 id 和 登录日期 dt 我们以连续登录3天为例 select id,diffdt from ( select id, sortdt - dt as diffdt from (select id, dt, rownumber() over(partition by id order by dt) as sortdt from employee )t1 )t2 group by id,diffdt having count(*) = 3;
数据倾斜的sql如何优化；数据量大的sql如何优化？
根据实际情况null值替换，二次聚合或者热点数据单独处理等方式
根据实际情况null值替换，二次聚合或者热点数据单独处理等方式
数据仓库主题的划分
参考Teradata的LDM模型；
Kimball和Inmon的相同和不同；
1.流程 Inmon架构是自顶向下，即从数据抽取-->数据仓库-->数据集市，以数据源为导向，是一种瀑布流开发方法，模型偏向于3NF， Kimball:架构是自下向上，即从数据集市(主题划分)-->数据仓库-->数据抽取，是以需求为导向的，一般使用星型模型 2事实表和维表 Inmon架构下，不强调事实表和维表的概念，因为数据源变化可能会比较大，更加强调的是数据清洗的工作 kimball架构强调模型由事实表和维表组成，注重事实表与维表的设计 3数据集市 Inmon架构中，数据集市有自己的物理存储，是真实存在的。 Kimball数据仓库架构中，数据集市是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，也可以说是虚拟的数据集市。是数据仓库的一个访问层，是按主题域组织的数据集合，用于支持部门级的决策。 4中心 Inmon架构是以部门为中心，而Kimball架构是以业务过程为中心 5EDW的访问 Inmon架构中用户可以直接访问企业数据仓库(EDW) Kimball架构中用户不可以直接访问企业数据仓库(EDW)，只能访问展现区数据
怎么进行数据建模？
l选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。 l选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。 l识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。 l选择事实。确定分析需要衡量的指标
l选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。 l选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。 l识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。 l选择事实。确定分析需要衡量的指标
实时数据是否有了解，过程是什么
可以说一下实时计算或者实时数仓
业务库2亿数据入仓的策略
全量初始化，之后每次增量；
什么场景会出现数据倾斜，怎么解决？比如select user_id,count(1) from table group by user_id,其中某些user_id的访问量很大，查询不出结果该怎么办？
null值join： 加随机数 热点数据：单独join 某些user_id访问量很大，可以分两阶段聚合
sql里面on和where有区别吗？
不考虑where条件下,left join 会把左表所有数据查询出来，on及其后面的条件仅仅会影响右表的数据(符合就显示,不符合全部为null) 在匹配阶段，where子句的条件都不会被使用，仅在匹配阶段完成以后，where子句条件才会被使用，它将从匹配阶段产生的数据中检索过滤 所以左连接关注的是左边的主表数据，不应该把on后面的从表中的条件加到where后，这样会影响原有主表中的数据 where后面：是先连接然生成临时查询结果，然后再筛选 on后面：先根据条件过滤筛选，再连接生成临时查询结果
不考虑where条件下,left join 会把左表所有数据查询出来，on及其后面的条件仅仅会影响右表的数据(符合就显示,不符合全部为null) 在匹配阶段，where子句的条件都不会被使用，仅在匹配阶段完成以后，where子句条件才会被使用，它将从匹配阶段产生的数据中检索过滤 所以左连接关注的是左边的主表数据，不应该把on后面的从表中的条件加到where后，这样会影响原有主表中的数据 where后面：是先连接然生成临时查询结果，然后再筛选 on后面：先根据条件过滤筛选，再连接生成临时查询结果
聊一下技术架构，整个项目每个环节用的什么技术这个样子；
根据实际情况回答 离线：datax，hive，hadoop，spark，kylin 实时：lotstash，kafka，sparkstreaming，flink，hbase，es
hive、hbase、spark等大数据组件，熟悉哪个或者哪些？我说hive和hbase，对方就问hive和hbase的原理，差异等问题；
根据自己对技术栈的熟悉程度进行选择
根据自己对技术栈的熟悉程度进行选择
有没有实时数仓的经验，数据实时入仓思路
canal+kafka+flink+clickhouse+redis
canal+kafka+flink+clickhouse+redis
你对当前的项目组有没有什么自己的看法、意见或者需要改进的地方，这个改进对你有没有什么影响
根据个人实际情况从人员配置，架构调整等方向回答即可
ods的增量能否做成通用的？
题目不明确
题目不明确
脏数据怎么处理？
根据公司实际情况作答
从原理上说一下mpp和mr的区别
MPP跑的是SQL,而Hadoop底层处理是MapReduce程序。 MPP虽然是宣称可以横向扩展Scale OUT，但是这种扩展一般是扩展到100左右，而Hadoop一般可以扩展1000+。 MPP数据库有对SQL的完整兼容和一些事务的处理能力，对于用户来说，在实际的使用场景中，如果数据扩展需求不是特别大，需要的处理节点不多，数据都是结构化的数据，习惯使用传统的RDBMS的很多特性的场景，可以考虑MPP,例如Greenplum/Gbase等。 如果有很多非结构化数据，或者数据量巨大，有需要扩展到成百上千个数据节点需求的，这个时候Hadoop是更好的选择。
MPP跑的是SQL,而Hadoop底层处理是MapReduce程序。 MPP虽然是宣称可以横向扩展Scale OUT，但是这种扩展一般是扩展到100左右，而Hadoop一般可以扩展1000+。 MPP数据库有对SQL的完整兼容和一些事务的处理能力，对于用户来说，在实际的使用场景中，如果数据扩展需求不是特别大，需要的处理节点不多，数据都是结构化的数据，习惯使用传统的RDBMS的很多特性的场景，可以考虑MPP,例如Greenplum/Gbase等。 如果有很多非结构化数据，或者数据量巨大，有需要扩展到成百上千个数据节点需求的，这个时候Hadoop是更好的选择。
对了中间还有问数仓数据的输出主要是哪些还有数仓的分层；
ODS层 贴源层，与业务库保持一致，不做任何处理 CDM层 数据公共层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD,DW和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标 公共维度层（DIM）：基于维度建模理念思想，建立企业一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。 明细粒度事实层（DWD）：对数据进行规范化编码转换，清洗，统一格式，脱敏等，不做横向整合 主题宽表层(DW)对dwd各种信息进行整合，输出主题宽表(面向业务过 程，不同业务过程的信息不冗余建设，采用外键形式) 公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。 公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。 ADS层 数据应用层ADS（Application Data Service）：面向业务需求定制开发，存放数据产品个性化的统计指标数据。
报表如何展示
l自研报表系统 lpowerBI ltableau
l自研报表系统 lpowerBI ltableau
数据源，怎么同步，同步时对业务库的性能影响，同步后怎么处理，使用方是谁，怎么使用
datax同步后清洗，分层建模 使用方是各个团队，搜索，运营，分析师等
datax同步后清洗，分层建模 使用方是各个团队，搜索，运营，分析师等
如何判断一个模型的好坏
1.模型层的完整度 比较好的模型，使用方是可以直接从该模型获取所有想要的数据的，如果dws，ads，dm层直接引用ods层的表比例太大，即跨层引用率太高，则该模型不是最优，可以继续优化 2.复用度 dw，dws下游直接产出的表的数量 3.规范度 表需要关联上主题域并且需要分层 表命名符合规范(清晰、一致，表名需易于使用方理解) 字段命名是依赖于词根 4.数据可回滚 重跑数据的情况下，数据结果不变 5.核心模型与扩展模型分离 建立核心模型与扩展模型体系，核心模型包括的宇段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的宇段过度侵人核心模型，以免破坏核心模型的架构简洁性与可维护性。
1.模型层的完整度 比较好的模型，使用方是可以直接从该模型获取所有想要的数据的，如果dws，ads，dm层直接引用ods层的表比例太大，即跨层引用率太高，则该模型不是最优，可以继续优化 2.复用度 dw，dws下游直接产出的表的数量 3.规范度 表需要关联上主题域并且需要分层 表命名符合规范(清晰、一致，表名需易于使用方理解) 字段命名是依赖于词根 4.数据可回滚 重跑数据的情况下，数据结果不变 5.核心模型与扩展模型分离 建立核心模型与扩展模型体系，核心模型包括的宇段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的宇段过度侵人核心模型，以免破坏核心模型的架构简洁性与可维护性。
你们需求的开发流程是什么样的
l需求分析调研(数据调研，需求调研，业务调研)：明确口径，评估排期，需求正规流程提交 l指标管理：完善指标命名规范，指标同名同义，指标与业务强相关，明确指标构成要素 l模型设计：完善开发流程规范，标准化业务调研，知识库文档集中管理，建立模型评审机制 lETL开发：ODS->DWD->DW->DWS->ADS l数据验证：制定数据测试标准 l任务调度：规范化调度参数配置 l上线管理
如何判定一个表是事实表还是维度表？
事实表（Fact Table）是指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。 事实表作为数据仓库建模的核心，需要根据业务过程来设计，包含了引用的维度和业务过程有关的度量。 维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。维度是维度建模的基础和灵魂，
事实表（Fact Table）是指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。 事实表作为数据仓库建模的核心，需要根据业务过程来设计，包含了引用的维度和业务过程有关的度量。 维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。维度是维度建模的基础和灵魂，
数据建模过程说一下？
l选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。 l选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。 l识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。 l选择事实。确定分析需要衡量的指标
l选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。 l选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。 l识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。 l选择事实。确定分析需要衡量的指标
三范式知道吗，说一下？
第一范式：表中的每一列都是不可拆分的原子项 第二范式要同时满足下面两个条件： l满足第一范式。 l没有部分依赖。 第三范式要同时满足下面两个条件： l满足第二范式。 l没有传递依赖。 简单点说，关系重复，能互相推导出来
第一范式：表中的每一列都是不可拆分的原子项 第二范式要同时满足下面两个条件： l满足第一范式。 l没有部分依赖。 第三范式要同时满足下面两个条件： l满足第二范式。 l没有传递依赖。 简单点说，关系重复，能互相推导出来
数据仓库模型建设可以使用范式建模吗，你是怎么看的？
Ods层是复合三范式的，但是在之后的建模过程中一般使用星型模型，以空间换时间
你们业务库怎么同步到数仓的
datax增量或者全量同步的
大宽表的优点与缺点？
优点 l提高查询性能 l快速响应 l方便使用，降低使用成本 l提高用户满意度 三缺点 l由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余 l另外就是灵活性差，就比如说线上业务表结构变更，宽表模式改造量也比较大 l开发宽表为了避免宽表重复迭代，我们应该去了解业务全流程，得需要知道需扩展哪些维度，沉淀哪些指标，这样就流程会比较长，特别是有些业务快速迭代的话，就有点捉襟见肘
dwd的表是全量的吗？为什么？
是的，我们公司dwd层的数据每个分区都是全量快照表
你们开发规范是怎样的？
l分层规范 l表命名规范 l字段命名规范 l注释规范 l数据类型规范 l分区规范 l词根规范 l指标规范 l数据抽取规范 l码表规范
l分层规范 l表命名规范 l字段命名规范 l注释规范 l数据类型规范 l分区规范 l词根规范 l指标规范 l数据抽取规范 l码表规范
你们公司有哪些主题？
用户，财务，订单，支付、物流等
用户，财务，订单，支付、物流等
日志采集有没做过？
做过，logstash/flume采集
流量域一般怎么做？
日志采集，清洗，建模，指标统计
核心指标都有哪些？
根据实际情况回答
如果你的代码运行很慢，你会怎么开始排查？
从服务器资源，数据量，执行引擎，数据倾斜，sql调优，执行计划等去作答
从服务器资源，数据量，执行引擎，数据倾斜，sql调优，执行计划等去作答
你们数据量大概有多大？
根据实际情况回答
根据实际情况回答
离线方面碰到什么困难
数据倾斜，开发规范，指标口径不统一等
datax源码有没有看过
看过
看过
何计算新用户和老用户？
根据设备id和登录id去判断
根据设备id和登录id去判断
Parquet和Orc和Rc的比较？
在我们当前的数据集和hive版本环境下，在文件写入方面，ORC相比RC文件的优势不显著，一些场合RC文件还要更优，在查询检索方面，ORC则基本是更优的，性能差距大小取决于具体数据集和检索模式。如果Hive能集成ORC更新的版本，支持LZ4，并修复一些Bug，那应该就没有任何再使用RC的理由了 至于Parquet，可以考虑在需要支持深度嵌套的数据结构的应用场合中去使用
在我们当前的数据集和hive版本环境下，在文件写入方面，ORC相比RC文件的优势不显著，一些场合RC文件还要更优，在查询检索方面，ORC则基本是更优的，性能差距大小取决于具体数据集和检索模式。如果Hive能集成ORC更新的版本，支持LZ4，并修复一些Bug，那应该就没有任何再使用RC的理由了 至于Parquet，可以考虑在需要支持深度嵌套的数据结构的应用场合中去使用
内外部表的区别、优缺点
l每天采集的ng日志和埋点日志,在存储的时候建议使用外部表，因为日志数据是采集程序实时采集进来的，一旦被误删，恢复起来非常麻烦。而且外部表方便数据的共享。 l抽取过来的业务数据，其实用外部表或者内部表问题都不大，就算被误删，恢复起来也是很快的，如果需要对数据内容和元数据进行紧凑的管理, 那还是建议使用内部表 l在做统计分析时候用到的中间表，结果表可以使用内部表，因为这些数据不需要共享，使用内部表更为合适。并且很多时候结果分区表我们只需要保留最近3天的数据，用外部表的时候删除分区时无法删除数据。
l每天采集的ng日志和埋点日志,在存储的时候建议使用外部表，因为日志数据是采集程序实时采集进来的，一旦被误删，恢复起来非常麻烦。而且外部表方便数据的共享。 l抽取过来的业务数据，其实用外部表或者内部表问题都不大，就算被误删，恢复起来也是很快的，如果需要对数据内容和元数据进行紧凑的管理, 那还是建议使用内部表 l在做统计分析时候用到的中间表，结果表可以使用内部表，因为这些数据不需要共享，使用内部表更为合适。并且很多时候结果分区表我们只需要保留最近3天的数据，用外部表的时候删除分区时无法删除数据。
dwd层有多少张表，每张表多少数据量
根据实际情况回答
根据实际情况回答
null值怎么打散，打散的伪代码或者sql
rand()函数
每天的数据量
根据实际情况回答
二次聚合对uv的话有没有什么问题
对pv没影响，对uv有影响，会重复
对pv没影响，对uv有影响，会重复
一天多少任务，多少表
根据实际情况回答
有一些任务需要回溯，比如历史时间需要重新执行，有遇到这种情况吗？
有重跑的情況
有重跑的情況
怎么保证每天能在固定的时间数据产出？
l任务优化 l集群扩容 l任务下线 l值班制度
l任务优化 l集群扩容 l任务下线 l值班制度
数据清洗做过没？主要做了哪些清洗
做过清洗 json解析 数据脱敏 空值给默认值 脏数据过滤 枚举值统一 1 男 2 女 0 男 1女 数据格式统一 yyyy/MM/dd yyyy-MM-dd
做过清洗 json解析 数据脱敏 空值给默认值 脏数据过滤 枚举值统一 1 男 2 女 0 男 1女 数据格式统一 yyyy/MM/dd yyyy-MM-dd
列式存储是什么？行数比较大的情况，比如说上亿，那么列式存储是怎么做的？列式存储是为了解决什么问题？
列存储不同于传统的关系型数据库，其数据在表中是按列存储的。
列方式所带来的重要好处之一就是，由于查询中的选择规则是通过列来定义的，因此整个数据库是自动索引化的。
按列存储每个字段的数据聚集存储，在查询只需要少数几个字段的时候，能大大减少读取的数据量，一个字段的数据聚集存储，那就更容易为这种聚集存储设计更好的压缩/解压算法。
列式数据库在分析需求（获取特点——每次查询几个维度，通常是）时候，不仅搜索时间效率占优势，其空间效率也是很明显的。
特别是针对动辄按T计算的数据量来说，在分布式环境中能进行压缩处理能节省宝贵的内部带宽，从而提高整个计算任务性能。
如果一张表的某个字段作为join的字段，但是这个字段有倾斜的非常厉害，比如性别这个字段，有男1000万个，女5万，这时候数据倾斜如何解决？
分两阶段进行聚合
分两阶段进行聚合
什么技术进行存储
orcFile+snappy压缩
orcFile+snappy压缩
数据存在hdfs上会有压缩吗？有什么优缺点？
会有压缩 ，
优点： 减少存储磁盘空间，降低单节点的磁盘IO。 减少网络传输带宽 。
缺点：需要花费额外的时间/CPU做压缩和解压缩计算。
常用压缩格式推荐使用：Snappy格式
会有压缩 ，
优点： 减少存储磁盘空间，降低单节点的磁盘IO。 减少网络传输带宽 。
缺点：需要花费额外的时间/CPU做压缩和解压缩计算。
常用压缩格式推荐使用：Snappy格式
维度建模和范式建模的区别；
范式建模常见于业务库 维度建模一般用于数仓建模，以空间换时间
维度退化具体的内容
把维表中的部分属性退化到事实表中
把维表中的部分属性退化到事实表中
数据仓库数据源都有哪些
爬虫数据 业务库数据 埋点日志
判断数仓搭建的好坏，怎么评价
数仓搭建的好坏，个人认为应该从以下几个方面思考：
1、数仓应用范围-即价值体现
2、数仓内部建设-即能力成熟度
首先价值体现主要围绕着“提效降本”，首先数仓建设的最终目的就是为了服务于业务，那么有没有为业务赋能这是一方面考虑；同时数仓建设也是服务于用户，即用户满意度也是可以用来评判数仓建设好坏的一项指标。
其次数仓内部能力成熟度，也就是主要围绕着规范度、及时性、稳定性、性能和成本、业务覆盖度、数据质量、复用扩展性这几个方面来衡量。
可以参考下面这篇文章：
https://mp.weixin.qq.com/s?__biz=MzU4MDkzMDE4Nw==&mid=2247489491&idx=1&sn=e2888bd70bdcbce3e0b4e4df2e2b965b&chksm=fd4e0837ca3981210a23d616d191e21a1cc16c0e6af9bb58ef95d236899f7dda5b77ce8a5c43&token=456993617&lang=zh_CN#rd
数仓分层的每层要注意什么
该问题需要结合面试者实际情况来回答：
1、首先要先回答你所参与的数仓建设是分成了几层？比如ods-->dwd-->dw--->dws-->ads。
2、然后说明一下每一层的作用
3、在讲述每一层的时候其实是有共性的，比如围绕着规范性、依赖性（即每层的依赖特点）、每一层的数据存储策略、数据安全策略等。
4、然后讲述一下每一层的差异点：比如ods贴源层在数据同步过程中的同步方式、同步范围；dwd层是明细宽表，还是要每个明细表，是使用何种加工方式（拉链、增量、全量、追加）
该问题需要结合面试者实际情况来回答：
1、首先要先回答你所参与的数仓建设是分成了几层？比如ods-->dwd-->dw--->dws-->ads。
2、然后说明一下每一层的作用
3、在讲述每一层的时候其实是有共性的，比如围绕着规范性、依赖性（即每层的依赖特点）、每一层的数据存储策略、数据安全策略等。
4、然后讲述一下每一层的差异点：比如ods贴源层在数据同步过程中的同步方式、同步范围；dwd层是明细宽表，还是要每个明细表，是使用何种加工方式（拉链、增量、全量、追加）
有一个订单表记录，根据你的数仓结构，说说怎么求出用户最近7天的最后一次下单记录？
订单数据是属于交易的核心数据，通常分析场景以及使用频率比较高。该问题主要是要考量你们对表设计模式的思考，这里分以下几种情况分析(注意：这里理解的最近7天指的是当前时刻往前推7天，这块的理解要反复和面试官check)：
1、如果每天的订单数据非常多，那么可以设计成按照订单创建时间作为分区字段，即每个分区保留每天的订单数据情况，但是这里需要考虑到如果历史订单属性发生了变化，那么对应分区的数据就要更新掉。(有点类似da+di的组合，或者做成拉链表)。基于这种情况，可以使用row_number来获取用户最近一次下单记录
select
user_id,
order_info
from
(
select
user_id,
row_number() over(partition by user_id order by create_time desc) as rank,
order_info
from order_table
where 分区字段>=近7天（如果是拉链表则需要注意开链和闭链的条件）
)res
where rank=1
2、第一种模式虽然设计简单，但是对于历史订单发生变化的处理手段就要变的复杂了。那么这里就可以结合实际业务情况拉长分区范围，比如按照月分区来存储
select
user_id,
order_info
from
(
select
user_id,
row_number() over(partition by user_id order by create_time desc) as rank,
order_info
from order_table
where 月分区字段=当月 and create_time>=date_sub(current_date(),7)
)res
where rank=1；
3、第二种模式虽然解决了历史订单发生变化的情况，但如果每天的订单量非常大，那么按月分区所消耗的算力也会递增，因此还有一种冷热分离的模式，即订单数据可能会按照冷热情况分别存储，比如近一周或者近三天的订单数据存储到热表，冷订单数据就会被归档起来。这种方式和前面的取数逻辑是一样的
4、以上三种都是基于明细表来查询的，还有一种会基于订单宽表向上做出一张用户最近活跃表，该表存储用户最近一次下单行为，那么可以直接从该表里取
select
user_id,
order_info
from user_active_info
where order_create_time>=date_sub(current_date(),7) and user_id='xxx'
订单数据是属于交易的核心数据，通常分析场景以及使用频率比较高。该问题主要是要考量你们对表设计模式的思考，这里分以下几种情况分析(注意：这里理解的最近7天指的是当前时刻往前推7天，这块的理解要反复和面试官check)：
1、如果每天的订单数据非常多，那么可以设计成按照订单创建时间作为分区字段，即每个分区保留每天的订单数据情况，但是这里需要考虑到如果历史订单属性发生了变化，那么对应分区的数据就要更新掉。(有点类似da+di的组合，或者做成拉链表)。基于这种情况，可以使用row_number来获取用户最近一次下单记录
select
user_id,
order_info
from
(
select
user_id,
row_number() over(partition by user_id order by create_time desc) as rank,
order_info
from order_table
where 分区字段>=近7天（如果是拉链表则需要注意开链和闭链的条件）
)res
where rank=1
2、第一种模式虽然设计简单，但是对于历史订单发生变化的处理手段就要变的复杂了。那么这里就可以结合实际业务情况拉长分区范围，比如按照月分区来存储
select
user_id,
order_info
from
(
select
user_id,
row_number() over(partition by user_id order by create_time desc) as rank,
order_info
from order_table
where 月分区字段=当月 and create_time>=date_sub(current_date(),7)
)res
where rank=1；
3、第二种模式虽然解决了历史订单发生变化的情况，但如果每天的订单量非常大，那么按月分区所消耗的算力也会递增，因此还有一种冷热分离的模式，即订单数据可能会按照冷热情况分别存储，比如近一周或者近三天的订单数据存储到热表，冷订单数据就会被归档起来。这种方式和前面的取数逻辑是一样的
4、以上三种都是基于明细表来查询的，还有一种会基于订单宽表向上做出一张用户最近活跃表，该表存储用户最近一次下单行为，那么可以直接从该表里取
select
user_id,
order_info
from user_active_info
where order_create_time>=date_sub(current_date(),7) and user_id='xxx'
如果让你设计实时数仓你会如何设计，为什么？
答案完善中，请耐心等待
答案完善中，请耐心等待
指标如何定义？
答案完善中，请耐心等待
答案完善中，请耐心等待
你的项目中数据的生命周期是怎样的？
该题目可以从存储策略和数据对业务影响度两个方向来回答。
数据的生命周期按照其所属层次作用、分析范围、重要性来考虑，不同的业务场景对其数据生命周期是不一样的，比如像银行业务，数据是需要全量存储的。像日志类的数据，其分析范围普遍是1~3年，那么3年之前的日志就可以删除的。
从存储策略来看：
如果是核心重要数据，一般是全量保留的；如果是非核心重要的数据，一般是保留3~5年（当然不同的业务对应的该周期也是不一样的）；如果是非核心非重要的数据，一般控制在1~2周即可。
像ods贴源层，根据同步方式不同，其存储策略也不同，如果是全量同步，那么就只会保留当天同步的数据，如果是追加同步，那么可能会保留3~7天
像dwd层的数据，普遍是采取快照保留7天（注意这里指的是快照数据）
像dw层的数据，一般是采取保留快照7天，或者不采用快照
像ads层的数据，一般是保留快照3天，或者不采用快照
该题目可以从存储策略和数据对业务影响度两个方向来回答。
数据的生命周期按照其所属层次作用、分析范围、重要性来考虑，不同的业务场景对其数据生命周期是不一样的，比如像银行业务，数据是需要全量存储的。像日志类的数据，其分析范围普遍是1~3年，那么3年之前的日志就可以删除的。
从存储策略来看：
如果是核心重要数据，一般是全量保留的；如果是非核心重要的数据，一般是保留3~5年（当然不同的业务对应的该周期也是不一样的）；如果是非核心非重要的数据，一般控制在1~2周即可。
像ods贴源层，根据同步方式不同，其存储策略也不同，如果是全量同步，那么就只会保留当天同步的数据，如果是追加同步，那么可能会保留3~7天
像dwd层的数据，普遍是采取快照保留7天（注意这里指的是快照数据）
像dw层的数据，一般是采取保留快照7天，或者不采用快照
像ads层的数据，一般是保留快照3天，或者不采用快照
元数据管理相关问题，集群存储不够了，需要清理不需要的任务和数据该怎么做？
答案完善中，请耐心等待
答案完善中，请耐心等待
数据血缘你们怎么做的
答案完善中，请耐心等待
假设上游业务系统说业务数据出错了，你会怎么办？在生产中有实际出现吗？没有，那你有思考过怎么办吗？
答案完善中，请耐心等待
假设数据仓库采集过程出错或者数仓计算过程出错，你怎么处理？在设计之初会做什么考虑？
答案完善中，请耐心等待
答案完善中，请耐心等待
实时数仓技术选型及保证exactly-once
答案完善中，请耐心等待
答案完善中，请耐心等待
sqoop怎么解决数据变动的问题
答案完善中，请耐心等待
答案完善中，请耐心等待
你们ads层怎么划分的
答案完善中，请耐心等待
数据如何为业务赋能
答案完善中，请耐心等待
答案完善中，请耐心等待
主题的划分原则
答案完善中，请耐心等待
答案完善中，请耐心等待
7日的留存率怎么求？
留存率一般是指流量域下面用户活跃主题的一个关键指标，和dau，mau一样，能够直接体现用户健康情况。 留存率一般分为3种情况，新用户留存，老用户留存，活跃用户留存。 7日留存率的计算，如需要统计5月2号的活跃用户7日留存率，只需要把5月2号的当天活跃数据(t1) left join 5月9号的当天活跃数据(t2)，用主键关联，然后计算cout(distinct t1.id) 活跃人数,count(distinct t2.id) 留存人数
留存率一般是指流量域下面用户活跃主题的一个关键指标，和dau，mau一样，能够直接体现用户健康情况。 留存率一般分为3种情况，新用户留存，老用户留存，活跃用户留存。 7日留存率的计算，如需要统计5月2号的活跃用户7日留存率，只需要把5月2号的当天活跃数据(t1) left join 5月9号的当天活跃数据(t2)，用主键关联，然后计算cout(distinct t1.id) 活跃人数,count(distinct t2.id) 留存人数
路径分析怎么做？
答案完善中，请耐心等待
答案完善中，请耐心等待
用phenix和es作为hbase二级索引的区别，最新的hbase已经支持二级索引了，你清楚吗？
答案完善中，请耐心等待
答案完善中，请耐心等待
怎么识别抖音中的大学生用户？用什么数据识别
答案完善中，请耐心等待
答案完善中，请耐心等待
说一下日常工作中负责的一个主题建模过程
答案完善中，请耐心等待
答案完善中，请耐心等待
你认为你的数据仓库还有哪些优化的余地？
答案完善中，请耐心等待
答案完善中，请耐心等待
模型的选取？
答案完善中，请耐心等待
答案完善中，请耐心等待
0-1建立数据仓库的一般流程，你的思路是什么
答案完善中，请耐心等待
答案完善中，请耐心等待
你们的指标都是怎么分的？
答案完善中，请耐心等待
答案完善中，请耐心等待
你们使用宽表会有什么问题吗
什么是宽表呢，字面意思指的是字段比较多，看起来表比较宽，所以叫宽表 宽表是怎么形成的呢？ 主要是事实表的关联及一些必要的维度退化
优点: 减少join操作，下游可以提高查询效率及减少学习成本
缺点: 过分的做宽表，会造成字段冗余，存储成本提升，查询效率下降 在业务频繁迭代的时候，宽表模型也要跟着不停迭代，影响面比较广，健壮性下降，此为模型优化的一个关键指标
什么是宽表呢，字面意思指的是字段比较多，看起来表比较宽，所以叫宽表 宽表是怎么形成的呢？ 主要是事实表的关联及一些必要的维度退化
优点: 减少join操作，下游可以提高查询效率及减少学习成本
缺点: 过分的做宽表，会造成字段冗余，存储成本提升，查询效率下降 在业务频繁迭代的时候，宽表模型也要跟着不停迭代，影响面比较广，健壮性下降，此为模型优化的一个关键指标
你们分层和阿里有点不一样，你们是怎么考虑的，你觉得阿里为什么那样分层
答案完善中，请耐心等待
答案完善中，请耐心等待
这个项目你觉得哪里好
答案完善中，请耐心等待
答案完善中，请耐心等待
你们数据域怎么划分的
答案完善中，请耐心等待
答案完善中，请耐心等待
。。。
数据结构-13
Flink
flink实时计算时落磁盘吗？
日活DAU的统计需要注意什么？
Flink调优
Flink的容错是怎么做的
定期checkpoint存储oprator state及keyedstate到stateBackend
定期checkpoint存储oprator state及keyedstate到stateBackend
Parque格式的好处？
什么时候读的快什么时候读的慢？
什么时候读的快什么时候读的慢？
Flink中checkpoint为什么状态有保存在内存中这样的机制？
为什么要开启checkpoint？
为什么要开启checkpoint？
Flink保证exactly one的原理？
Flink的时间形式和窗口形式有几种？
有什么区别，你用在什么场景下？
有什么区别，你用在什么场景下？
Flink的背压底层原理
Flink的watermark机制说下，以及怎么解决数据乱序的问题？
Flink on yarn执行流程
说一说spark和Flink的区别
Flink双流join
Flink提交任务方式
slot资源分配规划
Flink消费kafka发生partition数变更，Flink底层是不是reblance
checkpoint的原理
checkpoint barrier对齐原理，非对齐checkpoint原理
checkpoint失败的场景
Flink两阶段提交原理
onTime同state并发操作的安全问题
Flink kafkaConsumer源码实现
看过哪些Flink源码
Flink savepoint和checkpoint？
Flink 算子有哪些？都是干什么的？适用的场景？
Flink map和flatmap的比较
Flink两阶段提交原理
如果多个barrier对齐时，有一两个一直没到该怎么处理？什么情况下不需要等待对齐？
窗口和wm的关系
窗口的状态数据什么时候清楚
Flink有哪些窗口，介绍一下区别？
会话窗口关闭是什么控制的？
会话窗口关闭是什么控制的？
Flink的提交方式？
Flink的编程模型
Flink的姿态有哪些？
Flink的join源码
checkpoint源码和算法
Flink on yarn之后yarn会发生什么变化，源码里面的细节
Flink中状态相关的源码，比如修改状态大小，取出状态的值进行修改，再放回去，等其他状态的相关操作等？
Flink为算子提供状态的源码
为什么要升级为Flink
为什么Flink可以处理乱序？
给了个关注和取消的场景，问如何实现最终一致性问题
给了个关注和取消的场景，问如何实现最终一致性问题
说说sparkstreaming和Flink的区别？
作业挂掉了，恢复上一个Checkpoint，用什么命令
bin/flink run -s hdfs://node1:8020/flink-checkpoint/savepoint/savepoint-0e921a-1cac737bff7a --class com.CheckpointDemo01 /root/ckp.jar
bin/flink run -s hdfs://node1:8020/flink-checkpoint/savepoint/savepoint-0e921a-1cac737bff7a --class com.CheckpointDemo01 /root/ckp.jar
...
flume
什么是flume
flume运行机制
flume采集数据到kafka中丢数据怎么办
flume怎么进行监控
flume的三层架构，collector，agent。storage
flume断点续传多久保留一次offset
整个flume有使用高可用吗？怎么配置高可用
flume会不会丢数据？
hadoop
hdfs写流程
HDFS读流程
HDFS的体系结构
一个DataNode宕机一个流程怎么恢复
Hadoop的NameNode宕机怎么解决
NameNode对元数据的管理
元数据的checkpoint
yarn资源调度流程
Hadoop中combiner和partition的作用
用MapReduce怎么处理数据倾斜问题
shuffle阶段怎么理解
MapReduce的map数量和reduce数量是由什么决定的，怎么配置
MapReduce优化经验
分别举例什么情况要使用combiner，什么情况不使用？
MapReduce运行流程解析
简单描述一下HDFS的系统架构，怎么保证数据安全
在处理客户端向HDFS中写数据的时候，如果某一台机器宕机了，会怎么处理
Hadoop优化有哪些方面
大量数据求topN（写MapReduce的实现思路）
列出正常工作的Hadoop集群中Hadoop都分别启动哪些进程以及他们的作用
Hadoop中的job和task之间的区别是什么
Hadoop高可用HA模式
简要描述下安装配置一个Hadoop集群的步骤
fsimage和edit的区别
yarn的三大调度策略
Hadoop的shell命令用的多吗？说出一些常用的
用MapReduce实现用户的PV的top 10
一个文件只有一行，但是这行有100G大小，MapReduce会不会切分，我们应该如何解决
HDFS的HA机制，一台NameNode挂了，joualnode，NameNode，edit
shuffle过程瓶颈在哪里，你会怎么解决
小文件和数据倾斜，怎么处理
空值key加随机数是一种数据倾斜解决方案，如果有单个key是热点值呢？又如果有多个key是热点值呢？用参数和代码分别怎么解决？
MapReduce中join操作的具体原理
数据倾斜的处理方式
一个SQL在MapReduce中经过哪些过程
HDFS中DataNode之间怎么保证备份数据的同步
2NN的作用？高可用中的standby NameNode的作用
怎么进行故障转移
Hadoop中的组件，各自的作用，secondNode的作用
yarn的源码和参数配置相关的源码
ElasticSearch
为什么要用es?
es中存储的数据是什么格式的？怎么查询？
HBase-22
hive跟hbase的区别是？
HiveSql默认情况下会转换成MapReduce进行计算，所以比较慢，只能做离线数据分析，不能做实时查询 HBase是NoSql数据库，是物理表，不是逻辑表，虽然数据是存储在hdfs，但是读写速度非常快，适合做大数据量的即时查询
hbase写流程
1/ 客户端要连接zookeeper, 从zk的/hbase节点找到hbase:meta表所在的regionserver（host:port）; 2/ regionserver扫描hbase:meta中的每个region的起始行健，对比r000001这条数据在那个region的范围内； 3/ 从对应的 info:server key中存储了region是有哪个regionserver(host:port)在负责的； 4/ 客户端直接请求对应的regionserver； 5/ regionserver接收到客户端发来的请求之后，就会将数据写入到region中
Hbase调优
高可用 预分区 优化rowkey设计 内存优化 压缩 column数优化 开启布隆过滤器
高可用 预分区 优化rowkey设计 内存优化 压缩 column数优化 开启布隆过滤器
hbase的rowkey怎么创建好？列族怎么创建比较好？
一个列族在数据底层是一个文件，所以将经常一起查询的列放到一个列族中，列族尽量少，减少文件的寻址时间。
一个列族在数据底层是一个文件，所以将经常一起查询的列放到一个列族中，列族尽量少，减少文件的寻址时间。
Hbase中的region server发生故障后的处理方法(zk-->WAL)
Hbase检测宕机是通过 Zookeeper实现的，正常情况下 Regionserver会周期性向 Zookeeper发送心跳，一旦发生宕机，心跳就会停止，超过一定时间( Sessi ontimeout) Zookeeper就会认为 Regionserver宕机离线，并将该消息通知给 Master0一台 Regionserver只有一个Hog文件，然后，将og按照 Region进行分组，切分到每个 regionserver中，因此在回放之前首先需要将og按照 Region进行分组，每个 Region的日志数据放在一起，方便后面按照 Region进行回放。这个分组的过程就称为HLog切分。然后再对 region重新分配，并对其中的Hog进行回放将数据写入 memstore刷写到磁盘，完成最终数据恢复。
Hbase检测宕机是通过 Zookeeper实现的，正常情况下 Regionserver会周期性向 Zookeeper发送心跳，一旦发生宕机，心跳就会停止，超过一定时间( Sessi ontimeout) Zookeeper就会认为 Regionserver宕机离线，并将该消息通知给 Master0一台 Regionserver只有一个Hog文件，然后，将og按照 Region进行分组，切分到每个 regionserver中，因此在回放之前首先需要将og按照 Region进行分组，每个 Region的日志数据放在一起，方便后面按照 Region进行回放。这个分组的过程就称为HLog切分。然后再对 region重新分配，并对其中的Hog进行回放将数据写入 memstore刷写到磁盘，完成最终数据恢复。
HBase宕机如何处理
答：宕机分为HMaster宕机和HRegisoner宕机，如果是HRegisoner宕机，HMaster会将其所管理的region重新分布到其他活动的RegionServer上，由于数据和日志都持久在HDFS中，该操作不会导致数据丢失。所以数据的一致性和安全性是有保障的。 如果是HMaster宕机，HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行。即ZooKeeper会保证总会有一个HMaster在对外提供服务。
答：宕机分为HMaster宕机和HRegisoner宕机，如果是HRegisoner宕机，HMaster会将其所管理的region重新分布到其他活动的RegionServer上，由于数据和日志都持久在HDFS中，该操作不会导致数据丢失。所以数据的一致性和安全性是有保障的。 如果是HMaster宕机，HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行。即ZooKeeper会保证总会有一个HMaster在对外提供服务。
hive跟hbase的区别是？
HiveSql默认情况下会转换成MapReduce进行计算，所以比较慢，只能做离线数据分析，不能做实时查询 HBase是NoSql数据库，是物理表，不是逻辑表，虽然数据是存储在hdfs，但是读写速度非常快，适合做大数据量的即时查询
hbase写流程
1/ 客户端要连接zookeeper, 从zk的/hbase节点找到hbase:meta表所在的regionserver（host:port）; 2/ regionserver扫描hbase:meta中的每个region的起始行健，对比r000001这条数据在那个region的范围内； 3/ 从对应的 info:server key中存储了region是有哪个regionserver(host:port)在负责的； 4/ 客户端直接请求对应的regionserver； 5/ regionserver接收到客户端发来的请求之后，就会将数据写入到region中
hbase读流程
1/ 首先Client连接zookeeper, 找到hbase:meta表所在的regionserver; 2/ 请求对应的regionserver，扫描hbase:meta表，根据namespace、表名和rowkey在meta表中找到r00001所在的region是由那个regionserver负责的； 3/找到这个region对应的regionserver 4/ regionserver收到了请求之后，扫描对应的region返回数据到Client (先从MemStore找数据，如果没有，再到BlockCache里面读；BlockCache还没有，再到StoreFile上读(为了读取的效率)； 如果是从StoreFile里面读取的数据，不是直接返回给客户端，而是先写入BlockCache，再返回给客户端。)
1/ 首先Client连接zookeeper, 找到hbase:meta表所在的regionserver; 2/ 请求对应的regionserver，扫描hbase:meta表，根据namespace、表名和rowkey在meta表中找到r00001所在的region是由那个regionserver负责的； 3/找到这个region对应的regionserver 4/ regionserver收到了请求之后，扫描对应的region返回数据到Client (先从MemStore找数据，如果没有，再到BlockCache里面读；BlockCache还没有，再到StoreFile上读(为了读取的效率)； 如果是从StoreFile里面读取的数据，不是直接返回给客户端，而是先写入BlockCache，再返回给客户端。)
hbase数据flush过程
1）当MemStore数据达到阈值（默认是128M，老版本是64M），将数据刷到硬盘，将内存中的数据删除，同时删除HLog中的历史数据； 2）并将数据存储到HDFS中； 3）在HLog中做标记点。
1）当MemStore数据达到阈值（默认是128M，老版本是64M），将数据刷到硬盘，将内存中的数据删除，同时删除HLog中的历史数据； 2）并将数据存储到HDFS中； 3）在HLog中做标记点。
数据合并过程
当数据块达到4块，hmaster将数据块加载到本地，进行合并 当合并的数据超过256M，进行拆分，将拆分后的region分配给不同的hregionserver管理 当hregionser宕机后，将hregionserver上的hlog拆分，然后分配给不同的hregionserver加载，修改.META. 注意：hlog会同步到hdfs
当数据块达到4块，hmaster将数据块加载到本地，进行合并 当合并的数据超过256M，进行拆分，将拆分后的region分配给不同的hregionserver管理 当hregionser宕机后，将hregionserver上的hlog拆分，然后分配给不同的hregionserver加载，修改.META. 注意：hlog会同步到hdfs
Hmaster和Hgionserver职责
Hmaster
1、管理用户对Table的增、删、改、查操作；
2、记录region在哪台Hregion server上
3、在Region Split后，负责新Region的分配；
4、新机器加入时，管理HRegion Server的负载均衡，调整Region分布
5、在HRegion Server宕机后，负责失效HRegion Server 上的Regions迁移。
Hgionserver HRegion Server主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBASE中最核心的模块。
HRegion Server管理了很多table的分区，也就是region。
Hmaster
1、管理用户对Table的增、删、改、查操作；
2、记录region在哪台Hregion server上
3、在Region Split后，负责新Region的分配；
4、新机器加入时，管理HRegion Server的负载均衡，调整Region分布
5、在HRegion Server宕机后，负责失效HRegion Server 上的Regions迁移。
Hgionserver HRegion Server主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBASE中最核心的模块。
HRegion Server管理了很多table的分区，也就是region。
HBase列族和region的关系？
HBase有多个RegionServer，每个RegionServer里有多个Region，一个Region中存放着若干行的行键以及所对应的数据，一个列族是一个文件夹，如果经常要搜索整个一条数据，列族越少越好，如果只有一部分的数据需要经常被搜索，那么将经常搜索的建立一个列族，其他不常搜索的建立列族检索较快。
HBase有多个RegionServer，每个RegionServer里有多个Region，一个Region中存放着若干行的行键以及所对应的数据，一个列族是一个文件夹，如果经常要搜索整个一条数据，列族越少越好，如果只有一部分的数据需要经常被搜索，那么将经常搜索的建立一个列族，其他不常搜索的建立列族检索较快。
请简述Hbase的物理模型是什么
答案完善中，请耐心等待
答案完善中，请耐心等待
Hive-73
Java-29
Kafka-57
Kylin-12
Kylin调优？
1、Cube调优 l剪枝优化(衍生维度，聚合组，强制维度，层级维度，联合维度) l并发粒度优化 lRowkeys优化(编码，按维度分片，调整维度顺序) l降低度量精度 l及时清理无用的segment Rowkey调优 lKylin rowkey的编码和压缩选择 l维度在rowkey中顺序的调整， l将过滤频率较高的列放置在过滤频率较低的列之前， l将基数高的列放置在基数低的列之前。
2、 l在查询中被用作过滤条件的维度有可能放在其他维度的前面。
3、充分利用过滤条件来缩小在HBase中扫描的范围， 从而提高查询的效率。
Kylin的rowkey如何设计？
Kylin rowkey的编码和压缩选择 维度在rowkey中顺序的调整， 将过滤频率较高的列放置在过滤频率较低的列之前， 将基数高的列放置在基数低的列之前。 在查询中被用作过滤条件的维度有可能放在其他维度的前面。 充分利用过滤条件来缩小在HBase中扫描的范围， 从而提高查询的效率。
为什么kylin的维度不建议过多
Cube 的最大物理维度数量 (不包括衍生维度) 是 63，但是不推荐使用大于 30 个维度的 Cube，会引起维度灾难。
Kylin的构建过程是怎么样的
选择model 选择维度 选择指标 cube设计(包括维度和rowkeys) 构建cube(mr程序，hbase存储元数据信息及计算好的数据信息)
Kylin调优？
1、Cube调优 l剪枝优化(衍生维度，聚合组，强制维度，层级维度，联合维度) l并发粒度优化 lRowkeys优化(编码，按维度分片，调整维度顺序) l降低度量精度 l及时清理无用的segment Rowkey调优 lKylin rowkey的编码和压缩选择 l维度在rowkey中顺序的调整， l将过滤频率较高的列放置在过滤频率较低的列之前， l将基数高的列放置在基数低的列之前。
2、 l在查询中被用作过滤条件的维度有可能放在其他维度的前面。
3、充分利用过滤条件来缩小在HBase中扫描的范围， 从而提高查询的效率。
Kylin的优点和缺点？
1、优点:预计算，界面可视化
2、缺点：依赖较多，属于重量级方案，运维成本很高 不适合做即席查询 预计算量大，非常消耗资源
1、优点:预计算，界面可视化
2、缺点：依赖较多，属于重量级方案，运维成本很高 不适合做即席查询 预计算量大，非常消耗资源
Kylin的rowkey如何设计？
Kylin rowkey的编码和压缩选择 维度在rowkey中顺序的调整， 将过滤频率较高的列放置在过滤频率较低的列之前， 将基数高的列放置在基数低的列之前。 在查询中被用作过滤条件的维度有可能放在其他维度的前面。 充分利用过滤条件来缩小在HBase中扫描的范围， 从而提高查询的效率。
一张hive宽表有5个维度，kylin构建cube的时候我选了4个维度，我select *的时候会有几个维度字段？
只能查询出4个字段
只能查询出4个字段
其他olap工具有了解过吗？
了解过，kylin，druid、clickhouse、presto
了解过，kylin，druid、clickhouse、presto
kylin熟吗？kylin你一般怎么调优
Cube调优 l剪枝优化(衍生维度，聚合组，强制维度，层级维度，联合维度) l并发粒度优化 lRowkeys优化(编码，按维度分片，调整维度顺序) l降低度量精度 l及时清理无用的segment Rowkey调优 lKylin rowkey的编码和压缩选择 l维度在rowkey中顺序的调整， l将过滤频率较高的列放置在过滤频率较低的列之前， l将基数高的列放置在基数低的列之前。 l在查询中被用作过滤条件的维度有可能放在其他维度的前面。 充分利用过滤条件来缩小在HBase中扫描的范围， 从而提高查询的效率。
Cube调优 l剪枝优化(衍生维度，聚合组，强制维度，层级维度，联合维度) l并发粒度优化 lRowkeys优化(编码，按维度分片，调整维度顺序) l降低度量精度 l及时清理无用的segment Rowkey调优 lKylin rowkey的编码和压缩选择 l维度在rowkey中顺序的调整， l将过滤频率较高的列放置在过滤频率较低的列之前， l将基数高的列放置在基数低的列之前。 l在查询中被用作过滤条件的维度有可能放在其他维度的前面。 充分利用过滤条件来缩小在HBase中扫描的范围， 从而提高查询的效率。
Kylin的cuboid,cube和segment的关系？
1、Cube是所有cubiod的组合，一个cube包含一个或者多个cuboid Cuboid在Kylin中特指在某一种维度组合下所计算的数据。
2、Cube Segment是指针对源数据中的某一片段，全量构建的cube只存在唯一的segment，该segment没有分割时间的概念，增量构建的cube，不同时间的数据分布在不同的segment中
1、Cube是所有cubiod的组合，一个cube包含一个或者多个cuboid Cuboid在Kylin中特指在某一种维度组合下所计算的数据。
2、Cube Segment是指针对源数据中的某一片段，全量构建的cube只存在唯一的segment，该segment没有分割时间的概念，增量构建的cube，不同时间的数据分布在不同的segment中
kylin的原理和优化。
原理：预计算 优化同上
原理：预计算 优化同上
为什么kylin的维度不建议过多
Cube 的最大物理维度数量 (不包括衍生维度) 是 63，但是不推荐使用大于 30 个维度的 Cube，会引起维度灾难。
Kylin的构建过程是怎么样的
选择model 选择维度 选择指标 cube设计(包括维度和rowkeys) 构建cube(mr程序，hbase存储元数据信息及计算好的数据信息)
Kylin维度优化有几种类型
衍生维度 聚合组 强制维度 层级维度 联合维度
衍生维度 聚合组 强制维度 层级维度 联合维度
Kylin的构建算法
1、快速构建算法（inmem）也被称作“逐段”(By Segment) 或“逐块”(By Split) 算法，从1.5.x开始引入该算法，利用Mapper端计算先完成大部分聚合，再将聚合后的结果交给Reducer，从而降低对网络瓶颈的压力。
2、该算法的主要思想是，对Mapper所分配的数据块，将它计算成一个完整的小Cube 段（包含所有Cuboid）；每个Mapper将计算完的Cube段输出给Reducer做合并，生成大Cube，也就是最终结果 与旧算法相比，快速算法主要有两点不同： Mapper会利用内存做预聚合，算出所有组合；Mapper输出的每个Key都是不同的，这样会减少输出到Hadoop MapReduce的数据量，Combiner也不再需要； 一轮MapReduce便会完成所有层次的计算，减少Hadoop任务的调配。
1、快速构建算法（inmem）也被称作“逐段”(By Segment) 或“逐块”(By Split) 算法，从1.5.x开始引入该算法，利用Mapper端计算先完成大部分聚合，再将聚合后的结果交给Reducer，从而降低对网络瓶颈的压力。
2、该算法的主要思想是，对Mapper所分配的数据块，将它计算成一个完整的小Cube 段（包含所有Cuboid）；每个Mapper将计算完的Cube段输出给Reducer做合并，生成大Cube，也就是最终结果 与旧算法相比，快速算法主要有两点不同： Mapper会利用内存做预聚合，算出所有组合；Mapper输出的每个Key都是不同的，这样会减少输出到Hadoop MapReduce的数据量，Combiner也不再需要； 一轮MapReduce便会完成所有层次的计算，减少Hadoop任务的调配。
Linux-11
Mysql-4
收藏
0 条评论
下一页
