1、linux的常用的命令：
（1）磁盘管理：
pwd：显示工作目录的绝对路径名称
ls：显示指定工作目录下的内容（列出目前工作目录所含之文件及子目录)
mkdir：用于创建目录
rmdir：删除空的目录
cd：用于切换当前工作目录
（2）文件管理：
touch：用于修改文件或者目录的时间属性，包括存取时间和更改时间。若文件不存在，系统会建立一个新的文件
cp：用于复制文件或目录
rm：删除一个文件或者目录
mv：为文件或目录改名、或将文件或目录移入其它位置
cat：连接文件并打印到标准输出设备上
more：类似 cat ，不过会以一页一页的形式显示
less：与 more 类似，但使用 less 可以随意浏览文件，而 more 仅能向前移动，却不能向后移动，而且 less 在查看之前不会加载整个文件
chmod：控制用户对文件的权限的命令
chown：用于设置文件所有者和文件关联组的命令
chgrp：用于变更文件或目录的所属群组。（与 chown 命令不同，chgrp 允许普通用户改变文件所属的组，只要该用户是该组的一员）
（3）系统管理：
useradd：用来建立用户账号。账号建好之后，再用 passwd 设定账号的密码。而可用 userdel 删除账号。使用 useradd 指令所建立的账号，实际上是保存在 /etc/passwd 文本文件中
passwd：用来更改使用者的密码
su：用于变更为其他使用者的身份，除 root 外，需要键入该使用者的密码。（使用权限：所有使用者。）
sudo：以系统管理者的身份执行指令，也就是说，经由 sudo 所执行的指令就好像是 root 亲自执行。（使用权限：在 /etc/sudoers 中有出现的使用者。）
userdel：用于删除用户账号
who：用于显示系统中有哪些使用者正在上面，显示的资料包含了使用者 ID、使用的终端机、从哪边连上来的、上线时间、呆滞时间、CPU 使用量、动作等等。（使用权限：所有使用者都可使用。）
（4）其他命令：
head：用于查看文件的开头部分的内容，有一个常用的参数 -n 用于显示行数，默认为 10，即显示 10 行的内容
tail：用于查看文件的内容，有一个常用的参数 -f 常用于查阅正在改变的日志文件
【详细内容可参考 菜鸟教程的 linux命令大全：https://www.runoob.com/linux/linux-command-manual.html】
2、MR、Hive、Spark的词频统计
（1）MR的词频统计：
（2）Hive的词频统计：
① 在服务器，编辑文本 words.txt：
② 进到hive进行建表：
③ 导数据：
④ 先查询数据是否导入成功，验证一下：
⑤ 编写wordCount：
⑥ 结果如下，则运行成功：
（3）Spark的词频统计 [scala编写]：
3、Hadoop是什么？
Apache Hadoop 为可靠的，可扩展的分布式计算开源框架，用于集群上存储数据和运行应用程序。它为任何类型的数据提供海量存储，巨大的处理能力以及处理几乎无限的并发任务或作业的能力。
包括这些模块：
Hadoop Common：支持其他Hadoop模块的常用工具。
Hadoop分布式文件系统（HDFS™）：一种分布式文件系统，可提供对应用程序数据的高吞吐量访问。
Hadoop YARN：作业调度和集群资源管理的框架。
Hadoop MapReduce：一种用于并行处理大型数据集的基于YARN的系统。
上述每个模块有自己独立的功能，而模块之间又有相互的关联。
广义上来说，HADOOP通常是指一个更广泛的概念——HADOOP生态圈
HDFS：分布式文件系统
MAPREDUCE：分布式运算程序开发框架
HIVE：基于大数据技术（文件系统 运算框架）的SQL数据仓库工具
HBASE：基于HADOOP的分布式海量数据库
ZOOKEEPER：分布式协调服务基础组件
Mahout：基于mapreduce/spark/flink等分布式运算框架的机器学习算法库
Oozie：工作流调度框架
Sqoop：数据导入导出工具
Flume：日志数据采集框架
4、Hadoop常用端口号：
dfs.namenode.http-address：50070
dfs.datanode.http-address：50075
SecondaryNameNode辅助名称节点端口号：50090
dfs.datanode.address：50010
fs.defaultFS：8020 或者 9000
yarn.resourcemanager.webapp.address：8088
历史服务器web访问端口：19888
5、ETL是什么？
ETL：是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。
ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据， ETL是BI（商业智能）项目重要的一个环节。
6、Hadoop配置文件以及简单的Hadoop集群搭建：
7、hadoop1.0 和 hadoop2.0的区别：
NameNodes可以通过集群的方式布署，增强了NameNodes的水平扩展能力和可用性；
从mapreduce角度来看：2.0相比于1.0 新增了YARN框架，Mapreduce的运行环境发生了变化。
8、Yarn的Job提交流程：
9、Yarn的默认调度器、调度器分类、以及他们之间的区别
Hadoop2.7.2默认的资源调度器是 容量调度器
FIFO 、Capacity Scheduler（容量调度器）和Fair Sceduler（公平调度器）。
区别：
FIFO调度器：先进先出，同一时间队列中只有一个任务在执行。
容量调度器：多队列；每个队列内部先进先出，同一时间队列中只有一个任务在执行。队列的并行度为队列的个数。
公平调度器：多队列；每个队列内部按照缺额大小分配资源启动任务，同一时间队列中有多个任务执行。队列的并行度大于等于队列的个数。
10、Hadoop宕机
11、HDFS读流程
12、HDFS写流程
13、FileInputFormat切片机制
14、什么是InputSplit？FileInputFormat源码解析(input.getSplits(job))
15、MapReduce的Shuffle过程
16、MapTask工作机制
17、ReduceTask工作机制
18、mapreduce shuffle过程的优化
19、Hadoop优化
20、Zookeeper是什么
21、Zookeeper选举机制
22、Flume是什么
flume是一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据。数据源可定制、可扩展，数据存储系统可定制、可扩展。
flume运行的核心是agent。它是一个完整的数据收集工具，含有三个核心组件，分别是source、channel、sink。通过这些组件，event可以从一个地方流向另一个地方。为了保证输送一定成功，在送到目的地之前，会先缓存数据，待数据真正到达目的地后，删除自己缓存的数据。
23、flume有哪些组件，flume的source、channel、sink具体是做什么的
（1） Agent
Agent是一个JVM进程，它以事件的形式将数据从源头送至目的，是Flume数据传输的基本单元。
Agent主要有3个部分组成，Source、Channel、Sink。
（2） Source
Source是负责接收数据到Flume Agent的组件。Source组件可以处理各种类型、各种格式的日志数据，包括avro、thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、legacy。
（3） Channel
Channel是位于Source和Sink之间的缓冲区。因此，Channel允许Source和Sink运作在不同的速率上。Channel是线程安全的，可以同时处理几个Source的写入操作和几个Sink的读取操作。
Flume自带两种Channel：Memory Channel和File Channel, Kafka Channel
Memory Channel是内存中的队列。Memory Channel在不需要关心数据丢失的情景下适用。如果需要关心数据丢失，那么Memory Channel就不应该使用，因为程序死亡、机器宕机或者重启都会导致数据丢失。
File Channel将所有事件写到磁盘。因此在程序关闭或机器宕机的情况下不会丢失数据。
Kafka Channel：减少了Flume的Sink阶段，提高了传输效率。
（4）Sink
Sink不断地轮询Channel中的事件且批量地移除它们，并将这些事件批量写入到存储或索引系统、或者被发送到另一个Flume Agent。
Sink是完全事务性的。在从Channel批量删除数据之前，每个Sink用Channel启动一个事务。批量事件一旦成功写出到存储系统或下一个Flume Agent，Sink就利用Channel提交事务。事务一旦被提交，该Channel从自己的内部缓冲区删除事件。
Sink组件目的地包括hdfs、logger、avro、thrift、ipc、file、null、HBase、solr、自定义。
（5）Event
传输单元，Flume数据传输的基本单元，以事件的形式将数据从源头送至目的地。
24、Flume的source
（1）Exec Source
Exec Source可通过tail -f命令去tail住一个文件，然后实时同步日志到sink。但存在的问题是，当agent进程挂掉重启后，会有重复消费的问题。可以通过增加UUID来解决，或通过改进ExecSource来解决。
（2）Spooling Directory Source
Spooling Directory Source可监听一个目录，同步目录中的新文件到sink,被同步完的文件可被立即删除或被打上标记。适合用于同步新文件，但不适合对实时追加日志的文件进行监听并同步。如果需要实时监听追加内容的文件，可对SpoolDirectorySource进行改进。
（3）Taildir Source
Taildir Source可实时监控一批文件，并记录每个文件最新消费位置，agent进程重启后不会有重复消费的问题。
使用时建议用1.8.0版本的flume，1.8.0版本中解决了Taildir Source一个可能会丢数据的bug。
25、Flume的take和put事务
Source到Channel是Put事务
Channel到Sink是Take事务
26、flume性能调优
（1）Source
增加Source个（使用Tair Dir Source时可增加filegroups个数）可以增大Soure的读取数据的能力。例如：当某一个目录产生的文件过多时需要将这个文件目录拆分成多个文件目录，同时配置好多个Source 以保证Soure有足够的能力获取到新产生的数据。
batchSize参数决定Source一次批量运输到Channel的event条数，适当调大这个参数可以提高Soure搬运Event到Channel时的性能。
（2）Channel
type 选择memory 时Channel的性能最好，但是如果flume进程意外挂掉可能会丢失数据。type选择file时Channel的容错性更好，但是性能上会比memory channel差。
使用file Channel时dataDirs配置多个不同盘下的目录可以提高性能。
（3）Sink
增加Sink的个数可以增加Sink消费event的能力。Sink也不是越多越好够用就行，过多的Sink会占用系统资源，造成系统资源不必要的浪费。
batchSize参数决定Sink一次批量从Channel读取的event条数，适当调大这个参数可以提高Sink从Channel搬出event的性能。
27、Kakfa分区数
28、kafka写入数据流程
（1）producer先从broker-list的节点中找到该partition的leader；
（2）然后producer将消息发送给作为leader的partition；
（3）leader收到消息后，将消息写入本地log；
（4）followers从leader中pull消息，实现replication的副本备份机制，同样写入本地log；
（5）replication写入本地log后向leader发送ack（确认）；
（6）leader收到所有的replication的ack之后，向producer发送ack；
（7）producer收到leader的ack，证明生产的数据已被kafka成功写入。
29、kafka读流程
30、Kafka消息数据积压，Kafka消费能力不足怎么处理？
31、什么情况下会重复消费kafka数据
32、如何保证不重复读kafka数据
（1）幂等操作，重复消费不会产生问题
（2）
对每个partitionID，产生一个uniqueID,.只有这个partition的数据被完全消费，才算成功，否则失败回滚。下次若重复执行，就skip
33、如何做到复读kafka数据
消费者要从头开始消费某个topic的全量数据，需要满足2个条件（spring-kafka）：
（1）使用一个全新的"group.id"（就是之前没有被任何消费者使用过）;
（2）指定"auto.offset.reset"参数的值为earliest；
34、Kafka丢不丢数据
35、kafka保证数据不丢失
producer 生产端：
ack的配置
acks = 0 生产者发送消息之后 不需要等待服务端的任何响应，它不管消息有没有发送成功，如果发送过程中遇到了异常，导致broker端没有收到消息，消息也就丢失了。
acks = 1(默认值)
生产者发送消息之后，只要分区的leader副本成功写入消息，那么它就会收到来自服务端的成功响应。
acks = all (或-1)
生产者在发送消息之后，需要等待ISR中所有的副本都成功写入消息之后才能够收到来自服务端的成功响应，在配置环境相同的情况下此种配置可以达到最强的可靠性。
retries的配置策略
如遇到在leader的选举、网络的抖动等这些异常时，如果配置的retries大于0的，就可以进行重试操作，等到leader选举完成后、网络稳定后，这些异常就会消息，错误也就可以恢复，数据再次重发时就会正常发送到broker端。同时可以增大retries(重试)之间的时间间隔，以确保在重试时可恢复性错误都已恢复。
consumer消费端：
我们在处理消息的时候要添加一个unique key
假如pull 一个batch 100条的消息，在处理到第80条的时候，由于网络延迟、或者crash的原因没有来得及提交offset，被处理的80条数据都添加了unique key, 可以存到到DB中或者redis中(推荐，因为这样更快),当consumer端会再次poll消费数据时，因为没有提交offset，所以会从0开始消费数据，如果对之前已经消息过的数据没有做unique key的处理，那么会造成重复消息之前的80条数据，但是如果把每条对应的消息都添加了unique key，那就只需要对被处理的消息进行判断，有没有unique key 就可以做到不重复消费数据的问题，这样也同时保证了幂等性。
36、Kafka和其他mq的区别？
作为消息队列来说，企业中选择mq的还是多数，因为像Rabbit，Rocket等mq中间件都属于很成熟的产品，性能一般但可靠性较强，而kafka原本设计的初衷是日志统计分析，现在基于大数据的背景下也可以做运营数据的分析统计，redis的主要场景是内存数据库，作为消息队列来说可靠性太差，而且速度太依赖网络IO，在服务器本机上的速度较快，且容易出现数据堆积的问题，在比较轻量的场合下能够适用。
消息队列有什么优缺点
优点：解耦、异步、削峰。
缺点：系统可用性降低，系统复杂度提高，一致性问题
其他MQ相比较，Kafka有一些优缺点，主要如下，
优点：
可扩展。Kafka集群可以透明的扩展，增加新的服务器进集群。
高性能。Kafka性能远超过传统的ActiveMQ、RabbitMQ等，Kafka支持Batch操作。
容错性。Kafka每个Partition数据会复制到几台服务器，当某个Broker失效时，Zookeeper将通知生产者和消费者从而使用其他的Broker。
缺点：
重复消息。Kafka保证每条消息至少送达一次，虽然几率很小，但一条消息可能被送达多次。
消息乱序。Kafka某一个固定的Partition内部的消息是保证有序的，如果一个Topic有多个Partition，partition之间的消息送达不保证有序。
复杂性。Kafka需要Zookeeper的支持，Topic一般需要人工创建，部署和维护比一般MQ成本更高。
Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？
37、kafka的偏移量offset保存在哪里？
kafka消费者在会保存其消费的进度，也就是offset，存储的位置根据选用的kafka api不同而不同。
38、如何提高kafka消费性能？
39、kafka为什么那么快
总结：
Kafka速度的秘诀在于，它把所有的消息都变成一个批量的文件，并且进行合理的批量压缩，减少网络IO损耗，通过mmap提高I/O速度，写入数据的时候由于单个Partion是末尾添加所以速度最优；读取数据的时候配合sendfile直接暴力输出。
40、kafka能不使用zookeeper吗？原因是什么
41、为什么使用kafka
(1) 解耦
在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
(2) 冗余
有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
(3) 扩展性
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
(4) 灵活性 & 峰值处理能力
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
(5) 顺序保证
(6)缓冲
(7)容易扩展
42、Kafka中broker是做什么的
43、Hive 基本概念
Hive是基于Hadoop的一个 数据仓库工具，可以将结构化的数据文件映射成一张表，并提供类SQL查询功能；
Hive是构建在Hadoop 之上的数据仓库；
简单来说，Hive就是在Hadoop上架了一层SQL接口，可以将SQL翻译成MapReduce去Hadoop上执行，这样就使得数据开发和分析人员很方便的使用SQL来完成海量数据的统计和分析，而不必使用编程语言开发MapReduce那么麻烦。
44、Hive和数据库比较
45、Hive文件存储格式
在实际的项目开发当中，hive表的数据存储格式一般选择：orc或parquet。压缩方式一般选择snappy，lzo。
46、Hive内部表和外部表
47、Hive4个By区别
48、HIve窗口函数
49、sql语句中count(*)，count(1)，count(id)区别详解
50、Hive行转列
CONCAT(string A/col, string B/col…)：返回输入字符串连接后的结果，支持任意个输入字符串;
CONCAT_WS(separator, str1, str2,…)：它是一个特殊形式的 CONCAT()。第一个参数剩余参数间的分隔符。分隔符可以是与剩余参数一样的字符串。如果分隔符是 NULL，返回值也将为 NULL。这个函数会跳过分隔符参数后的任何 NULL 和空字符串。分隔符将被加到被连接的字符串之间;
COLLECT_SET(col)：函数只接受基本数据类型，它的主要作用是将某字段的值进行去重汇总，产生array类型字段。
51、Hive列转行
EXPLODE(col)：将hive一列中复杂的array或者map结构拆分成多行。
LATERAL VIEW 用于和split, explode等UDTF一起使用，它能够将一列数据拆成多行数据
52、Hive的优化
（1）、Fetch抓取（配置）
Fetch抓取是指，Hive中对某些情况的查询（select * …）可以不必使用MapReduce计算。
（2）、采用压缩，减少网络io（配置）
（3）、并行执行（配置）
某个特定的job可能包含众多的阶段，而这些阶段可能并非完全互相依赖的，也就是说有些阶段是可以并行执行的，这样可能使得整个job的执行时间缩短。
（4）、本地模式
有时Hive的输入数据量是非常小的。在这种情况下，为查询触发执行任务消耗的时间可能会比实际job的执行时间要多的多。对于大多数这种情况，Hive可以通过本地模式在单台机器上处理所有的任务。对于小数据集，执行时间可以明显被缩短。
（5）、表的优化
①. 大表Join大表
a. 空KEY过滤
b. 空key转换
有时虽然某个key为空对应的数据很多，但是相应的数据不是异常数据，必须要包含在join的结果中，此时我们可以表a中key为空的字段赋一个随机的值，使得数据随机均匀地分不到不同的reducer上
⑥. 动态分区调整
⑦. 采用分桶技术
（6）、数据倾斜
合理设置Map数
小文件进行合并
复杂文件增加Map数
合理设置Reduce数
（7）、JVM重用
小文件的场景或task特别多的场景，这类场景大多数执行时间都很短。
53、hive数据倾斜
数据倾斜主要表现在，map/reduce程序执行时，reduce节点大部分执行完毕，但是有一个或者几个reduce节点运行很慢，导致整个程序的处理时间很长，这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多)，这条Key所在的reduce节点所处理的数据量比其他节点就大很多，从而导致某几个节点迟迟运行不完。
2.小文件过多，需要合并小文件，还有就是jvm重用
3.map join解决小表关联大表造成的数据倾斜问题，其是将其中做连接的小表（全量数据）分发到所有Map端进行Join，从而避免了reduce任务，当小表全量数据很小的时候可进行此操作
7.对于Group操作，首先在map端聚合，最后在reduce端坐聚合
54、OLTP 与 OLAP
联机事务处理 OLTP，可以增删改查，用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数，性能要求高，数据量小
联机分析处理 OLAP，一般对数据进行分析，支持管理决策。
55、星型模型和雪花模型的区别？
星型模式是维度模型中最简单的形式,也用得最广泛。星型模式由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表。星型模式的物理模型像一颗星星的形状，中心是一个事实表， 围绕在事实表周围的维度表表示星星的放射状分支，这就是星型模式这个名字的由来。
雪花模式是一种多维模型中表的逻辑布局，其实体关系图有类似于雪花的形状，因此得名。雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。
星座模型由多个主题构成，包含多个事实表，而维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式。
模型的选择：
首先就是星座不星座这个只跟数据和需求有关系，跟设计没关系，不用选择。
星型还是雪花，取决于性能优先，还是避免冗余、灵活更优先。
目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤其是hadoop体系，减少join就是减少shuffle，性能差距很大。（关系型数据可以依靠强大的主键索引）
区别：
冗余：星星模式冗余相对于雪花模型多一些，雪花模型更符合三范式
性能：雪花模型因为要关联维度表，使用三范式降低了冗余，所以查询时性能偏低，星星模式更快一些，这里就是时间换空间，还是空间换时间的选择了，而且一般bi工具对星型模型支持更好
ETL，雪花模型etl中编写简单，但是并行化低，星星模型编写略麻烦，但是并行化高
56、数据仓库分层
57、Redis的5种数据类型
string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。
58、Redis 消息队列
59、Redis的hash存储
redis的hash架构就是标准的hashtable的结构，通过挂链解决冲突问题。
60、REDIS缓存穿透，缓存击穿，缓存雪崩原因
为了克服上述的问题，项目通常会引入NoSQL技术，这是一种基于内存的数据库，并且提供一定的持久化功能。
redis技术就是NoSQL技术中的一种，但是引入redis又有可能出现缓存穿透，缓存击穿，缓存雪崩等问题。本文就对这三种问题进行较深入剖析。
61、Redis缓存穿透解决方案
62、redis缓存击穿解决方案
key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。
使用互斥锁(mutex key)
63、redis缓存崩溃的解决方法
这里提出了三种方案：使用锁或队列、设置过期标志更新缓存、为key设置不同的缓存失效时间，还有一种被称为“二级缓存”的解决方法
64、redis集群模式
65、Redis主从模式
Redis 提供了复制（replication）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。
在复制的概念中，数据库分为两类，一类是主数据库（master），另一类是从数据库(slave）。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。
特点
- 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库
- 从数据库一般都是只读的，并且接收主数据库同步过来的数据
- 一个master可以拥有多个slave，但是一个slave只能对应一个master
- slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来
- master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务
- master挂了以后，不会在slave节点中重新选一个master
缺点：
从上面可以看出，master节点在主从模式中唯一，若master挂掉，则redis无法对外提供写服务。
66、Redis哨兵模式
主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因此sentinel应运而生。
sentinel中文含义为哨兵，顾名思义，它的作用就是监控redis集群的运行状况，特点如下：
- sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义
- 当master挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master
- 当master重新启动后，它将不再是master而是做为slave接收新的master的同步数据
- sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群
- 多sentinel配置的时候，sentinel之间也会自动监控
- 当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不需要担心
- 一个sentinel或sentinel集群可以管理多个主从Redis，多个sentinel也可以监控同一个redis
- sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了
优点：
哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
主从可以自动切换，系统更健壮，可用性更高。
缺点：
Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。
67、Redis Cluster集群
- 多个redis节点网络互联，数据共享
- 所有的节点都是一主一从（也可以是一主多从），其中从不提供服务，仅作为备用
- 不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，
并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为 - 支持在线增加、删除节点
- 客户端可以连接任何一个主节点进行读写
68、hdfs工作机制
69、tcp，udp的区别
70、网络七层和网络四层，它们的区别是什么
71、数据库存储数据的具体文件是什么，有几种
72、myisam和innodb的区别
73、数据库锁的类型
74、数据库explain和show profile的具体应用
75、Hbase是什么
76、Hbase特点
1）海量存储
Hbase适合存储PB级别的海量数据，在PB级别的数据以及采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。这与Hbase的极易扩展性息息相关。正式因为Hbase良好的扩展性，才为海量数据的存储提供了便利。
2）列式存储
这里的列式存储其实说的是列族存储，Hbase是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定。
3）极易扩展
Hbase的扩展性主要体现在两个方面，一个是基于上层处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）。
通过横向添加RegionSever的机器，进行水平扩展，提升Hbase上层的处理能力，提升Hbsae服务更多Region的能力。
备注：RegionServer的作用是管理region、承接业务的访问，这个后面会详细的介绍通过横向添加Datanode的机器，进行存储层扩容，提升Hbase的数据存储能力和提升后端存储的读写能力。
4）高并发
由于目前大部分使用Hbase的架构，都是采用的廉价PC，因此单个IO的延迟其实并不小，一般在几十到上百ms之间。这里说的高并发，主要是在并发的情况下，Hbase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。
5）稀疏
稀疏主要是针对Hbase列的灵活性，在列族中，你可以指定任意多的列，在列数据为空的情况下，是不会占用存储空间的。
77、HBase中的角色
HMaster
功能：
1．监控RegionServer
2．处理RegionServer故障转移
3．处理元数据的变更
4．处理region的分配或转移
5．在空闲时间进行数据的负载均衡
6．通过Zookeeper发布自己的位置给客户端
RegionServer
功能：
1．负责存储HBase的实际数据
2．处理分配给它的Region
3．刷新缓存到HDFS
4．维护Hlog
5．执行压缩
6．负责处理Region分片
78、hbase读写流程
读流程：
1）Client先访问zookeeper，从meta表读取region的位置，然后读取meta表中的数据。meta中又存储了用户表的region信息；
2）根据namespace、表名和rowkey在meta表中找到对应的region信息；
3）找到这个region对应的regionserver；
4）查找对应的region；
5）先从MemStore找数据，如果没有，再到BlockCache里面读；
6）BlockCache还没有，再到StoreFile上读(为了读取的效率)；
7）如果是从StoreFile里面读取的数据，不是直接返回给客户端，而是先写入BlockCache，再返回给客户端。
写流程：
1）Client向HregionServer发送写请求；
2）HregionServer将数据写到HLog（write ahead log）（WAL）。为了数据的持久化和恢复；
3）HregionServer将数据写到内存（MemStore）；
4）反馈Client写成功。
数据flush过程：
1）当MemStore数据达到阈值（默认是128M，老版本是64M），将数据刷到硬盘，将内存中的数据删除，同时删除HLog中的历史数据；
2）并将数据存储到HDFS中；
数据合并过程：
1）当数据块达到4块，Hmaster将数据块加载到本地，进行合并；
2）当合并的数据超过256M，进行拆分，将拆分后的Region分配给不同的HregionServer管理；
3）当HregionServer宕机后，将HregionServer上的hlog拆分，然后分配给不同的HregionServer加载，修改.META.；
4）注意：HLog会同步到HDFS。
79、hbase内部存储格式
HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，主要包括上述提出的两种文件类型：
1）HFile， HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile
2） HLog File，HBase中WAL（Write Ahead Log） 的存储格式，物理上是Hadoop的Sequence File
80、hbase的 rowkey设计
设计原则：
1.Rowkey 长度原则
RowKey是一个二进制码流，可以是任意字符串，最大长度为64kb，实际应用中一般为10-100byte，以 byte[] 形式保存，一般设计成定长。建议越短越好，不要超过16个字节，原因如下：
数据的持久化文件HFile中时按照Key-Value存储的，如果RowKey过长，例如超过100byte，那么1000w行的记录，仅RowKey就需占用近1GB的空间。这样会极大影响HFile的存储效率。
MemStore会缓存部分数据到内存中，若RowKey字段过长，内存的有效利用率就会降低，就不能缓存更多的数据，从而降低检索效率。
目前操作系统都是64位系统，内存8字节对齐，控制在16字节，8字节的整数倍利用了操作系统的最佳特性。
2.唯一原则
必须在设计上保证RowKey的唯一性。由于在HBase中数据存储是Key-Value形式，若向HBase中同一张表插入相同RowKey的数据，则原先存在的数据会被新的数据覆盖。
3.RowKey 散列原则
设计的RowKey应均匀的分布在各个HBase节点上。
4.排序原则
HBase的RowKey是按照ASCII有序排序的（字典序），因此我们在设计RowKey的时候要充分利用这点。
5.针对热点问题的 RowKey 设计原则：
我们设计的Rowkey应均匀的分布在各个HBase节点上。拿常见的时间戳举例，假如Rowkey是按系统时间戳的方式递增，Rowkey的第一部分如果是时间戳信息的话将造成所有新数据都在一个RegionServer上堆积的热点现象，也就是通常说的Region热点问题， 热点发生在大量的client直接访问集中在个别RegionServer上（访问可能是读，写或者其他操作），导致单个RegionServer机器自身负载过高，引起性能下降甚至Region不可用，常见的是发生jvm full gc或者显示region too busy异常情况，当然这也会影响同一个RegionServer上的其他Region。
①rowkey 的前面增加随机数，失去 get 快速定位数据的能力。
②rowkey 的前面增加哈希。哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的 rowkey，可以使用 get 操作准确获取某一个行数据。
6.反转
手机号反转，牺牲了rowkey的有序性
7.时间戳反转
8.组合 RowKey 设计原则
RowKey 为多个属性拼接而成时，将具有高标识度的、经常使用检索列的属性放在组合RowKey 的前面。
81、HBase优化
82、hbase的协处理器
协处理器有两种： Observer 和 Endpoint
(1) Observer 类似于传统数据库中的触发器，当发生某些事件的时候这类协处理器会被 Server 端调用
(2) Endpoint 协处理器类似传统数据库中的存储过程，客户端可以调用这些 Endpoint 协处 理器执行一段 Server 端代码，并将 Server 端代码的结果返回给客户端进一步处理，最常 见的用法就是进行聚集操作。
(3)总结：
Observer 允许集群在正常的客户端操作过程中可以有不同的行为表现
Endpoint 允许扩展集群的能力，对客户端应用开放新的运算命令
协处理器的加载方式：
协处理器的加载方式有两种，我们称之为静态加载方式（ Static Load，全局的） 和动态加载方式 （ Dynamic Load）
83、怎么理解scala的函数式编程
84、Scala中的高阶函数
函数可以作为一个参数传入到一个方法当中去
85、Scala中的匿名函数(函数字面量)
86、Scala中的部分应用函数
部分应用函数, 是指一个函数有N个参数, 而我们为其提供少于N个参数, 那就得到了一个部分应用函数。
87、Scala柯里化
88、Scala闭包
闭包是一个函数，返回值依赖于声明在函数外部的一个或多个变量。
闭包通常来讲可以简单的认为是可以访问一个函数里面局部变量的另外一个函数。
89、Scala样例类
90、case class （样本类）是什么？
91、scala 伴生对象的作用
1.什么是伴生对象
2.伴生对象与伴生类
3、单例对象在第一次被访问时才会被初始化，来自于scala自带的predef包。
92、Spark是什么?
93、Spark核心组件
Driver：
Spark驱动器节点，用于执行Spark任务中的main方法，负责实际代码的执行工作。Driver在Spark作业执行时主要负责：
1.将用户程序转化为作业（job）；
2.在Executor之间调度任务(task)；
3.跟踪Executor的执行情况；
4.通过UI展示查询运行情况；
Executor：
Spark Executor节点是一个JVM进程，负责在 Spark 作业中运行具体任务，任务彼此之间相互独立。Spark 应用启动时，Executor节点被同时启动，并且始终伴随着整个 Spark 应用的生命周期而存在。如果有Executor节点发生了故障或崩溃，Spark 应用也可以继续执行，会将出错节点上的任务调度到其他Executor节点上继续运行。（spark的容错机制）
Executor有两个核心功能：
- 负责运行组成Spark应用的任务，并将结果返回给驱动器进程；
- 它们通过自身的块管理器（Block Manager）为用户程序中要求缓存的 RDD 提供内存式存储。RDD 是直接缓存在Executor进程内的，因此任务可以在运行时充分利用缓存数据加速运算。
94、Spark和mapreduce的区别
95、Spark运行模式
本地模式：
Spark单机运行，一般用于开发测试。
Standalone模式：
构建一个由Master Slave构成的Spark集群，Spark运行在集群中。
Spark on Yarn模式：
Spark客户端直接连接Yarn。不需要额外构建Spark集群。
Spark on Mesos模式：
生产环境一般使用yarn-cluster,测试一个般用Client或者单机
96、Spark提交过程
YARN Cluster模式：
97、java和scala的区别：
持续更新中。。。。
来源：https://wwwhttp://www.360doc.com/content/21/0118/15/content-4-825701.html到此这篇连redis命令（redis软件怎么连接redis）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/rfx/24103.html