Comments 15
А есть ограничения по обьему даннах в такой конструкции?
А Google BigQuery как бы вы оценили в сравнении с вашими решениями?
как-то не впечатлило. 3 ноды по 4 ядра хадупа явно на два-три порядка более, чем 1к событий/сек прожуют, а тысячу событий просто же в mysql/postgres легко писать можно. выглядит что если цену азур стека пересчитать под более близкую нагрузку к kafka+spark (за $1181) разница будет в тысячи долларов.
плюс возможности kafka+spark+настоящий map-reduce явно другая вселенная в плане возможностей напрограммировать.
в следующей статье хотелось бы обновить расчеты посерьезней нагрузкой, такой с какой имеет смысл влезать в бигдату. с 1к/сек нет смысла так усложнять архитектуру, а рост нагрузки приводит к дополнительным расходам на каждый чих. останутся ли адекватными расходы на азур стек при нагрузках, какие по зубам трем нодам хадуп?
плюс возможности kafka+spark+настоящий map-reduce явно другая вселенная в плане возможностей напрограммировать.
в следующей статье хотелось бы обновить расчеты посерьезней нагрузкой, такой с какой имеет смысл влезать в бигдату. с 1к/сек нет смысла так усложнять архитектуру, а рост нагрузки приводит к дополнительным расходам на каждый чих. останутся ли адекватными расходы на азур стек при нагрузках, какие по зубам трем нодам хадуп?
Спасибо за отзыв! Со многими пунктами согласен. Видимо не удалось передать основную идею запросов от партнеров. Как я и писал 1к в сек — смешная цифра. Но это то, с чего обычно начинают игры на старте. И заканчивают на этапе сансета.
Давайте пересчитаем =) Какую нагрузку вы считаете оптимальной для такой конфигурации кластера?
Можно, но у нас есть конкретные примеры, когда игровым студиям было проблематично поддерживать БД больших размеров (3TB+), и запросы на них выполнялись многими часами.
Можете рассказать поподробнее, в чем вы видите ограничения по возможностям напрограммировать?
Согласен, но задача была посчитать **минимальную** конфигурацию, начиная от 1к событий в сек. Я ориентировался на минимальную архитектуру Apache Stack'a в рамках HDInsight.
У нас были требования таковы, что архитектура должна легко скалироваться от маленькой нагрузки, до реально больших масштабов.
Тут есть специфика игр. На старте игры нет уверенности, что она взлетил, поэтому вкладываться в разработку аналитической системы, администрирования серверов, оплату мощностей, студиям не выгодно. Многие боятся больших цен или сложности поддержки всего этого.
Они хотят начать с малого, платить за то что используют. Но при этом, в случае если игра бомбанет, быть уверенными, что ничего не шлепнется. Быть способными переварить весь возросший объем данных.
азур стека пересчитать под более близкую нагрузку к kafka+spark (за $1181) разница будет в тысячи долларов.
Давайте пересчитаем =) Какую нагрузку вы считаете оптимальной для такой конфигурации кластера?
а тысячу событий просто же в mysql/postgres легко писать можно.
Можно, но у нас есть конкретные примеры, когда игровым студиям было проблематично поддерживать БД больших размеров (3TB+), и запросы на них выполнялись многими часами.
плюс возможности kafka+spark+настоящий map-reduce явно другая вселенная в плане возможностей напрограммировать.
Можете рассказать поподробнее, в чем вы видите ограничения по возможностям напрограммировать?
3 ноды по 4 ядра хадупа явно на два-три порядка более, чем 1к событий/сек прожуют
с 1к/сек нет смысла так усложнять архитектуру, а рост нагрузки приводит к дополнительным расходам на каждый чих.
Согласен, но задача была посчитать **минимальную** конфигурацию, начиная от 1к событий в сек. Я ориентировался на минимальную архитектуру Apache Stack'a в рамках HDInsight.
У нас были требования таковы, что архитектура должна легко скалироваться от маленькой нагрузки, до реально больших масштабов.
Тут есть специфика игр. На старте игры нет уверенности, что она взлетил, поэтому вкладываться в разработку аналитической системы, администрирования серверов, оплату мощностей, студиям не выгодно. Многие боятся больших цен или сложности поддержки всего этого.
Они хотят начать с малого, платить за то что используют. Но при этом, в случае если игра бомбанет, быть уверенными, что ничего не шлепнется. Быть способными переварить весь возросший объем данных.
Я тут пересчитал все без HDInsight, так как нет смысла это все пихать на Hadoop для таких объемов данных. Apache стэк так же вышел очень рентабельный =)
спасибо за статью и апдейт, тема интересная и было познавательно для меня. пришло понимание на кой такие сервисы клауды предлагают.
имхо без HDInsight это уже слабый конкурент. гемор в администрировании, даже ноды уже так просто не добавишь, нужно погружаться в толмуды манулов. я посмотрел у гугла минимальный, как мне показалось, вариант с их аналогом HDInsight (google dataproc). вышло около $181 за one node cluster на high-mem машинке: 26Gb ram + kafka кластер предустановленный из 3х микронод (+$105). Итого порядка $286 без сториджа. сторидж был бы еще +$82 за 2Tb.
вот это уже будет ближе к вашему азур варианту, где администрирование на себя клауд берет. тут уже сам клиент сможет ноды добавлять. что касается перфоменса one node cluster я гонял cloudera quickstart vm на i7 с 12Gb у виртуалки с 4 spark executors по 2Gb. запросы SQL spark неплохо прожувал.
имхо без HDInsight это уже слабый конкурент. гемор в администрировании, даже ноды уже так просто не добавишь, нужно погружаться в толмуды манулов. я посмотрел у гугла минимальный, как мне показалось, вариант с их аналогом HDInsight (google dataproc). вышло около $181 за one node cluster на high-mem машинке: 26Gb ram + kafka кластер предустановленный из 3х микронод (+$105). Итого порядка $286 без сториджа. сторидж был бы еще +$82 за 2Tb.
вот это уже будет ближе к вашему азур варианту, где администрирование на себя клауд берет. тут уже сам клиент сможет ноды добавлять. что касается перфоменса one node cluster я гонял cloudera quickstart vm на i7 с 12Gb у виртуалки с 4 spark executors по 2Gb. запросы SQL spark неплохо прожувал.
Подход верный! Но мне кажется, что у вас где-то в рассчётах ошибка или что-то не учтено.
У нас небольшой кластер из 4 серверов под Proxmox стоимостью около 800 евро в месяц (2x12 core CPUs, 64GB RAM, 48TB SATA storage) получает на вход порядка 6000 RPS и генерит где-то 15-20 тыс сообщений в Kafka в секунду. Сервера между собой соединены 1Gbit сетью.
В кластере Kafka развернута на двух контейнерах (да, знаю, что надо три, но мы бедные)), по 4 ядра и 16GB памяти. Входящий трафик на одном где-то 3MB/sec. Написан специальный слушатель, который читает из Kafka и пишет в HDFS (развернутый тоже в контейнере как часть Cloudera Community edition).
Сорри, увлекся. К чему я это пишу — инфраструктура Kafka/Hadoop на самом деле, для вашего объема данных — недорогая. Одного физического сервера за 200 евро в месяц вам бы хватило за глаза, и, как пишут выше, вы бы получили систему, которая масштабируется при необходимости, и вообще «другая вселенная» )
При желании, можно было бы принимать эвенты на nginx, сразу же их ложить в очередь, и с другого конца укладывать в HDFS с пом. Flume, даже не написав ни строчки кода.
У нас небольшой кластер из 4 серверов под Proxmox стоимостью около 800 евро в месяц (2x12 core CPUs, 64GB RAM, 48TB SATA storage) получает на вход порядка 6000 RPS и генерит где-то 15-20 тыс сообщений в Kafka в секунду. Сервера между собой соединены 1Gbit сетью.
В кластере Kafka развернута на двух контейнерах (да, знаю, что надо три, но мы бедные)), по 4 ядра и 16GB памяти. Входящий трафик на одном где-то 3MB/sec. Написан специальный слушатель, который читает из Kafka и пишет в HDFS (развернутый тоже в контейнере как часть Cloudera Community edition).
Сорри, увлекся. К чему я это пишу — инфраструктура Kafka/Hadoop на самом деле, для вашего объема данных — недорогая. Одного физического сервера за 200 евро в месяц вам бы хватило за глаза, и, как пишут выше, вы бы получили систему, которая масштабируется при необходимости, и вообще «другая вселенная» )
При желании, можно было бы принимать эвенты на nginx, сразу же их ложить в очередь, и с другого конца укладывать в HDFS с пом. Flume, даже не написав ни строчки кода.
Я писал
Дело в том, что цена кластера — важный параметр. Но такой же важный параметр и надежность. Что будет, если эта единственная нода упадет? А что если в аналитику идут бизнес-критичные данные, по которым потом рассматривают тикеты пользователей?
Оценка Apache Stack'a была довольно грубой, широкими мазками, так сказать. Я понимал что конфигурация кластера мощнее, что можно это все развернуть руками на виртуалках меньших размеров, но я так же понимал, что студиям придется заниматься администрированием. А как я и говорил раньше, они не очень готовы в это вкладываться.
Решение «на голых VM» оценивалось ровно с такой же конфигурацией, что предлагает HDInight. Конечно, пожертвовав надежностью, можно уменьшить размер кластера и снизить цену, но это не совсем корректное сравнение.
Дело в том, что цена кластера — важный параметр. Но такой же важный параметр и надежность. Что будет, если эта единственная нода упадет? А что если в аналитику идут бизнес-критичные данные, по которым потом рассматривают тикеты пользователей?
Оценка Apache Stack'a была довольно грубой, широкими мазками, так сказать. Я понимал что конфигурация кластера мощнее, что можно это все развернуть руками на виртуалках меньших размеров, но я так же понимал, что студиям придется заниматься администрированием. А как я и говорил раньше, они не очень готовы в это вкладываться.
Слишком сложно и дорого. Такой поток метрик прожует ELK-стэк, развернутый на двух EX41-SSD на хецнере (2 * 34 € ), не особо при этом чихая. Да что там, rdms тоже должны справится, но эластик очевидно выигрывает за счет легкости в добавлении новых ключей и наличия коробочных средств просмотра.
Слишком сложно и дорого.
А в чем сложность? Все сводится к тому, чтобы поднять через портал пару сервисов, и связать их вместе. Ну в нашем случае еще пару Azure Functions написать — но это опциональный шаг, если нужна гибкость.
Такой поток метрик — довольно детская нагрузка. Среди основных требований — легко масштабироваться. Если игра схватит фичеринг, то легко можно вырасти в 10,20,30 раз.
У меня нет большого опыта с ELK. Но те студии, с которыми мы работали, у которых была своя система аналитики, ELK для игровой аналитики не пользовали. Пользовали для мониторинга.
Мы использовали. Считать по нему регулярные метрики — одно удовольствие. Масштабируется горизонтально добавлением новых нод, буфер на случай всплесков — обычный лог-файл, куда бекенд/сборщик сваливает события, а воркеры их разгребают и складывают в ЕС.
Нюансы были при построении воронок — в силу выбранной схемы (timeseries) приходилось писать скрипты, сохранящие список пользователей и подставляющие уменьшающийся с каждым разом список в качестве аргумента к следующему запросу. И, конечно, результаты таких агрегаций приходилось самостоятельно визуализировать.
Также болью было писать скрипты к двум разным базам — пользовательские профили в силу различных причин хранились в классической rdbms.
Прошу прощения, похоже, я не прикрепил ответ к ветке к нужной ветке диалога.
Нюансы были при построении воронок — в силу выбранной схемы (timeseries) приходилось писать скрипты, сохранящие список пользователей и подставляющие уменьшающийся с каждым разом список в качестве аргумента к следующему запросу. И, конечно, результаты таких агрегаций приходилось самостоятельно визуализировать.
Также болью было писать скрипты к двум разным базам — пользовательские профили в силу различных причин хранились в классической rdbms.
Прошу прощения, похоже, я не прикрепил ответ к ветке к нужной ветке диалога.
Звучит неплохо. Есть несколько вопросов:
* Приходилось ли ELK стэком визуализировать real-time данные (ну или в случае с Kibana с частым auto-refresh)?
* Какой максимальный объем данных приходилось хранить?
* Какова производительность запросов, например за сколько можно произвести аггрегацию данных всей базы?
* Хватало ли инструментов по визуализации?
* Приходилось ли ELK стэком визуализировать real-time данные (ну или в случае с Kibana с частым auto-refresh)?
* Какой максимальный объем данных приходилось хранить?
* Какова производительность запросов, например за сколько можно произвести аггрегацию данных всей базы?
* Хватало ли инструментов по визуализации?
Sign up to leave a comment.
Собственная игровая аналитика за $300 в месяц