ПРИМЕР ВОЗДУШНОГО ПОТОКА: ДОКАЗАТЕЛЬСТВО ПОРТА
Это первое в серии тематических исследований о том, как я спроектировал и разработал конвейер приема данных производственного уровня (ETL-конвейер) с использованием Apache Airflow.
Airflow-это инструмент с открытым исходным кодом под управлением Apache Software Foundation, разработанный Airbnb. Проще говоря, Air flow-это платформа для организации рабочего процесса. Тем не менее, он чаще всего используется для обработки данных (ETL). Он был очень успешным и стал отраслевым стандартом для пакетной обработки данных.
ФОН
Компания, в которой я работал в стартапе под названием Proof Port в течение последних 6 месяцев. До закрытия Proof Port был самым быстрым и простым способом автоматического обмена и поддержания актуальной информации о соответствии с поставщиками, поставщиками и клиентами B2B.
Я начал работать в порту 1 июля 2019 года. Они пытались запустить в течение 2 или 3 месяцев. И после нескольких итераций конвейеров данных, которые не сокращали его, они (по понятным причинам) стремились заставить работать часть данных приложения.
Требования
• Ingest a total of 8,000+ records from 8 different data sources weekly • Require minimal code changes when adding new data sources in the future • Compare the two most recent data runs, and capture the differences between them: adds, deletes, and changes • Detect company name changes (e.g. when a company name changes from "Federal Express" to "FedEx") • Ingest data from web pages, Excel files, and PDFs • Perform Optical Character Recognition (OCR) on the PDFs to harvest meaningful data • Facilitate manual human intervention for data audits to ensure premium data quality • Capture the data at each stage in the ETL process for auditing purposes • Capture and log high-level analytics on the data such as the number of adds, changes, and deletes • Load the data into ProofPort's backend system using GraphQL APIs • Uphold the ProofPort measure of quality: "The data in the our app must match the data as it appears in the public sources at the time of data capture."
TL DR; производственный сквозной трубопровод ETL в течение 3 месяцев. С нуля.
ПОНИМАТЬ
Как бы ни было заманчиво сразу же приступить к работе и начать кодировать во все ночные часы, я оставался спокойным и провел первые несколько дней, задавая тонны вопросов и пытаясь понять проблему. Я подошел к доске, набросал архитектуру системы и доменные сущности так хорошо, как я их понимал, и попросил откликов от моих новых коллег. В частности, я много спрашивал: “Почему?” вопросы:
Почему система была спроектирована таким образом? Почему была выбрана именно эта технология? Почему не эта альтернатива? Почему в прошлом произошел сбой конвейера данных?
Эти первые несколько дней были критическими. В конечном счете, цель программного обеспечения-обеспечить невероятную ценность для бизнеса. Поэтому крайне важно, чтобы вы поняли проблему бизнеса. Затем, с дисциплиной, вы можете использовать это понимание для оценки потенциальных инструментов и фреймворков.
В конечном счете, цель программного обеспечения-обеспечить невероятную ценность для бизнеса.
Чтобы привести пример, с портом Proof мы оценили Stitch как потенциальную платформу ETL. Хотя это сравнение может легко оправдать его собственный пост в блоге, Stitch-это система ETL на основе пользовательского интерфейса, ориентированная на подключение различных источников данных друг к другу. Он не позволяет записывать и вводить пользовательские преобразования в конвейер. Для сравнения, Airflow-это платформа оркестровки рабочих процессов, поэтому она имеет более общую область применения по дизайну. Вы можете расширить поток воздуха, чтобы организовать практически любой тип рабочего процесса, который только можно себе представить. Как только я понял необходимость ProofPort внедрить довольно сложную аналитику (обнаружение изменений названия компании и т. Д.) И даже облегчить несколько пунктов ручного вмешательства, стало ясно, что Stitch не будет работать для нашего варианта использования.
Рассмотрев одну или две альтернативы, мы решили использовать воздушный поток. Его гибкость и готовая интеграция в фактическую экосистему науки о данных (Python!) Трудно превзойти.
Еще несколько слов о понимании — многие люди будут просто стремиться понять текущие потребности под лозунгом гибкой разработки программного обеспечения (еще один пост в блоге, который мне придется написать). Будущие потребности в лучшем случае непредсказуемы, а в худшем-неизвестны. Но это не значит, что они неважны. Принимая архитектурные решения, вы должны спросить: “Что, вероятно, изменится в будущем?”. Этот простой вопрос будет обосновывать ваши решения. Это помешает вам далеко продвинуться по дороге только для того, чтобы позже понять, что у вас есть новые требования, которые полностью разрушают вашу архитектуру.
В порту Proof решение пойти с воздушным потоком стало еще более ясным, когда я задал вопросы о будущих требованиях. Было просто слишком много частей, которые нуждались бы в пользовательской бизнес-логике. Это был явный признак того, что нам нужно отказаться от готового решения (Stitch) в пользу более индивидуального решения (Airflow).
ИТЕРАЦИЯ
К концу первой недели или около того у меня был составлен очень грубый набросок, который выглядел следующим образом:
Короче говоря, план состоял в том, чтобы использовать Import.io для веб-очистки HTML-страниц, простых пакетов Python для обработки файлов Excel, а затем AWS Textract для распознавания текста (позже мы вместо этого использовали Camelot). Затем мы бы собрали все источники данных в общий формат хранения данных (фрейм данных Pandas). Наконец, мы напишем код для сравнения двух фреймов данных и создания различий.
В течение нескольких недель у меня был небольшой прототип, который работал, собирая данные из Import.io и создание фреймов данных, и сравнение фреймов данных.
Совет профессионала: Один из ключей к тому, чтобы воздушный поток работал локально и быстро развертывался, – это использование Astronomer. Астроном предлагает решение “Воздушный поток как услуга”, и это фантастика. Они предлагают бесплатный инструмент CLI, который в кратчайшие сроки позволит вам работать с воздушным потоком на вашем локальном компьютере с помощью Docker. Кроме того, они предлагают размещенное решение для воздушного потока; это упрощает развертывание.
Вместе с потрясающей командой в Proof Port мы много раз повторяли конвейер данных. Я бы показал немного функциональности, аудитор данных проверил бы данные и дал обратную связь по любым вопросам, которые он обнаружил. Эти проблемы либо превратятся в исправления ошибок, либо будут добавлены новые функции. Промойте и повторите процедуру.
Это указывает на важность итеративной разработки не только в программном обеспечении в целом, но и, в частности, в работе, связанной с данными. Вы просто не знаете, чего вы не знаете о данных. Часто наборы данных настолько велики и неуправляемы, что особенности и повреждения данных не проявляются до тех пор, пока вы не начнете больше работать с данными. Вот почему очень важно, чтобы вы разрабатывали свой конвейер итеративно.
Тестирование
Преимущества (читай: “необходимость”) надлежащего тестирования при разработке программного обеспечения были тщательно установлены в других местах. Здесь я просто рассмотрю его связь с конвейером данных воздушного потока.
Из-за невероятного разнообразия данных, которые могут поступать через конвейер данных, если у вас нет тестов для проверки вашей основной бизнес-логики, вопрос не в том, “если”, а в том, “когда” ваши данные будут повреждены.
Кто-то будет регулярно проверять выходные данные конвейера, но по мере добавления дополнительных функций он или она, конечно, не будет проверять каждую возможную комбинацию функций данных с каждым новым выпуском. Вместо этого, скорее всего, будет реализована какая-то стратегия обеспечения качества “Шесть сигм” или связанная с ней концепция. Это мощный способ измерения качества, но он предполагает, что базовая система остается постоянной! Все это предположение недействительно, если у вас нет автоматизированного тестирования для проверки вашей основной бизнес-логики.
При разработке конвейера ETL в Proof Port я написал обширные модульные тесты вокруг библиотеки основного кода (которая отвечала за извлечение, преобразование и загрузку данных). Эти тесты были дополнительно проверены путем сравнения результатов нашего инструмента diff с Import.io это другой инструмент. Это иллюстрирует еще одну важную и знакомую идиому: “Доверяй, но проверяй.”
Автоматизация
“Мы сократили время, затрачиваемое на ручные аудиты, на 90%”
К моему удивлению, в конце 3 месяцев у нас был рабочий производственный конвейер ETL, и поэтому мы запустили приложение. Затем я провел следующие несколько месяцев, сосредоточившись на добавлении новых функций, а также на автоматизации как можно большей части процесса. Это был огромный урок для нас. Любое время, потраченное на автоматизацию процесса ручного вмешательства человека в загрузку данных, окупилось чрезвычайно. На диаграмме выше вы можете увидеть “статистические аудиты”. Они не требовались для запуска, но идея состояла в том, чтобы автоматизировать большую часть работы человека-аудитора.
Мы разработали несколько автоматизаций, но одним из лучших примеров была автоматизация изменения названия компании. Изменение названия компании приведет к добавлению записи (например, “FedEx”) и удалению записи (например, “Federal Express”) в выводе diff. Если набор данных diff не содержит как добавленных, так и удаленных записей, мы могли бы продолжить и загрузить его в производство. Другой простой автоматизацией была проверка, изменилось ли что-нибудь вообще между двумя запусками данных. Если нет, то выводом инструмента diff будет пустой набор данных, и мы просто обновим некоторые метаданные для этого конкретного запуска данных.
С помощью нескольких таких оптимизаций, по оценкам нашего аудитора, мы сократили время, затрачиваемое на ручной аудит данных, на 90%.
Slack оказался полезным инструментом для создания простого пользовательского интерфейса для конвейера ETL. Перед закрытием магазина мы экспериментировали с пользовательским ботом Slack, который позволял аудитору данных подтверждать или отклонять изменения названия компании одним нажатием кнопки, и все это в окне канала Slack.
ДОСТАВЛЯТЬ
Одним из ключевых требований была возможность связать потоки данных между несколькими DAG воздушного потока (направленные ациклические графики). В своей основе это довольно распространенная проблема в разработке ETL. В основном вам нужен какой-то способ сохранения метаданных для ведения записей, а также для повторного запуска данных по мере необходимости. Мы решили эту проблему, создав уникальный идентификатор (GUID) для каждого запуска данных (из которых есть 3 шага или фазы). Мы создали каталог внутри корзины Amazon S3 с этим идентификатором и сохранили все файлы, представляющие каждый этап преобразования в конвейере для запуска этих данных в этот каталог. Этот уникальный идентификатор также был включен в уведомления о сообщениях Slack. Таким образом, по сути, мы создали систему с разделением проблем, но все еще связанную вместе, чтобы представить полную историю данных.
“ваш план ETL с использованием воздушного потока превратил ненадежную головную боль процесса ETL в стратегический актив для нашего бизнеса, на который клиенты могут положиться”, — Марк Хэмм, генеральный директор ProofPort
Пользователь-человек (аудитор данных) обновит переменные воздушного потока, чтобы указать на конкретные import.io запускает (при желании), а затем запускает первую фазу DAG для каждого источника данных. DAG будет запускать и обновлять файлы в S3 и метаданные в DynamoDB. Он также обновил некоторые метаданные в переменных воздушного потока. Когда DAG завершится, он отправит уведомление Slack, которое включало ссылку на файл набора данных для аудита на S3 и ссылку на вторую фазу DAG для запуска. Аудитор загружал файл из S3, вносил необходимые изменения, загружал его в S3, а затем начинал на следующий ДЕНЬ. Этот процесс повторится еще раз, и он будет завершен.
До того, как стартап закрылся, я работал над дальнейшей автоматизацией этого процесса, чтобы аудитору просто предоставлялись решения “да/нет” в сообщениях Slack с интерактивными кнопками.
Этот подход дал нам гибкость для автоматизации того, что мы могли бы автоматизировать, в то же время позволяя аудитору данных вносить изменения, если это необходимо, в различные точки конвейера.
За 3 месяца мы разработали производственный конвейер ETL, который еженедельно принимал тысячи записей, сравнивал их с самыми последними данными и загружал различия в очищенном формате в наше веб-приложение через API GraphQL.
Генеральный директор Proof Port сказал, что этот трубопровод ETL “превратил ненадежную головную боль процесса ETL в стратегический актив для нашего бизнеса, на который клиенты могут положиться”. Он добавил, что “подключение воздушного потока к утверждениям данных slack было трансформационным и устранило некоторые основные затраты на ручной аудит”.