Los sistemas de Big Data y análisis están emergiendo rápidamente como uno de los sistemas críticos en el entorno de TI de una organización. Sin embargo, con cantidades tan enormes de datos surgen desafíos de rendimiento. Si los sistemas de Big Data no se pueden utilizar para tomar o predecir decisiones comerciales críticas, o proporcionar información sobre los valores comerciales ocultos bajo una gran cantidad de datos en el momento adecuado, entonces estos sistemas pierden su relevancia. Este artículo habla sobre algunas de las consideraciones críticas de rendimiento de manera tecnológicamente agnóstica. Habla sobre algunas técnicas o pautas que se pueden utilizar durante diferentes fases de un sistema de Big Data (es decir, extracción de datos, limpieza de datos, procesamiento, almacenamiento y presentación). Esto debería actuar como pautas genéricas que cualquier profesional de Big Data puede utilizar para asegurarse de que el sistema final cumpla con los requisitos de rendimiento del sistema.

¿Qué es Big Data?

Big Data es uno de los términos más comunes en el mundo de la tecnología de la información en estos días. Aunque se utilizan diferentes términos y definiciones para explicar Big Data, en principio, todos concluyen en el mismo punto: con la generación de grandes cantidades de datos, tanto de fuentes estructuradas como no estructuradas, los enfoques tradicionales para manejar y procesar estos datos no son suficientes. Los sistemas de Big Data generalmente se consideran que tienen cinco características principales de los datos, comúnmente llamadas las 5 V del dato. Estas son Volumen, Variedad, Velocidad, Veracidad y Valor.

El volumen alto se puede definir como “cuando la capacidad de procesamiento de la tecnología y los procesos de captura de datos nativos es insuficiente para proporcionar valor comercial a casos de uso posteriores. El volumen alto también ocurre cuando la tecnología existente fue diseñada específicamente para abordar tales volúmenes, una solución exitosa de Big Data”. Estos datos de alto volumen no provienen solo de fuentes tradicionales, sino de fuentes nuevas y diversas como sensores, dispositivos, registros, automóviles y muchas otras fuentes variadas. Estas fuentes pueden enviar datos estructurados y no estructurados.

La variedad de datos puede definirse como “activos de información altamente variables que incluyen una mezcla de múltiples formas, tipos y estructuras sin tener en cuenta esa estructura en el momento de la escritura o lectura. Y los datos previamente subutilizados, que se habilitan para casos de uso en nuevas formas innovadoras de procesamiento, también representan variabilidad”.

La velocidad se puede definir como la velocidad a la que llegan los datos de diferentes fuentes. Los datos de dispositivos, sensores y otros flujos organizados y no organizados están entrando constantemente en los sistemas de TI. Con esto, también aumenta la necesidad de análisis e interpretación en tiempo real de estos datos. Según Gartner, la alta velocidad se puede definir como “una tasa más alta de llegada y/o consumo de datos, pero se centra en la velocidad variable dentro de un conjunto de datos o las tasas cambiantes de llegada de datos entre dos o más conjuntos de datos”.

La veracidad, o la corrección y precisión, es otro aspecto de los datos. Para tomar decisiones comerciales correctas, es imperativo que los datos en los que se realiza todo el análisis sean correctos y precisos. Los sistemas de Big Data pueden proporcionar un gran valor comercial. Industrias y organizaciones como telecomunicaciones, finanzas, comercio electrónico, redes sociales, colaboración y muchas más, ven sus datos como una gran oportunidad comercial. Pueden obtener información sobre el comportamiento del usuario y proporcionar recomendaciones de productos relevantes, generar alertas para posibles transacciones fraudulentas, y mucho más. Al igual que cualquier sistema de TI, el rendimiento es fundamental para que un sistema de Big Data tenga éxito. Cómo hacer que el rendimiento sea una parte integral de un sistema de Big Data es la idea básica de este artículo.

Bloques de construcción de un sistema de Big Data

Un sistema de Big Data se compone de varios bloques funcionales que proporcionan al sistema la capacidad de adquirir datos de diversas fuentes, realizar preprocesamiento (limpieza, validación, etc.) en estos datos, almacenar los datos, realizar procesamiento y análisis en estos datos almacenados (realizar análisis predictivos, generar recomendaciones para usos en línea, etc.) y, finalmente, presentar y visualizar los resultados resumidos y agregados. Los siguientes componentes de alto nivel de un sistema de Big Data se muestran en la siguiente figura:

En la siguiente sección se describen brevemente cada uno de los componentes mostrados en la Figura 1.

Fuentes de datos diversas

En el ecosistema de TI actual, es necesario analizar y actuar sobre datos de múltiples fuentes. Estas fuentes pueden ser desde aplicaciones web en línea, cargas por lotes o feeds, datos de transmisión en vivo, datos de sensores, etc. Los datos de estas fuentes pueden venir en diferentes formatos y utilizando diferentes protocolos. Por ejemplo, una aplicación web en línea puede enviar datos en formato SOAP/XML a través de HTTP, el feed puede venir en formato de archivo CSV, y los dispositivos pueden comunicarse a través del protocolo MQTT. Como el rendimiento de estos sistemas individuales no está bajo el control de un sistema de Big Data y a menudo estos sistemas son aplicaciones externas, propiedad de proveedores o equipos externos, el resto del artículo no entrará en detalles sobre el rendimiento de estos sistemas.

Adquisición de datos

Los datos de diversas fuentes deben adquirirse antes de que pueda ocurrir cualquier procesamiento. Esto implica el análisis, validación, limpieza, transformación, eliminación de duplicados y almacenamiento en un formato adecuado en algún tipo de almacenamiento persistente. En las siguientes secciones, este artículo resaltará algunas de las consideraciones que deben tenerse en cuenta para lograr un componente de adquisición de datos de alto rendimiento en un sistema de Big Data. Tenga en cuenta que este artículo no discutirá las diferentes técnicas utilizadas para la adquisición de datos.

Almacenamiento

Una vez que se adquieren, limpian y transforman los datos al formato requerido, es necesario almacenarlos en algún tipo de almacenamiento donde se puedan realizar funciones de procesamiento y análisis. En las siguientes secciones, este artículo presentará algunas de las mejores prácticas para el almacenamiento (tanto lógico como físico) para lograr un mejor rendimiento en un sistema de Big Data. También se discutirá el impacto de los requisitos de seguridad en el rendimiento al final del artículo.

Procesamiento y análisis de datos

Algunos de los pasos involucrados en esta etapa son la desnormalización de los datos limpios, la realización de algún tipo de correlación entre diferentes conjuntos de datos, la agregación de los resultados en función de intervalos de tiempo predefinidos, la realización de algoritmos de aprendizaje automático, análisis predictivos, etc. En las siguientes secciones, este artículo presentará algunas de las mejores prácticas para llevar a cabo el procesamiento y análisis de datos para lograr un mejor rendimiento en un sistema de Big Data.

Visualización y presentación

El último paso de un flujo de Big Data es ver la salida de diferentes funciones analíticas. Este paso implica leer los resultados agregados precalculados (u otras entidades similares) y presentarlos en forma de tablas, gráficos y otros métodos amigables para el usuario, que faciliten la interpretación y comprensión de los resultados.

Consideraciones de rendimiento para la adquisición de datos

La adquisición de datos es el paso en el que los datos de diversas fuentes ingresan al sistema de Big Data. El rendimiento de este componente afecta directamente la cantidad de datos que un sistema de Big Data puede recibir en un momento dado. El proceso de adquisición de datos puede variar según los requisitos exactos del sistema, pero algunos de los pasos comúnmente realizados en esto son: analizar los datos entrantes, realizar la validación necesaria, limpiar los datos (eliminar duplicados), transformar los datos limpios en un formato requerido y almacenarlos en algún tipo de almacenamiento persistente. Algunos de los pasos lógicos involucrados en el proceso de adquisición de datos se muestran a continuación en esta figura:

A continuación se presentan algunas consideraciones de rendimiento que deben tenerse en cuenta para garantizar un componente de adquisición de datos de alto rendimiento:

• La transferencia de datos desde diversas fuentes debe ser asíncrona. Una forma de lograr esto es utilizar transferencias de alimentación de archivos en intervalos de tiempo regulares o mediante el uso de algún middleware orientado a mensajes (MoM) para lo mismo. Esto permitirá que los datos de múltiples fuentes se bombeen a una velocidad mucho más rápida de lo que el sistema de Big Data puede procesar en un momento dado. Tener una transferencia de datos asíncrona permite el desacoplamiento entre las fuentes de datos y el sistema de Big Data. Ahora, la infraestructura de Big Data puede escalar de forma independiente. Las ráfagas de tráfico de una aplicación en línea no sobrecargarán el entorno de Big Data.
• Si los datos se extraen directamente de una base de datos externa, asegúrese de extraer los datos en bloque. Si los datos se analizan desde un archivo de alimentación, asegúrese de utilizar analizadores apropiados. Por ejemplo, si se lee desde un archivo XML, existen diferentes analizadores como JDOM, SAX, DOM, etc. De manera similar, para CSV, JSON y otros formatos similares, hay múltiples analizadores y APIs disponibles. Elija el que cumpla con los requisitos dados con un mejor rendimiento.
• Siempre es preferible utilizar soluciones de validación incorporadas o listas para usar. La mayoría de los flujos de trabajo de análisis/validaciones se ejecutan generalmente en un entorno de servidor (ESB/AppServer). Estos tienen validadores estándar disponibles para casi todos los escenarios. En la mayoría de las circunstancias, estos generalmente funcionarán mucho más rápido que cualquier validador personalizado que pueda desarrollar. De manera similar, si el formato de los datos es XML, es preferible utilizar esquemas XML (XSD) para las validaciones. Incluso en escenarios donde los analizadores o validaciones, etc. no se ejecutan en un entorno de servidor, sino en scripts personalizados desarrollados utilizando lenguajes de alto nivel como Java, es preferible utilizar bibliotecas y marcos incorporados. En la mayoría de las circunstancias, estos generalmente funcionarán mucho más rápido que cualquier código personalizado que pueda desarrollar.
• Identifique y filtre los datos no válidos lo antes posible, para que todo el procesamiento posterior a las validaciones funcione solo en un conjunto legítimo de datos. La mayoría de los sistemas desean que los datos no válidos se almacenen en algunas tablas de error. Tenga esto en cuenta al dimensionar la base de datos y el almacenamiento.
• Si los datos fuente válidos necesitan ser limpiados, por ejemplo, eliminando información que no es necesaria, haciendo que el código y las descripciones sean consistentes en los datos recibidos de múltiples sistemas, etc., asegúrese de que esta acción se realice en un conjunto de datos más grande de una sola vez, en lugar de hacerlo registro por registro o en fragmentos más pequeños. Generalmente implica hacer referencia a algunas tablas externas o diccionarios de datos para leer alguna información estática. Al utilizar la información estática recuperada una vez, para limpiar el conjunto de datos en bloque, se puede mejorar el rendimiento.
• Para eliminar los registros duplicados, es muy importante determinar qué constituye un registro único. En la mayoría de los casos, es posible que se deba agregar un identificador único como una marca de tiempo o un ID a los datos entrantes. Generalmente, cada registro individual debe actualizarse con este campo único, asegúrese de que cada generación de este ID único no sea muy complicada, de lo contrario, afectará negativamente el rendimiento.
• Los datos recibidos de múltiples fuentes pueden estar o no en el mismo formato. A veces, es necesario transformar los datos recibidos en múltiples formatos para usar algún formato común o un conjunto de formatos comunes. Al igual que el análisis, se recomienda utilizar transformadores disponibles o incorporados, en lugar de desarrollar algo desde cero. La transformación es generalmente el paso más complejo, que consume más tiempo y recursos del proceso de adquisición de datos. Por lo tanto, asegúrese de lograr la mayor paralelización posible en esto.
• Una vez que se completan todas las actividades anteriores de adquisición de datos, los datos transformados generalmente se almacenan en algún tipo de almacenamiento persistente, para que más tarde se puedan realizar procesos analíticos, resúmenes, agregaciones, etc. en estos datos. Existen múltiples soluciones tecnológicas para manejar este almacenamiento persistente (RDBMS, NoSQL, sistemas de archivos distribuidos como Hadoop, etc.). Evalúe cuidadosamente y elija una solución que cumpla con los requisitos. Dependiendo de los requisitos, es posible que deba elegir una combinación de diferentes soluciones.

Consideraciones de rendimiento para el almacenamiento

Una vez que se completan todos los pasos necesarios de adquisición de datos, los datos deben almacenarse en algún tipo de almacenamiento persistente. En esta sección, se discutirán algunas pautas importantes de rendimiento para almacenar los datos. Se discutirán tanto las opciones de almacenamiento lógico (y modelo) como las de almacenamiento físico. Tenga en cuenta que estas pautas deben considerarse para todos los datos, ya sean datos en bruto o datos de salida final de algunas funciones analíticas como datos agregados precalculados, etc.

• Siempre considere el nivel de normalización o desnormalización que elija. La forma en que modele sus datos tiene un impacto directo en el rendimiento, así como en aspectos como la redundancia de datos, la capacidad de almacenamiento en disco, etc. Para algunos escenarios, como simplemente volcar los feeds de origen en una base de datos, es posible que desee almacenar los datos en bruto iniciales tal como vienen de los sistemas de origen, para algunos escenarios, como realizar algunos cálculos analíticos como agregación, es posible que desee que los datos estén en formas desnormalizadas. La mayoría de los sistemas de Big Data tendrán bases de datos NoSQL en lugar de RDBMS para almacenar y procesar grandes cantidades de datos. Diferentes bases de datos NoSQL tienen diferentes capacidades, algunas son buenas para lecturas más rápidas, otras son buenas para inserciones, actualizaciones, etc. más rápidas. Algunas bases de datos son orientadas a filas, otras son orientadas a columnas, etc. Evalúe estas bases de datos en función de sus requisitos exactos (por ejemplo, si necesita un mejor rendimiento de lectura o mejor escritura) y luego elija. De manera similar, cada una de estas bases de datos tiene propiedades de configuración que controlan diferentes aspectos de cómo funcionan estas bases de datos. Algunas de estas propiedades son el nivel de replicación, el nivel de consistencia, etc. Algunas de estas propiedades tienen un impacto directo en el rendimiento de la base de datos. Tenga esto en cuenta antes de finalizar cualquier estrategia de este tipo.
• El nivel de compactación, el tamaño de los búferes, los tiempos de espera y la memoria caché son algunas de las propiedades de diferentes bases de datos NoSQL que pueden afectar el rendimiento. El particionamiento y la fragmentación son otra funcionalidad muy importante de estas bases de datos. La forma en que se configura el particionamiento puede tener un impacto drástico en el rendimiento del sistema. Elija las claves de particionamiento y fragmentación cuidadosamente. No todas las bases de datos NoSQL tienen soporte incorporado para diferentes técnicas como uniones, clasificaciones, agregaciones, filtros, índices, etc. Si necesita utilizar estas funciones de manera extensiva, será mejor utilizar soluciones que tengan estas funciones incorporadas. En general, las características incorporadas brindarán un mejor rendimiento que cualquier solución personalizada. Las bases de datos NoSQL vienen con compresores, códecs y transformadores incorporados. Si se pueden utilizar para cumplir con algunos de los requisitos, es preferible utilizarlos. Estos pueden realizar diversas tareas como conversiones de formato, compresión de datos, etc. Esto no solo hará que el procesamiento posterior sea más rápido, sino que también reducirá la transferencia de red. Muchas bases de datos NoSQL admiten múltiples tipos de sistemas de archivos para ser utilizados como su medio de almacenamiento. Estos incluyen sistemas de archivos locales, sistemas de archivos distribuidos e incluso soluciones de almacenamiento basadas en la nube. A menos que la interoperabilidad sea el criterio más importante, intente utilizar un sistema de archivos que sea nativo para el NoSQL (por ejemplo, HDFS para HBase). Esto se debe a que, si se utiliza algún sistema de archivos/formato externo, necesitará códecs/transformadores para realizar la conversión necesaria al leer/escribir los datos. Esto agregará otra capa en el proceso general de lectura/escritura y causará un procesamiento adicional. Los modelos de datos de un sistema de Big Data generalmente se modelan en función de los casos de uso que se espera que aborden estos sistemas. Por ejemplo, no es raro que un sistema de Big Data tenga tablas de salida final que tengan una estructura que represente de cerca el formato del informe de salida, que se mostrará mediante una herramienta de capa de presentación. En la mayoría de los casos, esto puede tener un gran impacto en cómo un usuario final percibe el rendimiento de este sistema. Considere un escenario en el que, al enviar una solicitud para ver los datos agregados de la semana pasada, la lógica comercial intenta agregar datos semanales a partir de los datos de salida, que tenían resultados de agregaciones diarias u horarias. Esto puede ser una operación tremendamente lenta si los datos son demasiado grandes.
• Algunos marcos de procesamiento de datos dividen los datos a procesar en fragmentos más pequeños. Estos fragmentos más pequeños de datos se procesan de forma independiente mediante trabajos individuales. Un trabajo coordinador administra todos estos subtrabajos independientes. Analice cuidadosamente cuántos datos se asignan a trabajos individuales. Cuanto más pequeños sean los datos, más sobrecarga de trabajo, como el inicio y la limpieza del trabajo, afectará al sistema. Si el tamaño de los datos es demasiado grande, la transferencia de datos puede llevar demasiado tiempo para completarse. Esto también puede llevar a una utilización desigual de los recursos de procesamiento, por ejemplo, un trabajo grande que se ejecuta durante mucho tiempo en un servidor, mientras que otros servidores están esperando trabajo. No olvide ver la cantidad de trabajos lanzados para una tarea determinada. Si es necesario, ajuste esta configuración para cambiar la cantidad de trabajos automáticos. Siempre esté atento al tamaño de las transferencias de datos para el procesamiento de trabajos. La localidad de los datos le brindará el mejor rendimiento, ya que los datos siempre están disponibles localmente para un trabajo. Pero lograr un mayor nivel de localidad de datos significa que los datos deben replicarse en múltiples ubicaciones. Esto, nuevamente, puede tener un gran impacto en el rendimiento. Además, los resultados de un evento de transmisión en tiempo real deben fusionarse con la salida de los procesos analíticos por lotes. Diseñe su sistema de manera que esto se maneje sin problemas, sin que ningún proceso afecte los resultados de otros procesos en caso de falla. Muchas veces, es necesario volver a procesar el mismo conjunto de datos. Esto puede ser debido a razones como algún error/excepción ocurrido en el procesamiento inicial o un cambio en algún proceso comercial y la empresa desea ver el impacto en los datos antiguos también. Diseñe su sistema para manejar estos escenarios. Esto significa que es posible que deba almacenar los datos en bruto originales durante períodos más largos, por lo que necesita más almacenamiento. La salida final de los trabajos de procesamiento debe almacenarse en un formato/modelo que se base en los resultados finales esperados del sistema de Big Data. Por ejemplo, si el resultado final es que un usuario comercial debe ver la salida agregada en intervalos de series de tiempo semanales, asegúrese de que los resultados se almacenen en formas agregadas semanales. Para lograr esto, el modelado de la base de datos de los sistemas de Big Data se realiza en función de los tipos de casos de uso que se espera que aborden. Por ejemplo, no es raro que un sistema de Big Data tenga tablas de salida final que tengan una estructura que represente de cerca el formato del informe de salida, que se mostrará mediante una herramienta de capa de presentación. En la mayoría de los casos, esto puede tener un gran impacto en cómo un usuario final percibe el rendimiento de este sistema.

Consideraciones de rendimiento para el procesamiento de datos

El procesamiento de datos y el procesamiento analítico son el núcleo de un sistema de Big Data. Aquí es donde se realiza la mayor parte del procesamiento, como la sumarización, el pronóstico, la agregación y otras lógicas. Esta sección habla sobre algunos consejos de rendimiento para el procesamiento de datos. Tenga en cuenta que, según los requisitos, la arquitectura del sistema de Big Data puede tener componentes tanto para el procesamiento de transmisión en tiempo real como para el procesamiento por lotes. Esta sección cubre todos los aspectos del procesamiento de datos sin categorizarlos necesariamente en algún modelo de procesamiento en particular.

• Elija un marco de procesamiento de datos adecuado después de una evaluación detallada del marco y los requisitos. Algunos marcos son buenos para el procesamiento por lotes, mientras que otros funcionan mejor para el procesamiento de transmisión en tiempo real. De manera similar, algunos marcos utilizan un modelo en memoria, mientras que otros funcionan en procesamiento basado en archivos y disco. Algunos marcos pueden proporcionar un mayor nivel de paralelización que otros marcos, lo que hace que toda la ejecución sea más rápida. Los marcos en memoria son muy probablemente mucho más rápidos que los marcos de procesamiento basados en disco, pero pueden generar costos de infraestructura más altos. En resumen, es imperativo elegir un procesamiento que tenga las capacidades para cumplir con los requisitos. De lo contrario, es posible que termine con un marco incorrecto y no pueda cumplir con los requisitos funcionales o no funcionales, incluido el rendimiento.
• Algunos de estos marcos dividen los datos a procesar en fragmentos más pequeños. Estos fragmentos más pequeños de datos se procesan de forma independiente mediante trabajos individuales. Un trabajo coordinador administra todos estos subtrabajos independientes. Analice cuidadosamente cuántos datos se asignan a trabajos individuales. Cuanto más pequeños sean los datos, más sobrecarga de trabajo, como el inicio y la limpieza del trabajo, afectará al sistema. Si el tamaño de los datos es demasiado grande, la transferencia de datos puede llevar demasiado tiempo para completarse. Esto también puede llevar a una utilización desigual de los recursos de procesamiento, por ejemplo, un trabajo grande que se ejecuta durante mucho tiempo en un servidor, mientras que otros servidores están esperando trabajo. No olvide ver la cantidad de trabajos lanzados para una tarea determinada. Si es necesario, ajuste esta configuración para cambiar la cantidad de trabajos automáticos.
• Siempre esté atento al tamaño de las transferencias de datos para el procesamiento de trabajos. La localidad de los datos le brindará el mejor rendimiento, ya que los datos siempre están disponibles localmente para un trabajo. Pero lograr un mayor nivel de localidad de datos significa que los datos deben replicarse en múltiples ubicaciones. Esto, nuevamente, puede tener un gran impacto en el rendimiento. Además, los resultados de un evento de transmisión en tiempo real deben fusionarse con la salida de los procesos analíticos por lotes. Diseñe su sistema de manera que esto se maneje sin problemas, sin que ningún proceso afecte los resultados de otros procesos en caso de falla. Muchas veces, es necesario volver a procesar el mismo conjunto de datos. Esto puede ser debido a razones como algún error/excepción ocurrido en el procesamiento inicial o un cambio en algún proceso comercial y la empresa desea ver el impacto en los datos antiguos también. Diseñe su sistema para manejar estos escenarios. Esto significa que es posible que deba almacenar los datos en bruto originales durante períodos más largos, por lo que necesita más almacenamiento. La salida final de los trabajos de procesamiento debe almacenarse en un formato/modelo que se base en los resultados finales esperados del sistema de Big Data. Por ejemplo, si el resultado final es que un usuario comercial debe ver la salida agregada en intervalos de series de tiempo semanales, asegúrese de que los resultados se almacenen en formas agregadas semanales. Para lograr esto, el modelado de la base de datos de los sistemas de Big Data se realiza en función de los tipos de casos de uso que se espera que aborden. En la mayoría de los casos, esto puede tener un gran impacto en cómo un usuario final percibe el rendimiento de este sistema.

Consideraciones de rendimiento para la visualización

Los sistemas de Big Data de alto rendimiento diseñados cuidadosamente brindan valor al realizar un análisis detallado de los datos y proporcionar información valiosa basada en este análisis. Aquí es donde entra en juego la visualización. Una buena visualización ayuda a los usuarios a tener una vista detallada y detallada de los datos. Tenga en cuenta que las herramientas tradicionales de BI e informes o los pasos utilizados para construir sistemas de informes personalizados no se pueden escalar para satisfacer las demandas de visualización de un sistema de Big Data. Ahora hay muchas herramientas de visualización comerciales disponibles. Este artículo no entrará en detalles sobre cómo ajustar estas herramientas individuales para obtener un mejor rendimiento, pero presentará pautas genéricas que deben seguirse al diseñar una capa de visualización.

• Asegúrese de que la capa de visualización muestre los datos de las tablas de salida resumidas finales. Estas tablas resumidas podrían ser agregaciones basadas en períodos de tiempo, recomendaciones basadas en categoría o cualquier otro caso de uso basado en tablas resumidas. Evite leer todos los datos en bruto directamente desde la capa de visualización. Esto no solo minimizará la transferencia de datos al mínimo, sino que también ayudará a evitar un procesamiento pesado cuando el usuario esté viendo los informes.
• Maximice el uso de la memoria caché en una herramienta de visualización. La memoria caché puede tener un gran impacto en el rendimiento general de la capa de visualización.
• Las vistas materializadas pueden ser otra técnica importante para mejorar el rendimiento. La mayoría de las herramientas de visualización permiten configuraciones para aumentar el número de trabajos (hilos) para manejar las solicitudes de informes. Si hay capacidad disponible y el sistema recibe un alto número de solicitudes, esta podría ser una de las opciones para obtener un mejor rendimiento.
• Mantenga los valores precalculados en las tablas resumidas. Si algunos cálculos deben realizarse en tiempo de ejecución, asegúrese de que sean lo más mínimos posible y trabajen en el nivel más alto de datos posible.
• Las herramientas de visualización también permiten múltiples formas de leer los datos que deben presentarse. Algunas de estas son el modo desconectado o de extracción, el modo de conexión en vivo, etc. Cada uno de estos modos sirve para diferentes requisitos y puede tener un rendimiento diferente en un escenario dado. Evalúe cuidadosamente.
• De manera similar, algunas herramientas permiten recuperar datos incrementalmente. Esto minimiza la transferencia de datos y puede acelerar toda la visualización.
• Mantenga el tamaño de las imágenes generadas, como gráficos, tablas, etc., al mínimo. La mayoría de los marcos y herramientas de visualización utilizan Scalable Vector Graphics (SVG). Los diseños complejos que utilizan SVG pueden tener graves impactos en el rendimiento.
• Una vez que se siguen todas las prácticas y pautas en todas las secciones de este artículo, asegúrese de planificar los recursos suficientes, como CPUs, memoria, almacenamiento en disco, ancho de banda de red, etc.

Seguridad de Big Data y su impacto en el rendimiento

Al igual que cualquier sistema de TI, los requisitos de seguridad también pueden tener un impacto serio en el rendimiento de un sistema de Big Data. En esta sección, se discutirán algunas consideraciones de alto nivel para diseñar la seguridad de un sistema de Big Data sin tener un impacto adverso en el rendimiento.

• Asegúrese de que los datos que provienen de diversas fuentes estén debidamente autenticados y autorizados en el punto de entrada del sistema de Big Data. Incluso si todos los datos provienen solo de fuentes confiables y no hay requisitos para dicha autenticación de datos de origen, mantenga su diseño flexible para manejar esto. Una vez que los datos estén debidamente autenticados, intente evitar cualquier otra autenticación de los mismos datos en un punto posterior de las ejecuciones. Si es necesario, etiquete estos datos autenticados con algún tipo de identificador o token para marcarlos como autenticados y usarlos más tarde. Esto ahorrará el procesamiento duplicado al intentar autenticar datos en cada paso una y otra vez.
• Es posible que deba admitir otros mecanismos como soluciones basadas en PKI o Kerberos. Cada uno de estos tiene diferentes características de rendimiento que deben considerarse antes de finalizar cualquier solución.
• La mayoría de las veces, los datos deben comprimirse antes de enviarse a los sistemas de Big Data. Esto disminuye el tamaño de los datos a transferir, lo que hace que la transferencia de datos sea más rápida. Pero debido a la necesidad de un paso adicional para descomprimir los datos, puede ralentizar el procesamiento. Hay disponibles diferentes algoritmos y formatos para esta compresión, y cada uno puede proporcionar diferentes niveles de compresión. Estos diferentes algoritmos tienen diferentes requisitos de CPU, así que elija el algoritmo cuidadosamente. De manera similar, evalúe la lógica y los algoritmos de cifrado antes de seleccionarlos. Es recomendable mantener el cifrado limitado a los campos o información que son sensibles o confidenciales.
• Puede ser necesario mantener registros de diferentes actividades como acceso, actualizaciones, etc. en una tabla de auditoría o registro. Esto puede ser necesario por diversas regulaciones o políticas comerciales. Tenga en cuenta que este requisito no solo aumenta la cantidad de pasos involucrados en el procesamiento, sino que también puede aumentar la cantidad de almacenamiento necesaria. Tenga esto en cuenta.
• Siempre use opciones de seguridad proporcionadas por entidades de infraestructura como sistemas operativos, bases de datos, etc. Estos funcionarán más rápido que las soluciones personalizadas construidas para realizar las mismas tareas.

Conclusión

Este artículo presentó varias consideraciones de rendimiento que pueden actuar como pautas para construir sistemas de Big Data y análisis de alto rendimiento. Los sistemas de Big Data y análisis pueden ser muy complejos debido a múltiples razones. Para cumplir con los requisitos de rendimiento de dicho sistema, es necesario que el sistema esté diseñado y construido desde el principio para cumplir con estos requisitos de rendimiento. Este artículo presentó pautas que deben seguirse durante las diferentes etapas de un sistema de Big Data, incluido cómo los requisitos de seguridad pueden afectar el rendimiento del sistema de Big Data.

Contenido original publicado aquí: https://dzone.com/articles/building-high-performance-big-data-and-analytics-s