Про подкаст DevZen
С большой радостью, благодаря gliv, послушал подкаст http://devzen.ru/episode-0038, где обсуждался в т.ч. и Cloud Dataflow (начало обсуждения в 00:38:30 примерно).
Хотел бы публично прояснить пару обсуждаемых там вещей.
0. Конечно же, это не "общая теория всего" и это даже не не инструмент для разработки приложений. Это просто инструмент, очень хорошо решающий одну конкретную задачу: удобно задавать и эффективно исполнять распределенные вычисления над большим объемом данных. Использовать MapReduce или Hadoop для этого удобнее, чем писать соответствующую систему с нуля для каждой задачи, использовать FlumeJava, Millwheel или Spark еще удобнее; мы надеемся, что использовать Dataflow будет и того удобнее.
1. Почему-то в подкасте про Dataflow говорили как про "программирование мышкой" - однако это совсем не так; возможно, ведущих ввел в заблуждение скриншот (см. http://antilamer.livejournal.com/461918.html), показывающий схему программы. Программа, использующая Dataflow, выглядит примерно так же, как программа, использующая Spark - это просто код, использующий наш API. Например, см. примеры из Google Genomics или примеры из нашего SDK. В коде вы оперируете коллекциями (PCollection) и преобразованиями (PTransform), собирая из них схему (Pipeline). На скриншоте изображена фича системы мониторинга, показывающая структуру вашей схемы, то, сколько по ней где течет данных в секунду, и т.п. Если угодно, "EXPLAIN PLAN".
2. Примерно в 00:44:20 звучит вопрос, как быть с ситуацией, когда нужно подождать одного события, перед тем, как обрабатывать другое. Для этой и схожих ситуаций, как я понимаю, предназначена концепция триггеров. Лучший способ выяснить точно - задать вопрос на StackOverflow с тегом google-cloud-dataflow; мы постоянно их мониторим и обычно отвечаем в течение нескольких часов. Я работаю над другими частями продукта и думаю, что кто-то другой из команды ответит на этот вопрос гораздо лучше меня.
3. В районе 00:46 обсуждается наш scheduler. Под этим можно понимать несколько разных вещей: 1) как Dataflow разбивает задачу на куски 2) как Dataflow решает, сколько ресурсов нужно для этих кусков 3) какой кусок задачи нужно выполнить на каком ресурсе 4) как, собственно, выделяются ресурсы, запрошенные Dataflow. Пункт 4 - это просто Google Compute Engine: он играет наиболее близкую к YARN роль в этой системе, и ему совершенно неважно, Dataflow на нем исполняется или что-то другое. Для пользователя GCE предоставляет абстракцию бесконечного количества ресурсов, ваше дело - попросить и заплатить. Подсистемы, решающие задачи 1, 2, 3 - это уже сам Dataflow, и они скорее являются аналогом Spark master или Hadoop JobTracker.
4. Около 00:47:30 - вопрос о динамическом изменении топологии потокового вычисления. Мы в курсе, что это очень важная проблема; внутри гугла (в Millwheel) она решена; рано или поздно, полагаю, она будет решена и в Dataflow.
Хотел бы публично прояснить пару обсуждаемых там вещей.
0. Конечно же, это не "общая теория всего" и это даже не не инструмент для разработки приложений. Это просто инструмент, очень хорошо решающий одну конкретную задачу: удобно задавать и эффективно исполнять распределенные вычисления над большим объемом данных. Использовать MapReduce или Hadoop для этого удобнее, чем писать соответствующую систему с нуля для каждой задачи, использовать FlumeJava, Millwheel или Spark еще удобнее; мы надеемся, что использовать Dataflow будет и того удобнее.
1. Почему-то в подкасте про Dataflow говорили как про "программирование мышкой" - однако это совсем не так; возможно, ведущих ввел в заблуждение скриншот (см. http://antilamer.livejournal.com/461918.html), показывающий схему программы. Программа, использующая Dataflow, выглядит примерно так же, как программа, использующая Spark - это просто код, использующий наш API. Например, см. примеры из Google Genomics или примеры из нашего SDK. В коде вы оперируете коллекциями (PCollection) и преобразованиями (PTransform), собирая из них схему (Pipeline). На скриншоте изображена фича системы мониторинга, показывающая структуру вашей схемы, то, сколько по ней где течет данных в секунду, и т.п. Если угодно, "EXPLAIN PLAN".
2. Примерно в 00:44:20 звучит вопрос, как быть с ситуацией, когда нужно подождать одного события, перед тем, как обрабатывать другое. Для этой и схожих ситуаций, как я понимаю, предназначена концепция триггеров. Лучший способ выяснить точно - задать вопрос на StackOverflow с тегом google-cloud-dataflow; мы постоянно их мониторим и обычно отвечаем в течение нескольких часов. Я работаю над другими частями продукта и думаю, что кто-то другой из команды ответит на этот вопрос гораздо лучше меня.
3. В районе 00:46 обсуждается наш scheduler. Под этим можно понимать несколько разных вещей: 1) как Dataflow разбивает задачу на куски 2) как Dataflow решает, сколько ресурсов нужно для этих кусков 3) какой кусок задачи нужно выполнить на каком ресурсе 4) как, собственно, выделяются ресурсы, запрошенные Dataflow. Пункт 4 - это просто Google Compute Engine: он играет наиболее близкую к YARN роль в этой системе, и ему совершенно неважно, Dataflow на нем исполняется или что-то другое. Для пользователя GCE предоставляет абстракцию бесконечного количества ресурсов, ваше дело - попросить и заплатить. Подсистемы, решающие задачи 1, 2, 3 - это уже сам Dataflow, и они скорее являются аналогом Spark master или Hadoop JobTracker.
4. Около 00:47:30 - вопрос о динамическом изменении топологии потокового вычисления. Мы в курсе, что это очень важная проблема; внутри гугла (в Millwheel) она решена; рано или поздно, полагаю, она будет решена и в Dataflow.