🎯 Как выбрать инструменты Data Engineering❗

Простой фреймворк с 13 критериями… 💥💥💥

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

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

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

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

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

Архитектурный дизайн является обязательным перед выбором любого инструмента. Думайте об архитектуре как о стратегическом руководстве, отвечающем на вопросы 3W("что", "почему" и "когда"), и инструментах для реализации этой архитектуры. Авторы книги Основы инженерии данных — Джо Рейс и Мэтт Хаусли придумали этот подход как сначала архитектуру, а затем технологии.

Тем не менее, я чувствую, что это должно называться:

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

Как выбрать инструменты Data Engineering?

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

Чтобы упростить выбор, мы обсудим следующие 13 критериев —

Потребности бизнеса и влияние
Все дело в команде
Скорость для безопасной и надежной доставки
Совместимость и гибкость
$$$$$
Строить или покупать?
Открытый исходный код и не только
Пользовательский интерфейс (UI) и существующее кодирование
Источники данных и облако
Перспективные решения
Monolith vs. Modular vs. Monolith Modular
Бессерверные и серверные решения
Управление данными и DataOps

Давайте углубимся в каждый из них…

1. Потребности бизнеса и влияние

Крайне важно, чтобы выбор инструментов производился с помощью бизнес-объективов. Data Engineer должен спросить:

Как технология XYZ помогает бизнесу добиться большей ценности и конкурентного преимущества?

Может ли быть лучшая альтернатива для удовлетворения потребностей бизнеса?

Получили ли вы зеленый свет от ключевых лиц, принимающих решения?

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

2. Все дело в команде

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

Узнайте о размере команды, ее навыках и возможностях.

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

Спросите свою команду, как бы они отнеслись к изучению технологии XYZ? Кто станет партнером для проведения проверки концепции?

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

3. Скорость для безопасной и надежной доставки

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

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

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

4. Совместимость и гибкость

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

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

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

5. $$$$$

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

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

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

Общая стоимость владения (TCO)
CapEx (фиксированная начальная стоимость) VS. OpEx (оплата по мере использования)
Общая альтернативная стоимость владения (TOCO)

Opportunity Cost = Return on option NOT chosen — Return on chosen option

6. Вы должны построить или купить?

Когда создавать? Если вас беспокоят безопасность и конкурентное преимущество, можно выбрать сборку. Спросите себя: подходит ли инструмент, доступный на рынке, для варианта использования компании? Хочет ли компания сосредоточиться на исследованиях и разработках для новых возможностей? Строительство дешевле?

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

7. Открытый исходный код и не только

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

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

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

8. Пользовательский интерфейс (UI) и существующее кодирование

Пользовательский интерфейс (веб, CLI, GUI) может сыграть достойную роль в управлении данными и мониторинге потока данных. Некоторые инструменты конвейера данных предлагают визуальные пользовательские интерфейсы с перетаскиванием или электронные таблицы. Другие используют сценарии или кодирование. Давайте рассмотрим пример инструмента конвейера данных — Fivetran, который предлагает веб-интерфейс (вообще без программирования) для подключения пользователя к источникам данных и загрузки данных в облачное хранилище данных. С другой стороны, инструмент Prefect ETL требует, чтобы ETL был написан на языке Python. Существует веб-интерфейс для мониторинга и тестирования развернутого потока в Prefect ETL, а также нет выхода из кодирования ETL.

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

9. Источники данных и облако

Источниками данных могут быть приложения SaaS, Rest API, базы данных, файлы, события или ручные файлы. Формат данных также может быть другим; это могут быть Json, Parquet, XML, файлы журналов, HDFS и т. д. Инженерам данных необходимо выбирать инструменты, совместимые с источниками данных и форматами файлов. Если некоторые инструменты несовместимы с определенным форматом данных, в этом случае можно использовать облачные функции (AWS Lambda или Google Cloud Function) для их преобразования в совместимый формат. Например, Fivetran еще не совместим с форматом XML, поэтому с помощью AWS Lamda можно конвертировать XML в Json и продолжать использовать Fivetran.

Что касается облака, какое расположение следует выбрать — локальная инфраструктура, облако или гибрид? Есть ли у вас понимание структуры ценообразования в облаке? Сколько будет стоить извлечение, анализ или перенос данных из облака? Как вы могли бы оптимизировать стоимость использования облака? Должен ли приоритет отдаваться мультиоблачному сервису (пример Snowflake)?

10. Перспективные решения

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

Неизменяемые технологии обычно служат базой в архитекторе. Было бы больно менять их в будущем. Например, выбор языка программирования (Python Scala, Go и т. д.) или вариант облачного провайдера (AWS, GCP, Azure или мультиоблако) может быть почти неизменным.

Будут ли в будущем неизменяемые технологии? Есть ли четкая дорожная карта? Могли бы вы использовать какие-то переходные технологии и изменить их в будущем?

11. Monolith против Modular против Monolith Modular

Инженерный блог Shopify прекрасно рассказывает о монолитах и модульных монолитах —

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

Шаблон распределенного монолита — это распределенная архитектура, которая все еще страдает от многих ограничений монолитной архитектуры.

12. Бессерверные решения против серверов

Сервер (или серверные вычисления) — это не что иное, как внутренняя серверная инфраструктура, необходимая для программного обеспечения или продуктов данных.

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

Backend-as-a-Service (например, AWS Lamda) и функции-как-сервис — два популярных варианта бессерверной архитектуры.

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

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

13. Управление данными и DataOps

DataOps — это набор культурных привычек. Это DevOps для данных и в основном для данных как продукта.

Как определено Gartner, «Управление данными (DM) состоит из практик, архитектурных методов и инструментов для обеспечения согласованного доступа и доставки данных по всему спектру предметных областей данных и типов структур данных на предприятии, чтобы соответствовать требования к потреблению данных всеми приложениями и бизнес-процессами.

DataOps — это набор культурных привычек. Это DevOps для данных и в основном для данных как продукта.

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

Безопасность — как данные защищены от взломов как снаружи, так и внутри? Какие инструменты предлагают контроль безопасности, контроль доступа пользователей и т. д.?
Нормативно-правовые акты. Как обеспечить соблюдение GDPR, CCPA и других нормативных актов о конфиденциальности данных? Позволяет ли имеющийся инструмент размещать данные в соответствии с GDPR, CCPA и другими правилами конфиденциальности данных?
Качество данных. Как вы обеспечиваете качество данных и то, что я просматриваю правильные данные?
Каталог данных — Какие инструменты будут поддерживать обнаружение и каталогизацию данных?
Автоматизация — какая технология больше помогает в автоматизации интеграции или доставки данных?
Наблюдение и мониторинг — при оценке новой технологии, насколько вы контролируете развертывание нового кода, как вы будете предупреждены, если возникнет проблема?
Оповещения и отчеты об инцидентах — как вы будете реагировать, когда возникнет проблема? Как вы будете решать проблемы? Какой будет реакция на инцидент?

Об авторе

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

Вы можете найти его на LinkedIn.

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

Отказ от ответственности: некоторые из вышеперечисленных критериев перефразированы из Основы инженерии данных — Джо Рейс, Мэтт Хаусли.

Подпишитесь📱, чтобы быть в курсе следующих статей. 🔔

Спасибо, что прочитали эту статью. 🙌 🙌