Yes, in the spirit as Camuel presented in his Apache Drill presentation -- 
executable script

-----Original Message-----
From: Timothy Chen [mailto:[email protected]] 
Sent: Thursday, December 06, 2012 5:13 PM
To: [email protected]
Cc: [email protected]; [email protected]
Subject: Re: What do you want out of Apache Drill?

So to be specific you mean the ability to translate drql into a spark execution 
plan?

Tim

Sent from my iPad

On Dec 6, 2012, at 1:33 PM, Andrew Psaltis <[email protected]> wrote:

>> So, What do you want Apache Drill to help you with?
> 
> I also want what Julian wants in respect to #1 (A SQL interface in addition 
> to DrQL interface), but Santa I also would like the following:
> 
> 1.  An ability to generate a plan for a Map Reduce framework, more 
> specifically to generate a plan that can be executed by Spark.  That plan can 
> start with the stack at a low level that then we could walk and do the 
> "correct" thing in Spark.
> 2. A follow on to #2 would be to generate the Java or Scala code that could 
> be used to drive then generation of a Spark RDD
> 
> I realize that this is perhaps outside of the scope of Drill, but I would be 
> willing and ready to work on making this gift a become reality.
> 
> Thanks,
> Andrew
> 
> 
> Dear Santa,
> 
> Here's what I'd like:
> 
> 
> -----Original Message-----
> From: Julian Hyde [mailto:[email protected]] 
> Sent: Thursday, December 06, 2012 12:44 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: What do you want out of Apache Drill?
> 
> On Dec 6, 2012, at 10:36 AM, Jacques Nadeau <[email protected]> wrote:
> 
>> So, What do you want Apache Drill to help you with?
> 
> Dear Santa,
> 
> Here's what I'd like:
> 
> 1 A SQL interface (in addition to DrQL interface)
> 2 JDBC driver
> 3 Access to the stack at a lower level (i.e. a way to use the 
> high-performance scan operators without writing a query)
> 4 Ability to query in-memory Java data in a compact form (e.g. arrays of 
> primitives or nio buffers)
> 
> 1+2 so that I can run Mondrian on Drill.
> 3 so that I can use Optiq to combine Drill data with data from other systems.
> 4 so that I can change Mondrian's cache implementation from "java objects" to 
> "in-memory database", whose blocks are managed by a cache such as jboss 
> infinispan
> 
> I know some of these are outside of Drill's scope. If so, feel free to 
> disregard. But if you don't ask, you don't get. :)
> 
> Julian

Reply via email to