Привет, сообщество! Где-то два месяца назад мне пришла в голову идея, очень простая по своей сути, но ой как обширная, если начать в ней копаться более подробно.
В мире порядка 200 территорий выдаёт паспорта. И порядка 250 направлений, куда по одному из этих паспортов можно поехать. А что если, создать базу таких связей (паспорт-направление), но не просто, а ссылаясь на официальные источники.
Так родился проект EntryConditions.comЧитать полностью »
Звонил мне на днях один знакомый CIO. Питерский, ритейл, средний бизнес, ничего особенного. Слушай, говорит, надо нам с ИИ что‑то делать: все вокруг внедряют, конкуренты вон что‑то запустили, на отраслевом Data Summit уши прожужжали, а у меня даже плана нет. И денег, кстати, особо на это не выделили, но не суть.
Это был, кажется, пятый такой звонок за месяц.
Когда инженер слышит «нам нужно хранилище данных», задача редко звучит однозначно. Кто‑то задыхается на боевой OLTP‑базе под аналитической нагрузкой. Кто‑то впервые строит BI и не понимает, с какого края подходить. У кого‑то накопились данные из десятка систем‑источников, и существующих средств уже не хватает.
У всех «хранилище». А правильный технический ответ зависит от условий задачи.
Автор работал в различных дата-инженерных проектах и иногда проекты представляют собой набор модулей без логики и без общего подхода. Поэтому цель статьи - разработать этот общий подход и заодно поупражняться вместе с читателем в его создании.
В Enterprise мы работаем с трансформациями данных, поэтому:
Краеугольный камень - это бизнес-процесс, некий Flow, который преобразует одну или несколько таблиц.
Таблица - это вспомогательная сущность, обслуживающая бизнес. Попытка сделать таблицы основными сущностями приведет к размыванию бизнес-логики.
CPU 80%, память на пределе, диск нагружен. Запросы тормозят. Расчёты не завершаются. Сервер на грани. Что же делать?
Расскажу как начинаю диагностику и как найти запрос, который создаёт нагрузку.
Если нода прямо сейчас перегружена, начинаем с system.processesЧитать полностью »
К написанию данной статьи меня подтолкнула другая статья:
«Не только sum() и uniq(): малоизвестные и очень полезные функции ClickHouse»
и вопрос автора: «В комментариях расскажите, какие „непопулярные“ функции кликхаус упростили вам жизнь.»
Недолго думая, я ответил: cityHash64().
Решил я как-то выгрузить пару лет переписки из Telegram в Apache Doris на своем компе. Зачем? Я тестирую Doris как единую систему хранения и поиска по всем личным данным: сообщениям из мессенджеров, ChatGPT, записям встреч и почте.
Первый запуск был болезненным: загрузка занимала почти 2 часа. После небольшой оптимизации пайплайна тот же сценарий дал другой результат: 206 400 сообщений за 5 секунд, то есть примерно 41 280 сообщений в секунду. Для контекста: каждое сообщение я грузил как JSON-массив.
В этот момент я подумал: «Окей, а что именно внутри Doris делает такую разницу между “2 часа” и “5 секунд”?».
Привет!
Меня зовут Натаров Иван. Я занимаюсь вопросами обработки, анализа и визуализации данных.
ClickHouse сегодня стал стандартом де-факто для аналитических задач, но часто начинающие специалисты тратят слишком много времени на погружение в технологию. Документация зачастую дает либо слишком поверхностное объяснение, либо уходит в технические детали, которые сложны для восприятия новичками.
В этой статье мы разберем фундамент ClickHouse - движок MergeTreeЧитать полностью »
