drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Drill query parser and Hive
Date Wed, 17 Oct 2012 22:43:45 GMT
I don't think you are off-base at all.

We (the current contributors) are targeting Dremel as a first language
syntax because it has a number of convenient features for the analysis of
nested data.  But having Dremel syntax be a first target doesn't mean that
other targets are out of scope at all.

Building a parser that understands a subset of what Hive can do would be
worthy goal as well.  It just isn't what the current contributors are
working on.  That doesn't mean that a Hive compatible parser is bad, just
that it isn't what those folks are doing.  If you would like to do it, it
would be a great way to start contributing.  And if you start generating
compatible intermediate language before the Dremel parser does, so be it.

The general tenor of the Drill project is to enable alternatives, not
fixate on single implementations.  That is the motive for having a textual
intermediate language and that is the goal for separating parsing,
optimizing and executing steps so strenuously.



On Wed, Oct 17, 2012 at 3:26 PM, kulkarni.swarnim@gmail.com <
kulkarni.swarnim@gmail.com> wrote:

> Hello,
>
> For past few days I have been reading about drill and it surely seems like
> a very interesting project. However, as far as I understood, the query
> syntax seems to be very similar to what Apache Hive uses. I was wondering
> why we couldn't really take the hive query analyzer as a starting point and
> try to refactor it according to our needs? Hive also uses the ANTLR based
> parser to parse the queries and generate a Abstract Syntax Tree for the
> queries. I understand that the part where the AST gets converted to M/R
> tasks would be different, but seems like the first part might be reusable.
>
> Surely seems like I am missing something here.
>
> Thanks,
> --
> Swarnim
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message