Cuando diseñamos y construimos arquitecturas software (Big Data, microservicios, Service Mesh…) resulta necesario y útil conocer las buenas prácticas aplicables a nuestro caso de uso y, con ellas, las arquitecturas de referencia que nos validen que estamos haciendo las cosas del modo adecuado para garantizar el funcionamiento óptimo del sistema.

En esta ocasión, más allá de hablar de buenas prácticas, queríamos abordar en este artículo enfocándolo justo a lo contrario: cuáles son las malas prácticas o, dicho de otro modo, lo que debemos evitar o paliar, cuando nos enfrentamos a una arquitectura Big Data. Los conocidos como AntiPatterns.

Prácticas a evitar en el diseño de arquitecturas #BigData Clic para tuitear

Hemos recopilado algunos de los que con mayor frecuencia nos hemos encontrado (y sufrido).

1. Ignorar el tamaño de los ficheros

Es fundamental elegir el tamaño correcto de los ficheros, el tamaño de bloques y el factor de replicación, para que la arquitectura de Big Data que estamos construyendo sea lo más eficiente posible. Ficheros demasiado pequeños provocarán que las lecturas y escrituras sean frecuentes (con la penalización que conlleva), y los ficheros demasiado grandes obligarán a tener procesos menos paralelizables que requerirán mayor cantidad de memoria y tiempo para poder gestionar tanta información de una sola vez. ¿Cuál es el tamaño correcto de ficheros y bloques? Esa es la gran pregunta que tendremos que analizar y responder para cada caso de uso y tecnología que estemos empleando.

2. Una herramienta para todo

Afortunadamente, en el ecosistema de Big Data disponemos de una gran cantidad de herramientas que nos van a permitir abordar multitud de tareas diferentes. Cada herramienta está adaptada a un caso de uso concreto y debemos asegurarnos de que la utilizamos para lo que está diseñada y así evitar caer en la tentación del antipatrón del martillo de oro. Por ejemplo, si utilizáramos una base de datos como DynamoDB o CosmosDB para almacenar un modelo relacional, antes o después nos encontraríamos con un muro bastante difícil de sortear. Lo mismo ocurriría si intentamos utilizar AWS RedShift o Azure SQL Data Warehouse para gestionar inserciones de datos masivas en tiempo real de forma concurrente.

3. No tener en cuenta la evolución de esquema

Los datos evolucionan con el tiempo. El esquema o modelo con el que trabajamos hoy probablemente no será el mismo con el que trabajemos el mes que viene. No plantear y diseñar desde el principio la evolución del esquema nos supondrá una inversión de tiempo y esfuerzo que, en algunos casos, será muy difícil de gestionar o revertir.

4. No elegir la clave de particionado adecuadamente

Al consultar un volumen enorme de datos, el hecho de definir un particionamiento eficiente y adecuado a los datos que estamos gestionando, nos ayudará a que las búsquedas sean más precisas y consuman menor tiempo y recursos. Definir las claves de particionado es una de las tareas a la que debemos prestar la mayor atención sobre todo durante las fases iniciales de diseño y modelado de la arquitectura de datos.

5. No contemplar el modelo de seguridad de acceso la información desde el diseño

Security by Design es el lema que debemos esgrimir siempre que nos enfrentemos a una arquitectura de datos. Desde la entrada en vigor de la GDPR, se ha hecho evidente (si es que no lo era ya) la importancia de garantizar la seguridad y el buen tratamiento de los datos que utilicemos, especialmente si hablamos de datos de carácter personal. Como mínimo debemos garantizar las siguientes medidas de seguridad sobre los datos:

  • Cifrado: Tanto en reposo como en tránsito. Lo ideal es tenerlo habilitado por defecto.
  • Enmascaramiento, ofuscación o anonimización en los casos requeridos.
  • Permisos: Quién tiene acceso a la información, a qué parte de la información tiene acceso, qué operaciones puede realizar sobre los datos (RBAC).
  • Derechos de los usuarios (en el caso de tratar con datos personales): rectificación, olvido, portabilidad.

Tener bien definidas y aplicadas estas políticas desde el inicio nos allanará el camino considerablemente a la hora de implementar nuestra arquitectura. Además, debemos ser conscientes de que los datos que debe gestionar nuestra arquitectura no son los únicos a proteger, ya que los datos que genera nuestra arquitectura son igual de importantes que los datos que tenemos que tratar: datos de logs, de transacciones, registros de actividad, registros de red…

6. No hacer pruebas de los algoritmos/procesos con volumetría real

Cuando diseñamos algoritmos o procesos, siempre nos aseguramos de tener las suficientes pruebas unitarias y de integración que nos permitan cumplir con un umbral mínimo de cobertura, pero cuando estos algoritmos tienen que lidiar con un volumen de datos muy grande, debemos asegurarnos además, que nuestros tests incluyen pruebas de volumetría real para garantizar el correcto funcionamiento de todo el sistema y evitar encontrar errores inesperados en los entornos de producción

7. Full scans

Habrá ocasiones en las que no tengamos más remedio que recorrer todo nuestro data set para realizar alguna operación en concreto (por ejemplo, eliminar un registro determinado y actualizar el data set u ofuscar campos que han pasado a ser considerados delicados), pero debemos tener en cuenta que esta es una operación que consumirá gran cantidad de recursos y de tiempo y, en función del tamaño del data set, puede que sea impracticable llevarla a cabo. En aquellas ocasiones en las que sea necesario llevar a cabo un full scan, debemos asegurarnos de contar con una ventana temporal lo suficientemente amplia para dar tiempo a los procesos a completarse y no impactar al resto de la arquitectura.

8. ¿Big Data?

Como último punto, queremos hacer una pequeña reflexión: ¿Qué es Big Data? ¿Cuándo podemos considerar que una arquitectura está trabajando con un volumen de datos lo suficientemente grande para denominarse Big Data?

A medida que avanza el tiempo y los servicios cloud se hacen más eficientes y asequibles, el coste de almacenar y procesar nuestros datos disminuye, por lo que podemos afrontar mayores retos con mayor volumen de datos a menor coste, lo que implica que la pregunta que nos planteamos inicialmente vaya evolucionando su respuesta al mismo tiempo que evolucionan los servicios cloud y las capacidades del hardware se incrementan.

Lo que hoy denominamos Big Data puede que el año que viene no encaje dentro de esa definición y tengamos que replantear nuevamente los criterios. Quizás, podría plantearse la pregunta desde otra perspectiva: Si todos tus datos caben en RAM, ¿estás haciendo big data?

Si todos tus datos caben en RAM, ¿estás haciendo #BigData? Clic para tuitear

Si te interesa profundizar en el tema, te dejo algunas lecturas interesantes.

Imagen: unsplash | tim gouw

Author

  • Pablo Valiente

    Principal Cloud Architect en Keepler. "I am passionate about the world of software development and architecture, which drives me to be in continuous search of new technologies to learn and research. My professional work is developed on Cloud Computing with Amazon Web Services technology and non-relational databases (NoSQL) such as DynamoDB or MongoDB."

    Ver todas las entradas