#dwh — Public Fediverse posts

AI-хакатон в GlowByte: как мы решали задачи для вымышленной розничной сети «МегаБайт»

Всем привет! На связи команда BI-практики GlowByte. У нас прошел внутренний хакатон AI Seasons. Он вдохнул жизнь в корпоративное обучение и дал участникам ощутимую бизнес-ценность. Хочу поделиться этим опытом и подкинуть вам идею для масштабирования истории у себя. Ниже расскажу подробно, а пока вкратце опишу основную идею, как это реализовали у нас в GlowByte. Итак, мы взяли вымышленную розничную сеть «МегаБайт» с сотнями магазинов и миллионами заказов. Поставили перед командами задачу реализовать DWH/BI-кейс, решать задачки нужно было с помощью ИИ. На старте участвовали 28 команд, до финиша добрались три: было по-спортивному напряжённо, горячо и энергично, так что не все смогли потянуть битву в таком темпе. Под катом я расскажу: ● как устроен наш хакатон; ● как оценивались задания; ● какие ошибки мы допустили; ● что было ценного и что мы уже забираем в текущие рабочие процессы. Будет здорово, если вам зайдет тема и организуете подобный «боевик» для специалистов у себя. Потом обязательно поделитесь в комментариях!

https://habr.com/ru/companies/glowbyte/articles/1068752/

#хакатон #AIхакатон #корпоративное_обучение #DWH #BI #аналитика_данных #aiагенты #вайбкодинг #GenBI #ии

FlatAdapter для преобразования иерархических структур

Превращаем иерархические структуры в набор плоских строк готовых для импорта в БД flat-adapter преобразует нетипизированные вложенные mapping в детерминированный список плоских строк. Библиотека умеет приводить scalar-типы, обрабатывать optional-поля, извлекать значения по путям, разворачивать вложенные FlatAdapter-ы и строить декартово произведение списков.

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

#etl #airflow #python #backend #data_compose #data_mining #dwh

Как мы описали 15 000 таблиц за полгода вместо 500 за год — и перестали писать документацию руками

Годы идут, но что‑то остаётся неизменным: писать документацию никто не любит, но тем не менее все почему‑то ругают тех, кто её не пишет. В Яндексе одних только таблиц с данными — десятки миллионов, общим объёмом в экзабайты данных. Даже когда мы оставляем из всего этого количества только самое востребованное, остаётся несколько десятков тысяч таблиц, которые кто‑то должен описать словами: что внутри, откуда взялось, можно ли этому доверять. Без таких описаний аналитик не находит данные через поиск, не понимает, что лежит в таблице, и заново собирает то, что уже собрал коллега. И страдает не только человек: ИИ‑агенты, которые всё чаще сами решают аналитические задачи, на неописанных данных также теряют в качестве — чем меньше известно про таблицу, тем хуже результат. Год мы уговаривали людей описывать таблицы вручную — и собрали описания всего на 500 таблиц из 40 тысяч. Если описывать все данные с такой скоростью (при учёте, что постоянно появляются новые) — страшно представить, на сколько десятков лет мог бы растянуться этот процесс. Меня зовут Роман Гриднев, я технический менеджер в Яндексе. Расскажу, как мы научились не писать документацию. «Не писать‑то все могут», — скажете вы. Но мы подключили к задаче LLM и дали людям вместо чистого листа черновик: пусть с ошибками, зато не пустую страницу, которая пугает. За полгода мы так описали 15 тысяч таблиц и сэкономили около пяти лет рабочего времени аналитиков. Со временем качество черновиков от LLM доросло до почти полного соответствия описаниям, сделанным людьми.

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

#dwh #документация #аналитика_данных #сырые_данные

DE. Путь файла по слоям

В исходном orders.csv было 11 строк. До BI-витрины дошло 7, а валовая сумма 4720.30 после применения бизнес-правил превратилась в 2200.30 выручки. Четыре строки не исчезли: каждая попала в rejects с конкретной причиной. На этом небольшом примере покажу весь путь данных через RAW, STG, CORE и MARTS. Разберём, где меняются строки и суммы, как пережить повторную доставку файла и какие проверки позволяют доверять итоговому дашборду. Внутри MinIO, Postgres и Airflow.

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

#Data_Engineering #ETL #DWH #пайплайн_данных #Apache_Airflow #PostgreSQL #MinIO #Data_Quality #CSV #BI

Оптимизация MPP-кластера: предсказываем потребление памяти SQL-запросов

В аналитике больших данных системы массивных параллельных вычислений часто находятся под постоянной нагрузкой в режиме 24/7. Из десятков и сотен тысяч запросов в день многие исполняются одновременно и конкурируют за ограниченные ресурсы вычислительного кластера. Чем рациональнее каждый отдельный запрос их использует, тем больше запросов система сможет обслуживать параллельно. Соответственно, выше пропускная способность за конкретный отрезок времени. Как правило, проблема нехватки ресурсов остро ощущается в пиковые часы нагрузки. Можно бесконечно до совершенства настраивать и править параметры сессии на каждый запрос индивидуально вручную, но нам — команде разработки платформы данных Data Ocean Nova — всегда хочется иметь более системный подход. В сегодняшней публикации мы расскажем о том, как реализовали идею автоматической системы предсказания потребления ресурсов SQL-запросами для Impala и StarRocks, основанную на ML-принципах, и сделали её частью платформы данных.

https://habr.com/ru/companies/datasapience/articles/1061866/

#mpp #impala #starrocks #bigdata #dwh #lakehouse #ml #olap

SSB — «мы стояли на „плоскости“»

SSB — «мы стояли на „плоскости“» Предлагаемый текст представляет опыт ознакомления автора с тестом SSB в свете обычных прикладных вопросов BI‑проекта умеренного размаха. Автор пытается бросить пытливый взгляд на спектр перспективных возможностей, обеспечиваемых доступностью и масштабируемостью теста SSB.

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

#SSB #Postgres #ClickHouse #Sizing #MDX #Flat #Star #BI #DWH #КХД

Ускоряем федеративные запросы в StarRocks

Когда речь заходит про Lakehouse и федеративный доступ , многие вспоминают про Trino и… часто на этом все. Но федеративные запросы поддерживаются в том или ином виде довольно большим количеством СУБД, SQL-движков и систем для виртуализации данных. В этой статье постараемся немного расширить кругозор читателей, которым интересна данная тема: рассмотрим федеративные запросы на примере набирающего популярность и активно развивающегося StarRocks . Из статьи вы узнаете: что такое федеративные запросы, как обстоят дела с реализацией гетерогенного федеративного доступа в этой СУБД и какие изменения команда решения Data Ocean Nova реализовала для оптимизации в StarRocks и Impala с целью улучшения функционала доступа к внешним данным.

https://habr.com/ru/companies/datasapience/articles/1057930/

#starrocks #федеративные_системы #lakehouse #datalakehouse #dwh #mpp #jdbc #greenplum #trino

Дашборд красиво врал. Как я с ИИ разобрала данные и пересобрала отчет без очереди к аналитикам

Очередная задача, очередной управленческий дашборд. Не учебный, не демонстрационный, а вполне рабочий: воронка продаж, подписанные заказы, оплаты, акты, плановые часы, загрузка команд, распределение лидов по продуктам и менеджерам. То есть всё то, что руководитель обычно хочет видеть утром, когда открывает ноутбук и пытается понять: где у нас деньги, где зависли сделки, кто перегружен, что уже подписано, что оплачено, а что красиво лежит в планах, но пока не стало реальностью. На первый взгляд всё выглядело прилично. Карточки считались. Графики строились. Таблицы открывались. Цвета были на месте. Но довольно быстро появилось неприятное ощущение: цифры слишком хорошие. Pipeline рос бодро. Суммы выглядели уверенно. Воронка казалась наполненной. Только внутренне я понимала, что бизнес не мог вырасти ровно настолько, насколько вырос график. И вот это, пожалуй, самый неприятный момент в работе с дашбордами. Когда отчет не падает с ошибкой, не показывает пустой экран, не ругается красным текстом, а просто тихо и убедительно врет.

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

#как_собрать_дашборд_с_ИИ #ИИ_для_руководителя #управленческий_дашборд #ai_для_бизнеса #автоматизация_отчетности #воронка_продаж #бизнесметрики #DWH #BI #Business_Intelligence

TPC-DS в 07.2026. Lakehouse: Spark, Trino, StarRocks, Impala и Doris. GreenPlum & Cloudberry vs StarRocks как MPP

Привет, Хабр! На связи команда Data Sapience. С последней публикации результатов тестирования MPP-движков прошло уже несколько месяцев. За этот период произошел ряд изменений в базовых версиях open source движков и фреймворков, а также наша команда разработки внесла ряд улучшений и доработок. Все это может повлиять расстановку сил в рейтинге. В сегодняшней публикации мы представим максимальное число претендентов, среди которых: Spark 3.5.*, Spark 3.5.* + DataFusion Comet, Spark 4.0.1, Spark 4.0.1 + DataFusion Comet, StarRocks (core based 3.5+, 4.0+), Impala (core based 4.5), Trino (459, 476, 479) и новичок нашего рейтинга — Apache Doris. Статья поможет вам ответить на вопросы: стоит ли переходить на Spark 4 в поисках производительности; Как нативные вычисления влияют на результаты Spark; Как улучшилась производительность Trino за последние полгода; нужно ли присмотреться к Apache Doris, если вы ищете альтернативу Impala и StarRocks, и как эти проекты связаны между собой; какие оптимизационные улучшения были добавлены нами в StarRocks и Impala за последнее время. И на десерт мы покажем вам сравнение Greenplum, Cloudberry и StarRocks в режиме Shared-Nothing MPP.

https://habr.com/ru/companies/datasapience/articles/1054316/

#starrocks #trino #spark #impala #greenplum #bigdata #dwh #lakehouse #olap

Apache Paimon: steamhouse как логическое продолжение современных КХД

Apache Paimon: стриминговый lakehouse для дата-инженеров Сколько систем вы держите ради того, чтобы аналитики видели события через секунды, а годовые отчёты собирались без прогрузки всех данных целиком? Kafka, Flink, S3/HDFS, ClickHouse и бесконечная синхронизация состояния между ними. Apache Paimon стирает границу между стримингом и батчем: одна таблица на LSM-tree отдаёт свежие данные за секунды и одновременно служит источником для тяжёлой аналитики. Разбираем архитектуру, честные бенчмарки против Iceberg, Delta Lake и Hudi - где Paimon выигрывает, а где проигрывает - и проходим путь от первой таблицы до CDC-пайплайна в проде на рабочем коде.

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

#paimon #flink #java #streamhouse #dwh #streaming #batch #lakehouse #datalakehouse #datalake

Теория и практика DWH: что такое согласованные факты и измерения по Кимбаллу и зачем они нужны

Небольшой обзор идей согласованности в DWH на основе книг Кимбалла. В статье - краткий разбор некоторых принципов моделирования данных простыми словами. - Кто такой Кимбалл и каков его подход - Факты и измерения - Согласованные факты - Согласованные измерения - SVOT, или single version of truth

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

#Кимбалл #kimball #dwh #svot #факты #измерения #согласование

У абонента положительный баланс, а услуга не работает: как DWH помог найти причину

Личный кейс из телекома: как мы сопоставляли биллинг, 1С, адреса, услуги и партнерскую платформу, чтобы найти, где нарушается синхронизация. Когда говорят про DWH, чаще всего обсуждают управленческую отчетность, BI-дашборды, витрины данных и красивые графики для руководителей. Но моя боль была в другом, и сейчас я знаю, что ценность DWH неизмеримо больше: он помогает не просто смотреть на бизнес сверху, а находить конкретные операционные ошибки, которые годами живут внутри сложной ИТ-инфраструктуры.

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

#dwh #biаналитика #телеком #sql #продуктовая_аналитика #управление_по_данным #биллинг #интеграции

Контракты данных между командами: гайд по data contracts в дата‑пайплайнах

Когда пайплайн отработал без ошибок, тесты зелёные, а в дашборде внезапно нули, проблема может быть не в инфраструктуре, а в отсутствии договорённостей между командами. В статье разбираем, как data contracts помогают фиксировать структуру, правила и ответственность за данные — и почему это спасает витрины, отчёты и нервы дата-инженеров.

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

#контракты_данных #data_contracts #датапайплайны #DWH #Data_Lake #Data_Engineering #dbt #Kafka #Schema_Registry #качество_данных

Сколько телефонов и планшетов продали партнёры: единое хранилище данных для бренда электроники

На связи Анна Астахова, коммерческий директор ИТ-интегратора «Белый код». В компаниях с развитой сетью партнеров топ-менеджерам нужны оперативные данные. А отчеты в Excel тормозят работу. Сегодня рассказываю, как можно организовать и настроить единое хранилище данных на примере компании с широкой партнёрской сетью в сфере электроники.

https://habr.com/ru/companies/w_code/articles/1037632/

#dwh #mdm #1с #хранилище_данных #аналитика_продаж #интеграция_данных #автоматизация_отчетности

Что такое DWH (КХД) и как работает корпоративное хранилище данных

Собрали для вас подробный материал про DWH — корпоративное хранилище данных: — что это такое и как работает КХД - простыми словами — когда DWH действительно нужно и какие задачи решает — как устроена архитектура DWH (LSA, A16Z, подходы к проектированию) — как данные проходят путь от источников до дашбордов — какие сложности чаще всего могут возникнуть при внедрении Этот разбор DWH — от базовых понятий до архитектуры и стека — даст вам целостное понимание и поможет ответить на основные вопросы о хранилищах данных.

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

#dwh #data_warehouse #бизнесанализ #корпоративное_хранилище_данных #bi

DWH в 2026: четыре зоны вместо Inmon, Kimball и Data Vault 2.0

Когда инженер слышит «нам нужно хранилище данных», задача редко звучит однозначно. Кто-то задыхается на боевой OLTP-базе под аналитической нагрузкой. Кто-то впервые строит BI и не понимает, с какого края подходить. У кого-то накопились данные из десятка систем-источников, и существующих средств уже не хватает. У всех «хранилище». А правильный технический ответ зависит от условий задачи. За годы работы в банках, ритейле и системной интеграции мы пришли к простой картине: для среднего и крупного бизнеса большинство DWH-проектов сводится к четырёхзонной архитектуре поверх двух специализированных движков. Не Inmon, не Kimball-star-schema, не Data Vault 2.0 - и при этом не «modern data stack как у Databricks один-в-один». В этой статье разберу архитектуру по зонам, потом честно скажу что осталось живо от классических методологий и где они продолжают работать, а где безнадёжно отстали от колоночной эры. И в конце - типичные ошибки, которые наблюдаем в проектах коллег и собственных пилотах.

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

#dwh #data_warehouse #clickhouse #apache_iceberg #trino #lakehouse #data_engineering #архитектура_данных #data_vault #dba

Код как документация: как мы строим самодокументируемые витрины данных в Почте 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

Нагрузочное тестирование динамического маскирования в Apache Ranger: что происходит с производительностью запросов

Привет, Хабр! На связи Илья Амосов из команды поддержки Lakehouse-платформы данных Data Ocean Nova вендора Data Sapience. В сегодняшней публикации я раскрою тему влияния динамического сокрытия чувствительных данных на производительность SQL-запросов. Мы сравним различные методики маскирования, узнаем, как работает оптимизатор и движок со скрытыми полями, происходит ли деградация пропускной способности платформы, как влияет на производительность выбранный метод сокрытия чувствительных данных в случаях, если вы используете компонент на базе Apache Ranger.

https://habr.com/ru/companies/datasapience/articles/1033038/

#mpp #lakehouse #datalakehouse #dwh #bigdata #ranger

Миграция с Greenplum. Эпизод I: Атака клонов и спасение на звёздных камнях

В мае 2024 года Broadcom заархивировал публичный репозиторий Greenplum: последний коммит остался на месте, дальнейшая разработка ушла в закрытый репозиторий, enterprise-сборка теперь доступна только по подписке. Greenplum как живой OSS-проект остановился — но сам код, выпускавшийся с октября 2015-го, остался под Apache 2.0. Именно на этой кодовой базе стартанули остальные форки. Те, кто строил аналитику на Greenplum, оказались перед развилкой. Сообщество разделилось: Apache Cloudberry (incubating) , Greengage DB от Arenadata, WarehousePG от EDB. Каждый форк продолжает линию, но в собственной траектории. У компании с боевым кластером появляется конкретный вопрос: переехать/остаться в одном из этих форков или мигрировать на принципиально другую платформу и архитектурную парадигму. Эта статья (сага из трёх эпизодов) будет полезна, если у вас уже есть Greenplum-кластер, вы понимаете его DDL/ETL/backup-процессы и хотите оценить, насколько болезненным будет переход на StarRocks.

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

#starrocks #Lakehouse #greenplum #sql #миграция_данных #субд #mpp #dwh #olap #etl

StarRocks вместо Oracle на смешанной аналитической нагрузке. Проверяем на практике

Привет, Хабр! Меня зовут Денис Пашков, я – ведущий архитектор данных в группе компаний GlowByte. В этой публикации я бы хотел поделиться опытом работы с MPP-решением StarRocks, набирающим популярность на российском рынке. Все, кто интересуется данной темой, уже, наверное, не сомневаются, что StarRocks очень хорошо себя показывает в аналитической нагрузке. Мои коллеги из Data Sapience регулярно делятся результатами нагрузочных испытаний платформы данных Data Ocean Nova (ознакомиться можно: 1 , 2 и 3 ). Сегодня же речь пойдет о неочевидном сценарии использования – OLTP-нагрузке.

https://habr.com/ru/companies/datasapience/articles/1029814/

#dwh #bigdata #datalake #datalakehouse #lakehouse #starrocks

DataCopilot: строим мультиагентную архитектуру для работы с корпоративным хранилищем данных и документацией

Привет, Хабр! Меня зовут Максим Шакуров, я ML-инженер в VK. Сегодня индустрия активно внедряет LLM для оптимизации рабочих процессов. Наша команда решила идти не от самой технологии, а от реальных потребностей. Чтобы найти процессы с наибольшим потенциалом для автоматизации, мы начали с аудита текущей рутины: проанализировали, с какими запросами аналитики и менеджеры приходят в чаты поддержки к инженерам Data Office (специалистам, отвечающим за сбор, хранение и миграцию корпоративных данных) и к разработчикам нашей платформы данных (команде, которая поддерживает и дорабатывает DWH). Затем сформировали образ нашей будущей системы: она помогает ориентироваться в каталоге витрин, может рассказать, что и где хранится, помогает заполнить заявку на доступы, отвечает на вопросы по специфической документации и пишет скрипты, которые люди могут сразу забрать к себе в ETL-процессы. Под катом рассказали о том, что из этого вышло. Почему рой, а не RAG

https://habr.com/ru/companies/vk/articles/1029088/

#llm #dwh #мультиагентные_системы #rag #swarm #langgraph

Как мы строили MVP data lineage системы в ЮMoney

Привет, меня зовут Юля, я дата-инженер в департаменте аналитических решений ЮMoney. Мы разрабатываем и поддерживаем ETL(ELT)-процессы загрузки данных для BI-продуктов компании: отчётов, дашбордов, витрин, API и других. В этой статье поделюсь, как мы разрабатывали MVP для построения data lineage системы и к каким выводам пришли, — так вы сможете адаптировать подход под свои процессы. Проблема, которая привела нас к разработке MVP, заключается в том, что в начале работы над большинством задач требуется подготовительная аналитика: восстановить путь происхождения данных, чтобы понимать, какие ETL(ELT)-процессы будут затронуты и на что повлияют изменения. Это увеличивает время выполнения задачи. Но, что ещё существеннее, процесс достаточно рутинный: каждый раз необходимо проводить статический анализ кода и изучать документацию (при её наличии). Мы решили автоматизировать эту работу, чтобы иметь под рукой инструмент для построения пути данных по точкам их обработки и применения, — то есть создать data lineage систему.

https://habr.com/ru/companies/yoomoney/articles/1027068/

#data_lineage #etl #elt #dwh #neo4j #kafka #cypher #data_governance #mvp #метаданные

Как мы объединили учётную систему, low-code, Big-Data и мобильное приложение для управления сотрудниками фармкомпании

Привет, Хабр! Представьте, что у вас несколько сотен сотрудников, которые распределены по всей стране. Каждый работает на своём «треке» — районе города или целом регионе, постоянно находится в разъездах и иногда даже без мобильной связи. При этом вам нужно не только координировать их, но и почти в реальном времени анализировать данные, в которых отражается результат их работы. Добавьте к этому необходимость соблюдения трудового законодательства, своевременный и очень внимательный выпуск организационно-распорядительных документов, внешние источники информации, базы данных аналитических агентств и жёсткую связь между ответственностью и анализом план/факт на основе разнородных данных… Мы — Иван Колесников , директор по цифровой трансформации в Группе компаний «Промомед», и Анастасия Чернова, директор по корпоративной аналитике — в этой статье расскажем, как мы обрабатываем эту сборную солянку из метаданных и на их основе определяем загрузку сотрудников на местах, анализируем продажи и долю присутствия компании на рынке. А ещё разберём, как мы собрали для этого гибкую систему-«пазл» из разных инструментов и почему в её центре low-code-платформа и DWH.

https://habr.com/ru/specials/1025514/

#анализ_данных #администрирование #lowcode #dwh #bi #персонал #бизнесприложения

Иллюзия точности метрик: о чем не принято говорить в «высоком обществе» BI-аналитиков

Как только вы уходите от сырых транзакционных данных к предагрегированным витринам, ваша BI-система начинает врать. И чем сложнее бизнес-логика и больше сложных показателей, тем сильнее искажения. Давайте разберем механику этой проблемы на фундаментальном уровне. Почему системы, в которые инвестированы миллионы, показывают фейк?

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

#BI #DWH #OLAP #DAX #MDX #архитектура_данных #rapeed #аналитика_данных #clickhouse #superset

Терабайты данных из Teradata в Trino — эффективный способ передачи

Архитектурный принцип Lakehouse предполагает, что вы оперируете всеми данными, загруженными в систему. Но иногда нужно выполнить ad hoc анализ за ее периметром, потому что необходимых данных по каким-либо причинам нет в Lakehouse-платформе . В этом случае на помощь приходит федеративный доступ. Стандартом для такой задачи является движок Trino. Он умеет извлекать данные из внешних СУБД и даже в некоторых случаях может делать push-down определенных вычислений на сторону системы-источника. Главное, чтобы под рукой был подходящий connector для нужной СУБД, который умеет эффективно с ней работать. Недавно в состав Data Ocean Nova был добавлен новый Trino Teradata Connector . Он позволяет пользователям «подтягивать» необходимые срезы данных из Teradata в рамках ad hoc запросов и решает задачу эффективной передачи данных: можно передавать терабайты в несколько потоков без существенного увеличения нагрузки на источник. В данной статье разберем: - Как организовать эффективную многопоточную работу с Teradata : где часто допускают ошибки, как должно выглядеть правильное решение; - Какие возможности дает Nova Trino Teradata Connector : многопоточная передача, push-down оптимизации.

https://habr.com/ru/companies/datasapience/articles/1024690/

#trino #teradata #mpp #lakehouse #datalakehouse #dwh #bigdata

[Перевод] Архитектура Apache Iceberg: модель метаданных, на которой всё держится

В этой статье я хотел был разобраться в механике Iceberg. Понимание того, как Iceberg организует свои метаданные, отделяет уровень «я умею создавать таблицы» от уровня «я умею разбираться, почему мои запросы медленные, а объём хранилища разрастается». Это фундамент для всего остального в серии. Если вы разберётесь с четырьмя слоями модели метаданных Iceberg, любая фича (time travel, эволюция схемы, эволюция партиций, компактизация) будет восприниматься интуитивно.

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

#lakehouse #iceberg #dwh #spark

Big Data больше не для гигантов: связка Airflow + ClickHouse вытеснила Airflow + PostgreSQL

Открываю ноутбук. Захожу в метрики своего интернет-магазина. 500 тысяч посетителей в день. Каждый клик — событие. Каждый просмотр товара — строка в логах. Каждое добавление в корзину — ещё одна строка. За месяц — 15 миллионов событий. За год — почти 200 миллионов. Это не Google. Не Amazon. Это обычный средний магазин на ~100 человек. А теперь умножьте это на количество таблиц: пользователи, заказы, платежи, доставки, отзывы, просмотры, лайки, рефералы, купоны, возвраты... Поздравляю. Вы уже работаете с Big Data. В 2026 году это уже не привилегия корпораций, а стандарт ведения цифрового бизнеса. И как следствие этой "гонки вооружений" произошла тектоническая смена ориентиров. Классическая связка Airflow + PostgreSQL, которая ещё вчера считалась золотым стандартом, сегодня стремительно сдает позиции. Её место уверенно занимает дуэт Airflow + ClickHouse — технологический фундамент современной инженерии данных.

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

#clickhouse #postgresql #data_engineer #dwh #airflow #big_data #аналитика #рынок_труда #sql #python

Spark SQL Scripting. Новые возможности для инженеров данных

До недавнего времени для реализации сложной многошаговой логики в экосистеме Apache Spark разработчикам приходилось выходить за рамки декларативного SQL. Оркестрация последовательных вызовов, вычисление промежуточных переменных и ветвление логики требовали привлечения внешних языков программирования, таких как Python (PySpark) или Scala и дополнительных инструментов. Spark SQL Scripting, который стал доступен, начиная с 4-й версии, кардинально меняет этот подход, представляя собой процедурное расширение классического Spark SQL. Теперь разработчики могут писать полноценные многошаговые сценарии непосредственно на уровне SQL-артефактов, внедряя в них управляющую логику. В данной публикации мы, команда вендора Data Sapience , разберем возможности Spark scripting на практике.

https://habr.com/ru/companies/datasapience/articles/1021214/

#spark #datalake #datalakehouse #lakehouse #dwh #script

StarRocks в облаке Selectel. Проверяем, как аналитическая СУБД ведет себя под нагрузкой

Идея развернуть аналитическую базу данных в облаке часто выглядит привлекательно — до того момента, пока администратор не начинает прикидывать реальную нагрузку в продакшене, а бизнес — итоговую стоимость. Именно здесь у многих появляются сомнения, и выбор все чаще смещается в сторону более осязаемых решений — например, выделенной инфраструктуры, где проще заранее оценить пределы производительности и стоимости. Я Антон Стеблянко, архитектор больших данных. В статье расскажу, как совместно с командой из компании «СР-ТЕХ» протестировали

https://habr.com/ru/companies/selectel/articles/1012836/

#starrocks #dwh #selectel #субд #базы_данных #хранение_данных #облако #серверы

asapBI: архитектура ETL процессов – Trino, Spark, Airflow и прочий зоопарк

С вами снова Виталий Виноградов, я занимаюсь созданием asapBI - платформы для моделирования баз данных и ETL. Продолжу цикл по системе. Чего хочется от ETL процесса? Если процесс простой – например, проброс данных из одной таблицы в другую с промежуточным расчетом – то графический мэппинг полей. Таких простых пробросов в работе – 90%, не хочется лазить по SQL-коду. Если же процесс сложный – только тогда уже в бой идет ручной SQL, Python, Java, Scala, R. Если процесс длительный – тогда его лучше выполнять на внешних кластерах Trino, Spark, Impala – как говорится, хранилища отдельно, считалища – отдельно. Еще нужна только одна точка контроля загрузок – не дело, когда мониторинг загрузок раскидан по разным системам. В связи с последними (?) событиями было бы здорово иметь возможность заниматься разработкой в оффлайне – сидишь в палатке без 5G, разрабатываешь модели и тестируешь трансформации и цепочки без доступа к инету, а вечером результат сбрасываешь в систему разработки через wi-fi придорожного кафе. Причем должна быть возможность убрать asapBI и продолжать заниматься разработкой вручную (= медленно и печально) – этим мы предотвращаем вендор лок. Как бы нам это все замиксовать? На текущий момент существует много систем со своими интерфейсами и для моделей данных, ETL–процессов нужно в них создавать объекты. Объектов много, надо не забывать, где что лежит и как завязано. По идее, хорошо бы иметь единый интерфейс, где объекты, рассыпанные по разным системам, связаны между собой. Если убрать этот интерфейс, то модели данных и ETL процессы не рассыплются, все продолжит работу, но настраивать будет уже не так удобно. Единый интерфейс просто объединяет в себе удобную работу с разными инструментами. Именно этот принцип я и реализую в asapBI. «Миксуем… Сегодня мы с тобой миксуем…»

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

#asapBI #data_platform #trino #spark #postgresql #greenplum #sql #data_engineering #dwh #etlпроцессы