phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [DISCUSS] Road to HBase 2.0.0
Date Tue, 17 Oct 2017 20:24:58 GMT
+1 James' plan is similar to what I had in mind. I think the quicker we 
can get a branch in place to build against HBase2, the quicker we can 
find and fix all of these rough edges.

Great list you have here, Sergey. Will certainly be helpful.

Ankit/Rajeshbabu, did you guys have anything to add here? Could I 
encourage you to "run" with James' idea and start implementing some of 
these changes?

On 10/13/17 6:28 PM, Sergey Soldatov wrote:
> There is a list of problems that we need to fix to get it working with
> HBase 2.0:
> 1. renamed methods (such as add => addColumn). That's the easiest to fix
> 2. removed interfaces such as HTableInterface. We are supposed to use Table
> now. That may lead to some small difference between branches. Because
> that's funny, but there are some HBase 1.x methods are using deprecated
> API, but have no duplicated methods that appears only in 2.0. The same
> thing with KeyValue => Cell if I remember correctly.
> 3. Our wrappers for HTable/etc. Since the set of methods sometimes very
> different for 1.x and 2.0, we will need to maintain different versions.
> Luckily that's one time work and maintaining would not be hard because we
> rarely change them.
> 4. Some renaming would be required. I can recall KeyValueUtil, possible
> some else to avoid ambiguity between our and HBase classes.
> 5. signature some of methods has been changed. Like batch() now doesn't
> return the result, but requires it as an argument
> 6. Many methods switched from using byte[] to TableName. Don't remember,
> but possible that works fine with 1.x, so it can be part of (1)
> refactoring.
> 7. new Coprocessors. I have no idea how many changes we will have, because
> my previous attempts to get it working with HBase 2.0 were far before new
> implementation.
> I support the roadmap provided by James. Most of the changes I listed
> (300+K patch) can be done as the first bullet in his list.
> Thanks,
> Sergey
> On Fri, Oct 13, 2017 at 2:40 PM, James Taylor <>
> wrote:
>> One idea of where to put the code:
>> - switch to using non deprecated HBase methods in master
>> - same for Tephra
>> - create a 5.0-HBase-2.0 branch to put code specific to getting Phoenix to
>> work against HBase 2.0
>> - take a look at the changes and see if a shim layer makes sense (I'm only
>> -1 on an HBase 0.98 shim layer because the life span of that branch is very
>> limited)
>> - eventually make 5.0-HBase-2.0 the master branch
>> Thoughts?
>> On Fri, Oct 13, 2017 at 8:31 AM, Josh Elser <> wrote:
>>> Thanks, Anoop!
>>> I know Sergey, Ankit, and Rajeshbabu have been looking at this already.
>>> While tracking it is good, I think we still need to come up with a plan
>>> for where we're going to put that new code in Phoenix :)
>>> On 10/13/17 6:58 AM, Anoop John wrote:
>>>> Thanks for bringing this up.  I was abt to ask this.  Ya the CP
>>>> framework itself and the CP exposed interfaces (Like
>>>> RegionServerServices, Region etc) are undergoing a big change for for
>>>> HBase 2.0..  I did  a look at some of the usages of the Phoenix
>>>> exposed interfaces/classes.  There are some items for fix.   Was
>>>> thinking to raise an umbrella issue once we have a plan for the
>>>> version based on HBase 2.0
>>>> -Anoop-
>>>> On Thu, Oct 12, 2017 at 3:30 AM, Josh Elser <> wrote:
>>>>> Since 4.12.0 is out and we have the concurrent discussions about the
>>>>> 0.98,
>>>>> 1.1, and 1.2 HBase branches, do folks have a vision of how we get to
>>>>> HBase
>>>>> 2.0.0?
>>>>> The lack of chatter is pretty obvious that the Calcite work (the
>> previous
>>>>> impetus for Phoenix 5) has slowed. Once we get to an HBase
>> 2.0.0-alpha4,
>>>>> coprocessor API should stabilize and give us a point against which we
>> can
>>>>> start Phoenix work.
>>>>> Should a release of Phoenix that supports HBase 2.0 be worthy of the
>>>>> Phoenix
>>>>> 5.0 label, or should we stick to the 4.x numbering? Given the breaking
>>>>> changes going into HBase 2.0 and James' previous -1 to shim-layers for
>>>>> 0.98,
>>>>> do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x a
>>>>> different
>>>>> beast? I can see pros/cons for both sides.
>>>>> - Josh

View raw message