Se preparó una traducción del artículo específicamente para estudiantes del curso de Ingeniero de datos .
Lee la primera parteNadie necesita Big Data
Cuando escuche, "Nadie necesita Big Data", mire el currículum del orador. Un operador de telecomunicaciones africano que experimente niveles sorprendentes de crecimiento no se pondrá en contacto con el nuevo desarrollador web de JavaScript y le preguntará si puede ayudarlo a desarrollar su plataforma de datos y optimizar los cálculos de facturación. Puede encontrar muchas aplicaciones web internas en la sede de la aerolínea, pero cuando se trata de analizar petabytes de telemetría de aeronaves para mantenimiento preventivo, puede que no haya un solo desarrollador de PHP en este proyecto.
Los proyectos anteriores a menudo no se anuncian de tal manera que los desarrolladores web puedan conocerlos. Es por eso que alguien puede pasar años trabajando en nuevos proyectos que están en la parte inferior de su curva S en términos de crecimiento y acumulación de datos, y en la mayoría de los casos nunca ve la necesidad de procesar datos más allá de lo que Puede caber en RAM en una máquina.
En los últimos 25 años, el desarrollo web ha sido un gran impulsor en el crecimiento del número de programadores. La mayoría de las personas que se autodenominan programadores suelen crear aplicaciones web. Creo que muchos de los conjuntos de habilidades que tienen están bien alineados con los necesarios para el diseño de datos, pero a menudo carecen de computación distribuida, estadísticas y narración de historias.
Los sitios web a menudo no crean una gran carga para ningún usuario, y a menudo el objetivo es mantener la carga en los servidores que admiten una gran cantidad de usuarios por debajo del umbral máximo de hardware. El mundo de los datos consiste en cargas de trabajo en las que una solicitud hace todo lo posible para maximizar una gran cantidad de máquinas, para completar el trabajo lo más rápido posible, al tiempo que reduce los costos de infraestructura.
Las compañías de datos de Petabyte a menudo tienen consultores experimentados y proveedores de soluciones en su arsenal. Raramente vi a alguien que sus empleadores retiraran del desarrollo web y lo transfirieran al área de desarrollo de la plataforma de datos; casi siempre es el resultado de un largo auto-reciclaje.
Este conjunto de datos puede vivir en RAM
Escuché a la gente decir que "un conjunto de datos puede caber en la memoria". La cantidad de RAM, incluso en la nube, ha crecido significativamente últimamente. Hay instancias de EC2 con 2 TB de RAM. Por lo general, la RAM se puede usar a 12-25 GB / s, dependiendo de la arquitectura de su instalación. El uso de RAM solo no proporcionará la recuperación de una falla si ocurre una falla de energía en la máquina. Además, el costo por GB será enorme en comparación con el uso de unidades.
Los discos también se están volviendo más rápidos. Recientemente se
anunció una tarjeta SSD PCIe 4.0 NVMe 4 x 2 TB capaz de leer y escribir a una velocidad de 15 GB / s. El precio de una unidad PCIe 4.0 NVMe será bastante competitivo con la RAM y proporcionará memoria no volátil. No puedo esperar para ver un clúster HDFS con una buena red usando estas unidades, porque demostrará cómo se ve un archivo de datos en la memoria con almacenamiento no volátil con las herramientas ricas del ecosistema Hadoop.
Sobrecargado con excesos de ingeniería
No me gustaría gastar 6 o 7 dígitos en el desarrollo de una plataforma de datos y un equipo para una empresa que no podría escalar más allá de lo que cabe en una computadora portátil de un desarrollador.
Desde la perspectiva del flujo de trabajo, mis días consisten principalmente en usar BASH, Python y SQL. Muchos nuevos graduados están calificados en lo anterior.
Petquet data Parquet se puede distribuir fácilmente en un millón de archivos en S3. La planificación relacionada con lo anterior no es mucho más complicada que considerar cómo almacenar 100,000 archivos de micropaquetes en S3. El hecho de que una solución sea escalable no significa que sea redundante.
¿Solo usa PostgreSQL?
También he escuchado argumentos de que los sistemas orientados a filas como MySQL y PostgreSQL pueden satisfacer las necesidades de las cargas de trabajo analíticas, así como sus cargas de trabajo transaccionales tradicionales. Ambas sugerencias pueden hacerse mediante análisis, y si está viendo menos de 20 GB de datos, probablemente no valga la pena escalar.
Tuve que trabajar con un sistema que cargaba 10 mil millones de filas diariamente en MySQL. En MySQL y PostgreSQL, no hay nada que pueda manejar tal carga. El costo de la infraestructura para almacenar conjuntos de datos, incluso durante varios días, en almacenamiento orientado a filas, ha eclipsado los costos de personal. Cambiar a una solución de almacenamiento en columna para este cliente redujo los costos de infraestructura y aceleró los tiempos de consulta en dos órdenes de magnitud para cada uno.
PostgreSQL tiene una serie de complementos para almacenar y distribuir consultas en varias máquinas. Los mejores ejemplos que he visto son ofertas comerciales. El
Zedstore anunciado puede, en un grado u otro, apoyar el establecimiento del almacenamiento de columnas como una función integrada estándar de PostgreSQL. Será interesante ver si la distribución de solicitudes individuales y la separación del almacenamiento se convertirán en funciones estándar en el futuro.
Si necesita un conjunto de datos transaccionales, es mejor mantener esta carga de trabajo aislada utilizando un almacén de datos transaccionales. Es por eso que espero que MySQL, PostgreSQL, Oracle y MSSQL duren mucho tiempo.
¿Pero le gustaría ver un descanso de 4 horas en Uber porque una de sus solicitudes de Presto causó un comportamiento inesperado? ¿Desea que su empresa sea informada sobre la necesidad de facturación mensual, por qué tendría que apagar su sitio web durante una semana para que haya suficientes recursos para esta tarea? Las cargas de trabajo analíticas no deben asociarse con cargas de trabajo transaccionales. Puede reducir los riesgos operativos y elegir el equipo más adecuado ejecutándolos en una infraestructura separada.
Y dado que trabaja en hardware separado, no necesita usar el mismo software. Muchas de las habilidades inherentes a un ingeniero PostgreSQL competente se adaptan bien al mundo de los datos orientado al análisis; Este es un pequeño paso en comparación con saltar para un desarrollador web que se muda al gran espacio de datos.
¿Cómo se ve el futuro?
Continuaré analizando y ampliando mis habilidades de datos en el futuro previsible. En los últimos 12 meses, he estado trabajando usando Redshift, BigQuery y Presto en cantidades casi iguales. Intento distribuir mis apuestas, porque todavía no he encontrado una bola de cristal del predictor que funcione.
Lo que realmente espero es más fragmentación y más jugadores entrando y saliendo de la industria también. Existen razones para la existencia de la mayoría de las bases de datos, pero los casos de uso que pueden servir pueden ser limitados. Al mismo tiempo, los buenos vendedores pueden ampliar la demanda del mercado para cualquier oferta. Escuché que la gente cree que crear una base de datos de calidad comercial requiere alrededor de $ 10 millones, y este es probablemente el mejor lugar para capital de riesgo.
Hay muchas sugerencias e implementaciones que dejan a los clientes con un sabor desagradable. También existe el impacto de una etiqueta de precio en la nube. Hay soluciones que son buenas, pero demasiado caras debido al costo de contratar expertos. Los profesionales de ventas y marketing de la industria estarán ocupados durante algún tiempo discutiendo las compensaciones anteriores.
Cloudera y MapR pueden estar en tiempos difíciles en este momento, pero no he escuchado nada como esto para hacerme creer que AWS EMR, DataBricks y Qubole tienen algo con lo que competir. Incluso Oracle está lanzando una oferta
impulsada por Spark . Sería bueno que la industria viera en Hadoop algo más que una simple oferta de Cloudera, y reconociera que estas empresas, así como Facebook, Uber y Twitter hicieron una contribución significativa al mundo de Hadoop.
Hortonworks, que se fusionó con Cloudera este año, es un proveedor de plataforma para Azure HDInsight, administrado por Microsoft Hadoop. Hay personas en la empresa que pueden proporcionar una plataforma decente a un proveedor externo de servicios en la nube. Espero que cualquier propuesta en la que estén trabajando se centre en este tipo de oferta.
Sospecho que los primeros clientes de Cloudera eran usuarios de HBase, Oozie, Sqoop e Impala. Sería bueno ver que no compiten por un tiempo de desarrollo tan largo y por futuras versiones de sus plataformas que se enviarán con Airflow, Presto y la última versión de Spark lista para usar.
Al final, si su empresa planea implementar una plataforma de datos, no encontrará un reemplazo para un equipo de administración exigente que pueda investigar cuidadosamente, planificar cuidadosamente e identificar fallas rápidamente.