[
https://issues.apache.org/jira/browse/HIVE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649247#action_12649247
]
Ashish Thusoo commented on HIVE-30:
-----------------------------------
hmm...
Ideally the HiveServer that is being done as part of JDBC driver should be able
to handle all the session creation, processlist, authentication and be a single
gateway for submitting the queries, and as Joy says the client side libraries
for that server should be managing the data path. Regarding the state belonging
to the client, there is some state that needs to be there on the server as the
typical JDBC is session oriented and calls are within the context of a session.
The web server that is being done as part of this JIRA and the cli would then
communicate to the HiveServer for all those services as well as for query
compilation and submission. Having said that there would still be some web
client specific session information that the web server would have
to maintain, things like if a websession is free to take some other queries,
whether it has been named and initialized etc. Maybe we should call
SessionItem, WebSessionItem. All the administrative options that this JIRA then
provides for now are then only over WebSessions and not any other sessions
started by other clients (cli or programs like JDBC). We can expand the
capabilities of the Web Client to provide administration over those sesssions
once the HiveServer is ready and able to do all those things.
I think the current implementation of the HWIServer is also a vestige of the
fact that we do not have a server implementation for hive and our compiler
essentially runs as a client library today. One could see the SessionState(or
some equivalent of it) class be subsumed in the HiveServer and be provided to
the clients through the HiveServer interfaces (essentially a client side
handle). If we think of it in those terms then the current implementation is
not too much off the mark. SessionItem becomes WebSession. Processlist becomes
WebSessionLists. The authentication stuff that Edward is pointing to becomes
authentication for manipulating websessions only (though in the long term it
will be better to integrate the notion of authority there with the notion of
authority in HiveServer - which does not have any right now - maybe that should
get pulled into the Hive Server). WebSession holds the SessionState which is
the client side representation of a HiveServer session and allows the
websession to access the corresponding session on the HiveServer side.
Something on those lines...
Note in this model there is a single HiveServer (similar to a mysql or Oracle
instance), JDBC is a client side driver that just talks to this server, the Web
Server talks to this server too for much of the stuff (it is doing this through
the metastore server for metadata stuff and the HiveServer as proposed
currently by Ragu and Michi just includes those thrift calls as well - it is
super set of the MetaStore and the data operations).
Makes sense?
> Hive web interface
> ------------------
>
> Key: HIVE-30
> URL: https://issues.apache.org/jira/browse/HIVE-30
> Project: Hadoop Hive
> Issue Type: Bug
> Reporter: Jeff Hammerbacher
> Assignee: Edward Capriolo
> Priority: Minor
> Attachments: HIVE-30.patch
>
>
> Hive needs a web interface. The initial checkin should have:
> * simple schema browsing
> * query submission
> * query history (similar to MySQL's SHOW PROCESSLIST)
> A suggested feature: the ability to have a query notify the user when it's
> completed.
> Edward Capriolo has expressed some interest in driving this process.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
