Member since
02-24-2016
175
Posts
56
Kudos Received
3
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1500 | 06-16-2017 10:40 AM | |
12415 | 05-27-2016 04:06 PM | |
1359 | 03-17-2016 01:29 PM |
05-25-2016
12:25 PM
Just as an aside, if you also happen to be a paying Hortonworks support cluster, I can't speak highly enough about SmartSense, which will analyse the configs of your cluster and provide you with performance, stability and security recommendations specific to your exact environment. This service is included in every support contract, for more info take a look at: http://hortonworks.com/services/smartsense/ There was also a recent session at the Dublin Hadoop Summit which is worth watching for general tuning suggestions and recommendations (not security specific): https://www.youtube.com/watch?v=sCB6HmfdTZ4
... View more
06-07-2016
02:09 PM
1 Kudo
We came across a similar issue and our solution was to create a custom synchronization script which replaces the standard LDAP sync process. We define a "super-group" whose members are all groups that are visible/relevant to Hadoop. This is helpful for several reasons: It limits the group selection in Ranger itself It limits the users that are pulled into Ranger - only members of one of the relevant groups will be visible to Ranger It limits the amount of data that needs to be transfered during synchronization. (We have around 50k users in our Active Directory.) It gives us an efficient filter for LDAP queries. (We cannot filter by base DN because of AD policy.) The synchronization process knows only the DN of the super-group - it fetches that one LDAP entry; from there it determines the members, which are the authorization groups, and then the members of each authorization group, which are th authorized users.
... View more
05-19-2016
03:38 PM
Sure @Jitendra Yadav
... View more
09-11-2017
08:54 AM
@Rakesh Gupta Thank you very much. Smart debug sir. Saved me my day today.
... View more
05-19-2016
11:37 AM
1 Kudo
Thanks @vshukla, @Timothy Spann, @Jitendra Yadav, @Yuta Imai
... View more
05-26-2016
06:24 AM
1 Kudo
You are going to use hive account to run spark thrift server. So, if it is a manual install, then ./sbin/start-thriftserver.sh --master yarn-client --executor-memory 512m --hiveconf hive.server2.thrift.port=10015 will be run as user hive (with su hive) instead of user spark in secure setup. Similarly /var/run/spark and /var/log/spark should be read/write to hive. So, just seeing contents as user hive is not enough, you need to be able to write to those folders. One good easy way is to give 77x permissions on these folders. Since spark:hadoop is owner:group and hive belongs to group hadoop, it will have write access with this setup.
... View more
05-19-2016
10:23 AM
This doc is just showing you an example. Instead of using the principal "spark/blue1@EXAMPLE.COM", we could also consider using the principal "app1/blue1@EXAMPLE.COM" for one application, then using "app2/blue1@EXAMPLE.COM" for a second application etc.
... View more
02-02-2018
08:11 PM
with hiveserver2 you can also submit job on spark if spark is configured as execution engine in hive, right?
... View more
03-17-2016
01:29 PM
Well found the solution 🙂 posting answer in case if others face this issue in future. following line was missing: import sqlContext.implicits._
... View more
05-24-2016
04:28 PM
Thanks @Ancil McBarnett.
... View more
- « Previous
- Next »