kafka kerberos安全认证后消息测试

在CDH 5.13.1 启用了安全认证后,KAFKA需要经过一些安全参数配置才可以使用。而CDH各个地方的资料都有或多或少的问题,导致各种错误。我这里将今天的踩坑过程记录下来。

1、准备工作
首先需要通过kerberos的安全,需要准备好四个个文件:kaytab文件(krb认证文件)、jaas.conf文件、producer.properties、consumer.properties

jaas.conf文件内容:
KafkaClient {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab=”/Users/develop/test/testkafka/kafka.keytab”
storeKey=true
useTicketCache=true
debug=true
principal=”kafka@TEST.COM”;
};
注意里面keytab文件路径,要指向你存放keytab文件路径。

producer.properties文件内容:
security.protocol=SASL_PLAINTEXT
sasl.kerberos.service.name=kafka

consumer.properties文件内容:
security.protocol=SASL_PLAINTEXT
sasl.kerberos.service.name=kafka
sasl.mechanism=GSSAPI

2、导出jaas.conf文件路径到JVM环境变量
export KAFKA_OPTS=”-Djava.security.auth.login.config=/root/kafka_test/jaas.conf”

至此完成安全认证准备,可以进行kafka的相关操作了

3、创建topic
sh /opt/cloudera/parcels/KAFKA/bin/kafka-topics –create –zookeeper server1:2181/kafka –replication-factor 1 –partitions 1 –topic test
注意:-zookeeper server1:2181/kafka 最后的路径/kafka是cdh上kafka的默认root路径。如果不加这个路径就会报如下错误。

4、审查topic是否创建成功

sh /opt/cloudera/parcels/KAFKA/bin/kafka-topics –list –zookeeper server1:2181/kafka

5、创建消费者
sh /opt/cloudera/parcels/KAFKA/bin/kafka-console-consumer –new-consumer –topic test –from-beginning –bootstrap-server server1:9092 –consumer.config consumer.properties –partition 0
注意:虽然我们创建topic的时候设置–partitions 1,但是这里如若不指定–partition 0 ,消费者死活都不会拿到消息的!!具体原因没有仔细探查,估计是什么默认参数的问题,目前这样设置是可以拿到消息的。

6、创建生产者
sh /opt/cloudera/parcels/KAFKA/bin/kafka-console-producer –broker-list server1:9092 –topic test –producer.config producer.properties

至此可以在安全认证的kafka上,通过生产者和消费者测试。但是如何使用java程序登入安全认证的kafka还在努力中。。。感觉免费版的cdh真难用。。

Solr查询调优三:facet.threads

This param will cause loading the underlying fields used in faceting to be executed in parallel with the number of threads specified. Specify as facet.threads=N where N is the maximum number of threads used. Omitting this parameter or specifying the thread count as 0 will not spawn any threads, and only the main request thread will be used. Specifying a negative number of threads will create up to Integer.MAX_VALUE threads.

facet.threads指定执行facet查询时,并行执行的线程数量。
facet.threads默认为1或者指定为0时,在执行facet的时候只有一个单线程处理。当设置 facet.threads为N时,就会指定最大N个线程执行。当设置为-1时,等于设置为Interger.MAX_VALUE.

Solr查询调优二:fq 禁用缓存和post filter

关闭filter query的缓存
实际应用中,有很多的filter cache是没有必要的,而且filter cahce的上限数量是固定,所以应该禁用一些不常用的filter cache。
例子:
1、fq={!cache=false}id:123&fq={!frange l=90 u=100 cache=false}
2、scale(query({!v=”content:(solr OR lucene)”}),0,100)

改变filter执行顺序
将过滤最多数据的filter置于最前面,这样后面如果有需要进行高开销的filter,计算的数据量就大大减少。
例子:
fq={!cost=1}category:technology&
fq={!cost=2}date:[NOW/DAY-1YEAR TO *]&
fq={!geofilt pt=37.773,-122.419 sfield=location d=50 cost=3}&
fq={!frange l=90 u=100 cache=false cost=100}
scale(query({!v=”content:(solr OR lucene)”}),0,100)

COST的数值越高,filter越后执行。将特别耗资源的filter设置成100,同时将cache变成false,因为它的结果是随机值,没有保存的意义。类似于POST FILER。

POST FILTER
Post Filter是一个特殊filter。它在所有的main query和filter执行完毕后才开始执行,即在mainquery和filter产生的最后交集文档后执行post filter。
post filter类似于前面提到的将filter设置为cost=100.
post filter 一般用于高开销的检索和匹配。自己可以实现postfiler interface实现自己的post filter。

Solr查询调优一: query VS filterquery 区别

Solr有两个查询参数,分别是query(q)和filterquery(fq)。官方文档没有写清楚两者之间具体有什么区别。

fq的官方文档这样写着:https://lucene.apache.org/solr/guide/7_3/common-query-parameters.html#fq-filter-query-parameter

The fq parameter defines a query that can be used to restrict the superset of documents that can be returned, without influencing score. It can be very useful for speeding up complex queries, since the queries specified with fq are cached independently of the main query. When a later query uses the same filter, there’s a cache hit, and filter results are returned quickly from the cache.
When using the fq parameter, keep in mind the following:

  • The fq parameter can be specified multiple times in a query. Documents will only be included in the result if they are in the intersection of the document sets resulting from each instance of the parameter. In the example below, only documents which have a popularity greater then 10 and have a section of 0 will match.fq=popularity:[10 TO *]&fq=section:0
  • Filter queries can involve complicated Boolean queries. The above example could also be written as a single fq with two mandatory clauses like so:fq=+popularity:[10 TO *] +section:0
  • The document sets from each filter query are cached independently. Thus, concerning the previous examples: use a single fq containing two mandatory clauses if those clauses appear together often, and use two separate fq parameters if they are relatively independent. (To learn about tuning cache sizes and making sure a filter cache actually exists, see The Well-Configured Solr Instance.)
  • It is also possible to use filter(condition) syntax inside the fq to cache clauses individually and – among other things – to achieve union of cached filter queries.
  • As with all parameters: special characters in an URL need to be properly escaped and encoded as hex values. Online tools are available to help you with URL-encoding. For example: http://meyerweb.com/eric/tools/dencoder/.

fq和q虽然不太好区分,但是能明确区分出两者的差别,对性能提升很高。两者的主要区别如下:
1、q又叫main query,fq全程filter query;
2、相关性评分
fq只有一个用途:就是查询出满足条件的文档。q有两个用途:1、查询出满足条件的文档;2、对返回的文档针对搜索关键字进行相关性评分。因此可以这样使用两者:将q看成一个特殊的filter,仅会多一步相关性评分。所以可以将用户搜索的关键词放入q中,这样可以根据用户的搜索给出相关性最高的文档,例如keyword=apache solr,同时将用户下拉选择的枚举字段放入fq参数中,例如category=techonology。
3、缓存和执行速度
将filter query 从main query中分离出来,有两个目的:
1、filter query 可以使用 filter query cache。
2、filter query 不进行开销巨大的相关性评分,加快执行速度。
4、可以指定多fq,但是只能有一个q
5、执行顺序
到底是fq先执行,还是q执行,看了很多文档,各执一词。但是solr in action的答案比较靠谱,执行顺序还是要看具体情况。

1 、每一个fq参数都会首先到filter cache中查询文档是否存在。
2、如果fq参数没有在 filter cache 找到,就会检索索引文件,并将检索到docset放入缓存中。
3、所有filter的docset进行取交集,最终生成一个唯一的docset。
4 、The q parameter is passed in (along with the filter DocSet) to be executed as a
Lucene query. When executing the query, Lucene plays leapfrog between the
query and combined filters, advancing both the query and filter results objects
to their next present internal ID (an integer). When both the query result and
filter result objects contain the same ID, that ID is collected, a process that
includes generating the relevancy score for the document
这段我翻译的不太清楚。意思大概是将q查出来的结果和前面filter的结果进行交集,最后为交集的每一个结果计算相关性评分。
5、执行post filter

参考资料:
1、solr in action

Solr优化一:部署调整

我们有一张大宽表,数据量大概在20亿左右,100多个字段,HDFS中不算复制因子,原始数据文件差不多1.8TB。这算是一个较大的宽表了。
大数据集群节点大概20台.CDH默认只能在一个节点上安装一个SOLR实例。由于其版本过低,不满足我们的功能要求。改为了独立部署当时最新的SOLR版本V7.3.1。

第一种方案:
由于每个物理机上留给SOLR的内存只有60GB,所以一开始,我们在每个节点上部署了3个实例,每个SOLR实例 60GB/3 =20GB。这样部署有以下几个问题:
1、SOLR普通检索过慢,经常需要10S到几十秒不等。
2、SOLR的distinct分析语句经常导致 SOLR实例OOM。
3、SOLR实例挂掉后,无法自动重启。
4、索引建立还行,每分钟接近1000万。

第二种方案:
从大数据集群中独立出6台物理机,专门用作SOLR集群。扣掉HBASE占用的50GB内存,操作系统50GB,剩下的150GB留给SOLR使用。每个节点上部署5个实例,摊到每个实例上150GB/5=30GB。部署后结果:
1、SOLR普通检索速度提升,时间变为1秒到3秒之内。
2、SOLR的distinct分析语句偶尔导致 SOLR实例OOM 。但是SOLR能够自动重启。
3、 SOLR的distinct分析语句执行时间较长,大致在3.3分钟左右。
4、索引建立极慢,20分钟才能建完400万数据。目前未探明是卡在网络还是磁盘?磁盘应该不会,因为每个实例都在一块独立的磁盘。

个人认为OOM的原因是因为内存不足,没有给SOLR足够的缓存空间吧。因为在SOLR实例中看到系统的物理内存始终为250.6G,差一点256GB,濒临崩溃的边缘。但是CDH的监控,只有146GB,和SOLR的监控不一致。SOLR的HEAP-SPACE,32GB只用到了8GB.