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. Disponer de esta información puede ahorrar problemas a los usuarios de tu ORG, espero que te sea de ayuda .

Lo he desarrollado bajo los siguientes criterios:

1. Ejecutable en ORGs tanto pequeñas como de gran tamaño.
2. Utilizo mecanismos 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. Escribir código lo más comprensible posible (write code for humans).
4. Cumplir mejoras prácticas y 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 ni ningún objeto.
6. Minimizar la creación de objetos auxiliares (sólo he creado 3 objetos, que requieren de unos pocos registros).

Es completamente libre, la puedes copiar, estudiar, modificar, utilizar dónde y cuándo sea.

En este artículo voy a explicar su funcionamiento, como está organizada (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 campos 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 debería 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 busca este registro con el flag a TRUE, para aplicar la configuración que indique.

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 que puedas anticiparte antes de tener el problema.
  Te recomiendo pues, usar valores inferiores y así averiguar si tienes objetos con campos que puedan tender a tener Data Skew.
• 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 de nosotros, 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, para 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 que sólo se analicen ciertos objetos Custom. Nuevamente, 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 no vale la pena comprobar (createdbyid, id, insertedbyid, isdeleted, lastmodifieddate etc.).
  Puedes utilizar esta lista para indicar que no compruebe ciertos campos (en el código fuente, tienes la definición de los que yo creo que deben obviarse con total seguridad, pero compruébala para ampliarla o reducirla según creas).
• IsActive__c: indica si este 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 haber 1 configuración activa, pero tener tantas como desees.
• 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 inmensa, 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. 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ún 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 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 (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 proceso Batch, y obtiene 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 sus relaciones. Si el número de registros del objeto no es como mínimo el Data Skew Limit, se descarta, ya que 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 tienen 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 depositan trazas de ejecución en el objeto Process_Log__c, que puedes consultar.

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 hasta quizás 1′ en una 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 la Cardinality 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, y si somos capaces de anticiparnos, podremos ahorrar costes, dolores de cabeza y mantendrá más sana nuestra ORG.

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.

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.

Espero que sea de ayuda.

Anuncio publicitario