Una guía del ingeniero de datos para almacenamientos de datos no tradicionales

Ingeniería de datos

Con el auge del big data y la ciencia de datos, muchos roles de ingeniería están siendo desafiados y ampliados. Una función de la nueva era es la ingeniería de datos .

Originalmente, el propósito de la ingeniería de datos era la carga de fuentes de datos externas y el diseño de bases de datos (diseño y desarrollo de canalizaciones para recopilar, manipular, almacenar y analizar datos).

Desde entonces, ha crecido para admitir el volumen y la complejidad de los grandes datos. Por lo tanto, la ingeniería de datos ahora encapsula una amplia gama de habilidades, desde rastreo web, limpieza de datos, computación distribuida y almacenamiento y recuperación de datos.

Para la ingeniería de datos y los ingenieros de datos, el almacenamiento y la recuperación de datos es el componente crítico de la tubería junto con la forma en que se pueden usar y analizar los datos.

En los últimos tiempos, han surgido muchas tecnologías de almacenamiento de datos nuevas y diferentes. Sin embargo, ¿cuál se adapta mejor y tiene las características más adecuadas para la ingeniería de datos?

La mayoría de los ingenieros están familiarizados con las bases de datos SQL, como PostgreSQL, MSSQL y MySQL, que están estructuradas en tablas de datos relacionales con almacenamiento orientado a filas.

Dada la omnipresencia de estas bases de datos, no las discutiremos hoy. En su lugar, exploramos tres tipos de almacenamiento de datos alternativos que están creciendo en popularidad y que han introducido diferentes enfoques para manejar los datos.

En el contexto de la ingeniería de datos, estas tecnologías son los motores de búsqueda, los almacenes de documentos y los almacenes de columnas.

• Los motores de búsqueda se destacan en las consultas de texto. En comparación con las coincidencias de texto en las bases de datos SQL, como LIKE , los motores de búsqueda ofrecen mayores capacidades de consulta y un mejor rendimiento desde el primer momento.
• Los almacenes de documentos proporcionan una mejor adaptabilidad del esquema de datos que las bases de datos tradicionales. Al almacenar los datos como objetos de documentos individuales, a menudo representados como JSON, no requieren la predefinición del esquema.
• Las tiendas en columnas se especializan en consultas de una sola columna y agregaciones de valores. Las operaciones de SQL, como SUM y AVG , son considerablemente más rápidas en los almacenes de columnas, ya que los datos de la misma columna se almacenan más juntos en el disco duro.

En este artículo, exploramos las tres tecnologías: Elasticsearch como motor de búsqueda, MongoDB como almacén de documentos y Amazon Redshift como almacén de columnas.

Al comprender el almacenamiento alternativo de datos, podemos elegir el más adecuado para cada situación.

Para comparar estas tecnologías, examinaremos cómo indexan, fragmentan y agregan datos.

Cada estrategia de indexación de datos mejora ciertas consultas y obstaculiza otras.

Saber qué consultas se usan con más frecuencia puede influir en qué almacén de datos adoptar.

Sharding, una metodología mediante la cual las bases de datos dividen sus datos en fragmentos, determina cómo crecerá la infraestructura a medida que se ingieren más datos.

Elegir uno que coincida con nuestro plan de crecimiento y presupuesto es fundamental, y esto se aplica a cualquier empresa de ciencia de datos, independientemente de su tamaño.

Finalmente, cada una de estas tecnologías agrega sus datos de manera muy diferente.

Cuando tratamos con gigabytes y terabytes de datos, la estrategia de agregación incorrecta puede limitar los tipos y el rendimiento de los informes que podemos generar.

Como ingenieros de datos, debemos considerar los tres aspectos al evaluar diferentes almacenamientos de datos.

contendientes

Motor de búsqueda: Elasticsearch

Elasticsearch rápidamente ganó popularidad entre sus pares por su escalabilidad y facilidad de integración. Construido sobre Apache Lucene, ofrece una potente funcionalidad de indexación y búsqueda de texto lista para usar. Además de las tareas tradicionales del motor de búsqueda, la búsqueda de texto y las consultas de valor exacto, Elasticsearch también ofrece capacidades de agregación en capas.

Almacén de documentos: MongoDB

En este punto, MongoDB puede considerarse la base de datos NoSQL de referencia. Su facilidad de uso y flexibilidad ganaron rápidamente su popularidad. MongoDB admite consultas enriquecidas y adaptables para profundizar en documentos complejos. Los campos consultados con frecuencia se pueden acelerar a través de la indexación y, al agregar una gran cantidad de datos, MongoDB ofrece una canalización de varias etapas.

Tienda en columnas: Amazon Redshift

Junto con el crecimiento de la popularidad de NoSQL, las bases de datos en columnas también han llamado la atención, especialmente para el análisis de datos. Al almacenar datos en columnas en lugar de las filas habituales, las operaciones de agregación se pueden ejecutar directamente desde el disco, lo que aumenta considerablemente el rendimiento. Hace unos años, Amazon lanzó su servicio alojado para una tienda en columnas llamada Redshift.

Indexación

Capacidad de indexación de Elasticsearch

En muchos sentidos, los motores de búsqueda son almacenes de datos que se especializan en indexar textos.

Mientras que otros almacenes de datos crean índices basados ​​en los valores exactos del campo, los motores de búsqueda permiten la recuperación con solo un fragmento del campo (generalmente texto).

Por defecto, esta recuperación se realiza automáticamente para cada campo a través de analizadores.

Un analizador es un módulo que crea varias claves de índice evaluando los valores de campo y dividiéndolos en valores más pequeños.

Por ejemplo, un analizador básico podría examinar "el rápido zorro marrón saltó sobre el perro perezoso" en palabras como "el", "rápido", "marrón", "zorro", etc.

Este método permite a los usuarios encontrar los datos buscando fragmentos dentro de los resultados, clasificados por cuántos fragmentos coinciden con los mismos datos del documento.

Un analizador más sofisticado podría utilizar editar distancias, n-gramas y filtrar por palabras vacías para crear un índice de recuperación completo.

Capacidad de indexación de MongoDB

Como almacén de datos genérico, MongoDB tiene mucha flexibilidad para indexar datos.

A diferencia de Elasticsearch, solo indexa el campo _id de manera predeterminada, y necesitamos crear índices para los campos comúnmente consultados manualmente.

Comparado con Elasticsearch, el analizador de texto de MongoDB no es tan poderoso. Pero proporciona mucha flexibilidad con los métodos de indexación, desde el compuesto y el geoespacial para una consulta óptima hasta el TTL y el disperso para la reducción del almacenamiento.

Capacidad de indexación de Redshift

A diferencia de Elasticsearch, MongoDB o incluso las bases de datos tradicionales, incluido PostgreSQL, Amazon Redshift no admite un método de indexación.

En su lugar, reduce el tiempo de consulta al mantener una clasificación uniforme en el disco.

Como usuarios, podemos configurar un conjunto ordenado de valores de columna como clave de ordenación de la tabla. Con los datos ordenados en el disco, Redshift puede omitir un bloque completo durante la recuperación si su valor cae fuera del rango consultado, lo que aumenta considerablemente el rendimiento.

fragmentación

Capacidad de fragmentación de Elasticsearch

Elasticsearch se construyó sobre Lucene para escalar horizontalmente y estar listo para la producción.

El escalado se realiza creando varias instancias de Lucene (fragmentos) y distribuyéndolas en varios nodos (servidores) dentro de un clúster.

De forma predeterminada, cada documento se enruta a su fragmento respectivo a través de su campo _id .

Durante la recuperación, el nodo maestro envía a cada fragmento una copia de la consulta antes de finalmente agregarlos y clasificarlos para la salida.

Capacidad de fragmentación de MongoDB

Dentro de un clúster MongoDB, hay tres tipos de servidores: enrutador, configuración y fragmento.

Al escalar el enrutador, los servidores pueden aceptar más solicitudes, pero el trabajo pesado ocurre en los servidores de fragmentos.

Al igual que con Elasticsearch, los documentos de MongoDB se enrutan (de manera predeterminada) a través de _id a sus respectivos fragmentos. En el momento de la consulta, el servidor de configuración notifica al enrutador, que fragmenta la consulta, y el servidor del enrutador luego distribuye la consulta y agrega los resultados.

Capacidad de fragmentación de Redshift

Un clúster de Amazon Redshift consta de un nodo líder y varios nodos informáticos.

El nodo líder maneja la compilación y distribución de consultas, así como la agregación de resultados intermedios.

A diferencia de los servidores de enrutadores de MongoDB, el nodo líder es consistente y no se puede escalar horizontalmente.

Si bien esto crea un cuello de botella, también permite el almacenamiento en caché eficiente de planes de ejecución compilados para consultas populares.

agregando

Capacidad de agregación de Elasticsearch

Los documentos dentro de Elasticsearch se pueden agrupar por valores exactos, de rango o incluso temporales y de geolocalización.

Estos cubos se pueden agrupar aún más en una granularidad más fina a través de la agregación anidada.

Las métricas, incluidas las medias y las desviaciones estándar, se pueden calcular para cada capa, lo que brinda la capacidad de calcular una jerarquía de análisis dentro de una sola consulta.

Al ser un almacenamiento basado en documentos, sufre la limitación de las comparaciones de campo dentro del documento.

Por ejemplo, si bien es bueno para filtrar si un campo de seguidores es mayor que 10, no podemos verificar si los seguidores son mayores que otro campo siguiente .

Como alternativa, podemos inyectar scripts como predicados personalizados. Esta característica es excelente para el análisis único, pero el rendimiento se ve afectado en la producción.

Capacidad de agregación de MongoDB

Aggregation Pipeline es potente y rápido.

Como sugiere su nombre, opera con los datos devueltos por etapas.

Cada paso puede filtrar, agregar y transformar los documentos, introducir nuevas métricas o deshacer grupos previamente agregados.

Debido a que estas operaciones se realizan por etapas, y al garantizar que los documentos y campos se reduzcan a solo filtrados, se puede minimizar el costo de la memoria. En comparación con Elasticsearch, e incluso con Redshift, Aggregation Pipeline es una forma extremadamente flexible de ver los datos.

A pesar de su adaptabilidad, MongoDB sufre la misma falta de comparación de campos dentro del documento que Elasticsearch.

Además, algunas operaciones, incluido $group , requieren que los resultados se pasen al nodo maestro.

Por lo tanto, no aprovechan la computación distribuida.

Aquellos que no estén familiarizados con el cálculo de canalización por etapas encontrarán ciertas tareas poco intuitivas. Por ejemplo, sumar el número de elementos en un campo de matriz requeriría dos pasos: primero, la operación $unwind y luego la operación $group .

Capacidad de agregación de Redshift

Los beneficios de Amazon Redshift no se pueden subestimar.

Amazon Redshift resuelve rápidamente las agregaciones frustrantemente lentas en MongoDB mientras se analiza el tráfico móvil.

Al ser compatible con SQL, a los ingenieros de bases de datos tradicionales les resultará fácil migrar sus consultas a Redshift.

Dejando de lado el tiempo de incorporación, SQL es un lenguaje de consulta probado, escalable y potente, que admite comparaciones de campo intradocumento/fila con facilidad. Amazon Redshift mejora aún más su rendimiento al compilar y almacenar en caché consultas populares ejecutadas en los nodos de cómputo.

Como base de datos relacional, Amazon Redshift no tiene la flexibilidad de esquema que tienen MongoDB y Elasticsearch. Optimizado para operaciones de lectura, sufre impactos en el rendimiento durante las actualizaciones y eliminaciones.

Para mantener el mejor tiempo de lectura, las filas deben ordenarse, lo que agrega esfuerzos operativos adicionales.

Diseñado para aquellos con problemas del tamaño de petabytes, no es barato y probablemente no valga la pena la inversión a menos que haya problemas de escalado con otras bases de datos.

Elegir al ganador

En este artículo, examinamos tres tecnologías diferentes: Elasticsearch, MongoDB y Amazon Redshift, dentro del contexto de la ingeniería de datos. Sin embargo, no hay un ganador claro ya que cada una de estas tecnologías es pionera en su categoría de tipo de almacenamiento.

Para la ingeniería de datos, según el caso de uso, algunas opciones son mejores que otras.

• MongoDB es una fantástica base de datos de inicio. Proporciona la flexibilidad que queremos cuando aún no se ha determinado el esquema de datos. Dicho esto, MongoDB no supera los casos de uso específicos en los que se especializan otras bases de datos.
• Si bien Elasticsearch ofrece un esquema fluido similar al de MongoDB, está optimizado para múltiples índices y consultas de texto a expensas del rendimiento de escritura y el tamaño del almacenamiento. Por lo tanto, deberíamos considerar migrar a Elasticsearch cuando nos encontremos manteniendo numerosos índices en MongoDB.
• Redshift requiere un esquema de datos predefinido y carece de la adaptabilidad que ofrece MongoDB. A cambio, supera a otras bases de datos para consultas que solo involucran una (o unas pocas) columnas. Cuando el presupuesto lo permite, Amazon Redshift es una gran arma secreta cuando otros no pueden manejar la cantidad de datos.