sql的一些问题：group by 时候前面字段比较多？
kafka是怎么工作的？
zookeeper有了解吗？
zookeeper是一个分布式服务框架，主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。有较好的容错机制，我们在实现Hadoop集群高可用，HBase集群元数据管理方面都用到了zookeeper。
Zookeeper的角色一般包含leader, Follower. 我们开发环境中的zookeeper节点是3台，一个是leader，剩下的是follower。（可能面试官会问zookeeper选举机制，回答不知道就行了，说清楚的话比较复杂）
平时开发用什么工具？
IDEA(Java开发工具)，Xshell（连接服务器，注意是服务器，不是虚拟机），Git（版本控制工具，说会的话，一些命令要知道，另外，私服是收费的）
linux netcat是怎么玩的？
Netcat是一款非常出名的网络工具，简称“NC”,有渗透测试中的“瑞士军刀”之称。它可以用作端口监听、端口扫描、远程文件传输、还可以实现远程shell等功能。简单用过一些，比如nc -lk 9999之类的。
你们搭建kafka是怎么测试连接的？
kafka的acks机制？怎么保证kafka最大吞吐量？
acks参数指定了在集群中有多少个分区副本收到消息，kafka producer才会认为消息是被写入成功。这个参数对消息丢失的可能性有很大的影响
如果acks=0，生产者在成功写入消息之前是不会等待任何的来自服务器的响应。也就是说如果当中出现了错误，导致broker没有收到消息，那么生产者是无从得知的，消息也就丢失了。不过，因为生产者不需要等待服务器的响应，从而可以以网络可以支持的最大的速度来发送消息，使得系统能够达到很高的吞吐量。
如果acks=1，只要集群的leader节点收到消息，生产者就会收到来自服务器成功的响应。若果消息不能够被leader节点接收（比如说leader节点崩溃，而新的leader尚未选出来），这时候生产者会收到一个错误响应，但是为了避免数据的丢失，生产者会重发消息。不过，如果一个没有收到消息的节点成为新leader，消息还是会丢失的。这个时候的吞吐量取决于使用的同步还是异步发送。如果让发送客户端（生产者）等待服务器的响应（通过调用Futrue对象的get()方法），显然会增加延迟（一次发送和响应的会话延迟）。如果客户端（生产者）使用回调，延迟问题就可以得到解决了，不过吞吐量还是会受到发送中消息数量的限制（比如生产者在收到服务器响应之前可以发送多少个消息）
如果acks=all / -1，只有在集群所有的跟随副本都接收到消息后，生产者才会受到一个来自服务器的成功响应。这种模式是最安全的，它可以保证集群中不止一个服务器接收到消息，就算有服务器崩溃了，这个集群还是能够正常运行。不过它比acks=1的延迟性更高，因为生产者要等待的所有参与复制消息的节点接收到消息。
我们为了保证kafka的吞吐量，以及消息的不丢失，ack设的为1.
Kafka 高吞吐率的实现
顺序读写
kafka的消息是不断追加到文件中的，这个特性使kafka可以充分利用磁盘的顺序读写性能顺序读写不需要硬盘磁头的寻道时间，只需很少的扇区旋转时间，所以速度远快于随机读写
零拷贝
文件分段
kafka的队列topic被分为了多个区partition，每个partition又分为多个段segment，所以一个队列中的消息实际上是保存在N多个片段文件中通过分段的方式，每次文件操作都是对一个小文件的操作，非常轻便，同时也增加了并行处理能力
批量发送
Kafka允许进行批量发送消息，先将消息缓存在内存中，然后一次请求批量发送出去比如可以指定缓存的消息达到某个量的时候就发出去，或者缓存了固定的时间后就发送出去如100条消息就发送，或者每5秒发送一次这种策略将大大减少服务端的I/O次数
数据压缩
Kafka还支持对消息集合进行压缩，Producer可以通过GZIP或Snappy格式对消息集合进行压缩压缩的好处就是减少传输的数据量，减轻对网络传输的压力
Consumer的负载均衡
当一个group中,有consumer加入或者离开时,会触发partitions均衡.均衡的最终目的,是提升topic的并发消费能力
shell 的if判断的条件，什么时候是true？
不懂这句话的意思。。。，是下面这个意思吗？
字符串判断
str1 = str2 当两个串有相同内容、长度时为真
str1 != str2 当串str1和str2不等时为真
-n str1 当串的长度大于0时为真(串非空)
-z str1 当串的长度为0时为真(空串)
str1 当串str1为非空时为真
Kafka的Topic特点
Flume的扇入扇出
在flume中有时候需要将一个源（source）将数据发送到多个地方（sink），在flume中该术语叫做扇出（fan out）
多个source配一个channel和一个sinks，这叫扇入；
ELK的几个查询关键词
"query": 在请求消息体中的query允许我们用Query DSL的方式查询。
"term": 查询时判断某个document是否包含某个具体的值，不会对被查询的值进行分词查询
"match" 将被查询值进行分词，然后用评分机制(TF/IDF)进行打分
"match_phrase": 查询指定段落
"Bool": 结合其他真值查询，通常和must should mustnot(与或非)一起组合出复杂的查询
"range": 查询时指定某个字段在某个特定的范围
"from": 以一定的偏移量来查看我们检索的结果，缺省从检索的第一条数据开始显示
"size": 指定检索结果中输出的数据条数，缺省为10条
"sort": 允许我们将检索的结果以指定的字段进行排序显示
"aggs": 基于搜索查询，可以嵌套聚合来组合复杂的需求
为什么HBase查询比较快
主要原因是由其架构和底层的数据结构决定的，即由LSM-Tree(Log-Structured Merge-Tree) + HTable(region分区) + Cache决定
客户端可以直接定位到要查数据所在的HRegion server服务器，然后直接在服务器的一个region上查找要匹配的数据，并且这些数据部分是经过cache缓存的
HBase会将数据保存到内存中，在内存中的数据是有序的，如果内存空间满了，会刷写到HFile中，而在HFile中保存的内容也是有序的。当数据写入HFile后，内存中的数据会被丢弃。HFile文件为磁盘顺序读取做了优化
HBase的写入速度快是因为它其实并不是真的立即写入文件中，而是先写入内存，随后异步刷入HFile。所以在客户端看来，写入速度很快。另外，写入时候将随机写入转换成顺序写，数据写入速度也很稳定。读取速度快是因为它使用了LSM树型结构，而不是B或B+树。磁盘的顺序读取速度很快，但是相比而言，寻找磁道的速度就要慢很多。HBase的存储结构导致它需要磁盘寻道时间在可预测范围内，并且读取与所要查询的rowkey连续的任意数量的记录都不会引发额外的寻道开销。比如有5个存储文件，那么最多需要5次磁盘寻道就可以。而关系型数据库，即使有索引，也无法确定磁盘寻道次数。而且，HBase读取首先会在缓存（BlockCache）中查找，它采用了LRU（最近最少使用算法），如果缓存中没找到，会从内存中的MemStore中查找，只有这两个地方都找不到时，才会加载HFile中的内容
工作中用什么将Kafka中的数据导入HBase