[
https://issues.apache.org/jira/browse/PHOENIX-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15170690#comment-15170690
]
James Taylor edited comment on PHOENIX-154 at 2/27/16 6:39 PM:
---------------------------------------------------------------
Glad to hear you're interested, [~RCheungIT]. You have some impressive and
relevant experience. I completely agree that the scope of this JIRA is too
large to complete for a single person over a single GSoC term. I think the
first step would be to file sub tasks that break this down into more manageable
parts with the fundamental core pieces being developed first.
I'd recommend doing this work on our calcite branch [1]. This branch will
become our master branch as soon as the integration work is complete [2].
[~maryannxue] is leading this effort, so she'll likely have information to add
here. Apache Calcite [3] already supports the parsing and planning of the OLAP
extensions, producing relational algebra. The core work is already done to have
Phoenix work on top of calcite in terms of querying, so these OLAP extensions
would fit within that framework and the work would focus on the actual runtime
pieces and pushing as much of the work into the cluster as possible. There's an
interesting discussion on a good initial use case here: PHOENIX-2700. One of
the important core pieces IMO is pushing the sliding window building into the
HBase region servers through our coprocessors but still handling the case where
a the logical boundary of a window spans across our scan or region boundaries
(i.e. dealing with combining the windows that are being populated on different
servers without having to pull all the row-level information to the client).
[1]
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=shortlog;h=refs/heads/calcite
[2] https://issues.apache.org/jira/issues/?filter=12334819
[3] https://calcite.apache.org/
was (Author: jamestaylor):
Glad to hear you're interested, [~RCheungIT]. You have some impressive and
relevant experience. I completely agree that the scope of this JIRA is too
large to complete for a single person over a single GSoC term. I think the
first step would be to file sub tasks that break this down into more manageable
parts with the fundamental core pieces being developed first.
I'd recommend doing this work on our calcite branch [1]. This branch will
become our master branch as soon as the integration work is complete [2].
Apache Calcite [3] already supports the parsing and planning of the OLAP
extensions, producing relational algebra. The core work is already done to have
Phoenix work on top of calcite in terms of querying, so these OLAP extensions
would fit within that framework and the work would focus on the actual runtime
pieces and pushing as much of the work into the cluster as possible. There's an
interesting discussion on a good initial use case here: PHOENIX-2700. One of
the important core pieces IMO is pushing the sliding window building into the
HBase region servers through our coprocessors but still handling the case where
a the logical boundary of a window spans across our scan or region boundaries
(i.e. dealing with combining the windows that are being populated on different
servers without having to pull all the row-level information to the client).
[1]
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=shortlog;h=refs/heads/calcite
[2] https://issues.apache.org/jira/issues/?filter=12334819
[3] https://calcite.apache.org/
> Support SQL OLAP extensions
> ---------------------------
>
> Key: PHOENIX-154
> URL: https://issues.apache.org/jira/browse/PHOENIX-154
> Project: Phoenix
> Issue Type: New Feature
> Reporter: James Taylor
> Labels: gsoc2016
>
> Support the WINDOW, PARTITION OVER, GROUPING, RANK, DENSE RANK, ORDER BY etc.
> functionality.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
