Since Google Bigtable doesn't support coprocessors, you'd need a version of Phoenix that doesn't rely on coprocessors (some server-side hooks that HBase provides). It'd be non trivial and you'd lose some functionality and performance in doing this, but theoretically it's possible.
Here are the kinds of changes you'd need to make: - modify aggregation so that it's done on the client instead of the server (this would be slower) - modify order by so that it's done on the client side (this wouldn't scale well) - don't use mutable, global secondary indexing (they're maintained on the server side) - don't use sequences (or replace them with a more limited/restricted implementation on top of HBase increment) - don't use local indexes (you might be able to cobble something together that'd work on the client, but there'd be some tricky edge cases) - don't use transactions (though they could potentially be made to work, there'd be some effort here) You'd also want to use Phoenix 5.0 since it's using HBase 2.0 APIs which I believe are the APIs support by Bigtable. Another couple alternative would be: - convince Google to support coprocessors, provide kind of similar server-side hooks, or support the server side code of Phoenix - use Big Query instead of Phoenix which has some Bigtable integration Thanks, James On Thu, Aug 2, 2018 at 1:56 PM, Vijay Vangapandu < vijayvangapa...@eharmony.com> wrote: > Hi Guys, > > We are using Hortneworks Hbase cluster with apache phoenix as query server. > We recently started migrating few services to GCP ( Google cloud). > > To move our on-prem Hbase to google cloud we found bigtable as suitable > replacement as it supports HBase client, but to use Hbase client we need to > change application code. > > Is there anyway we can work with apache phoenix query server with Google > Bigtable? > > Thanks for your response in advance. > > --Vijay. > >
