Данные не то, что раньше. Десять лет назад организации работали со статичными рядами на складах. Теперь мы имеем дело с живыми продуктами, которые объединяют исходные данные, метаданные, логику преобразования, документацию, тесты и политики доступа. Мы используем это для всего, от базовой аналитики до сложных систем ИИ, принятия решений в режиме реального времени-сложность удерживает большинство команд.
Я видел, как команды пытаются координировать эти сложные системы, которые включают в себя сотни трубопроводов и зависимостей. Каждый день инженеры данных сталкиваются с фрагментированной оркестровкой, неэффективным распределением ресурсов и бесконечным пожаром. Большинство из них просто ошеломлены, пытаясь ответить после того, как неудачи уже нарушили производственные системы, в то время как злые заинтересованные стороны требуют ответов.
Почти каждый месяц мы видим, как простые изменения схемы вызывают каскадные сбои через нижестоящие трубопроводы. Команды тратят дни на картирование зависимостей, которые никто не задокументировал. К тому времени, когда все исправлено, критические сроки отчетности часто пропускаются.
Трехслойная проблема, нарушая современные команды данных
По моему опыту, современный оркестровка данных разрушается, потому что организации имеют дело с тремя уровнями, которые едва разговаривают друг с другом:
Эти слои работают в полных бункерах в большинстве компаний. Я видел, как изменение одной схемы в уровне данных может вызвать сбои на протяжении всего рабочих процессов и инфраструктуры. Без единой системы они всегда пытаются исправить вещи, когда ломаются.
Мы часто видим, что задания по прогнозированию машинного обучения проваливается в период с высоким трафиком. Команда данных добавляет новые поля, которые увеличивают размеры таблиц, но инфраструктурная группа не имеет видимости в этих изменениях и не может соответственно масштабировать ресурсы. Это приводит к значительному времени простоя в критических системах, таких как обнаружение мошенничества, в самые важные деловые периоды.
Предоставление ресурсов — это еще одна проблема, которую я наблюдал. Организации либо бросают слишком много денег на проблему, либо недооценивают и пропускают сроки. Пользовательские решения, которые создают команды, обычно усугубляют ситуацию.
Некоторые из наших клиентов часто управляют трубопроводами в тех случаях, которые сидят бездействующими большую часть времени из -за прошлых перебоев, которые создавали институциональный страх оптимизации. Это тратит впустую значительный объем облачного бюджета каждый месяц, но процесс утверждения для реализации автоматического масштаба обычно занимает больше времени, чем просто позволить ему сжигать деньги. Никто не хочет касаться того, что «работает».
Обычно можно найти несколько разных систем оркестровки в командах в одной и той же организации. Встроение занимает недели, потому что процессы существуют только как знание племен. Новые сотрудники часто нарушают вещи, потому что никто не документирует случайные случаи и обходные пути, которые все остальные запоминают.
Инженеры, как правило, тратят значительную часть своего времени, просто стандартизируя входящие данные из систем продаж. Форматы поля неожиданно изменяются, критическая информация отсутствует, и разные команды по -разному интерпретируют правила ввода. Много дней это больше похоже на то, чтобы быть уборщиком, чем инженером.
От реактивного пожаротушения до активного управления
Оркестрация данных должна развиваться от лоскутного беспорядка, который сейчас часто имеют в сплоченной стратегии полного стека. Существует необходимость объединить оркестровку между данными, рабочими процессами и инфраструктурой с наблюдаемой, встроенной на каждом уровне.
Когда мы внедрили межслойный мониторинг в моей нынешней компании, разница была немедленной.
При правильном мониторинге мы регулярно определяем ситуации, когда сторонние API изменяют размеры записей воздействия, прежде чем они достигнут производства. Вместо середины ночных звонков по бедствию, проблемы решаются в обычное рабочее время, и пользователи ниже по течению остаются незатронутыми. Это значительно улучшает как надежность системы, так и благополучие команды.
Унифицированная система преобразовала то, как мы подходим к надежности и доверительному доверию к нашим продуктам данных. Это дает нам видимость, в которой выполнялись задачи, их последовательность и соответствовали ли они соглашениям об уровне обслуживания (SLA). Это изменило не только наш технический подход, но и то, как бизнес -пользователи воспринимают наши данные.
После реализации отслеживания линии мы наблюдали, что аналитики перестали добавлять отказы от ответственности в свои отчеты. Ранее они начинали презентации с «предполагая, что данные верны…» Теперь они уверенно объясняют, откуда поступают данные, какие преобразования применялись и когда они были в последний раз подтверждены. Оценки доверия данных обычно показывают существенное улучшение после этих реализаций.
Преимущества единой оркестровки
Полное стек с оркестровкой обеспечивает конкретные преимущества, которые можно измерить. Интегрируя наблюдаемость повсюду, мы резко улучшили надежность и сделали управление зависимостями.
После реализации унифицированного отслеживания, среднее время для разрешения обычно падает от нескольких часов до минут. Команды могут мгновенно увидеть, что вызвало проблему, вместо того, чтобы все указывали пальцы и копаясь через журналы из нескольких систем.
Стандартизация также значительно увеличила нашу скорость развития. Команды могут двигаться быстрее и лучше сотрудничать, не борясь с разрозненными системами. Мониторинг ресурсов в реальном времени изменил наши затраты на инфраструктуру.
Компании часто видят значительное снижение облачных затрат, одновременно повышая надежность. Вместо того, чтобы чрезмерно повысить все, масштаб ресурсов на основе фактических потребностей. Многие команды выполняют задания в больших случаях вокруг часов, потому что никто не хочет нести ответственность за другой сбой, но автоматическое масштабирование на основе объемов входных данных устраняет эти отходы.
Самой большой победой для меня стало сдвиг в том, над чем на самом деле работает моя команда. автоматизация обрабатывает повторяющиеся задачи и пожаротушение, которые использовали большую часть нашего времени.
Команды с хорошей оркестровкой постоянно тратят больше времени на создание новых функций, чем на ремонт сломанных. Они развертывают продукты данных намного быстрее, чем раньше. Вращения по вызову трансформируются от гарантированных недель кошмаров до в основном тихих смен. Мы даже наблюдаем более низкие показатели оборота в организациях после внедрения этих изменений.
Будущее объединяется или бюст
Объединенная оркестровка имеет важное значение. Нам нужны платформы, которые включают лучшие практики разработки программного обеспечения, такие как автоматизация и самовосстановление, в управление данными. Без этого мы будем продолжать утонуть в сложности, поскольку объемы данных и бизнес -требования увеличиваются.
Когда системы данных работают надежно и быстро адаптируются, данные становятся подлинным стратегическим активом, а не чем -то, за что мы всегда извиняемся.
Компании, которые охватывают этот переход к объединенной, упреждающей оркестровке, получат конкурентное преимущество. Они превратят свои продукты данных в надежные, масштабируемые и безопасные активы, которые выполняют все эти обещания, которые мы даем для заинтересованных сторон в течение многих лет. Остальные будут продолжать сражаться, пока они не сгорят или не будут заменены.
InfluxData является создателем PlupuxDB, ведущей платформы временных рядов, используемой для сбора, хранения и анализа данных всех временных рядов в любом масштабе. Разработчики могут запрашивать и анализировать свои данные, отмеченные временем в режиме реального времени, чтобы открыть, интерпретировать и обмениваться новыми идеями, чтобы получить конкурентное преимущество. Узнайте больше новейших из InfluxData Trending Stories YouTube.com/ThenewStack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Джулиан Лейнве, технический директор Astronomer, ведущей в отрасли платформы Unified DataOps, работающая на Apache Airflow® Подробнее от Julian Laneve
