Не очень понял, почему и что будет хуже? Сейчас потребление ресурсов таким и планировалось. Есть хорошее capacity по ресурсам, которое позволяет нам смело интегрировать новые источники данных и увеличивать плотность событий, которые и так увеличиваются каждые полгода. При этом мы не умираем при больших выбросах данных на "пике волны" и можем не заботиться о покупке новых серверов ближайшие несколько лет. От Кафки отказаться в пользу файлов в нашем случае будет менее эффективным вариантом, потому что: 1. Kafka - единая интеграционная шина для систем источников данных и систем потребителей. Не все системы источники и системы потребители умеют эффективно работать с файлами, однако практически в любом популярном фреймворке и языке программирования есть интеграция с Kafka, которая обычно очень простая. При этом некоторые системы потребители могут работать только с Kafka и ради нас переходить на интеграцию через файлы не будут. 2. При таком объёме данных и скорости обработки пары серверов-файлообменников нам будет недостаточно, как минимум понадобится 3 реплики с 4 серверами, чтобы мы не теряли данные в случае исключительных ситуаций. Возникают также вопросы какую файловую систему использовать с таким количеством I/O, как организовывать параллельность чтения этих файлов и какого размера должны быть эти файлы, то есть по каким критериям их роллировать? Слишком большие файлы и слишком маленькие файлы будут обрабатываться неэффективно относительно такого потока данных. Сколько inode может поддерживать система? И кто будет следить за удалением неактуальных данных? Много вопросов, которые нужно прорабатывать и которые, как мне кажется, уже решены в Kafka. 3. Spark Streaming из коробки не умеет эффективно вести запись в файлы, как минимум не умеет роллировать файлы по размеру и времени. 4. Системе источнику придётся самостоятельно отслеживать изменения в файлах, если таковые будут, то есть нужно будет прикручивать механизм CDC. 5. Также возникают вопросы безопасности данных и разграничения доступов. В Kafka в большинстве своём всё уже есть, а с файлообменниками нужно будет ещё подумать, как это удобно организовать.
По поводу KSQL, вы правы, на больших объёмах использовать неэффективно, поэтому планировалось использовать KSQL именно на небольших потоках, которые появляются после фильтрации "миллиоников". Это могут быть, например, сегменты абонентов со старыми тарифами, в рамках небольшого региона. Чтобы получить таких абонентов нужно сначала с помощью Spark Streaming отфильтровать жирный поток и сделать небольшой поток из таких абонентов. Затем уже можно дополнительно строить аналитику на лету по такому потоку с помощью KSQL.
Примерно 40% в среднем по HDD и 25% по CPU и RAM. Кластер для Kafka действительно "жирный" и это осознанный шаг. Исходя из специфики потоков наших данных мы выявили важный нюанс - поток ведёт себя волнообразно и "пик волны" может быть очень большим. Проще говоря, за короткий промежуток времени поступает большой объём данных и кластер Kafka прилично нагружается. К тому же этот кластер используется для хранения промежуточных вычислений и выходных триггеров. Сообщения-триггеры создаются на основе входного сообщения, а значит, что на одно сообщение может быть сгенерировано десятки выходных сообщений триггеров и таким образом при нагрузке в 7 млн. сообщений, мы получим дополнительные 7 млн. сообщений в промежуточных топиках и уже сотни миллионов сообщений в кластере в результирующих топиках. Исходя из этого, сервера у нас с запасом и прицелом на будущее, так как есть идеи попробовать для некоторых задач использовать KSQL и подключать новые источники данных.
Для джойна стримов необходимо иметь watermark с указанием временного интервала, чтобы можно было "поймать" соотносимые данные в потоке. Если один из стримов всегда будет "бежать" быстрее другого, то нужно определённым образом скорректировать условия watermark. KSQL от Confluent имеет такую же идею, с временными окнами, но под "капотом" работает немного по другому, хотя результат такой же. Ссылка на пример кода и небольшое overview (кому интересно): https://docs.confluent.io/platform/current/streams/developer-guide/dsl-api.html#kstream-kstream-join.
В этой статье действительно не описываются конкретные задачи, которые решаются с помощью системы стриминга на основе этой концепции. Сделано это сознательно, чтобы подчеркнуть, что данная концепция достаточно универсальна и позволяет решить широкий круг задач. В нашем мире можно заметить следующую парадигму: чем быстрее данные мы обработаем, тем больше выгоды мы сможем получить. Лучший способ сделать это - обрабатывать в режиме реального времени, насколько это возможно. Если говорить о телекоме, то можно привести следующие примеры задач:
Зная, что человек находится в роуминге, мы можем сразу же оповестить человека о том, что теперь у него роуминг и ему выгодней будет временно поменять тариф или подключить соответствующую услугу. Оповестить клиента нужно быстро, в режиме реального времени, чтобы клиент не тратил зря деньги.
Зная геолокацию, например, что человек находится в торговом центре и зная из кликстрима, что он искал конкретную модель телефона, мы можем прислать смс со скидкой, если он сейчас зайдёт в retail точку МТС.
Зная информацию по событиям звонков можно вычислить в режиме реального время спамеров, мошенников и быстрее их заблокировать.
На основе информации из кликстрима, геолокации, события звонков на номера других банков можно выявить клиентов, которых интересует финансовые услуги и предложить им в числе первых актуальные услуги, например кредит на более выгодных условиях. Этот кейс подходит и для финтеха. Можно придумать ещё множество кейсов в зависимости от идей и потребностей бизнеса.
Эта статья состоит из двух частей. Первая часть содержит информацию о том, каким образом можно организовать подход к потоковой обработки данных, а вторая часть реализация этого подхода. В этой части статьи объясняется концепция, которая может быть реализована на многих популярных стеках технологий. На основе этой концепции реализована и работает система стриминга, что показывает, что эта концепция имеет право на жизнь. Подробнее о результатах и о нюансах реализации, со скриншотами метрик, характеристик железа и кусками кода будет во второй части, которая выйдет позднее.
Эту методологию на текущий момент можно реализовать и с помощью Flink. Такое решение тоже имеет право на жизнь. В нашем случае мы провели RnD на сравнение Flink vs Spark, то есть реализовали несколько кейсов, которые учитывают специфику наших данных, объёмы данных, особенности обработки. Запустили решение на одном и том же железе, на одних и тех же объёмах. Выяснили, что для решения одних и тех же задач, чтобы не создавать большие задержки в обработки данных Flink требуется больше ресурсов (CPU, RAM), чем Spark. То есть Spark обходился нам дешевле по ресурсам. Также важным фактором на тот момент был опыт и компетенции команды, в команде было больше опыта со Spark и мы могли более качественно проектировать решение. Было ещё несколько критериев, но эти моменты для нас были важнее. При этом считаю, что Flink отличный фреймворк, так как он имеет свои преимущества, на его основе можно сделать мощную систему стриминга, используя эту методологию.
Не очень понял, почему и что будет хуже? Сейчас потребление ресурсов таким и планировалось. Есть хорошее capacity по ресурсам, которое позволяет нам смело интегрировать новые источники данных и увеличивать плотность событий, которые и так увеличиваются каждые полгода. При этом мы не умираем при больших выбросах данных на "пике волны" и можем не заботиться о покупке новых серверов ближайшие несколько лет.
От Кафки отказаться в пользу файлов в нашем случае будет менее эффективным вариантом, потому что:
1. Kafka - единая интеграционная шина для систем источников данных и систем потребителей. Не все системы источники и системы потребители умеют эффективно работать с файлами, однако практически в любом популярном фреймворке и языке программирования есть интеграция с Kafka, которая обычно очень простая. При этом некоторые системы потребители могут работать только с Kafka и ради нас переходить на интеграцию через файлы не будут.
2. При таком объёме данных и скорости обработки пары серверов-файлообменников нам будет недостаточно, как минимум понадобится 3 реплики с 4 серверами, чтобы мы не теряли данные в случае исключительных ситуаций. Возникают также вопросы какую файловую систему использовать с таким количеством I/O, как организовывать параллельность чтения этих файлов и какого размера должны быть эти файлы, то есть по каким критериям их роллировать? Слишком большие файлы и слишком маленькие файлы будут обрабатываться неэффективно относительно такого потока данных. Сколько inode может поддерживать система? И кто будет следить за удалением неактуальных данных? Много вопросов, которые нужно прорабатывать и которые, как мне кажется, уже решены в Kafka.
3. Spark Streaming из коробки не умеет эффективно вести запись в файлы, как минимум не умеет роллировать файлы по размеру и времени.
4. Системе источнику придётся самостоятельно отслеживать изменения в файлах, если таковые будут, то есть нужно будет прикручивать механизм CDC.
5. Также возникают вопросы безопасности данных и разграничения доступов. В Kafka в большинстве своём всё уже есть, а с файлообменниками нужно будет ещё подумать, как это удобно организовать.
По поводу KSQL, вы правы, на больших объёмах использовать неэффективно, поэтому планировалось использовать KSQL именно на небольших потоках, которые появляются после фильтрации "миллиоников". Это могут быть, например, сегменты абонентов со старыми тарифами, в рамках небольшого региона. Чтобы получить таких абонентов нужно сначала с помощью Spark Streaming отфильтровать жирный поток и сделать небольшой поток из таких абонентов. Затем уже можно дополнительно строить аналитику на лету по такому потоку с помощью KSQL.
Примерно 40% в среднем по HDD и 25% по CPU и RAM. Кластер для Kafka действительно "жирный" и это осознанный шаг. Исходя из специфики потоков наших данных мы выявили важный нюанс - поток ведёт себя волнообразно и "пик волны" может быть очень большим. Проще говоря, за короткий промежуток времени поступает большой объём данных и кластер Kafka прилично нагружается. К тому же этот кластер используется для хранения промежуточных вычислений и выходных триггеров. Сообщения-триггеры создаются на основе входного сообщения, а значит, что на одно сообщение может быть сгенерировано десятки выходных сообщений триггеров и таким образом при нагрузке в 7 млн. сообщений, мы получим дополнительные 7 млн. сообщений в промежуточных топиках и уже сотни миллионов сообщений в кластере в результирующих топиках. Исходя из этого, сервера у нас с запасом и прицелом на будущее, так как есть идеи попробовать для некоторых задач использовать KSQL и подключать новые источники данных.
В Spark Structured Streaming джойн стримов появился с версии 2.3, сейчас актуальная версия 3.3.0 и stream-stream join продолжает развиваться.
Ссылка на пример кода и небольшое overview: https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#stream-stream-joins.
Для джойна стримов необходимо иметь watermark с указанием временного интервала, чтобы можно было "поймать" соотносимые данные в потоке. Если один из стримов всегда будет "бежать" быстрее другого, то нужно определённым образом скорректировать условия watermark. KSQL от Confluent имеет такую же идею, с временными окнами, но под "капотом" работает немного по другому, хотя результат такой же. Ссылка на пример кода и небольшое overview (кому интересно): https://docs.confluent.io/platform/current/streams/developer-guide/dsl-api.html#kstream-kstream-join.
Стоит отметить и джойн стримов у Flink - это тоже хорошее решение. Ссылка на пример кода и небольшое overview: https://nightlies.apache.org/flink/flink-docs-master/docs/dev/datastream/operators/joining/.
Что из этого эффективней работает - это интересный вопрос для исследования.
В этой статье действительно не описываются конкретные задачи, которые решаются с помощью системы стриминга на основе этой концепции. Сделано это сознательно, чтобы подчеркнуть, что данная концепция достаточно универсальна и позволяет решить широкий круг задач. В нашем мире можно заметить следующую парадигму: чем быстрее данные мы обработаем, тем больше выгоды мы сможем получить. Лучший способ сделать это - обрабатывать в режиме реального времени, насколько это возможно. Если говорить о телекоме, то можно привести следующие примеры задач:
Зная, что человек находится в роуминге, мы можем сразу же оповестить человека о том, что теперь у него роуминг и ему выгодней будет временно поменять тариф или подключить соответствующую услугу. Оповестить клиента нужно быстро, в режиме реального времени, чтобы клиент не тратил зря деньги.
Зная геолокацию, например, что человек находится в торговом центре и зная из кликстрима, что он искал конкретную модель телефона, мы можем прислать смс со скидкой, если он сейчас зайдёт в retail точку МТС.
Зная информацию по событиям звонков можно вычислить в режиме реального время спамеров, мошенников и быстрее их заблокировать.
На основе информации из кликстрима, геолокации, события звонков на номера других банков можно выявить клиентов, которых интересует финансовые услуги и предложить им в числе первых актуальные услуги, например кредит на более выгодных условиях. Этот кейс подходит и для финтеха. Можно придумать ещё множество кейсов в зависимости от идей и потребностей бизнеса.
Эта статья состоит из двух частей. Первая часть содержит информацию о том, каким образом можно организовать подход к потоковой обработки данных, а вторая часть реализация этого подхода. В этой части статьи объясняется концепция, которая может быть реализована на многих популярных стеках технологий. На основе этой концепции реализована и работает система стриминга, что показывает, что эта концепция имеет право на жизнь. Подробнее о результатах и о нюансах реализации, со скриншотами метрик, характеристик железа и кусками кода будет во второй части, которая выйдет позднее.
Эту методологию на текущий момент можно реализовать и с помощью Flink. Такое решение тоже имеет право на жизнь. В нашем случае мы провели RnD на сравнение Flink vs Spark, то есть реализовали несколько кейсов, которые учитывают специфику наших данных, объёмы данных, особенности обработки. Запустили решение на одном и том же железе, на одних и тех же объёмах. Выяснили, что для решения одних и тех же задач, чтобы не создавать большие задержки в обработки данных Flink требуется больше ресурсов (CPU, RAM), чем Spark. То есть Spark обходился нам дешевле по ресурсам. Также важным фактором на тот момент был опыт и компетенции команды, в команде было больше опыта со Spark и мы могли более качественно проектировать решение. Было ещё несколько критериев, но эти моменты для нас были важнее. При этом считаю, что Flink отличный фреймворк, так как он имеет свои преимущества, на его основе можно сделать мощную систему стриминга, используя эту методологию.