Esta entrada de blog se publicó en Hortonworks.com antes de la fusión con Cloudera. Es posible que algunos enlaces, recursos o referencias ya no sean precisos.
En 2016, publicamos la segunda versión v1.0.1 de Spark HBase Connector (SHC). En este blog, repasaremos las funciones principales que hemos implementado este año.
Apoyo al codificador de Phoenix
SHC se puede utilizar para escribir datos en el clúster de HBase para su posterior procesamiento posterior. Es compatible con la serialización Avro para datos de entrada y salida y, de forma predeterminada, una serialización personalizada mediante un mecanismo de codificación nativo simple. Al leer los datos de entrada, SHC empuja hacia abajo los filtros a HBase para escaneos eficientes de datos. Dada la popularidad de los datos de Phoenix en HBase, parece natural admitir los datos de Phoenix como entrada a HBase además de los datos de Avro. Además, el uso predeterminado de la codificación binaria nativa simple parece susceptible a cambios futuros y es un riesgo para los usuarios que escriben datos de SHC en HBase. Por ejemplo, con SHC en el futuro, la compatibilidad con versiones anteriores debe manejarse adecuadamente. Por lo tanto, el SHC predeterminado debe cambiar a un formato más estándar y bien probado como Phoenix.
Para la compatibilidad con la clave compuesta, antes de esta función, se requería fijar la longitud del valor de cada dimensión, con la excepción de la última dimensión de la clave compuesta. Esta limitación ha sido eliminada por el codificador Phoenix. Actualmente, si los usuarios eligen Phoenix como codificador de datos, no necesitan especificar la longitud de cada parte de la clave compuesta en el catálogo.
Como Phoenix es el codificador predeterminado, el único cambio para los usuarios es que si quieren usar PrimitiveType como codificador de datos, deben especificar "tableCoder":"PrimitiveType" en sus catálogos para notificar a SHC que quieren usar PrimitiveType en su lugar. de Phoenix como "tableCoder".
def catálogo =s”””{
|”table”:{“namespace”:”default”, “name”:”table1″, “tableCoder”:”PrimitiveType”},
|”rowkey ”:”clave”,
|”columnas”:{
|”col0″:{“cf”:”fila”, “col”:”clave”, “tipo”:”cadena”} ,
|”col1″:{“cf”:”cf1″, “col”:”col1″, “type”:”boolean”},
|”col2″:{“cf”:”cf2″, “col”:”col2″, “tipo”:”doble”},
|”col3″:{“cf”:”cf3″, “col”:”col3″, “tipo” :”float”},
|”col4″:{“cf”:”cf4″, “col”:”col4″, “type”:”int”},
|”col5″:{“cf”:”cf5″, “col”:”col5″, “tipo”:”bigint”},
|”col6″:{“cf”:”cf6″, “col”:”col6 ″, “tipo”:”smallint”},
|”col7″:{“cf”:”cf7″, “col”:”col7″, “tipo”:”cadena”},
|”col8″:{“cf”:”cf8″, “col”:”col8″, “type”:”tinyint”}
|}
|}”””.stripMargin
Caché de conexiones Spark HBase
SHC no almacenaba en caché los objetos de conexión a HBase antes. Específicamente, la llamada a 'ConnectionFactory.createConnection' se realizó cada vez que SHC necesitaba visitar tablas y regiones de HBase. Los usuarios pueden ver esto simplemente mirando los registros del ejecutor y observando las conexiones del cuidador del zoológico que se establecen para cada solicitud. En la documentación de la conexión de la interfaz, dice que la creación de la conexión es una operación pesada y que las implementaciones de conexión son seguras para subprocesos. Por lo tanto, para procesos de larga duración, sería muy útil que SHC mantuviera una conexión en caché. Con esta función, SHC reduce drásticamente la cantidad de conexiones creadas y mejora considerablemente su rendimiento en el proceso.
Admite familias de columnas duplicadas
SHC ha apoyado el soporte de familias de columnas duplicadas. Ahora los usuarios pueden definir sus catálogos así:
def catálogo =s”””{
|”table”:{“namespace”:”default”, “name”:”table1″, “tableCoder”:”PrimitiveType”},
|”rowkey ”:”clave”,
|”columnas”:{
|”col0″:{“cf”:”fila”, “col”:”clave”, “tipo”:”cadena”} ,
|”col1″:{“cf”:”cf1″, “col”:”col1″, “type”:”boolean”},
|”col2″:{“cf”:”cf1″, “col”:”col2″, “tipo”:”doble”},
|”col3″:{“cf”:”cf1″, “col”:”col3″, “tipo” :”float”},
|”col4″:{“cf”:”cf2″, “col”:”col4″, “type”:”int”},
|”col5″:{“cf”:”cf2″, “col”:”col5″, “tipo”:”bigint”},
|”col6″:{“cf”:”cf3″, “col”:”col6 ″, “tipo”:”smallint”},
|”col7″:{“cf”:”cf3″, “col”:”col7″, “tipo”:”cadena”},
|”col8″:{“cf”:”cf3″, “col”:”col8″, “type”:”tinyint”}
|}
|}”””.stripMargin
En la definición de catálogo anterior, la columna 'col0', 'col1' y 'col2' tienen la misma familia de columnas 'cf1'.
Usar la API Spark UnhandledFilters
SHC también implementó Spark API unhandledFilters, que es una optimización efectiva. Esta API informa a Spark sobre los filtros que SHC no está implementando en lugar de devolver todos los filtros. El comportamiento anterior, en este caso, era volver a aplicar todos los filtros una vez que se extraen los datos en Spark. Esto debería ser idempotente, por lo que no cambia ningún dato, pero puede ser costoso si los filtros son complicados.
Comunidad SHC
La comunidad de SHC es más grande e influyente que hace un año. En 2016, dimos charlas en Hadoop Summit y en reuniones de HBase/Spark, y escribimos blogs detallados. Con el aumento del número de usuarios de SHC, recibimos un mayor número de preguntas de los usuarios. Estamos muy contentos de ver una mayor adopción de SHC y si tiene alguna idea sobre cómo mejorarlo aún más, envíenos sus comentarios a través de Hortonworks Community Connection.
RECONOCIMIENTO
Queremos agradecer al equipo de Bloomberg por guiarnos en este trabajo y también por ayudarnos a validar este trabajo. También queremos agradecer a la comunidad de HBase por brindar sus comentarios y mejorar esto. Finalmente, este trabajo ha aprovechado las lecciones de integraciones anteriores de Spark HBase y queremos agradecer a sus desarrolladores por allanar el camino.
REFERENCIA:
SHC:https://github.com/hortonworks-spark/shc
Apache HBase: https://hbase.apache.org/
Apache Spark: http://spark.apache.org/
Apache Phoenix: https://phoenix.apache.org/
