Посетил сегодня встечу на тему «Breaking ETL barrier with Spark Streaming and Real Time Txn Volume Forecasting» и решил записать путевые заметки. Заметки получились немного циничные, но, надеюсь, интересные.
Встреча была организована компанией Concur, которая в основном работает на корпоративных клиентов, предоставляя им набор финансово-«туристических» услуг. Материл был интересный, уровень — легкий, обзор будет короткий.
Вкратце, смысл в том, чтобы заменить ETL на такое же примерно количество процессов, которые читают транзакционные логи и посылают их через Kafka в Spark Streaming, где они могут быть «лучше обработаны и проанализированны», и дальше сложены в OLAP (как и раньше). То есть это, по сути ETL, но real time, а не пакетный, и более программируемый.
Короткая вводная — со Spark я не работал, о Kafka читал только художественную литературу, Java не знаю, Scala и Akka знаю поверхностно, своих монадов не писал, потому не могу оценить техническую сторону предоставленного решения. На встречу я попал почти случайно. Где-то так.
И немного об организаторах. Встреча была проведена небольшой инициативной командой от фирму Concur. Офис Concur находится практически через дорогу от офиса Expedia, что в наши дни не означает ничего, потому как 90% народу и в одной фирме, и в другой, на самом деле сидит в Индии.
Я на работе пользуюсь их сервисом и то, что вижу, похоже на комбинацию 2х сервисов.
Первый сервис напоминает Expedia — я могу планировать и заказывать все детали командировки: билеты, машину, отель, выбирать по всякому (ближе-дешевле-быстрее); хорошая интеграци с отелями, авиакомпаниями; учтены детали компании где я работаю, например, есть «предпочтительные» рейсы и если я ими не пользуюсь, то должен привести обоснование и получить разрешение от моего начальства. Хорошо сделано.
Второй сервис — это отчеты о затратах и другая околофинансовая тематика.
Конечно, бухгалтерия видит все это по другому и сложнее. В целом система очень сложная и большая, даже огромная. Интегрирована с многими другими системами — отели, платежи и т.д.
Собственно, докладчик и начал с того, что у них есть проблемы, связанные с общей сложностью и размером системы, которую они и хотят побороть. По словам докладчика, в Concur-е около 28000 то ли баз данных, то ли ETL процессов, но в любом случае цифра впечатляющая. И «ночью» они перегоняют данные из OLTP баз в OLAP базы, дабы генерировать отчеты и анализировать всякие неясности. Ночь тут понятие относительное от локального времени заказчика, но это не сильно облегчает жизнь.
А потом докладчик добил фразой, что некоторые ETL длятся до 10 часов. И начал втаптывать текущую архитектуру в грязь:
Я несколько оживился, но вопросов задавать не стал — народ в зале кивал и одобрял каждый гвоздь в крышку этого гроба, в общем, не стал я придираться. Но как можно назвать 28000 databases монолитом или «hard to scale» я не понимаю. Да, нынче модно так обзывать все, и я понимаю, что инициативная группа, на доклад которой я попал, по сути пропагандирует локальную революцию (и пожизненную оплату 2-3 городов индийских программистов), и тут любые эпитеты допустимы.
Потом докладчик рассказал, что есть 100% идеальное решение проблемы и зал с ним как-то сразу согласился. Ну, то есть 28000 слева они, конечно, не масштабируются, да. А вот те же 28000 справа сразу раз — и масштабируются.
Дальше пошло немного веселее — быстро прошлись по существующим вариантам и как-то тоже их обругали немного. Я не успел сделать фото, где справа были еще отчеты, но на них то же не особо концентрировались — ну, отчет и отчет, делов то, отчет — это не архитектура! Отдельно упомянули Alerts — им была посвящена вторая часть мероприятия, но об этом позже.
Устно сравнили Spark Streaming с конкурентами, отдельно упомянули возможность обрабатывать события и пакетные данные одним и тем же кодом. Код конечно надо писать на Scala. Отдельно и многократно упоминались Exactly Once, гарантированная доставка и встроенная резервная репликация данных.
Ну и собственно финальный слайд:
Слева внизу OLTP — это те 28000 баз, они были, есть и будут.
Справа внизу синенькие OLAP — это то куда сейчас стекаются данные по ETL. Репликация есть и остается, отчеты есть и остаются. Тут ничего не меняем.
Между ними сейчас ETL процессы запускаемые по сложному графику, на схеме не показано.
Все остальное — это будущее, но очень светлое!
Слева внизу «P» — это продюсер, их много, читатель уже наверняка знает, сколько их будет. Этот продюсер читает транзакционные логи и посылает в Kafka. Конечно, как protobuf, ведь так быстрее! А Kafka в 5-20 раз быстрее, чем RabbitMQ. В будущем мы OLTP базы устраним и заменим на Service Bus, потому как Event Store! Но не сейчас, к сожалению, мешает UI, и тут мы безсильны…
Дальше данные идут в Spark Streaming, где мы напишем несложный Scala код и Spak-SQL запросы. Результат запишем в OLAP. Он не будет до конца правильный, потому как Eventual Consistency, но это нормально, так сейчас везде.
А вверху — это Hadoop. В принципе, он нам не нужен, но пусть будет — часть данных ведь прийдет в виде файлов и не по Service Bus. Увы, и так бывает. Поэтому Hadoop надо.
Вокруг этого слайда и прошли минут 15 вопросов и ответов.
Потом была сумбурная вторая часть, минут 15, где упомянули о сложении Twitter Trees. Зал молчал, вопросов не было.
Выяснилось, что это все только планируется и, возможно, прототип заработает к августу. Надо будет пойти на следующую встречу, посмотреть, заработал ли прототип.
Встреча была организована компанией Concur, которая в основном работает на корпоративных клиентов, предоставляя им набор финансово-«туристических» услуг. Материл был интересный, уровень — легкий, обзор будет короткий.
Вкратце, смысл в том, чтобы заменить ETL на такое же примерно количество процессов, которые читают транзакционные логи и посылают их через Kafka в Spark Streaming, где они могут быть «лучше обработаны и проанализированны», и дальше сложены в OLAP (как и раньше). То есть это, по сути ETL, но real time, а не пакетный, и более программируемый.
Короткая вводная — со Spark я не работал, о Kafka читал только художественную литературу, Java не знаю, Scala и Akka знаю поверхностно, своих монадов не писал, потому не могу оценить техническую сторону предоставленного решения. На встречу я попал почти случайно. Где-то так.
И немного об организаторах. Встреча была проведена небольшой инициативной командой от фирму Concur. Офис Concur находится практически через дорогу от офиса Expedia, что в наши дни не означает ничего, потому как 90% народу и в одной фирме, и в другой, на самом деле сидит в Индии.
Я на работе пользуюсь их сервисом и то, что вижу, похоже на комбинацию 2х сервисов.
Первый сервис напоминает Expedia — я могу планировать и заказывать все детали командировки: билеты, машину, отель, выбирать по всякому (ближе-дешевле-быстрее); хорошая интеграци с отелями, авиакомпаниями; учтены детали компании где я работаю, например, есть «предпочтительные» рейсы и если я ими не пользуюсь, то должен привести обоснование и получить разрешение от моего начальства. Хорошо сделано.
Второй сервис — это отчеты о затратах и другая околофинансовая тематика.
Конечно, бухгалтерия видит все это по другому и сложнее. В целом система очень сложная и большая, даже огромная. Интегрирована с многими другими системами — отели, платежи и т.д.
Собственно, докладчик и начал с того, что у них есть проблемы, связанные с общей сложностью и размером системы, которую они и хотят побороть. По словам докладчика, в Concur-е около 28000 то ли баз данных, то ли ETL процессов, но в любом случае цифра впечатляющая. И «ночью» они перегоняют данные из OLTP баз в OLAP базы, дабы генерировать отчеты и анализировать всякие неясности. Ночь тут понятие относительное от локального времени заказчика, но это не сильно облегчает жизнь.
А потом докладчик добил фразой, что некоторые ETL длятся до 10 часов. И начал втаптывать текущую архитектуру в грязь:
Я несколько оживился, но вопросов задавать не стал — народ в зале кивал и одобрял каждый гвоздь в крышку этого гроба, в общем, не стал я придираться. Но как можно назвать 28000 databases монолитом или «hard to scale» я не понимаю. Да, нынче модно так обзывать все, и я понимаю, что инициативная группа, на доклад которой я попал, по сути пропагандирует локальную революцию (и пожизненную оплату 2-3 городов индийских программистов), и тут любые эпитеты допустимы.
Потом докладчик рассказал, что есть 100% идеальное решение проблемы и зал с ним как-то сразу согласился. Ну, то есть 28000 слева они, конечно, не масштабируются, да. А вот те же 28000 справа сразу раз — и масштабируются.
Дальше пошло немного веселее — быстро прошлись по существующим вариантам и как-то тоже их обругали немного. Я не успел сделать фото, где справа были еще отчеты, но на них то же не особо концентрировались — ну, отчет и отчет, делов то, отчет — это не архитектура! Отдельно упомянули Alerts — им была посвящена вторая часть мероприятия, но об этом позже.
Устно сравнили Spark Streaming с конкурентами, отдельно упомянули возможность обрабатывать события и пакетные данные одним и тем же кодом. Код конечно надо писать на Scala. Отдельно и многократно упоминались Exactly Once, гарантированная доставка и встроенная резервная репликация данных.
Ну и собственно финальный слайд:
Слева внизу OLTP — это те 28000 баз, они были, есть и будут.
Справа внизу синенькие OLAP — это то куда сейчас стекаются данные по ETL. Репликация есть и остается, отчеты есть и остаются. Тут ничего не меняем.
Между ними сейчас ETL процессы запускаемые по сложному графику, на схеме не показано.
Все остальное — это будущее, но очень светлое!
Слева внизу «P» — это продюсер, их много, читатель уже наверняка знает, сколько их будет. Этот продюсер читает транзакционные логи и посылает в Kafka. Конечно, как protobuf, ведь так быстрее! А Kafka в 5-20 раз быстрее, чем RabbitMQ. В будущем мы OLTP базы устраним и заменим на Service Bus, потому как Event Store! Но не сейчас, к сожалению, мешает UI, и тут мы безсильны…
Дальше данные идут в Spark Streaming, где мы напишем несложный Scala код и Spak-SQL запросы. Результат запишем в OLAP. Он не будет до конца правильный, потому как Eventual Consistency, но это нормально, так сейчас везде.
А вверху — это Hadoop. В принципе, он нам не нужен, но пусть будет — часть данных ведь прийдет в виде файлов и не по Service Bus. Увы, и так бывает. Поэтому Hadoop надо.
Вокруг этого слайда и прошли минут 15 вопросов и ответов.
Потом была сумбурная вторая часть, минут 15, где упомянули о сложении Twitter Trees. Зал молчал, вопросов не было.
Выяснилось, что это все только планируется и, возможно, прототип заработает к августу. Надо будет пойти на следующую встречу, посмотреть, заработал ли прототип.
