ETL Best Practices

Процессы извлечения, преобразования и загрузки данных (ETL) являются центральными в стратегии управления данными любой организации. Каждый шаг в процессе ETL — получение данных из различных источников, изменение их формы/структуры, применение бизнес-правил, загрузка в хранилище и проверка результатов — является важным этапом в процессе передачи данных.

Ниже перечислены некоторые основы, которые являются ключевыми для большинства имплементаций ETL.

Описание ключевых процессов ETL согласно лучшим практикам

What is ETL (Что такое ETL)

ETL (Extraction, Transformation, Loading) является сокращением от процессов извлечения, преобразования и загрузки данных, которые используются при наполнении данными хранилища.

При работе с операциями ETL вы обычно слышите термин конвейер данных/data pipeline (или просто «конвейер/pipeline»). Легко визуализировать такой процесс, как конвейер, в который поступают необработанные данные и выходит полезная информация.

Некоторые данные могут быть переданы в специальное место для очистки, а некоторые данные могут быть помечены как плохие и отправлены в область хранения плохих данных.

Конвейер данных может быть простым и прямым или может иметь множество изгибов и разветвлений. В большинстве случаев этот виртуальный конвейер данных существует в RAM на компьютере/сервере, на котором выполняются операции ETL, также данные могут быть временно сохранены в промежуточные или временные таблицы по мере необходимости.

Как следует из названия, в ETL-операциях существует три разных этапа.

Extraction (Экстракция или выгрузка данных)

На этом этапе данные извлекаются из источника и попадают в конвейер. Источником может быть реляционная база данных, плоский файл (csv, excel, txt, и т.д.), API, устройство IOT, веб-сайт — почти все, что может создавать и/или хранить данные, может использоваться в качестве источника в процессе ETL. Этот этап не ограничен одним источником данных. Обычно для операций выгрузки данных характерно использование нескольких источников.

Хотя извлечение данных обычно является самой простой частью процесса ETL, иногда процесс выгрузки данных может приобретать сложную форму. Например, при выгрузке очень больших наборов данных, экстракция данных может выполняться длительное время, поэтому может потребоваться реализация дополнительной логики для создания инкрементальной выгрузки данных.

Также при выгрузке данных из API сервисов, таких как Youtube API, Facebook API при большом объеме данных может портебоваться специальная логика, т.к. многие сервисы отдают данные в рамках доступного лимита (например, лимит по количеству запросов или скорости обращения к API).

Transformation (Преобразование)

На этапе преобразования/трансформации данных могут выполняться следующие манипуляции над данными:

• Data reshaping: Изменение формы данных
• Изменение гранулярности данных (data granularity), когда одна входная строка становится несколькими выходными или наоборот
• Изменения типа данных (например, преобразование текста в целое число)
• Устранение дубликатов
• Использование таблицы поиска или маппинга (lookup tables/mappings) для проверки значений или для подстановки значения по ключу
• Удаление пробелов в начале или в конце строки, а также удаление других непечатных символов (их кстати можно обнаружить в MS Word или Notepad++, если вставить в документ и включить режим отображения символов)
• Привести текст к единому виду: например, стандартизировать регистр и заглавные буквы
• Выявление и перенаправление неверных или подозрительных строк данных
• Применение бизнес-логики
• Парсинг отдельных значений из строк, например, с помощью RegEx и создание на основе полученных значений дополнительного атрибута данных/транзакций

Не каждый процесс ETL требует всех перечисленных манипуляций. Большинство процессов будет использовать только их часть, либо отдельные методы для решения конкретной задачи. Степень преобразования данных зависит от качества и формы исходных данных, а также от того, насколько хорошо они соответствуют потребностям бизнеса и от поставленных задач самим бизнесом.

Некоторые наборы данных потребуют минимального преобразования, в то время как другие наборы данных потребуют значительной переработки. Для финансовых данных очень часто требуется реализация специальной логики аллокаций расходов, что порой приводит к большому числу обрабатывающих скриптов для небольшого объема данных по сравнению с остальными доменами.

Преобразование данных является наиболее сложной частью процесса ETL. Фактически, для большинства инициатив по перемещению данных, разработка процесса преобразования данных (включая сбор требований, разработку и тестирование) является наиболее трудоемкой частью всего проекта.

Совет по ETL для project managers: не стоит недооценивать время или усилия, необходимые для создания процесса преобразования данных. Проекты могут значительно задерживаться по срокам, потому что архитекторы или разработчики недооценили время, необходимое для разработки и тестирования этапа преобразования данных.

Load (Загрузка)

Фаза загрузки является последним этапом процесса ETL. На этом этапе данные передаются в структуры (data storage), в которых они будут храниться постоянно.

К тому времени, когда данные достигают фазы загрузки, все обновления завершены и данные уже подготовлены.

Собираем все этапы вместе

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

Иногда и загрузка данных в хранилище включается в эту цепочку.

Logging (Ведение журнала)

Logging (Ведение журнала). Правильная стратегия ведения журнала является ключом к успеху любой архитектуры ETL.

Если бы вы опрашивали специалистов по данным, над какими задачами им больше всего нравится работать, журналирование ETL, вероятно, не попало бы в список. Тем не менее, для успеха любой архитектуры ETL важно установить соответствующую стратегию ведения журнала. Отличной метафорой хорошей инфраструктуры логирования процесса ETL является водопровод дома: он не виден внешне, не является очень интересным, но вы наверняка со временем узнаете, правильно ли он спроектирован и смонтирован (или не установлен вовсе) при возникновении первых проблем с ним.

Что такое Logging?

Что же такое протоколирование ETL (или Logging). Протоколирование ETL — это журнал активности соответствующих событий, которые происходят до, во время и после выполнения процесса extract-transform-load.

Ведение журнала обычно осуществляется в самом программном обеспечении ETL, но может также включать другие журналы (например, в средствах планирования заданий) для получения дополнительных сведений по процессам ETL. Эти журналы будут различаться по степени детализации и объему записей, некоторые из них описывают метрики уровня нагрузки (сколько времени занимал весь процесс, сколько ресурсов потребовалось для работы), а другие относятся к одному небольшому сегменту нагрузки (сколько строк было загружено на шаге N).

Не существует универсального подхода к ведению журнала. В идеале каждый процесс должен оцениваться для определения стратегии ведения журнала на основе критичности данных, частоты выполнения, вероятности отказа и других факторов, которые важны в вашей среде.

Что следует логировать (писать в журнал)?

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

• либо они вообще не регистрируются,
• либо все возможные метрики регистрируются и сохраняются навсегда.

Хотя для каждого из них есть некоторые крайние случаи, ответ почти всегда лежит где-то посередине (хотя, мы надеемся, ближе к способу «регистрировать все»).

Минималистичный подход может включать в себя просто запись времени начала и окончания всего процесса. Подобный урезанный подход работает лучше всего, когда объем возможных ошибок невелик, и когда процесс может быть перезапущен без больших временных и стоимостных издержек.

Это успешно используется для некоторых этапов загрузки, когда данные загружаются в изменяемые промежуточные таблицы. Большинство этапов загрузки включают в себя сначала удаление старых данных из целевых таблиц, что означает, что они могут запускаться повторно, не вызывая случайного дублирования данных. Следовательно, использование минималистического подхода к ведению журнала может быть использовано при таких типах нагрузок, поскольку точки отказа довольно минимальны, и процесс может быть легко перезапущен, если потребуется дальнейшая диагностика.

Однако большинство процессов требуют более интенсивного ведения журнала. Чтобы по-настоящему фиксировать то, что происходит внутри каждого процесса загрузки, а не просто измерять процесс в целом, для каждой задачи должен существовать пошаговый журнал. Если конкретное задание ETL имеет, например, десять шагов, в идеальном проекте будет регистрироваться запуск и остановка каждой задачи, любые исключения на уровне задачи, а также любая необходимая информация для аудита.

Следующие атрибуты logging могут использоваться в качестве приблизительного руководства по типам событий и метрик, которые нужно регистрировать во время логирования:

• Запуск и остановка событий. Начальная и конечная временные метки для процесса ETL в целом, а также их отдельные шаги должны быть сохранены.
• Статус. Шаги процесса могут быть успешными или неудачными по отдельности, и поэтому их состояние (not started, running, succeeded, или failed) должно регистрироваться индивидуально.
• Ошибки и другие исключения. Сбои и аномалии ведения журнала часто являются наиболее трудоемкой частью построения инфраструктуры ведения журнала. Это также та часть, которая приносит наибольшую пользу при тестировании и устранении неисправностей.
• Аудиторская информация. Это может варьироваться от простого захвата количества строк, загруженных при каждом выполнении процесса, до полного анализа количества строк и значений в единицах измерения на пути от источника к месту назначения.
• Тестирование и отладка информации. Это особенно полезно на этапе разработки и тестирования, в частности, для процессов, которые сильно влияют на преобразование ETL.

При планировании стратегии ведения журнала обычно просто регистрируют все события. Некоторые инструменты ETL, в том числе службы интеграции SQL Server , позволяют относительно легко перейти в режим захвата всех событий.

Регистрировать слишком много информации лучше, чем недостаточно, при прочих равных условиях. Однако с ведением журнала всегда связаны затраты: накладные расходы на обработку, пропускная способность сети и требования к хранилищу должны учитываться при определении того, как будут регистрироваться процессы ETL. Регистрация каждого доступного показателя и события может быть проще, но это не бесплатно.

Помните: соблюдайте баланс между тем, что вы хотели бы получить при ведении журнала, и затратами (жесткими и мягкими) на стратегию ведения журнала.

Как следует использовать Logs?

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

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

Большинство фанатов данных на самом деле предпочитают иметь доступ к необработанным, нефильтрованным данным журнала, чтобы можно было писать собственные запросы для получения именно тех исходных данных для детального понимания процессов ETL. Другие люди, которые не так любят писать SQL, вероятно, добились бы большего успеха с более упорядоченной информацией по логированию. Все чаще другим, часто полутехническим или нетехническим людям, также необходим доступ к журналам ETL. Администраторам баз данных, сотрудникам службы поддержки, бизнес-аналитикам и аудиторам, возможно, потребуется увидеть, что находится в журналах, и каждая группа, вероятно, имеет совершенно разные ожидания того, как получить эти данные. Некоторые топ менеджеры также могут периодически просматривать данные журнала ETL.

При рассмотрении того, как будет использоваться информация о регистрации, учтите следующее:

• Кто будет основной аудиторией для этих журналов?
• Каким другим аудиториям может понадобиться доступ к этой информации?
• Будут ли данные проверяться в режиме ad-hoc, или их необходимо формализовать с помощью принудительной доставки через уведомления или с помощью различных dashboards?
• В каком формате информация будет доставлятся наиболее понятным способом?
• Существуют ли проблемы безопасности, требующие фильтрации данных на уровне пользователя?

Ответы на эти вопросы будут определять стратегию раскрытия данных журнала. Это может быть так же просто, как предоставить другим администраторам баз данных местоположение данных журнала, или более формализованным, например, создать отчет через службу отчетов SQL Server или создать отдельную панель мониторинга Power BI.

Независимо от того, какой подход используется, цель состоит в том, чтобы донести необходимую информацию до целевой аудитории максимально понятным способом.

Политика хранения (Retention Policy)

Часто клиенты спрашивают: «Как долго необходимо хранить журналы ETL?».

Оптимальный ответ таков: «Храните их столько, сколько нужно, но не дольше». Да, это стереотипный ответ консультанта, но на самом деле ответ полностью зависит от ожиданий того, как будут использоваться эти журналы.

Вот общий диалог, который случается при обсуждении краткосрочной и долгосрочной стратегии хранения для журналов ETL:

• Короткий срок хранения : «Короткий срок хранения гарантирует, что вы не будете заполнять свои диски кучей старых данных журнала, которые вы никогда не будете использовать. Ведение журналов всего за несколько месяцев или за год обеспечивает достаточную историю для устранения любых недавних логических проблем или проблем с производительностью в вашем ETL. Короткие сроки хранения могут работать хорошо для вас, если вы в основном заинтересованы в оперативной поддержке и не используете свои журналы для долгосрочного анализа производительности или аудита».
• Длительный срок хранения : «Да, в хранилище вам дороже хранить журналы в течение более длительного периода времени. Но кого это волнует? Хранение относительно недорого, и вы можете архивировать старые логи на более медленные и более дешевые диски. Сохраняя свои журналы в течение более длительного периода, вы можете анализировать рабочие нагрузки и производительность ETL с течением времени, чтобы увидеть, как вы оцениваете тенденции по сравнению с прошлым годом. А если вы находитесь в среде с жестким аудитом, длительное хранение журналов может удовлетворить большую часть (или даже все) ваши требования аудита ETL».

Как и с большинством других концепций, не существует единого подхода для удовлетворения каждой ситуации. Однако в большинстве случаев следует ориентироваться на более длительный срок хранения журналов ETL, если только нет явной причины избегать этого. Лучше иметь данные, которые вы никогда не будете использовать, чем если вам потребуются данные, которых у вас нет.

Также можно агрегировать информацию из логов и наиболее старые данные хранить в виде сводной информации по дням или месяцам.

При создании стратегии хранения журналов ETL необходимо задать следующие ключевые вопросы:

• Будем ли мы использовать данные журнала ETL для тактического устранения неполадок или анализа тенденций и аудита?
• Сколько данных журнала мы генерируем каждый день / месяц / год?
• Сколько стоит хранение данных журнала?
• Насколько сложно и дорого будет архивировать старые логи в более дешевое и медленное хранилище?
• Каковы нормативные и/или аудиторские требования для журналов ETL?

Вывод

Построение правильной архитектуры ведения журнала ETL является одним из самых основных компонентов стратегии управления данными предприятия. Слишком часто ведение журнала является запоздалой мыслью, связанной с тем, что все остальное завершено или почти завершено. Точно так же, как сантехника в вашем доме спроектирована параллельно с остальной частью дома, ваша стратегия logging должна быть центральной частью вашей архитектуры ETL.

Дизайн ведения журнала ETL будет отличаться в разных организациях и даже может отличаться в разных проектах одной и той же компании. Рассмотрение всех переменных — какой уровень ведения журнала требуется, кто будет его использовать и как долго его следует хранить — поможет сформировать дизайн вашей архитектуры ведения журнала ETL.

ETL Auditing (Аудит)

Auditing (Аудит). Загрузка данных без ошибок не обязательно является успешной загрузкой. Хорошо продуманный процесс не только проверяет ошибки, но также поддерживает аудит количества строк, финансовых сумм и других показателей.

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

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

ETL Аудит

Начнем с определения аудита ETL. Аудит в процессе извлечения, преобразования и загрузки предназначен для достижения следующих целей:

• Проверка наличия аномалий в данных, помимо простой проверки серьезных ошибок.
• Захват и хранение электронного следа любых существенных изменений, внесенных в данные во время преобразования.

Если процесс ETL — это автомобиль, то аудит — это страховой полис. Аудит ETL помогает подтвердить отсутствие аномалий в данных даже при отсутствии ошибок. Хорошо продуманный механизм аудита также повышает целостность процесса ETL, устраняя двусмысленность в логике преобразования путем перехвата и отслеживания каждого изменения, вносимого в данные по пути. Есть некоторые общие черты поведения аудита и линии передачи данных.

Проверка аномалий данных

Допустим, вы загружаете данные из OLTP в хранилище данных с помощью своего любимого инструмента ETL. Эта конкретная загрузка извлекает 1,5 миллиона строк из источника OLTP. По пути он проходит несколько шагов преобразования и успешно завершает все свои задачи, загружая данные в пункт назначения. Однако быстрая проверка места назначения показывает, что было загружено только 1 499 990 строк. Что случилось с теми недостающими 10 строками данных?

Вот небольшой грязный секрет, который существует в программном обеспечении ETL: относительно легко просто потерять данные. Даже в таком инструменте ETL как SSIS, не так уж сложно настроить пакет, который позволяет данным попадать в битовое ведро (bit bucket) без каких-либо предупреждений или ошибок. А обновить данные — возможно, неправильно — даже проще, чем просто потерять данные. Это не дисфункция программного обеспечения, а функция его гибкости. Инструмент ETL не сможет долго продержаться на рынке, если он не позволит разработчикам сгибать, изменять форму и преобразовывать данные неортодоксальными способами. Эта гибкость связана с ответственностью за правильное использование инструментов; при плохой настройке данные могут просто исчезнуть или неправильно преобразоваться. Даже самые опытные и благонамеренные ETL-инженеры время от времени обнаруживали, что их данные где-то пошли не в ту сторону.

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

• Общее количество строк
• Совокупные итоги (которые могут включать финансовые суммы или другие сводные данные)

Некоторые процессы потребуют более тщательного аудита. Те, кто, как и я, когда-либо тратили время на перемещение и преобразование данных главной бухгалтерской книги, подтвердят, что даже подсчета строк и финансовых сумм недостаточно; обеспечение того, чтобы конечный баланс соответствовал начальному балансу плюс все транзакции за этот период. В других случаях может потребоваться проверка, чтобы убедиться, что данные находятся в разумных пределах.

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

Журнал изменений скриптов трансформации данных

Разработчики ETL имеют значительные возможности для изменения данных. Часть «T» ETL подразумевает, что создаваемые нами процессы будут обновлять данные из их исходного состояния. Когда возникают проблемы с ETL-нагрузками, они очень часто коренятся в этих преобразованиях: сталкиваются бизнес-правила, процессы очистки, дедупликации и другие настройки, что приводит к неожиданному выводу данных. 

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

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

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

• Насколько критичен этот процесс?
• Сколько преобразований выполняется с данными?
• Насколько сложно неспециалисту понять, какие изменения происходят по замыслу в процессе ETL?
• В какой степени эти данные регулируются HIPAA , SOX или другими правилами?

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

Построение системы аудита ETL

Способы добавления аудита в существующий процесс ETL сильно различаются в зависимости от используемой платформы и требуемого объема аудита. В большинстве программных пакетов ETL есть инструменты, которые могут помочь в процессе регистрации, а некоторые сторонние поставщики программного обеспечения предлагают компоненты и платформы аудита. Иногда в этом может помочь и само ядро ​​базы данных: и SQL Server , и Oracle предлагают функции сбора измененных данных для отслеживания всех операций вставки, обновления и удаления в отслеживаемых таблицах.

Независимо от того, является ли ваша архитектура ETL простой, как набор пакетных файлов, выполняющих операторы SQL, или сложной, как сотни или тысячи вложенных пакетов SSIS, добавление логики аудита достижимо. Даже при наличии программного обеспечения, специально созданного для аудита ETL, считается, что подход, который работает лучше всего заключается в настройке логики аудита для каждого процесса. С аудитом сложно справиться с помощью шаблонного подхода (даже в большей степени, чем с логированием), и то, что вы получаете в удобстве, дорого обходится в гибкости.

Можно проводить аудит процессов ETL в индивидуальном порядке, не изобретая каждый раз велосипед. Я держу под рукой общий набор определений таблиц и поддерживающую логику, чтобы сократить путь к следующим целям аудита:

• Простой совокупный аудит количества строк, финансовых данных и других ключевых показателей.
• Шаблоны документации для сопоставления источника и цели и логики преобразования
• Облегченный аудит изменений на уровне пакетов
• Полный аудит каждого изменения, внесенного в процессе трансформации

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

Вывод

Аудит процессов ETL часто считается роскошью, несущественной необходимостью, которую можно добавить, если позволяет время. Однако пропуск этого критического элемента хорошо спроектированной архитектуры ETL почти всегда приведет к трениям или путанице в отношении того, как и почему данные выглядят именно так. Аудит ETL редко является наиболее заметным элементом архитектуры, но это необходимый страховой полис для защиты целостности данных и процесса.

Data Lineage (Линия данных или Наследование данных ETL)

Data Lineage (Линия данных). Понимание того, откуда берутся данные, когда они были загружены и как они были преобразованы, крайне важно для целостности последующих данных и процесса их перемещения.

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

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

В мире данных шаблон проектирования линии передачи данных ETL — это наша цепочка поставок. В этом совете ETL Best Practices  я расскажу о важности происхождения данных ETL и продемонстрирую некоторые советы по проектированию, как добавить это в ваши новые и существующие процессы.

ETL Data Lineage

Почему важна линия передачи данных?

• Он укрепляет доверие к данным, разъясняя происхождение данных
• Упрощает процесс устранения неполадок, позволяя отслеживать данные на уровне строк
• Снижает риск потери данных ETL, делая «дыры» в процессе более заметными
• Обеспечивает лучшую видимость бизнес-правил, которые в противном случае были бы скрыты в процессе загрузки ETL

Концепция происхождения данных относительно проста: построить процессы ETL таким образом, чтобы можно было проследить одну строку данных до источника, откуда они пришли и как они пришли сюда. Достаточно просто как шаблон дизайна, верно? Однако «простое» не означает «простое», и в результате я обнаружил, что большинство процессов ETL не определяют четкую линию данных. Правильное построение и тестирование элементов отслеживания происхождения данных требует времени и усилий. Требуются положения в самих данных — некоторые ключи или ключи, позволяющие отслеживать данные из исходного источника в конечный пункт назначения, — а также тщательная документация процессов, через которые они проходят, чтобы туда попасть. В большинстве случаев установление происхождения данных также включает в себя аудит изменений, которые происходят на различных этапах ETL.

Относительная и Абсолютная Линия Данных

Существует два варианта построения линии данных ETL: либо отследить каждую строку до ее исходного значения, используя первое доступное значение ключа (абсолютное происхождение), либо для процесса ETL с несколькими шагами настройте каждую таблицу так, чтобы каждый row будет иметь указатель на ключ из таблицы, которая непосредственно предшествовала этому процессу загрузки (относительное происхождение). Первый шаблон лучше подходит для более простых установок, когда есть только одна или две фазы (или шлюзы) ETL-преобразования, и прохождение данных от одного шлюза к другому является четким и однозначным. Однако модель абсолютного происхождения данных легко перерастает, что требует перехода к относительной модели происхождения данных.

Как показано в приведенной выше модели, модель относительного происхождения данных является немного более сложной, требующей обхода нескольких шлюзов для определения происхождения конкретной строки. Тем не менее, относительная модель происхождения данных также гораздо легче масштабируется и упрощает процесс отслеживания нетипичных моделей нагрузки (например, таких, когда один из этапов в процессах ETL может генерировать новые данные без соответствующей строки из источника).

Как выглядит Data Lineage?

Давайте установим конкретный пример этого. Знакомый сценарий: клиент отправляет нам данные с помощью Excel. Ниже приведен фрагмент этого файла данных.

Быстрый взгляд показывает некоторые очевидные закономерности в этих данных:

• В этом файле представлены две разные категории данных: демография пациентов и детали транзакций.
• Существует уникальный ключ уровня строки. PatientID специфичен для пациента, но у нас есть дублированные значения для пациента «Уэйн, Брюс»
• Грязно. Имена появляются в двух разных форматах.
• Это неполно Количество отсутствует в одной строке, а в другой отсутствует Итоговая строка и Новый баланс.
• У него есть запись Джона Доу. Возможно, это потребует особой обработки?

Одна из основ происхождения данных — наличие одного или нескольких полей, обеспечивающих уникальность на уровне строк. В этом случае у нас нет таких полей из источника, поэтому нам нужно будет создать свои собственные в этом случае. Даже в тех случаях, когда поле (или комбинация полей), по-видимому, обеспечивает уникальность на уровне строк, я рекомендую вам не поддаваться искушению использовать естественный уникальный ключ (ключи) для целей происхождения данных. Хотя он может сохранить дополнительный столбец, пропуская суррогатный уникальный ключ, в ряде случаев использование естественных ключей может вызвать проблемы: заполнение одной и той же таблицы из нескольких источников потенциально перекрывающимися значениями; непреднамеренные повторяющиеся значения ключей, когда ни один из них не ожидается процессом ETL; и тип 2 медленно меняющиеся размерыгде дублирование бизнес-ключей ожидается в соответствии с замыслом. Для использования суррогатного уникального ключа требуется немного больше усилий и дополнительное пространство для хранения, но преимущества намного перевешивают затраты.

При создании идентификаторов строк на уровне таблицы лучше всего работает целое число (целое число 4 или 8 байтов). Чтобы поместить эти данные в таблицу базы данных, я бы создал дополнительный столбец в виде автоматически увеличивающегося целочисленного значения, которое в большинстве систем баз данных упоминается как значение идентификатора, чтобы обеспечить привязку на уровне строк для уникальности и отслеживания происхождения данных. Ниже я показываю промежуточную таблицу, используемую для получения данных из файла выше. Обратите внимание, что на данный момент я не вносил изменений в схему, за исключением добавления этого нового столбца идентификаторов (SourceRowID) и столбца ETLID для отслеживания идентификатора операции ETL, которая обработала загрузку (подробнее об этом позже).

Новый столбец SourceRowID теперь будет использоваться для целей происхождения данных.

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

Как показано, перемещение данных элемента начисления в его собственную таблицу сохраняет строки, относящиеся к отдельным позициям начисления, а также значение SourceRowID, сгенерированное, когда данные попали в исходную промежуточную таблицу выше. В этой таблице я также добавил поле идентификации ChargeItemKey, которое однозначно идентифицирует каждый элемент начисления. Поле ChargeItemKey не является обязательным для этого дизайна, но я обычно использую столбец идентификаторов в каждой новой таблице в стробированном дизайне ETL — особенно, когда данные изменяются при прохождении через эти ворота. Использование этого шаблона создания нового суррогатного идентификатора для каждой таблицы также поддерживает гибкий шаблон относительного происхождения данных, упомянутый выше.

Работа с информацией о пациенте из исходного файла данных немного сложнее, чем элементы оплаты. Поскольку в данных есть известные дубликаты, перемещение данных в таблицу с детализацией на уровне пациента потребует некоторой дедупликации. Существует много методов для выполнения дедупликации, поэтому я сохраню специфику этой операции для другого дня. После дедупликации мы получаем таблицу подготовки пациентов, которая выглядит примерно так.

Как и прежде, специфичные для зерна поля передаются в новую таблицу пациентов. SourceRowID сохраняется как указатель на исходные данные, сохраняя происхождение данных. Поскольку эти ворота также управляли дедупликацией записей о пациентах, выходные данные представляют собой пять строк, а не шесть, показанные в оригинале. Обратите внимание, что процесс дедупликации в этом примере явно не отслеживает запись пациента для SourceRowID 2 (дубликат пациента «Уэйн, Брюс»), так как данные уровня пациента были свернуты в строку, помеченную SourceRowID 1. В некоторых При планировании линий данных ETL может возникнуть необходимость отслеживать строки, которые намеренно отбрасываются из-за дедупликации. Вот где может пригодиться хорошая стратегия аудита ETL , отслеживая те строки, которые приносятся в жертву дедупликации и другим бизнес-правилам.

Этот относительно тривиальный пример показывает краткое описание конструкции, в которой уникальный идентификатор строки создается и сохраняется на протяжении двух этапов ETL. Очевидно, что состояние этих данных, скорее всего, будет и дальше меняться: очистка данных будет выполняться по формату столбца с именем, столбцы с нулевыми числами, скорее всего, должны быть очищены, а запись Джона Доу имеет некоторые недостатки (нет AccountStatus или Значения ChargeEvent), которые могут потребовать либо создания значения, либо перенаправления всей строки для сортировки. Независимо от того, имеет ли этот процесс два шлюза или двадцать, один и тот же шаблон происхождения данных ETL будет по-прежнему оставаться верным: каждая строка должна быть прослеживаемой до своего происхождения либо напрямую (через абсолютное происхождение), либо косвенно (используя относительное происхождение).

Отслеживание процесса ETL

При реализации линии данных я почти всегда добавляю также идентификаторы линии процесса ETL. Эти идентификаторы процесса, представленные в приведенном выше примере в столбце ETLID, идентифицируют экземпляр выполнения процесса ETL, который загрузил данные. Как показано выше, эти идентификаторы отличаются от одной таблицы к другой, но дублируются в каждой таблице. Это по замыслу; все строки, вставленные или обновленные в данной таблице в одном и том же цикле ETL, будут совместно использовать значение идентификатора ETL, и в большинстве случаев эти идентификаторы ETL являются специфическими для каждой загрузки таблицы. Отслеживание происхождения линии на уровне, а также идентификаторов операций ETL помогает создать электронный след, показывающий путь, по которому каждая строка данных проходит через конвейер ETL.

заявка

Все ли процессы ETL требуют отслеживания происхождения данных? Нет. Меньшие, менее сложные процессы ETL могут не требовать того же уровня (если вообще) отслеживания происхождения, который был бы обнаружен при большой загрузке хранилища данных с несколькими шлюзами. Больше гейтов и / или преобразований, которые происходят во время ETL, увеличат потребность в полном отслеживании линии передачи данных. В случае сомнений, я рекомендую потратить дополнительное время на встраивание происхождения данных ETL в ваш конвейер данных. Лучше иметь это и не нуждаться в этом, чем наоборот.

Вывод

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

ETL Modularity (ETL Модульность)

ETL Modularity (ETL Модульность). Создание многократно используемых структур кода важно в большинстве областей разработки, и особенно в процессах ETL. Модуляризация ETL помогает избежать многократного написания одного и того же сложного кода и уменьшает общие усилия, необходимые для поддержки архитектуры ETL.

Представьте на минуту, что вы создали программную вещь. На самом деле, мы будем называть это Вещи. Вы вложили много работы в The Thing, и она делает именно то, что вы хотели. Вы вводите The Thing в игру как часть более крупного решения, и после нескольких ревизий его поведение проверяется, и оно считается готовым к производству. Месяцы спустя, создавая другое программное решение, вы столкнетесь с проблемой, аналогичной той, которую вы решили с The Thing. Вы делаете копию оригинальной The Thing, настраиваете ее для этой цели и помещаете в новое решение. Повторите этот цикл несколько раз. Пять лет спустя вы смотрите вверх и понимаете, что у вас есть две дюжины адаптаций The Thing, несколько отличающихся друг от друга и разбросанных по всей ширине базы кода.

Так, дорогие читатели, так разрабатывается большинство решений ETL.

Этот дизайн, который часто приводит к десяткам — возможно, даже сотням — копий одной и той же логики, создан с благими намерениями. Мне нужно использовать Вещи здесь, я делаю копию последней Вещи и изменяю ее для этого случая использования. Это быстро решает проблему. Тем не менее, это техническое поведение, вызывающее долги, стоит гораздо дороже при длительном обслуживании, чем количество времени, сэкономленное за счет рефакторинга копии существующего фрагмента кода.

Это затруднение не уникально для ETL. Каждый проект по кодированию в каждой организации имеет некоторое количество целенаправленного дублирования кода. Проекты ETL, однако, кажутся особенно восприимчивыми к этой проблеме. Разработчики, архитекторы и менеджеры проектов опасаются незавидного определения лица, нарушившего фид хранилища данных, загрузку данных клиентов или отчет акционеров. Короткий путь заключается в дублировании и адаптации. Но так ли это?

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

ETL Модульность

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

Этот шаблон прекрасно работает для одного процесса. Однако у вас никогда не будет только одного процесса ETL, который загружает файл с FTP. Эти вещи всегда путешествуют в стадах, так что вероятность того, что у вас есть тонна связанных задач, велика. Когда вы устанавливаете их по частям в течение месяцев или даже лет, ваши шаблоны начинают выглядеть примерно так.

Видишь что случилось? Мы начали с хорошего паттерна в процессе ETL A, но два других слегка различались в своих подходах, каждый из которых упускал что-то из исходного паттерна. На самом деле разработчик (и) ETL мог намеренно целенаправленно проектировать эти процессы с различным поведением. Однако в большинстве случаев это не так — разница между этими шаблонами проектирования вызвана ошибкой человека, а не намерением.

Модуляризация процессов ETL может помочь избежать подобных проблем. Модульная конструкция включает в себя разделение общих операций на отдельные и отдельные процессы, которые можно вызывать в общем. Эти модульные процессы параметризованы для обеспечения возможности передачи рабочих значений во время выполнения и централизованно хранятся, чтобы они были доступны и отображались для общего использования.

Среди преимуществ модульности процессов ETL:

• Стандартизированное поведение в основных функциях, а также в периферийных задачах, таких как ведение журнала и обработка ошибок
• Уменьшите дублирующую работу в будущем развитии ETL
• Более легкие процессы изменения
• Более простое модульное тестирование
• Упрощенный обмен задачами разработки между несколькими разработчиками
• Меньшая площадь поверхности для устранения неполадок, когда что-то идет не так

Создание архитектуры ETL с использованием модульных и многократно используемых компонентов требует времени и усилий для внедрения, и, как и любая другая часть программного обеспечения, со временем будет развиваться при надлежащем уходе и питании. Работа модуляризации обычно включает четыре этапа:

• Инвентаризация общих задач. Что может быть модульным? Насколько большими или маленькими должны быть эти единицы работы?  Я не хочу упрощать работу, которая входит в этот этап, потому что решение, какие задачи можно использовать повторно, чтобы оправдать работу (и, что более важно, может быть сделано универсальным без чрезмерной сложности), требует больших усилий. Просмотр журналов прошлых выполнений, изучение возможных процессов, которые могут быть объединены, и создание прототипов — все это требуется для правильной работы.
• Построить модульный процесс. Этот этап может быть облегчен путем повторного использования некоторых зрелых компонентов существующих процессов (если они уже существуют).
• Выявление и вывод значений во время выполнения. Любое значение, которое может быть изменено (например, имя FTP-сервера или место загрузки в приведенном выше примере), должно быть задано как параметр времени выполнения, а не как жестко заданное значение.
• Стандартизация использования. Этот этап в основном включает документацию и обучение и предназначен для устранения быстрых и простых (и вызывающих технический долг) жестко закодированных шагов, смоделированных выше.

В приведенном выше кратком примере проектов есть две легко идентифицируемые возможности для модульности: загрузка файлов с FTP и перемещение файлов в архив. Поскольку эти типы операций очень распространены, и каждый из них включает в себя этапы ведения журнала для сбора некоторой информации об операции (всегда хорошая практика — см. Мой пост по разработке ведения журнала ETL в этой серии), оба они будут хорошими кандидатами для модульности. Инкапсулируя общее поведение и параметрируя значения, необходимые во время выполнения, следующий дизайн можно использовать повторно и намного проще в обслуживании.

Как показано, высокоуровневые нагрузки (процессы ETL A, B и C) блаженно не знают, что входит в загрузку с FTP или операцию архивирования файлов. Единственное, что важно для этих трех процессов — это требуемые параметры и результат каждой операции. По мере добавления новых процессов разработчики могут просто вызывать модули для загрузки по FTP и / или файлового архива по мере необходимости, без необходимости каждый раз переписывать эти фрагменты логики. Хотя этот шаблон требует дополнительной предварительной работы, усилия, необходимые для обновления модульной логики или добавления новых процессов с использованием указанной логики, намного меньше, чем поддержание множества копий одних и тех же задач ETL.

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

Вывод

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

ETL Atomicity (ETL Атомность)

ETL Atomicity (ETL Атомность). Насколько большим должен быть каждый процесс ETL?

Я до сих пор помню первый настоящий процесс ETL, который я разработал. В то время я работал в больнице, проходя серьезную реализацию системы, когда мы заменили 17-летнюю систему на основе UNIX более современным набором медицинских приложений с серверной частью SQL Server. Мне было поручено создать, протестировать и выполнить процессы ETL для этого преобразования. Несмотря на то, что я имел опыт работы с базами данных, я все еще был новичком в мире ETL и нашего предпочтительного инструмента, SSIS. Моей первой и единственной заботой было перемещение данных как единовременной операции, поэтому я поместил все в один огромный пакет служб SSIS. В этом пакете были десятки задач, которых было слишком много, чтобы их можно было разместить на одном экране, и только метаданные для этого пакета имели размер более 5 МБ.

В конце концов, монолитный процесс, который я построил, сделал то, что должен был сделать. Он был разработан для одноразового использования и больше не будет вызываться после окончательной загрузки данных в новую систему. Тем не менее, я извлек некоторые ценные уроки о возможности повторного использования и тестируемости в ходе разработки этого процесса, и в результате я полностью изменил способ, которым я строил процессы ETL с этого момента. Это тот шаблон проектирования, которым я поделюсь с вами в этой части моей серии ETL Best Practices .

ETL Atomicity

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

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

Почему ETL Atomicity?

Существует множество преимуществ для создания небольших узкопрофильных подпроцессов, а не для монолитных пакетов «все».

Опыт тестирования и отладки . Если вы когда-либо пытались выполнить модульное тестирование или отладку процесса с помощью множества движущихся частей, вы знаете, какое это может быть время. Если что-то ломается или не ведет себя должным образом, обход кода для поиска проблемной логики является излишне сложным и отнимает много времени. Разбивая нагрузку на функциональные блоки, тестирование и отладку можно выполнять индивидуально для выявления ошибок до того, как будет проведено полное интеграционное тестирование.

Техническое обслуживание . Каждый процесс ETL нужно будет пересмотреть и настроить в какой-то момент. Разделяя функции на их собственные процессы, обновлять или заменять эти поведения становится легче, потому что теперь это модульная конструкция.

Разделение обязанностей по развитию . Если вы работаете в среде с несколькими разработчиками, и у вас есть несколько сотрудников, работающих над одной и той же нагрузкой, процесс разработки будет намного проще, если каждый разработчик будет работать над своим назначенным подпроцессом, а не пытаться согласовать изменения в одном монолитном коде. файл. Как сторонние разработчики служб SSIS: если вы никогда не пытались использовать файл пакета служб SSIS, не делайте этого; это бесполезное упражнение. Разделите свою логику на несколько пакетов, если вы разрабатываете как часть команды.

Пользовательский интерфейс . Большинство инструментов ETL имеют графический интерфейс, который может стать очень занятым, когда задействовано много движущихся частей. Кроме того, многие из них (включая мой инструмент выбора, SQL Server Integration Services) выполняют проверку во время разработки, пока вы редактируете пакеты, и наличие большого количества соединений и конечных точек может замедлить этот процесс проверки. Разделение функциональных блоков работы на отдельные подпроцессы обеспечивает более удобный и отзывчивый интерфейс.

Возможность повторного использования . Как уже отмечалось, сохранение процессов ETL небольшим и сфокусированным не обязательно должно быть связано с возможностью повторного использования, но это может быть дополнительным преимуществом атомарности ETL. С более мелкими и более конкретными функциональными блоками вы сможете повторно использовать некоторые компоненты в том же процессе или даже в других процессах.

При использовании атомарного дизайна ETL вы обычно получаете больше кода. Но действительно ли это имеет значение? Как профессионалы в области данных, наша основная цель должна заключаться не в том, чтобы уменьшить объем кода, который мы пишем, а в том, чтобы написать максимально эффективный код. Если атомарный ETL-дизайн означает, что у вас на 20% больше кода (что является очень либеральной оценкой), вы в разы вернете свои затраты времени и памяти за счет более простого тестирования, более простого обслуживания и лучшего повторного использования.

Насколько маленькими должны быть эти процессы?

При проектировании атомарности ETL должна быть только одна движущаяся часть на процесс, или две, или десять? Как это часто бывает, ответ — это зависит . Я не стремлюсь к определенному размеру или количеству движущихся частей; скорее, я сосредотачиваюсь на функциональной единице работы . Все задачи или шаги в рамках одного процесса должны быть непосредственно связаны с другими. Оценивая отдельные этапы процесса, чтобы определить, какие (или группы) должны стоять самостоятельно, я задаю следующие вопросы:

• Не упростит ли это процесс тестирования, если я сам протестирую эту задачу?
• Что касается этого процесса, нужно ли мне когда-либо выполнять эту задачу самостоятельно?
• Будет ли этот процесс иметь логику после этой задачи, которая будет по-разному реагировать на успех или провал этой задачи?
• Может ли логика в этой задаче быть изменена или заменена без принудительного изменения других частей процесса?
• Может ли логика в этой задаче быть повторно использована в других частях этого процесса или других процессов?

Чем больше ответов «Да» я получу выше, тем больше вероятность того, что задача или группа задач будут преобразованы в отдельный подпроцесс.

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

• Подпроцесс для выполнения загрузки SFTP. Я хотел бы сделать это как можно более универсальным, чтобы его могли использовать другие процессы, поскольку подключение к SFTP-серверам для обмена данными довольно часто встречается в рабочих нагрузках ETL.
• Подпроцесс для извлечения архивных файлов. Опять же, поскольку это довольно часто встречается в операциях ETL, я бы сделал этот процесс модульным .
• Подпроцесс для усечения промежуточных таблиц и загрузки этих таблиц с извлеченными файлами в качестве источника. Обратите внимание, что в этом подпроцессе есть две разные задачи. Это сделано намеренно, поскольку маловероятно, что мне нужно будет усекать промежуточные таблицы без последующей их перезагрузки, и я определенно не хочу загружать в изменчивые промежуточные таблицы без предварительного их усечения.
• Подпроцесс для перемещения zip-файла в расположение архива.

Как показано, это не всегда дизайн с одной задачей на подпроцесс. Группировка задач целесообразна, когда коллекция работает вместе для выполнения единой единицы работы, и когда выполнение или тестирование одного фрагмента из этой группы не добавляет ценности.

Связывая все вместе

Имейте в виду, что разделение процессов на группы тесно связанных задач не означает, что у вас все еще не может быть одного процесса, контролирующего выполнение. В атомарном процессе ETL обычно существует процесс оркестровки, который объединяет все движущиеся части для сквозной нагрузки, обеспечивая единую точку вызова для этой нагрузки. Разница между этим шаблоном и монолитом, который я описал в начале поста, состоит в том, что этот шаблон встраивает рабочую логику (где выполняется «настоящая работа») в эти подпроцессы, а процесс оркестровщика или контроллера обрабатывает поток из одного подпроцесса. другому.

Вывод

Модульность ETL облегчает задачу разработки и поддержки процессов извлечения, преобразования и загрузки. Разбивая функциональные блоки работы на индивидуально тестируемые, заменяемые и исполняемые подпроцессы, общий механизм загрузки становится более устойчивым.

Error Handling (Обработка ошибок)

Error Handling (Обработка ошибок). Что происходит, когда что-то идет не так? В этом разделе рассматриваются шаблоны проектирования для предотвращения и управления ошибками в процессах ETL.

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

В этой части моей серии ETL Best Practices я расскажу о важности логики обработки ошибок в процессах ETL.

Fail-First Design

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

Обработка ошибок ETL

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

• Предотвращение ошибок: исправить или обойти условие ошибки, чтобы остановить процесс сбоя.
• Реакция на ошибку: когда сбой неизбежен, критически важно правильно реагировать на ошибку.

Чтобы быть понятным, управление условиями отказа не означает, что вы должны выбрать один из двух вышеуказанных подходов. Эффективные архитектуры ETL обычно включают в себя как предотвращение, так и реагирование, формируя двусторонний подход к управлению ошибками. Я расскажу о каждом из этих подходов ниже.

Предотвращение ошибок

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

• Процесс загрузки состоит из нескольких этапов, но один сбой не должен прерывать остальную нагрузку
• В некоторых частях данных существует известный недостаток, который можно исправить как часть процесса ETL
• Некоторая часть процесса ETL является нестабильной, и вам необходимо повторить попытку в случае сбоя

Первый пункт в списке выше — это наиболее распространенный сценарий, в котором предотвращение ошибок полезно. Допустим, вы выполняете операции ETL, собирая данные о розничных продажах по всему миру и в каждом часовом поясе. Для загрузки в одном часовом поясе могут быть торговые точки, данные которых еще не доступны (магазин оставался открытым поздно, задержки в сети и т. Д.). Этот сценарий не обязательно представляет ошибку, просто задержка в обработке. В этом примере бизнес-загрузка имеет смысл при загрузке доступных данных, пропуская источники, которые еще не готовы. В таком случае, как правило, допускается сбой отдельных задач без прерывания процесса ETL, а затем сбой процесса в целом после выполнения всех задач. Процесс может попытаться выполнить все задачи загрузки, завершившись с ошибкой только в случае сбоя одного или нескольких отдельных шагов.

Хотя предотвращение ошибок является полезным инструментом в вашем наборе трюков ETL, позвольте мне призвать вас не подавлять условия ошибок просто для того, чтобы заставить ваши процессы ETL успешно работать. Хотя это, как правило, имеет хорошие намерения, оно может вызвать некоторые неожиданные проблемы, если не будет сделано должным образом. То, что ошибку можно предотвратить, не означает, что она должна быть! Предотвращение ошибок часто является решением бизнес-логики, а не техническим. Прежде всего, убедитесь, что любое предотвращение или подавление ошибок решает деловую проблему под рукой.

Ответ об ошибке

Не все ошибки ETL должны быть предотвращены. Фактически, большинство бизнес-случаев поддается ошибочному реагированию, а не предотвращению. Как бы странно это ни звучало, есть смысл в том, чтобы позволить процессам ETL не работать:

• Управление зависимостями: если шаг B зависит от успеха шага A, то шаг B не должен выполняться в случае сбоя A.
• Отчет об ошибках: часто уведомления запускаются из-за ошибок. Разрешение сбоя процессов обеспечивает выполнение этих уведомлений.
• Триггеры ошибок: задачи, которые не выполняются, могут инициировать логику ответа об ошибках для дополнительных уведомлений, операций очистки и т. Д.

Именно в дизайне ответа на ошибку я свободно использую фразу, изящно терпящую неудачу, При разработке процессов, которые построены так, что они терпят неудачу, вы должны учитывать, как что-то может пойти не так, и решить, что должно произойти, когда это произойдет. Для многих процессов изящный сбой — это просто сбой без других действий. Рассмотрим пример процесса, который загружает энергозависимую промежуточную таблицу. Обычно это включает усечение этой таблицы с последующей перезагрузкой этой таблицы. Если произойдет сбой этого процесса, очистить нечего — просто исправьте недостаток и повторите последовательность усечения / перезагрузки. Однако при загрузке данных транзакций в рабочую таблицу дело обстоит иначе. Если эта транзакционная нагрузка завершится неудачей на полпути, вы получите частично загруженную целевую таблицу. Вы не можете просто перезапустить процесс, чтобы избежать дублирования транзакций. В таком случае,

В некоторых случаях можно прогнозировать сбой и реагировать соответствующим образом. Некоторые инструменты ETL, включая мой любимый такой инструмент (SSIS), включают функциональность для проверки возможных сбоев перед выполнением. В службах SSIS вы можете запустить проверку пакета без фактического выполнения указанного пакета. Хотя этот процесс проверки не обнаруживает все возможные ошибки, он проверяет некоторые общие точки ошибок. Другие этапы проверки можно выполнить вручную, например, проверить, существует ли каталог или есть ли у учетной записи выполнения разрешение на загрузку.

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

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

Сбой рано, если это возможно

При прочих равных условиях лучше потерпеть неудачу рано, чем поздно в процессе. Ранний сбой позволяет избежать ненужных накладных расходов, если весь процесс придется перезапускать в случае сбоя. Неудача раньше, чем позже, также снижает вероятность необходимости очистки данных после сбоя. Есть случаи, когда поздние неудачи неизбежны (или даже предпочтительнее). Тем не менее, для большинства сценариев загрузки ETL это правило остается верным: по возможности сбой рано .

логирование

Редко я пишу пост о ETL, в котором нет напоминания о регистрации . Нигде логирование не является более важным, чем в дизайне обработки ошибок. Если ваш процесс ETL ничего не делает после сбоя, как минимум, он должен регистрировать детали сбоя. Сбор информации о сбоях очень важен для улучшения сортировки и архитектуры. Это вдвойне верно, если ваш процесс ETL подавляет или предотвращает ошибки. Единственный механизм, который дает вам историческое понимание логики ошибок, — это хорошая подсистема журналирования. Независимо от того, используете ли вы инструменты, встроенные в ваше программное обеспечение ETL, или пишете собственные, убедитесь, что вы собираете достаточно информации для регистрации, чтобы полностью документировать любые и все сбои.

Логика ошибок тестирования

Ранее я отмечал, что логика ошибок часто является запоздалой мыслью. Это еще более верно для проверки логики ошибок. Построение тестов на основе логики предотвращения ошибок и ответов так же важно, как тестирование логики загрузки ядра. Я даже не могу вспомнить, сколько раз мне звонили, чтобы помочь с процессами ETL, чтобы выяснить, что не только сбой загрузки, но и логика ошибок тоже. Тестирование процессов загрузки является сложным, а тестирование обработки ошибок ETL еще более. Однако только правильное тестирование обнаружит недостатки в вашей логике ошибок.

Вывод

Управление ошибками в ETL должно занимать центральное место в разработке этих процессов. У хорошей стратегии ETL будут меры по предотвращению и реагированию на ошибки при правильной детализации. Благодаря хорошо спроектированной обработке ошибок ETL процессы становятся более надежными, предсказуемыми и обслуживаемыми.

Managing Bad Data (Управление неверными данными)

Managing Bad Data (Управление неверными данными). Когда обнаружены подозрительные данные, должна срабатывать система для очистки или иного реагирования по устранению несоответствующих строкам данных. В этой статье я поделюсь некоторыми шаблонами проектирования для обработки неверных данных.

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

Что такое плохие данные?

Плохой — это субъективный термин, и, соответственно, плохие данные . Следовательно, не существует единого неопровержимого определения неверных данных; она может и будет отличаться от одной организации к другой и от одного процесса ETL к другой. Тем не менее, вот общее руководство, которому я следую:

Неверные данные — это данные, происхождение или точность которых являются подозрительными, и в результате риск их использования превышает потенциальную ценность для бизнеса.

То, что считается плохими данными, будет широко варьироваться. При загрузке списка контактной информации для потенциальных потенциальных покупателей возможны пропущенные или неверные значения данных, которые, скорее всего, не являются дисквалифицирующим атрибутом. С другой стороны, при загрузке финансовых данных отсутствующее или недействительное значение для одной строки может сделать подозрительной всю загрузку данных. Точно так же происхождение данных может поставить под сомнение их значение (для любой загрузки в проверяемую систему) или может не оказать большого влияния (например, при расчете анализа настроений).

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

Последний пункт определения границ неверных данных: это не всегда двоичное решение. На самом деле, большинство таких оценок являются «успешными / неудачными», но иногда возникает необходимость получить более детальную оценку качества данных. Создавайте эти относительные оценки качества данных, только если это необходимо; каждое создаваемое вами ведение увеличивает сложность и затраты на обслуживание.

Определение гранулярности

Определение гранулярности неправильной обработки данных обычно означает выбор одного из двух вариантов: строка за строкой или нагрузка в целом.

Управление подозрительными данными построчно

Обработка подозрительных данных обычно представляет собой построчную операцию. Из этих двух шаблонов проектирования обработка некорректных данных по очереди является гораздо более распространенным и более простым подходом. Используя этот подход, процесс ETL отфильтрует каждую подозрительную строку данных на основе критериев, установленных на предыдущем этапе, а затем очистит, перенаправит или удалит (подробнее об этих параметрах позже) каждую из этих строк.

Управление данными как нагрузка «все или ничего»

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

Прекрасным примером этого является процесс ETL, загружающий записи главной книги. В таких нагрузках исключение хотя бы одной строки данных из-за проблем с качеством данных может нарушить баланс всей нагрузки. Здесь лучше вообще не загружать данные, чем иметь частичный (и, следовательно, неверный) набор данных, записанных в место назначения.

Архитектура загрузки «все или ничего» более сложна, чем их построчная обработка ошибок. Используйте этот шаблон проектирования только в том случае, если этого требуют деловые или технические потребности; если есть сомнения, обработайте ошибки или другие аномалии на уровне строк.

Управление неверными данными в ETL

Как только определение неверных данных и детализация согласованы, следующим этапом является разработка тактического подхода к управлению неверными данными в ETL.

Хотя детали обработки неверных данных будут очень техническими, всегда имейте в виду, что деловые потребности должны определять поведение. Первой и главной проблемой при обработке неверных данных всегда должно быть влияние на бизнес.

Очистить в ETL

При обнаружении неверных данных используйте процесс ETL для очистки и продолжения обработки этих данных, если это возможно. Устранение недостатков данных в полете обычно имеет наименьшее количество остаточного багажа. Подозреваемые данные, которые могут быть очищены встроенными средствами, не страдают от задержки отдельного процесса (или, что еще хуже, вмешательства человека) для выполнения очистки перед использованием. Встроенная очистка данных также делает процесс очистки данных более четким, поскольку раздвоенный путь очистки обычно сливается с органически чистыми данными перед загрузкой в ​​место назначения.

Как показано на блок-схеме выше, этот шаблон хранит заведомо исправные данные и подозрительные данные в параллельных конвейерах, объединяя их вместе после устранения недостатков. Этот шаблон предполагает гранулярность на уровне строк.

Прямая очистка данных — мой предпочтительный метод обработки подозрительных данных. Однако я не хочу подразумевать, что очистка данных — это простой процесс. Определение бизнес-правил и технических частей для обнаружения и очистки данных обычно требует значительных временных затрат, особенно когда эти бизнес-правила сложны.

Большинство систем ETL имеют встроенную логику для обработки некоторых наиболее распространенных операций очистки данных, а также интерфейсы сценариев, позволяющие вам создавать собственные решения для обеспечения качества данных. Для более сложных задач стороннее решение может быть правильным решением. Например, вы можете написать свою собственную логику проверки адресов, но создание этой логики И поддержание точной базы данных адресов, вероятно, будет стоить больше времени и денег, чем использование стороннего поставщика, уже оборудованного для таких операций. Обратите внимание на влияние на производительность и ограничения объема данных при использовании поставщика для работы с качеством данных, так как большинство из них используют облачный сервис и лицензируют свое программное обеспечение на основе объема данных.

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

• Поскольку этот процесс будет изменять данные во время полета, обязательно сохраняйте контрольный журнал очистки изменений.
• Будут ли случаи, когда данные не могут быть исправлены? Если это так, создайте предохранительный клапан для сортировки (или удаления, если необходимо) неразрешимых неверных данных.
• Поскольку каждая подозрительная строка данных будет обрабатываться индивидуально, помните о возможных узких местах производительности, если для операции очистки требуется много системных ресурсов.

сортировка

Шаблон проектирования сортировки полезен для проблем качества данных, которые не могут быть решены в оперативном режиме. Здесь подозрительные строки остаются нетронутыми и записываются в альтернативное местоположение, которое будет рассматриваться в отдельном процессе. Процесс ETL становится системой с двумя выходами, где хорошие данные отправляются в свое обычное место назначения, в то время как подозрительные данные записываются в выходной сигнал сортировки.

Хотя эта блок-схема указывает на более простую конструкцию, чем встроенная архитектура очистки, это показывает только часть решения. Редко подозрительные данные остаются в сортировке навсегда; в большинстве случаев существуют дополнительные процессы — или, возможно, даже вмешательство человека — для исправления тригифицированных данных и загрузки их в конечный пункт назначения.

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

Несколько вещей, которые следует иметь в виду при использовании вывода triage для сбора подозрительных данных:

• Обязательно тщательно протестируйте процесс (ы), которые взаимодействуют с обработанными данными. Недостаточно отправить подозрительные данные в triage, поэтому модульного тестирования вышеупомянутой архитектуры недостаточно.
• При создании тех периферийных процессов, которые очищают данные в triage, не забудьте извлечь из triage все очищенные строки и записать их в окончательный вывод. В противном случае таблица сортировки будет продолжать расти, и производительность в конечном итоге пострадает.
• Поскольку в этом шаблоне используются два (или, возможно, больше) выходных сигнала, возможно непреднамеренная потеря данных в конвейере ETL, если один из выходных сигналов не был правильно подключен. Настоятельно рекомендуется использовать аудит количества строк, чтобы убедиться, что все входящие строки данных учтены в одном из выходных данных.

Удалить

Я стесняюсь даже привести этот шаблон дизайна по причинам, которые я перечислю в ближайшее время. Однако в интересах всестороннего освещения этой темы я кратко опишу схему удаления неверных данных. Короче говоря, этот шаблон проектирования выглядит очень похоже на шаблон сортировки, описанный выше, за исключением того, что неверные данные просто отбрасываются.

Как показано на приведенной выше блок-схеме, сохраняются только хорошие данные. Строки, не прошедшие проверку качества данных, отправляются в область битов.

Положительным моментом является то, что этот шаблон дизайна отличается простотой разработки. Недостатком является то, что я не могу особо подчеркнуть серьезность этого момента, вы потеряете данные . Не только данные — вы также потеряете любой контрольный журнал, показывающий, что данные были обработаны, но отклонены. Кроме того, вы потеряете способность проверять логику управления качеством данных с использованием исторических неверных данных. В некоторых крайних случаях это может быть приемлемым. Этот шаблон проектирования следует учитывать для обработки подозрительных неверных данных только в том случае, если выполняются все следующие условия:

• Не существует практического способа устранения недостатка данных, приводящего к тому, что записи переходят в состояние ошибки
• Нет никакого смысла в том, чтобы иметь какие-либо данные в любом столбце или поле в строке данных, которые не прошли проверку качества данных
• Удаление одной или нескольких записей не влияет на достоверность или полноту импортированных данных.
• В этом наборе данных нет процессов, требующих аудита
• Нет планов по изменению критериев, определяющих хороший или плохой ряд данных.

Лично, даже если все вышеприведенные утверждения верны, я все равно буду сопротивляться простому удалению этих подозрительных строк. Я ненавижу потерять данные, даже если это специально . Если ничего другого, хранение неверных данных в таблице дампа или файле может быть полезно для проверки логики оценки качества данных.

Гибридный подход

В действительности большинство конвейеров для управления неверными данными в ETL используют объединение вышеуказанных шаблонов проектирования. Часто я вижу встроенную очистку, используемую с шаблоном сортировки, при которой данные, которые невозможно очистить, отправляются в таблицу или файл сортировки. Кроме того, в проекте ETL, состоящем из множества отдельных процессов загрузки, обработка подозрительных данных может и будет варьироваться от одной загрузки к другой.

Аудиторская проверка

Я кратко упомянул об этом ранее, но это достаточно важно повторить. При создании процесса, который управляет неверными данными, убедитесь, что вы записываете цифровой контрольный журнал при манипулировании или фильтрации данных, прежде чем загружать их в конечный пункт назначения. Эта цепочка доказательств имеет решающее значение для устранения неполадок, документирования происхождения данных и, иногда, для целей CYA.

Вывод

Управление неверными данными в ETL является требованием во многих корпоративных проектах ETL. Данные могут быть очищены в ETL, сохранены в сортировке или просто отброшены, если обнаружены недостатки. Прежде всего, помните, что обработка подозрительных данных должна отвечать потребностям бизнеса.

Get Your Email Out Of My ETL (Получите ваш адрес электронной почты из моего ETL)

Get Your Email Out Of My ETL (Получите ваш адрес электронной почты из моего ETL). Для каждой работы есть подходящий инструмент. Внедрение уведомлений по электронной почте непосредственно в процессы ETL добавляет ненужную сложность и возможные точки отказа.

Версия этого поста — я позволил моим процессам extract-transform-load делать только ETL и оставлять уведомления системе планирования, которой они принадлежат.

Получите ваш электронный адрес из моего ETL

Прежде чем читать дальше, вы должны знать, что я выздоравливающий писатель ETL. Не так много лет назад я бы включил все — и я имею в виду все — в свои процессы ETL (обычно с использованием SSIS). Даже вещи, которые на самом деле не имеют ничего общего с перемещением данных. Конечно, это включало задачи уведомления по электронной почте. Однако за прошедшие годы я усвоил очень ценный урок: для каждой работы есть подходящий инструмент . Быстрые исправления приносят быстрое облегчение, но часто за счет устойчивости и общей стоимости владения.

Начнем с рассмотрения причин, по которым вы могли бы в первую очередь включить логику уведомлений по электронной почте в процессы ETL. Безусловно, наиболее распространенной причиной является уведомление кого-либо (или группы людей), когда что-то идет не так в процессе ETL. Менее распространенные причины включают в себя необходимость уведомлений о завершении каждого процесса (плохая идея сама по себе, но я оставлю это обсуждение на другой день) или желание отправить подмножество или совокупность данных (например, количество строк или долларовая сумма) для проверки. Каждый крупный поставщик ETL включает возможности электронной почты, которые соблазнительно легко внедрить в существующие загрузки ETL. И давайте не будем ошибаться: некоторые уведомления имеют решающее значение, особенно те, которые предназначены для привлечения внимания людей, которые должны реагировать на сбои загрузки данных или аномалии. Тем не мение,

В чем проблема?

Что плохого в использовании процессов загрузки ETL для прямой отправки электронной почты? Позвольте мне сосчитать пути.

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

С некоторыми низкоуровневыми сбоями вы никогда не получите уведомление . Мой инструмент ETL — SSIS , так что вот как это будет работать: некоторая часть структуры данных источника или назначения изменяется, и пакет SSIS обнаруживает, что ему нужно обновить метаданные. Поскольку этот этап проверки выполняется до начала какой-либо реальной работы, возможно, что ни одна часть пакета — даже обработка ошибок или логика уведомлений — не будет запущена. Дерево упадет в лес, и никто его не услышит.

Это удлиняет процесс разработки и тестирования . Процессы ETL часто бывают сложными и требуют нескольких недель или месяцев. Зачем излишне загромождать процесс разработки и тестирования большим количеством движущихся частей, которые не являются основной частью перемещения данных?

Несогласованность . В самой последней статье из серии ETL Best Practices я говорил о модульности кода . Одним из преимуществ модульных процессов является последовательность. Если вы вставляете множество специальных уведомлений об исключениях в пакеты ETL, их трудно поддерживать согласованными. Конечно, у вас может быть общий процесс, подобный тому, что я описал в модульном посте, но это требует дополнительной сложности, которая является второстепенной по отношению к основной цели процесса ETL.

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

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

Лучший путь

Как я упоминал ранее, для каждой работы есть инструмент. При рассмотрении роли уведомлений по электронной почте это скорее механизм планирования, чем функция ETL. Поэтому я рекомендую всегда рассматривать ваш инструмент планирования в качестве основного средства для создания уведомлений об исключениях для нагрузок ETL. Каждый инструмент планирования предприятия, от агента SQL Server, включенного в состав SQL Server, до коммерческих продуктов, таких как Control-M или JAMS, имеет встроенные средства уведомления по электронной почте. Перенесите ваши уведомления об исключениях в любой инструмент, который планирует работу.

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

Наконец, если вы убеждены в том, что вам действительно нужно включить информацию об ошибках в уведомления по электронной почте, вы можете воспользоваться для этого своими инструментами отчетности. Например, службы отчетов SQL Server позволят вам использовать управляемые данными подписки для отправки настроенных электронных писем для отправки отфильтрованных данных журнала нужным получателям.

Вывод

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

Using ETL Staging Tables (Использование промежуточных таблиц ETL)

Using ETL Staging Tables (Использование промежуточных таблиц ETL). Часто использование промежуточных таблиц может повысить производительность и снизить сложность процессов ETL.

Большинство традиционных процессов ETL выполняют свои загрузки, используя три отдельных и последовательных процесса: извлечение с последующим преобразованием и, наконец, загрузку в место назначения. Однако для некоторых больших или сложных нагрузок использование промежуточных таблиц ETL может повысить производительность и снизить сложность.

Как часть моей продолжающейся серии по ETL передовой практике , в этой статье я буду некоторые рекомендации по использованию таблиц ETL стадирования.

Обычный трехступенчатый ETL

Процессы извлечения, преобразования и загрузки, как подразумевается в этой метке, обычно имеют следующий рабочий процесс:

1. Получить (извлечь) данные из их источника, который может быть реляционной базой данных, простым файлом или облачным хранилищем
2. Изменять и очищать (преобразовывать) данные по мере необходимости, чтобы вписаться в схему назначения и применить любые правила очистки или бизнес-правила
3. Вставьте (загрузите) преобразованные данные в место назначения, которое обычно (но не всегда) является таблицей реляционной базы данных

Этот типичный рабочий процесс предполагает, что каждый процесс ETL обрабатывает преобразование встроенно, обычно в памяти и до того, как данные попадают в место назначения. Для большинства потребностей ETL этот шаблон работает хорошо. Каждый инструмент ETL корпоративного класса построен со сложными инструментами преобразования, способными выполнять многие из этих общих задач очистки, дедупликации и преобразования. Этот трехэтапный процесс перемещения и манипулирования данными поддается простоте, а при прочих равных условиях чем проще, тем лучше.

Однако есть случаи, когда простое извлечение, преобразование и загрузка не подходят. Среди этих потенциальных случаев:

• Для каждой загружаемой строки требуется что-то из одной или нескольких других строк в том же наборе данных (например, определение порядка или группировки или промежуточного итога)
• Исходные данные используются для обновления (а не для вставки в) назначения
• Процесс ETL представляет собой инкрементную нагрузку, но объем данных является достаточно значительным, так что сравнение строк за строкой на этапе преобразования неэффективно
• Преобразование данных требует нескольких шагов, и вывод одного шага преобразования становится вводом другого

Хотя обычно все это можно выполнить с помощью одного этапа преобразования в процессе, это может привести к снижению производительности или излишней сложности. Я сторонник использования правильного инструмента для работы, и часто лучший способ обработать груз — это позволить базе данных назначения выполнить некоторые тяжелые работы.

Использование промежуточных таблиц ETL

Когда объем или детализация процесса преобразования приводит к плохой работе процессов ETL, рассмотрите возможность использования промежуточной таблицы в базе данных назначения в качестве средства для обработки результатов промежуточных данных. Промежуточные таблицы обычно рассматриваются как изменчивые таблицы, то есть они очищаются и перезагружаются каждый раз без сохранения результатов от одного выполнения к другому. Промежуточные таблицы следует использовать только для промежуточных результатов, а не для постоянного хранения.

При использовании схемы загрузки с промежуточными таблицами поток ETL выглядит примерно так:

1. Удалить существующие данные в промежуточных таблицах
2. Извлечь данные из источника
3. Загрузите эти исходные данные в промежуточные таблицы
4. Выполните реляционные обновления (обычно используя T-SQL, PL / SQL или другой язык, специфичный для вашей СУБД), чтобы очистить или применить бизнес-правила к данным, повторяя этот этап преобразования по мере необходимости
5. Загрузите преобразованные данные из промежуточной таблицы (таблиц) в окончательную таблицу (таблицы) назначения

Этот шаблон проектирования нагрузки имеет больше шагов, чем традиционный процесс ETL, но он также обеспечивает дополнительную гибкость. Загрузив данные сначала в промежуточные таблицы, вы сможете использовать ядро ​​базы данных для вещей, которые уже хорошо работают. Например, объединение двух наборов данных вместе для целей проверки или поиска может быть выполнено в большинстве инструментов ETL, но это тип задач, который механизм базы данных выполняет исключительно хорошо. То же самое с выполнением операций сортировки и агрегирования; Инструменты ETL могут делать эти вещи, но в большинстве случаев ядро ​​базы данных делает это тоже, но гораздо быстрее.

Варианты промежуточных столов

При использовании промежуточных таблиц для сортировки данных вы включаете поведения СУБД, которые, вероятно, недоступны при обычном преобразовании ETL. Например, вы можете создавать индексы для промежуточных таблиц, чтобы повысить производительность последующей загрузки в постоянные таблицы. Вы можете запустить несколько преобразований для одного и того же набора данных, не сохраняя их в памяти на время этих преобразований, что может снизить влияние на производительность.

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

Кроме того, для некоторых крайних случаев я использовал шаблон, который имеет несколько слоев промежуточных таблиц, и первая промежуточная таблица используется для загрузки второй промежуточной таблицы. Это шаблон проектирования, которым я редко пользуюсь, но он пригодился в тех случаях, когда форма или структура данных должна была существенно измениться в процессе загрузки.

Это все еще ETL?

Те, кто педантичен по поводу терминологии (в эту группу часто входит и я), захотят знать: при использовании этого сценария постановки процесса этот процесс все еще называется ETL? Как правило, вы увидите этот процесс, называемый ELT — извлечение, загрузка и преобразование — потому что загрузка до места назначения выполняется до того, как произойдет преобразование. Я видел много вариантов этого, включая ELTL (извлечение, загрузка, преобразование, загрузка). Тем не менее, я склонен использовать ETL в качестве широкой метки, которая определяет получение данных из некоторого источника, некоторую меру преобразования по пути, сопровождаемую загрузкой в ​​конечный пункт назначения. Семантически я считаю ELT и ELTL специфическими шаблонами проектирования в широкой категории ETL.

Также имейте в виду, что использование промежуточных таблиц должно оцениваться для каждого процесса отдельно. Промежуточная архитектура ETL является одним из нескольких шаблонов проектирования и не идеально подходит для всех нагрузок. Любая зрелая инфраструктура ETL будет иметь смесь обычных ETL, поэтапных ETL и других вариантов в зависимости от специфики каждой нагрузки.

Советы по использованию промежуточных таблиц ETL

Когда вы решите использовать промежуточные таблицы в процессах ETL, вот несколько соображений, о которых следует помнить:

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

Используйте постоянные промежуточные таблицы, а не временные таблицы . Основные поставщики реляционных баз данных позволяют создавать временные таблицы, которые существуют только на время соединения. Обычно я рекомендую избегать их, потому что запрос промежуточных результатов в этих таблицах (обычно для целей отладки) может оказаться невозможным вне рамок процесса ETL. Кроме того, некоторые инструменты ETL, включая службы интеграции SQL Server, могут сталкиваться с ошибками при попытке выполнить проверку метаданных по таблицам, которые еще не существуют.

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

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

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

Правильно обрабатывать данные . Если ваши процессы ETL созданы для отслеживания происхождения данных , убедитесь, что ваши промежуточные таблицы ETL настроены для поддержки этого. Линия данных предоставляет цепочку доказательств от источника до конечного пункта назначения, обычно на уровне строк. Если вы отслеживаете происхождение данных, вам может потребоваться добавить один или два столбца в промежуточную таблицу, чтобы правильно отследить это.

Вывод

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

Secure Your Data Prep Area (Защитите свою область подготовки данных)

Secure Your Data Prep Area (Защитите свою область подготовки данных). Staging или Landing area обрабатываемых в настоящее время данных не должна быть доступна потребителям данных. В противном случае вы можете получить неверные данные, противоречивую аналитику или потенциальные угрозы безопасности.

Я много лет строил процессы ETL, и я узнал две универсальные истины: подготовка данных грязная, и вы всегда должны защищать свою область подготовки данных. Область подготовки данных очень похожа на коммерческую кухню и так же, как клиенты не допускаются на кухню, поэтому следует избегать доступа потребителей к структурам данных в процессе.

Что такое область подготовки данных?

Прежде всего, давайте определимся с областью подготовки данных. Подготовка данных (prep) — это обычная фаза операций извлечения, преобразования и загрузки ( ETL ), в которой данные временно записываются для очистки, дедупликации, изменения формы или других изменений данных. Также иногда называемый областью посадки или промежуточной области, это общий шаблон проектирования при перемещении данных из хранилища данных, оптимизированных для оперативной обработки транзакций ( OLTP ), в модель данных, более удобную для аналитики или отчетности.

Область подготовки данных действительно очень похожа на кухню ресторана: иногда она хаотична, не удобна для потребителей и существует законный риск потребления полуфабрикатов.

Когда клиенты бродят по кухне

Несмотря на свое предназначение, потребители данных нередко имеют доступ к области подготовки данных. И я понял — иногда удобно позволить пользователям возиться с необработанными данными, особенно с навыками Excel на уровне мастера. Однако при открытии области подготовки данных для конечных пользователей существуют ощутимые риски:

• Данные находятся в промежуточном состоянии . По определению область подготовки или подготовки данных предназначена для временного хранения текущих операций с данными. Предоставление потребителям данных доступа к этим данным сродни тому, чтобы подавать им частично приготовленную еду. Средне-редкая курица, кто-нибудь?
• Нет единого источника правды . Наихудший возможный результат любого перемещения или преобразования данных состоит в том, что существует несколько возможных источников данных, дающих ответы на одни и те же вопросы. Если область подготовки данных является временной остановкой на пути к хранилищу данных или ODS, предоставление доступа к этой промежуточной станции практически гарантирует, что содержащиеся в ней данные будут конкурировать с полностью обработанными и проверенными данными в DW или ODS.
• Доступ пользователя может помешать подготовке данных . Если пользователи выполняют дорогостоящие запросы во время выполнения процессов ETL, производительность обоих процессов может снизиться. В области подготовки данных процессы ETL должны иметь приоритет.
• Возможные угрозы безопасности . Хотя это не должно быть так, область подготовки данных иногда не получает такой же уровень контроля безопасности, как хранилище данных или другие структуры, ориентированные на пользователя. Если пользователи обращаются к этому временному хранилищу данных напрямую, они могут случайно получить доступ, которого у них обычно не должно быть.

Защитите свою область подготовки данных!

Хотя это требует определенной институциональной дисциплины, я настоятельно рекомендую ограничить доступ пользователей к вашей области подготовки данных. Это помогает устранить некоторые риски получения плохих или противоречивых результатов и сохраняет эту зону посадки данных в соответствии с ее назначением.

Сообщение ETL Best Practices. ETL Design Patterns. Что такое ETL? появились сначала на Python 3 | Data Science | Нейронные сети | AI - Искусственный Интеллект.

В повседневной обработке данных для проектов машинного обучения и data science библиотека Python Pandas является одной из наиболее часто используемых.

shift() — функция Python Pandas

Предположим, вы столкнулись с ситуацией, когда вам нужно сместить все строки в DataFrame или использовать цену акций предыдущего дня в DataFrame. Может быть, мы хотим построить среднюю температуру за последние три дня в наборе данных.

Shift() будет идеальным способом для достижения всех этих целей.

Функция Pandas Shift(), сдвигает индекс на желаемое количество периодов. Эта функция принимает скалярный параметр, называемый периодом, который представляет количество сдвигов для желаемой оси. Эта функция полезна при работе с данными временных рядов. Мы можем использовать fill_value для заполнения за пределами граничных значений.

import pandas as pd
import numpy as np
df = pd.DataFrame({'DATE': [1, 2, 3, 4, 5],
                   'VOLUME': [100, 200, 300,400,500],
                   'PRICE': [214, 234, 253,272,291]})
print(df)

===РЕЗУЛЬТАТ===
    DATE  VOLUME  PRICE
0     1     100    214
1     2     200    234
2     3     300    253
3     4     400    272
4     5     500    291

print(df.shift(1))

===РЕЗУЛЬТАТ===
DATE  VOLUME  PRICE
0   NaN     NaN    NaN
1   1.0   100.0  214.0
2   2.0   200.0  234.0
3   3.0   300.0  253.0
4   4.0   400.0  272.0

# with fill_Value = 0
print(df.shift(1,fill_value=0))

===РЕЗУЛЬТАТ===
DATE  VOLUME  PRICE
0     0       0      0
1     1     100    214
2     2     200    234
3     3     300    253
4     4     400    272

Теперь, если нам нужно получить цену акций предыдущего дня в виде нового столбца, мы можем использовать сдвиг с помощью функции shift():

df['PREV_DAY_PRICE'] = df['PRICE'].shift(1,fill_value=0)
print(df)

===Результат===
DATE  VOLUME  PRICE  PREV_DAY_PRICE
0     1     100    214               0
1     2     200    234             214
2     3     300    253             234
3     4     400    272             253
4     5     500    291             272

Мы можем легко рассчитать среднюю цену акций за последние три дня, как показано ниже, и создать новый столбец функций.

df['LAST_3_DAYS_AVE_PRICE'] = (df['PRICE'].shift(1,fill_value=0) + 
                               df['PRICE'].shift(2,fill_value=0) + 
                               df['PRICE'].shift(3,fill_value=0))/3

Теперь DataFrame станет таким:

DATE  VOLUME  PRICE     LAST_3_DAYS_AVE_PRICE
0     1     100    214               0.000000
1     2     200    234              71.333333
2     3     300    253             149.333333
3     4     400    272             233.666667
4     5     500    291             253.000000

Мы также можем сдвигаться вперед, чтобы получить значение из следующего временного периода или следующего значения в ряду (не обязательно это должен быть период).

df['TOMORROW_PRICE'] = df['PRICE'].shift(-1,fill_value=0)

Теперь фрейм данных будет:

DATE  VOLUME  PRICE     TOMORROW_PRICE
0     1     100    214             234
1     2     200    234             253
2     3     300    253             272
3     4     400    272             291
4     5     500    291               0

Более подробную информацию о параметрах и других настройках см. в документации Pandas.

value_counts() — функция Python Pandas

Функция Pandas value_counts() возвращает объект, содержащий количество уникальных значений. Полученный объект можно отсортировать в порядке убывания или в порядке возрастания, включить NA или исключить NA посредством управления параметрами. Эта функция может использоваться с индексами в DataFrames или Pandas Series.

a = pd.Index([3,3,4,2,1,3, 1, 2, 3, 4, np.nan,4,6,7])
print(a.value_counts())

===РЕЗУЛЬТАТ===
3.0    4
4.0    3
1.0    2
2.0    2
7.0    1
6.0    1
dtype: int64

Ниже приведен пример Series.

#In
b = pd.Series(['ab','bc','cd',1,'cd','cd','bc','ab','bc',1,2,3,2,3,np.nan,1,np.nan])
b.value_counts()

#Out
bc    3
cd    3
1     3
3     2
ab    2
2     2
dtype: int64

Опция Bin может использоваться вместо подсчета уникальных значений значений, разделив индекс на указанное количество полуоткрытых Bins.

#In
a = pd.Index([3,3,4,2,1,3, 1, 2, 3, 4, np.nan,4,6,7])
a.value_counts(bins=4)

#Out
(2.5, 4.0]      7
(0.993, 2.5]    4
(5.5, 7.0]      2
(4.0, 5.5]      0
dtype: int64

Более подробную информацию о параметрах и других настройках см. в документации Pandas.

mask() — функция Python Pandas

Метод mask() является применением условия if-then для каждого элемента Series или DataFrame. Если Condition равно True, тогда он использует значение из Other (значение по умолчанию — NaN), в противном случае будет сохранено исходное значение. Этот метод mask() очень похож на where().

Ниже приведен DataFrame, в котором мы хотим изменить знак всех элементов, которые делятся на два без остатка.

Этого легко можно достигнуть с помощью функции mask():

df = pd.DataFrame(np.arange(15).reshape(-1, 3), columns=['A', 'B','C'])
print(df)

#Out
    A   B   C
0   0   1   2
1   3   4   5
2   6   7   8
3   9  10  11
4  12  13  14

#mask operation to check if element is divided by 2 without any remainder. If match change the sign of the element as original
df.mask(df % 2 == 0,-df)

#Out
A   B   C
0   0   1  -2
1   3  -4   5
2  -6   7  -8
3   9 -10  11
4 -12  13 -14

Более подробную информацию о параметрах и других настройках см. в документации Pandas mask.

nlargest() — функция Python Pandas

Во многих случаях мы сталкиваемся с ситуациями, когда нам нужно найти 3 верхних (top) или 5 нижних (bottom) значений для Series или DataFrame (например, трех лучших учеников с самыми высокими показателями с их совокупным баллом или трех худших кандидатов с общим количеством голосов, полученных на выборах).
Функции Python Pandas nlargest() и nsmallest() — лучший способ для такой обработки данных.
В приведенном ниже примере показаны три самых больших значения из DataFrame из 10 наблюдений.

import pandas as pd
import numpy as np
df = pd.DataFrame({'HEIGHT': [170,78,99,160,160,130,155,70,70,20],
                   'WEIGHT': [50,60,70,80,90,90,90,50,60,70]},
                   index=['A','B','C','D','E','F','G','H','I','J'])
print(df)

HEIGHT  WEIGHT
A     170      50
B      78      60
C      99      70
D     160      80
E     160      90
F     130      90
G     155      90
H      70      50
I      70      60
J      20      70

dfl = df.nlargest(3,'HEIGHT')
print(dfl)

HEIGHT  WEIGHT
A     170      50
D     160      80
E     160      90

Если есть связь, то есть несколько вариантов, которые можно разрешить с помощью «first», «last», «all» (по умолчанию «first»). Сохраняйте все случаи. Мы попытаемся найти две самые большие высоты в примерах ниже.

dfl = df.nlargest(2,'HEIGHT',keep='all')
print(dfl)

HEIGHT  WEIGHT
A     170      50
D     160      80
E     160      90

Сохраните последнее вхождение.

dfl = df.nlargest(2,'HEIGHT',keep='last')
print(dfl)

HEIGHT  WEIGHT
A     170      50
E     160      90

Сохраните первое вхождение.

dfl = df.nlargest(2,'HEIGHT',keep='first')
print(dfl)

HEIGHT  WEIGHT
A     170      50
D     160      80

Более подробную информацию о параметрах и других настройках см. в документации Pandas nlargest().

nsmallest() — функция Python Pandas

nsmallest() также работает аналогичным образом, но с учетом самого маленького фильтра. Обратитесь к примеру ниже, в котором осуществляется поиск двух наименьших веса.

import pandas as pd
import numpy as np
df = pd.DataFrame({'HEIGHT': [170,78,99,160,160,130,155,70,70,20],
                   'WEIGHT': [50,60,70,80,90,90,90,50,60,70]},
                   index=['A','B','C','D','E','F','G','H','I','J'])
print(df)

HEIGHT  WEIGHT
A     170      50
B      78      60
C      99      70
D     160      80
E     160      90
F     130      90
G     155      90
H      70      50
I      70      60
J      20      70

dfs = df.nsmallest(3,'WEIGHT')
print(dfs)

HEIGHT  WEIGHT
A     170      50
H      70      50
B      78      60

Более подробную информацию о параметрах и других настройках см. в документации Pandas nsmallest.

Сообщение 5 Полезных функций Python Pandas для Data Science появились сначала на Python 3 | Data Science | Нейронные сети | AI - Искусственный Интеллект.

Введение. Почему в сфере работы с данными важно уделять внимание очистке данных и качеству данных?

Независимо от вашего опыта работы с данными и построения отчетности — плохие данные практически всегда приводят к неверным решениям.

Независимо от класса информационных систем, профессиональности специалистов по работе с данными, всегда выполняется условие:

Мусор на входе => мусор на выходе.

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

Например, как вводятся накладные, как разносятся накладные по платежкам, как выставляются счета. Все ли взаимосвязано для расчета дебиторской задолженности в автоматическом режиме и т.д.

За все это как раз и отвечают бизнес-процессы. Если компания маленькая, то все можно собрать в ручном режиме и бизнес-процессы (точнее их отсутствие) не оказывают большого влияния на бизнес. Но для среднего и крупного бизнеса бизнес-процессы по занесению и ведению информации — очень критичный вид деятельности.

Для любого специалиста по работе с данными очень важным «параметром деятельности» является авторитет данных, заработать который зачастую не так-то просто, а вот потерять его можно очень быстро.
Если Вы на основе грязных данных разработаете отчеты, а потом скажете своей компании сделать что-то с этими результатами, которые окажутся неверными, то у Вас будет много неприятностей!

Неверные или противоречивые данные приводят к ложным выводам. То, насколько хорошо вы очищаете и понимаете данные, оказывает большое влияние на качество результатов.

Зачастую простой алгоритм может превзойти сложный алгоритм только потому, что ему были предоставлены более качественные данные.

Качество данных превосходит модные алгоритмы.

Что это означает качество данных? Каковы показатели качества данных?

Прежде чем предпринимать какие-либо действия, важно понять Вашу цель. Что Вы пытаетесь достичь, куда Вы хотите попасть в конце пути?

Качество данных — Data Quality (Validity, Accuracy, Completeness, Consistency, Uniformity)

Существует много определений качества данных, в общем, качество данных — это оценка того, насколько данные пригодны для использования и соответствуют его контексту обслуживания. Многие факторы помогают измерять качество данных, такие как: Согласованность данных, Точность данных, Уникальность данных, Полнота данных, Своевременность данных, Доступность и т.д.

Достоверность данных — Validity

Степень, в которой данные соответствуют определенным бизнес-правилам или ограничениям.

• Ограничения типа данных (Data-Type Constraints): значения в определенном столбце должны иметь определенный тип данных, например, логическое, числовое, формат даты и т.д.
• Ограничения диапазона (Range Constraints): как правило, числа или даты должны попадать в определенный диапазон.
• Обязательные ограничения (Mandatory Constraints): некоторые столбцы не могут быть пустыми.
• Ограничения уникальности (Unique Constraints): поле или комбинация полей должны быть уникальными в наборе данных.
• Ограничения Set-Membership: значения столбца происходят из набора дискретных значений, например, пол человека может быть «мужской» или «женский». Т.е. фиксированный, редко изменяемый набор значений (или никогда не изменяющийся).
• Ограничения внешнего ключа: как и в реляционных базах данных, столбец внешнего ключа не может иметь значение, которого нет в указанном первичном ключе.
• Шаблоны регулярных выражений: текстовые поля, которые должны быть в определенном шаблоне. Например, для телефонных номеров может потребоваться шаблон (999) 999–9999.
• Проверка между полями (Cross-field validation): должны выполняться определенные условия, охватывающие несколько полей. Например, дата выписки пациента из больницы не может быть раньше даты госпитализации.

Точность — Accuracy

Степень, в которой данные близки к истинным значениям.

Хотя определение всех возможных допустимых значений позволяет легко обнаружить недействительные значения, это не означает, что они являются точными.

Действительный почтовый адрес не может существовать на самом деле. А действительный цвет глаз человека, скажем, синий, может быть действительным, но не соответствовать реальности.

Еще одна вещь, которую следует отметить, это разница между достоверностью и точностью. Сказать, что вы живете на земле, на самом деле правда. Но не точно. Где на земле? Точнее сказать, что вы живете по определенному адресу.

Завершенность — Completeness

Степень, в которой все необходимые данные известны.

Отсутствие данных случается по разным причинам. Можно смягчить эту проблему, по возможности, задавая вопрос первоисточнику, скажем, повторное интервьюирование человека.

Скорее всего, субъект либо даст другой ответ, либо ответ будет трудно снова найти.

Консистенция — Consistency

Степень соответствия данных в одном наборе данных или в нескольких наборах данных.

Несоответствие возникает, когда два значения в наборе данных противоречат друг другу.

Допустимый возраст, скажем, 10, может не совпадать с семейным положением, скажем, в разводе. Клиент записывается в две разные таблицы с двумя разными адресами.

Какой из них является правдой?

Единообразие — Uniformity

Степень, в которой данные указываются с использованием одной и той же единицы измерения.

Вес может быть записан в фунтах или килограммах. Дата может соответствовать формату США или европейскому формату. Валюта иногда в долларах, а иногда в иенах.

И поэтому данные должны быть преобразованы в одну единицу измерения.

Рабочий процесс — Workflow (inspection, cleaning, verifying, reporting)

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

1. Проверка (Inspection): обнаружение неожиданных, неправильных и противоречивых данных.
2. Очистка (Cleaning): исправить или удалить обнаруженные аномалии.
3. Проверка (Verifying): После очистки результаты проверяются для проверки правильности.
4. Отчетность (Reporting): записывается отчет об изменениях и качестве сохраненных данных.

То, что вы видите как последовательный процесс, на самом деле является итеративным, бесконечным процессом. Можно переходить от проверки к проверке, когда обнаруживаются новые недостатки в данных.

Проверка — Inspection

Проверка данных занимает много времени и требует использования многих методов для исследования основных данных для обнаружения ошибок. Вот некоторые из них:

Профилирование данных — Data profiling

Сводные статистические данные о данных, которые называются профилирование данных, очень полезно, чтобы дать общее представление о качестве данных.

Например, проверьте, соответствует ли определенный столбец определенным стандартам или образцу. Столбец данных записан в виде строки или числа?

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

Зрительные — Visualizations

Анализируя и визуализируя данные с использованием статистических методов, таких как среднее значение, стандартное отклонение, диапазон или квантили, можно найти значения, которые являются неожиданными и, наиболее вероятно, ошибочными.

Например, визуализируя средний доход по странам, можно увидеть, что есть некоторые выбросы. 

В некоторых странах есть люди, которые зарабатывают намного больше, чем кто-либо другой. Эти выбросы заслуживают изучения, но не обязательно, это это неверные данные.

Пакеты программ — Software packages

Несколько пакетов программного обеспечения или библиотек, доступных на вашем языке, позволят вам указать ограничения и проверить данные на предмет нарушения этих ограничений.

Более того, они могут не только создать отчет о том, какие правила были нарушены и сколько раз, но также создать график того, какие столбцы связаны с какими правилами.

Возраст, например, не может быть отрицательным, а значит и рост. Другие правила могут включать несколько столбцов в одной строке или в наборах данных.

Очистка — Cleaning

Очистка данных включает различные методы, основанные на проблемах и типах данных. Различные методы могут быть применены с каждым атрибутом данных, но имеют свои собственные особенности применения.

В целом, неверные данные либо удаляются, исправляются, либо присваиваются.

Нерелевантные данные — Irrelevant data

Нерелевантные данные — это те, которые на самом деле не нужны и не вписываются в контекст проблемы, которую мы пытаемся решить.

Например, если бы мы анализировали данные об общем состоянии здоровья населения, номер телефона не был бы необходим.

Точно так же, если бы вы были заинтересованы только в одной конкретной стране, вы не хотели бы включать в набор данных все другие страны. Или изучать только тех пациентов, которые ходили на операцию, мы бы не включали всех пациентов клиники.

Только если вы уверены, что часть данных не важна, вы можете удалить ее. В противном случае изучите матрицу корреляции между атрибутами объекта.

И даже если вы не заметили никакой корреляции, вы должны спросить кого-то, кто является экспертом в области. Вы никогда не знаете, что функция, которая кажется неактуальной, может быть очень актуальной с точки зрения предметной области, например с клинической точки зрения.

Дубликаты — Duplicates

Дубликаты — это значения, которые повторяются в вашем наборе данных (повторяться могут как транзакции, так и сущности в различных справочниках).

Дублирование часто случается, когда, например,

• Данные объединены из разных источников
• Пользователь может дважды нажать кнопку «Отправить», думая, что форма фактически не была отправлена.
• Запрос на онлайн-бронирование был подан дважды, исправляя неверную информацию, которая была введена случайно в первый раз.

Распространенным симптомом является случай, когда два пользователя имеют одинаковый идентификационный номер. Или одна и та же статья была отменена дважды.

И поэтому они просто должны быть удалены.

Тип преобразования — Type conversion

Убедитесь, что числа хранятся в виде числовых типов данных. Дата должна храниться в виде объекта даты или метки времени Unix (количество секунд) и т.д.

Категориальные значения могут быть преобразованы в/из чисел при необходимости.

Это можно быстро определить, взглянув на типы данных каждого столбца в сводке (мы обсуждали выше).

Предупреждение: значения, которые нельзя преобразовать в указанный тип, следует преобразовать в значение NA (или любое другое) с отображением предупреждения. Это указывает на неправильное значение, которое должно быть исправлено.

Синтаксические ошибки — Syntax errors

Удалить пробелы: следует удалить лишние пробелы в начале или конце строки.

"   hello world  " => "hello world"

Строки заполнения: строки могут быть дополнены пробелами или другими символами до определенной ширины. Например, некоторые числовые коды часто представлены с предшествующими нулями, чтобы они всегда имели одинаковое количество цифр.

313 => 000313 (6 digits)

Исправьте опечатки: строки могут быть введены разными способами, и неудивительно, что могут быть ошибки.

Gender
m
Male
fem.
FemalE
Femle

Считается, что эта категориальная переменная имеет 5 разных классов, а не 2, как ожидалось: мужской и женский, поскольку каждое значение различно.

Bar plot полезно визуализировать все уникальные значения. Можно заметить, что некоторые значения различны, но означают одно и то же, то есть «information_technology» и «IT». Или, возможно, разница только в заглавных буквах, то есть в «other» и «Other».

Следовательно, наша обязанность состоит в том, чтобы по приведенным выше данным определить, является ли каждое значение мужским или женским. Как мы можем сделать это?.

Первое решение состоит в том, чтобы вручную сопоставить каждое значение с «мужской» или «женский».

dataframe['gender'].map({'m': 'male', fem.': 'female', ...})

Второе решение — использовать сопоставление с образцом. Например, мы можем искать вхождение m или M в поле в начале строки.

re.sub (r "\ ^ m \ $", ' Male ', ' male ', flags = re. IGNORECASE )

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

Gender   male  female
m         3      5
Male      1      3
fem.      5      3
FemalE    3      2
Femle     3      1

Кроме того, если у вас есть переменная, такая как название города, вы подозреваете, что опечатки или похожие строки должны обрабатываться одинаково. 

Например, “lisbon” можно ввести как “lisboa”, “lisbona”, “Lisbon”, и т.д.

City     Distance from "lisbon"
lisbon       0
lisboa       1
Lisbon       1
lisbona      2
london       3
...

Если это так, то мы должны заменить все значения, которые означают одно и то же, на одно уникальное значение. В этом случае замените первые 4 строки на «lisbon».

Следите за значениями, такими как «0», «Не применимо», «NA», «None», «Null» или «INF», они могут означать одно и то же: значение отсутствует.

rand = np.random.randint(average_age - 2*std_age, average_age + 2*std_age, size = count_nan_age)
dataframe["age"][np.isnan(dataframe["age"])] = rand

city       rent  transportation food  total
libson     500        20         40    560
paris      750        40         60    850

pip install pandas

pip install pandas_profiling

import pandas as pd
import pandas_profiling
pd.read_csv('https://raw.githubusercontent.com/mwaskom/seaborn-data/master/planets.csv').profile_report()

Сообщение Очистка данных. Качество данных. Руководство по Data Cleaning появились сначала на Python 3 | Data Science | Нейронные сети | AI - Искусственный Интеллект.

Вводная часть по Python 3 Tutorial — Data Wrangling

Биткойн и криптовалюта сейчас в тренде… но как специалисты по данным, мы эмпиристы, верно? Мы не хотим просто поверить на слово другим… мы хотим посмотреть на данные из первых рук! В этом уроке будут описаны общие и мощные методы обработки данных в Python.

Python 3 Tutorial — Data Wrangling

Вообще говоря, обработка данных (Data Wrangling) — это процесс преобразования, агрегирования, разделения или иного преобразования ваших данных из одного формата в более подходящий.

Например, мы хотим провести пошаговый анализ очень элементарной торговой стратегии, которая выглядит следующим образом:

1. В начале каждого месяца мы покупаем криптовалюту, которая имела наибольший прирост цены за последние 7, 14, 21 или 28 дней. Мы хотим оценить каждое из этих временных окон.
2. Затем мы держим ровно 7 дней и продаем нашу позицию. Обратите внимание: это целенаправленно простая стратегия, которая предназначена только для иллюстративных целей.

Как мы будем оценивать эту стратегию?

Это хороший вопрос для демонстрации методов обработки данных, потому что вся тяжелая работа заключается в преобразовании вашего набора данных в правильный формат. Когда у вас есть соответствующая аналитическая базовая таблица (analytical base table, ABT), ответить на вопрос становится просто.

Чем это руководство не является:

Это не руководство по инвестиционным или торговым стратегиям, и не призыв за или против торговли криптовалютами. Потенциальные инвесторы должны самостоятельно формировать свои взгляды, но в этом руководстве будут представлены инструменты для этого.

Опять же, основное внимание в этом руководстве уделяется методам обработки данных и возможности преобразования необработанных наборов данных в форматы, которые помогут вам ответить на интересные вопросы.

Быстрый совет, прежде чем мы начнем:

Этот учебник предназначен для быстрого ознакомления, и он не будет охватывать ни одну тему слишком подробно. Ознакомьтесь дополнительно с Tutorial по библиотеке Pandas.

Содержание учебника по обработке данных Python — Data Wrangling Tutorial

Вот шаги, которые мы пройдем в рамках нашего анализа:

1. Настройка среды.
2. Импорт библиотек и наборов данных.
3. Первичное знакомство с данными.
4. Фильтр нежелательных наблюдений (подмножеств).
5. Вращение набора данных — Pivot the dataset.
6. Сдвиг развернутого набора данных — Shift the pivoted dataset.
7. Melt сдвинутого набора данных — Melt the shifted dataset.
8. Уменьшение-объединение (Reduce-merge) melted data.
9. Агрегация данных с помощью group-by.

Шаг 1. Настройка среды программирования Python

Сначала убедитесь, что на вашем компьютере установлено ПО:

• Python 2.7+ или Python 3
• Pandas
• Jupyter Notebook (необязательно, но рекомендуется)

Мы настоятельно рекомендуем установить дистрибутив Anaconda, который поставляется со всеми этими пакетами. Просто следуйте инструкциям на этой странице загрузки.

Jupyter Notebook – это бесплатная интерактивная оболочка для языка программирования Python, позволяющая объединить код, изображения, комментарии, формулы и графики/диаграммы.

После установки Anaconda запустите Jupyter Notebook (Anaconda3):

Откроется окно в браузере. В нем создайте новое окно Python3:

Откроется новая вкладка, на ней Вы можете поменять название документа.

Интерфейс Jupyter Notebook

В Jupyter Notebook есть два важных термина: cells (ячейки) и kernels (ядра) являются ключом как к пониманию Jupyter.

• kernel (Ядро) – это «вычислительный движок», который выполняет код, содержащийся в документе Notebook.
• cell (Ячейка) – это контейнер для текста, который будет отображаться в Notebook, или код, который будет выполняться ядром записной книжки.

Запуск и прерывание выполнения кода в Jupyter Notebook

Если ваша программа зависла, то можно прервать ее выполнение выбрав на панели меню пункт Kernel -> Interrupt.

Для добавления новой ячейки используйте Insert->Insert Cell Above и Insert->Insert Cell Below.

Для запуска ячейки используете команды из меню Cell, либо следующие сочетания клавиш:

• Ctrl+Enter – выполнить содержимое ячейки.
• Shift+Enter – выполнить содержимое ячейки и перейти на ячейку ниже.
• Alt+Enter – выполнить содержимое ячейки и вставить новую ячейку ниже.

Шаг 2: Импортируем библиотеки и загружаем набор данных

Сначала мы импортируем библиотеку Pandas (лучшая библиотека для обработки реляционных наборов данных в табличном формате).
Библиотеке Pandas мы дадим alias (псевдоним). Позже мы сможем вызывать библиотеку с помощью pd.

# Pandas for managing datasets
import pandas as pd

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

# Display floats with 2 decimal places
pd.options.display.float_format = '{:,.2f}'.format
 
# Expand display limits
pd.options.display.max_rows = 200
pd.options.display.max_columns = 100

В этом уроке мы будем использовать набор данных о ценах Brave New Coin и распространяемый в Quandl. Полная версия отслеживает индексы цен для 1900+ фиат-крипто трейдинговых пар, но требует премиальной подписки, поэтому мы предоставили небольшую выборку с небольшим количеством криптовалют.

Чтобы использовать набор данных в своей программе скачайте файл BNC2_sample.csv.

После того, как вы скачали набор данных, разместите его в том же каталоге, что и сохраненный блокнот.

Набор данных можно загрузить как непосредственно в директорию на диске в windows:

Также можно загрузить файл из интерфейса Jupyter:

Если Вы все правильно сделали, то файл разместится рядом с вашим проектом:

Далее запускаем следующий код, чтобы прочитать набор данных из csv файла и создать DataFrame (набор данных библиотеки Pandas). Далее выводим примеры записей.

# Read BNC2 sample dataset
df = pd.read_csv('BNC2_sample.csv',
                 names=['Code', 'Date', 'Open', 'High', 'Low', 
                        'Close', 'Volume', 'VWAP', 'TWAP'])
 
# Display first 5 observations
df.head()

Запускаем наш скрипт и получим следующий результат:

Обратите внимание, что мы используем аргумент names = для pd.read_csv(), чтобы установить наши собственные имена столбцов, потому что исходный набор данных не содержит заголовка таблицы (наименования столбцов).

Словарь данных (для кода GWA_BTC):

• Date: день, в который были рассчитаны значения индекса.
• Open: дневной индекс цен на биткойны в долларах США.
• High: максимальное значение индекса цен на биткойны в долларах США за день на дату.
• Low: самое низкое значение индекса цен на биткойны в долларах США за день на дату.
• Close: дневной индекс цен на биткойны в долларах США.
• Volume: объем торговли биткойнами в этот день.
• VWAP: средневзвешенная цена за биткойн, торгуемая в этот день.
• TWAP: средневзвешенная по времени цена Биткойна, торгуемая в этот день.

Шаг 3: Понимание данных. Изучение данных

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

Как правило, все наблюдения (записи/транзакции) должны быть эквивалентны по степени детализации и в единицах измерения.

Существуют исключения, но по большей части это правило поможет вам избежать многих головных болей.

• Эквивалентность в гранулярности —  например, вы можете иметь 10 строк данных по 10 разным криптовалютам. Однако у вас не должно быть 11-й строки со средними или суммарными значениями из других 10 строк. Эта 11-я строка будет агрегацией и, следовательно, не эквивалентна по гранулярности с другими 10.
• Эквивалентность в единицах — у вас может быть 10 строк с ценами в долларах США, собранных на разные даты. Однако у вас не должно быть еще 10 строк с ценами, указанными в евро. Любые агрегаты, распределения, визуализации или статистика станут бессмысленными.

Наш текущий набор необработанных данных нарушает оба эти правила!

Данные, хранящиеся в CSV-файлах или базах данных, часто имеют формат «стопки» или «запись». Они используют один столбец «Код» в качестве универсального для метаданных. Например, в примере набора данных у нас есть следующие коды:

# Unique codes in the dataset
print( df.Code.unique() )

Результат выполнения:

Во-первых, посмотрите, что некоторые коды начинаются с GWA, а другие — с MWA? На самом деле это абсолютно разные типы индикаторов согласно странице документации.

• MWA означает «средневзвешенное значение по рынку», и они показывают региональные цены. Существует несколько кодов MWA для каждой криптовалюты, по одному на каждую местную фиатную валюту.
• С другой стороны, GWA означает «средневзвешенное значение по всему миру», которое показывает глобально проиндексированные цены. Таким образом, GWA — это совокупность MWA, а не эквивалентность по гранулярности. (Примечание: в образец набора данных включен только поднабор региональных кодов MWA)

Например, давайте посмотрим на коды Биткойн в ту же дату:

# Example of GWA and MWA relationship
df[df.Code.isin(['GWA_BTC', 'MWA_BTC_JPY', 'MWA_BTC_EUR']) & (df.Date == '2018-01-01')]

 Результат выполнения команды:

Как видите, у нас есть несколько записей для криптовалюты на данную дату. Чтобы еще больше усложнить ситуацию, региональные данные MWA выражены в местной валюте (то есть в неэквивалентных единицах), поэтому вам также понадобятся исторические обменные курсы.

Наличие разных уровней детализации и/или разных единиц делает анализ в лучшем случае громоздким, а в худшем — невозможным.

К счастью, как только мы обнаружили эту проблему, исправить ее на самом деле тривиально!

Шаг 4: Отфильтруем нежелательные наблюдения (записи/строки)

Одним из самых простых, но наиболее полезных методов обработки данных является удаление нежелательных наблюдений.

На предыдущем этапе мы узнали, что коды GWA являются агрегированием региональных кодов MWA. Поэтому для проведения нашего анализа нам нужно только сохранить глобальные коды GWA:

# Number of observations in dataset
print( 'Before:', len(df) )
 
# Get all the GWA codes
gwa_codes = [code for code in df.Code.unique() if 'GWA_' in code]
 
# Only keep GWA observations
df = df[df.Code.isin(gwa_codes)]
 
# Number of observations left
print( 'After:', len(df) )

Результат работы скрипта Python 3 в Jupyter Notebook:

Теперь, когда у нас остались только коды GWA, все наши наблюдения эквивалентны по степени детализации и единицах измерения. Мы можем продолжать обработку данных.

Шаг 5: Pivot the dataset — Развернем набор данных

Далее, чтобы проанализировать нашу стратегию торговли по импульсам, описанную выше, для каждой криптовалюты нам потребуется рассчитать доходность за предыдущие 7, 14, 21 и 28 дней для первого дня каждого месяца.

Тем не менее, было бы очень сложно производить этот расчет с текущим «сложенным» набором данных («stacked» dataset). Это потребует написания вспомогательных функций, циклов и множества условной логики. Вместо этого мы будем использовать более элегантный подход.

Во-первых, мы повернем набор данных, оставив только один ценовой столбец. В этом уроке мы сохраним столбец VWAP (средневзвешенная цена).

# Pivot dataset
pivoted_df = df.pivot(index='Date', columns='Code', values='VWAP')
 
# Display examples from pivoted dataset
pivoted_df.tail()

Результат:

Как видите, каждый столбец в нашем сводном наборе данных (pivoted dataset) теперь представляет цену за одну криптовалюту, а каждая строка содержит цены за одну дату. Все объекты теперь выровнены по дате.

Шаг 6: Сдвиг развернутого набора данных — Shift the pivoted dataset

Чтобы легко рассчитать returns за предыдущие 7, 14, 21 и 28 дней, мы можем использовать метод shift из библиотеки Pandas.

Эта функция сдвигает индекс dataframe на указанное количество периодов. Например, вот что происходит, когда мы сдвигаем наш pivoted dataset на 1:

print( pivoted_df.tail(3) )

print( pivoted_df.tail(3).shift(1) )

Обратите внимание, как смещенный набор данных теперь имеет значения за 1 день до этого? Мы можем воспользоваться этим, чтобы рассчитать prior returns для 7, 14, 21, 28 дней.

Например, для расчета доходности за 7 дней этого нам понадобится prices_today / prices_7_days_ago - 1.0, что означает:

Рассчитать returns для всех наших периодов так же просто, как написать цикл и сохранить его в словаре:

# Calculate returns over each window and store them in dictionary
delta_dict = {}
for offset in [7, 14, 21, 28]:
    delta_dict['delta_{}'.format(offset)] = pivoted_df / pivoted_df.shift(offset) - 1.0

# Display result "delta_dict"
delta_dict

Полный список результата (out):

{'delta_7': Code        GWA_BTC  GWA_ETH  GWA_LTC  GWA_XLM  GWA_XRP
 Date                                                   
 2014-04-01      nan      nan      nan      nan      nan
 2014-04-02      nan      nan      nan      nan      nan
 2014-04-03      nan      nan      nan      nan      nan
 2014-04-04      nan      nan      nan      nan      nan
 2014-04-05      nan      nan      nan      nan      nan
 ...             ...      ...      ...      ...      ...
 2018-01-19    -0.18    -0.17    -0.18    -0.21    -0.22
 2018-01-20    -0.13    -0.19    -0.18    -0.23    -0.29
 2018-01-21    -0.15    -0.20    -0.22    -0.22    -0.30
 2018-01-22    -0.21    -0.24    -0.24    -0.25    -0.32
 2018-01-23    -0.11    -0.12    -0.13    -0.02    -0.04
 
 [1394 rows x 5 columns],
 'delta_14': Code        GWA_BTC  GWA_ETH  GWA_LTC  GWA_XLM  GWA_XRP
 Date                                                   
 2014-04-01      nan      nan      nan      nan      nan
 2014-04-02      nan      nan      nan      nan      nan
 2014-04-03      nan      nan      nan      nan      nan
 2014-04-04      nan      nan      nan      nan      nan
 2014-04-05      nan      nan      nan      nan      nan
 ...             ...      ...      ...      ...      ...
 2018-01-19    -0.29     0.05    -0.23    -0.27    -0.41
 2018-01-20    -0.26     0.13    -0.29    -0.26    -0.42
 2018-01-21    -0.29    -0.01    -0.32    -0.31    -0.51
 2018-01-22    -0.29    -0.13    -0.30    -0.28    -0.52
 2018-01-23    -0.31    -0.22    -0.32    -0.24    -0.48
 
 [1394 rows x 5 columns],
 'delta_21': Code        GWA_BTC  GWA_ETH  GWA_LTC  GWA_XLM  GWA_XRP
 Date                                                   
 2014-04-01      nan      nan      nan      nan      nan
 2014-04-02      nan      nan      nan      nan      nan
 2014-04-03      nan      nan      nan      nan      nan
 2014-04-04      nan      nan      nan      nan      nan
 2014-04-05      nan      nan      nan      nan      nan
 ...             ...      ...      ...      ...      ...
 2018-01-19    -0.22     0.42    -0.24     0.88     0.02
 2018-01-20    -0.05     0.60    -0.09     0.57    -0.26
 2018-01-21    -0.11     0.51    -0.12     0.47    -0.28
 2018-01-22    -0.19     0.36    -0.19     0.05    -0.35
 2018-01-23    -0.25     0.13    -0.29    -0.10    -0.39
 
 [1394 rows x 5 columns],
 'delta_28': Code        GWA_BTC  GWA_ETH  GWA_LTC  GWA_XLM  GWA_XRP
 Date                                                   
 2014-04-01      nan      nan      nan      nan      nan
 2014-04-02      nan      nan      nan      nan      nan
 2014-04-03      nan      nan      nan      nan      nan
 2014-04-04      nan      nan      nan      nan      nan
 2014-04-05      nan      nan      nan      nan      nan
 ...             ...      ...      ...      ...      ...
 2018-01-19    -0.17     0.57    -0.24     1.30     0.65
 2018-01-20    -0.13     0.60    -0.27     1.23     0.53
 2018-01-21    -0.12     0.65    -0.27     1.22     0.45
 2018-01-22    -0.20     0.38    -0.33     1.09     0.30
 2018-01-23    -0.31     0.29    -0.37     1.16     0.29
 
 [1394 rows x 5 columns]}

Примечание. Для расчета returns путем смещения набора данных необходимо выполнить 2 допущения:

1. наблюдения отсортированы ascending by date и
2. отсутствуют пропущенные даты. Этого шага нет в статье, чтобы сделать этот урок лаконичным, рекомендуется проверить это самостоятельно.

Шаг 7: Сплавка смещенного набора данных — Melt the shifted dataset

Теперь, когда мы вычислили возвраты с использованием развернутого набора данных (Pivot dataset), мы собираемся «разворачивать (unpivot)» возвраты. Развернув (Unpivot) или расплавив данные, мы можем позже создать аналитическую базовую таблицу (АБТ — analytical base table, ABT), где каждая строка содержит всю необходимую информацию для конкретной монеты на определенную дату.

Мы не могли напрямую сместить исходный набор данных, потому что данные для разных монет были сложены друг на друга, поэтому границы могли бы перекрываться. Другими словами, данные BTC попадут в расчеты ETH, данные ETH попадут в расчеты LTC и так далее.

Чтобы расплавить данные, нам требуется:

• reset_index(), чтобы мы могли вызывать столбцы по имени;
• Вызовите метод melt();
• Передайте столбец (столбцы), чтобы сохранить в аргумент id_vars=;
• Назовите растопленный столбец (melted column), используя аргумент value_name=.

Вот как это выглядит для одного dataframe:

# Melt delta_7 returns
melted_7 = delta_7.reset_index().melt(id_vars=['Date'], value_name='delta_7')
 
# Melted dataframe examples
melted_7.tail()

Результат:

Чтобы сделать это для всех возвращаемых DataFrame, мы можем просто перебрать delta_dict, вот так:

# Melt all the delta dataframes and store in list
melted_dfs = []
for key, delta_df in delta_dict.items():
    melted_dfs.append( delta_df.reset_index().melt(id_vars=['Date'], value_name=key) )

melted_dfs

Результат:

[            Date     Code  delta_7
 0     2014-04-01  GWA_BTC      nan
 1     2014-04-02  GWA_BTC      nan
 2     2014-04-03  GWA_BTC      nan
 3     2014-04-04  GWA_BTC      nan
 4     2014-04-05  GWA_BTC      nan
 ...          ...      ...      ...
 6965  2018-01-19  GWA_XRP    -0.22
 6966  2018-01-20  GWA_XRP    -0.29
 6967  2018-01-21  GWA_XRP    -0.30
 6968  2018-01-22  GWA_XRP    -0.32
 6969  2018-01-23  GWA_XRP    -0.04
 
 [6970 rows x 3 columns],             Date     Code  delta_14
 0     2014-04-01  GWA_BTC       nan
 1     2014-04-02  GWA_BTC       nan
 2     2014-04-03  GWA_BTC       nan
 3     2014-04-04  GWA_BTC       nan
 4     2014-04-05  GWA_BTC       nan
 ...          ...      ...       ...
 6965  2018-01-19  GWA_XRP     -0.41
 6966  2018-01-20  GWA_XRP     -0.42
 6967  2018-01-21  GWA_XRP     -0.51
 6968  2018-01-22  GWA_XRP     -0.52
 6969  2018-01-23  GWA_XRP     -0.48
 
 [6970 rows x 3 columns],             Date     Code  delta_21
 0     2014-04-01  GWA_BTC       nan
 1     2014-04-02  GWA_BTC       nan
 2     2014-04-03  GWA_BTC       nan
 3     2014-04-04  GWA_BTC       nan
 4     2014-04-05  GWA_BTC       nan
 ...          ...      ...       ...
 6965  2018-01-19  GWA_XRP      0.02
 6966  2018-01-20  GWA_XRP     -0.26
 6967  2018-01-21  GWA_XRP     -0.28
 6968  2018-01-22  GWA_XRP     -0.35
 6969  2018-01-23  GWA_XRP     -0.39
 
 [6970 rows x 3 columns],             Date     Code  delta_28
 0     2014-04-01  GWA_BTC       nan
 1     2014-04-02  GWA_BTC       nan
 2     2014-04-03  GWA_BTC       nan
 3     2014-04-04  GWA_BTC       nan
 4     2014-04-05  GWA_BTC       nan
 ...          ...      ...       ...
 6965  2018-01-19  GWA_XRP      0.65
 6966  2018-01-20  GWA_XRP      0.53
 6967  2018-01-21  GWA_XRP      0.45
 6968  2018-01-22  GWA_XRP      0.30
 6969  2018-01-23  GWA_XRP      0.29
 
 [6970 rows x 3 columns]]

Наконец, мы можем создать другой расплавленный фрейм данных, который содержит прогнозные 7-дневные возвраты. Это будет нашей «целевой переменной» для оценки нашей торговой стратегии.

Просто сдвиньте сводный набор данных на — 7, чтобы получить «будущие» цены, например:

# Calculate 7-day returns after the date
return_df = pivoted_df.shift(-7) / pivoted_df - 1.0
 
# Melt the return dataset and append to list
melted_dfs.append( return_df.reset_index().melt(id_vars=['Date'], value_name='return_7') )

Теперь у нас есть 5 расплавленных фреймов данных, сохраненных в списке melted_dfs, по одному для каждого из ретроспективных 7, 14, 21 и 28-дневных возвратов и один для прогнозных 7-дневных возвратов.

Шаг 8: Уменьшить-объединить расплавленные данные — Reduce-merge the melted data

Все, что осталось сделать — это объединить наши расплавленные DataFrames в единую аналитическую базовую таблицу. Нам понадобятся два инструмента.

Первый инструмент — это функция слияния Pandas, которая работает как JOIN в SQL. Например, для того, чтобы объединить первые два расплавленных DataFrames:

# Merge two dataframes
pd.merge(melted_dfs[0], melted_dfs[1], on=['Date', 'Code']).tail()

Результат:

Посмотрите, теперь у нас delta_7 и delta_14 в одной строке! Это начало нашей аналитической базовой таблицы. Все, что нам нужно сделать сейчас — это объединить все наши расплавленные DataFrames с базовым DataFrame других функций, которые нам могут понадобиться.

Самый элегантный способ сделать это — использовать встроенную функцию уменьшения Python. Сначала нам нужно её импортировать:

from functools import reduce

Далее, прежде чем использовать эту функцию, давайте создадим список feature_dfs, который содержит базовые элементы из исходного набора данных плюс расплавленные наборы данных.

# Grab features from original dataset
base_df = df[['Date', 'Code', 'Volume', 'VWAP']]
 
# Create a list with all the feature dataframes
feature_dfs = [base_df] + melted_dfs

Теперь мы готовы использовать функцию Reduce.

Reduce применяет функцию двух аргументов кумулятивно к объектам в последовательности (например, список).
Например,

reduce(lambda x,y: x+y, [1,2,3,4,5])

вычисляет

((((1+2)+3)+4)+5)

Таким образом, мы можем уменьшить-объединить все функции следующим образом:

# Reduce-merge features into analytical base table
abt = reduce(lambda left,right: pd.merge(left,right,on=['Date', 'Code']), feature_dfs)
 
# Display examples from the ABT
abt.tail(10)

Словарь данных для нашей аналитической базовой таблицы (ABT):

• Date (Дата):  день, в который были рассчитаны значения индекса.
• Code (Код):  пара, какая криптовалюта.
• VWAP:  средневзвешенная цена за день торгов на дату .
• delta_7:  возврат за предыдущие 7 дней (1.0 = 100% возврат).
• delta_14:  возврат за предыдущие 14 дней (1.0 = 100% возврат).
• delta_21:  возврат за предыдущие 21 день (1.0 = 100% возврат).
• delta_28:  возврат за предыдущие 28 дней (1.0 = 100% возврат).
• return_7:  будущий возврат в течение следующих 7 дней (1.0 = 100% возврат).

Кстати, обратите внимание, что последние 7 наблюдений не имеют значений для функции return_7? Это ожидаемо, так как мы не можем рассчитать «будущие 7-дневные доходы» за последние 7 дней набора данных.

Технически, с этой ABT, мы уже можем ответить на нашу первоначальную цель. Например, если мы хотим выбрать монету, которая имела наибольший импульс 1 сентября 2017 года, мы могли бы просто отобразить строки для этой даты и посмотреть на 7, 14, 21 и 28-дневный возврат:

# Data from Sept 1st, 2017
abt[abt.Date == '2017-09-01']

И если вы хотите программно выбрать криптовалюту (пару для торгов) с наибольшим импульсом (например, за предыдущие 28 дней), вы должны написать:

max_momentum_id = abt[abt.Date == '2017-09-01'].delta_28.idxmax()
abt.loc[max_momentum_id, ['Code','return_7']]

Тем не менее, поскольку мы заинтересованы в торговле только в первый день каждого месяца, мы можем упростить ситуацию для себя…

Шаг 9: (Необязательно) Агрегация через Group By — Aggregate with group-by

В качестве последнего шага, если мы хотим сохранить только первые дни каждого месяца. Для этого мы можем использовать группирование с последующей агрегацией.

Сначала создайте новую функцию ‘month’ из первых 7 символов строк Date.
Затем сгруппируйте наблюдения по «Коду» и «месяцу». Pandas создадут «ячейки» данных, которые разделяют наблюдения по коду и месяцу.
Наконец, в каждой группе просто возьмите .first() и сбросьте индекс.
Примечание. Мы предполагаем, что ваш фрейм данных по-прежнему правильно отсортирован по дате.

Вот как все это выглядит вместе:

# Create 'month' feature
abt['month'] = abt.Date.apply(lambda x: x[:7])
 
# Group by 'Code' and 'month' and keep first date
gb_df = abt.groupby(['Code', 'month']).first().reset_index()
 
# Display examples
gb_df.tail()

Как видите, теперь у нас есть правильная Аналитическая базовая таблица АБТ с:

• Только соответствующие данные с 1-го числа каждого месяца.
• Импульсные характеристики рассчитаны за предыдущие 7, 14, 21 и 28 дней.
• Прогноз будущих возвратов (future returns) через 7 дней.

Другими словами, у нас есть именно то, что нам нужно, чтобы оценить простую торговую стратегию, которую мы предложили в начале статьи!

Полный код от начала до конца

Вот весь основной код в одном месте, в одном скрипте.

# 2. Import libraries and dataset
import pandas as pd
pd.options.display.float_format = '{:,.2f}'.format
pd.options.display.max_rows = 200
pd.options.display.max_columns = 100
 
df = pd.read_csv('BNC2_sample.csv',
                 names=['Code', 'Date', 'Open', 'High', 'Low', 
                        'Close', 'Volume', 'VWAP', 'TWAP'])
 
# 4. Filter unwanted observations
gwa_codes = [code for code in df.Code.unique() if 'GWA_' in code]
df = df[df.Code.isin(gwa_codes)]
 
# 5. Pivot the dataset
pivoted_df = df.pivot(index='Date', columns='Code', values='VWAP')
 
# 6. Shift the pivoted dataset
delta_dict = {}
for offset in [7, 14, 21, 28]:
    delta_dict['delta_{}'.format(offset)] = pivoted_df / pivoted_df.shift(offset) - 1
    
# 7. Melt the shifted dataset
melted_dfs = []
for key, delta_df in delta_dict.items():
    melted_dfs.append( delta_df.reset_index().melt(id_vars=['Date'], value_name=key) )
 
return_df = pivoted_df.shift(-7) / pivoted_df - 1.0
melted_dfs.append( return_df.reset_index().melt(id_vars=['Date'], value_name='return_7') )
 
# 8. Reduce-merge the melted data
from functools import reduce
 
base_df = df[['Date', 'Code', 'Volume', 'VWAP']]
feature_dfs = [base_df] + melted_dfs
 
abt = reduce(lambda left,right: pd.merge(left,right,on=['Date', 'Code']), feature_dfs)
 
# 9. Aggregate with group-by.
abt['month'] = abt.Date.apply(lambda x: x[:7])
gb_df = abt.groupby(['Code', 'month']).first().reset_index()

Сообщение Python 3 Tutorial — Data Wrangling — Обработка данных по криптовалютам появились сначала на Python 3 | Data Science | Нейронные сети | AI - Искусственный Интеллект.

import numpy as np
import pandas as pd
data = pd.DataFrame(np.random.rand(6, 1),
                  columns=['close'],
                 index=['a', 'b', 'c', 'd', 'e', 'f'])

data['shift_plus_1'] = data.close.shift(1)

data.loc[data.close.shift(+1) < data.close, 'TrendUp'] = 1

print(data)

Результат выполнения скрипта

      close  shift_plus_1  TrendUp
a  0.743436           NaN      NaN
b  0.254870      0.743436      NaN
c  0.689602      0.254870      1.0
d  0.233681      0.689602      NaN
e  0.100933      0.233681      NaN
f  0.391622      0.100933      1.0

Сообщение Предыдущий и следующий элемент в dataframe pandas. Shift Python появились сначала на Python 3 | Data Science | Нейронные сети | AI - Искусственный Интеллект.

Введение — перевод документации (pandas.pydata.org)

Базовый синтаксис:

DataFrame.to_sql(
	name,
	con,
	schema=None,
	if_exists='fail',
	index=True,
	index_label=None,
	chunksize=None,
	dtype=None,
	method=None
)

Записывает записи, хранящиеся в DataFrame, в базу данных SQL. Поддерживаются базы данных, поддерживаемые SQLAlchemy. Таблицы могут быть заново созданы, добавлены или перезаписаны. Пояснения для параметров метода to_sql:

name : string
Имя таблицы SQL.

con : sqlalchemy.engine.Engine или sqlite3.Connection
Использование SQLAlchemy позволяет использовать любую БД, поддерживаемую этой библиотекой.

schema : string, optional
Укажите схему (если это поддерживает база данных). Если схема не указана, то будет использована схема по-умолчанию.

if_exists : {‘fail’, ‘replace’, ‘append’}, default ‘fail’
Параметр описывает поведение, если таблица уже существует.
fail: вызвать ошибку ValueError.
replace: Drop table перед вставкой новых значений.
append: вставить новые значения в существующую таблицу.

index : bool, по-умолчанию True
Запишет индекс DataFrame в виде столбца. Использует index_label в качестве имени столбца в таблице.

index_label : string или sequence, по-умолчанию отсутствует
Метка столбца для индексных столбцов. Если указано None (по-умолчанию), а index — True, тогда используются имена индексов. Последовательность должна быть задана, если DataFrame использует MultiIndex.

chunksize : int, необязательный параметр
Строки будут записаны партиями заданного размера за раз. По-умолчанию строки пишутся одновременно.

dtype : dict, необязательный параметр
Указание типа данных для столбцов. Ключи должны быть именами столбцов, а значения — типами или строками.

method : {None, ‘multi’, callable}, по-умолчанию None
Контролирует SQL Insert
None : используется стандартный SQL INSERT (по одному на строку).
‘multi’: передать несколько значений в одном INSERT.
callable:вызывается с подписью (pd_table, conn, keys, data_iter).

https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.to_sql.html

Пример записи данных из DataFrame ‘data’ в таблицу

import psycopg2
from sqlalchemy import create_engine

# предполагаем, что у нас есть DataFrame с названием 'date'

# Подключаемся к базе данных PGSQL
engine = create_engine('postgresql+psycopg2://user_name:password@host_name_or_ip/database_name')

# Пишем в PGSQL
data.to_sql('table_name', con=engine, schema = 'dbo', if_exists='replace')

Сообщение Python3 Pandas DataFrame To_Sql — запись данных в таблицу появились сначала на Python 3 | Data Science | Нейронные сети | AI - Искусственный Интеллект.

Что такое Pandas DataFrame?

Pandas — более новый пакет, надстройка над библиотекой NumPy, обеспечивающий эффективную реализацию класса DataFrame.

Объекты DataFrame — многомерные массивы с метками для строк и столбцов, а также зачастую с неоднородным типом данных и/или пропущенными данными.

Помимо удобного интерфейса для хранения маркированных данных, библиотека Pandas реализует множество операций для работы с данными хорошо знакомых пользователям фреймворков баз данных и электронных таблиц.

Импорт библиотек NumPy и Pandas

На самом примитивном уровне объекты библиотеки Pandas можно считать расширенной версией структурированных массивов библиотеки NumPy, в которых строки и столбцы идентифицируются метками, а не простыми числовыми индексами. Библиотека Pandas предоставляет множество полезных утилит, методов и функциональности в дополнение к базовым структурам данных, но все последующее изложение потребует понимания этих базовых структур. Позвольте познакомить вас с тремя фундаментальными структурами данных библиотеки Pandas: классами Series, DataFrame и Index.

Начнем наш сеанс программирования с обычных импортов библиотек NumPy и Pandas:

import numpy as np
import pandas as pd

Объект Series библиотеки Pandas

Объект Series библиотеки Pandas — одномерный массив индексированных данных. Его можно создать из списка или массива следующим образом:

import numpy as np
import pandas as pd

data = pd.Series([0.25, 0.5, 0.75, 1.0])
print(data)

Результат:

Как мы видели из предыдущего результата, объект Series служит адаптером как для последовательности значений, так и последовательности индексов, к которым можно получить доступ посредством атрибутов values и index. Атрибут values представляет собой массив NumPy:

import numpy as np
import pandas as pd

data = pd.Series([0.25, 0.5, 0.75, 1.0])
print(data.values)

Результат:

[0.25 0.5  0.75 1.  ]

Index — массивоподобный объект типа pd.Index:

import numpy as np
import pandas as pd

data = pd.Series([0.25, 0.5, 0.75, 1.0])
print(data.index)

Результат:

RangeIndex(start=0, stop=4, step=1)

Аналогично массивам библиотеки NumPy, к данным можно обращаться по соответствующему им индексу посредством нотации с использованием квадратных скобок языка Python:

import numpy as np
import pandas as pd

data = pd.Series([0.25, 0.5, 0.75, 1.0])
print('data[1]:')
print(data[1])

print('data[1:3]:')
print(data[1:3])

Результат:

data[1]:
0.5
data[1:3]:
1    0.50
2    0.75
dtype: float64

Однако объект Series библиотеки Pandas намного универсальнее и гибче, чем эмулируемый им одномерный массив библиотеки NumPy.

Объект Series как обобщенный массив NumPy

Может показаться, что объект Series и одномерный массив библиотеки NumPy взаимозаменяемы. Основное различие между ними — индекс. В то время как индекс массива NumPy, используемый для доступа к значениям, — целочисленный и описывается неявно, индекс объекта Series библиотеки Pandas описывается явно и связывается со значениями.

Явное описание индекса расширяет возможности объекта Series. Такой индекс не должен быть целым числом, а может состоять из значений любого нужного типа. Например, при желании мы можем использовать в качестве индекса строковые значения:

import numpy as np
import pandas as pd

data = pd.Series([0.25, 0.5, 0.75, 1.0],
                 index=['a', 'b', 'c', 'd'])
print(data)

Результат:

a    0.25
b    0.50
c    0.75
d    1.00
dtype: float64

При этом доступ к элементам работает обычным образом:

import numpy as np
import pandas as pd

data = pd.Series([0.25, 0.5, 0.75, 1.0],
                 index=['a', 'b', 'c', 'd'])
print(data['b'])

Результат:

0.5

Объект Series как специализированный словарь

Объект Series библиотеки Pandas можно рассматривать как специализированную разновидность словаря языка Python. Словарь — структура, задающая соответствие произвольных ключей набору произвольных значений, а объект Series — структура, задающая соответствие типизированных ключей набору типизированных значений.

Типизация важна: точно так же, как соответствующий типу специализированный код для массива библиотеки NumPy при выполнении определенных операций делает его эффективнее, чем стандартный список Python, информация о типе в объекте Series библиотеки Pandas делает его намного более эффективным для определенных операций, чем словари Python.

Можно сделать аналогию «объект Series — словарь» еще более наглядной, сконструировав объект Series непосредственно из словаря Python.

По умолчанию при этом будет создан объект Series с полученным из отсортированных ключей индексом. Следовательно, для него возможен обычный доступ к элементам, такой же, как для словаря. Объект Series поддерживает операции «срезы».

import numpy as np
import pandas as pd

# Словарь
population_dict = {'California': 38332521,
                   'Texas': 26448193,
                   'New York': 19651127,
                   'Florida': 19552860,
                   'Illinois': 12882135}
population = pd.Series(population_dict)
print('population:')
print(population)

# Доступ к элементам
print("population['California']:")
print(population['California'])

# Срез
print("population['California':'New York']:")
print(population['California':'New York'])

Результат:

population:
California    38332521
Texas         26448193
New York      19651127
Florida       19552860
Illinois      12882135
dtype: int64

population['California']:
38332521

population['California':'New York']:
California    38332521
Texas         26448193
New York      19651127
dtype: int64

Создание объектов Series

Мы уже изучили несколько способов создания объектов Series библиотеки Pandas с нуля.

Все они представляют собой различные варианты следующего синтаксиса Pandas Series (общий вид синтаксиса):

pd.Series(data, index=index)

где index — необязательный аргумент, а data может быть одной из множества сущностей.

Например, аргумент data может быть списком или массивом NumPy. В этом случае index по умолчанию будет целочисленной последовательностью:

import pandas as pd

data = pd.Series([2, 4, 6])
print(data)

Результат:

0    2
1    4
2    6
dtype: int64

Аргумент data может быть скалярным значением, которое будет повторено нужное количество раз для заполнения заданного индекса:

import pandas as pd

data = pd.Series(5, index=[100, 200, 300])
print(data)

Результат:

100    5
200    5
300    5
dtype: int64

Аргумент data может быть словарем, в котором index по умолчанию является отсортированными ключами этого словаря:

import pandas as pd

data = pd.Series({2:'a', 1:'b', 3:'c'})
print(data)

Результат:

2    a
1    b
3    c
dtype: object

В каждом случае индекс можно указать вручную, если необходимо получить другой результат:

import pandas as pd

data = pd.Series({2:'a', 1:'b', 3:'c'}, index=[3, 2])
print(data)

Результат:

3    c
2    a
dtype: object

Обратите внимание, что объект Series заполняется только заданными явным образом ключами.

Объект DataFrame библиотеки Pandas

Следующая базовая структура библиотеки Pandas — объект DataFrame. Как и объект Series, объект DataFrame можно рассматривать или как обобщение массива NumPy, или как специализированную версию словаря Python. Изучим оба варианта.

DataFrame как обобщенный массив NumPy

Если объект Series — аналог одномерного массива с гибкими индексами, объект DataFrame — аналог двумерного массива с гибкими индексами строк и гибкими именами столбцов. Аналогично тому, что двумерный массив можно рассматривать как упорядоченную последовательность выровненных столбцов, объект DataFrame можно рассматривать как упорядоченную последовательность выровненных объектов Series. Под «выровненными» имеется в виду то, что они используют один и тот же индекс.

Чтобы продемонстрировать это, сначала создадим новый объект Series, содержащий площадь каждого из пяти упомянутых в предыдущем разделе штатов:

import pandas as pd

area_dict = {'California': 423967,
             'Texas': 695662,
             'New York': 141297,
             'Florida': 170312,
             'Illinois': 149995}
area = pd.Series(area_dict)
print(area)

Результат:

California    423967
Texas         695662
New York      141297
Florida       170312
Illinois      149995
dtype: int64

Воспользовавшись объектом population класса Series, сконструируем на основе словаря единый двумерный объект, содержащий всю эту информацию:

import pandas as pd

# Словарь площадь штатов
area_dict = {'California': 423967,
             'Texas': 695662,
             'New York': 141297,
             'Florida': 170312,
             'Illinois': 149995}
area = pd.Series(area_dict)

# Словарь население
population_dict = {'California': 38332521,
                   'Texas': 26448193,
                   'New York': 19651127,
                   'Florida': 19552860,
                   'Illinois': 12882135}
population = pd.Series(population_dict)

# Создаем DataFrame
states = pd.DataFrame({'population': population, 'area': area})
print(states)

Результат:

            population    area
California    38332521  423967
Texas         26448193  695662
New York      19651127  141297
Florida       19552860  170312
Illinois      12882135  149995

Аналогично объекту Series у объекта DataFrame имеется атрибут index, обеспечивающий доступ к меткам индекса. Еще у объекта DataFrame есть атрибут columns, представляющий собой содержащий метки столбцов объект Index.

import pandas as pd

# Словарь площадь штатов
area_dict = {'California': 423967,
             'Texas': 695662,
             'New York': 141297,
             'Florida': 170312,
             'Illinois': 149995}
area = pd.Series(area_dict)

# Словарь население
population_dict = {'California': 38332521,
                   'Texas': 26448193,
                   'New York': 19651127,
                   'Florida': 19552860,
                   'Illinois': 12882135}
population = pd.Series(population_dict)

# Создаем DataFrame
states = pd.DataFrame({'population': population, 'area': area})

print('Индексы - states.index:')
print(states.index)
print('')
print('Колонки - states.columns:')
print(states.columns)

Результат:

Индексы - states.index:
Index(['California', 'Texas', 'New York', 'Florida', 'Illinois'], dtype='object')

Колонки - states.columns:
Index(['population', 'area'], dtype='object')

Таким образом, объект DataFrame можно рассматривать как обобщение двумерного массива NumPy, где как у строк, так и у столбцов есть обобщенные индексы для доступа к данным.

Объект DataFrame как специализированный словарь

DataFrame можно рассматривать как специализированный словарь. Если словарь задает соответствие ключей значениям, то DataFrame задает соответствие имени столбца объекту Series с данными этого столбца. Например, запрос данных по атрибуту ‘area’ приведет к тому, что будет возвращен объект Series, содержащий площади штатов:

import pandas as pd

# Словарь площадь штатов
area_dict = {'California': 423967,
             'Texas': 695662,
             'New York': 141297,
             'Florida': 170312,
             'Illinois': 149995}
area = pd.Series(area_dict)

# Словарь население
population_dict = {'California': 38332521,
                   'Texas': 26448193,
                   'New York': 19651127,
                   'Florida': 19552860,
                   'Illinois': 12882135}
population = pd.Series(population_dict)

# Создаем DataFrame
states = pd.DataFrame({'population': population, 'area': area})

print(states['area'])

Результат:

California    423967
Texas         695662
New York      141297
Florida       170312
Illinois      149995
Name: area, dtype: int64

Создание объектов DataFrame

Существует множество способов создания объектов DataFrame библиотеки Pandas. Вот несколько примеров.

Из одного объекта Series

Объект DataFrame — набор объектов Series.

DataFrame, состоящий из одного столбца, можно создать на основе одного объекта Series:

import pandas as pd

# Словарь население
population_dict = {'California': 38332521,
                   'Texas': 26448193,
                   'New York': 19651127,
                   'Florida': 19552860,
                   'Illinois': 12882135}
population = pd.Series(population_dict)

df = pd.DataFrame(population, columns=['population'])

print(df)

Результат:

            population
California    38332521
Texas         26448193
New York      19651127
Florida       19552860
Illinois      12882135

Из списка словарей

Любой список словарей можно преобразовать в объект DataFrame. Мы воспользуемся простым списковым включением для создания данных:

import pandas as pd

data = [{'a': i, 'b': 2 * i}
        for i in range(3)]

print('data:')
print(data)
print('')

df = pd.DataFrame(data)
print('df:')
print(df)

Результат:

data:
[{'a': 0, 'b': 0}, {'a': 1, 'b': 2}, {'a': 2, 'b': 4}]

df:
   a  b
0  0  0
1  1  2
2  2  4

Даже если некоторые ключи в словаре отсутствуют, библиотека Pandas просто заполнит их значениями NaN (то есть Not a number — «не является числом»):

import pandas as pd

df = pd.DataFrame([{'a': 1, 'b': 2}, {'b': 3, 'c': 4}])
print('df:')
print(df)

Результат:

df:
     a  b    c
0  1.0  2  NaN
1  NaN  3  4.0

Из словаря объектов Series

Объект DataFrame также можно создать на основе словаря объектов Series (этот пример был приведен ранее):

import pandas as pd

# Словарь площадь штатов
area_dict = {'California': 423967,
             'Texas': 695662,
             'New York': 141297,
             'Florida': 170312,
             'Illinois': 149995}
area = pd.Series(area_dict)

# Словарь население
population_dict = {'California': 38332521,
                   'Texas': 26448193,
                   'New York': 19651127,
                   'Florida': 19552860,
                   'Illinois': 12882135}
population = pd.Series(population_dict)

# Создаем DataFrame
df = pd.DataFrame({'population': population,
                   'area': area})

print(df)

Результат:

            population    area
California    38332521  423967
Texas         26448193  695662
New York      19651127  141297
Florida       19552860  170312
Illinois      12882135  149995 

Из двумерного массива NumPy

Если у нас есть двумерный массив данных, мы можем создать объект DataFrame с любыми заданными именами столбцов и индексов. Для каждого из пропущенных значений будет использоваться целочисленный индекс:

import numpy as np
import pandas as pd

df = pd.DataFrame(np.random.rand(3, 2),
                  columns=['foo', 'bar'],
                  index=['a', 'b', 'c'])
print(df)

Результат:

        foo       bar
a  0.290872  0.647270
b  0.690850  0.950563
c  0.468706  0.344193

Из структурированного массива NumPy

Объект DataFrame библиотеки Pandas ведет себя во многом аналогично структурированному массиву библиотеки NumPy и может быть создан непосредственно из него:

import numpy as np
import pandas as pd

A = np.zeros(3, dtype=[('A', 'i8'), ('B', 'f8')])
print('A:')
print(A)
print('')

df = pd.DataFrame(A)
print('df:')
print(df)

Результат:

A:
[(0, 0.) (0, 0.) (0, 0.)]

df:
   A    B
0  0  0.0
1  0  0.0
2  0  0.0

Объект Index библиотеки Pandas

Как объект Series, так и объект DataFrame содержат явный индекс, обеспечивающий возможность ссылаться на данные и модифицировать их.

Объект Index можно рассматривать или как неизменяемый массив (immutable array), или как упорядоченное множество (ordered set) (формально мультимножество, так как объекты Index могут содержать повторяющиеся значения). Из этих способов его представления следуют некоторые интересные возможности операций над объектами Index. В качестве простого примера создадим Index из списка целых чисел:

import pandas as pd

ind = pd.Index([2, 3, 5, 7, 11])
print(ind)

Результат:

Int64Index([2, 3, 5, 7, 11], dtype='int64')

Объект Index как неизменяемый массив

Объект Index во многом ведет себя аналогично массиву. Например, для извлечения из него значений или срезов можно использовать стандартную нотацию индексации языка Python. У объектов Index есть много атрибутов.

Результат:

ind[1]
3

ind[::2]
Int64Index([2, 5, 11], dtype='int64')

ind.size, ind.shape, ind.ndim, ind.dtype
5 (5,) 1 int64

Одно из различий между объектами Index и массивами NumPy — неизменяемость индексов, то есть их нельзя модифицировать стандартными средствами:

import pandas as pd

ind = pd.Index([2, 3, 5, 7, 11])
ind[1] = 0

Результат:

Traceback (most recent call last):
  File "C:/Users/User/Desktop/test.py", line 4, in <module>
    ind[1] = 0
  File "C:\Users\User\AppData\Local\Programs\Python\Python37-32\lib\site-packages\pandas\core\indexes\base.py", line 3938, in __setitem__
    raise TypeError("Index does not support mutable operations")
TypeError: Index does not support mutable operations

Неизменяемость делает безопаснее совместное использование индексов несколькими объектами DataFrame и массивами, исключая возможность побочных эффектов в виде случайной модификации индекса по неосторожности.

Выбор подмножеств данных в Pandas

Анатомия Python Pandas DataFrame — Column, Index, Data

Рассмотрим изображение контейнера данных DataFrame (библиотеки Pandas):

Три компонента DataFrame:

DataFrame состоит из трех различных компонентов: индекса , столбцов и данных. Данные также известны как значения.

Индекс — это последовательность значений в левой части DataFrame. Каждое отдельное значение индекса называется index label, Иногда индекс упоминается как заголовки строк. В приведенном выше примере метки строк не очень интересны и представляют собой целые числа, начиная с 0 до n-1, где n — количество строк в таблице.

Столбцы представляют собой последовательность значений в самой верхней части DataFrame.

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

Каждая строка имеет метку, каждая колонка имеет метку

Основной вывод из анатомии DataFrame заключается в том, что каждая строка имеет метку, каждый столбец имеет метку. Эти метки используются для ссылки на конкретные строки или столбцы в DataFrame.

Что такое выбор подмножества?

Прежде чем мы начнем делать выбор подмножества, было бы хорошо определить, что это такое. Выбор подмножества — это просто выбор определенных строк и столбцов данных из DataFrame (или Series). Это может означать выбор всех строк и некоторых столбцов, некоторых строк и всех столбцов или некоторых строк и столбцов.

Выбор при помощи []

Загружаем данные из CSV в Pandas DataFrame (Python 3)

В совокупности [], .loc и .iloc называются индексаторами. Это самые распространенные способы выбора данных.

Скачать файл для использования в примерах:

SampleData_Pandas.csv

Код загрузки данных из csv в Pandas DataFrame:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';', index_col=0)
print(df)

Результат:

Вариант 2 загрузки данных из CSV (Index генерируется самостоятельно)

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')
print(df)

Результат:

Извлечение отдельных компонентов DataFrame

Ранее мы упоминали три компоненты DataFrame. Индекс, столбцы и данные (значения). Мы можем извлечь каждый из этих компонентов в свои переменные. Давайте сделаем это, а затем осмотрим их:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

index = df.index
columns = df.columns
values = df.values

index_list = df.index.tolist()
columns_list = df.columns.tolist()
values_list = df.values.tolist()

print('+++++ БЕЗ TOLIST() +++++')
print(index)
print('==========================')
print(columns)
print('==========================')
print(values)
print('==========================')


print('+++++ С TOLIST() +++++')
print(index_list)
print('==========================')
print(columns_list)
print('==========================')
print(values_list)

Результат:

Типы данных компонентов

Давайте выведем тип каждого компонента, чтобы точно понять, что это за объект.

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

index = df.index
columns = df.columns
values = df.values

index_list = df.index.tolist()
columns_list = df.columns.tolist()
values_list = df.values.tolist()

print('+++++ БЕЗ TOLIST() +++++')
print(type(index))
print('==========================')
print(type(columns))
print('==========================')
print(type(values))
print('==========================')


print('+++++ С TOLIST() +++++')
print(type(index_list))
print('==========================')
print(type(columns_list))
print('==========================')
print(type(values_list))

Результат:

+++++ БЕЗ TOLIST() +++++
<class 'pandas.core.indexes.range.RangeIndex'>
==========================
<class 'pandas.core.indexes.base.Index'>
==========================
<class 'numpy.ndarray'>
==========================

+++++ С TOLIST() +++++
<class 'list'>
==========================
<class 'list'>
==========================
<class 'list'>

Понимание этих типов

Интересно, что и индекс, и столбцы имеют одинаковый тип. Они оба Index-объект Pandas. Этот объект сам по себе довольно мощный, но сейчас вы можете думать о нем как о последовательности меток для строк или столбцов.

Значения (ячейки таблицы) — это numpy.ndarray, который обозначает n-мерный массив и является основным контейнером данных в библиотеке NumPy. 

Pandas построен непосредственно поверх NumPy, и именно этот массив отвечает за большую часть рабочей нагрузки.

Выбор одного столбца как серии

Чтобы выбрать один столбец данных, просто поместите имя столбца в скобках. Давайте выберем столбец Подразделение:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df['Подразделение'])

Результат:

0            Отдел продаж
1       Отдел продвижения
2       Отдел продвижения
3       Отдел продвижения
              ...        
2662         Отдел продаж
2663         Отдел продаж
2664         Отдел продаж
2665    Отдел продвижения
2666    Отдел продвижения
2667    Отдел продвижения
2668    Отдел продвижения
Name: Подразделение, Length: 2669, dtype: object

Анатомия Series, возвращаемой при выборе 1 столбца

Выбор одного столбца данных возвращает другой контейнер данных Pandas Series. 

Series — это одномерная последовательность помеченных данных. Существует два основных компонента Серии: указатель и данные (или значения . В серии нет колонок.

Визуальное отображение Series — это просто текст, в отличие от красиво оформленной таблицы для DataFrames.

Вы также заметите две дополнительные части данных в нижней части Series. 

Name из Series становится старое имя колонки. Вы также увидите тип данных или dtype серии. Вы можете игнорировать оба этих элемента на данный момент. А также количество элементов Length.

Выбор нескольких столбцов с помощью оператора индексации

Можно выбрать несколько столбцов только с помощью оператора индексации, передав ему список имен столбцов. Давайте выберем ‘Подразделение’, ‘Менеджер’, ‘Номенклатура’, ‘Продажи’

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df[['Подразделение','Менеджер','Номенклатура','Продажи']])

Результат:

          Подразделение    Менеджер Номенклатура       Продажи
0          Отдел продаж      Петров         Лыжи   956898,3051
1     Отдел продвижения     Сидоров   Велосипеды   1841949,153
2     Отдел продвижения     Сидоров        Доски   1052542,373
3     Отдел продвижения     Сидоров      Палатки   74478,81356
4          Отдел продаж    Илинская   Велосипеды   1649745,763
5          Отдел продаж    Илинская        Доски   1263241,525
...                 ...         ...          ...           ...
2661       Отдел продаж      Петров       Прочее   423,7288136
2662       Отдел продаж    Илинская         Лыжи  -15254,23729
2663       Отдел продаж      Петров         Лыжи   8176271,186
2664       Отдел продаж      Петров       Прочее   171186,4407
2665  Отдел продвижения  Охлобыстин       Прочее   16949,15254
2666  Отдел продвижения    Розницов         Лыжи   15254,23729
2667  Отдел продвижения    Розницов       Одежда   1444915,254
2668  Отдел продвижения    Розницов       Прочее   3389,830508

[2669 rows x 4 columns]

Выбор нескольких столбцов возвращает DataFrame

Выбор нескольких столбцов возвращает DataFrame. На самом деле вы можете выбрать один столбец как DataFrame со списком из одного элемента:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df[['Подразделение']])

Результат:

          Подразделение
0          Отдел продаж
1     Отдел продвижения
2     Отдел продвижения
...                 ...
2666  Отдел продвижения
2667  Отдел продвижения
2668  Отдел продвижения

[2669 rows x 1 columns]

Хотя это напоминает Series, технически это DataFrame, другой объект.

Порядок столбцов не имеет значения

При выборе нескольких столбцов вы можете выбрать их в любом порядке по вашему выбору. Это не должен быть тот же самый порядок как оригинальный DataFrame.

Например, давайте выберем Номенклатура, Подразделение:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df[['Номенклатура','Подразделение']])

Результат:

     Номенклатура      Подразделение
0            Лыжи       Отдел продаж
1      Велосипеды  Отдел продвижения
2           Доски  Отдел продвижения
3         Палатки  Отдел продвижения
4      Велосипеды       Отдел продаж
...           ...                ...
2666         Лыжи  Отдел продвижения
2667       Одежда  Отдел продвижения
2668       Прочее  Отдел продвижения

[2669 rows x 2 columns]

Исключения, при выполнении скрипта

Есть несколько общих исключений, которые возникают при выполнении выборок только с помощью оператора индексации.

• Если вы ошиблись словом, вы получите KeyError
• Если вы забыли использовать список, содержащий несколько столбцов, вы также получите KeyError

print(df['ПодразделениЯ'])
Результат: 
KeyError: 'ПодразделениЯ'

print(df['Номенклатура','Подразделение'])
Результат:
KeyError: ('Номенклатура', 'Подразделение')

В первом случае должно стоять print(df['Подразделение']). А во-втором случае: print(df[['Номенклатура','Подразделение']]).

Выборка данных из Pandas DataFrame с помощью .loc

В .loc индексатор выбирает данные по-другому, чем просто оператор индексации. Он может выбирать подмножества строк и/или столбцов. Самое главное, он выбирает данные только по метке (label) строк и столбцов.

Выберем одну строку как Series с .loc

.loc — Индексатор возвращает одну строку в серии, когда указали одну метку строки (один индекс).

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.loc[0])

Результат:

Дата                 01.01.2016
Подразделение      Отдел продаж
Контрагент           Абакус ООО
Менеджер                 Петров
Номенклатура               Лыжи
Продажи             956898,3051
Себестоимость       621983,8983
Валовая прибыль     334914,4068
Name: 0, dtype: object

Теперь у нас есть Series, где старые имена столбцов теперь являются индексными метками.

Выбираем несколько строк из DataFrame с помощью .loc

Чтобы выбрать несколько строк, поместите все метки строк, которые вы хотите выбрать, в список и передайте их .loc. Давайте выберем 3 и 20.

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.loc[[3,20]])

Результат:

          Дата      Подразделение  ... Себестоимость Валовая прибыль
3   01.01.2016  Отдел продвижения  ...   55859,11017     18619,70339
20  01.01.2016       Отдел продаж  ...   80585,27542     26861,75847

[2 rows x 8 columns]

Обозначение среза для выборки диапазона строк с .loc

Можно «нарезать» строки DataFrame с .locпомощью нотации среза. Для обозначения среза используется двоеточие для разделения значений начала, остановки и шага . Например, мы можем выбрать все строки из с 134 по 139:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.loc[134:139])

Результат:

           Дата      Подразделение  ... Себестоимость Валовая прибыль
134  01.01.2016  Отдел продвижения  ...   560,5932203     62,28813559
135  01.01.2016       Отдел продаж  ...   625773,3051     268188,5593
136  01.01.2016  Отдел продвижения  ...   508671,6102     218002,1186
137  01.01.2016  Отдел продвижения  ...   1034427,966     443326,2712
138  01.01.2016  Отдел продвижения  ...   55792,37288     18597,45763
139  01.01.2016  Отдел продвижения  ...   8477,542373     941,9491525

[6 rows x 8 columns]

.loc включает в себя последнее значение из обозначения среза

Обратите внимание, что строка с пометкой 139 в примере без шага была выведена. В других контейнерах данных, таких как списки Python, последнее значение исключается.

Вывод среза с использованием .loc и шага из DataFrame

Выведем тот же самый результат, только будем выводить каждый второй элемент из среза:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.loc[134:139:2])

Результат:

           Дата      Подразделение  ... Себестоимость Валовая прибыль
134  01.01.2016  Отдел продвижения  ...   560,5932203     62,28813559
136  01.01.2016  Отдел продвижения  ...   508671,6102     218002,1186
138  01.01.2016  Отдел продвижения  ...   55792,37288     18597,45763

[3 rows x 8 columns]

Выбор до указанной позиции .loc

Пример скрипта Python 3 для вывода 139 первых строк из Pandas DataFrame:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.loc[:139])

Результат:

           Дата      Подразделение  ... Себестоимость Валовая прибыль
0    01.01.2016       Отдел продаж  ...   621983,8983     334914,4068
1    01.01.2016  Отдел продвижения  ...   1289364,407     552584,7458
2    01.01.2016  Отдел продвижения  ...    736779,661     315762,7119
3    01.01.2016  Отдел продвижения  ...   55859,11017     18619,70339
..          ...                ...  ...           ...             ...
136  01.01.2016  Отдел продвижения  ...   508671,6102     218002,1186
137  01.01.2016  Отдел продвижения  ...   1034427,966     443326,2712
138  01.01.2016  Отдел продвижения  ...   55792,37288     18597,45763
139  01.01.2016  Отдел продвижения  ...   8477,542373     941,9491525

[140 rows x 8 columns]

Тот же самый пример, но выведем с шагом 25:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.loc[:139:25])

Результат выполнения выборки данных из Pandas DataFrame:

           Дата      Подразделение  ... Себестоимость Валовая прибыль
0    01.01.2016       Отдел продаж  ...   621983,8983     334914,4068
25   01.01.2016       Отдел продаж  ...   12813,55932     5491,525424
50   01.01.2016       Отдел продаж  ...   42978,81356     14326,27119
75   01.01.2016  Отдел продвижения  ...   6246,610169     694,0677966
100  01.01.2016  Отдел продвижения  ...   89694,91525     38440,67797
125  01.01.2016  Отдел продвижения  ...   879864,4068     377084,7458

[6 rows x 8 columns]

Выбор с указанной позиции до конца DataFrame через .loc

Полный код вывода данных из Pandas DataFrame:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.loc[2660:])

Результат запроса к DataFrame:

            Дата      Подразделение  ... Себестоимость Валовая прибыль
2660  01.12.2017       Отдел продаж  ...   762,7118644     84,74576271
2661  01.12.2017       Отдел продаж  ...   381,3559322     42,37288136
2662  01.12.2017       Отдел продаж  ...  -9915,254237    -5338,983051
2663  01.12.2017       Отдел продаж  ...   5314576,271     2861694,915
2664  01.12.2017       Отдел продаж  ...   154067,7966     17118,64407
2665  01.12.2017  Отдел продвижения  ...   15254,23729     1694,915254
2666  01.12.2017  Отдел продвижения  ...   9915,254237     5338,983051
2667  01.12.2017  Отдел продвижения  ...   1083686,441     361228,8136
2668  01.12.2017  Отдел продвижения  ...   3050,847458     338,9830508

[9 rows x 8 columns]

Тот же пример, но с шагом 3 (вывод каждого третьего элемента из Pandas DataFrame с использованием .iloc[]):

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.loc[2660::3])

Результат:

            Дата      Подразделение  ... Себестоимость Валовая прибыль
2660  01.12.2017       Отдел продаж  ...   762,7118644     84,74576271
2663  01.12.2017       Отдел продаж  ...   5314576,271     2861694,915
2666  01.12.2017  Отдел продвижения  ...   9915,254237     5338,983051

[3 rows x 8 columns]

Выбор строк и столбцов одновременно с .loc

В отличие от просто оператора индексирования, можно выбирать строки и столбцы одновременно с .loc. Вы делаете это, разделяя выбранные строки и столбцы запятой. Это будет выглядеть примерно так:

df.loc [row_selection, column_selection]

Пример запроса на Python 3:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.loc[[150,163],['Подразделение','Менеджер','Продажи']])

Результат:

         Подразделение Менеджер      Продажи
150       Отдел продаж   Петров   1067796,61
163  Отдел продвижения  Сидоров  13665,25424

Используйте любую комбинацию выбора для строки или столбца с .loc

Выбор строки или столбца может быть совершен любым из следующих способов:

• Один ярлык
• Список ярлыков
• slice с метками

Мы можем использовать любой из этих трех вариантов для выбора строки или столбца с помощью .loc. Давайте посмотрим несколько примеров.

Пример 1 «Выборка данных из Pandas DataFrame»:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.loc[150:163:3,['Подразделение','Менеджер','Продажи']])

Результат:

         Подразделение  Менеджер      Продажи
150       Отдел продаж    Петров   1067796,61
153  Отдел продвижения  Добряков  82944,91525
156  Отдел продвижения  Добряков  85023,30508
159       Отдел продаж    Петров  499385,5932
162  Отдел продвижения   Сидоров  130805,0847

Выбор строк и столбцов через переменные

Гораздо проще назначить список строк и столбцов переменным перед использованием в .loc. Это полезно, если вы выбираете много строк или столбцов:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

rows = [59, 134, 1045]
columns = ['Контрагент', 'Номенклатура', 'Продажи'] 
print(df.loc[rows, columns])

Результат:

        Контрагент Номенклатура      Продажи
59        ИП Лусон   Велосипеды  1139110,169
134        Союз АО       Прочее  622,8813559
1045  Эсвольтр ООО       Прочее  2915,254237

Пример параметризации с slice:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

iStart = 59
iEnd = 134
iStep = 7
columns = ['Контрагент', 'Номенклатура', 'Продажи'] 
print(df.loc[iStart:iEnd:iStep, columns])

Результат:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

iStart = 59
iEnd = 134
iStep = 7
columns = ['Контрагент', 'Номенклатура', 'Продажи'] 
print(df.loc[iStart:iEnd:iStep, columns])

Выборка данных из Pandas DataFrame с помощью индексатора .iloc[]

.iloc индексатор очень похож на .loc, но использует только целое число позиций, по которым необходимо сделать выборку.

Выбор одной строки при помощи .iloc

Передав одно целое число в .iloc, он выберет одну строку в качестве ряда:

Код запроса:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.iloc[5])

Результат:

Дата                  01.01.2016
Подразделение       Отдел продаж
Контрагент         Билли Боб ООО
Менеджер                Илинская
Номенклатура               Доски
Продажи              1263241,525
Себестоимость        884269,0678
Валовая прибыль      378972,4576
Name: 5, dtype: object

Выбор нескольких строк с .iloc

Используйте список целых чисел, чтобы выбрать несколько строк:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.iloc[[5,45,876]])

Результат:

           Дата      Подразделение  ... Себестоимость Валовая прибыль
5    01.01.2016       Отдел продаж  ...   884269,0678     378972,4576
45   01.01.2016       Отдел продаж  ...   162972,4576     69845,33898
876  01.08.2016  Отдел продвижения  ...   444322,0339     190423,7288

[3 rows x 8 columns]

Выборка диапазона строк через указание среза в .iloc

В случае с .iloc нотация слайса работает так же, как и список, и исключает последний элемент.

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.iloc[5:9])

Результат:

         Дата      Подразделение  ... Себестоимость Валовая прибыль
5  01.01.2016       Отдел продаж  ...   884269,0678     378972,4576
6  01.01.2016       Отдел продаж  ...   16517,47881     5505,826271
7  01.01.2016       Отдел продаж  ...   1098,305085     122,0338983
8  01.01.2016  Отдел продвижения  ...   22957,62712     9838,983051

[4 rows x 8 columns]

Выбор строк и столбцов одновременно в .iloc

Рассмотрим несколько примеров, чтобы понять, чем отличается .iloc от .loc.

Выберем две строки и два столбца:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.iloc[[2,3], [0,3]])

Результат:

         Дата Менеджер
2  01.01.2016  Сидоров
3  01.01.2016  Сидоров

Осуществим выборку строк и столбцов с помощью среза:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.iloc[2:9, 0:3])

Результат:

         Дата      Подразделение     Контрагент
2  01.01.2016  Отдел продвижения     Абакус ООО
3  01.01.2016  Отдел продвижения     Абакус ООО
4  01.01.2016       Отдел продаж  Билли Боб ООО
5  01.01.2016       Отдел продаж  Билли Боб ООО
6  01.01.2016       Отдел продаж  Билли Боб ООО
7  01.01.2016       Отдел продаж  Билли Боб ООО
8  01.01.2016  Отдел продвижения  Билли Боб ООО

Выберем 1 значение из столбца и указанной колонки:

import pandas as pd
import numpy as np

df = pd.read_csv('D:\#python#\example\SampleData_Pandas.csv', sep=';')

print(df.loc[3, 4])

Результат:

Палатки

Резюме по .loc и .iloc

Доступ к строкам и колонкам по индексу возможен несколькими способами:

• .loc — используется для доступа по строковой метке — т.е. фактически по значению индекса и по названию столбца
• .iloc — используется для доступа по числовому значению (начиная от 0) — т.е. по номеру строки и номеру столбца

Как выбрать строки из Pandas DataFrame по условию

Собираем тестовый набор данных для иллюстрации работы выборки по условию

Пишем скрипт:

import pandas as pd

Boxes = {'Color': ['Green','Green','Green','Blue','Blue','Red','Red','Red'],
         'Shape': ['Rectangle','Rectangle','Square','Rectangle','Square','Square','Square','Rectangle'],
         'Price': [10,15,5,5,10,15,15,5]
        }

df = pd.DataFrame(Boxes, columns= ['Color','Shape','Price'])
print (df)

Результат выполнения:

   Color      Shape  Price
0  Green  Rectangle     10
1  Green  Rectangle     15
2  Green     Square      5
3   Blue  Rectangle      5
4   Blue     Square     10
5    Red     Square     15
6    Red     Square     15
7    Red  Rectangle      5

Синтаксис выборки строк из Pandas DataFrame по условию

Вы можете использовать следующую логику для выбора строк в Pandas DataFrame по условию:

df.loc[df.column name condition]

Например, если вы хотите получить строки с зеленым цветом , вам нужно применить:

df.loc[df.Color == 'Green']

Где:

• Color — это название столбца
• Green — это условие (значение колонки)

А вот полный код Python для нашего примера:

import pandas as pd

Boxes = {'Color': ['Green','Green','Green','Blue','Blue','Red','Red','Red'],
         'Shape': ['Rectangle','Rectangle','Square','Rectangle','Square','Square','Square','Rectangle'],
         'Price': [10,15,5,5,10,15,15,5]
        }

df = pd.DataFrame(Boxes, columns= ['Color','Shape','Price'])
print (df.loc[df.Color == 'Green'])

Результат:

   Color      Shape  Price
0  Green  Rectangle     10
1  Green  Rectangle     15
2  Green     Square      5

Выберем строки, где цена равна или больше 10

Чтобы получить все строки, где цена равна или больше 10, Вам нужно применить следующее условие:

df.loc[df.Price >= 10]

Полный код Python:

import pandas as pd

Boxes = {'Color': ['Green','Green','Green','Blue','Blue','Red','Red','Red'],
         'Shape': ['Rectangle','Rectangle','Square','Rectangle','Square','Square','Square','Rectangle'],
         'Price': [10,15,5,5,10,15,15,5]
        }

df = pd.DataFrame(Boxes, columns= ['Color','Shape','Price'])

print (df.loc[df.Price >= 10])

Результат:

   Color      Shape  Price
0  Green  Rectangle     10
1  Green  Rectangle     15
4   Blue     Square     10
5    Red     Square     15
6    Red     Square     15

Выберем строки, в которых цвет зеленый, а форма — прямоугольник

Теперь цель состоит в том, чтобы выбрать строки на основе двух условий:

• Color зеленый; а также
• Shape = прямоугольник

Мы будем использовать символ & для применения нескольких условий. В нашем примере код будет выглядеть так:

df.loc[(df.Color == 'Green') & (df.Shape == 'Rectangle')]

Полный код примера Python для выборки Pandas DataFrame:

import pandas as pd

Boxes = {'Color': ['Green','Green','Green','Blue','Blue','Red','Red','Red'],
         'Shape': ['Rectangle','Rectangle','Square','Rectangle','Square','Square','Square','Rectangle'],
         'Price': [10,15,5,5,10,15,15,5]
        }

df = pd.DataFrame(Boxes, columns= ['Color','Shape','Price'])

print (df.loc[(df.Color == 'Green') & (df.Shape == 'Rectangle')])

Результат:

   Color      Shape  Price
0  Green  Rectangle     10
1  Green  Rectangle     15

Выберем строки, где цвет зеленый ИЛИ форма прямоугольная

Для достижения этой цели будем использовать символ | следующим образом:

df.loc[(df.Color == 'Green') | (df.Shape == 'Rectangle')]

Полный код Python 3:

import pandas as pd

Boxes = {'Color': ['Green','Green','Green','Blue','Blue','Red','Red','Red'],
         'Shape': ['Rectangle','Rectangle','Square','Rectangle','Square','Square','Square','Rectangle'],
         'Price': [10,15,5,5,10,15,15,5]
        }

df = pd.DataFrame(Boxes, columns= ['Color','Shape','Price'])

print (df.loc[(df.Color == 'Green') | (df.Shape == 'Rectangle')])

Результат:

   Color      Shape  Price
0  Green  Rectangle     10
1  Green  Rectangle     15
2  Green     Square      5
3   Blue  Rectangle      5
7    Red  Rectangle      5

Выберем строки, где цена не равна 15

Мы будем использовать комбинацию символов !=, чтобы выбрать строки, цена которых не равна 15:

df.loc[df.Price != 15]

Полный код Pandas DF на питоне:

import pandas as pd

Boxes = {'Color': ['Green','Green','Green','Blue','Blue','Red','Red','Red'],
         'Shape': ['Rectangle','Rectangle','Square','Rectangle','Square','Square','Square','Rectangle'],
         'Price': [10,15,5,5,10,15,15,5]
        }

df = pd.DataFrame(Boxes, columns= ['Color','Shape','Price'])

print (df.loc[df.Price != 15])

Результат работы скрипта Python:

   Color      Shape  Price
0  Green  Rectangle     10
2  Green     Square      5
3   Blue  Rectangle      5
4   Blue     Square     10
7    Red  Rectangle      5

Data Wrangling with Pandas

• Data Wrangling Pandas Cheat Sheet.pdf
• Data Wrangling With Pandas

Обработка данных с помощью Pandas (Data Wrangling)

Обработка данных является одной из важнейших задач в data science и анализе данных, которая включает такие операции, как:

• Dealing with missing values (Работа с пропущенными значениями) — количественная оценка пропущенных значений для каждого столбца, заполнение и удаление пропущенных значений.
• Reshaping data (Изменение формы данных) — единая кодировка данных, сводные таблицы, объединения, группировка и агрегирование.
• Data Sorting (Сортировка данных): упорядочивание значений в порядке возрастания или убывания.
• Data Filtration (Фильтрация данных): создание подмножества данных согласно тем или иным условиям.
• Data deduplication (Дедупликация данных) — это технология поиска и устранения дубликатов в хранилищах данных. Применяется для снижения накладные расходов на хранение информации.
• Data Reduction (Понижение размерности/Сокращение данных): Уменьшение объема данных, сокращение количества используемых признаков и разнообразия их значений. Применяется в случае, когда данные избыточны. Избыточность возникает тогда, когда задачу анализа можно решить с тем же уровнем эффективности и точности, но используя меньшую размерность данных. Это позволяет сократить время и вычислительные затраты на решение задачи, сделать данные и результаты их анализа более интерпретируемыми и понятными для пользователя.
• Data Access (Доступ к данным): для чтения или записи файлов данных.
• Data Handling/Data Processing (Обработка данных) или Data Transformation (преобразование данных): выполнение агрегации, статистических и подобных операций над конкретными значениями.
• Другое: Создание описательных столбцов, поэлементные условные операции.

Concatenation DataFrame

todo

Joining DataFrame

todo

Merging DataFrame

todo

Pivot & Melt (Unpivot) DataFrame

todo

GroupBy Операции

todo

Применение Lambda функции в DataFrame

todo

10 трюков Python Pandas, которые сделают вашу работу более эффективной

Pandas — это широко используемый пакет Python для структурированных данных.

read_csv

Все знают эту команду. Но данные, которые вы пытаетесь прочитать, велики, попробуйте добавить этот аргумент: nrows = 5, чтобы загружать только часть данных. Тогда вы можете избежать ошибки, выбрав неправильный разделитель (он не всегда может быть разделен запятой).

(Или вы можете использовать команду ‘head’ в linux, чтобы проверить первые 5 строк (скажем) в любом текстовом файле: head -n 5 data.txt)

Затем вы можете извлечь список столбцов, используя df.columns.tolist()для извлечения всех столбцов, а затем добавить аргумент usecols = [‘c1’, ‘c2’,…], чтобы загрузить нужные вам столбцы. 

Кроме того, если вы знаете типы данных нескольких определенных столбцов, вы можете добавить аргумент dtype = {‘c1’: str, ‘c2’: int,…}, чтобы он загружался быстрее. 

Еще одно преимущество этого аргумента в том, что если у вас есть столбец, который содержит как строки, так и числа, рекомендуется объявить его тип строковым, чтобы не возникало ошибок при попытке объединить таблицы, используя этот столбец в качестве ключа.

select_dtypes

Если предварительная обработка данных должна выполняться в Python, эта команда сэкономит вам время. После чтения в таблице типами данных по-умолчанию для каждого столбца могут быть bool, int64, float64, object, category, timedelta64 или datetime64. Вы можете сначала проверить распределение по

df.dtypes.value_counts()

чтобы узнать все возможные типы данных вашего DataFrame

df.select_dtypes(include=['float64', 'int64'])

выбрать sub-dataframe только с числовыми характеристиками.

copy()

Это важная команда, если вы еще не слышали о ней. Если вы выполните следующие команды:

import pandas as pd
df1 = pd.DataFrame({ 'a':[0,0,0], 'b': [1,1,1]})
df2 = df1
df2['a'] = df2['a'] + 1
df1.head()

Вы обнаружите, что df1 изменен. Это потому, что df2 = df1 не делает копию df1 и присваивает ее df2, но устанавливает указатель, указывающий на df1. Таким образом, любые изменения в df2 приведут к изменениям в df1. Чтобы это исправить, вы можете сделать либо

df2 = df1.copy()

или же

from copy import deepcopy
df2 = deepcopy(df1)

map()

Это классная команда для простого преобразования данных. Сначала вы определяете словарь, в котором «ключами» являются старые значения, а «значениями» являются новые значения.

level_map = {1: 'high', 2: 'medium', 3: 'low'}
df['c_level'] = df['c'].map(level_map)

Некоторые примеры:

True, False до 1, 0 (для моделирования); определение уровней; определяемые пользователем лексические кодировки.

apply or not apply?

Если мы хотим создать новый столбец с несколькими другими столбцами в качестве входных данных, функция apply иногда будет весьма полезна.

def rule(x, y):
    if x == 'high' and y > 10:
         return 1
    else:
         return 0
df = pd.DataFrame({ 'c1':[ 'high' ,'high', 'low', 'low'], 'c2': [0, 23, 17, 4]})
df['new'] = df.apply(lambda x: rule(x['c1'], x['c2']), axis =  1)
df.head()

В приведенных выше кодах мы определяем функцию с двумя входными переменными и используем функцию apply, чтобы применить ее к столбцам ‘c1’ и ‘c2’.

Но проблема «apply» в том , что иногда он слишком медленный . Скажем, если вы хотите вычислить максимум из двух столбцов «c1» и «c2», конечно, вы можете сделать

df['maximum'] = df.apply(lambda x: max(x['c1'], x['c2']), axis = 1)

но вы найдете это намного медленнее, чем эта команда:

df['maximum'] = df[['c1','c2']].max(axis =1)

Вывод: не используйте apply, если вы можете выполнить ту же работу с другими встроенными функциями (они часто быстрее). Например, если вы хотите округлить колонку «с» целыми числами, делать

round(df[‘c’], 0)

или

df[‘c’].round(0)

Вместо использования функции применяются: 

df.apply(lambda x: round(x['c'], 0), axis = 1)

value counts

Это команда для проверки распределения значений. Например, если вы хотите проверить возможные значения и частоту для каждого отдельного значения в столбце «c», вы можете сделать

df['c'].value_counts()

Есть несколько полезных трюков / аргументов:

1. normalize = True: если вы хотите проверить частоту вместо количества.
   
2. dropna = False: если вы также хотите включить пропущенные значения в статистику.
   
3. df['c'].value_counts().reset_index().: если вы хотите преобразовать таблицу статистики в кадр данных pandas и манипулировать ею
   
4. df['c'].value_counts().sort_index(): показать статистику, отсортированную по разным значениям, в столбце «c» вместо счетчиков.

number of missing values — количество пустых значений

При построении моделей может потребоваться исключить строку со слишком большим количеством пропущенных значений / строки со всеми пропущенными значениями. Вы можете использовать .isnull() и .sum() для подсчета количества пропущенных значений в указанных столбцах.

import pandas as pd
import numpy as np
df = pd.DataFrame({ 'id': [1,2,3], 'c1':[0,0,np.nan], 'c2': [np.nan,1,1]})
df = df[['id', 'c1', 'c2']]
df['num_nulls'] = df[['c1', 'c2']].isnull().sum(axis=1)
df.head()

выбрать строки с конкретными идентификаторами (select rows with specific IDs)

В SQL мы можем сделать это, используя SELECT * FROM … WHERE ID in (‘A001’, ‘C022’, …), чтобы получить записи с конкретными идентификаторами. Если вы хотите сделать то же самое с Pandas, вы можете сделать

df_filter = df['ID'].isin(['A001','C022',...])
df[df_filter]

Процентильные группы (Percentile groups)

У вас есть числовой столбец, и вы хотите классифицировать значения в этом столбце по группам, скажем, верхние 5% в группе 1, 5–20% в группе 2, 20–50% в группе 3, нижние 50% в группе 4 Конечно, вы можете сделать это с помощью pandas.cut, но я бы хотел предоставить здесь другую опцию:

import numpy as np
cut_points = [np.percentile(df['c'], i) for i in [50, 80, 95]]
df['group'] = 1
for i in range(3):
    df['group'] = df['group'] + (df['c'] < cut_points[i])
# or <= cut_points[i]

который быстро запускается (не применяется функция apply).

to_csv

Опять же, это команда, которую все будут использовать. Я хотел бы указать на две уловки здесь. Первый

print(df[:5].to_csv())

Вы можете использовать эту команду, чтобы распечатать первые пять строк того, что будет записано в файл точно.

Еще один трюк — это смешанные целые числа и пропущенные значения. Если столбец содержит как пропущенные значения, так и целые числа, тип данных по-прежнему будет плавающим, а не целым. Когда вы экспортируете таблицу, вы можете добавить float_format=‘%.0f’, чтобы округлить все числа с плавающей точкой до целых чисел. Используйте этот трюк, если вам нужны только целочисленные выходные данные для всех столбцов — вы избавитесь от всех назойливых ‘.0’s.

Сообщение Python 3 Pandas: Объекты Series и DataFrame. Построение Index появились сначала на Python 3 | Data Science | Нейронные сети | AI - Искусственный Интеллект.