Про этих ребят знаем, если оглядываться назад, то в целом обратиться за поддержкой было бы разумным решением, но в моменте это был не беклог проблем, а итеративно появляющиеся, после каждой новой итерации и они все интереснее и интереснее. У нас очень динамично растет спрос на данных в этом хранилище. Так же нужно понимать что любая подобная поддержка с SLA в несколько дней и не всегда такого же качества как собственная экспертиза, мы отправляли запрос в altinity именно по части обучения уровня DBA наших ребят, но в тот момент такой услуги у них не было.
Но даже сейчас мы думаем о том чтобы воспользоваться консультацией по некоторым вопросам и возможно мы воспользуемся их услугами.
Если речь про cloud решения которые делает altinity, то тут исследований не проводили, мы пробовали использовать яндекс.облако и нам не понравилась эксплуатация этого решения, когда речь коснулась мониторинга и траблшутинга некоторых проблем, но возможно на текущий момент ситуация изменилась. Но как быстрый старт - это отличное решение!
Какой-нибудь журнал на случай отключения до дампа данных?
Не понял вопроса, но думаю имеется ввиду "отключения для дампа", это отдельно рассмотрим в другой статье. Скорее стык между окружением с low latency и окружением которое может работать медленно потому что идет обслуживание или к нам вышел новый аналитики который по незнанию приложил хранилище )
Сейчас вы сделали для них промежуточный интерфейс, или это превратилось в python + SQL?
Многие запросы теперь не требуют написания python кода, но к сожалению пока нам удалось не везде исключить использование python, но мы работаем над этим. Исключить использование python конечно не цель, но продуктивнее когда аналитику не приходиться писать python код на любой чих.
Тут скорее вопрос был про содержание данных: много ли числовых полей и т.п. Судя по описанию - большая часть данных - enum-ы и числовые значения, преимущественно из ограниченного диапазона, верно?
Большинство enum + числа, но много datetime и основной прожорливый тип это конечно UUID, но в clickhouse для его хранения есть тоже достаточно эффективный тип колонок UUID.
ElasticSearch у нас использовался только для хранения информации о действиях пользователей (clickstream), в случае текущего кластера clickhouse - это уже data lake для хранения, обработки и объединения данных из всех источников, тут поток данных расширился сильно. Если вопрос про инсталляцию того ElasticSearch, то у нас средний размер записей около 400 байт на запись (размер уже в хранилище с некоторым коэффициентом сжатия).
Про решение проблем с пиками и скоростью разбора этих пиков это скорее уже тема для след. статьи про это мы тоже напишем в ближайшее время. Но сейчас кратко могу ответить что в целом проблему с пиками мы не испытывали и доставляли данные с задержкой до 2-ух минут. Зачет запись данных в хранилище пачками по несколько тысяч. До хранилища ранее у нас стоял redis где копились данные, сейчас мы перешли в большинстве мест на kafka, как накопительный буфер.
После перехода на CH у нас добавилось работы по поддержке этого хранилища, по крайней мере на текущем этапе, но это возможно из за того что запросов к хранилищу стало больше, но при этом задачи решаются быстрее, ранее аналитики выгружали куски данных в python + pandas и крутили уже сегменты данных в памяти, для 95% задач этого достаточно, но не удобно для использования. В целом мы ставили задачи которые решили переходом: повысить удобство использования хранилища аналитиками, эффективнее использовать ресурсы хранилища, уменьшить кол-во задач где аналитику приходится всю обработку данных строить на pandas и без использования BI инструментов.
В основном мы работаем с данными продаж, которые позволяют сегментировать типы совершенных заказов, а так же click stream, все действия пользователей на сайте (клики, заходы на страницы, какие-то действия в интерфейсе) по которым в основном анализируются воронки посещаемость отдельных проектов. click stream в целом приметивен это как правило документ из нескольких полей обязательными там: имя события (с очень низкой кардинальностью, т.е. много событий которые имеют малое кол-во уникальных значений), время события на устройстве пользователя и идентификатор пользователя UUID, есть еще несколько технических обязательных параметров, но не думаю что это важно + все события имеют несколько сотен возможных параметров, по сути если это представить в виде таблички это очень широкая табличка с большим кол-вом колонок. Clickhouse очень хорошо жмет данные если вы их храните ввиде колонок скалярных типов (не используя массивы, структуры типа nested, строки с json и пр.)
Один из примеров потери данных - в некоторых случая мы замечали что при чтении данных из kafka терялись данные и не доходили до таблички.
Я конечно понимаю положительность затеи. Но к сожалению для того что бы выделить компонент в самостоятельный необходимо его протестировать как «самостоятельный», в разных окружениях и прочее, без отладки в условиях «самостоятельности» эта затея мало полезна. Я говорю что подобная затея может оказаться не эффективной в плане расходования времени. Лучше при необходимости произвести рефакторинг и вынести компонент в отдельную библиотеку. Но тут тоже есть подводный камень при вынесении кода из работающего проекта в отдельную библиотеку есть риск что-либо сломать, конечно если тесты вероятность этого снижается.
Это конечно здорово если все библиотеки будут атомарные и независимые. Только вот это далеко от реальности, по крайней мере при разработке бизнес приложений.
Вот пример поставлена задача реализовать работу приложения по определенному интерфейсу для работы с API какого либо сервиса (предположим что готовых библиотек для работы с нашим API нет) и в момент написания не известно будет ли данная библиотека использоваться в дальнейшем. Что делаю я, как разработчик — решаю задачу. Пишу библиотеку (класс, модуль что угодно) для работы конкретного приложения и тестирую приложение и наш свеженаписанный модуль в тех условиях в которых используется мое приложение. Результат: задача решена в максимально выгодные сроки.
Затем через полгода приходит автор и говорит: «Вот мне нужна вот эта штука....» (продолжение смотреть выше)
Т.е. уважаемый предлагает плевать на задачи которые ставятся перед разработчиками и разрабатывать модули с тестированием во всевозможных условиях пусть даже далеких от реалий проекта, на тот случай «А вдруг кому нибудь понадобится». Считаю что выделение в самостоятельные библиотеки необходимо делать лишь если возникла потребность в повторном использовании кода.
Кому-то удобно пользоваться и notepad, vi или редактором в mc, команды программистов работающие над проектами бывают разные и вкусы у всех разные, да и не всегда есть возможность запустить IDE, для того что бы сделать какой либо hotfix.
На своих проектах админку локализаций делал по принципу описанному в этой презентации www.slideshare.net/ingvar/symfony-presentation-i18n-2, там описано именно работа с отдельными сообщениями, на последних слайдах есть скриншот админки, делал локализацию объектов по тому же принципу, все поля подлежащие переводу клал в отдельную таблицу, минус что приходилось join`ить таблицы, но в плане удобства очень приятное решение. Список всех языков выделен в отдельные сущности, т.е. таблицы с переводами имеют внешние ключи. Так же в таблицах с переводами определен язык по умолчанию. Пока проблем в данном механизме не возникало. Если у кого проблемы были буду рад о них узнать.
На мой взгляд, постепенное вовлечение это просто отличная идея, но вот только надо понимать что такого рода регистрация очень хороша для контингента «домохозяек» и подобного рода людей, а не людей живущих в интернете. Для продвинутых пользователей подобная регистрация будет только дополнительным раздражителем, т.к. продвинутый пользователь прекрасно понимает зачем он регистрируется на том или ином сервисе
Про этих ребят знаем, если оглядываться назад, то в целом обратиться за поддержкой было бы разумным решением, но в моменте это был не беклог проблем, а итеративно появляющиеся, после каждой новой итерации и они все интереснее и интереснее. У нас очень динамично растет спрос на данных в этом хранилище. Так же нужно понимать что любая подобная поддержка с SLA в несколько дней и не всегда такого же качества как собственная экспертиза, мы отправляли запрос в altinity именно по части обучения уровня DBA наших ребят, но в тот момент такой услуги у них не было.
Но даже сейчас мы думаем о том чтобы воспользоваться консультацией по некоторым вопросам и возможно мы воспользуемся их услугами.
Если речь про cloud решения которые делает altinity, то тут исследований не проводили, мы пробовали использовать яндекс.облако и нам не понравилась эксплуатация этого решения, когда речь коснулась мониторинга и траблшутинга некоторых проблем, но возможно на текущий момент ситуация изменилась. Но как быстрый старт - это отличное решение!
Не понял вопроса, но думаю имеется ввиду "отключения для дампа", это отдельно рассмотрим в другой статье. Скорее стык между окружением с low latency и окружением которое может работать медленно потому что идет обслуживание или к нам вышел новый аналитики который по незнанию приложил хранилище )
Многие запросы теперь не требуют написания python кода, но к сожалению пока нам удалось не везде исключить использование python, но мы работаем над этим. Исключить использование python конечно не цель, но продуктивнее когда аналитику не приходиться писать python код на любой чих.
Большинство enum + числа, но много datetime и основной прожорливый тип это конечно UUID, но в clickhouse для его хранения есть тоже достаточно эффективный тип колонок UUID.
Как обещал отвечаю на оставшиеся вопросы (-:
ElasticSearch у нас использовался только для хранения информации о действиях пользователей (clickstream), в случае текущего кластера clickhouse - это уже data lake для хранения, обработки и объединения данных из всех источников, тут поток данных расширился сильно. Если вопрос про инсталляцию того ElasticSearch, то у нас средний размер записей около 400 байт на запись (размер уже в хранилище с некоторым коэффициентом сжатия).
Про решение проблем с пиками и скоростью разбора этих пиков это скорее уже тема для след. статьи про это мы тоже напишем в ближайшее время. Но сейчас кратко могу ответить что в целом проблему с пиками мы не испытывали и доставляли данные с задержкой до 2-ух минут. Зачет запись данных в хранилище пачками по несколько тысяч. До хранилища ранее у нас стоял redis где копились данные, сейчас мы перешли в большинстве мест на kafka, как накопительный буфер.
После перехода на CH у нас добавилось работы по поддержке этого хранилища, по крайней мере на текущем этапе, но это возможно из за того что запросов к хранилищу стало больше, но при этом задачи решаются быстрее, ранее аналитики выгружали куски данных в python + pandas и крутили уже сегменты данных в памяти, для 95% задач этого достаточно, но не удобно для использования. В целом мы ставили задачи которые решили переходом: повысить удобство использования хранилища аналитиками, эффективнее использовать ресурсы хранилища, уменьшить кол-во задач где аналитику приходится всю обработку данных строить на pandas и без использования BI инструментов.
В основном мы работаем с данными продаж, которые позволяют сегментировать типы совершенных заказов, а так же click stream, все действия пользователей на сайте (клики, заходы на страницы, какие-то действия в интерфейсе) по которым в основном анализируются воронки посещаемость отдельных проектов. click stream в целом приметивен это как правило документ из нескольких полей обязательными там: имя события (с очень низкой кардинальностью, т.е. много событий которые имеют малое кол-во уникальных значений), время события на устройстве пользователя и идентификатор пользователя UUID, есть еще несколько технических обязательных параметров, но не думаю что это важно + все события имеют несколько сотен возможных параметров, по сути если это представить в виде таблички это очень широкая табличка с большим кол-вом колонок. Clickhouse очень хорошо жмет данные если вы их храните ввиде колонок скалярных типов (не используя массивы, структуры типа nested, строки с json и пр.)
Один из примеров потери данных - в некоторых случая мы замечали что при чтении данных из kafka терялись данные и не доходили до таблички.
На другие вопросы чуть позже отвечу
Вот пример поставлена задача реализовать работу приложения по определенному интерфейсу для работы с API какого либо сервиса (предположим что готовых библиотек для работы с нашим API нет) и в момент написания не известно будет ли данная библиотека использоваться в дальнейшем. Что делаю я, как разработчик — решаю задачу. Пишу библиотеку (класс, модуль что угодно) для работы конкретного приложения и тестирую приложение и наш свеженаписанный модуль в тех условиях в которых используется мое приложение. Результат: задача решена в максимально выгодные сроки.
Затем через полгода приходит автор и говорит: «Вот мне нужна вот эта штука....» (продолжение смотреть выше)
Т.е. уважаемый предлагает плевать на задачи которые ставятся перед разработчиками и разрабатывать модули с тестированием во всевозможных условиях пусть даже далеких от реалий проекта, на тот случай «А вдруг кому нибудь понадобится». Считаю что выделение в самостоятельные библиотеки необходимо делать лишь если возникла потребность в повторном использовании кода.
К примеру gedit бывает странно отображает табы