Big Objects: Contenedores de Datos – un quiero y quizás puedo de almacenamiento masivo en Salesforce

En la entrada anterior, describía el caso de uso de cómo acceder a una gran volumen de datos desde nuestra ORG via External Objects, y dejaba la puerta abierta a la alternativa a la funcionalidad nativa de Big Objects en Salesforce.

Esta entrada describe qué son, en qué casos de uso pueden aplicarse, cómo crearlos, insertar datos (con Data Loader que parece ser un caso poco documentado) y describir sus características y restricciones, que no son pocas.

¿Qué son los Big Objects?

Big Objects es la implementación de Salesforce de contenedores de datos, para ingesta masiva, rendimiento garantizado de consulta e independientemente del volumen de registros (según la documentación oficial, sea 1 Millón o 1.000 Millones de registros).

Por tanto, como contenedores de datos de gran masivo, inicialmente podrían aplicarse a muchos casos de uso por la gran cantidad de datos que generan las compañías, pero sus limitaciones, restringen el abanico de casos de uso real.

Casos de uso aplicables

Algunos de estos casos de uso son:

  • A mi entender, son un paso para la ingesta de datos procedentes por sistemas heterogéneos sin llegar a ser IoT (Internet of Things)
    • La capacidad de relacionar, transacciones, eventos, lecturas, movimientos, etc., con objetos como Contacts, Accounts, Contracts, etc., nos proporciona una capacidad de análisis muy potente, aunque limitada (como veremos)
  • Data Archiving regulatorio: algunos ámbitos regulatorios, requieren el tener una foto concreta de unos objetos en fechas determinadas.
    • El volcado de la información a un Big Object en la fecha deseada nos permite tener ese snapshot puntual demostrativo
  • En la documentación oficial se describen 3 casos de uso adicionales,  que creo es interesante citar:
    1. Customer 360 Degree and Filtering (un poco rimbobante el nombre para el volcado de interacciones con el cliente)
    2. Field Audit Trail (histórico completo de cambios)
    3. Event Monitoring (Login Forensics and Real-Time Events, enable you to track who is accessing confidential and sensitive data in your org)

Características de los Big Objects

Antes que nada, noticia bomba

A continuación veremos las características más imporantes a mi entender, pero la noticia bomba sobre los Big Objects es que el almacenamiento usado por estos objetos, no computa contra Data Storage.

En la siguiente imagen puedes ver como la interfaz de usuario lo muestra muy claramente:

El Almacenamiento de los Big Objects no se considera Data Storage
El Almacenamiento de los Big Objects no se computa contra la cuota de Data Storage

Esto es muy importante, dado que el coste del almacenamiento de Data Storage en Salesforce es muy elevado comparado con el de cualquier otro Cloud generalista.

Características y Limitaciones muy a tener en cuenta

Para ello, Salesforce toma ciertas decisiones que son cruciales para que podamos usar los Big Objects:

  • La definición de un Big Object solo puede realizarse mediante la Metadata API, no existe interfaz de usuario como para Standard y Custom Objects.
    • Dejaré un ejemplo de su definición, para que directamente desde el Workbench->Migration->Deploy puedas desplegarlo en una ORG de desarrollo.
  • Los campos que se definen en el objeto sólo pueden ser de los tipos: DateTime, Lookup, Number, Text, y LongTextArea.
  • No se permiten filtros ni subqueries, y por tanto, siempre están basadas en un campo Lookup desde el Big Object, a otro objeto, Custom o Standard
  • Además no podemos ejecutar cualquier consulta SOQL, sinó con bastantes restricciones, y debemos abordar el uso de Async SOQL
  • La definición de índices en el objeto es determinante, para poder llevar a cabo  consultas y tener en cuenta como consultaremos el objeto determina claramente como son esos índices (ya que posteriormente no pueden eliminarse)
  • El objeto no aparece como disponible para creación de un Custom Report Type
  • Para mostrar su contenido deberemos programar mediante VisualForce o Lightning, ya que no están disponibles los componentes habituales de visualización como List View, Home Page, etc.
  • Existe un límite de 100 Big Objects por ORG, que también tienen sus Limits, establecidos por la licencia que tengamos
  • No hay soporte para transacciones
  • Se establece la seguridad a nivel de objeto y campo, nada más
  • Para evitar que el rendimiento pueda verse afectado, las funcionalidades de Triggers, Flows, Processes no están permitidos
  • No podemos usar Salesforce1 (recientemente renombrada) para visualizar estos objetos

Por tanto, estos objetos:

  • Son creados y gestionados por el equipo de desarrollo
  • No es una funcionalidad orientada a usuario final, sino al que puede acceder el usuario final, posteriormente a que el equipo de desarrollo lo haya preparado meticulosamente
  • Destinados a ingesta masiva, consulta programática y limitada para asegurar el rendimiento
Las ventajas de los Big Objects pueden verse empañadas por los incovenientes o restricciones que conlleva su uso
Las ventajas de los Big Objects pueden verse empañadas por los inconvenientes o restricciones que conlleva su uso

¿Cómo se definen y despliegan?

Definición

Se realiza la definición mediante los ficheros XML de descripción de Metadata:

  1. Fichero XML de definición de los campos y del índice
  2. Fichero XML con la definición del Permission Set de accesibilidad a los campos

Aquí va el ejemplo que he preparado sobre Ciudadanos de un país, que supuestamente serán millones de registros:

  • Primero el fichero de definición, cuyo nombre es fundamental, en este caso le he llamado: Ciudadanos_Pais__b.object
Definicion Metadata Big Object Ciudadano
Definición Metadata Big Object Ciudadano
  • Y el fichero de Permission Set, denominado: Historial_Ciudadanos.permissionSet
Definición del Permissión Set para el Big Object CiudadanoPermissionSet
Definición del Permission Set

Como es habitual, para su despliegue, debemos organizar las carpetas correspondientes según las convenciones de la Metadata API:

Estructura Ficheros y Directorios para el Despliegue del Big Object Ciudadanos
Estructura Ficheros y Directorios para el Despliegue del Big Object Ciudadanos de un País

El fichero package.xml contiene:

Contenido del fichero package.xml para el despliegue del Big Object Ciudadanos
Contenido del fichero package.xml para el despliegue del Big Object Ciudadanos

A vueltas con el Índice

Importante, la definición del índice no puede ser modificada a posteriori, con lo que si cargamos datos, nos veremos obligados a re-cargarlos, lo que en algunas situaciones, no es aceptable.

Despliegue

Para desplegar el objeto, solo nos queda comprimir la carpeta src, y mediante Workbench o Force.com Migration Tool ejecutar el Deploy.

Despliegue del Big Object mediante Workbench
Despliegue del Big Object mediante Workbench (nada nuevo)

En Setup->Big Objects, ya nos aparece creado:

Detalle del Big Object Ciudadano creado
Detalle del Big Object creado

Como almacenar datos en un Big Object

En la mayoría de casos de uso de Big Object, la ingesta vendrá producida por uno o varios sistemas externos. Salesforce ofrece la ingesta vía:

  • Fichero .csv a través de BULK API (muy importante la primera fila, debe contener el nombre de las columnas)
    • Aunque la función UPSERT no está soportada, si insertamos un registro con el mismo índice varias veces, se produce la actualización del registro (existe un campo que indica el número de re-inserción realizado)
  • Carga mediante APEX: la ingesta (pseudo-UPSERT) mediante el método insertImmediate de la clase Database. El código necesario, consiste en:
    • Crear un nuevo registro de nuestro Big Object
    • Insertar los valores en cada uno de los miembros
    • Ejecutar database.insertImmediate(registro)

Como en esta entrada me centraré en la carga mediante Data Loader por CLI, recomiendo el artículo de ingesta por APEX de Agustina García (Salesforce Big Objects).

Carga mediante Data Loader de 850K registros (para testing)

Llevar a cabo la carga mediante Data Loader por CLI, es sencillo:

  1. Tener una JDK instalada y accesible
  2. Tener en el path el fichero .jar de DataLoader
  3. Generar el fichero de mapping entre los nombres de las columnas del fichero CSV y los nombres de los campos del objeto
  4. Utilizar un log-conf.xml para la generación y rotación de los logs (log4j)
  5. Adecuar el fichero process-conf.xml:
    1. Paths a los diferentes ficheros de carga y log
    2. Modificar las características de la carga, activando BULK API y ajustando el tamaño del Batch
    3. Las credenciales de conexión a la ORG
  6. Ejecutar el fichero .bat suministrado para invocar la clase
    com.salesforce.dataloader.process.ProcessRunner de Data Loader

Aquí van las capturas de pantallas del contenido de estos pasos:

Contenido del fichero 1M.csv con los datos que queremos cargar en el Big Object
Contenido del fichero 1M.csv con los datos que queremos cargar en el Big Object – en este caso el fichero tiene 850.000 filas, solo se muestran unas pocas 😉
Estructura Ficheros y Directorios completa
Estructura Ficheros y Directorios para la carga desde Data Loader en CLI
Contenido del fichero process-conf.xml
Contenido del fichero process-conf.xml
Contenido del fichero log-conf.xml
Contenido del fichero log-conf.xml
Contenido del fichero CargaCiudadanos.sdl con el mapping entre las columna del fichero CSV y los campos del Big Object
Contenido del fichero CargaCiudadanos.sdl con el mapping entre las columna del fichero CSV y los campos del Big Object
Fichero de lostes para la ejecución de la carga
Fichero de lotes para la ejecución de la carga

 Al final de este artículo dejo los enlaces a las descargas de estos ficheros, donde solo tendrás que realizar unos mínimos ajustes para ejecutarlo desde tu ordenador.

Al ejecutar la carga, el proceso finaliza correctamente:

Resultado de la carga de 850k registros en el BigObject
Resultado de la carga de 850k registros en el Big Object Ciudadano

 ¿Cómo accedemos al Big Object?

Como he comentado anteriormente, los Big Objects, no permiten la visualización de sus registros, como un objeto Standard/Custom, con List View en una Tab, etc.

Por tanto, deben construirse consultas SOQL y/o Async SOQL y si se pretende visualizar dentro de la plataforma, deben construirse páginas VisualForce o Lightning.

Veamos cada una de los 2 opciones de construcción de Queries.

Acceso con SOQL

Las consultas que podemos hacer sobre un Big Object, vienen totalmente condicionadas por la definición del índice.

Es decir, para consultar un Big Object, con filtros hay que saber que:

  • Sólo podemos filtrar por los campos especificados en el índice
  • Si tenemos más de 2 campos definidos en el índice, deben siempre incluirse los campos sin saltos entre ellos (no es posible olvidar un campo anterior)
  • No están permitidos los operadores !=, LIKE, NOT IN, EXCLUDES, e INCLUDES
  • Pueden incluirse los campos de sistema: CreatedById, CreatedDate, y SystemModstamp

Hay que tener presente la naturaleza síncrona y bloqueante de la ejecución de un SOQL. Es decir, la utilización de una SOQL, está destinada a mostrar los resultados a un usuario que está esperando para obtenerlos, por ejemplo vía una VisualForce, o por ejemplo en la ejecución de un snippet APEX.

El tiempo de respuesta y recuperación de la activación del thread se verá penalizado por el volumen que estemos solicitando, llegando incluso, a provocar un Timeout.

A continuación se muestran algunos ejemplos de Queries (correctas/incorrectas) con el Big Object definido anteriormente:

Definición del Índice de Big Object Ciudadano
Query correcta donde se utiliza un solo campo del índice
Query correcta dónde se utiliza los 2 campos definidos en el índice pero en orden cambiado
Query incorrecta dado que se pretende filtrar por un campo que no está definido en el índice
Query incorrecta dado que se pretende utilizar un operador “LIKE” que no está permitido

Acceso con Async SOQL

Async SOQL es la ejecución de una consulta en background, en la que no se bloquea la ejecución esperando el resultado de la consulta.

Sus características principales son:

  • Se pueden incluir: entity data, standard objects, custom objects, y big objects
  • Es una API REST (por tanto invocable exteriormente)
  • No está sujeta a los límites de SOQL e incluso aporta capacidades superiores
  • Los resultados que se obtengan de la Query, deben ser redirigidos a un objeto creado anteriormente
  • Los operadores=, !=, <, <=, >, >=, LIKE,AN y OR están permitidos, así como los formatos de fecha de tipo ExcelYYYY-MM-DD y YYYY-MM-DDThh:mm:ss-hh:mm

Por tanto, es el mecanismo idóneo para consultar millones o centenares de millones de registros.

A continuación se muestra un caso de uso que aparece en la documentación oficial, con un diagrama muy clarificador:

Esquema de un Caso de Uso de SOQL con Big Object
Esquema de un Caso de Uso de SOQL con Big Object procedente de la documentación oficial

Para demostrar su uso: supongamos que se desean obtener todos los ciudadanos nacidos en mi mismo año 1973, siguiendo el ejemplo del artículo.

Bajo esta petición debe:

  1. Crearse un objeto receptor de los resultados de la query que ejecutemos
  2. Construirse una Query mediante Async SOQL (lo haremos mediante el Workbench – también puede realizar por supuesto con cualquier cliente REST, en la documentación se explica tanto el verbo HTTP como el Payload asociado)

Notar que si el índice no tuviera en primer campo, el campo Fecha_Nacimiento__c, esta Query no la podríamos llevar a cabo, ya que una de las restricciones que tienen las consultas en Big Objects, es que los campos filtrados respeten el orden de los campos definidos en el objeto (ya se ha mencionado anteriormente, pero es crucial).

Crear el objeto receptor de los resultados

Es un objeto Custom completamente habitual:

DefinicionMetadataObjetoNacidos1973
Definición del Objeto Nacidos1973 que recibirá los resultados de la Async SOQL

Definición de la Query Async SOQL (mediante Workbench)

Consta de 2 pasos – la Selección de campos del Big Object y aplicación de filtros (atención al uso del operador LIKE):

Definición de la Async SOQL
Definición de la Async SOQL – en el siguiente paso mostraremos el objeto receptor de los resultados. Notar que al utilizar Async SOQL podemos utilizar el comando LIKE, que con SOQL simple no era posible

El segundo, definir el objeto receptor de los resultados y el mapping de los campos entre objeto origen y destino:

Definición del Mapping entre Objetos

Los resultados quedan almacenados en el objeto Nacidos1973__c y son explotables mediante los mecanismos habituales de visualización.

Conclusiones

Después del largo artículo y habiendo entendido el funcionamiento de los Big Objects, y valorando sus funcionalidades y limitaciones, queda claro que los casos de uso de esta característica de Salesforce, aún siendo muy potente, son limitados.

Su gran baza, es que el almacenamiento destinado a estos Objetos, no computan contra el Data ni File Storage de nuestra ORG (cuyo coste no es nada despreciable) y por tanto cuando lo podamos aplicar es una funcionalidad muy interesante.

Finalmente, destacar nuevamente, que el acceso mediante SOQL tanto síncrono como en modo Async, tiene limitaciones que hay que conocer y que en cualquiera de los 2, la definición del índice nos limitará el acceso al objeto.

Valorar correctamente las posibilidades y los condicionantes de los Big Objects, es crucial para usarlos
Valorar correctamente las posibilidades y los condicionantes de los Big Objects, es crucial para incorporarlos en nuestra arquitectura

Código disponible

Todo el código queda disponible como Repo Público en mi cuenta Bitbucket en: https://bitbucket.org/estevegraells/forcegraells-bigobjects

Enlaces interesantes

 

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s