CopyTable es una sencilla utilidad de Apache HBase que, como era de esperar, se puede utilizar para copiar tablas individuales dentro de un clúster de HBase o de un clúster de HBase a otro. En esta publicación de blog, hablaremos sobre qué es esta herramienta, por qué querría usarla, cómo usarla y algunas advertencias de configuración comunes.
Casos de uso:
CopyTable es, en esencia, un trabajo de Apache Hadoop MapReduce que usa la interfaz de ruta de lectura HBase Scan estándar para leer registros de una tabla individual y los escribe en otra tabla (posiblemente en un clúster separado) usando la interfaz de ruta de escritura HBase Put estándar. Se puede utilizar para muchos propósitos:
- Copia interna de una tabla (fotografía del pobre)
- Copia de seguridad de instancia HBase remota
- Copias incrementales de tablas HBase
- Copias parciales de la tabla HBase y cambios en el esquema de la tabla HBase
Supuestos y limitaciones:
La herramienta CopyTable tiene algunas suposiciones y limitaciones básicas. En primer lugar, si se utiliza en una situación de varios clústeres, ambos clústeres deben estar en línea y la instancia de destino debe tener la tabla de destino presente con las mismas familias de columnas definidas que la tabla de origen.
Dado que la herramienta utiliza exploraciones y colocaciones estándar, el clúster de destino no tiene que tener la misma cantidad de nodos o regiones. De hecho, puede tener diferentes números de tablas, diferentes números de servidores de región y podría tener límites de división de región completamente diferentes. Dado que estamos copiando tablas completas, puede usar la configuración de optimización del rendimiento, como establecer valores de almacenamiento en caché de escáner más grandes para una mayor eficiencia. El uso de la interfaz put también significa que se pueden hacer copias entre grupos de diferentes versiones secundarias. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) o versiones compatibles con cable (0.92.1 -> 0.94.0).
Finalmente, HBase solo proporciona garantías ACID a nivel de fila; esto significa que mientras se ejecuta una CopyTable, pueden aparecer filas recién insertadas o actualizadas y estas ediciones simultáneas se incluirán por completo o se excluirán por completo. Si bien las filas serán consistentes, no hay garantías sobre la consistencia, la causalidad o el orden de las opciones de venta en las otras filas.
Copia interna de una tabla (Instantánea del pobre)
Las versiones de HBase hasta la versión 0.94.x más reciente, inclusive, no admiten la creación de instantáneas de tablas. A pesar de las limitaciones ACID de HBase, CopyTable se puede utilizar como un mecanismo de instantáneas ingenuo que hace una copia física de una tabla en particular.
Digamos que tenemos una tabla, tableOrig con familias de columnas cf1 y cf2. Queremos copiar todos sus datos a tableCopy. Primero debemos crear tableCopy con las mismas familias de columnas:
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
Luego podemos crear y copiar la tabla con un nuevo nombre en la misma instancia de HBase:
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig
Esto inicia un trabajo de MR que copiará los datos.
Copia de seguridad de instancia HBase remota
Digamos que queremos copiar datos a otro clúster. Esto podría ser una copia de seguridad única, un trabajo periódico o podría ser un arranque para la replicación entre clústeres. En este ejemplo, tendremos dos clústeres separados:srcCluster y dstCluster.
En este caso de varios clústeres, CopyTable es un proceso de inserción:su origen será la instancia de HBase a la que hace referencia su hbase-site.xml actual y los argumentos agregados apuntan al clúster y la tabla de destino. Esto también supone que todos los MR TaskTrackers pueden acceder a todos los nodos HBase y ZK en el clúster de destino. Este mecanismo de configuración también significa que puede ejecutar esto como un trabajo en un clúster remoto anulando las configuraciones de hbase/mr para usar la configuración de cualquier clúster remoto accesible y especificar los nodos ZK en el clúster de destino. Esto podría ser útil si desea copiar datos de un clúster de HBase con SLA más bajos y no desea ejecutar trabajos de MR directamente en ellos.
Utilizará la configuración –peer.adr para especificar el conjunto ZK del clúster de destino (por ejemplo, el clúster al que está copiando). Para esto, necesitamos la IP y el puerto del quórum ZK, así como el nodo raíz ZK de HBase para nuestra instancia de HBase. Digamos que una de estas máquinas es srcClusterZK (enumerada en hbase.zookeeper.quorum) y que estamos usando el puerto de cliente zk predeterminado 2181 (hbase.zookeeper.property.clientPort) y el ZK znode padre predeterminado /hbase (zookeeper.znode. padre). (Nota:si tuviera dos instancias de HBase usando el mismo ZK, necesitaría un zookeeper.znode.parent diferente para cada clúster.
# create new tableOrig on destination cluster dstCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell # on source cluster run copy table with destination ZK quorum specified using --peer.adr # WARNING: In older versions, you are not alerted about any typo in these arguments! srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase tableOrig
Tenga en cuenta que puede usar el argumento –new.name con –peer.adr para copiar a una tabla con un nombre diferente en el dstCluster.
# create new tableCopy on destination cluster dstCluster$ echo "create 'tableCopy', 'cf1', 'cf2'" | hbase shell # on source cluster run copy table with destination --peer.adr and --new.name arguments. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase --new.name=tableCopy tableOrig
Esto copiará datos de tableOrig en srcCluster a la tabla tableCopy de dstCluster.
Copias incrementales de tablas HBase
Una vez que tiene una copia de una tabla en un clúster de destino, ¿cómo copia los datos nuevos que luego se escriben en el clúster de origen? Ingenuamente, podría ejecutar el trabajo CopyTable nuevamente y copiar toda la tabla. Sin embargo, CopyTable proporciona un mecanismo de copia incremental más eficiente que simplemente copia las filas actualizadas del srcCluster al dstCluster de respaldo especificado en una ventana de tiempo. Por lo tanto, después de la copia inicial, podría tener un trabajo cron periódico que copie datos solo de la hora anterior de srcCluster a dstCuster.
Esto se hace especificando los argumentos –starttime y –endtime. Los tiempos se especifican como milisegundos decimales desde la época de Unix.
# WARNING: In older versions, you are not alerted about any typo in these arguments! # copy from beginning of time until timeEnd # NOTE: Must include start time for end time to be respected. start time cannot be 0. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=1 --endtime=timeEnd ... # Copy from starting from and including timeStart until the end of time. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timeStart ... # Copy entries rows with start time1 including time1 and ending at timeStart excluding timeEnd. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timestart --endtime=timeEnd
Copias parciales de la tabla HBase y cambios en el esquema de la tabla HBase
De forma predeterminada, CopyTable copiará todas las familias de columnas de las filas coincidentes. CopyTable proporciona opciones solo para copiar datos de familias de columnas específicas. Esto podría ser útil para copiar datos de origen originales y excluir familias de columnas de datos derivados que se agregan mediante el procesamiento de seguimiento.
Al agregar estos argumentos, solo copiamos datos de las familias de columnas especificadas.
- –familias=srcCf1
- –familias=srcCf1,srcCf2
A partir de 0.92.0, puede copiar mientras cambia el nombre de familia de la columna:
- –familias=srcCf1:dstCf1
- copiar de srcCf1 a dstCf1
- –familias=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
- copiar de srcCf1 a destCf1, copiar dstCf2 a dstCf2 (sin cambiar el nombre) y srcCf3 a dstCf3
¡Tenga en cuenta que dstCf* debe estar presente en la tabla dstCluster!
A partir de 0.94.0, se ofrecen nuevas opciones para copiar marcadores de eliminación e incluir un número limitado de versiones sobrescritas. Anteriormente, si se eliminaba una fila en el clúster de origen, la eliminación no se copiaba, sino que una versión obsoleta de esa fila permanecía en el clúster de destino. Esto aprovecha algunas de las funciones avanzadas de la versión 0.94.0.
- –versiones=vers
- donde vers es el número de versiones de celdas para copiar (el valor predeterminado es 1, también conocido como el último solamente)
- –todas.las.celdas
- también copiar eliminar marcadores y celdas eliminadas
Errores comunes
El cliente de HBase en las versiones 0.90.x, 0.92.x y 0.94.x siempre usa zoo.cfg si está en el classpath, incluso si un archivo hbase-site.xml especifica otras opciones de configuración de quórum de ZooKeeper. Esta "característica" causa un problema común en CDH3 HBase porque sus paquetes incluyen de forma predeterminada un directorio donde vive zoo.cfg en la ruta de clases de HBase. Esto puede generar frustración al intentar usar CopyTable (HBASE-4614). La solución para esto es excluir el archivo zoo.cfg de la ruta de clase de su HBase y especificar las propiedades de configuración de ZooKeeper en su archivo hbase-site.xml. http://hbase.apache.org/book.html#zookeeper
Conclusión
CopyTable proporciona un seguro de recuperación ante desastres simple pero efectivo para las implementaciones de HBase 0.90.x (CDH3). Junto con la función de replicación encontrada y admitida en HBase basado en HBase 0.92.x de CDH4, las funciones incrementales de CopyTable se vuelven menos valiosas, pero su funcionalidad central es importante para arrancar una tabla replicada. Si bien las funciones más avanzadas, como las instantáneas de HBase (HBASE-50), pueden ayudar con la recuperación ante desastres cuando se implementa, CopyTable seguirá siendo una herramienta útil para el administrador de HBase.
