16 500 отзывов в одном рабочем контуре, 9 500 записей в собственном хранилище, четыре XML‑фида, 4 000 строк кода и 130+ страниц документации. Все это работает за 8 500 в месяц.
Задача была очень простая: сделать так, чтобы отзывы гостей ресторанной сети перестали жить в десятке вкладок, кабинетов, выгрузок и ручных таблиц. На первый взгляд — обычная автоматизация. Забрать данные, сложить в одно место, показать человеку. Но мы не ищем легких путей)
Все началось с просьбы сделать отчеты в реальном времени. На первый взгляд задача выглядела простой, но довольно быстро выяснилось, что существующая архитектура для этого не подходит.
Проект был разбит на множество микросервисов, каждый из которых хранил данные в собственной PostgreSQL-базе. Чтобы строить сквозные отчеты, информацию нужно было где-то объединять.
В условиях глобальной неопределенности финансовое планирование и бюджетирование перестает быть ритуалом подготовки отчетов – сегодня это живой процесс, который определяет жизнеспособность компании, развивая базовые подходы в комплексную систему интегрированного планирования.
Бюджетирование – очень важная, интересная и нетривиальная задача, которую в современном мире принято решать при помощи автоматизации. Если еще 5 лет назад в системе бюджетирования видели инструмент консолидации и план-факт анализа, то сегодня это комплексная высокотехнологична модель бизнеса.
Привет! Меня зовут Черняховский Денис, и я Data Engineer. Я достаточно продолжительное время работаю с данными и увлекаюсь математической статистикой. Совсем недавно решил поискать в интернете, как другие опытные дата-инженеры исследуют качество данных при помощи статистики, и обнаружил, что никак… пум-пум-пум. А далее обнаружил, что проблема уходит корнями гораздо глубже, чем может показаться.
В этой статье я постараюсь рассказать:
почему дата-инженерам необходимо использовать статистику и почему её не используют
проведём тесты на реальных примерах данных
На днях мне прилетела задача, в которой нужно было вычерпывать данные по HTTP с такими вводными:
Есть ограничение по количеству запросов в минуту
Объём данных - миллионы записей
Один запрос выполняется долго (возвращает много данных)
Нужен асинхронный механизм выгрузки
Не включая мозг, я начал накидывать решение...
Грабли №1: async, который работает синхронно
async def fetch_all_pages():
...
while True:
response = await fetch( # ← ошибка
f"/resource?page={page}"
)
...
page += 1
...Формально:
async
await
Фактически:
один запрос за разЧитать полностью »
Привет!
Потоки данных между системами стабильно увеличиваются, и в обозримом будущем эта тенденция вряд ли изменится, что создает постоянную потребность в инструментах для работы с данными.
Apache NiFi — программный продукт с открытым исходным кодом, написанный на языке Java, предназначенный для автоматизации потоков данных между системами. Главная его задача: организовывать ETL‑процессы. На GitHub у Apache NiFi имеется 5.9 тысяч звезд.
Для тех, кто не знает, что такое Apache NiFi советую прочитать отличную статью.
В этой статье мы поговорим о том, как реализовать поведение атомарной вставки в ClickHouse. Рассмотрим несколько вариантов, подсветим их сильные и слабые стороны, а также, когда каждый из них применять.
Задача
Мы хотим добиться, чтобы не было случаев, когда мы начали вставку, а пользователь прочитал данные до её завершения и получил неактуальный (неполный) набор данных.
Неатомарная вставка = риск чтения некорректного набора данных.
Сценарии, когда такое может произойти:
Удалили партицию и хотели начать вставлять данные взамен удалённой, но пользователь обратился к этому интервалу.
Привет, Habr!
Ятимлид достаточно молодой команды разработки и недавно столкнулась с недопониманием у ребят различий между процессами загрузки данных ETL и ELT. Решила разобрать разницу в одной статье, попробовать объяснить где и почему нужно использовать ETL и зачем понадобился ELT. Также в статье попробую ответить на вопрос — какой подход выбрать.
И это моя первая статья на Habr, буду рада поддержке.
В русскоязычной части интернета присутствует много статей по теме паттернов разработки, однако я не нашел никакой информации о паттернах работы с данными.
В данной статье я хочу рассказать о паттерне Write-Audit-Publish, о предпосылках его появления, а также наглядно рассмотреть как он работает.
С момента появления концепции data lake, компании старались собирать как можно данных, иногда не слишком задумываясь об их качестве. Появилось четкое понимание, что данные "когда-нибудь" могут быть использованы. Так, согласно исследованиям market.usЧитать полностью »