La Conferencia Hydra se llevará a cabo del 11 al 12 de julio en San Petersburgo, dedicada al desarrollo de sistemas paralelos y distribuidos. La característica de Hydra es que combina científicos geniales (que generalmente se pueden encontrar solo en conferencias científicas extranjeras) e ingenieros practicantes famosos, en un gran programa en la intersección de la ciencia y la práctica.
Hydra es una de nuestras conferencias más importantes en los últimos años. Fue precedida por una preparación muy seria, la selección de oradores e informes. La semana pasada , se publicó una entrevista con el director de la compañía JUG.ru Group, Alexei Fedorov ( 23derevo ).
Ya hemos hablado de tres participantes importantes, los fundadores de la teoría de los sistemas distribuidos: Leslie Lamport, Maurice Herlichi y Michael Scott. ¡Es hora de hablar más sobre todo el programa!
Motivación
Si está programando, entonces de alguna manera se trata de computación multiproceso y distribuida. Los expertos en los campos relevantes trabajan directamente con ellos, pero implícitamente la distribución nos mira desde todas partes: en cualquier computadora multinúcleo o servicio distribuido hay algo paralelo al cálculo.
Hay muchas conferencias que revelan varios aspectos de la programación de aplicaciones. En el otro lado del espectro, tenemos escuelas científicas especiales que, en el formato de conferencias, revelan enormes volúmenes de teoría compleja. Por ejemplo, la escuela SPTDC funciona en paralelo con Hydra en San Petersburgo. En Hydra, tratamos de unir prácticas duras, ciencia y todo lo que se unía.
Piense en esto: vivimos en un momento increíble cuando puede conocer a los fundadores del campo de la ciencia y la ingeniería en los que estamos involucrados. Los físicos no se encontrarán con Newton ni con Einstein: el tren se fue. Pero todavía hay personas que viven cerca de nosotros que crearon los fundamentos de la teoría de los sistemas distribuidos, idearon lenguajes de programación populares y, por primera vez, incorporaron todo esto en prototipos funcionales. Estas personas no han abandonado su trabajo a mitad de camino, ahora se dedican a tareas urgentes en universidades y empresas de fama mundial, y son las mayores fuentes de conocimiento y experiencia hasta la fecha.
Por otro lado, la oportunidad de reunirse con ellos generalmente sigue siendo puramente teórica: pocos de nosotros podemos monitorear constantemente los eventos públicos en cualquier Universidad de Rochester, luego correr a los Estados Unidos y regresar a una conferencia con Michael Scott. Visitar a todos los participantes de Hydra en general estaría en un estado pequeño, sin contar el abismo del tiempo empleado (aunque esto suena como una búsqueda interesante).
Por otro lado, tenemos muchos ingenieros superiores que están trabajando en problemas urgentes de sistemas distribuidos en este momento, y definitivamente tienen algo que contar. Pero aquí está el problema: trabajan y su tiempo es costoso. Sí, si usted es un empleado de Microsoft, Google o JetBrains, la probabilidad de conocer a uno de los oradores conocidos en un evento interno aumenta dramáticamente, pero en general, no, no todos los días sucede.
Por lo tanto, la conferencia Hydra cumple una tarea importante que la mayoría de nosotros no podemos hacer por nosotros mismos, en un solo lugar y al mismo tiempo, reúne a personas cuyas ideas o comunicación con quienes pueden cambiar su vida. Admito que no todos necesitan sistemas distribuidos, algunas cosas fundamentales complejas. Puede programar CRUD en PHP por el resto de su vida y permanecer completamente feliz. Pero quién lo necesita es tu oportunidad.
Ha pasado mucho tiempo desde el primer anuncio de la conferencia de Hydra sobre Habré. Durante este tiempo, se ha realizado mucho trabajo, y ahora tenemos una lista de casi todos los informes. ¡Sin algoritmos lentos de un solo subproceso, solo puro hardcore distribuido! Terminemos con palabras generales y veamos lo que tenemos a mano ahora.
Notas clave
Las conferencias magistrales comienzan y terminan los días de la conferencia. Por lo general, el significado de la nota de apertura es establecer el espíritu general y la dirección de la conferencia. La nota final cierra una línea y explica cómo vivir con el conocimiento y las habilidades adquiridas durante los días de la conferencia. Principio y fin: lo que será recordado lo mejor de todo, y en general, es de mayor importancia.
Cliff es una leyenda en el mundo de Java. A finales de los 90, para su tesis doctoral, escribió un artículo titulado Combinando análisis, combinando optimizaciones , que después de un tiempo se convirtió en la base del compilador de servidores HotSpot JVM. Dos años después, ya trabajó en Sun Microsystems en JVM y le mostró al mundo que JIT tiene derecho a existir. Toda la historia de que Java es uno de los tiempos de ejecución modernos más rápidos con las optimizaciones más inteligentes y rápidas provino de Cliff Click. Al principio, se creía que si algo está disponible para el compilador estático, ni siquiera puede intentar jit. Gracias al trabajo de Cliff y el equipo, todos los nuevos idiomas comenzaron a crearse con la idea de la compilación JIT predeterminada. Por supuesto, este no era un trabajo para una persona, pero Cliff jugó un papel muy importante en él.
En el discurso de apertura, Cliff hablará sobre su otro esfuerzo: el H20 , una plataforma en memoria para aprendizaje automático distribuido y escalable para aplicaciones industriales. O más bien, sobre el almacenamiento distribuido de pares clave-valor dentro de él. Este es un repositorio muy rápido con muchas propiedades interesantes (la lista exacta se encuentra en la descripción ) que le permite usar soluciones similares en las matemáticas de la transmisión de datos grandes.
Otra charla que Cliff dará es la experiencia de la memoria transaccional de hardware azul . Otra parte de su biografía es diez años de trabajo en Azul , donde actualizó y mejoró muchas cosas en hardware y la pila de tecnología Azul: compiladores JIT, tiempo de ejecución, modelo de subprocesos, manejo de errores, trabajo de pila, interrupciones de hardware, carga de clases, etc. así, bueno, entiendes el punto.
La parte más interesante comenzó cuando crearon hardware para grandes empresas: una supercomputadora para ejecutar Java. Fue algo bastante innovador, afilado específicamente para Java, que tiene requisitos especiales: barreras de memoria para la lectura para la recolección de basura en pozos bajos, matrices con verificación de bordes, llamadas virtuales ... Una de las mejores tecnologías es la memoria transaccional de hardware. Todos los L1 de cualquiera de los 864 núcleos podrían participar en la escritura transaccional, lo cual es especialmente importante para trabajar con bloqueos en Java (los bloques sincronizados pueden funcionar en paralelo, siempre que no haya un conflicto real de memoria). Pero una hermosa idea se estrelló contra la dura realidad, y en este informe, Cliff explicará por qué HTM y STM no son muy adecuados para las necesidades prácticas de la computación multiproceso.
Michael Scott es profesor de informática en la Universidad de Rochester, con quien el destino lo ha vinculado durante 34 años , y en la universidad de origen de Wisconsin - Madison, fue decano durante cinco años. Se dedica a la investigación en el campo de la programación paralela y distribuida y el diseño del lenguaje y enseña a los estudiantes esto.
Todo el mundo conoce a Michael gracias al libro de texto "Programming Language Pragmatics" , cuya última edición fue lanzada relativamente recientemente, en 2015. Su trabajo , Algoritmos para sincronización escalable en multiprocesadores de memoria compartida, recibió el Premio Dijkstra como uno de los más famosos en el campo de la informática distribuida y se encuentra abiertamente en la biblioteca en línea de la Universidad de Rochester. También puede conocerlo como el autor del mismo algoritmo de Michael-Scott de "Algoritmos de cola concurrentes simples, rápidos y prácticos que no bloquean y bloquean" .
En cuanto al mundo Java, este es un caso especial: junto con Doug Lea, desarrolló esos algoritmos sin bloqueo y colas sincrónicas que ejecutan las bibliotecas Java. Esto es exactamente lo que será la nota clave de las estructuras de datos duales: la introducción de estas estructuras en Java SE 6 permitió 10 veces mejorar el rendimiento de java.util.concurrent.ThreadPoolExecutor . Si le interesa de antemano cuáles son estas "estructuras de datos duales", entonces hay un trabajo correspondiente al respecto.
Maurice Herlichi es el ganador de dos premios Dijkstra. El primero es para trabajar en Sincronización sin esperas (Brown University), y el segundo, más reciente, es Memoria transaccional: Soporte arquitectónico para estructuras de datos sin bloqueo (Virginia Tech University). El Premio Dijkstra se otorga por obras cuya importancia e influencia han sido notables durante al menos diez años, y, obviamente, Maurice es uno de los especialistas más famosos en el campo. Actualmente trabaja como profesor en la Universidad de Brown y tiene muchos logros para un párrafo completo.
En esta nota final de cierre, Maurice hablará sobre la teoría y la práctica de los sistemas distribuidos de blockchain en términos de los clásicos de la computación distribuida y cómo esto simplifica muchos problemas relacionados. Este informe es exclusivamente sobre el tema de la conferencia, no sobre la exageración de la minería, sino sobre cómo nuestro conocimiento puede ser increíblemente efectivo y apropiado para aplicarlo a una variedad de tareas.
En julio de 2017, Maurice llegó a Rusia en la escuela SPTDC, participó en el mitin JUG.ru y la grabación se puede ver en YouTube:
Programa principal
A continuación se realizará una breve revisión de los informes incluidos en el programa. Algunos de los informes se describen en detalle aquí, y algunos son más cortos. Se obtuvieron descripciones extensas principalmente en informes en inglés que requieren enlaces a artículos científicos, términos en Wikipedia, etc. La lista completa se puede ver en el sitio web de la conferencia . La lista en el sitio será actualizada y complementada.
Leslie Lampport es el autor del trabajo fundamental en computación distribuida. LaTeX significa Lamport TeX. Esta es la primera vez que presenta el concepto de consistencia consistente en 1979, y su artículo "Cómo hacer una computadora multiprocesador que ejecute correctamente programas multiprocesador" ganó el Premio Dijkstra.
Esta es la parte más inusual del programa en términos de formato, porque ni siquiera es un informe, sino una sesión de preguntas y respuestas. Cuando una parte importante de la audiencia ya está familiarizada (o puede familiarizarse) con todo tipo de trabajos basados en la "teoría de Lamport", sus propios artículos e informes, es importante dedicar todo el tiempo disponible a la comunicación directa.
La idea es simple: ves dos informes en YouTube: "La programación debería ser más que codificación" y "Si no estás escribiendo un programa, no uses un lenguaje de programación" y preparas al menos una pregunta, y Leslie responde.
El primero de estos dos videos ya nos hemos convertido en habrosta . Si no tiene una hora para ver el video, puede leer todo esto rápidamente en texto.
Nota: hay muchos más videos de Leslie Lamport en YouTube. Por ejemplo, hay un excelente curso TLA + . La versión fuera de línea de todo este curso se encuentra en la página de inicio del autor , y en YouTube la subió para facilitar su visualización en dispositivos móviles.
Martin Kleppmann es investigador en la Universidad de Cambridge y trabaja en CRDT y verificación formal de algoritmos. El libro de Martin , Diseño de aplicaciones intensivas en datos , publicado en 2017, demostró ser muy exitoso y llegó a la lista de los más vendidos en el campo del almacenamiento y procesamiento de datos. Kevin Scott, CTO de Microsoft, dijo una vez : “Este libro debería ser una necesidad para los ingenieros de desarrollo. "Este es un recurso raro que combina teoría y práctica, ayudando a los desarrolladores a diseñar e implementar sistemas de infraestructura y procesamiento de datos de manera más inteligente". Algo similar fue dicho por el creador de Kafka y CEO Confluent, Jay Kreps.
Antes de dedicarse a la investigación académica, Martin trabajó en la industria y cofundó dos startups exitosas:
- Rapportive, dedicado a mostrar el perfil social de los contactos de su correo electrónico, que LinkedIn compró en 2012;
- Go Test It, un servicio para verificar automáticamente sitios web en varios navegadores, que RedGate compró en 2009.
En general, Martin, aunque menos conocido que nuestros keynoters, ya pudo hacer una contribución al desarrollo de la informática distribuida y a la industria.
En este informe, Martin hablará sobre un tema más cercano a su investigación académica. En Google Docs y un sofá similar para la coedición de documentos, "coedición" significa la tarea de replicación: cada usuario tiene su propia réplica del documento común, que luego modifica, y todos los cambios se envían a los otros participantes a través de la red. Los cambios en los documentos fuera de línea dan como resultado una inconsistencia temporal del documento con respecto a otros participantes, y la resincronización requiere manejo de conflictos. Solo por esto, hay tipos de datos replicados libres de conflictos (CRDT), de hecho, algo bastante nuevo, cuya esencia se formuló solo en 2011. Este informe discute lo que ha sucedido desde entonces en el mundo CRDT, cuáles son los últimos logros, discute el enfoque para crear aplicaciones locales primero en general y el uso de la biblioteca de código abierto Automerge en particular.
La próxima semana publicaremos en Habré una gran entrevista con Martin, será interesante.
Pedro ha estado trabajando en Cisco y ha estado desarrollando algoritmos paralelos durante los últimos diez años, incluidos mecanismos de sincronización, estructuras de datos sin bloqueo y sin esperar y todo lo que pueda imaginar sobre este tema. Sus intereses actuales de investigación e ingeniería se centran en construcciones universales, memoria transaccional de software, memoria persistente y tecnologías similares que permiten la implementación de aplicaciones correctas, escalables y tolerantes a fallas. También es el autor del blog Concurrency Freaks , ampliamente conocido en círculos estrechos.
La mayoría de las aplicaciones de subprocesos múltiples ahora funcionan en estructuras de datos paralelas, comenzando con el uso de colas de mensajes entre actores y terminando con estructuras de datos indexadas en almacenamientos de valores clave. En Java JDK, han estado trabajando con éxito durante muchos años, y en C ++ se están agregando lentamente.
La forma más sencilla de implementar una estructura de datos paralela es una implementación secuencial (de un solo subproceso) en la que los métodos están protegidos por mutexes. Esto es accesible para cualquier junio, pero tiene problemas obvios con la escala y el rendimiento. Al mismo tiempo, las estructuras de datos sin bloqueo y sin esperar no solo resuelven mejor los errores, sino que también tienen un perfil de rendimiento más exitoso; sin embargo, su desarrollo requiere experiencia profunda y adaptación a una aplicación específica. Una línea de código incorrecta es suficiente para romperlo todo.
¿Cómo hacer que incluso un no experto sea capaz de diseñar e implementar tales estructuras de datos? Se sabe que cualquier algoritmo secuencial puede hacerse seguro para subprocesos utilizando un diseño universal o una memoria transaccional. Por un lado, pueden reducir el umbral para ingresar a esta tarea. Sin embargo, ambas soluciones tienden a conducir a una implementación ineficiente. Pedro hablará sobre cómo lograron hacer estos diseños más eficientes y cómo pueden usarse para sus algoritmos.
Heidi Howard es, como Martin, investigadora de sistemas distribuidos en la Universidad de Cambridge. Su especialización es consistencia, tolerancia a fallas, desempeño y consenso distribuido. Ella es mejor conocida por generalizar el algoritmo de Paxos llamado Flexible Paxos .
Recuerde que Paxos es una familia de protocolos para resolver el problema del consenso en una red de computadoras poco confiables, que se basaron en el trabajo de Leslie Lamport. Por lo tanto, algunos de nuestros oradores están trabajando en tareas originalmente propuestas por nuestros otros oradores, y esto es maravilloso.
La capacidad de encontrar consenso entre múltiples hosts (para direccionamiento, selección de líderes, bloqueo o coordinación) es un problema fundamental en los sistemas distribuidos modernos. Paxos es ahora la principal forma de resolver los problemas de encontrar un consenso, y se está investigando mucho para expandir y optimizar el algoritmo para diversas necesidades prácticas.
En este informe, revisaremos la base teórica de Paxos, debilitando los requisitos iniciales y generalizando el algoritmo. Veremos que Paxos, de hecho, es solo una opción entre una amplia gama de enfoques de consenso, y que otros puntos en el espectro también son muy útiles para construir buenos sistemas distribuidos.
Alex es especialista en bases de datos y sistemas de almacenamiento, y lo que es más importante para nosotros, es un encargado de Cassandra . Junto con O'Reilly, actualmente está trabajando en el libro Database Internals.
Para sistemas con consistencia eventual (en terminología rusa - “consistencia a largo plazo”), después de que un nodo se cae o la red se divide, se debe resolver el siguiente dilema: continuar cumpliendo solicitudes, sacrificando consistencia, o rehusarse a cumplirlas y sacrificar disponibilidad. En dicho sistema, los quórums que se superponen a subconjuntos de nodos y garantizan que al menos un nodo contendrá el valor más reciente puede ser una buena solución límite. Puede sobrevivir a fallas y pérdida de conexión a algunos nodos, continuando respondiendo con los últimos valores.
Sin embargo, todo tiene un precio. Un esquema de replicación de quórum significa un mayor costo de almacenamiento: necesita almacenar datos redundantes en varios nodos a la vez para garantizar un número suficiente de copias disponibles en el momento del problema. Resulta que no puede almacenar todos los datos en todas las réplicas. Puede reducir la carga en el almacenamiento manteniendo datos solo en una parte de los nodos y usar nodos especiales (réplica transitoria) para escenarios de procesamiento de fallas.
En el curso del informe, analizaremos las réplicas de testigos , el esquema de replicación utilizado por Spanner y Megastore , y la implementación de este concepto en Apache Cassandra bajo los nombres Replicación transitoria y quórums baratos .
Dmitry es un desarrollador de Google que trabaja en pruebas dinámicas de C / C ++ y Go - Address / Memory / ThreadSanitizer, y en herramientas similares para el kernel de Linux. Go tiene un programador escalable de rutina, un sondeo de red y un recolector de basura paralelo. Es experto en subprocesos múltiples, autor de una docena de nuevos algoritmos sin bloqueo y es el propietario de Intel Black Belt .
Ahora un poco sobre el informe en sí. Go tiene soporte nativo para subprocesos múltiples en forma de gorutinas (hilos de luz) y canales (colas FIFO). Gracias a estos mecanismos, es muy fácil y agradable para los usuarios escribir aplicaciones modernas multiproceso, y parece mágico. Como entendemos, no hay magia aquí. En este informe, Dmitry profundizará en las complejidades del trabajo del programador Go y mostrará los secretos de la implementación de esta "magia". Primero, le dará una descripción general de los componentes principales del planificador y le dirá cómo funciona. Además, analizaremos más de cerca ciertos aspectos, como la estrategia de estacionamiento / desempaque y el procesamiento de llamadas del sistema de bloqueo. Finalmente, Dmitry hablará un poco sobre posibles mejoras en el programador.
Dmitry trabajó en outsourcing durante casi 9 años, sin perder el contacto con la universidad y la comunidad científica. El análisis de Big Data en Odnoklassniki fue una oportunidad única para él de combinar la formación teórica y la base científica con el desarrollo de productos reales y buscados.
El análisis gráfico distribuido fue y sigue siendo una tarea difícil: cuando se hace necesario obtener información sobre las conexiones de un vértice vecino, los datos a menudo tienen que ser destilados entre máquinas, lo que conduce a un aumento en el tiempo de ejecución y la carga en la infraestructura de red. En este informe, veremos cómo puede obtener una velocidad de procesamiento significativa utilizando estructuras de datos probabilísticos o hechos como la simetría de un gráfico de amistad en una red social. Todo esto se ilustra con ejemplos de código de Apache Spark.
Denis es un desarrollador de Cosmos DB , un experto en el campo de la verificación de modelos de consistencia, en algoritmos de consenso y en transacciones distribuidas. Ahora trabaja en Microsoft, y antes estaba involucrado en sistemas distribuidos en Amazon y Yandex.
En este informe, nos familiarizaremos con los protocolos de transacciones distribuidas inventados en los últimos años, que pueden implementarse en el lado del cliente sobre cualquier almacén de datos que admita la actualización condicional (comparar y configurar). La conclusión es que la vida no termina con un compromiso de dos fases, las transacciones se pueden agregar sobre cualquier base de datos, a nivel de aplicación, pero los diferentes protocolos (2PC, Percolator, RAMP) tienen diferentes compensaciones y no se nos dan de forma gratuita.
Alexey ( zaleslaw ) es nuestro orador desde hace mucho tiempo y miembro de los comités del programa en otras conferencias. Entrenador en práctica en EPAM Systems, y ha sido amigo de Hadoop / Spark y otras grandes citas desde 2012.
En este informe, Alexey hablará sobre los problemas de adaptar los algoritmos clásicos de aprendizaje automático para la ejecución distribuida en función de su experiencia trabajando con Apache Spark ML, Apache Mahout, Apache Flink ML y la experiencia en la creación de Apache Ignite ML. Alexey también hablará sobre la implementación de algoritmos ML distribuidos en estos marcos.
Y finalmente, dos informes de Yandex sobre Yandex Database.
Vladislav es un desarrollador de Yandex en un grupo de plataformas distribuidas. Yandex Database es un DBMS tolerante a fallas geodistribuido y escalable horizontalmente que puede resistir la falla de discos, servidores, bastidores y centros de datos sin comprometer la consistencia. Para garantizar la tolerancia a fallos, se utiliza un algoritmo de consenso distribuido patentado, así como una serie de soluciones técnicas, que se analizan en detalle en el informe. El informe puede ser de interés tanto para los desarrolladores de DBMS como para los desarrolladores de soluciones de aplicaciones basadas en DBMS.
Semyon, un desarrollador de un grupo de una plataforma distribuida en Yandex, está trabajando en la posibilidad del uso de la instalación de YDB por parte de varios inquilinos.
La base de datos Yandex está diseñada para solicitudes OLTP y cumple con los requisitos de ACID para un sistema de transacciones. En el informe, consideraremos el algoritmo de planificación de transacciones subyacente al sistema de transacciones YDB. Analicemos qué entidades participan en las transacciones, quién asigna el orden global a las transacciones, cómo se logran la atomicidad de las transacciones, la confiabilidad y un estricto nivel de aislamiento. Usando un ejemplo de un problema común, consideramos la implementación de transacciones usando un compromiso de dos fases y transacciones deterministas. Discutimos sus diferencias.
Que sigue
El programa de la conferencia continúa lleno de nuevos informes. En particular, esperamos un informe de Nikita Koval ( ndkoval ) de JetBrains y Oleg Anastasiev ( m0nstermind ) de Odnoklassniki. Nikita participa en algoritmos para corutinas en el equipo de Kotlin, y Oleg está desarrollando arquitectura y soluciones para sistemas altamente cargados en la plataforma Odnoklassniki. Además, hay un espacio adicional condicionalmente vacío, con candidatos para los cuales el comité del programa está trabajando en este momento.
La Conferencia Hydra se llevará a cabo del 11 al 12 de julio en San Petersburgo. Las entradas se pueden comprar en el sitio web oficial . Llamamos la atención sobre la disponibilidad de boletos en línea, si por alguna razón no puede llegar a San Petersburgo en estos días.
¡Nos vemos en Hydra!