hbase/hbase-examples
Apekshit Sharma 0c883a23c5 HBASE-17732 Coprocessor Design Improvements
------------------------------------------------------
TL;DR
------------------------------------------------------
We are moving from Inheritence
- Observer *is* Coprocessor
- FooService *is* CoprocessorService
To Composition
- Coprocessor *has* Observer
- Coprocessor *has* Service

------------------------------------------------------
Design Changes
------------------------------------------------------
- Adds four new interfaces - MasterCoprocessor, RegionCoprocessor, RegionServierCoprocessor,
  WALCoprocessor
- These new *Coprocessor interfaces have a get*Observer() function for each observer type
  supported by them.
- Added Coprocessor#getService() to base interface. All extending *Coprocessor interfaces will
  get it from the base interface.
- Added BulkLoadObserver hooks to RegionCoprocessorHost instad of SecureBulkLoadManager doing its
  own trickery.
- CoprocessorHost#find*() fuctions: Too many testing hooks digging into CP internals.
  Deleted if can, else marked @VisibleForTesting.

------------------------------------------------------
Backward Compatibility
------------------------------------------------------
- Old coprocessors implementing *Observer won't get loaded (no backward compatibility guarantees).
- Third party coprocessors only implementing Coprocessor will not get loaded (just like Observers).
- Old coprocessors implementing CoprocessorService (for master/region host)
  /SingletonCoprocessorService (for RegionServer host) will continue to work with 2.0.
- Added test to ensure backward compatibility of CoprocessorService/SingletonCoprocessorService
- Note that if a coprocessor implements both observer and service in same class, its service
  component will continue to work but it's observer component won't work.

------------------------------------------------------
Notes
------------------------------------------------------
Did a side-by-side comparison of CPs in master and after patch. These coprocessors which were just
CoprocessorService earlier, needed a home in some coprocessor in new design. For most it was clear
since they were using a particular type of environment. Some were tricky.

- JMXListener - MasterCoprocessor and RSCoprocessor (because jmx listener makes sense for
  processes?)
- RSGroupAdminEndpoint --> MasterCP
- VisibilityController -> MasterCP and RegionCP

These were converted to RegionCoprocessor because they were using RegionCoprocessorEnvironment
which can only come from a RegionCPHost.
- AggregateImplementation
- BaseRowProcessorEndpoint
- BulkDeleteEndpoint
- Export
- RefreshHFilesEndpoint
- RowCountEndpoint
- MultiRowMutationEndpoint
- SecureBulkLoadEndpoint
- TokenProvider

Change-Id: I813145f2bc11815f52ac703563b879962c249764
2017-09-27 12:45:51 -07:00
..
src HBASE-17732 Coprocessor Design Improvements 2017-09-27 12:45:51 -07:00
README.txt HBASE-18387: [Thrift] Make principal configurable in DemoClient.java 2017-08-10 23:47:17 -04:00
pom.xml HBASE-18819 Set version number to 2.0.0-alpha3 from 2.0.0-alpha3-SNAPSHOT 2017-09-14 12:38:46 -07:00

README.txt

Example code.

* org.apache.hadoop.hbase.mapreduce.SampleUploader
    Demonstrates uploading data from text files (presumably stored in HDFS) to HBase.

* org.apache.hadoop.hbase.mapreduce.IndexBuilder
    Demonstrates map/reduce with a table as the source and other tables as the sink.
    You can generate sample data for this MR job via hbase-examples/src/main/ruby/index-builder-setup.rb.


* Thrift examples
    Sample clients of the HBase ThriftServer. They perform the same actions, implemented in
    C++, Java, Ruby, PHP, Perl, and Python. Pre-generated Thrift code for HBase is included
    to be able to compile/run the examples without Thrift installed.
    If desired, the code can be re-generated as follows:
    thrift --gen cpp --gen java --gen rb --gen py --gen php --gen perl \
        ${HBASE_ROOT}/hbase-thrift/src/main/resources/org/apache/hadoop/hbase/thrift/Hbase.thrift
    and re-placed at the corresponding paths. You should not have to do this generally.

    Before you run any Thrift examples, find a running HBase Thrift server (and a running
    hbase cluster for this server to talk to -- at a minimum start a standalone instance
    by doing ./bin/start-hbase.sh). If you start one locally (bin/hbase thrift start),
    the default port is 9090 (a webserver with basic stats defaults showing on port 9095).

    * Java: org.apache.hadoop.hbase.thrift.DemoClient (jar under lib/).
      1. Make sure your client has all required jars on the CLASSPATH when it starts. If lazy,
      just add all jars as follows: {HBASE_EXAMPLE_CLASSPATH=`./bin/hbase classpath`}
      2. If HBase server is not secure, or authentication is not enabled for the Thrift server, execute:
      {java -cp hbase-examples-[VERSION].jar:${HBASE_EXAMPLE_CLASSPATH} org.apache.hadoop.hbase.thrift.DemoClient <host> <port>}
      3. If HBase server is secure, and authentication is enabled for the Thrift server, run kinit at first, then execute:
      {java -cp hbase-examples-[VERSION].jar:${HBASE_EXAMPLE_CLASSPATH} org.apache.hadoop.hbase.thrift.DemoClient <host> <port> true <server-principal>}
      <server-principal> should only be specified when the client connects to a secure cluster. It's default value is "hbase".
      4. Here is a lazy example that just pulls in all hbase dependency jars and that goes against default location on localhost.
      It should work with a standalone hbase instance started by doing ./bin/start-hbase.sh:
      {java -cp ./hbase-examples/target/hbase-examples-2.0.0-SNAPSHOT.jar:`./bin/hbase classpath` org.apache.hadoop.hbase.thrift.DemoClient localhost 9090}

    * Ruby: hbase-examples/src/main/ruby/DemoClient.rb
      1. Modify the import path in the file to point to {$THRIFT_HOME}/lib/rb/lib.
      2. Execute {ruby DemoClient.rb} (or {ruby DemoClient.rb <host> <port>}).

    * Python: hbase-examples/src/main/python/DemoClient.py
      1. Modify the added system path in the file to point to {$THRIFT_HOME}/lib/py/build/lib.[YOUR SYSTEM]
      2. Execute {python DemoClient.py <host> <port>}.

    * PHP: hbase-examples/src/main/php/DemoClient.php
      1. Modify the THRIFT_HOME path in the file to point to actual {$THRIFT_HOME}.
      2. Execute {php DemoClient.php}.
      3. Starting from Thrift 0.9.0, if Thrift.php complains about some files it cannot include, go to thrift root,
        and copy the contents of php/lib/Thrift under lib/php/src. Thrift.php appears to include, from under the same root,
        both TStringUtils.php, only present in src/, and other files only present under lib/; this will bring them under
        the same root (src/).
        If you know better about PHP and Thrift, please feel free to fix this.

    * Perl: hbase-examples/src/main/perl/DemoClient.pl
      1. Modify the "use lib" path in the file to point to {$THRIFT_HOME}/lib/perl/lib.
      2. Use CPAN to get Bit::Vector and Class::Accessor modules if not present (see thrift perl README if more modules are missing).
      3. Execute {perl DemoClient.pl}.

    * CPP: hbase-examples/src/main/cpp/DemoClient.cpp
      1. Make sure you have boost and Thrift C++ libraries; modify Makefile if necessary.
        The recent (0.9.0 as of this writing) version of Thrift can be downloaded from http://thrift.apache.org/download/.
        Boost can be found at http://www.boost.org/users/download/.
      2. Execute {make}.
      3. Execute {./DemoClient}.

ON PROTOBUFS
This maven module has core protobuf definition files ('.protos') used by hbase
examples. 

Generation of java files from protobuf .proto files included here is done as
part of the build.