Комментарии 15
А есть ограничения по обьему даннах в такой конструкции?
0
А Google BigQuery как бы вы оценили в сравнении с вашими решениями?
+1
как-то не впечатлило. 3 ноды по 4 ядра хадупа явно на два-три порядка более, чем 1к событий/сек прожуют, а тысячу событий просто же в mysql/postgres легко писать можно. выглядит что если цену азур стека пересчитать под более близкую нагрузку к kafka+spark (за $1181) разница будет в тысячи долларов.
плюс возможности kafka+spark+настоящий map-reduce явно другая вселенная в плане возможностей напрограммировать.
в следующей статье хотелось бы обновить расчеты посерьезней нагрузкой, такой с какой имеет смысл влезать в бигдату. с 1к/сек нет смысла так усложнять архитектуру, а рост нагрузки приводит к дополнительным расходам на каждый чих. останутся ли адекватными расходы на азур стек при нагрузках, какие по зубам трем нодам хадуп?
плюс возможности kafka+spark+настоящий map-reduce явно другая вселенная в плане возможностей напрограммировать.
в следующей статье хотелось бы обновить расчеты посерьезней нагрузкой, такой с какой имеет смысл влезать в бигдату. с 1к/сек нет смысла так усложнять архитектуру, а рост нагрузки приводит к дополнительным расходам на каждый чих. останутся ли адекватными расходы на азур стек при нагрузках, какие по зубам трем нодам хадуп?
+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.
У нас были требования таковы, что архитектура должна легко скалироваться от маленькой нагрузки, до реально больших масштабов.
Тут есть специфика игр. На старте игры нет уверенности, что она взлетил, поэтому вкладываться в разработку аналитической системы, администрирования серверов, оплату мощностей, студиям не выгодно. Многие боятся больших цен или сложности поддержки всего этого.
Они хотят начать с малого, платить за то что используют. Но при этом, в случае если игра бомбанет, быть уверенными, что ничего не шлепнется. Быть способными переварить весь возросший объем данных.
0
Я тут пересчитал все без HDInsight, так как нет смысла это все пихать на Hadoop для таких объемов данных. Apache стэк так же вышел очень рентабельный =)
0
спасибо за статью и апдейт, тема интересная и было познавательно для меня. пришло понимание на кой такие сервисы клауды предлагают.
имхо без 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 неплохо прожувал.
0
Подход верный! Но мне кажется, что у вас где-то в рассчётах ошибка или что-то не учтено.
У нас небольшой кластер из 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, даже не написав ни строчки кода.
0
Я писал
Дело в том, что цена кластера — важный параметр. Но такой же важный параметр и надежность. Что будет, если эта единственная нода упадет? А что если в аналитику идут бизнес-критичные данные, по которым потом рассматривают тикеты пользователей?
Оценка Apache Stack'a была довольно грубой, широкими мазками, так сказать. Я понимал что конфигурация кластера мощнее, что можно это все развернуть руками на виртуалках меньших размеров, но я так же понимал, что студиям придется заниматься администрированием. А как я и говорил раньше, они не очень готовы в это вкладываться.
Решение «на голых VM» оценивалось ровно с такой же конфигурацией, что предлагает HDInight. Конечно, пожертвовав надежностью, можно уменьшить размер кластера и снизить цену, но это не совсем корректное сравнение.
Дело в том, что цена кластера — важный параметр. Но такой же важный параметр и надежность. Что будет, если эта единственная нода упадет? А что если в аналитику идут бизнес-критичные данные, по которым потом рассматривают тикеты пользователей?
Оценка Apache Stack'a была довольно грубой, широкими мазками, так сказать. Я понимал что конфигурация кластера мощнее, что можно это все развернуть руками на виртуалках меньших размеров, но я так же понимал, что студиям придется заниматься администрированием. А как я и говорил раньше, они не очень готовы в это вкладываться.
0
Слишком сложно и дорого. Такой поток метрик прожует ELK-стэк, развернутый на двух EX41-SSD на хецнере (2 * 34 € ), не особо при этом чихая. Да что там, rdms тоже должны справится, но эластик очевидно выигрывает за счет легкости в добавлении новых ключей и наличия коробочных средств просмотра.
0
Слишком сложно и дорого.
А в чем сложность? Все сводится к тому, чтобы поднять через портал пару сервисов, и связать их вместе. Ну в нашем случае еще пару Azure Functions написать — но это опциональный шаг, если нужна гибкость.
Такой поток метрик — довольно детская нагрузка. Среди основных требований — легко масштабироваться. Если игра схватит фичеринг, то легко можно вырасти в 10,20,30 раз.
У меня нет большого опыта с ELK. Но те студии, с которыми мы работали, у которых была своя система аналитики, ELK для игровой аналитики не пользовали. Пользовали для мониторинга.
0
Мы использовали. Считать по нему регулярные метрики — одно удовольствие. Масштабируется горизонтально добавлением новых нод, буфер на случай всплесков — обычный лог-файл, куда бекенд/сборщик сваливает события, а воркеры их разгребают и складывают в ЕС.
Нюансы были при построении воронок — в силу выбранной схемы (timeseries) приходилось писать скрипты, сохранящие список пользователей и подставляющие уменьшающийся с каждым разом список в качестве аргумента к следующему запросу. И, конечно, результаты таких агрегаций приходилось самостоятельно визуализировать.
Также болью было писать скрипты к двум разным базам — пользовательские профили в силу различных причин хранились в классической rdbms.
Прошу прощения, похоже, я не прикрепил ответ к ветке к нужной ветке диалога.
Нюансы были при построении воронок — в силу выбранной схемы (timeseries) приходилось писать скрипты, сохранящие список пользователей и подставляющие уменьшающийся с каждым разом список в качестве аргумента к следующему запросу. И, конечно, результаты таких агрегаций приходилось самостоятельно визуализировать.
Также болью было писать скрипты к двум разным базам — пользовательские профили в силу различных причин хранились в классической rdbms.
Прошу прощения, похоже, я не прикрепил ответ к ветке к нужной ветке диалога.
0
Звучит неплохо. Есть несколько вопросов:
* Приходилось ли ELK стэком визуализировать real-time данные (ну или в случае с Kibana с частым auto-refresh)?
* Какой максимальный объем данных приходилось хранить?
* Какова производительность запросов, например за сколько можно произвести аггрегацию данных всей базы?
* Хватало ли инструментов по визуализации?
* Приходилось ли ELK стэком визуализировать real-time данные (ну или в случае с Kibana с частым auto-refresh)?
* Какой максимальный объем данных приходилось хранить?
* Какова производительность запросов, например за сколько можно произвести аггрегацию данных всей базы?
* Хватало ли инструментов по визуализации?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Собственная игровая аналитика за $300 в месяц