Митап Tinkoff DWH Connect

Рет қаралды 4,828

Код Желтый

Күн бұрын

Пікірлер: 20

@Roman_marusyak 7 ай бұрын

Химера и Арсений просто огонь!!!

@kod_zheltyi 7 ай бұрын

Вопрос: есть ли релизный дни, например раз в неделю/две или вывод витрин на прод возможен в любой день? какие этапы согласования проходит задача перед выводом витрины на прод? Ответ: Релиз происходит еженедельно с понедельника по четверг (4 раза в неделю) в рабочее время. Исключения - если есть праздничные дни либо ведутся восстановительные работы после сбоя, если такое вдруг случилось. Иначе, общее правило, релиз проходит, если процессы сейчас стабильны и завтра не выходной. Этапы согласования: таковыми являются успешно пройденные ревью анализа и ревью разработки более опытным коллегой. Иных согласований нет. Релиз возможен на следующий день после перевода задачи в статус Ready to Release.

@kod_zheltyi 7 ай бұрын

Вопрос: How do you measure tables that are barely used but occupy space within DWH infra? If so, how often? Also, what's the evaluation time for determining a "non-used" table? Ответ: Мы используем в Greenplum, а дальше планируем раскатывать и на другие системы, такой элемент как Consumer. Это усовершенствованная модель, основанная на Ресурсных группах. Consumer содержит в себе квотирование по всем видам ресурсов на группу пользователей, в том числе таблицы, которые им необходимы для аналитики. Если объект новый или используется в ETL, он попадает в технический Consumer. В других случаях пользователи добавляют таблицы в свои собственные Consumer. Если объект не состоит ни в одном Consumer-е, то через пару недель он удаляется за ненадобностью никому.

@kod_zheltyi 7 ай бұрын

Вопрос: сколько витрин в каждом продукте? Ответ: Если вести речь только про презентационные витрины в слое EMART, то их немного до 3 витрин на один продукт. Если говорить про размеры MART-слоев, то в одном слое в среднем около 20-25 таблиц. Таких слое несколько десятков.

@kod_zheltyi 7 ай бұрын

Вопрос: Используете ли Greenplum ? Ответ: Да. Сейчас является основным инструментом для аналитики. Но он далеко не единственный, где храним и обрабатываем данные.

@kod_zheltyi 7 ай бұрын

Вопрос: Sorry, I can't write in Russian properly. Do you have any reporting tool for Stream data? i.e. close to Real-Time reports/fraud detection tools? Ответ: Есть инструменты для мониторинга процессов, Здоровье систем. Это техническая достаточно история, инструменты одинаковые для всего Тинькофф. Есть визуализаторы процессов в онлайне - process mining. Раньше пользовались Celonis, сейчас используем похожий инструмент собственной разработки. И Федор рассказывал про ETL-инструмент Unicorn. Наш собственный фреймворк для стриминговой обработки данных. Но это больше про процесс на основе данных, а не отчетность.

@kod_zheltyi 7 ай бұрын

Вопрос: Как подключить Debezium к кафке? Ответ: Debezium выступает больше аналогом нашего BatchODS, отличаются внутренним устройством - BatchODS написан нами. Вопрос вероятно возник в контексте упоминания SDP - Streaming Data Platform. Тут можно ответить в общем формате: это собственная разработка, от и до. На входе топик Kafka, cообщения в avro-формате, через использование Schema Registry. На выходе наш движок читает сообщения, и раскладывает в реляционный формат.

@kod_zheltyi 7 ай бұрын

Вопрос: как вы решаете задачу маппинга одной сущности в разных системах-источниках? Поподробнее пожалуйста)) клиенты/транзакции Ответ: Если вопрос касательно схлопывания одного экземпляра из разных систем, то здесь чаще всего все просто: в компании принято везде заводить Интеграционные идентификаторы, через которые системы общаются между собой. На основе интеграционного ID всегда можно легко выйти на нужный экземпляр. Если вопрос был больше про наличие сущностей в нескольких системах, то собственно при разных интеграционных ID собирается новый экземпляр. Генерация ключа из значений родного id + код системы.

@kod_zheltyi 7 ай бұрын

Вопрос: Добрый день. Подскажите - хранится ли в хранилище техническая история объектов? если да, то в каком слое? Ответ: В большинстве кейсов храним техническую историю именно в детальном слое (и DataVault слой, и DDS). Такая история применима для объектов Измерений. Для Фактов обычно не имеет смысла. История может быть как подневная (идет фиксацией датой загрузки), так и внутридневной (это больше можно назвать бизнесовой). В объектах выше детального слоя история хранится, только если это было условием для создания витрины.

@kod_zheltyi 7 ай бұрын

Вопрос: До таблицы в учетной системе можно спуститься? Есть какие-то S2T? Ответ: Источник является зоной ответственности его владельца. Базы в большинстве кейсов боевые, поэтому имеют высокие требования по доступам и критичности. В большинстве кейсов доступа туда нет. Есть размеченный владелец, к которому можно в любой момент времени обратиться. Маппинг, как правило, или 1 в 1 (для BatchOds), или лежит на стороне источника - тут мы оперируем задокументированной avro-схемой.

@kod_zheltyi 7 ай бұрын

Вопрос: Видно только технические контроли, бизнес-проверки можно сделать? Межвитринные проверки? Ответ: Все, что касается последнего показанного инструмента DQ Tools в конце первого доклада, это про бизнес-проверки в первую очередь. Инструмент предоставляет python-библиотеку, через готовые функции которого в пару строк можно поднять большинство проверок.

@kod_zheltyi 7 ай бұрын

Вопрос: А как живёт созданная нода? 24/7 пока её не убьют руками или пока не закроется задача? Среды для разработки существуют 24/7 все время пока идет разработка задачи. В принципе их можно удалять и создавать заново без потери изменений, поскольку изменения сохраняются (в git или в файлах пакета), но это просто неудобно. Тестовые среды создаются заново перед каждым запуском тестов, которым они нужны. Опять же, их можно было бы удалять сразу же после окончания теста, но мы оставляем их, чтобы пользователи могли разобраться почему тесты упали.

@kod_zheltyi 7 ай бұрын

Вопрос: Кто занимается автоматизацией скриптов / отладкой etl и т.д , дата инженеры или аналитики? Ответ: Занимаются все. Бэклог "хотелок" на автоматизацию есть всегда, его наполняют все участники процесса. Делают задачи и аналитики, и разработчики как доп активность в рабочее время между основными задачами, у кого есть просто желание, есть навыки, или хочет больше прокачаться в python-е.

@kod_zheltyi 7 ай бұрын

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

@kod_zheltyi 7 ай бұрын

Вопрос: распределяется ли опыт между членами команды на функциональном уровне, или для конкретных технологий есть конкретные эксперты, которые делятся между командами? Ответ: Как упоминал Федор в докладе - мы стараемся не замыкать функции внутри центральных дата-команд, а распределять экспертизу по всем продуктам, где это необходимо. Поэтому в каждую технологию создаём и стараемся поддерживать актуальной возможность быстрого погружения в технологию для любого инженера продуктовых команд. Для того же NiFi есть отдельный трёхдневный курс молодого бойца, который может пройти любой желающий инженер данных.

@kod_zheltyi 7 ай бұрын

Вопрос: На каком языке ведете разработку инструментов? Python ? Ответ: Наша ETL-платформа, которая разрабатывает инструменты для наших инженеров - уже настолько масштабная (десятки инструментов), что не ограничивается одним-двумя языками. Язык стараемся подбирать под конкретную технологию. Что касается ETL-инструментов, то: Apache Airflow - это Python, Apache Flink - Java+Scala, Apache NiFi - в основном Java. Что касается остальных инструментов для инженеров и пользователей хранилища: в основном используется Python, но есть и более специализированные сервисы на Go и, например, JavaScript.

@kod_zheltyi 7 ай бұрын

Вопрос: не был представлен инструмент Оркестратор. Ответ: Планировщик для всех ETL процессов также является собственной разработкой. Достаточно технический продукт, решили не показывать. Не все аналитики, и даже разработчики, сильно погружаются обычно. Планировщик есть основной, который запускается каждую ночь в 00 00. Есть ручные задания. Планировщик собирает все объекты, которые необходимо построить, всех видов и со всех кластеров, выстраивает последовательность запуска, и по мере получения события запускает следующее. Многие объекты строятся параллельно. У планировщика есть свой интерфейс, где можно посмотреть настройки объекты, статус построения последних запущенных, настроить бизнес-задания.

@kod_zheltyi 7 ай бұрын

Вопрос: Не совсем понял, у вас аналитик решает как с источника загрузить данные в реплику (стейджинг)? Ответ: Да, все так. У загрузки данных с источника есть много нюансов: разобраться, как данные лежат на источнике, какие есть особенности, выбрать инструмент, который даст win-win с тз удобства двум сторонам и оптимальности процессов, убедиться, что схема составлена верно, формат схемы не повлияет на качество данных.

@kod_zheltyi 7 ай бұрын

Вопрос: Что если под собранную среду понадобились дополнительные таблицы? Ответ: Это очень распространенная ситуация, поэтому мы разрешаем в любой момент вручную добавлять в собранную среду дополнительные таблицы и ETL-процессы. Кроме того, мы позволяем сбрасывать изменения в таблицах, на случай если разработчик что-то испортит или просто захочет убрать добавившиеся строки из таблиц-приемников.

@kod_zheltyi 7 ай бұрын

Вопрос: Как у вас организованно регрессионное тестирование изменений, вносимых из множества изолированных сред? Ответ: Действительно, каждый разработчик разрабатывает и тестирует только свой кусок изменений в своей пробирке и убеждается, что изменения в его процессах и данных ожидаемы и соответствуют задаче. У нас есть автоматика, которая следит и предупреждает пользователей, если они дорабатывают одни и те же объекты, либо если их доработки влияют друг на друга. Таким образом проблему отсутствия влияния изменений в рамках задач друг на друга мы пока решаем процессным образом - связываем и блокируем задачи, нотифицируем аналитиков и разработчиков о пересечениях. Это действительно не самый надёжный подход, поэтому в ближайшем будущем у нас появится отдельный пред-продакшен контур со своим регламентом, на который будут выкатываться и тестироваться изменения.