¿Qué tan bueno es BigQuery de Google en comparación con Redshift de Amazon?

Además de otras respuestas aquí, mis 2 centavos:

• BigQuery está verdaderamente completamente administrado. Esto significa que Google sabe cuándo fallan sus trabajos, los SRE de Google están disponibles las 24 horas, los 7 días de la semana, y Google realiza actualizaciones para los clientes de BigQuery sin tiempo de inactividad. El modelo Redshift es mucho más práctico, como lo demuestra el ecosistema de nuevas empresas que prometen ayudar a los usuarios a administrar sus grupos de Redshift.
• La naturaleza totalmente gestionada de BigQuery también significa que los ingenieros de BigQuery introducen con frecuencia mejoras que hacen que el servicio sea más rápido o más resistente. La gran mayoría de estas mejoras no se informan, pero BigQuery realmente está evolucionando a un ritmo rápido. Es posible que deba ver qué tan bien BigQuery ejecuta JOINs grandes (escala TB vs TB) en comparación con incluso hace un año, o en comparación con Redshift. Redshift está mayormente bloqueado con solo mejoras marginales.
• BigQuery no se limita al tamaño de los ‘recursos aprovisionados’ como lo hace Redshift. Esto significa que BigQuery puede potencialmente usar vastos recursos para su consulta SQL. Independientemente de la eficiencia del procesamiento, BigQuery simplemente puede dedicar más recursos a su trabajo por menos tiempo. Si su trabajo requiere X recurso-segundos, BigQuery puede 10x recursos y 1/10 de los segundos. Esta es una razón por la cual BigQuery es a menudo órdenes de magnitud más rápido que Redshift.
• BigQuery le pide que pague solo por los recursos necesarios para procesar su trabajo. Si tuviéramos que establecer un paralelismo entre los precios de BigQuery y los precios de VM, BigQuery le permite escalar a 10,000 núcleos por solo un par de segundos Y solo paga por segundo. Esto es muy superior al modelo de facturación por hora de Redshift, y así es como BigQuery puede ser más barato y más rápido.
• Amazon adquirió el código fuente de Paraccel para obtener el producto mínimo viable de Redshift. Esto es excelente para ir al mercado rápidamente, pero plantea problemas importantes para el desarrollo a largo plazo. No ayuda que Paraccel haya visto una tracción muy limitada en el mercado. Por el contrario, BigQuery es la evolución de Dremel, que ha estado en producción en Google desde 2006, y BigQuery continúa iterando a un ritmo rápido.
• Redshift por defecto es de zona única. Esto es lo que tiene que hacer para que esté altamente disponible, una tarea tan compleja que la mayoría de las personas simplemente se arriesgan a ejecutar una sola zona. BigQuery es HA y multi-zona de forma predeterminada, sin cargos adicionales, sin ninguna complejidad para los usuarios. Si se comparara Redshift y BigQuery con esto en mente, los cálculos de costos tendrían que agregar un multiplicador de 3x a 5x a cualquier precio de Redshift.
• Los clientes más grandes de BigQuery almacenan docenas de petabytes de datos en lo que equivale a un solo clúster. Esto es muy difícil de organizar en Redshift: necesitará muchos clústeres dispares, la mayoría desplegados en una sola AZ. Las cosas pueden volverse poco fiables y complejas muy rápidamente.

Y este punto es muy práctico en la naturaleza y la separación de los osos. Si tiene un conjunto de datos que desea compartir con equipos / proveedores / clientes dispares o separados por caso de uso:

• Una arquitectura típica en Redshift es poner en pie grupos diferentes para cada parte y copiar el conjunto de datos en cada grupo. Es bastante complejo de operar, especialmente si el conjunto de datos cambia, y es altamente ineficiente.
• BigQuery admite compartir conjuntos de datos en su lugar y simplemente ajustar las listas de control de acceso (ACL), algo así como compartir un documento de Google con otros. Las ACL permiten a las personas compartir conjuntos de datos como lectores, editores y propietarios. Por lo tanto, no necesita tener varios clústeres que sirvan a un conjunto de datos, lo que simplifica enormemente las operaciones y la implementación.

Actualización de septiembre de 2015 – con algunos comentarios sobre Aurora

Me ha impresionado la cantidad de tráfico que ha estado recibiendo esta pregunta, así que pensé en actualizar mi publicación original. Mi equipo es un gran usuario de los servicios en la nube de AWS y Google, por lo que me gustaría pensar que puedo proporcionar una comparación honesta entre los dos. ¡Algunas de las respuestas aquí son bastante desiguales! (Te estoy mirando, Felipe 😉!)

Cualquiera que aterrice en esta página ahora también estaría bien atendido para ver la oferta Aurora de AWS. Lo que AWS ha hecho es bastante notable: han realizado ingeniería inversa de manera efectiva un socket MySQL desde cero, con gran parte de la escala oculta para el usuario. Fui parte de la versión beta inicial, y puedo decir que me impresionó:

• La velocidad.
• El factor de reemplazo de “caída”. Si tiene una aplicación pesada basada en MySQL, toda su indexación, procedimientos almacenados, etc. simplemente funcionarán en Aurora … lo cual es una gran ventaja sobre cualquier otra oferta (¡de AWS o Google!)
• El nivel de accesibilidad del personal de AWS. En los últimos meses, conocí a un gerente de cuenta en persona y me dieron acceso a personas reales que conocen sus cosas. Los gerentes de producto en Aurora son excelentes, y muy accesibles.
• Toda la ingeniería ‘back-end’ que se incluyó en ella, de modo que cosas como el respaldo, la recuperación ante desastres y la construcción del servidor se conviertan en simples llamadas de GUI o API.

Pero..

Todavía me sorprende, como lo estaba el año pasado, que AWS realmente no se aleje del modelo de hacer negocios basado en hardware. Supongo que les ha servido bien, pero en mi humilde opinión, la forma de Google BigQuery es aún más transparente, a menos que tenga un alto grado de inserciones / lectura todo el tiempo. Además, debe escalar su hardware para cualquier cuello de botella. (En nuestro caso, fueron insertos, y necesitábamos el hardware más grande que había …) Si su Insert y la Lectura no coinciden, sentirá que está gastando más de lo que necesita en Aurora.

Tal vez sea injusto, pero mi punto es que hay una libertad que viene de no tener que pensar tanto en el hardware. Piense en S3, ese servicio de almacenamiento mágico que “simplemente funciona”. Imagine que AWS lo obliga a aprovisionar nuevo hardware cuando desea más almacenamiento, o cuando desea leer o escribir más rápidamente, y tiene una idea de lo que siempre está al acecho en todas las ofertas de RDS.

Pero, creo que el objetivo de Aurora no es tanto reinventar MySQL, sino actuar como una ‘droga de entrada’ a otras ofertas de AWS. A medida que comienza a pensar en paralelizar sus flujos de datos, hay muchas otras ofertas de AWS que vale la pena considerar … (Kinesis, DynamoDb, SQS, Lambda, etc.) Pero, la mentalidad de esas herramientas es completamente diferente de lo que un desarrollador de LAMP-stack está acostumbrado. Entonces, la mayor contribución de Aurora al imperio de AWS probablemente será que trae a los desarrolladores de LAMP a la mesa y gradualmente los presenta a otras herramientas que, por cierto, tienen un precio transparente …

Si AWS puede implementar con éxito su estrategia de drogas de entrada , entonces las herramientas que esperan al desarrollador son bastante impresionantes y tienen un precio acorde. Probablemente estén mejor integrados que lo que Google ofrece hoy también.

Pero para una oferta pura de SQL como servicio, BigQuery sigue siendo el mejor juego de la ciudad. Seguimos considerándolo tan útil que procesamos una tonelada de datos en AWS-land, y luego los enviamos (a un gran costo, por cierto, ya que pagas para que los datos salgan de AWS) de una nube a otra.

Me he alejado un poco de la pregunta original “BigQuery vs Redshift”, pero pensé que valía la pena presentar la nueva Aurora a la pregunta, y también destacar las diferentes filosofías de precios de las diversas herramientas.

-Peter

Publicación original: marzo de 2014

Financieramente hablando, tiene mucho que ver con si prefiere tener costos fijos o variables. Al final del día, AWS piensa en prácticamente todos los productos como un conjunto de instancias de EC2, por lo que su fórmula de costos es algo así:

((tamaño de las instancias EC2 x (horas en funcionamiento)) – (Descuento prepago)

AWS no se mueve mucho de este enfoque, incluso para las ofertas de bases de datos como servicio como Redshift.

Google, por otro lado, cobra por el almacenamiento y la cantidad de datos consumidos en el ‘tiempo de consulta’. Esa última parte es un poco difícil de entender, pero significa que pagará más por más consultas, pero también menos si sus consultas se ejecutan en menos columnas. (Piense en ‘seleccionar a, b de tbl’ como un movimiento costoso que ‘seleccionar a de tbl’).

Mi propia suposición es que si necesita un flujo de consultas “siempre activo”, relativamente constante, pagaría menos por Redshift.

Si no estás golpeando continuamente la cosa, entonces tus resultados probablemente serían más baratos, y volverían más rápido, con BigQuery. Esto se debe a que puede pensar en BQ como un clúster Redshift masivo y siempre activo, y nunca querría aprovisionar tantas instancias de EC2 para replicar su velocidad.

Edición : 2 años más tarde actualización .

Publiqué esta comparación en reddit. Rápidamente, un practicante de RedShift a largo plazo vino a comentar mis declaraciones. Consulte https://www.reddit.com/r/bigdata … para ver la conversación completa.

Dimensionar su clúster:

• Redshift le pedirá que elija una cantidad de CPU, RAM, HD, etc. y que las encienda.
• A BigQuery no le importa. Úselo cuando lo desee, sin necesidad de aprovisionamiento.

Costos por hora sin hacer nada:

• Redshift le pedirá que pague por hora de cada uno de estos servidores en ejecución, incluso cuando no esté haciendo nada.
• Cuando está inactivo, BigQuery solo le cobra $ 0.02 por mes por GB almacenado. 2 centavos por mes por GB, eso es todo.

Velocidad de consultas:

• El rendimiento de Redshift está limitado por la cantidad de CPU que está pagando
• BigQuery aporta de forma transparente tantos recursos como sea necesario para ejecutar su consulta en segundos.

Indexación:

• Redshift le pedirá que indexe (corrección: distribuya) sus datos bajo ciertos criterios, y solo podrá ejecutar consultas rápidas basadas en este índice.
• BigQuery no tiene índices. Cada operación es rápida.

Pasar la aspiradora:

• Redshift requiere mantenimiento periódico y operaciones de ‘vacío’ que duran horas. Estás pagando por cada una de estas horas de servidor.
• BigQuery no lo hace. Olvídate de ‘aspirar’.

Particionamiento y distribución de datos:

• Redshift requiere que piense en cómo distribuir datos dentro de sus servidores para mantener el rendimiento, una optimización que funciona solo para ciertas consultas.
• BigQuery no lo hace. Simplemente ejecute la consulta que desee.

Transmisión de datos en vivo:

• Imposible (?) Con Redshift.
• BigQuery maneja fácilmente la ingesta de hasta 100,000 filas por segundo por tabla.

Cultivando tu clúster:

• Si tiene más datos o más usuarios concurrentes, la ampliación será dolorosa con Redshift.
• BigQuery simplemente funcionará.

Zona múltiple:

• ¿Desea un Redshift multizona para disponibilidad e integridad de datos? Doloroso.
• BigQuery tiene varias zonas de forma predeterminada.

Para probar BigQuery no necesita una tarjeta de crédito ni ningún tiempo de configuración. Solo pruébalo (instrucciones rápidas para probar BigQuery).
Cuando esté listo para poner sus propios datos en BigQuery, simplemente copie sus registros separados de nueva línea JSON de Google Cloud Storage e impórtelos.
Consulte esta guía detallada sobre los precios del almacén de datos en la nube:
Comprensión de los precios en la nube Parte 3.2 – Más almacenes de datos

No me atrevería a llamar a uno de ellos “mejor” que el otro, ya que son diferentes tipos de bestias.

Redshift es un servicio que debe aprovisionarse para usted: primero debe decidir qué tipo de servidor desea y luego debe encenderlo. Se le cobrará por la cantidad de horas que los servidores se mantienen en línea. (Por favor, alguien que realmente lo esté utilizando verifique esta declaración).

Con Google BigQuery no necesita preocuparse por los servidores o el aprovisionamiento. Solo hay 2 variables que le cobran: la cantidad de datos que carga y la cantidad de datos que consultan sus consultas. El servicio siempre está encendido.

Por ejemplo, puede ir ahora mismo a https://bigquery.cloud.google.com/ y comenzar a consultar cualquiera de los conjuntos de datos públicos. Incluso incluye una cuota de consulta mensual gratuita para que pueda probarla.

¿Quieres saber cuál fue el peso promedio de los niños nacidos durante 1970 en los Estados Unidos? Simplemente cargue https://bigquery.cloud.google.com (cree una cuenta si no tiene una) y ejecute:

SELECCIONE AVG (weight_pounds)
DE [publicdata: samples.natality]
DONDE año = 1970;

Eso es solo el comienzo. Desea comparar 2 productos diferentes, con 2 características diferentes establecidas. La respuesta correcta siempre dependerá de su caso de uso y de lo que esté buscando. El mejor consejo que puedo darle es cargar sus conjuntos de datos privados de CSV o JSON en BigQuery ahora y ver qué tan bien se ajusta a sus necesidades.

A continuación, presento dos puntos de vista complementarios para responder a su pregunta, técnica y comercial, para que saque sus propias conclusiones.

– Desde un punto de vista técnico:

Aquí hay una comparación muy detallada y característica por característica entre Amazon Redshift, Google BigQuery, SlicingDice y otras soluciones, que también cubre muchas de las limitaciones actuales de Redshift. (Abril / 2017)

Hay un punto muy importante a tener en cuenta al comparar BigQuery y SlicingDice con Redshift:

No hay infraestructura / servidor para administrar en BigQuery y SlicingDice. Ambas soluciones son totalmente sin servidor. En Redshift necesita administrar todo (servidor, clúster, etc.) y también hacer muchas optimizaciones.

– Desde el punto de vista del costo:

Es bastante complicado hacer comparaciones, porque todos los modelos de fijación de precios son muy diferentes de una solución a otra y hay muchos “costos ocultos” que se observan cuando comienza a usar cada solución.

De todos modos, aquí hay una comparación de precios muy detallada entre SlicingDice, Google BigQuery, Amazon Redshift, ElasticSearch y Keen IO. (desde abril / 2017).

Algunas consideraciones importantes sobre esta comparación:

1. Si tiene un volumen razonable de datos, digamos, docenas de terabytes que rara vez usa para realizar consultas y es aceptable que tenga tiempos de respuesta de consulta de hasta unos pocos minutos cuando lo usa, entonces Google BigQuery es un excelente candidato para su escenario .
2. Si necesita analizar una gran cantidad de datos (por ejemplo, hasta unos pocos terabytes ) ejecutando muchas consultas, que deben responderse muy rápidamente, y no necesita mantener los datos disponibles una vez que se realiza el análisis, entonces una solución en la nube a pedido como Amazon Redshift es una excelente opción. Pero tenga en cuenta que, a diferencia de Google BigQuery, Redshift necesita configurarse y ajustarse para que funcione bien.
3. Aunque ElasticSearch se usa con mucha frecuencia para almacenar y consultar datos relacionados con el análisis debido a sus excelentes capacidades de agregación, administrar y ajustar un clúster de ElasticSearch puede ser un verdadero problema , incluso con una versión en la nube.
4. Como dijimos antes, Keen IO no es una base de datos ni tiene todas las capacidades de base de datos de otras soluciones, aunque se centran en proporcionar una plataforma de análisis basada en API para almacenar y procesar datos de eventos.
5. Aunque Amazon Redshift y ElasticSearch son utilizados actualmente por miles de empresas como almacenes de datos, la solución única de almacenamiento de datos sin servidor (base de datos real) que compite contra SlicingDice es Google BigQuery, ya que estas otras soluciones son una versión en la nube de un servidor.

(Descargo de responsabilidad: empleado de SlicingDice)

BigQuery tiene algunas ventajas significativas para los clientes de Google. Estos son los 3 beneficios principales:

1. Escalabilidad : Google Big Query es una plataforma SaaS, lo que significa que no debe preocuparse por el autoescalado.
2. Velocidad : Big Query es mucho más rápido, en Redshift depende del tamaño de su clúster. En Big Query esto no importa, incluso si le das un petabyte para procesar, lo procesará en segundos.
3. Costo : con BigQuery simplemente paga en función de los bytes de datos procesados. 1 TB es de $ 5 (el primero cada mes es gratis). En Redshift, tiene que pagar por un clúster, lo que significa que lo está pagando, lo use o no.

En Rivery, trabajamos con clientes que usan ambos (¡los ayudamos a agregar y unificar datos independientemente de su elección!). En este momento parece que Redshift es una opción más popular porque la infraestructura de Amazon más allá de los servicios de datos es más amplia, y además fueron los primeros en comercializar, lo que también les dio una ventaja.

Hilo muy interesante, pero desde mi experiencia, las respuestas simplifican un poco la pregunta.

Claramente en Redshift, pero también en BigQuery, la oferta “desnuda” requiere un trabajo administrativo adicional para funcionar bien.

Solo un ejemplo es la cuestión del rendimiento: estoy de acuerdo con Felipe en que el rendimiento de Google BQ para una consulta determinada es excelente y (ligeramente) superior al de Redshift. Sin embargo, para grandes datos “verdaderos” (cientos de millones de registros y más) no proporcionará los resultados en unos pocos segundos, incluso para consultas simples.

Para lograr un buen rendimiento, necesita particionar bien los datos y / o programar un mecanismo de agregación que reduzca los volúmenes que realmente está escaneando cuando realiza consultas.

En CoolaData trabajamos muy duro para lograr esto (casi) automáticamente: particionamos el evento entrante por tiempo (por lo que las consultas se ejecutan solo en la partición relevante para el período de tiempo consultado), particionamos por eventos (eventos tan frecuentes como “carga de página” no gravar la consulta) y también optimizamos consultas frecuentes a través de agregaciones programadas. Sin hacer este trabajo pesado, el DB “desnudo” todavía deja mucho que desear.

Supongo que lo que digo es que la pregunta no es simplemente qué es mejor entre BQ y Redshift, sino también cómo administras esas plataformas.

Espero que ayude 🙂

Uno de los inconvenientes más importantes que noté sobre Big Query que no se discute en este hilo es su incapacidad para eliminar / actualizar registros dentro de una tabla. La solución alternativa prescrita es esencialmente copiar los registros combinados (original + actualizar / eliminar) en una nueva tabla. Este es un gran inconveniente para las cargas de trabajo de tipo EDW donde hay un requerimiento ocasional de retroceder y volver a cargar datos debido a varias razones. Esta operación de fusión se vuelve costosa y lenta cuando la tabla tiene miles de millones de filas y se agregan diariamente cientos de millones de filas por día.

Aunque como muchos sugirieron, Redshift tiene su propio conjunto de contras, le permite actualizar / fusionar de manera eficiente y eliminar registros de forma transparente.

BigQuery es lo suficientemente bueno si no tiene en cuenta la velocidad de actualización de datos. En comparación con Redshift, Google BigQuery solo admite sincronizaciones por hora como su actualización de frecuencia más rápida. Esto nos hizo elegir Redshift, ya que necesitábamos la solución con soporte de integración de datos casi en tiempo real. Para cargar datos de Salesforce y mantenerlos actualizados en Redshift, elegimos Skyvia, que permite actualizar con frecuencia una vez por minuto.

La respuesta de Kiyoto Tamura a esta pregunta es muy completa e incluso entregada. Quería agregar un par de puntos sobre desarrollos recientes que abordan algunos elementos que mencionó.

El Sr. Tamura analiza el Modelo de precios a pedido de BigQuery y cita que el modelo puede ser “menos predecible y más difícil para que trabaje su equipo de compras”. Para abordar esto, lanzamos los precios de tarifa plana en septiembre de 2016. En precios de tarifa plana los clientes pueden comprar acceso a un conjunto de recursos dedicado (los llamamos espacios) en BigQuery y luego ejecutar todo el trabajo que deseen.

¿Qué es una ranura? Un espacio es la medida de BigQuery del recurso computacional. Es un número de CPU más el ancho de banda de red y la RAM para que funcionen.

Tanto en los modelos de precios a pedido como en tarifa plana, el almacenamiento se vende por separado del cómputo, lo que permite a los clientes escalar sus recursos de manera completamente independiente.

Puede consultar nuestra página de precios para ver más información sobre los modelos de precios de tarifa plana y bajo demanda. Precios | Documentación de BigQuery.

Gracias por tu interés,

Chad

Ver [1] para una comparación de rendimiento entre BigQuery y RedShift.

Los resultados sugieren que BigQuery es mejor para determinar cuánto hardware lanzar en consultas de tipo de escaneo simple, mientras que RedShift es mejor cuando las uniones entran en escena.

[1] http://courses.cs.washington.edu …