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:
- Customer 360 Degree and Filtering (un poco rimbobante el nombre para el volcado de interacciones con el cliente)
-
Field Audit Trail (histórico completo de cambios)
-
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:
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
¿Cómo se definen y despliegan?
Definición
Se realiza la definición mediante los ficheros XML de descripción de Metadata:
- Fichero XML de definición de los campos y del índice
- 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
- Y el fichero de Permission Set, denominado: Historial_Ciudadanos.permissionSet
Como es habitual, para su despliegue, debemos organizar las carpetas correspondientes según las convenciones de la Metadata API:
El fichero package.xml contiene:
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.
En Setup->Big Objects, ya nos aparece 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:
- Tener una JDK instalada y accesible
- Tener en el path el fichero .jar de DataLoader
- Generar el fichero de mapping entre los nombres de las columnas del fichero CSV y los nombres de los campos del objeto
- Utilizar un log-conf.xml para la generación y rotación de los logs (log4j)
- Adecuar el fichero process-conf.xml:
- Paths a los diferentes ficheros de carga y log
- Modificar las características de la carga, activando BULK API y ajustando el tamaño del Batch
- Las credenciales de conexión a la ORG
- 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:
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:
¿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:
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:
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:
- Crearse un objeto receptor de los resultados de la query que ejecutemos
- 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:
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):
El segundo, definir el objeto receptor de los resultados y el mapping de los campos entre objeto origen y destino:
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.
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
- Documentación oficial sobre Salesforce Big Objects
- Trailhead Module de Big Objects
- Video en Youtube: Async SOQL – Big Data Computing for Force.com
- Entrada en el blog de Agustina García sobre Big Objects
Salesforce FOR ARTISANS 
Deja una respuesta