В этой статье мы рассмотрим эволюцию стратегий репликации данных, начиная с ручных подходов и заканчивая автоматизированными решениями, использующими современные технологии, такие как Kafka и Debezium. Ниже описан пример примененный в компании Wildberries.
В 2024 году в сфере проектирования и строительства происходит значительный технологический сдвиг в области использования и обработки данных. Если вы считаете, что понимание основ BIM (openBIM и closedBIM) будет достаточно для работы с данными в строительстве в ближайшие годы, то вас вскоре может ждать сюрприз. Вместо свободного доступа к проектным данным, производители CAD-систем, сосредотачиваются на продвижении очередных новых концепций. Устаревающие подходы, такие как BIM (2002 год) и openBIM (2012 год), постепенно уступают место современным технологическим решениям, которые ожидают нас в ближайшем будущем:
Немного лирики, что такое Apache Airflow — это оркестратор (ваших данных), инструмент для создания, планирования и мониторинга рабочих процессов (так называемых DAGs — Directed Acyclic Graphs).
Системы дополненной генерации (RAG) были разработаны для улучшения качества ответа крупной языковой модели (LLM). Когда пользователь отправляет запрос, система RAG извлекает релевантную информацию из векторной базы данных и передает ее в LLM в качестве контекста. Затем LLM использует этот контекст для генерации ответа для пользователя. Этот процесс значительно улучшает качество ответов LLM с меньшим количеством «галлюцинаций».
Сегодня поговорим о T-shape — концепции, которая играет огромную роль для дата-инженеров и профессионалов в работе с данными.
Почему важно быть не только специалистом в своей области, но и понимать, как работают другие направления? Почему T-shape подход лучше узкой специализации или полной универсальности?
Современное производство — это уже давно не просто набор станков и всяких железок в ангарах, теперь это ещё и автоматизации, IT-инфраструктура и много, очень много данных, которые в режиме реального времени стекаются в DWH (Data Warehouse — хранилище данных) из сотен источников.
Эти данные нужно собирать, хранить, обрабатывать и анализировать, чтобы компания могла принимать правильные бизнес-решения. Качество данных (Data Quality, DQ) в таких условиях становится критически важным показателем, от которого зависит рентабельность бизнеса в целом.
Это вторая статья из небольшого цикла, в котором мы разбираем опыт СИБУРа в создании, поддержке и развитии DQ-сервиса. И этот опыт универсален — его можно применять в любой компании, перед которой стоят задачи по обеспечению качества данных.
В первой статье мы рассказывали про импортозамещение DQ-решений после ухода вендора с рынка РФ. В этой статье мы поговорим о задачах, которые решает DQ в целом, и рассмотрим архитектуру решения, которое мы строим в СИБУРе.
Рассказывать об этом опыте будет Александр Бергер, Lead DQ Analyst в СИБУРе, которому посчастливилось лидить процесс создания DQ-сервиса в компании последние несколько лет.
Мы выпустили новый технический каталог для аналитических платформ, который поддерживает спецификацию Iceberg REST API. Рассказываем, зачем это нужно вам и нам
Привет, меня зовут Даниил, я занимаюсь Data Science в Альфа-Банке! Думаю, каждый из нас при разработке модели сталкивается с различными трудностями. Часто нам удаётся наступить на новые грабли, но намного чаще — на старые. Чтобы вам не пришлось наступать на мои, хочу на примере своего проекта, касающегося ценообразования, рассказать, на что стоит обращать внимание при создании моделей, и почему глубокое погружение в бизнес-процесс так важно.
Привет! Меня зовут Мира и я работаю DQE (Data Quality Engineer) в крупной международной компании.
В этой статье я расскажу, как у нас получилось автоматизировать работу аналитиков DQ и разработать продукт, который генерирует тесты автоматически на любой source.
Всё началось с того, что в компании зародилась новая команда, целью которой было построить качественное хранилище данных. Хранилище, которому можно доверять «без угрызения совести». И, конечно же, без DQ здесь не обойтись.
Тема преимуществ открытых табличных форматов при работе с озерами данных всё чаще поднимается в среде дата-инженеров. Предполагается, что их использование способно устранить недостатки популярного Apache Hive. Но так ли это на практике?
Меня зовут Иван Биленко, я инженер данных в команде дата-платформы Циан. В этой статье я хочу немного познакомить вас с процессами и стеком внутри нашей платформы, рассказать, почему мы решили попробовать Iceberg, с какими проблемами столкнулись при тестировании и какие преимущества Iceberg может дать тем, кто еще только задумывается о переходе. Дисклеймер: статья носит обзорный характер.
Привет! Меня зовут Дмитрий Литвиненко, я Data Scientist в компании Prooftech IT. В первой части статьи мы задали довольно обширную базу по событиям, корреляции и причинности. Эта часть статьи более глубоко погружается в причинность и причуды с ней связанные. Что примерно происходит в мозгах людей и мощных системах мониторинга? Как же мы:
- восстанавливаем причинность,
- (не)справляемся с иллюзиями в процессе этого,
- и наконец, находим способы ослабить иллюзии?
Привет, сообщество. Меня зовут Илья, я старший разработчик в БФТ-Холдинге. В этой статье хочу поделиться опытом использования dbt (data build tool) в рамках проекта «Консолидации и нормализации данных» для процессов трансформации данных и создания витрин.
Pandas — это основная библиотека для работы с данными. Вот несколько приёмов, которые я использую, чтобы быстрее и проще выполнять повторяющиеся задачи по работе с данными.
BI (Business Intelligence) – это инструмент или несколько инструментов, которые помогают собрать данные в нужный вид и посмотреть на бизнес со стороны данных.
Чаще всего BI-инструментами пользуются аналитики. Они строят дашборды (витрины), выполняют Ad hoc задачи и в целом проводят анализ данных в этих инструментах.
В этой статье я хотел бы показать куда уходят данные и что с ними происходит, когда пайплайны дата-инженеров заканчивают работу.
В этой статье мы сравним различные бенчмарки, которые помогают ранжировать большие языковые модели для задач разработки программного обеспечения.
Big data is dead. Во всяком случае, так утверждает генеральный директор MotherDuck в статье, перевод которой собрал 140 плюсов на Хабре. Обработку и использование больших данных обсуждали в течение последнего десятилетия, но они потеряли актуальность как драйвер развития компаний. Означает ли это их окончательную смерть?
Есть и другое мнение: концепция не умерла, а эволюционирует. Фокус смещается от количества собираемой информации к ее качеству. Этот сдвиг парадигмы привел к появлению понятия Smart Data — «умных» данных, которые являются продуктом интеллектуальной обработки и эволюции Big Data.
Давайте рассмотрим концепцию Smart Data и выясним, действительно ли Big Data превращаются во что-то более интеллектуальное.
Я сейчас занимаюсь разработкой своего pet-проекта: LMS на базе TG, и подошел к стадии набрасывания первых модели: курсы, лекции и их контент. Всё это вывел для дебага.
Но давайте вернёмся к теме. Раз я занялся моделью предметной области, есть один неочевидный момент, который многие упускают на старте проекта: когда проект только начинается, мало кто задумывается, как в будущем мы будем анализировать данные. Но уверяю вас, желание анализировать данные у вас обязательно появится, причём захочется анализировать больше, чем то, что изначально доступно.
Когда люди впервые сталкиваются с аналитикой, они думают: "Надо добавить событийную аналитику и логировать каждое действие." Но у такого подхода есть два основных минуса...
В статье "Семантический веб: краткий обзор технологий и инструментов" вы найдете доступное объяснение основ семантического веба и его ключевых компонентов. Мы рассмотрим что такое семантический веб, как он помогает сделать данные более доступными и понятными для машинной обработки. В статье обсуждаются технологии, лежащие в его основе: RDF (Resource Description Framework) для моделирования данных, OWL (Web Ontology Language) для создания онтологий, SPARQL — язык запросов для RDF и другие. Кроме того, мы рассмотрим популярные инструменты, такие как Apache Jena, OWLAPI, которые используются для создания и работы с семантическими данными.
Распознавание именованных сущностей (Named Entity Recognition, NER) — это одна из самых востребованных задач в обработке естественного языка (NLP). Чтобы создать качественную модель для NER, требуется тщательно размеченная обучающая выборка, а процесс её создания может занять много времени и ресурсов. В этой статье я расскажу о своём пути разметки данных, начиная с использования Open Source инструментов и переходя к Prodigy, профессиональному инструменту для создания обучающих наборов данных.
Привет Хабр! Это продолжение истории о развитии «Культуры работы с данными». Первая статья была о том, как данный термин вообще появился в России. Итак, у нас есть план продаж идея, как сделать использование аналитики в компании массовым, тем самым увеличив охват и глубину использования аналитических инструментов в компании (и мы все знаем, что это за «аналитический инструмент»), остается проверить эту идею на практике.
Очевидно, что самый простой способ — это узнать у наших текущих заказчиков, у которых уже были достаточно крупные инсталляции, не нужна ли им тысяча — другая лицензий бесплатно? Ну, там, туда — сюда раздать, потестировать... вдруг что‑то да приживется? Кстати, первый, кто сообразил что это «золотая жила», и даже пытался нам самим это рассказать — был Иван Черницын, Начальник управления аналитических решений, технологий больших данных и искусственного интеллекта Дирекции региональных продаж ПАО «Газпром нефть» — большое ему за это Спасибо: он много рассказывал на конференциях про использование Qlik внутри «Газпром нефти», в частности — про работу с большими инсталляциями. Это нам помогло и с другими заказчиками, но больше ни один «нефтяник» на Qlik даже не взглянул, наоборот, видя насколько успешно стало использование данного инструмента и слыша «все все увидели, стало все открыто, все говорим на одном языке» — все остальные бегали от нас, как от огня..
