Привет, Хабр! Хочу поделиться своей историей того, как я пришла к GitHub Actions в попытках автоматизировать сбор аналитики для личного использования.
Статья будет полезна аналитикам, которые хотят автоматизировать сбор и анализ данных для своих небольших пет‑проектов.
До начала обработки персональных данных оператор должен подать уведомление в Роскомнадзор. В сегодняшних реалиях по факту 99.9% самозанятых, ИП и организаций являются операторами и должны подать уведомление.
За неподачу или за несвоевременную подачу уведомления о намерении осуществлять обработку персональных данных предусмотрены штрафы.
И вот первые судебные ласточки по этому поводу...
Можно ли подключить сетевой диск к железному серверу за минуту, при этом не выключая его, сохраняя отказоустойчивость и не привлекая инженеров?
Я Беляков Алексей — Go-разработчик в Cloud.ru, в статье расскажу, как нам удалось это сделать. Сначала поделюсь кейсами, которые натолкнули на создание такой фичи, затем расскажу, как мы реализовали ее интеграцию со стороны сервиса Bare Metal, а в конце покажу, как всего за минуту можно расширить дисковое пространство физического сервера.
Привет! Меня зовут Андрей, я разработчик из команды контента в Банки.ру.
Как человек, который постоянно изучает новые технологии и читает тонны документации, я давно устал тратить часы на ручное конспектирование. Перепробовал кучу способов — от блокнотов до сложных систем управления знаниями, пока не наткнулся на идеальную связку Obsidian + Zotero.
В этой статье поделюсь своим решением для автоматизации конспектов, которое экономит мне кучу времени и нервов. Если вы тоже много читаете и устали переписывать цитаты руками — эта статья для вас. Расскажу, как за 10 минут настроить систему, которая будет сама создавать красивые конспекты
Не так давно в блоге компании Arenadata был опубликован материал тестирования поведения различных распределенных файловых систем при работе с маленькими файлами (~2 Мб). Краткий вывод: по результатам проверки оказалось, что лучше всего с задачей маленьких файлов справляется старый-добрый HDFS, деградируя в 1.5 раза, S3 на базе minIO не тянет, замедляясь в 8 раз, S3 API над Ozone деградирует в 4 раза, а наиболее предпочтительной системой в при работе с мелкими файлами, по утверждению коллег, является Greenplum, в том числе для компаний «экзабайтного клуба». Коллеги также выполнили огромную работу по поиску «Теоретических подтверждений неожиданных показателей».
Результаты тестирования в части S3 minIO показались нашей команде неубедительными, и мы предположили, что они могут быть связаны с:
• недостаточным практическим опытом эксплуатации SQL compute over S3 и S3 в целом;
• отсутствием опыта работы с кластерами minIO. В частности в высоконагруженном продуктивном окружении на 200+ Тб сжатых колоночных данных Iceberg/parquet, особенно в сценариях, где проблема маленьких файлов быстро становится актуальной.
• особенностями сборок дистрибутивов;
Мы благодарны коллегам за идею и вдохновение провести аналогичное тестирование. Давайте разбираться.
Когда я начал работать с Asio и изучал документацию библиотеки, прочитал мнение, что доку писали «для роботов». Описание каждого концепта, функции или особенности приводится лишь однажды, без перекрестных ссылок и других удобных для разработчика деталей. Документация составлена так, что понять ее может разве что машина, «просканировав» текст целиком.
Я подумал, что было бы здорово написать статью, которая служила бы введением в библиотеку. Статью, которая помогла бы начать пользоваться Asio, даже если раньше вы с ней не работали. Что получилось, читайте под катом.
На первый взгляд работа с данными может показаться скучной, состоящей из перетаскивания данных из одного хранилища в другое. В этом действительно есть часть правды :) но не вся правда… Если присмотреться, мы увидим, что дата-инженеры помогают компаниям сокращать время на поиск инсайтов, обучение моделей и понимание нужд пользователей. Данные — это новая нефть, поэтому важно понимать, как правильно их организовывать и какие сложности в работе могут повлиять на успешность бизнеса.
Привет, Хабр! Меня зовут Алёна Катренко, и я уже больше 10 лет работаю с данными. Сейчас занимаю позицию руководителя платформы данных в Циане, но начинала как BigData-инженер в Неофлексе. Сегодня расскажу, как мы приручали петабайты данных, искали призраков забытых таблиц и нашли инструмент, который сделал работу с метаданными понятной, безопасной и полезной для бизнеса. А ещё о том, как сейчас развиваться дату-инженеру, чтобы успевать за тенденциями на рынке.
Привет!
У бизнеса на практике часто встречается задача построить полноценную аналитику, используя данных из excel, csv файлов. Разнообразие подходов к заполнению и образованию таких файлов может быть разное:
Привет Хабр! Меня зовут Юлия Воробьева, и уже больше 10 лет я занимаюсь тестированием. За это время успела поработать в проектах, связанных с восстановлением, миграцией и резервным копированием данных. Я много занимаюсь облачными технологиями и получаю от этого настоящее удовольствие. Последние 6 лет я работаю в компании Хайстекс, где продукт и задачи позволяют мне не просто тестировать, а прокачивать экспертизу и при этом сохранять интерес к облачным решениям.
В этой статье расскажу, как мы настроили, внедрили и протестировали резервное копирование с решением Хайстекс Акура и S3-хранилищем от Selectel, на основе реальных требований и возможностей компании-клиента. Покажу, как это выглядит на практике глазами QA.
Не претендую на универсальный рецепт, но подробно опишу, как мы упростили восстановление тестовой среды, сэкономили время и перестали бояться, что важные данные потеряются после очередного сбоя. Разберу всё по шагам: как настраивали, что сработало, где пришлось доработать и какие выводы сделали в итоге. Если вам интересно, как внедрить надежный бэкап всех данных у себя в компании, встретимся под катом. Там же ссылка на вебинар для тех, кому ближе видеоформат.
Пошаговое руководство по установке и настройке кластера Apache Kafka с тремя брокерами в режиме KRaft (без ZooKeeper) на Windows — без виртуальных машин и Confluent Cloud.
Чтобы сделать кластер удобнее в использовании и приблизить его функциональность к облачным решениям, мы добавим веб-интерфейс на основе Kafka UI.
В результате получится гибкая система, которую можно масштабировать и настраивать под свои задачи.
Для кого эта статья?
Для тех, кто только начинает работать с Kafka и хочет разобраться в её устройстве на практике.
Для тех, кто работает на Windows, но не хочет ставить виртуальную машину.
Для тех, кто хочет понять внутреннее устройство Kafka, а не просто запустить «чёрный ящик».
Это третья статья специалиста по архитектуре ИТ-систем и трансформации ИТ-ландшафта Дениса Прилепского из серии «Строим корпоративную GenAI-платформу: от концепции до ROI». Автор разбирает, что такое RAG и зачем он нужен, как устроена архитектура retrieval-уровня и почему он критически важен для достоверных ответов. В статье — пример генерации юридической справки, практические проблемы (задержки, кеширование, актуальность) и подготовка к следующей теме — guardrails.
PostgreSQL известна как надежная и универсальная СУБД. Но если нужно хранить координаты, строить маршруты или анализировать границы районов, ее базовых возможностей уже не хватает. Здесь на помощь приходит PostGIS. Под катом разберемся, что умеет расширение и как его использовать.
Гаджеты становятся всё меньше, а вот требования к памяти только растут. Смартфоны, консоли, ноутбуки, дроны и даже AR-гарнитуры нуждаются в хранилищах, которые одновременно компактные и быстрые. Китайская компания Biwin представила новый формат — Mini SSD. Он чуть больше microSD-карты, но по скорости близок к настольным NVMe-дискам. Идея быстро привлекла внимание: быстрый накопитель в формате, похожем на SIM-карту, звучит как настоящий прорыв. Попробуем разобраться, что это за технология, как она устроена и есть ли у неё шанс стать новым стандартом.
В этой статье — история о том, как мы вместе с командой Аналитики цифровых продуктов работали над одной небольшой фичей и в процессе создали собственную альтернативу известной платформе для сбора статистики пользователей сайтов.
Пару слов о нашей команде и о том, чем мы занимаемся. У нас 6 инженеров данных и 5 аналитиков — вместе мы помогаем продуктовым командам (тем, кто развивает сайты и приложения) создавать дашборды и отчёты. Они нужны для того, чтобы коллеги видели, как их изменения влияют на бизнес-метрики и поведение пользователей.
Вторая часть нашей работы — поддержка маркетологов. Мы помогаем им анализировать эффективность продвижения Спортмастера и других наших брендов: где увеличивать бюджеты, где сокращать и как быстро оценивать результат. В общем, мы те, кто превращает данные в понятные решения.
Как появилась задача
Наши пользователи — маркетологи — каждую неделю сталкивались с одной проблемой. По вторникам у них проходят планёрки с руководством, где они разбирают результаты прошлой недели: что сработало, что можно улучшить. Им критично важно к этому времени уже иметь готовый отчёт, чтобы успеть проанализировать данные и принять решения по рекламе.
Однако наш продукт выдавал отчёты только к 16:00. Кому-то хватает часа на подготовку, кому-то трёх, но пользователи жаловались: они просто не успевают осмыслить данные и сформулировать выводы.
Коллеги обратились к нам с запросом: перенести формирование отчетов на 12:00, чтобы оставалось больше времени на анализ. И мы стали думать, как это сделать своими силами без увеличения команды.
В организациях зачастую можно наблюдать картину, когда разные отделы используют разные системы создания и ведения документации. Это ведет к нескольким проблемам:
• Отсутствие контроля структуры и содержания документа.
• Проблема совместимости файлов и форматов.
• Отсутствие единого хранилища и версионированию.
• Замедление согласования из‑за отсутствия интеграции с системами электронного — документооборота.
• Дублирование документов.
• Сложность с отчетностью и аудиторскими проверками — документы, в т.ч. архивные, не хранятся централизованно.
• Дополнительные затраты для обучения персонала и поддержке нескольких систем.
Как можно решить всю совокупность этих проблем? Лучшим вариантом является гибкая система документооборота с возможностью согласования документов прямо в системе, единым хранилищем документов (в том числе архивных) и возможностью отслеживания версий документов, которая может быть использована во всех отделах компании, чтобы не увеличивать количество используемых инструментов и затраты на поддержку систем в компании. И на рынке есть система, удовлетворяющая всем этим запросам — это Сфера.Документы.
Рассмотрим конкретный бизнес‑сценарий, когда административно‑хозяйственному отделу (АХО) нужно закупить мелкое оборудование для ремонта офиса.
Рынок SSD-накопителей прямо сейчас переживает непростое время. С одной стороны, далеко не все еще поняли, есть ли смысл переходить с PCIe 4.0 на PCIe 5.0. А с другой, производители уже демонстрируют твердотельники следующего поколения с еще более высокой пропускной способностью. Получается парадокс: технология развивается быстрее, чем у массового потребителя появляется реальная потребность в ней. Но это не значит, что PCIe 6.0 не нужна никому. Напротив, очень даже нужна.
Ещё лет десять назад мало кого интересовали дата-центры — они воспринимались скорее как техническая «кухня» цифровой экосистемы. Но ситуация в корне изменилась. ЦОДы стали горячей темой для всей мировой экономики. Они влияют на IT-ландшафт, сырьевой рынок, энергетику и даже на геополитику. Подробнее об этом читайте далее.
Я Евгений Прочан, в платформенной команде Magnit OMNI развиваю инфраструктуру DWH. Расскажу здесь, почему нам понадобилось перейти от батчинга к CDC и как мы это делали. Причин перехода было две: потребность бизнеса в расширении возможностей инфраструктуры и нестабильность нашего старого процесса репликации.
Мы используем в основном базы данных PostgreSQL. Оттуда пакетами раз в час передаём данные в S3, ClickHouse и таблицы Iceberg. Наша потоковая нагрузка достигает примерно полутора терабайта данных, 6000 операций в секунду (около 1500 в самой нагруженной базе данных).
Реализация системы с микросервисной архитектурой редко обходится без классического разруливающего REST-гейтвея. Но когда ваша система растёт годами, а в гейтвее плодятся сотни ручек с просачивающейся бизнес-логикой, можно внезапно обнаружить, что ваш REST-гейтвей стал монолитом со всеми вытекающими последствиями.
Мы в Авто.ру шли к этому состоянию гейтвея довольно долго. История его началась в 2015 году: десятки разработчиков, сотни ручек, почти 300 000 строк кода — и релизы, которые можно катить неделю. Чтобы спасти наш стремительно деградирующий time-to-market и вернуть разработке гибкость, мы решили попробовать GraphQL-федерацию. Спойлер: кажется, получилось.
Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру, и в этой статье я расскажу, как мы перешли от REST к федерации GraphQL: зачем нам это понадобилось, с какими подводными камнями мы столкнулись, как выглядели первые миграции трафика, к чему всё это привело на данный момент в цифрах и инфраструктуре.
Данные не ломаются сами по себе — их ломают люди. Уборщица шваброй, приложение, написанное «на отвали», админ в пятничной прострации. Причины разные — результат один: файлов нет, виноватого тоже.
Чтобы не восстанавливать инфраструктуру с нуля по скриншотам из Notion, в АЭРОДИСК ENGINE есть файловая репликация. Это не бэкап, это реальное дублирование файлов между хранилищами, которое спасает, когда кто-то опять «просто немного пофиксил в проде».
Без костылей, без CLI-гимнастики, без надежды на авось. Настроили — и пусть хоть полсервера ляжет, данные у вас уже есть в другом месте.
Разбираемся, как оно устроено, чтобы потом не было «ой, не знал».
