Skip to content

Instantly share code, notes, and snippets.

@samuelgmartinez
Created April 10, 2013 13:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save samuelgmartinez/e3610dcd6bc639a0397a to your computer and use it in GitHub Desktop.
Save samuelgmartinez/e3610dcd6bc639a0397a to your computer and use it in GitHub Desktop.
Respuesta a https://twitter.com/hmartinezlopez/status/321943192897462273 que no me cabe en Twitter :)
-- ¡Empezamos YA! sistemas sencillos de implantar y sin necesidad de diseño previo.
No estoy de acuerdo. Casi todos estos sistemas son bastante complejos de implantar y diseñar su despliegue. Hay montón de "blue prints" sobre cómo desplegar estos servicios en tu empresa, pero cada despliegue tiene sus requisitos y sus necesidades.
-- El FIN del DBA. Al ser sistemas más cercanos al desarrollador, podemos optar por prescindir de esta figura.
Tampoco estoy de acuerdo. Casi todos los sistemas necesitan de administradores a tiempo completo, ya que requieren de un mantenimiento por parte de operaciones bastante intensivo y suelen necesitar bastantes métricas de monitorización.
Este mismo argumento puede aplicarse a los sistemas SQL; si tú desarrollas usando una base de datos, no tienes que saber administrarla. El hecho de programar jobs en MR (o en pig, o hive o lo que quiera dios que uses) no tienes por qué conocer la administración del ecosistema. Lo mismo para las bases de datos distribuidas.
Aquí tienes un ejemplo de la certificación de administración para Hadoop por parte de Cloudera: http://university.cloudera.com/training/apache_hadoop/administrator.html
-- Hay escasez de herramientas. Destaca un producto, Hadoop, que además de no ser una base de datos, sino un sistema de ficheros, ofrece otras ventajas como la alta disponibilidad. Es la solución que multitud de fabricantes han embebido en sus soluciones de BigData, entre ellos Oracle.
Aquí hay dos errores. El primero es que Hadoop no es un DSF, es un framework/ecosistema (que entre otras consta de un DSF) para realizar cálculos de manera "segura" (robusta?) y distribuida.
El segundo error es, desde mi punto de vista (este es más personal), que no hay escasez de herramientas, de hecho hay un montón. Si bien es cierto que para MapReduce solo hay Hadoop (MR y YARN), bases de datos distribuidas (como la que nombras: Greenplum) hay un porrón:
- HBase/Hypertable
- Cassandra
- MongoDB
- Riak
- Redis
- DynamoDB (Amazon SaaS database)
Luego hay cosas más específicas como SploutSQL (de los españoles de DataSalt) que permite, usando Hadoop y SQLite, realizar consultas SQL sobre datos ya preagregados en HDFS.
Sobre Hadoop, para seguir con el paradigma MR, hay un porrón de herramientas para facilitar el desarrollo:
- Pangool
- Cascading
- Pig
- Hive
- Crunch
Incluso hay frameworks de computación en tiempo real como puede ser Storm (de Twitter); similar a Hadoop pero orientado a procesado NRT en lugar de batch.
Y seguro que hay más herramientas de big data que no conozco, pero pocas no me parecen.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment