Los días 11 y 12 de julio se llevará a cabo una conferencia en San Petersburgo. dedicada al desarrollo de sistemas paralelos y distribuidos. Lo que pasa con Hydra es que combina a los mejores científicos (que generalmente se encuentran solo en conferencias científicas extranjeras) e ingenieros en ejercicio reconocidos en un gran programa en la intersección de la ciencia y la práctica.
Hydra es una de nuestras conferencias más importantes de los últimos años. Fue precedida por una preparación muy seria, selección de ponentes e informes. sobre eso la semana pasada con el director del Grupo JUG.ru, Alexey Fedorov ().
nosotros sobre tres participantes importantes, los fundadores de la teoría de los sistemas distribuidos: Leslie Lamport, Maurice Herlihy y Michael Scott. ¡Es hora de hablar más sobre todo el programa!
Motivación
Si está programando, entonces, de una forma u otra, está tratando con subprocesos múltiples y computación distribuida. Los especialistas en los campos relevantes trabajan con ellos directamente, pero implícitamente, la distribución nos mira desde todos lados: en cualquier computadora multinúcleo o servicio distribuido, hay algo que realiza cálculos en paralelo.
Hay muchas conferencias que cubren ciertos aspectos de la programación de aplicaciones. En el otro lado del espectro, tenemos escuelas científicas especiales, en formato de conferencias, que revelan enormes cantidades de teoría compleja. Por ejemplo, en paralelo con Hydra en San Petersburgo, . En la conferencia de Hydra, tratamos de reunir la dura práctica, la ciencia y todo lo que se encuentra en su intersección.
Piensa en esto: vivimos en una época increíble en la que puedes conocer en vivo a los fundadores del campo de la ciencia y la ingeniería en el que nos dedicamos. Los físicos no se encontrarán ni con Newton ni con Einstein: el tren se ha ido. Pero aquellos que crearon los cimientos de la teoría de los sistemas distribuidos, inventaron lenguajes de programación populares y, por primera vez, incorporaron todo esto en prototipos funcionales, aún viven junto a nosotros. Estas personas no han renunciado a sus trabajos a la mitad, actualmente realizan tareas del mundo real en universidades y empresas de renombre mundial, y son las mayores fuentes de conocimiento y experiencia de la actualidad.
Por otro lado, la oportunidad de conocerlos suele ser puramente teórica: pocos de nosotros podemos monitorear constantemente eventos públicos en alguna Universidad de Rochester para luego correr a los Estados Unidos y regresar a una conferencia de Michael Scott. Visitar a todos los miembros de Hydra en general sería una pequeña fortuna, aparte del abismo de tiempo invertido (aunque suena a quest interesante).
Por otro lado, tenemos muchos ingenieros de primer nivel que están trabajando en los problemas reales de los sistemas distribuidos en este momento, y definitivamente tienen algo que contar. Pero aquí está el problema: ellos работаютy su tiempo es precioso. Sí, si es un empleado de Microsoft, Google o JetBrains, la probabilidad de encontrarse con uno de los oradores conocidos en un evento interno aumenta drásticamente, pero en general, no, no sucede todos los días.
De esta manera, la conferencia Hydra logra una tarea importante que la mayoría de nosotros no podemos hacer por nuestra cuenta: en un lugar y en un momento, reúne a personas cuyas ideas o comunicación con quienes pueden cambiar su vida. Admito que no todo el mundo necesita sistemas distribuidos, algunas cosas fundamentales complejas. Puedes programar CRUD en PHP por el resto de tu vida y ser completamente feliz. Pero quién lo necesita, esta es tu oportunidad.
Ha pasado bastante tiempo desde el primer anuncio de la conferencia Hydra en Habré. Durante este tiempo, se ha trabajado mucho 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 qué tenemos a mano ahora.
Conferencias magistrales
Las conferencias magistrales inician y finalizan los días de la conferencia. Por lo general, el propósito del discurso de apertura es establecer el espíritu general y la dirección de la conferencia. El discurso de cierre traza una línea y explica cómo podemos vivir con los conocimientos y habilidades adquiridos durante los días de la conferencia. Principio y fin: lo que mejor se recuerda y, en general, tiene mayor valor.
Acantilado Click-
Cliff es una leyenda en el mundo de Java. A finales de los 90, para una tesis doctoral, escribió un artículo llamado , que después de un tiempo se convirtió en la base para el compilador del servidor HotSpot JVM. Dos años más tarde, ya estaba trabajando en Sun Microsystems en JVM y le mostró al mundo entero que el JIT tiene derecho a existir. Toda esta 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 un compilador estático, ni siquiera puede intentarlo. Gracias al trabajo de Cliff y el equipo, todos los lenguajes nuevos comenzaron a crearse con la idea de compilación JIT por defecto. Por supuesto, este no fue el trabajo de una sola persona, pero Cliff jugó un papel muy importante en él.
En el discurso de apertura, Cliff hablará sobre su otra empresa: , una plataforma en memoria para aprendizaje automático distribuido y escalable para aplicaciones industriales. Más precisamente, sobre el almacenamiento distribuido de pares clave-valor en su interior. Este es un almacenamiento muy rápido con muchas propiedades interesantes (la lista exacta está en ) que permiten el uso de soluciones similares en las matemáticas de la transmisión de big data.
Otra charla que dará Cliff es . Otra parte de su biografía - diez años. , donde actualizó y mejoró muchas cosas en el hardware y la tecnología de Azul: compiladores JIT, tiempo de ejecución, modelo de subprocesos, manejo de errores, manipulación de pilas, interrupciones de hardware, carga de clases, etc., bueno, obtienes el idea.
La parte más interesante comenzó cuando crearon hardware para grandes empresas: una supercomputadora para ejecutar Java. Fue algo bastante innovador, diseñado específicamente para Java, que tiene requisitos especiales: barreras de memoria para lectura para recolección de basura de baja pausa, matrices con verificación de límites, llamadas virtuales... Una de las tecnologías más geniales es la memoria transaccional de hardware. El L1 completo de cualquiera de los 864 núcleos podría participar en una 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 de memoria real). Pero la hermosa idea se estrelló contra la dura realidad, y en este informe Cliff le dirá por qué HTM y STM no son adecuados para las necesidades prácticas de la computación de subprocesos múltiples.
Michael Scott -
- Profesor de Ciencias de la Computación en la Universidad de Rochester, con quien el destino lo unió , y en su Universidad natal 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 de lenguajes y enseña esto a los estudiantes.
Todo el mundo conoce a Michael gracias al libro de texto. , cuya última edición se publicó hace relativamente poco tiempo, en 2015. Su trabajo recibido como uno de los más famosos en el campo de la computación distribuida y 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 .
En cuanto al mundo de Java, este es un caso especial: junto con Doug Lea, desarrolló esos algoritmos sin bloqueo y colas sincrónicas en las que se ejecutan las bibliotecas de Java. De esto se tratará el discurso de apertura de "Estructuras de datos duales": la introducción de estas estructuras en Java SE 6 nos permitió mejorar el rendimiento 10 veces java.util.concurrent.ThreadPoolExecutor. Si está interesado de antemano en qué son estas "estructuras de datos duales", entonces hay .
Maurice Herlihy-
- Ganador de dos premios Dijkstra. La primera es para el trabajo. (Universidad de Brown), y el segundo, más reciente - (Universidad Tecnológica de Virginia). El Premio Dijkstra se otorga por obras cuya importancia e influencia han sido notables durante al menos diez años, y está claro que Maurice es uno de los especialistas más famosos en el campo. Actualmente es profesor en la Universidad de Brown y tiene logros de un párrafo.
En esta conferencia de cierre, Maurice hablará sobre la teoría y la práctica de los sistemas distribuidos blockchain desde el punto de vista de los clásicos de la computación distribuida y cómo simplifica muchos problemas relacionados. Este informe es exclusivamente sobre el tema de la conferencia, no sobre el bombo de la minería, sino más bien sobre cómo nuestro conocimiento puede usarse de manera sorprendentemente efectiva y apropiada en relación con una variedad de tareas.
En julio de 2017, Maurice ya vino a Rusia a la escuela SPTDC, participó en la reunión JUG.ru y la grabación se puede ver en YouTube:
Programa principal
A continuación se hará un breve repaso de los informes incluidos en el programa. Algunos de los informes se describen en detalle aquí, algunos más brevemente. Las descripciones largas se dirigieron principalmente a informes en inglés que requieren enlaces a artículos científicos, términos en Wikipedia, etc. Una lista completa puede ser . La lista en el sitio se actualizará y complementará.
Leslie Lamport-
Leslie Lamport es una autora pionera de computación distribuida. significa "Lamport TeX". Fue él quien por primera vez, allá por 1979, introdujo el concepto , y su artículo recibió 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 significativa 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 más importante dedicar todo el tiempo disponible a la comunicación directa.
La idea es simple: ve dos informes en YouTube: и y prepare al menos una pregunta, y Leslie responde.
El primero de estos dos videos ya lo tenemos . Si no tiene una hora de tiempo para ver el video, puede leerlo rápidamente en forma de texto.
Nota: Hay muchos más videos en YouTube con Leslie Lamport. Por ejemplo, hay una excelente . Una versión sin conexión de todo este curso está disponible en , y en YouTube lo vertió para una visualización más conveniente en dispositivos móviles.
Martín Kleppman-
Martin Kleppmann es un investigador de la Universidad de Cambridge que trabaja en CRDT y verificación de algoritmos formales. el libro de martin , publicado en 2017, resultó ser un gran éxito y llegó a las listas de los más vendidos en el campo del almacenamiento y procesamiento de datos. Kevin Scott, CTO de Microsoft : “Este libro debería ser imprescindible para los ingenieros de diseño. Este es un recurso excepcional que une la teoría y la práctica para ayudar a los desarrolladores a diseñar e implementar sistemas e infraestructuras de datos de manera más inteligente”. Algo similar dijo el creador de Kafka y CTO Confluent, Jay Kreps.
Antes de pasar a la investigación académica, Martin trabajó en la industria y cofundó dos nuevas empresas exitosas:
- Rapportive, dedicada a mostrar el perfil social de tus contactos de correo electrónico, que compró LinkedIn en 2012;
- Go Test It, un verificador de sitios web automatizado de múltiples navegadores que RedGate compró en 2009.
En general, aunque Martin es menos conocido que nuestros ponentes principales, ya ha podido hacer alguna contribución tanto al desarrollo de la computación distribuida como a la industria.
En esta charla, Martin hablará sobre un tema más cercano a su investigación académica. En Google Docs y un sofá similar para documentos de coautoría, "coautoría" significa una tarea de replicación: cada usuario tiene su propia réplica de un documento compartido, que luego modifica, y todos los cambios se envían a través de la red al resto. de los participantes Los cambios sin conexión a los documentos dan como resultado una incoherencia temporal del documento con respecto a otros participantes, y la resincronización requiere el manejo de conflictos. Solo para esto hay (CRDT), de hecho, es algo bastante nuevo, cuya esencia se formuló solo en 2011. Esta charla analiza lo que ha sucedido desde entonces en el mundo CRDT, cuáles son los últimos desarrollos, analiza el enfoque para crear aplicaciones locales en general y el uso de una biblioteca de código abierto. en particular
La próxima semana publicaremos una gran entrevista con Martin sobre Habré, será interesante.
Pedro Ramalhete -
Pedro trabaja 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 espera, y todo lo que se 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 para habilitar aplicaciones correctas, escalables y tolerantes a fallas. Y también es autor de un blog ampliamente conocido en círculos estrechos. .
La mayoría de las aplicaciones de subprocesos múltiples ahora se ejecutan en estructuras de datos paralelas, desde el uso de colas de mensajes entre actores hasta estructuras de datos indexados en almacenes de clave-valor. Han estado trabajando con éxito en Java JDK durante muchos años y poco a poco se están agregando a C ++.
La forma más sencilla de implementar una estructura de datos paralela es una implementación en serie (un solo subproceso) en la que los métodos están protegidos por mutexes. Esto está disponible para cualquier jun, pero tiene problemas obvios de escala y rendimiento. Al mismo tiempo, las estructuras de datos sin bloqueos y sin esperas no solo manejan mejor los errores, sino que también tienen un mejor perfil de rendimiento; sin embargo, su desarrollo requiere una gran experiencia y adaptación a un caso de uso específico. Una línea de código incorrecta es suficiente para romper todo.
¿Cómo asegurarse de que incluso un no experto pueda diseñar e implementar tales estructuras de datos? Se sabe que cualquier algoritmo secuencial puede hacerse seguro para subprocesos mediante o memoria transaccional. Por un lado, pueden reducir el umbral de entrada para resolver este problema. Sin embargo, ambas soluciones tienden a conducir a implementaciones ineficientes. Pedro hablará sobre cómo lograron que estas construcciones sean más eficientes y cómo pueden usarse para sus algoritmos.
heidi howard-
Heidi Howard es, al igual que Martin, investigadora de sistemas distribuidos en la Universidad de Cambridge. Su especialización es la coherencia, la tolerancia a errores, el rendimiento y el consenso distribuido. Es mejor conocida por su generalización del algoritmo de Paxos llamada .
Recordemos que - 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 que fueron propuestas originalmente por nuestros otros oradores, y esto es maravilloso.
La capacidad de encontrar consenso entre múltiples hosts (para direccionamiento, selección de líder, bloqueo o coordinación) es un tema fundamental en los sistemas distribuidos de hoy. Paxos es ahora la principal forma de resolver problemas de consenso, y hay mucha investigación a su alrededor para extender y optimizar el algoritmo para diversas necesidades prácticas.
En este informe, revisaremos la base teórica de Paxos, relajando los requisitos iniciales y generalizando el algoritmo. Veremos que Paxos es, de hecho, solo una de las opciones entre una amplia gama de enfoques de consenso, y que otros puntos en el espectro también son bastante útiles para construir buenos sistemas distribuidos.
Alex Petrov-
Alex es un especialista en bases de datos y almacenamiento y, lo que es más importante, un committer en . Actualmente está trabajando con O'Reilly en el libro Database Internals.
Para sistemas con (en terminología rusa: "consistencia al final"), después de la caída de un nodo o una división de la red, se debe resolver el siguiente dilema: continuar cumpliendo con las solicitudes, sacrificando la consistencia, o negarse a ejecutarlas y sacrificar la disponibilidad. En un sistema de este tipo, los quórumes, la superposición de subconjuntos de nodos y la garantía de que al menos un nodo contenga el valor más reciente, pueden ser una buena solución. Es posible sobrevivir a fallas y pérdidas de conexión a algunos nodos mientras continúa respondiendo con los valores más recientes.
Sin embargo, todo tiene su precio. Un esquema de replicación de quórum significa un mayor costo de almacenamiento: debe almacenar datos redundantes en varios nodos a la vez para asegurarse de que haya suficientes copias disponibles cuando ocurra un problema. Resulta que no puede almacenar todos los datos en todas las réplicas. Puede reducir la carga en el almacenamiento si mantiene los datos solo en una parte de los nodos y usa nodos especiales (réplica transitoria) para escenarios de manejo de fallas.
En el transcurso del informe, consideraremos , el esquema de replicación utilizado en и , y la implementación de este concepto en Apache Cassandra bajo los nombres .
Dmitri Vyukov -
Dmitry es un desarrollador de Google que trabaja en pruebas dinámicas de C/C++ y Go - Dirección/Memoria/ThreadSanitizer y herramientas similares para el kernel de Linux. Ha contribuido con un programador de rutinas go escalable, un sondeador de red y un recolector de basura paralelo para Go. Es experto en subprocesos múltiples, autor de una docena de nuevos algoritmos sin bloqueo y propietario de Intel.
Ahora un poco sobre el informe en sí. El lenguaje Go tiene soporte nativo para subprocesos múltiples en forma de goroutines (subprocesos ligeros) y canales (colas FIFO). Gracias a estos mecanismos, es muy fácil y agradable para los usuarios escribir aplicaciones multiproceso modernas, y parece magia. Como entendemos, no hay magia aquí. En este informe, Dmitry profundizará en las complejidades del programador Go y mostrará los secretos para implementar esta "magia". Primero, dará una descripción general de los componentes principales del programador, cómo funciona. A continuación, veremos más de cerca ciertos aspectos, como la estrategia de estacionamiento / desestacionamiento y el manejo de las llamadas del sistema de bloqueo. Finalmente, Dmitry hablará un poco sobre las posibles mejoras en el programador.
Dmitri Bugaichenko -
Dmitry ha trabajado 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 en demanda.
El análisis de gráficos distribuidos ha sido y sigue siendo una tarea difícil: cuando se hace necesario obtener información sobre las conexiones de un vértice vecino, a menudo los datos deben transferirse entre máquinas, lo que conduce a un aumento en el tiempo de ejecución y una carga en la red. infraestructura. En esta charla, veremos cómo puede obtener una aceleración significativa del procesamiento utilizando estructuras de datos probabilísticas o hechos como la simetría del gráfico de amistad en una red social. Todo esto se ilustra con ejemplos de código de Apache Spark.
Denis Rystsov -
Denis - desarrollador , experto en validación de modelos de consistencia, algoritmos de consenso y transacciones distribuidas. Ahora trabaja en Microsoft, y antes de eso se dedicaba a sistemas distribuidos en Amazon y Yandex.
En este informe, nos familiarizaremos con los protocolos de transacciones distribuidas que se han inventado en los últimos años, que se pueden implementar en el lado del cliente sobre cualquier almacén de datos que admita la actualización condicional (comparar y establecer). La conclusión es que la vida no termina con un compromiso de dos fases, las transacciones se pueden agregar encima de cualquier base de datos, en el nivel de la aplicación, pero los diferentes protocolos (2PC, Percolator, RAMP) tienen diferentes compensaciones y no se nos dan. gratis.
Aleksey Zinoviev -
Alexei () es nuestro orador desde hace mucho tiempo y miembro de los comités de programa en otras conferencias. Entrenador en ejercicio en EPAM Systems, y ha sido amigo de Hadoop/Spark y otros bigdata desde 2012.
En esta charla, 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 con Apache Spark ML, Apache Mahout, Apache Flink ML y la experiencia de crear Apache Ignite ML. Alexey también hablará sobre la implementación de algoritmos ML distribuidos en estos marcos.
Y en conclusión, dos informes de Yandex sobre Yandex Database.
Vladislav Kuznetsov—
Vladislav es desarrollador en Yandex en el grupo de plataformas distribuidas. Yandex Database es un DBMS tolerante a fallas, distribuido geográficamente y escalable horizontalmente que puede soportar fallas de discos, servidores, bastidores y centros de datos sin comprometer la consistencia. Para garantizar la tolerancia a fallas, 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 aplicadas basadas en DBMS.
Semión Checherinda -
Semyon es un desarrollador en el grupo de plataformas distribuidas de Yandex, que trabaja en la posibilidad de un uso multiinquilino de la instalación de YDB.
Yandex Database está diseñado para consultas OLTP y cumple con los requisitos ACID para un sistema transaccional. En el informe, consideraremos el algoritmo de programación de transacciones subyacente al sistema transaccional YDB. Analicemos qué entidades participan en las transacciones, quién asigna un orden global a las transacciones, cómo se logra la atomicidad de las transacciones, la confiabilidad y el nivel de aislamiento estricto. Usando un ejemplo de una tarea común, considere la implementación de transacciones usando un compromiso de dos fases y transacciones deterministas. Hablemos de sus diferencias.
¿Qué será lo próximo?
El programa de conferencias sigue llenándose de nuevos informes. En particular, esperamos un informe de Nikita Koval () de JetBrains y Oleg Anastasiav () de Odnoklassniki. Nikita trabaja en algoritmos para rutinas en el equipo de Kotlin y Oleg desarrolla arquitectura y soluciones para sistemas de alta carga en la plataforma Odnoklassniki. Además, hay 1 espacio condicionalmente vacío más, con candidatos para los cuales el comité de programa está trabajando en este momento.
La conferencia Hydra tendrá lugar el 11 y 12 de julio en San Petersburgo. Los boletos pueden ser . Preste atención a la disponibilidad de boletos en línea, si por alguna razón no puede llegar a San Petersburgo en vivo en estos días.
¡Nos vemos en Hidra!
Fuente: habr.com