Why is LLAP needed to enable row level security on SparkThriftServer or Spark SQL through Ranger

[#1]

If Ranger is doing query re-writes why does it need LLAP. Why isn't Spark + HDFS sufficient for the query filtering?

[#2]

@Amit Sehgal

check this out https://hortonworks.com/blog/sparksql-ranger-llap-via-spark-thrift-server-bi-scenarios-provide-row-c...

[#3]

@Rishi

I read this article before, but the filtering and projection is already provided by Spark execution engine over HDFS. Why do we need LLAP in the middle only in context of row level security. (Note: I am not talking about performance benefits of LLAP in general here).

How about this?

USer submits query -> Ranger authorizes and modifies the query filters/projections-> the new query gets executed as normal Saprk SQL of HDFS (with no need of LLAP)

[#4]

I read this article before, but the filtering and projection is already provided by Spark execution engine over HDFS. Why do we need LLAP in the middle only in context of row level security. (Note: I am not talking about performance benefits of LLAP in general here).

How about this?

USer submits query -> Ranger authorizes and modifies the query filters/projections-> the new query gets executed as normal Saprk SQL of HDFS (with no need of LLAP)

[#5]

Indeed there is no need of using LLAP.

You could use this library for achieving what you are requesting without LLAP:

https://github.com/apache/submarine/tree/master/submarine-security/spark-security

It works between Spark and Ranger.