incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Han <>
Subject Re: Looking for Champion
Date Wed, 20 Jun 2018 00:35:20 GMT
I think this should leave to the team who contribute to this project, those
projects could share different purpose but also can work together...if the
architecture is flexible enough.

Jim Apple <>于2018年6月19日周二 上午5:39写道:

> Let me respond specifically to a few of these as a way to, I hope,
> inspire the Palo community to reconsider contributing to Impala. It
> could be a great opportunity for us to produce value by keeping the
> query engine working smoothly while the Palo community can focus more
> of their efforts on the storage system. There is some analogue here
> with how Impala works on other storage systems.
> > Firstly, as a query engine for Hadoop, Impala deeply depend on HDFS and
> > HBase
> > (At least several years ago it was like this)
> Impala can run on other storage. See, for instance
> and
> > Secondly, due to introduced Mesa data model. The Catalog is different
> from
> > Impala.
> > We developped a In-Memory Catalog and also support Rollup, aggregation
> > data
> > model. As a consequnce, we have to change sql grammar based on Impala.
> Impala supports catalog data cached in memory, and adding new features
> to Impala's SQL grammar is not forbidden. I think one of my first
> largish contributions changed the grammar.
> > Thirdly, it is a big difference in Cluster manager and node deployment.
> > Contrast Impala, Query compiling, query execution coordination and
> catalog
> > management of storage engine are integrated to be frontend daemon.
> > Query execution and data storage are integrated to be backend daemon.
> I'm not sure I understand - how is Palo different here?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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