• Три года автотестов: как повысить скорость и не только
    +1
    Мы у себя такую используем самопал — DbMocks, подробности тут:
    habr.com/ru/company/badoo/blog/443768
    Если у вас у таблицы foreign key и триггеры, то это несколько сложнее, но раз уж вы научились это транслировать в SQLite, то наверное и свой DbMocks сделаете :)
  • JVM TI: как сделать плагин для виртуальной машины
    0
    apangin, а можете ткнуть носом в годную реализацию, где есть JNI-код и одновременно Java-часть. Хочется чтобы при запуске в IDE maven пошуршал, перекомпилировал JNI и поехали дебажиться.
    P.s. CPP-код организуется через CMAKE
  • Продуктовая аналитика ВКонтакте на базе ClickHouse
    0

    Отличная статья, спасибо!
    Скажите пожалуйста, какое количество типов продуктовых событий вы ожидаете?
    Наш опыт проектирования подобной штуки показал, что при наличии более 300 событий начинает сильно деградировать система репликации, zookeeper, и т.д.

  • Анализ данных на Scala — суровая необходимость или приятная возможность?
    0
    У нас ситуация, когда встраивание model-evaluation (Java) в application-сервер (PHP) не доступно. Я хотел понять, почему Yo1 называл это анти-паттерном для JPMML. В случае batch-обработки я бы, наверное, оставил бы Spark + master=local[*] для пайплайнов. Но у нас ситуация с единичными предсказаниям. В сравнении JPMML и MLEAP пока побеждает первый, с примерно 100ms на запрос. Пытался понять, можно ли для такого кейса где-то подшаманить, чтобы сделать 10ms :)
  • Анализ данных на Scala — суровая необходимость или приятная возможность?
    0
    Поясните, пожалуйста, почему использование JPMML через REST это плохо?
    Что значит «как полагается, внутри спаркового датасета»?
  • Разгоняем обработку событий до 1,6 миллионов в секунду
    0
    Спасибо за вопрос!
    Тут суть в том, что в Exasol мы используем тот функционал, который нам не даст ClickHouse ни под каким соусом — не equi-join, оконные функции. Можно забыть про транзакционную доставку данных, и нагородить какой-то хитрый ETL с RENAME'ом таблиц/удалением партиций, и прочее, но вот JOIN, оконные функции, и у нас ещё есть немного скриптинга под Exasol — без этого мы не проживём :)
  • Анализ данных на Scala — суровая необходимость или приятная возможность?
    0
    dmitrybugaychenko, спасибо, крутейшая статья! Также как и PravdaML — присматриваемся к этому продукту.
    Есть вопрос — вы описали Pipeline, включающий в себя подготовку данных, векторизацию фич, и прочее. Этот Pipeline применяется только в batch-обработке через Spark, или доступен в real-time предсказаниях?
    Мы у себя внедряем Pipeline на Spark, но для исполнения модели используем JPMML и MLEAP движки (существенно быстрее дают предсказания чем Spark с master=local[*]). Как следствие, у нас нет таких вкусных трансформеров как SQLTransformer (требует Spark-контекст, и довольно забагованная реализация, и только у JPMML). В связи с этим интересно узнать, как вы у себя строите сервисы для real-time предсказаний?
  • Разгоняем обработку событий до 1,6 миллионов в секунду
    0
    Спасибо за комментарий!
    Я позволю себе с вами не согласиться, что Hadoop был не предназначен для задачи. Если забыть про второй ДЦ, с доставкой данных из которого возникали сложности, то задача по-прежнему звучит как «считать сложные агрегаты на массивном потоке эвентов, в окне размером вплоть до одного дня». И тут как раз работает и Spark (+Spark Streaming), разделение работ по агрегации по воркерам, использование HDFS для сохранения сериализованных представлений агрегатных функций. Поэтому, анекдот про рынок парнокопытного скота мне кажется здесь несколько притянутым.
  • Разгоняем обработку событий до 1,6 миллионов в секунду
    0
    Спасибо за аналогию, постараюсь загуглить subj :)
  • Разгоняем обработку событий до 1,6 миллионов в секунду
    0
    Спасибо за вопрос!
    На момент появления ClickHouse у нас в качестве транспорта уже использовался LSD. Переделывать связку транспорт + процессинг в один заход у нас намерения не было (переход Hadoop -> CH был не одномоментным, а постепенным), и мы фокусировались на процессинге.
    В дальнейшем мы, возможно, рассмотрим использование Kafka.
    На данный момент мне нравятся «ручки» в нашей системе вставки:
    1.) Отключение произвольных хостов/шардов
    2.) Регулирование concurrency и размера батчей
    3.) Внешний контроль в принципе. На мой взгляд, текущая интеграция CH + Kafka несколько сыровата. Например, я не понимаю, зачем нужна настройка «kafka_row_delimiter» (API Kafka подразумевает, что разбиение потока на отдельные сообщения реализовано в рамках broker-consumer протокола)
  • Разгоняем обработку событий до 1,6 миллионов в секунду
    0
    AnyKey80lvl, сейчас AD представляет собой комбинацию из Spark + Spark-ts + Yahoo Egads. В ближайшее время мы собираемся рефакторить этот функционал. Думаем над тем, чтобы оформить его в стиле Spark MLLIB (Transformers API, etc.). В этом случае можно будет говорить о каком-либо open-source. Но что это случится скоро — не могу обещать.
  • Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет
    +1
    «Explicit better than implicit» :)
    Тут получается каламбур, но — у нас явно видно, что значение для чего-то (due date) не установлено. Т.к. это поле предназначено для заполнения вручную, то автоматическое вмешательство может вызвать некий диссонанс — «как это Due date уже прошел? я не помню, чтобы менял его».
  • Развитие баз данных в Dropbox. Путь от одной глобальной базы MySQL к тысячам серверов
    0
    В 2012 году мы поняли, что создавать таблицы и обновлять их в БД на каждую добавляемую бизнес-логику очень сложно, муторно и проблематично.

    Не очень понятно — теперь альтеров нет вообще? Вроде далее описывается, что есть шарды, куча нод, и всё такое.
    Репликация в MySQL не параллельная, и все шарды работают в один поток. Если с одним шардом что-то происходит, то остальные тоже становятся жертвами.

    − Самый большой минус — намного сложнее всем этим управлять. Нужен какой-то умный планировщик, который будет понимать, куда он может вынести этот инстанс, где будет оптимальная нагрузка.

    Насколько я понимаю, на момент выхода доклада MySQL 5.7, поддерживающий многопоточную репликацию, уже применялся в ряде коммерческих проектов.
  • Исчезающие фреймворки
    +1
    Как посчитал Alex Russell, превышение размера всего в 130KB для всех наших ресурсов, может означать невозможность уложиться в 5 секундный интервал загрузки на стандартном телефоне и мобильной сети.

    Например, в этой статье суммарный объём, занимаемый встроенными в неё картинками, превысил 4Mb, что, вероятно, ощутимо для мобильного телефона.
  • Немного закулисья VK
    0
    4 года, может ещё очухается, раз про него рассказывают
  • Митап JavaJam. Спор о джавистах, сплав на брёвнах, эксперименты и микросервисы
    0
    Есть ещё малораспространённые варианты «явасек» и «ява-любознательный» (последнее применимо, впрочем к любому ЯП).
    P.s. лично меня ни один вариантов, в том числе мною озвученных, не оскорбляет. «Хоть горшком назови, только в печь не суй»
  • Patch me if you can: как мы отлаживаемся на production. Часть 2
    +5
    Есть такое понятие как common sense. Я полагаю что тестирования на возникновение колллизий не производилось, но выбранной (с запасом) точности хватает для решения поставленной задачи. Риск (вероятность возникновения ошибки, помноженная на стоимость её устранения) присутствует при разработке любого ПО. Как мне кажется, в данном случае риск не стоит того чтобы применять алгоритмы хеширования, отличные от повсеместно распространённых.
  • Сравнение открытых OLAP-систем Big Data: ClickHouse, Druid и Pinot
    +1
    В Hadoop можно добавить произвольное количество нод без какого-либо maintenance.
    Так же, как и удалить, пока replication factor данных позволяет.
    С ClickHouse это выливается в необходимость перераскладки конфига, рестарта, накатывания ALTER на новые узлы. Процедура resharding отсутствует/неактуально описана/находится в разработке.
  • Список полезных идей для высоконагруженных сервисов
    +1
    Когда что-то важное упало — напишите постмортем

    Как мне кажется, упущен пункт, что это знание должно быть расшарено с заинтересованными.
  • Мы на Highload++ в этом ноябре: задай вопрос инженерам Badoo
    +1
    В настоящий момент мы проводим эксперименты по применению ClickHouse к нашей системе потоковой агрегации событий. В общем и целом, нам удалось найти схему хранения, которая удовлетворяет нашим задачам. Осталось дело за одним нюансом — мы ждём кастомного партицирования. Нужно оно нам из соображений партицирования — мы не хотим хранить месяц данных (на самом деле — два, т.к. удалять можно только по месяцу), т.к. нам нужно максимум 1-2 дня.
    Когда система войдёт в production использование, мы выпустим статью на эту тему.
  • Выбор алгоритма вычисления квантилей для распределённой системы
    +1
    Ваши замечания вполне справедливы, однако я не был бы столь категоричен насчёт этого:
    HDR выглядит явным фаворитом уже из описания

    1. Вставка в него, безуловно, быстра. Однако, как я упоминал выше, у нас все вычисления происходят на M/R, что означает что модель у нас не мутабельна (т.е. мы не производим модификации) — бенефиты от CAS на элементы массива счётчиков нам бесполезны
    2. Необходимость иметь представление о верхней границе диапазона измеряемых значений. Поначалу мы считали, что имплементация с такими ограничениями для нас неприемлема, но со временем решили включить её в API системы дополнительно, наряду с неограниченными рядами на основании Algebird.
  • Как получить оффер в Badoo в день собеседования. Часть вторая, для PHP-разработчика
    +1
    В BI мы разрабатываем распределённые приложения для обработки данных. Стек технологий — Spark + Hadoop + Java, т.к. Java нативна для Хадупа. Система построена в тесной интеграции с PHP-backend'ом (существует DSL для описания событий, PHP-API для их отправки, различные GUI для работы с данными), так что можно смело называть связку «Java + PHP».
  • Как получить оффер в Badoo в день собеседования. Часть вторая, для PHP-разработчика
    +2
    Если вы больше про backend всё же (прямо огонь, если Java + PHP), то можно мне написать.
  • О том, как мы начинали разрабатывать собственную систему управления проектами и что из этого получилось
    +1
    Внутри система представляла собой обыкновенный сайт, написанный функциональным стилем.

    К проектам на PHP, как правило, применимо «процедурным» стилем (если имелось в виду нагромождение функций, а не оперирование функциями высших порядков).
  • Badoo time-series storage: итак, она звалась Кассандрой
    +4
    Такой вариант уже существовал в виде rrd-кластера (за вычетом резервирования), и менять шило на мыло выглядит не вполне целесообразно.
  • Распределённый xargs, или Исполнение гетерогенных приложений на Hadoop-кластере
    0
    Спасибо за ещё один инструмент в копилку!
    Как я написал в комментарии ниже, за счёт spawn'а remote shell, мы рискуем оставить после себя долгоиграющий неприбитый процесс, что для нас неприемлемо. Ну и да, опять — где брать список хостов, и т.д.
  • Распределённый xargs, или Исполнение гетерогенных приложений на Hadoop-кластере
    0
    В общем случае, любой кластер, где производятся подобного рода вычисления, является statless. Это означает, что после выполнения программы, все артефакты (временные файлы), которые она наплодила, должны быть уничтожены. Для сохранения каких-либо результатов следует использовать shared-ресурсы (база данных, HDFS).
    Конкретно в случае нашей задачи, мы на Python производим вычисления и записываем результат в файл в текущей рабочей директории. Когда бизнес-логика отработала, файл заливается в HDFS (из этого же процесса).
    В случае краха процесса/уничтожения YARN контейнера, рабочая директория контейнера уничтожается, и мы не мусорим локальную FS кластера.
  • Распределённый xargs, или Исполнение гетерогенных приложений на Hadoop-кластере
    0
    Спасибо за комментарий и интересный инструмент!
    Из входных данных проекта https://github.com/cheusov/paexec/:
    Small program that processes a list of tasks in parallel on different CPUs, computers in a network or whatever.
    Очень похоже на то, что выполняет наша утилита.
    А здесь: https://github.com/cheusov/paexec/blob/master/paexec/paexec.pod
    Tasks are read by paexec from stdin and are represented as one line of text, i.e. one input line — one task.
    И здесь мы схожи.

    Выходит, что реализации схожи, и, с моей точки зрения, обе могут называться «распределённым xargs» :)

    Со своей колокольни обратил внимание на пару вещей, из-за которых мы бы не стали этот инструмент брать в рассмотрение:

    https://github.com/cheusov/paexec/blob/master/paexec/paexec.pod
    Remember that empty line MUST NOT appears in general result lines

    Мы ограничены форматом output'а того, что мы запускаем на удалённой стороне.

    Последовательность fork-exec
    krash@krash:~$ paexec -t '/usr/bin/ssh -x' -n 'cloud1' -c '/usr/bin/uptime; echo ""' -d
    nodes_count = 1
    nodes [0]=cloududs1
    cmd = uptime; echo ""
    start: init__read_graph_tasks
    start: init__child_processes
    running cmd: /usr/bin/ssh -x cloududs1 'env PAEXEC_EOT='\'''\''  /bin/sh -c '\''/usr/bin/uptime; echo ""'\'''
    


    Команды транспорта опускаем, рассмотим то, что запускается на удалённой стороне:
    /bin/sh -c "/usr/bin/uptime"
    

    При выполнении этой команды, мы получим на удалённой стороне последовательность fork-exec, которая сначала запустит /bin/sh, а затем — fork-exec для /usr/bin/uptime.
    Я запустил paexec, указав в качестве команды пользователя /usr/bin/sleep 1000, затем прервал выполнение paexec через SIGINT.
    Что мы получаем в результате? Правильно — на удалённом хосте у нас висит /usr/bin/sleep (аналог нашего долгоиграющего приложения).
    Т.е. при прерывании работы управляющего приложения, дочерние не прибиваются. Именно по этой причине, мы в своей реализации не используем spawn shell'а, а сразу зовём execve приложения.
  • Распределённый xargs, или Исполнение гетерогенных приложений на Hadoop-кластере
    0
    Честно говоря, мы не сильно углублялись в нутра parallel, т.к. широкого применения он у нас не имеет, а предварительные изыскания показали его неприменимость к нашей задаче.
    Помимо загруженности хоста есть ещё понятие «доступности» (выключен, например, или gracefully выводится из эксплуатации :). Также, нам не хочется держать где-то в конфиге список хостов и их технические характеристики — пусть это будет головной болью кластер-менеджера.
  • SmartMonitoring — мониторинг бизнес-логики в Одноклассниках
    0
    Скажите, пожалуйста, какова частота обновления точек у одной метрики, с которой работает Anomaly Detector? Т.е. каков временной юнит, которым оперирует AD?

    И ещё вопрос — какова «пропускная способность» детектора?
    Т.е. сколько метрик обслуживает инстанс AD, в пересчёте на ядра/память?
  • Обзор конференций, на которых мы побывали в 2016 году
    +3
    Помимо Android, Java используется только в среде BI (Hadoop, Spark), т.е. массово распространения не имеет.
    В связи с этим, тематические Java конференции посетило малое количество народа, и их не включили в список.
  • Что такое облака и мифы о них в головах ИТшников: мнения, стереотипы и жизнь в «облаках»
    +1
    «Если в Германии – будет долго»

    round trip time из МСК/СПБ до вашего ДЦ можете привести, пожалуста?
  • SoftMocks: наша замена runkit для PHP 7
    0
    Это, бесспорно, круто, но не придётся ли тем же заниматься с новой версией PHP?
  • Apache Spark или возвращение блудного пользователя
    0
    У Вас в драйвере по таймеру запускается updateConditions(), который модифицирует rdd.
    1.) Насколько я понимаю, размер этой коллекции должен быть мал, т.к. она должна быть послана через broadcast на всех executor'ов — это так? Если нет — расскажите, пожалуйста.
    2.) У меня в приложении есть такая же необходимость — со временем обновлять некий конфиг, и доставлять его на executor'ов. Но, согласно документации, чтобы применилось синхронно на всех executor'ах, это должен быть либо ручной broadcast, либо неявный — через сериализатор лямбд. Недокументировано то, что при обновлении в драйвере, изменения разъедутся по executor'ам. Насколько стабильно/синхронно у Вас применяются эти изменения? Или в Вашем случае допустимо несинхронное применение изменений, и Вы о нем знаете?
  • Apache Spark или возвращение блудного пользователя
    0
    Наверное, здесь произошла «типичная подмена понятий». Вы имели в виду из executor'а (исполнителя юзерских лямбд)? А какого рода конфигурация нужна? Для своих нужд я вполне обхожусь broadcast'ами, или сериализуемым своим классом с настройками.
  • 36 млн запросов в час, 10000+ постоянно работающих клиентов, на одном сервере, nginx+mysql
    +1
    Честно говоря, 400 инсертов в секунду для одного сервера MySQL это ничто :) Другое дело, что тут всё на одной железяке.
  • Badoo PHP Code Formatter. Теперь в open source!
    +3
    Согласен, выглядит несколько пугающе, но при рассмотрении вариантов:

    1.) То же самое, в XML (плюсов с ходу не вижу, из минусов — потребить больше памяти, написать парсер конфига)
    2.) Инструкции, подобно тому, как PHP: lxr.php.net/xref/PHP_5_5/Zend/zend_language_parser.y (опять же, подсистему парсинга, но теперь уже — псевдокода конфига)
    3.) Сделать OOP-интерфейс для правил переходов
    $State ->when($ContextPredicate) ->then($Transition) ->done($ReverseTransition); // (а-ля Promises, не обещает быть меннее монстроузным)
    и для правил форматирования
    $ClassToken ->inContext($ClassDefinitionContext)->do($IndentIncreateAction) ->inContext($ClassReferenceContext)->do($IndentIncreateAction);
    4.) Текущая реализация (минимальный memory footprint, возможность программирования конфига на языке приложения)

    Последний вариант мне кажется наиболее оптимальным.
  • Badoo PHP Code Formatter. Теперь в open source!
    +1
    Проблема форматирования связана с комбинированным использованием PHP + HTML в файле.
    По инциденту заведен Issue на github, спасибо за репорт.
  • Badoo PHP Code Formatter. Теперь в open source!
    +5
    Наш pre-receive хук проверяет плохое форматирование, используя phpcf. Т.е. производится форматирование измененных строк, и, если там код не отформатирован, коммит не проходит.