Мы у себя такую используем самопал — DbMocks, подробности тут: habr.com/ru/company/badoo/blog/443768
Если у вас у таблицы foreign key и триггеры, то это несколько сложнее, но раз уж вы научились это транслировать в SQLite, то наверное и свой DbMocks сделаете :)
apangin, а можете ткнуть носом в годную реализацию, где есть JNI-код и одновременно Java-часть. Хочется чтобы при запуске в IDE maven пошуршал, перекомпилировал JNI и поехали дебажиться.
P.s. CPP-код организуется через CMAKE
Отличная статья, спасибо!
Скажите пожалуйста, какое количество типов продуктовых событий вы ожидаете?
Наш опыт проектирования подобной штуки показал, что при наличии более 300 событий начинает сильно деградировать система репликации, zookeeper, и т.д.
У нас ситуация, когда встраивание model-evaluation (Java) в application-сервер (PHP) не доступно. Я хотел понять, почему Yo1 называл это анти-паттерном для JPMML. В случае batch-обработки я бы, наверное, оставил бы Spark + master=local[*] для пайплайнов. Но у нас ситуация с единичными предсказаниям. В сравнении JPMML и MLEAP пока побеждает первый, с примерно 100ms на запрос. Пытался понять, можно ли для такого кейса где-то подшаманить, чтобы сделать 10ms :)
Спасибо за вопрос!
Тут суть в том, что в Exasol мы используем тот функционал, который нам не даст ClickHouse ни под каким соусом — не equi-join, оконные функции. Можно забыть про транзакционную доставку данных, и нагородить какой-то хитрый ETL с RENAME'ом таблиц/удалением партиций, и прочее, но вот JOIN, оконные функции, и у нас ещё есть немного скриптинга под Exasol — без этого мы не проживём :)
dmitrybugaychenko, спасибо, крутейшая статья! Также как и PravdaML — присматриваемся к этому продукту.
Есть вопрос — вы описали Pipeline, включающий в себя подготовку данных, векторизацию фич, и прочее. Этот Pipeline применяется только в batch-обработке через Spark, или доступен в real-time предсказаниях?
Мы у себя внедряем Pipeline на Spark, но для исполнения модели используем JPMML и MLEAP движки (существенно быстрее дают предсказания чем Spark с master=local[*]). Как следствие, у нас нет таких вкусных трансформеров как SQLTransformer (требует Spark-контекст, и довольно забагованная реализация, и только у JPMML). В связи с этим интересно узнать, как вы у себя строите сервисы для real-time предсказаний?
Спасибо за комментарий!
Я позволю себе с вами не согласиться, что Hadoop был не предназначен для задачи. Если забыть про второй ДЦ, с доставкой данных из которого возникали сложности, то задача по-прежнему звучит как «считать сложные агрегаты на массивном потоке эвентов, в окне размером вплоть до одного дня». И тут как раз работает и Spark (+Spark Streaming), разделение работ по агрегации по воркерам, использование HDFS для сохранения сериализованных представлений агрегатных функций. Поэтому, анекдот про рынок парнокопытного скота мне кажется здесь несколько притянутым.
Спасибо за вопрос!
На момент появления ClickHouse у нас в качестве транспорта уже использовался LSD. Переделывать связку транспорт + процессинг в один заход у нас намерения не было (переход Hadoop -> CH был не одномоментным, а постепенным), и мы фокусировались на процессинге.
В дальнейшем мы, возможно, рассмотрим использование Kafka.
На данный момент мне нравятся «ручки» в нашей системе вставки:
1.) Отключение произвольных хостов/шардов
2.) Регулирование concurrency и размера батчей
3.) Внешний контроль в принципе. На мой взгляд, текущая интеграция CH + Kafka несколько сыровата. Например, я не понимаю, зачем нужна настройка «kafka_row_delimiter» (API Kafka подразумевает, что разбиение потока на отдельные сообщения реализовано в рамках broker-consumer протокола)
AnyKey80lvl, сейчас AD представляет собой комбинацию из Spark + Spark-ts + Yahoo Egads. В ближайшее время мы собираемся рефакторить этот функционал. Думаем над тем, чтобы оформить его в стиле Spark MLLIB (Transformers API, etc.). В этом случае можно будет говорить о каком-либо open-source. Но что это случится скоро — не могу обещать.
«Explicit better than implicit» :)
Тут получается каламбур, но — у нас явно видно, что значение для чего-то (due date) не установлено. Т.к. это поле предназначено для заполнения вручную, то автоматическое вмешательство может вызвать некий диссонанс — «как это Due date уже прошел? я не помню, чтобы менял его».
В 2012 году мы поняли, что создавать таблицы и обновлять их в БД на каждую добавляемую бизнес-логику очень сложно, муторно и проблематично.
Не очень понятно — теперь альтеров нет вообще? Вроде далее описывается, что есть шарды, куча нод, и всё такое.
Репликация в MySQL не параллельная, и все шарды работают в один поток. Если с одним шардом что-то происходит, то остальные тоже становятся жертвами.
− Самый большой минус — намного сложнее всем этим управлять. Нужен какой-то умный планировщик, который будет понимать, куда он может вынести этот инстанс, где будет оптимальная нагрузка.
Насколько я понимаю, на момент выхода доклада MySQL 5.7, поддерживающий многопоточную репликацию, уже применялся в ряде коммерческих проектов.
Как посчитал Alex Russell, превышение размера всего в 130KB для всех наших ресурсов, может означать невозможность уложиться в 5 секундный интервал загрузки на стандартном телефоне и мобильной сети.
Например, в этой статье суммарный объём, занимаемый встроенными в неё картинками, превысил 4Mb, что, вероятно, ощутимо для мобильного телефона.
Есть ещё малораспространённые варианты «явасек» и «ява-любознательный» (последнее применимо, впрочем к любому ЯП).
P.s. лично меня ни один вариантов, в том числе мною озвученных, не оскорбляет. «Хоть горшком назови, только в печь не суй»
Есть такое понятие как common sense. Я полагаю что тестирования на возникновение колллизий не производилось, но выбранной (с запасом) точности хватает для решения поставленной задачи. Риск (вероятность возникновения ошибки, помноженная на стоимость её устранения) присутствует при разработке любого ПО. Как мне кажется, в данном случае риск не стоит того чтобы применять алгоритмы хеширования, отличные от повсеместно распространённых.
В Hadoop можно добавить произвольное количество нод без какого-либо maintenance.
Так же, как и удалить, пока replication factor данных позволяет.
С ClickHouse это выливается в необходимость перераскладки конфига, рестарта, накатывания ALTER на новые узлы. Процедура resharding отсутствует/неактуально описана/находится в разработке.
Скажите, а какие фичи учитывает модель для определения оптимального кодека для колонок?
С ходу мысль - для низкокардинальных полей использовать RLE. Но что положить в модель - не очень понятно.
И второй вопрос - оптимизация направлена только на оптимизацию сжатия?
Часто можно применть ZSTD с максимальным сжатием, но перф работы при этом будет оставлять желать лучшего.
Спасибо.
habr.com/ru/company/badoo/blog/443768
Если у вас у таблицы foreign key и триггеры, то это несколько сложнее, но раз уж вы научились это транслировать в SQLite, то наверное и свой DbMocks сделаете :)
P.s. CPP-код организуется через CMAKE
Отличная статья, спасибо!
Скажите пожалуйста, какое количество типов продуктовых событий вы ожидаете?
Наш опыт проектирования подобной штуки показал, что при наличии более 300 событий начинает сильно деградировать система репликации, zookeeper, и т.д.
Что значит «как полагается, внутри спаркового датасета»?
Тут суть в том, что в Exasol мы используем тот функционал, который нам не даст ClickHouse ни под каким соусом — не equi-join, оконные функции. Можно забыть про транзакционную доставку данных, и нагородить какой-то хитрый ETL с RENAME'ом таблиц/удалением партиций, и прочее, но вот JOIN, оконные функции, и у нас ещё есть немного скриптинга под Exasol — без этого мы не проживём :)
Есть вопрос — вы описали Pipeline, включающий в себя подготовку данных, векторизацию фич, и прочее. Этот Pipeline применяется только в batch-обработке через Spark, или доступен в real-time предсказаниях?
Мы у себя внедряем Pipeline на Spark, но для исполнения модели используем JPMML и MLEAP движки (существенно быстрее дают предсказания чем Spark с master=local[*]). Как следствие, у нас нет таких вкусных трансформеров как SQLTransformer (требует Spark-контекст, и довольно забагованная реализация, и только у JPMML). В связи с этим интересно узнать, как вы у себя строите сервисы для real-time предсказаний?
Я позволю себе с вами не согласиться, что Hadoop был не предназначен для задачи. Если забыть про второй ДЦ, с доставкой данных из которого возникали сложности, то задача по-прежнему звучит как «считать сложные агрегаты на массивном потоке эвентов, в окне размером вплоть до одного дня». И тут как раз работает и Spark (+Spark Streaming), разделение работ по агрегации по воркерам, использование HDFS для сохранения сериализованных представлений агрегатных функций. Поэтому, анекдот про рынок парнокопытного скота мне кажется здесь несколько притянутым.
На момент появления ClickHouse у нас в качестве транспорта уже использовался LSD. Переделывать связку транспорт + процессинг в один заход у нас намерения не было (переход Hadoop -> CH был не одномоментным, а постепенным), и мы фокусировались на процессинге.
В дальнейшем мы, возможно, рассмотрим использование Kafka.
На данный момент мне нравятся «ручки» в нашей системе вставки:
1.) Отключение произвольных хостов/шардов
2.) Регулирование concurrency и размера батчей
3.) Внешний контроль в принципе. На мой взгляд, текущая интеграция CH + Kafka несколько сыровата. Например, я не понимаю, зачем нужна настройка «kafka_row_delimiter» (API Kafka подразумевает, что разбиение потока на отдельные сообщения реализовано в рамках broker-consumer протокола)
Тут получается каламбур, но — у нас явно видно, что значение для чего-то (due date) не установлено. Т.к. это поле предназначено для заполнения вручную, то автоматическое вмешательство может вызвать некий диссонанс — «как это Due date уже прошел? я не помню, чтобы менял его».
Не очень понятно — теперь альтеров нет вообще? Вроде далее описывается, что есть шарды, куча нод, и всё такое.
Насколько я понимаю, на момент выхода доклада MySQL 5.7, поддерживающий многопоточную репликацию, уже применялся в ряде коммерческих проектов.
Например, в этой статье суммарный объём, занимаемый встроенными в неё картинками, превысил 4Mb, что, вероятно, ощутимо для мобильного телефона.
P.s. лично меня ни один вариантов, в том числе мною озвученных, не оскорбляет. «Хоть горшком назови, только в печь не суй»
Так же, как и удалить, пока replication factor данных позволяет.
С ClickHouse это выливается в необходимость перераскладки конфига, рестарта, накатывания ALTER на новые узлы. Процедура resharding отсутствует/неактуально описана/находится в разработке.
Как мне кажется, упущен пункт, что это знание должно быть расшарено с заинтересованными.