|
Translate
viernes, 8 de marzo de 2019
Seminario web de MongoDB
Me llego un mail de la gente de MongoDB y quería compartirlo con ustedes:
miércoles, 6 de marzo de 2019
Libros gratuitos de Java Code Geeks
Download Dev Guides!
martes, 5 de marzo de 2019
Snitches en Cassandra
El trabajo de un snitch es determinar la proximidad del host relativa para cada nodo en un clúster, que se utiliza para determinar de qué nodos leer y escribir. Los snitches recopilan información sobre la topología de su red para que Cassandra pueda enrutar las solicitudes de manera eficiente. El snitch descubrirá dónde están los nodos en relación con otros nodos.
A modo de ejemplo, examinemos cómo participa el snitch en una operación de lectura. Cuando Cassandra realiza una lectura, debe contactar una cantidad de réplicas determinadas por el nivel de consistencia. Para admitir la velocidad máxima para las lecturas, Cassandra selecciona una única réplica para consultar el objeto completo y solicita réplicas adicionales para los valores de hash para garantizar que se devuelva la última versión de los datos solicitados. La función de el snitch es ayudar a identificar la réplica que devolverá este dato de forma rápida, y esta es la réplica que se consulta para obtener los datos completos.
El snitch predeterminado (el SimpleSnitch) es la topología inconsciente; es decir, no conoce los racks y los centros de datos en un clúster, lo que lo hace inadecuado para implementaciones de centros de datos múltiples. Por esta razón, Cassandra viene con varios snitches para diferentes entornos de nube, incluyendo Amazon EC2, Google Cloud y Apache Cloudstack.
Los snitches se pueden encontrar en el paquete org.apache.cassandra.locator. Cada snitch implementa la interfaz IEndpointSnitch.
Si bien Cassandra proporciona una manera conectable de describir de forma estática la topología de su clúster, también proporciona una función llamada "snitching dinámico" que ayuda a optimizar el enrutamiento de las lecturas y escrituras a lo largo del tiempo. Así es como funciona. Su snitch seleccionado se envuelve con otro snitch llamado DynamicEndpointSnitch. El snitch dinámico obtiene su comprensión básica de la topología de la snitch seleccionada. A continuación, supervisa el rendimiento de las solicitudes a los otros nodos, e incluso realiza un seguimiento de cosas como qué nodos realizan la compactación. Los datos de rendimiento se utilizan para seleccionar la mejor réplica para cada consulta. Esto permite a Cassandra evitar las solicitudes de enrutamiento a réplicas que tienen un bajo rendimiento.
La implementación de snitching dinámico utiliza una versión modificada del mecanismo de detección de fallas Phi utilizado por los Gossiper(que hablamos el post anterior). El "umbral de maldad" es un parámetro configurable que determina cuánto peor debe realizar un nodo preferido que el nodo con el mejor desempeño para perder su estado preferencial. Las puntuaciones de cada nodo se restablecen periódicamente para permitir que un nodo con un rendimiento deficiente demuestre que se ha recuperado y reclamar su estado preferido.
A modo de ejemplo, examinemos cómo participa el snitch en una operación de lectura. Cuando Cassandra realiza una lectura, debe contactar una cantidad de réplicas determinadas por el nivel de consistencia. Para admitir la velocidad máxima para las lecturas, Cassandra selecciona una única réplica para consultar el objeto completo y solicita réplicas adicionales para los valores de hash para garantizar que se devuelva la última versión de los datos solicitados. La función de el snitch es ayudar a identificar la réplica que devolverá este dato de forma rápida, y esta es la réplica que se consulta para obtener los datos completos.
El snitch predeterminado (el SimpleSnitch) es la topología inconsciente; es decir, no conoce los racks y los centros de datos en un clúster, lo que lo hace inadecuado para implementaciones de centros de datos múltiples. Por esta razón, Cassandra viene con varios snitches para diferentes entornos de nube, incluyendo Amazon EC2, Google Cloud y Apache Cloudstack.
Los snitches se pueden encontrar en el paquete org.apache.cassandra.locator. Cada snitch implementa la interfaz IEndpointSnitch.
Si bien Cassandra proporciona una manera conectable de describir de forma estática la topología de su clúster, también proporciona una función llamada "snitching dinámico" que ayuda a optimizar el enrutamiento de las lecturas y escrituras a lo largo del tiempo. Así es como funciona. Su snitch seleccionado se envuelve con otro snitch llamado DynamicEndpointSnitch. El snitch dinámico obtiene su comprensión básica de la topología de la snitch seleccionada. A continuación, supervisa el rendimiento de las solicitudes a los otros nodos, e incluso realiza un seguimiento de cosas como qué nodos realizan la compactación. Los datos de rendimiento se utilizan para seleccionar la mejor réplica para cada consulta. Esto permite a Cassandra evitar las solicitudes de enrutamiento a réplicas que tienen un bajo rendimiento.
La implementación de snitching dinámico utiliza una versión modificada del mecanismo de detección de fallas Phi utilizado por los Gossiper(que hablamos el post anterior). El "umbral de maldad" es un parámetro configurable que determina cuánto peor debe realizar un nodo preferido que el nodo con el mejor desempeño para perder su estado preferencial. Las puntuaciones de cada nodo se restablecen periódicamente para permitir que un nodo con un rendimiento deficiente demuestre que se ha recuperado y reclamar su estado preferido.
lunes, 4 de marzo de 2019
Gossip y Detección de fallos en Apache Cassandra
Para admitir la descentralización y la tolerancia de partición, Cassandra usa un protocolo de Gossip que permite a cada nodo realizar un seguimiento de la información de estado sobre los otros nodos en el clúster. El gossiper se ejecuta cada segundo en un temporizador.
Los protocolos de Gossip (a veces llamados "protocolos epidémicos") generalmente asumen una red defectuosa, se emplean comúnmente en sistemas de redes muy grandes y descentralizados, y se usan a menudo como un mecanismo automático para la replicación en bases de datos distribuidas.
Toman su nombre del concepto de chisme humano, una forma de comunicación en la que los compañeros pueden elegir con quién desean intercambiar información y no solo intercambian información de ellos mismos sino tambien de otros compañeros, lo que permite disminuir el trafico de la red, ya que no todos se comunican con todos.
El protocolo de Gossip en Cassandra se implementa principalmente mediante la clase org.apache.cassandra.gms.Gossiper, que es responsable de administrar los chismes para el nodo local. Cuando se inicia un nodo de servidor, se registra con el gossiper para recibir información del estado del punto final.
Debido a que los Gossip de Cassandra se usan para la detección de fallas, la clase Gossiper mantiene una lista de nodos que están vivos y muertos.
Así es como funciona el Gossiper:
- Una vez por segundo, el Gossiper elegirá un nodo aleatorio en el clúster e iniciará una sesión de chismes con él. Cada ronda de chismes requiere tres mensajes.
- El iniciador de chismes envía a su amigo elegido un GossipDigestSynMessage.
- Cuando el amigo recibe este mensaje, devuelve un GossipDigestAckMessage.
- Cuando el iniciador recibe el mensaje de acuse de recibo del amigo, le envía un mensaje de GossipDigestAck2 para que complete la ronda de chismes.
Cuando el Gossiperer determina que otro punto final está muerto, "condena" ese punto final al marcarlo como muerto en su lista local y registrar ese hecho.
Cassandra tiene un soporte robusto para la detección de fallas, como lo especifica un algoritmo popular para la computación distribuida llamada Phi Accrual Failure Detection. Esta forma de detección de fallas se originó en el Instituto Avanzado de Ciencia y Tecnología en Japón en 2004.
La detección del fracaso acumulado se basa en dos ideas principales. La primera idea general es que la detección de fallas debe ser flexible, lo que se logra al desacoplarla de la aplicación que se está monitoreando. La segunda y más novedosa idea desafía la noción de detectores de falla tradicionales, que se implementan mediante simples "latidos" y deciden si un nodo está muerto o no, según si se recibe un latido o no. Pero la detección de fallos acumulados decide que este enfoque es ingenuo, y encuentra un lugar entre los extremos de muertos y vivos, un nivel de sospecha.
Por lo tanto, el sistema de monitoreo de fallas genera un nivel continuo de "sospecha" con respecto a la confianza de que un nodo ha fallado. Esto es deseable porque puede tener en cuenta las fluctuaciones en el entorno de red. Por ejemplo, solo porque una conexión quede atrapada no significa necesariamente que todo el nodo esté muerto.
Por lo tanto, la sospecha ofrece una indicación más fluida y proactiva de la posibilidad de falla más débil o más fuerte basada en la interpretación (el muestreo de los latidos), en lugar de una simple evaluación binaria.
La detección de fallos se implementa en Cassandra mediante la clase org.apache.cassandra.gms.FailureDetector, que implementa la interfaz org.apache.cassandra.gms.IFailureDetector. Juntos, permiten operaciones que incluyen:
- isAlive (InetAddress) : Lo que el detector informará sobre la vida de un nodo dado.
- interpret (InetAddress): Utilizado por el Gossiper para ayudarlo a decidir si un nodo está vivo o no basado en nivel de sospecha alcanzado mediante el cálculo de Phi.
- report (InetAddress) : Cuando un nodo recibe un latido, invoca este método.
domingo, 3 de marzo de 2019
La arquitectura de Cassandra
Vamos a examinar la arquitectura de Apache Cassandra, para entender como trabaja. Los nodos interactúan de un modo peer-to-peer o punto a punto, y para conocer donde están los datos utilizan técnicas de gossip, anti-entropy y hinted handoff que vamos a ir desarrollando en este post y los próximos.
Cassandra nos permite separar nuestros nodos en racks y datacenters, esto nos da ventajas a la hora de tener los datos separados en diferentes ubicaciones geográficas. Un rack en un conjunto de nodos , físicamente tiene en cuenta que un rack siempre son maquinas que están próximas, idealmente en un mismo rack. Un datacenter es un conjunto de rack que se encuentran en el mismo edificio físico y conectadas a la misma red.
Cassandra aprovecha la información que proporciona sobre la topología de su clúster para determinar dónde almacenar los datos y cómo encaminar las consultas de manera eficiente. Cassandra intenta almacenar copias de sus datos en múltiples centros de datos para maximizar la disponibilidad y la tolerancia de partición, mientras que prefiere enrutar las consultas a los nodos en el centro de datos local para maximizar el rendimiento.
sábado, 2 de marzo de 2019
Quiero recomendar el curso “AI for Everyone”
El amigo Andrew Ng me invito a hacer un curso gratuito en coursera sobre Inteligencia artificial:
Yo que ustedes le hago caso y me anoto!!
| |||||||||||||
|
Yo que ustedes le hago caso y me anoto!!
miércoles, 27 de febrero de 2019
Libros de Java Code Geeks
|
Modelo lógico de datos de Apache HBase
Hbase provee row
keys, concepto que podemos mapear con las primary keys de las bases
de datos relacionales. Nosotros podemos trabajar sin grandes
operaciones de lectura y escritura, dado que las filas estan
divididas en columns families y columnas. Esto soporta escalado
vertical y horizontal de las tablas.
Una tabla esta
compuesta por filas→ familias de columnas → columnas → celdas
Por lo tanto podemos
pensar en una fila como un conjunto no vacio de familias de columnas,
la familia de columnas como un conjunto no vacio de columnas y las
columnas son estan formadas (made up) por celdas. Y los datos son
accedidos por el row key.
Nosotros podemos o debemos consultar por row key más el column family y el nombre de la
columna.
A nivel conceptual,
las tablas de hbase vistas como un conjunto separado de filas pero a
nivel fisico, se guardan conjuntos de columnas que son las familias
de columnas.
A nivel conceptual, una tabla HBase se puede ver como un conjunto disperso de filas, pero en el almacenamiento real, se almacena según una familia de columnas. Al definir una tabla, las columnas se pueden agregar o especificar en la ejecución en una familia de columnas. Debemos decidir el número y el nombre de la familia de columnas en el momento de la reactivación de la tabla, pero las columnas se pueden agregar según sea necesario en cualquier momento mientras se almacenan los datos, y esta es la belleza de la ausencia de esquemas cuando usamos HBase.
Una columna siempre se representa y se accede utilizando el nombre de la familia de columnas como prefijo (columnfamilyname: columnname) para que sepamos a qué familia de columnas se accede. Las columnas que no contienen valores no se almacenan.
En las versiones anteriores de HBase, no teníamos un concepto de base de datos; sin embargo, existía el concepto de Tabla. La versión más reciente de HBase introduce un concepto llamado espacio de nombres (compatible con HBase 0.96 y versiones posteriores) que agrupa las tablas de forma lógica, lo que brinda una representación más estructurada y organizada, y un almacenamiento de tablas.
domingo, 24 de febrero de 2019
Relacional vs. HBase Schemas
No hay una asignación uno a uno de las bases de datos relacionales a HBase. En el diseño relacional, el enfoque y el esfuerzo están alrededor de describir la entidad y su interacción con otras entidades.
Pero con HBase, tiene un diseño de esquema de "consulta primero"; todas las posibles consultas deben identificarse primero, y el modelo de esquema debe diseñarse en consecuencia. Debes diseñar tu esquema HBase para aprovechar las fortalezas de HBase. Piense en sus patrones de acceso y diseñe su esquema para que los datos que se leen juntos se almacenen juntos. Recuerde que HBase está diseñado para agrupación. Por lo tanto tenemos que tener en cuenta estos 3 puntos a la hora de diseñar una estema hbase:
- Los datos distribuidos se almacenan y se accede juntos.
- Se centra en las consultas, así que concéntrese en cómo se leen los datos
- Diseño para las consultas.
En una base de datos relacional, la normalización de el esquema tiene como beneficios:
- No tiene que actualizar varias copias cuando se produce una actualización, lo que hace que las escrituras sean más rápidas.
- Reduce el tamaño de almacenamiento al tener una sola copia en lugar de varias copias.
- Sin embargo, esto provoca uniones o joins. Como los datos deben recuperarse de más tablas, las consultas pueden tardar más tiempo.
En un almacén de datos des-normalizado, almacena en una tabla lo que serían múltiples índices en un mundo relacional. La des-normalización puede considerarse como un reemplazo para las uniones. A menudo, con HBase, des-normaliza o duplica datos para que los datos se accedan y almacenen juntos.
Este es un ejemplo de desnormalización en HBase, si sus tablas existen en una relación de uno a varios, es posible modelarlo en HBase como una sola fila. Esto hace que las lecturas sean mucho más rápidas que unir tablas.
La clave de fila corresponde al ID de entidad principal, el Id. para HBase puede ser una familia de columnas para los datos. Este tipo de diseño de esquema es apropiado cuando la única forma de acceder a las entidades secundarias es a través de la entidad principal.
jueves, 21 de febrero de 2019
Amazon Corretto
Amazon me esta sorprendiendo y para bien, ultimamente.
Amazon permite bajar su OpenJDK: Amazon Corretto. La cual no tiene costo, es multiplataforma y lista para producción.
Corretto viene con soporte a largo plazo que incluirá mejoras de rendimiento y correcciones de seguridad. Para el que no la conocía, Amazon ejecuta Corretto internamente en miles de servicios de producción y Corretto está certificado como compatible con el estándar Java SE. Con Corretto, puede desarrollar y ejecutar aplicaciones Java en sistemas operativos populares, incluidos Linux, Windows, macOS y hasta Docker.
Actualmente podemos bajar la version 8 o la preview de la 11 :
Installation Guides for Corretto 8
Installation Guides for Corretto 11 Preview
Dejo link: https://aws.amazon.com/corretto/
martes, 19 de febrero de 2019
AdoptOpenJDK
El código de Java es de código abierto y está disponible en la OpenJDK. AdoptOpenJDK proporciona binarios OpenJDK creados previamente a partir de un conjunto de código totalmente abierto de scripts de compilación e infraestructura.
Con AdoptOpenJDK podemos obtener imágenes de Docker en Docker Hub, con la open que necesitemos. A la vez podemos obtener las últimas versiones. Y se pueden obtener Nightly builds.
Las plataformas que son soportadas son:
Linux x64
jdk8u202-b08
Windows x32
jdk8u202-b08
Windows x64
jdk8u202-b08
macOS x64
jdk8u202-b08
Linux s390x
jdk8u202-b08
Linux ppc64le
jdk8u202-b08
Linux aarch64
jdk8u191-b12
Solaris sparcv9
jdk8u202-b08
AIX ppc64
jdk8u202-b08
Docker
Official Image
Dejo link: https://adoptopenjdk.net/releases.html
lunes, 18 de febrero de 2019
Apache ZooKeeper
Ya hablamos de Apache ZooKeeper varias veces, pero de costado. Es decir hablando de otros productos relacionados con el mundo hadoop, y a la vez hablamos de él. Y por que tantas veces tuvimos que hablar de este producto? porque este producto, como lo indica su nombre, se encarga de cuidar las bestias que son todos los productos hadoop.
ZooKeeper tiene integración con todos los productos, dado que es es encargado de monitoriar su trabajo. ZooKeeper es un servicio centralizado para mantener la información de configuración, asignar nombres, proporcionar sincronización distribuida y proporcionar servicios de grupo. Todos estos tipos de servicios son utilizados de una forma u otra por las aplicaciones distribuidas. Cada vez que se implementan, hay un montón de trabajo que consiste en solucionar estos problemas. Debido a la dificultad de implementar este tipo de servicios, al principio las aplicaciones generalmente los escatiman, lo que los hace frágiles este tipo de aplicaciones frente al cambio y difíciles de administrar. Incluso cuando se realizan correctamente, las diferentes implementaciones de estos servicios conducen a la complejidad de la administración cuando se implementan las aplicaciones.
ZooKeeper apunta a destilar la esencia de estos diferentes servicios en una interfaz muy simple a un servicio de coordinación centralizado. El servicio en sí es distribuido y altamente confiable. El servicio implementará los protocolos de consenso, administración de grupos y presencia para que las aplicaciones no tengan que implementarlas por su cuenta. Los usos específicos de la aplicación consistirán en una mezcla de componentes específicos de ZooKeeper y las convenciones específicas de la aplicación. ZooKeeper Recipes muestra cómo este simple servicio se puede usar para construir abstracciones mucho más poderosas.
Espero que este post les abra el apetito del conocimiento dado que vamos a analizar más este producto. Dejo link: https://zookeeper.apache.org/
Spark y HBase
Tuve que conectar una aplicación spark con hbase con scala y sbt y scalatra... etc...
primero vamos a ver a build.sbt :
val ScalatraVersion = "2.6.3"
organization := "com.hexacta"
name := "Sparklatra"
version := "0.1.0-SNAPSHOT"
scalaVersion := "2.11.8"
resolvers += Classpaths.typesafeReleases
resolvers += "Cloudera Repository" at "https://repository.cloudera.com/content/repositories/releases/"
resolvers += "Cloudera Repository2" at "https://repository.cloudera.com/artifactory/cloudera-repos/"
libraryDependencies ++= Seq(
"org.scalatra" %% "scalatra" % ScalatraVersion ,
"org.scalatra" %% "scalatra-scalatest" % ScalatraVersion % "test" ,
"ch.qos.logback" % "logback-classic" % "1.2.3" % "runtime" ,
"org.eclipse.jetty" % "jetty-webapp" % "9.4.9.v20180320" % "container" ,
"javax.servlet" % "javax.servlet-api" % "3.1.0" % "provided" ,
"com.sun.jersey" % "jersey-core" % "1.19.4" ,
"com.sun.jersey" % "jersey-server" % "1.19.4" ,
"org.apache.spark" % "spark-core_2.11" % "2.3.1",
"org.apache.spark" %% "spark-sql" % "2.3.1",
"org.apache.spark" %% "spark-streaming" % "2.3.1" ,
"org.apache.hbase" % "hbase-spark" % "2.1.0-cdh6.1.1" intransitive() ,
"org.apache.hbase" % "hbase-server" % "2.1.0-cdh6.1.1" intransitive() ,
"org.apache.hbase" % "hbase-mapreduce" % "2.1.0-cdh6.1.1" intransitive() ,
"org.apache.hbase" % "hbase-common" % "2.1.0" exclude("com.fasterxml.jackson.core", "jackson-databind"),
"org.apache.hbase" % "hbase-client" % "2.1.0" exclude("com.fasterxml.jackson.core", "jackson-databind")
)
enablePlugins(SbtTwirl)
enablePlugins(ScalatraPlugin)
Ahora vamos hacer un ejemplito, de un metodo get que insertar y consultar :
get(s"/testSparkHbase/:key/:value") {
val conf : Configuration = HBaseContext.getConf()
// cree la tabla
// create 'TableTest', 'info'
// put 'TableTest', 'rowkey1', 'info:test', 'ejemplo'
val connection = ConnectionFactory.createConnection(conf)
val hbaseContext = new org.apache.hadoop.hbase.spark.HBaseContext(SparkContext.getSc, conf)
val tableName = "TableTest"
val columnFamily = "info"
val rdd = SparkContext.getSc.parallelize(Array(
(Bytes.toBytes(params("key")),
Array((Bytes.toBytes(columnFamily), Bytes.toBytes("test"), Bytes.toBytes(params("value")))))))
hbaseContext.bulkPut[(Array[Byte], Array[(Array[Byte], Array[Byte], Array[Byte])])](rdd,
TableName.valueOf(tableName),
(putRecord) => {
val put = new Put(putRecord._1)
putRecord._2.foreach((putValue) =>
put.addColumn(putValue._1, putValue._2, putValue._3))
put
});
Ok("ok")
}
get(s"/testSparkHbase/:key") {
val conf : Configuration = HBaseContext.getConf()
// cree la tabla
// create 'TableTest', 'info'
// put 'TableTest', 'rowkey1', 'info:test', 'ejemplo'
val connection = ConnectionFactory.createConnection(conf)
val hbaseContext = new org.apache.hadoop.hbase.spark.HBaseContext(SparkContext.getSc, conf)
val tableName = "TableTest"
val columnFamily = "info"
val rdd = SparkContext.getSc.parallelize(Array(Bytes.toBytes(params("key"))))
val getRdd = rdd.hbaseBulkGet[String](hbaseContext, TableName.valueOf(tableName), 2,
record => {
System.out.println("making Get"+ record.toString)
new Get(record)
},
(result: Result) => {
val it = result.listCells().iterator()
val b = new StringBuilder
b.append(Bytes.toString(result.getRow) + ":")
while (it.hasNext) {
val cell = it.next()
val q = Bytes.toString(CellUtil.cloneQualifier(cell))
if (q.equals("counter")) {
b.append("(" + q + "," + Bytes.toLong(CellUtil.cloneValue(cell)) + ")")
} else {
b.append("(" + q + "," + Bytes.toString(CellUtil.cloneValue(cell)) + ")")
}
}
b.toString()
})
getRdd.collect().foreach(v => println(v))
var result = ListBuffer[String]()
getRdd.collect().foreach(v => result += v)
Ok(compact(render(result)))
}
}
Dejo el git: https://github.com/emanuelpeg/spark-scalatra
Suscribirse a:
Entradas (Atom)