Is there a way to make the broker merge big result set faster?
Hi, community, I have a subquery running slow on druid cluster. The *inner query* yield fields: *SELECT D1, D2, D3, MAX(M1) as MAX_M1* *FROM SOME_TABLE* *GROUP BY D1, D2, D3* Then, the outer query looks like: *SELECT D1, D2, SUM(MAX_M1)* *FROM INNER_QUERY* *GROUP BY D1, D2* The D3 is a high cardinality dimension, which makes the result set of the inner query very huge. But still, the inner query itself takes 1~2 seconds to "process" and transfer the data to the broker. The outer query, however, takes 40 seconds to process. As far as I understand how broker work with the historicals, I think the druid simply fetch the result of each segment directly from historicals' memory for the inner query, so that there isn't any computation when druid deals with the inner query. However, as the inner query finishes, all the results from the historicals will be passed to one single broker for merging the result. In my case, because the result set from the inner query is tremendous, this phase takes a long time to finish. I think the situation mentioned in this thread is quite similar to my case: https://groups.google.com/d/msg/druid-user/ir7hRpxg0PI/3oqCDAwoPjMJ Gian mentioned "Historical merging", and I have tried that by disabling the broker cache, but it didn't really make the query faster. Is there any other way to make broker merge faster? Thanks! Best regards, Mu
Re: Question about standalone Spark cluster reading from Kerberosed hadoop
Thanks for your prompt responses! @Steve I actually put my keytabs to all the nodes already. And I used them to kinit on each server. But how can I make spark to use my key tab and principle when I start cluster or submit the job? Or is there a way to let spark use ticket cache on each node? I tried --keytab and --principle when I submit the job, still get the same error. I guess that's for YARN only. On Fri, Jun 23, 2017 at 18:50 Steve Loughran <ste...@hortonworks.com> wrote: > On 23 Jun 2017, at 10:22, Saisai Shao <sai.sai.s...@gmail.com> wrote: > > Spark running with standalone cluster manager currently doesn't support > accessing security Hadoop. Basically the problem is that standalone mode > Spark doesn't have the facility to distribute delegation tokens. > > Currently only Spark on YARN or local mode supports security Hadoop. > > Thanks > Jerry > > > There's possibly an ugly workaround where you ssh in to every node and log > in direct to your kdc using a keytab you pushed out...that would eliminate > the need for anything related to hadoop tokens. After all, that's > essentially what spark-on-yarn does when when you give it keytab. > > > see also: > https://www.gitbook.com/book/steveloughran/kerberos_and_hadoop/details > > On Fri, Jun 23, 2017 at 5:10 PM, Mu Kong <kong.mu@gmail.com> wrote: > >> Hi, all! >> >> I was trying to read from a Kerberosed hadoop cluster from a standalone >> spark cluster. >> Right now, I encountered some authentication issues with Kerberos: >> >> >> java.io.IOException: Failed on local exception: java.io.IOException: >> org.apache.hadoop.security.AccessControlException: Client cannot >> authenticate via:[TOKEN, KERBEROS]; Host Details : local host is: >> ""; destination host is: XXX; >> >> >> >> I checked with klist, and principle/realm is correct. >> I also used hdfs command line to poke HDFS from all the nodes, and it >> worked. >> And if I submit job using local(client) mode, the job worked fine. >> >> I tried to put everything from hadoop/conf to spark/conf and hive/conf to >> spark/conf. >> Also tried edit spark/conf/spark-env.sh to add >> SPARK_SUBMIT_OPTS/SPARK_MASTER_OPTS/SPARK_SLAVE_OPTS/HADOOP_CONF_DIR/HIVE_CONF_DIR, >> and tried to export them in .bashrc as well. >> >> However, I'm still experiencing the same exception. >> >> Then I read some concerning posts about problems with >> kerberosed hadoop, some post like the following one: >> http://blog.stratio.com/spark-kerberos-safe-story/ >> , which indicates that we can not access to kerberosed hdfs using >> standalone spark cluster. >> >> I'm using spark 2.1.1, is it still the case that we can't access >> kerberosed hdfs with 2.1.1? >> >> Thanks! >> >> >> Best regards, >> Mu >> >> >
Question about standalone Spark cluster reading from Kerberosed hadoop
Hi, all! I was trying to read from a Kerberosed hadoop cluster from a standalone spark cluster. Right now, I encountered some authentication issues with Kerberos: java.io.IOException: Failed on local exception: java.io.IOException: org.apache.hadoop.security.AccessControlException: Client cannot authenticate via:[TOKEN, KERBEROS]; Host Details : local host is: ""; destination host is: XXX; I checked with klist, and principle/realm is correct. I also used hdfs command line to poke HDFS from all the nodes, and it worked. And if I submit job using local(client) mode, the job worked fine. I tried to put everything from hadoop/conf to spark/conf and hive/conf to spark/conf. Also tried edit spark/conf/spark-env.sh to add SPARK_SUBMIT_OPTS/SPARK_MASTER_OPTS/SPARK_SLAVE_OPTS/HADOOP_CONF_DIR/HIVE_CONF_DIR, and tried to export them in .bashrc as well. However, I'm still experiencing the same exception. Then I read some concerning posts about problems with kerberosed hadoop, some post like the following one: http://blog.stratio.com/spark-kerberos-safe-story/ , which indicates that we can not access to kerberosed hdfs using standalone spark cluster. I'm using spark 2.1.1, is it still the case that we can't access kerberosed hdfs with 2.1.1? Thanks! Best regards, Mu
