Opción para agregar columnas particionadas en tablas master y reference

[huemulDeveloper]

Actualmente las particiones solo están implementadas para las tablas de tipo transaccional.

El objetivo es poder implementar particiones sobre tablas maestras y de referencia, de tal forma que permita mejorar la performance para tablas maestras que pueden ser de gran volúmen (> 10 millones de filas) y evitar los fullscan

[huemulDeveloper]

Implementación se hace sobre tablas maestras, de referencia y transaccionales. Considerar esta mejora para tablas tipo PARQUET, AVRO Y ORC. Para el caso de tablas en formato DELTA, la recomendación es habilitar solo una partición (https://docs.databricks.com/delta/porting.html).

Se implementa nuevo método que permite configurar a nivel de cada columna:

• setPartitionColumn(position,dropBeforeInsert, oneValuePerProcess): Este método permite indicar a cada columna de la tabla si es o no parte de la partición, recibe los siguientes parámetros:
  • position: indica la posición de la partición, por ejemplo si tiene 2 columnas de partición, la primera (1) irá en la parte más alta del arbol, y así sucesivamente.
  • dropBeforeInsert: Solo aplica para tablas de tipo transaction. Indica si la partición específica se debe borrar antes de insertar los nuevos valores. En caso que ninguna partición de la tabla esté en true, los valores anteriores nunca serán borrados, esto se debe tener presente por los reprocesos históricos. En caso que se requiera una tabla que almacene toda la historia y nunca sea borrada, se recomienda dejar todas las particiones con este parámetro en false.
  • onValueperProcess: Solo aplica para tblas de tipo transaction. Indica si el proceso en particular debe validar que la columna contenga un único valor. Usar este parámetro en true para indicar que un proceso solo puede contener un valor, por ejemplo si el campo particionado es una fecha, y en el archivo solo puede llegar una fecha a la vez, se debe dejar este atributo en true.

Ejemplo

  val periodo: huemul_Columns = new huemul_Columns(DateType,true,"Periodo de los datos")
                            .setIsPK().setPartitionColumn(1,false, true)
  val empresa: huemul_Columns = new huemul_Columns(StringType,true,"Empresa que registra ventas")
    .setPartitionColumn(2,true, false)
  val app: huemul_Columns = new huemul_Columns(StringType,true,"app que registra ventas")
    .setPartitionColumn(3,false, false)
  val producto: huemul_Columns = new huemul_Columns(StringType,true,"producto de la venta")
  val cantidad: huemul_Columns = new huemul_Columns(IntegerType,true,"Cantidad de productos vendidos")

En este ejemplo, se define una tabla con 4 columnas, con 3 columnas particionadas, el ejemplo y comportamiento de cada una de ellas se explica a continuación:

Tenemos un archivo diario de ventas de productos por empresa con la siguiente estructura y datos de ejemplo: archivo 20170501_com01.txt periodo empresa app producto cantidad 20170501 com01 internet chocolate 10 20170501 com01 tienda dulce 2

archivo 20170501_com02.txt periodo empresa app producto cantidad 20170501 com02 internet alfajor 5 20170501 com02 tienda jugo 3

archivo 20170502_com03_4.txt periodo empresa app producto cantidad 20170502 com03 internet flan 8 20170502 com04 tienda platano 6

El objetivo es poder cargar en la tabla estos archivos de forma independiente, debido a que llegan en distintos momentos del día, y se requiere generar un proceso eficiente de carga y consulta.

Por tanto, en nuestra tabla de tipo transaction definiremos tres columnas particionadas

• periodo: es la primera columna particionada, en este caso el objetivo es hacer eficiente los filtros de usuarios por fechas, nunca se borrará esta partición directamente (dropBeforeInsert=false), debido a que cada empresa cargará los datos en momentos distintos del día, y cada archivo solo puede contener un periodo a la vez (onValueperProcess=true, en caso de tener dos periodos es un error)
• empresa: es la segunda columna particionada, el objetivo es permitir cargar los datos transaccionales de forma independiente, y en caso de existir reproceso, se debe eliminar el contenido anterior (dropBeforeInsert=true) y volver a cargar. En nuestro ejemplo, un archivo podría contener más de una empresa (onValueperProcess=false)
• app: es la tercera columna particionada, el objetivo es solo de optimización de subconsultas, debido a que se tienen pocas aplicaciones, pero mucha transaccionalidad, se generan particiones por este criterio. Esta columna permite múltiples valores (onValueperProcess=false)

En el último campo particionado, es indistinto usar el atributo dropBeforeInsert=true, debido a que siempre se borrará la partición específica de los valores de "empresa".

Consideraciones:

• dropBeforeInsert=true solo borra particiones de datos que contiene el archivo que se está cargando: supongamos que tenemos las siguientes particiones:

  • periodo=2017-05-01/empresa=com01/app=internet
  • periodo=2017-05-01/empresa=com01/app=tienda
  • periodo=2017-05-01/empresa=com02/app=internet
  • periodo=2017-05-01/empresa=com02/app=tienda
  • periodo=2017-05-02/empresa=com03/app=internet
  • periodo=2017-05-02/empresa=com04/app=tienda

  En el caso que tengamos un nuevo archivo archivo 20170502_com03_4.txt con los siguientes datos

archivo 20170502_com03_4_v2.txt periodo empresa app producto cantidad 20170502 com03 internet flan 8 20170502 com04 tienda platano 6 20170502 com02 tienda manzana 7

Las acciones sobre las particiones se explican a continuación:

 * periodo=2017-05-01/empresa=com01/app=internet   (sin impacto)
 * periodo=2017-05-01/empresa=com01/app=tienda     (sin impacto)       
 * periodo=2017-05-01/empresa=com02/app=internet   (sin impacto)
 * periodo=2017-05-01/empresa=com02/app=tienda     (sin impacto)
 * periodo=2017-05-02/empresa=com03/app=internet   (elimina antigua, crea nuevamente)
 * periodo=2017-05-02/empresa=com04/app=tienda     (elimina antigua, crea nuevamente)
 * periodo=2017-05-02/empresa=com02/app=tienda     (nueva partición)