Data Skew Detector: aplicación para detectar Data Skew en tu ORG

En la entrada anterior describí que era la anomalía en los datos llamada Data Skew en Salesforce. Y aunque ese es el primer paso, lo realmente útil, en nuestro día a día, es poderlo detectar con antelación.

No conozco qué Salesforce ofrezca, ninguna utilidad para la localización de Data Skew, aunque anticiparnos a qué suceda en nuestra ORG, puede suponer ahorrarnos muchos dolores de cabeza.

Por ello, he desarrollado una utilidad en APEX que permite analizar tu ORG, y encontrar todos los campos con Data Skew. Disponibilizar esta información a tus compañeros, a tus usuarios, a tus administradores, o a tu cliente, puede suponer ahorrar problemas futuros, y ahorrar costes al proyecto.

Lo he desarrollado bajo los siguientes criterios:

  1. Ejecutable en ORGs tanto pequeñas como en otras de gran tamaño.
  2. Utilizando mecanismos de Batchable, para no afectar nunca a los procesos online y aprovechar las mejores capacidades de esta modalidad de ejecución (límites, colas, etc.).
  3. Obtener el mejor rendimiento posible, pero sin perjudicar la comprensión del código.
  4. Escribir código lo más comprensible posible (write code for humans) dentro de mis conocimientos y cumplir las reglas de PMD
  5. No realizar ninguna modificación en los objetos existentes de la ORG, con lo que no debes preocuparte, de que se modifique ningún dato.
  6. Crear los menos objetos y datos posibles (solo he creado 3 objetos como veremos que requieren de unos pocos registros para mostrar los resultados).

Es completamente libre, lo puedes coger, modificar, utilizar dónde sea y si lo encuentras útil, pues divulgarlo.

En este artículo voy a explicar su funcionamiento, como está organizado (código, objetos, etc.) y cómo modificar ciertos parámetros para que lo adaptes a tus necesidades.

Si tienes comentarios/mejoras/correcciones encantado de conocerlas.

¿Qué es?

Fácil, sabiendo las anomalías que suponen Data Skew, esta utilidad investiga todos los objetos de la ORG*, en búsqueda de valores con Data Skew.

Tan sencillo como eso, *tu indicas los objetos que quieres (hay ciertas convenciones) y se analizarán sus campos relaciones. Si alguno de los valores en esos campos supera el valor que hayas indicado como Data Skew Limit (típicamente 10.000) se registra y queda almacenada la información en un objeto, para que puedas crear informes y transmitirlo.

Componentes

Custom Metadata Type (CMT)

Este objeto permite definir los parámetros de ejecución del proceso. Dado que pensé que podría ser interesante tener varias configuraciones de ejecución distintas, utilicé un CMT.

Idealmente solo un registro de este CMT debería tener el valor de Active en el campo Is_Active__c, ya que el código de la aplicación, intenta encontrar este registro con el flan a TRUE, para obtener la configuración que debe aplicar.

Definición del Custom Metadata para definición de los parámetros de Ejecución

Te explico los parámetros definidos:

  • Data_Skew_Limit__c: por defecto y tal y como indica la documentación de  Salesforce este valor debería ser 10.000. Pero pensé, que puede ser interesante modificarlo, para anticipar cuando podríamos tener este problema. Te recomiendo pues, que aprovechando la versatilidad del Custom Metadata Type, definas varios registros con valores con 7.000, 8.000, 9.000 registros y así averiguar si tienes objetos con campos que puedan tender a tener Data Skew, y comunicarlo a tus  compañeros/administradores/clientes y así evitar el problema a posteriori.
  • Standard_Object_To_Check_List__c: dado que cada ORG puede utilizar objetos Standard distintos, esta lista de nombres de objetos separada por ‘;’ permite que cada uno indique los objetos Standard que desea analizar. En mi opinión lo mejor es utilizar el listado de Company Settings-> Company Information, seleccionar View de la opción  Used Data Space, y obtener el listado de los objetos que tienen más de X miles de registros. Estos son  los objetos sospechosos para comprobar Data Skew.
  • Check_Custom_Objects_for_Data_Skew__c: por defecto se comprueban todos los objetos Custom de la ORG. Aunque no te lo recomiendo, con esta opción puedes desactivar que no se analice ninguno de ellos.
  • Custom_Object_List_To_avoid_to_check__c: como he comentado en el campo anterior, por defecto se comprueban todos los objetos Custom de la ORG. Con esta opción, puedes indicar sobre qué objetos no deseas el análisis. Es una lista separada por ‘;’ de nombres de objetos Custom.
  • Field_List_Not_to_be_checked__c: no es interesante ni útil, comprobar absolutamente todos los campos, existen campos Standard que vale la pena comprobar (createdbyid, id, insertedbyid, isdeleted, lastmodifieddate etc.).
    Puedes adaptar esta lista separada por ‘;’ para indicar a la aplicación que no compruebe estos campos (en el código fuente, tienes la definición de los que yo creo que deben obviarse como mínimo).
  • IsActive__c: indica si esta es el registro del CMT de configuración que la aplicación debe utilizar, para leer los parámetros de ejecución. Sólo debe haver 1 una configuración activa, pero puedes tener tantas como desees y así variar el comportamiento del detector.
  • Reload_Count_Row_and_Relations_Table__c: el detector tiene una etapa donde cuenta los registros de todos los objetos y busca sus relaciones. Si trabajas en una ORG immensa, y después de ejecutar un primer análisis, consideras que no es necesario volver a ejecutar esta etapa porque no ha cambiado cambios sustanciales, puedes indicar este parámetro a FALSE. En mi experiencia, en la mayoría de ORGs esto no es necesario, solo requiere de pocos segundos de ejecución, por lo que no te recomiendo modificar el valor por defecto (TRUE) y trabajar con el estado real de los datos en la ORG.

Como puedes ver en la siguiente imagen, yo me he definido diferentes configuraciones para probar diferentes escenarios:

Varias configuraciones definidas pero solo 1 activa para su ejecución

Objetos definidos

He definido 3 objetos custom que registran los pasos de la ejecución (ciertamente podría haber utilizado uno solo, pero creo que es más comprensible con estos 3):

    1. Data_Skew_Object__c: en este objeto se almacenan todos los resultados obtenidos de la fase 1 del Detector, es decir, el recuento de registros de cada objeto y la introspección para recabar sus relaciones con otros objetos.
    2. Data_Skew_Field__c: en este objeto se registran los resultados finales, donde podemos ver, cada objeto, todos sus campos, y para cada uno de esos campos, el resultado de analizar su Data Skew.
    3. Process_Log__c: contiene las trazas que va produciendo el proceso. Puede ser útil para detectar algúun comportamiento anómalo o situación no contemplada y para comprender el funcionamiento de la aplicación.

A continuación, te muestro para cada objeto, su definición y un ejemplo de como se ve en mi ORG de Desarrollo personal:

Data_Skew_Object_c

Data_Skew_Field_c

Process_Log__c

Clases Apex

Pues ya solo nos queda ver como está estructurado el código, que es realmente simple:

De la imagen capturada de mi IDE, puedes ver que utilizo 6 clases:

  • DS_Execution_Params: realiza una lectura de los parámetros de ejecución interrogando el registro Activo del CMT definido. Esta clase me permite realizar una sola consulta, y disponer de los valores para el resto de clases durante la ejecución del contexto (utilizando variables Static).
  • DS_Finder: es la clase entrada de ejecución, la que instanciamos y dónde se inicia por tanto la ejecución. Invoca a 2 funciones: la primera, que mediante introspección de Apex, obtiene el listado de todos los objetos Custom y  Standard que deseas analizar, y la segunda, que invoca un proceso Batch que obtiene para cada objeto su número de registros.
  • DS_Measure_Objects: es la clase Batchable que cuenta los registros de los objetos. Al finalizar, mediante Batch Chaining, invoca la clase DS_Relations_Object_Finder.
  • DS_Relations_Object_Finder: para todos los objetos que tienen suficiente volumen, se ejecuta otro Batch, para obtener todas sus relaciones, que son, los campos donde se produce las anomalías de Data Skew. Nuevamente, y mediante Batch Chaining se invoca a DS_Check_Relation_Fields.
  • DS_Check_Relation_Fields: realiza el análisis de Data Skew de los campos de relaciones identificados en la etapa anterior y almacena los resultados.

¿Cómo se ejecuta?

El procedimiento es muy simple:

  1. Se cargan las definiciones del CMT marcado como Active.
  2. Proceso 1: para los Standard y Custom se calcula el número de registros de cada objeto y las relaciones que tiene cada objeto. Si el número de registros del objeto no es como mínimo el Data Skew Limit, ya se descarta, no es posible que tenga Data Skew. Esta información se almacena en el objeto Data_Skew_Object__c.
  3. Proceso 2: Para los objetos que tiene suficiente volumen de registros y tienen relaciones a analizar, se lleva a cabo el análisis de cada relación, para detectar los valores que tengan Data Skew. La información y los resultados obtenidos se almacenan en Data_Skew_Field__c.
  4. Puedes consultar este objeto (Data_Skew_Field__c)  para obtener el detalle completo de cada objeto, campo y valores afectados, con el número de registros exacto que provocan Data Skew. Puedes crear informes a partir de este objeto, para compartir con quien sea necesario.
  5. Durante el proceso se van dejando trazas de ejecución en el objeto Process_Log__c, que puedes consultar durante el proceso o al final.

Por tanto existen 2 procesos principales, que  a nivel técnico son 2 procesos Batchable. La clase principal DS_Finder(), la he definido como un proceso Schedulable, para que puedas planificar su ejecución. Para lanzarlo como Anonymous Apex tan solo ejecútalo mediante la instanciación de la clase mediante: new DS_Finder().

La duración de este proceso es de varios segundos hata quizás 1′ en ORG masiva de objetos y gran volumen de datos. En cualquier caso, puedes desplegar y lanzar en un Full Sandbox para evaluarlo en tu caso concreto y así no afectar a tu ORG productiva.

Posibles mejoras para ORGs con grandes Volúmenes de datos

Creación de índices Custom

En ORGs con grandes volúmenes de datos, las queries realizadas por la aplicación, en algunos campos podría ser que no tuvieran un valor inferior a 1 en “selectivity“, por lo que la query tarde más de lo esperado.
En tal caso, puedes crear índices custom temporales sobre esos campos, solo en los objetos más voluminosos, y obtendrás una mejora del rendimiento, ya que el optimizador de SOQL obtendrás valores de selectivity aceptables(Cost<1).
Posteriormente puedes eliminar esos índices, y volver al estado original.

Utilización de Query Plan mediante API REST para obtener el Count de las tablas de datos

La aplicación utiliza Database.countQuery() para obtener el número de registros de las tablas de datos. En ORGs con grandes volúmenes de datos, estas queries pueden consumir algo más de pocos segundos. Alternativamente a este procedimiento, existe la posibilidad de consumir la API REST desde Apex consultando el Query Plan.
El resultado de Query Plan retorna un parámetro que es sobjectCardinality que contiene un valor aproximado del número de registros del objeto.

Resultados y Conclusiones

La detección precoz de Data Skew en nuestra ORG, es una tarea compleja para la que Salesforce no proporciona ninguna utilidad, que yo conozca, por lo que me pareció útil crear ésta.

Como comentaba durante el artículo, ser capaces de detectar con antelación estas situaciones, ahorrará costes, mejorará la comprensión de como Salesforce gestiona los datos, y nos ahorrará problema en Producción en un futuro.

En esta imagen he realizado una ejecución en mi ORG personal de desarrollo para detectar registros con un parámetro de Data Skew Limit = 10. En ORGs con volumetrías productivas, este valor debe ser alrededor de 10.000 para obtener los campos que pronto provocarán Data Skew ó que ya lo están provocando.

Todo el código lo tienes disponible para que lo utilices como desees y pueda serte de ayuda a tí, a tus compañeros y/o a tus clientes.

Repositorio de Código disponible

El código completo de esta aplicación está disponible aquí. Una vez desplegado en tu ORG, seguramente deberás ajustar las Views y Layouts para mostrar los campos como quieras, así como el profile y permission sets que tu desees.

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 )

Conectando a %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.