Визуализация данных как язык XXI века: от аналитики к сторителлингу

Сергей Тищенко, аналитик студии визуализации данных AkademiaDev , рассказывает, как данные перестали быть сугубо аналитическим инструментом и превратились в полноценный язык, на котором сегодня говорят медиа, бизнес, цифровые сервисы и дизайнеры: от доступного визуального сторителлинга в Flourish и Datawrapper до повседневной работы с данными в Superset, Metabase, Power BI и DataLens. Почему данные давно вышли за пределы таблиц и отчетов, как визуализация помогает превращать сложные массивы информации в понятные истории.

https://habr.com/ru/articles/1039412/

#Визуализация_данных #big_data #дизайн #Интерактивные_дашборды

Визуализация данных как язык XXI века: от аналитики к сторителлингу

Сергей Тищенко, аналитик студии визуализации данных AkademiaDev , рассказывает, как данные перестали быть сугубо аналитическим инструментом и превратились в полноценный язык, на котором сегодня...

Хабр

Мультитенантность в FinOps: Проектируем ядро системы учета расходов

«Кто виноват и что делать?» — эти два вопроса, которые классики русской литературы адресовали обществу, сегодня как никогда актуальны для IT-директоров и финансовых руководителей. Только «виноват» не конкретный человек, а не оптимально работающая инфраструктура, а ответ на вопрос «что делать?» — внедрять FinOps. FinOps — это не технология, а организационная методика. Важная часть инструментария для FinOps это правильно построенная информационная система, которая собирает, хранит и дает анализировать данные о расходах и нагрузке. В этой статье мы разберем архитектурное ядро такой системы.

https://habr.com/ru/companies/inferit/articles/1035562/

#управление_проектами #облачные_вычисления #data_warehouse #системная_архитектура #itинфраструктура #big_data #devops #data_engineering #finops #финопс

Мультитенантность в FinOps: Проектируем ядро системы учета расходов

«Кто виноват и что делать?» — эти два вопроса, которые классики русской литературы адресовали обществу, сегодня как никогда актуальны для ИТ-директоров и финансовых руководителей. Готовы к ответу?...

Хабр

Московский мотоциклист: портрет на больших данных

Весна. На дорогах столицы всё меньше луж и всё больше их - шумных, быстрых, не отражающихся в зеркалах и тех, к кому горожане относятся по-разному. Автор статьи, например, относится к ним непосредственно , а потому в его голове давно зрела идея посмотреть на мотосообщество не через призму стереотипов, а сквозь петабайты больших данных Т2. Астрологи объявляют открытие мотосезона 2026: количество SQL-запросов по теме увеличивается вдвое! Промчаться по ночной столице

https://habr.com/ru/companies/t2/articles/1030044/

#мотоциклисты #Москва #Big_Data #геоаналитика #телеком #DMP #сегментация_аудитории #геолокация #сотовая_связь

Московский мотоциклист: портрет на больших данных

Весна. На дорогах столицы всё меньше луж и всё больше их - шумных, быстрых, не отражающихся в зеркалах и тех, к кому горожане относятся по-разному. Автор статьи, например, относится к ним...

Хабр

Код как документация: как мы строим самодокументируемые витрины данных в Почте Mail

В аналитике больших данных есть старая проблема: код ETL-витрин живет своей жизнью, а документация — своей. Изменяешь логику, забываешь обновить описание колонки — и через месяц никто не помнит, что означает wallet_cards_category_hits. В Почте Mail (VK) мы решили эту проблему системно, разработав внутренний фреймворк, который делает код витрины и ее документацию неразрывными. На связи Дима Швеенков. Я все так же руковожу направлением аналитики в команде и отвечаю за данные в Почте Mail , а теперь еще и отвечаю за DWH в VK Tech . В предыдущих статьях я подробно рассказывал о нашем Data Driven-подходе к работе с данными, а также, в частности, как мы работаем со Spark и какие ключевые проблемы с данными мы решили, чтобы построить свое хранилище данных. Сегодня хотел бы остановиться на более узкой теме — как держать в порядке документацию, если у вас такое же огромное хранилище, как и у нас. Материал короткий, но, надеюсь, будет для вас полезным.

https://habr.com/ru/companies/vktech/articles/1032686/

#big_data #apache_spark #airflow #clickhouse #sql #документация #dwh #metadata #dbt #vk_tech

Код как документация: как мы строим самодокументируемые витрины данных в Почте Mail

В аналитике больших данных есть старая проблема: код ETL-витрин живет своей жизнью, а документация — своей. Изменяешь логику, забываешь обновить описание колонки — и через месяц никто не помнит, что...

Хабр

ClickHouse для больших данных: полный гайд по интеграции с NoSQL‑экосистемой

Когда классические SQL‑базы падают под аналитической нагрузкой, а Hadoop‑кластер напоминает чемодан без ручки — пора искать новое решение. В этой статье разбираем, как ClickHouse в связке с NoSQL‑экосистемой закрывает бреши в высоконагруженных проектах. Разберём архитектурные ловушки, Best Practices и честно оценим, где этот инструмент экономит миллионы, а где может создать проблемы.

https://habr.com/ru/companies/otus/articles/1022158/

#clickhouse #nosql #big_data #аналитика_данных #kafka #olap #архитектура_данных

ClickHouse для больших данных: полный гайд по интеграции с NoSQL‑экосистемой

Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce, преподаю на курсах разработки и архитектуры в OTUS....

Хабр

Avalon: как построить эффективный Feature Store на YDB

В современном развитии рекомендательных систем и алгоритмов принятия решений особое место занимают Feature Store — хранилища признаков, позволяющие быстро и централизованно управлять данными. В городских сервисах Яндекса для таких задач мы создали собственное решение под названием Avalon. Оно служит универсальным каталогом признаков, которым легко пользоваться разработчикам и аналитикам вне зависимости от того, что им нужно хранить — бинарные индикаторы или сложные метрики вроде количества поездок у водителя. Наш Feature Store — Avalon — возник в момент, когда понадобилось масштабируемое и производительное хранилище с низкой задержкой, в котором можно структурировать признаки по иерархии «каталог/файл», получать быстрый доступ к ним из рантайма, автоматически отслеживать актуальность данных и контролировать жизненный цикл каждого признака. Роль СУБД для системы выполняет YDB, что позволяет достичь высокой отказоустойчивости и горизонтального масштабирования. Всем привет! Меня зовут Паша, я руковожу группой разработки технологий эффективности Такси. В этой статье я расскажу, как мы проектировали и строили Avalon, какие вызовы пришлось решать команде по мере роста нагрузок и аудитории, почему прежние подходы перестали соответствовать задачам современного продуктового анализа и как в результате получился удобный и надёжный Feature Store для множества бизнес-сценариев.

https://habr.com/ru/companies/yandex/articles/1032478/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1032478

#ydb #субд #feature_store #архитектура #big_data

Avalon: как построить эффективный Feature Store на YDB

В современном развитии рекомендательных систем и алгоритмов принятия решений особое место занимают Feature Store — хранилища признаков, позволяющие быстро и централизованно управлять данными. В...

Хабр

Avalon: как построить эффективный Feature Store на YDB

В современном развитии рекомендательных систем и алгоритмов принятия решений особое место занимают Feature Store — хранилища признаков, позволяющие быстро и централизованно управлять данными. В городских сервисах Яндекса для таких задач мы создали собственное решение под названием Avalon. Оно служит универсальным каталогом признаков, которым легко пользоваться разработчикам и аналитикам вне зависимости от того, что им нужно хранить — бинарные индикаторы или сложные метрики вроде количества поездок у водителя. Наш Feature Store — Avalon — возник в момент, когда понадобилось масштабируемое и производительное хранилище с низкой задержкой, в котором можно структурировать признаки по иерархии «каталог/файл», получать быстрый доступ к ним из рантайма, автоматически отслеживать актуальность данных и контролировать жизненный цикл каждого признака. Роль СУБД для системы выполняет YDB, что позволяет достичь высокой отказоустойчивости и горизонтального масштабирования. Всем привет! Меня зовут Паша, я руковожу группой разработки технологий эффективности Такси. В этой статье я расскажу, как мы проектировали и строили Avalon, какие вызовы пришлось решать команде по мере роста нагрузок и аудитории, почему прежние подходы перестали соответствовать задачам современного продуктового анализа и как в результате получился удобный и надёжный Feature Store для множества бизнес-сценариев.

https://habr.com/ru/companies/yandex/articles/1032478/

#ydb #субд #feature_store #архитектура #big_data

Avalon: как построить эффективный Feature Store на YDB

В современном развитии рекомендательных систем и алгоритмов принятия решений особое место занимают Feature Store — хранилища признаков, позволяющие быстро и централизованно управлять данными. В...

Хабр

Почему Big Data стек небезопасен по своей природе

Год назад на рандом-кофе мы с коллегой обсуждали так называемую (мной) цифровую экологию и проблемы работы с большими данными, и он мне посоветовал доклад "The Unbelievable Insecurity of the Big Data Stack" с конференции Black Hat USA 2021 - в целом название полностью описывает содержание доклада. И вот только сейчас, спустя год, у меня дошли руки его разобрать и поделиться с вами своими мыслями на этот счёт. За пять лет доклад совершенно не утратил актуальности и, кажется, стал только более насущным. Доклад делала Sheila A. Berta - специалист по offensive security из Аргентины, которая много лет занимается поиском уязвимостей и исследованием инфраструктур. В последние годы она сфокусировалась на безопасности Big Data и cloud-native систем. Это не теоретическая работа, а результат практического ресёрча.

https://habr.com/ru/articles/1030842/

#big_data #data_security #безопасность_данных #архитектура_систем #архитектура_системы_хранения_данных #apache

Почему Big Data стек небезопасен по своей природе

Год назад на рандом-кофе мы с коллегой обсуждали так называемую (мной) цифровую экологию и проблемы работы с большими данными, и он мне посоветовал доклад "The Unbelievable Insecurity of the Big Data...

Хабр

Единое окно инженера данных: как мы построили веб-среду разработки для 12 000 потоков данных

Привет, Хабр! Меня зовут Никита Калганов, я ведущий системный инженер данных в X5 Tech. Мы с командой проектируем и развиваем высоконагруженную систему потоков данных и поддерживаем её в условиях постоянного роста, как по числу потоков, так и по количеству команд, которые с ней работают. В нашей системе обработки данных живёт больше двенадцати тысяч потоков данных, и их число растёт в среднем на несколько десятков в день. Всё нормально работает, но мы решили сделать её ещё лучше. В этой статье расскажу, как мы построили единое окно инженера данных, сделали собственный DDL-мигратор с поддержкой зависимостей и при этом сохранили то, что уже работает.

https://habr.com/ru/companies/X5Tech/articles/1026382/

#большие_данные #big_data #lakehouseплатформа_данных #data_pipelines #airflow #yaml #gitlab_cicd #микросервисная_архитектура #оркестрация #ddl

Единое окно инженера данных: как мы построили веб-среду разработки для 12 000 потоков данных

Привет, Хабр! Меня зовут Никита Калганов, я ведущий системный инженер данных в X5 Tech. Мы с командой проектируем и развиваем высоконагруженную систему потоков данных и поддерживаем её в условиях...

Хабр

ELT против ETL в FinOps: Почему мы сначала кладем сырые данные, а потом думаем

«Фарш невозможно прокрутить назад» — этой поговоркой инженеры данных могли бы объяснить, как работает классический ETL. Ошибка может случиться на любом этапе: не тот коэффициент применили, не ту валюту подставили, забыли про скидку. Но после того как исходные данные трансформированы и отчет сформирован, но иногда бывают такие ситуации, когда вернуться к первоисточнику по какой-то причину уже нельзя. В FinOps эта ситуация — не метафора, а суровая реальность. Данные от облачных провайдеров доступны лишь в ограниченном окне (30–90 дней), а иногда и меньше. Если вы сначала обработали их, а потом поняли, что ошиблись, может так случиться, что перезапросить исходники уже не получится. В этой статье мы разберем два подхода к построению процессов обработки и преобразования данных — ETL и ELT — и докажем, почему для FinOps выбор ELT — это не просто вопрос производительности, а вопрос выживания исторических данных.

https://habr.com/ru/companies/inferit/articles/1025790/

#облачные_вычисления #finops #финопс #data_engineering #data_warehouse #itинфраструктура #big_data #управление_проектами #системная_архитектура #devops

ELT против ETL в FinOps: Почему мы сначала кладем сырые данные, а потом думаем

«Фарш невозможно прокрутить назад» — этой поговоркой инженеры данных могли бы объяснить, как работает классический ETL. Ошибка может случиться на любом этапе: не тот коэффициент применили, не ту...

Хабр