¿Cómo se pueden usar Hadoop y NoSQL para procesar grandes conjuntos de datos en Java?

Actualmente, enero de 2011, la integración entre Hadoop / Mahout y varios sistemas NoSQL no está disponible de forma comercial. Los enfoques simplistas de cosecha propia para esta integración pueden ser tan ineficientes como para anular la ventaja de escala de usar Hadoop; Depende de la aplicación. Del mismo modo, la capacidad de ejecutar Mahout en la nube está cada vez más disponible; No lo he probado, pero es tecnología de punta. Además, ejecutar Hadoop o Mahout en grupos demasiado pequeños generalmente no vale la pena. Si desea seguir esta ruta y aún no tiene los recursos internos, es mejor probarlo en la nube en lugar de comenzar a armar su propio clúster.

Los algoritmos de recomendación parecen ser una especie de punto dulce en el aprendizaje automático en este momento. Pero debe ser consciente de las limitaciones en cualquier enfoque de crowdsourcing (revisiones de venenos por parte de los competidores, astroturfing por parte de las partes interesadas). A los adolescentes y a las amas de casa de todo el mundo (incluidos los EE. UU.) Se les pagan salarios de tiempo completo para falsificar comentarios en los tableros de mensajes. Superar esto requiere un análisis más profundo que el que ofrece la PNL moderna.

Además, es posible que desee considerar enfoques alternativos para el paradigma MapReduce. Los sistemas conexionistas modernos o la teoría de los gráficos pueden dar resultados decentes en configuraciones de máquinas individuales con grandes memorias. El punto óptimo actual es una máquina de 512 GB de RAM (solicite detalles) que ejecute algún Método libre de modelo adecuado. Estos minimizan el esfuerzo humano requerido para el modelado del dominio (ya que son Modelo Libre) y aún pueden devolver resultados decentes. Para ver un ejemplo, vea mi charla sobre Science Beyond Reductionism en http://videos.syntience.com donde analizo el desafío de NetFlix realizado utilizando un enfoque teórico Graph. Estudie un puñado de ejemplos de teoría de grafos utilizados para resolver problemas y comprenderá cómo se hace.

Desea realizar el procesamiento fuera de línea de los artículos y luego entregar los resultados que se calculan. Este es un patrón común.

No intente ejecutar su procesamiento en el almacén de datos en vivo como lo han sugerido otros en este hilo, esta es una muy mala idea.

En su lugar, realice su procesamiento en Hadoop como lo describió, y luego implemente los resultados en algún sistema de almacenamiento donde se pueda servir. Esto permite que su procesamiento fuera de línea sea tan computacionalmente intensivo como sea necesario sin dañar el servicio en línea.

Si está intentando elegir una solución de almacenamiento adecuada, esto es lo que debe pensar:

  1. ¿Cuál es el costo de la carga de datos? Si cargar datos es muy costoso, no podrá actualizar los resultados fácilmente. El cambio de estructuras persistentes suele ser una operación muy costosa, por lo que si realiza este tipo de carga una secuencia de modificaciones de btree, esto puede ser prohibitivamente costoso para un conjunto de datos de gran tamaño.
  2. ¿Cuántos datos se pueden almacenar por nodo y servir con un tiempo de respuesta adecuado?
  3. ¿Qué tipo de conmutación por error es compatible?
  4. ¿Cómo se manejará la transferencia y actualización de datos reales? Por ejemplo, en un RDMS puede tener dos tablas, una en vivo y otra en uso para cargar nuevos datos y una vista que apunta a la activa.

Así es como hacemos esto en LinkedIn:

Los datos se proporcionan desde el Proyecto Voldemort ( http://project-voldemort.com ) utilizando tiendas de solo lectura. Esto nos permite dividir los datos en un grupo de máquinas y elegir un factor de replicación para cada conjunto de datos con conmutación por error automática.

Estas tiendas están construidas en Hadoop utilizando un trabajo incluido en la sección contrib de voldemort. Esto significa que el costoso trabajo de creación de tiendas se realiza realmente en el sistema fuera de línea en lugar del sistema en línea, por lo que no afecta el servicio en vivo. La estructura de la tienda está optimizada para permitir la construcción rápida en el mapa / reducir, y podemos construir una tienda en un solo pase de mapa / reducción (muy barato) que utiliza el tipo incorporado para todo el trabajo duro.

La estructura de almacenamiento real es solo una estructura de índice inmutable mapeada en memoria simple y puede soportar una relación muy alta de datos a memoria.

Con este complemento de contribución hadoop, Voldemort admite la capacidad de obtener tiendas de HDFS y hacerlas vivir sin ningún tiempo de inactividad. Usamos esto para servir a docenas de conjuntos de datos fuera de línea, algunos de los cuales contienen decenas de miles de millones de elementos precalculados.

Aquí se describen más detalles sobre esta configuración:
http://sna-projects.com/blog/200