Комментарии 26
Редкой прелести текст.
А я люблю для анализа данных при миграции (и не только) использовать QlikView. Отклонения в данных сразу в глаза бросаются в фильтрах.
Такое ощущение, что ребята, так лихо мигрирующие данные с ошибками и так лихо пропускающие ошибки — пропустили что-то еще действительно важное, например мой остаток по счёту, или несколько процентов проводок, потому-что у них слишком много нулей оказалось, либо назначение слишком длинное.
Работает и в Excel, и в Google Docs, и в «Яндекс.Таблицах»
Яндекс.Таблицах????
Любопытно. Если можно, два вопроса:
1. Зачем динамически строить SQL в Excel, когда можно делать это ещё лучше на чистом SQL на базе системных вьюшек?
2. С какой целью ETL выделен в отдельную команду? Почему нельзя импортировать все данные из старой базы в отдельные схемы в новой, а затем делать трансформации и сравнения на SQL?
Получаем возможность делать прямые JOIN'ы между «было -> стало», а также экономим время на коммуникациях и неизбежных ошибках в логике ETL.
1. Зачем динамически строить SQL в Excel, когда можно делать это ещё лучше на чистом SQL на базе системных вьюшек?
SELECT ', count(' || column_name || ') AS ' || column_name
FROM columns
WHERE ...
2. С какой целью ETL выделен в отдельную команду? Почему нельзя импортировать все данные из старой базы в отдельные схемы в новой, а затем делать трансформации и сравнения на SQL?
Получаем возможность делать прямые JOIN'ы между «было -> стало», а также экономим время на коммуникациях и неизбежных ошибках в логике ETL.
1. Специально не стала писать про системные представления и служебные таблицы, т.к. доступ к ним на уровне системы-источника обычно не дают. Если доступ есть, то это отличная альтернатива экселю! Спасибо за комментарий!
2. ETL делают или системные интеграторы со стороны заказчика, или отдельные компании, которые приходят со своими ETL-продуктами или шиной, например, Data Stage или Tibco. Т.е. в нашей БД мы видим уже конечный результат трансформаций, который происходит «где-то».
Но мы сейчас как раз в поиске своего ETL-разработчика, чтобы сэкономить время на коммуникациях и объяснениях, как вы и написали.
2. ETL делают или системные интеграторы со стороны заказчика, или отдельные компании, которые приходят со своими ETL-продуктами или шиной, например, Data Stage или Tibco. Т.е. в нашей БД мы видим уже конечный результат трансформаций, который происходит «где-то».
Но мы сейчас как раз в поиске своего ETL-разработчика, чтобы сэкономить время на коммуникациях и объяснениях, как вы и написали.
Я очень далек от кровавого энтерпрайза, спросить среди знакомых не у кого, поэтому полюбопытствую:
1. Сколько времени и итераций занимает типичная такая миграция от начала анализа и до завершения проекта? Насколько процесс бюрократизирован?
2. Как с безопасностью данных? Вам, чтобы проанализировать данные, нужно получить к ним доступ. Вам выдают копию? Или пускают на свои серваки? Или каждый запрос проверяет безопасник банка?
1. Сколько времени и итераций занимает типичная такая миграция от начала анализа и до завершения проекта? Насколько процесс бюрократизирован?
2. Как с безопасностью данных? Вам, чтобы проанализировать данные, нужно получить к ним доступ. Вам выдают копию? Или пускают на свои серваки? Или каждый запрос проверяет безопасник банка?
Спасибо за отличные вопросы! По пунктам:
1. Что считать «типичной миграцией»? В каждом проекте исторические миграции данных занимают разное время. Почему? Основные факторы, от которых зависит длительность миграции:
— характеристики железа
— сложность ETL-трансформаций и особенности БД системы-источника
— объем загружаемых данных
— полнота загружаемых данных
На одном из проектов оба этапа миграции (ETL + обработка в нашем продукте) для 100 млн клиентов, но более полмиллиарда сущностей — счета, адреса, связи, заняли 20 дней — 10 дней ETL, 10 дней нашей обработки.
Бюрократизированность сильно зависит от конкретного заказчика. Обычно все решается письмами или звонками. Иногда сталкивалась с тем, что на предоставление доступов к таблицам БД или на необходимую железку заводят заявки, срок выполнения индивидуален — от нескольких минут до нескольких дней, смотря, что попросишь. Заказчики тоже заинтересованы в результате.
2. Вы подняли животрепещущий вопрос, который мы с коллегами в чате обсуждали. Тоже все очень сильно зависит от заказчика. При старте проекта мы подписываем NDA и другие соглашения. Данные смотрим на серверах заказчиков, если обе стороны заинтересованы в том, чтобы улучшить качество данных. Про проверку каждого запроса ничего не скажу, возможно в фоновом режиме мониторинг идет. На предоставление доступа к конкретным таблицам я писала заявки с обоснованием необходимости.
Еще раз подчеркну, все очень сильно зависит от заказчика и его внутренних процессов.
1. Что считать «типичной миграцией»? В каждом проекте исторические миграции данных занимают разное время. Почему? Основные факторы, от которых зависит длительность миграции:
— характеристики железа
— сложность ETL-трансформаций и особенности БД системы-источника
— объем загружаемых данных
— полнота загружаемых данных
На одном из проектов оба этапа миграции (ETL + обработка в нашем продукте) для 100 млн клиентов, но более полмиллиарда сущностей — счета, адреса, связи, заняли 20 дней — 10 дней ETL, 10 дней нашей обработки.
Бюрократизированность сильно зависит от конкретного заказчика. Обычно все решается письмами или звонками. Иногда сталкивалась с тем, что на предоставление доступов к таблицам БД или на необходимую железку заводят заявки, срок выполнения индивидуален — от нескольких минут до нескольких дней, смотря, что попросишь. Заказчики тоже заинтересованы в результате.
2. Вы подняли животрепещущий вопрос, который мы с коллегами в чате обсуждали. Тоже все очень сильно зависит от заказчика. При старте проекта мы подписываем NDA и другие соглашения. Данные смотрим на серверах заказчиков, если обе стороны заинтересованы в том, чтобы улучшить качество данных. Про проверку каждого запроса ничего не скажу, возможно в фоновом режиме мониторинг идет. На предоставление доступа к конкретным таблицам я писала заявки с обоснованием необходимости.
Еще раз подчеркну, все очень сильно зависит от заказчика и его внутренних процессов.
А вариант со средствами профилирования совсем не рассматривался? Talend, Ataccama, Oracle и пр.?
Конечно можно использовать специальные средства профилирования, если они у вас есть и вы умеете ими пользоваться.
Мой посыл скорее в том, как дешево и сердито (табличными редакторами и sql) сделать аналитику и не страдать, что нет подручных программ.
Мой посыл скорее в том, как дешево и сердито (табличными редакторами и sql) сделать аналитику и не страдать, что нет подручных программ.
Talend опенсорс, а Ataccama бесплатна в части профилирования. Есть разные видео, где все достаточно просто (сильно проще чем эксель и sql)…
Не, я понимаю, что в «кровавом энтерпрайзе» тебе могут урезать все права, не дать поставить софт самому, отказать в установке по запросу — тогда да, тогда и VBA будет самым лучшим языком программирования.
Но все же, я бы настаивал на использовании средств профилирования для себя лично.
Не, я понимаю, что в «кровавом энтерпрайзе» тебе могут урезать все права, не дать поставить софт самому, отказать в установке по запросу — тогда да, тогда и VBA будет самым лучшим языком программирования.
Но все же, я бы настаивал на использовании средств профилирования для себя лично.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миграция данных в кровавом энтерпрайзе: что анализировать, чтобы не завалить проект