我在hbase中有一个表，它存储了数十亿行。行键设计和数据读写方式有点“智能”。例如：行键的前缀是salt，读取使用一个自定义的hbase过滤器，有一点多线程并行执行多个扫描。。。
一些应用程序将使用这些数据。我看到几个选项：
在每个客户端应用程序中实现“智能”，并使这些客户端应用程序直接使用hbase api访问数据。在多个客户机应用程序中复制智能看起来是一件坏事，因为如果智能的一部分发生变化，那么很难维护。
实现一个库来“封装”这个智能，并使客户机应用程序使用这个库。同样，如果智能发生变化，如何确保所有客户端应用程序都使用库的最新版本
在（微型）服务中实现这种智能。所有客户端应用程序都将通过此服务访问hbase数据。对我来说，这是最好的解决办法。如果智能发生了变化，我只需更改此服务中的代码就可以了（当然，只要与客户端应用程序的接口不受影响）。
所以我想选择第三种。然而，客户端应用程序在一次调用中可以读取的数据量可能涉及数百万条记录。如何使客户机应用程序和服务高效地通信？我觉得rest服务只提供少量数据。我想我需要一种流策略，服务在从hbase提取数据的同时将数据发送到客户端应用程序。我认为我不应该提取服务中的整个数据集，然后将其发送给客户端。这将导致内存不足异常。
到目前为止，我的策略是“低水平”。我使用javasocket。该服务有一个serversocket等待客户端socket。当客户端应用程序想要读取时，会创建一个套接字通信。客户端应用程序通过套接字通信向服务发送搜索条件。然后服务检索与搜索条件匹配的数据。服务在从hbase接收数据（使用经典的hbase api提取）的同时，动态地将数据写入套接字的输出流（使用dataoutputstream和bufferedoutputstream）。另一方面，客户机应用程序读取套接字输入流并解码数据。为了不让客户端应用程序代码受到这种低级套接字处理的困扰，我创建了一个库来“封装”它。
你怎么认为？这是正确的方法吗？是不是太“低级”？在保持良好性能的同时，您是否可以建议采用较少的“低级”方法将大量数据从一个应用程序传输到另一个应用程序（rest、rmi、rpc等等）？