Автоматизированный, Без кода Стек данных
Научиться Astera Data Stack может упростить и оптимизировать управление данными вашего предприятия.
Вопросы и ответы с Барри Девлином об автоматизированных конвейерах данных
Автоматизированные конвейеры данных - важная часть головоломки хранилища данных. Они позволяют современным предприятиям поддерживать точные и высококачественные данные, которые подпитывают их инициативы в области бизнес-аналитики и аналитики. Мы недавно запустили Astera DW Builder — надежный конструктор хранилищ данных, который радикально ускоряет построение, оркестрацию и управление конвейерами данных, позволяя быстрее принимать решения на основе данных.
Astera Саморегулируемые конвейеры данных DW Builder позволяют беспрепятственно наполнять хранилище данных межкорпоративными данными. Используя автоматизированные функции ETL и ELT продукта, вы можете проследить путь данных от источника до аналитической информации с минимальными ручными усилиями.
Недавно у нас была возможность пообщаться с Барри Девлином, выдающимся авторитетом во всех вопросах, связанных с хранением данных, от лучших практик бизнес-аналитики до больших данных и не только. Вот некоторые идеи, которые Барри высказал по ключевым вопросам конвейерной обработки данных в современном EDW.
Современные хранилища данных обрабатывают огромные объемы данных. Когда дело доходит до создания конвейеров данных, которые могут активно доставлять такие большие объемы данных, какие рекомендации вы бы порекомендовали?
Что ж, прежде чем говорить о лучших практиках, я бы хотел заранее применить одну лучшую практику, которая определяет и уточняет некоторые фразы, которые мы здесь будем использовать. [Это] потому, что в настоящий момент на рынке существует очень много разных значений ключевых слов и фраз.
Итак, во-первых, конвейеры данных. Многие люди используют эту фразу для обозначения полного интегрированного пути от исходных данных до инструментов, используемых бизнесменом. Я вижу, что вы используете этот термин не столько сфокусировано на этом пути от «от супа до орехов», сколько на возможности более короткого конвейера между, скажем, различными компонентами, такими как экземпляр SAP и поток посещений веб-сайта в корпоративное хранилище данных. Я считаю, что это лучший подход и тот, у которого больше шансов на успех.
Во-вторых, возникает вопрос, что мы имеем в виду, когда говорим «хранилище данных». Потому что существует много противоположных подходов. Итак, в большинстве случаев, когда я говорю о хранилище данных, я имею в виду двухуровневую структуру, состоящую из корпоративного хранилища данных, EDW и, в общих чертах, третьей нормальной формы — или, что более вероятно сегодня, модели хранилища данных — питающей несколько витрин данных, многие из которых могут иметь размерную природу. И это не исключает других структур, большинство из которых являются упрощением этого двухуровневого подхода.
Наконец, я буду использовать фразу «подготовка данных или информации», чтобы охватить все типы обработки, такие как ETL, ELT, потоковая передача, автоматизация хранилищ данных и даже виртуализация данных, поскольку все эти последние термины представляют собой конкретные случаи подготовки данных и информации или технические подходы к этому.
Итак, сказав это заранее, позвольте мне рассказать о лучших практиках, о которых вы меня спрашивали, и я собираюсь ограничиться тремя, но их гораздо больше.
Итак, прежде всего я бы сказал, что это простые в использовании комплексные инструменты и средства автоматизации — и это довольно очевидно. Data prep [подготовка] — самая затратная часть хранилища данных. Таким образом, создание групп программистов для создания множества противоречивых и неподдерживаемых индивидуальных решений осталось или должно уйти в прошлое. Это пункт первый.
Вторая лучшая практика: правильно провести этап проектирования, тесно и постоянно вовлекая бизнес в этот процесс. Это означает итеративный, гибкие подходы к разработке [то есть] меньше о доставке бизнес-приложений, но больше о доставке полезных частей объема информации хранилища данных.
И в-третьих, я бы сказал, обслуживание и управление изменениями. Это ключевые особенности, которыми часто пренебрегают. Поэтому сосредоточьтесь на том, чтобы обновления и обслуживание рассматривались как можно раньше, и внедрите процесс, тесно связанный с первоначальным проектированием и сборкой.
Итак, возвращаясь к моему первому тезису, инструменты и автоматизация играют центральную роль в том, чтобы это произошло. Итак, есть три передовых метода, которые, на мой взгляд, действительно важны в этой области.
ETL был синонимом хранилища данных с момента появления этой технологии. Как развивался этот процесс в эпоху так называемых больших данных, которые мы имеем сейчас? Какие инновации вы видите, которые могут снизить стоимость и сложность традиционного ETL?
Я считаю, что нам всегда нужно учиться у истории. На мой взгляд, подготовка данных развивалась урывками с частыми шагами назад. Например, в последнее время исходные озера данных и облачные хранилища данных очень часто заполнялись с помощью скриптов и аналогичных программных решений в Hadoop. Для меня это было большим разочарованием.
Приятно видеть, что сейчас происходит переориентация на автоматизированные инструменты. Долгосрочная тенденция заключалась в широком переходе от ручных и индивидуальных решений к использованию ETL, а в последнее время и инструментов ELT. Это было дополнено переходом от пакетной доставки данных к различным подходам к поэтапной доставке, поскольку объемы данных увеличиваются, а бизнес требует все более и более своевременной информации.
В прежние времена ETL был полностью основан на операционных системах, часто старомодных по конструкции и со множеством загадочных кодов. Понимание сложностей, а также глубоких бизнес-правил, которые устарели, но все еще присутствовали в системе, было ключевым требованием для ETL-программиста.
Кроме того, существовало абсолютное требование ограничить влияние на операционные системы, [с точки зрения] их конструкции и производительности. Инженеры ETL должны были быть глубокими экспертами в загадочных структурах и содержимом этих устаревших исходных систем.
Хорошей новостью является то, что операционные системы зачастую лучше спроектированы, более современны и иногда облачны. Таким образом, теперь меньше необходимости иметь дело с загадочными системами и больше внимания уделять инновационному дизайну и целевым системам. Конечно, [это] снижает затраты и сложность подготовки данных.
Однако внешние источники данных, такие как Интернет вещей (IoT), действительно порождают новые потребности как с точки зрения своевременности данных, так и с точки зрения типов используемой аналитики. Итак, с технической стороны нам также необходимо рассмотреть подходы потоковой передачи, пакетной загрузки или репликации.
Менее архаичные источники также позволяют перейти от заказных преобразований, запрограммированных вручную, к более основанному на модели или метаданным подходу к подготовке информации, который действительно лежит в основе автоматизации хранилищ данных.
Вы пару раз упомянули, что ELT — это новый, получивший распространение подход. Как вы видите это по отношению к ETL? Являются ли эти подходы взаимодополняющими или здесь происходит нечто противоположное?
Я думаю, что по этому поводу возникает много вопросов, но, во-первых, я хотел бы сказать кое-что, что, по моему мнению, ETL был действительно неудачным выбором терминологии на заре. Извлечение, преобразование и загрузка — потому что это фокусирует внимание на последовательности действий, а не на общем процессе, поэтому я предпочитаю использовать термин «данные» или «подготовка информации».
Порядок и расположение шагов для меня менее важны, чем то, как мы на самом деле их выполняем. Надеюсь, каким-то образом, основанным на метаданных. Итак, стоит также отметить, что трансформация — это самый сложный и важный этап процесса, и понимание того, где она происходит, оказывается ключевым моментом при проектировании.
Итак, это сказано и вернемся к вашему вопросу. ELT — извлечение, загрузка и преобразование — просто означает, что преобразование происходит в целевой среде с использованием вычислительной мощности таких подходов, как найденная там реляционная база данных. Это хорошо? Ага. По большей части.
Преобразование в исходной системе (возможно, его следовало бы назвать преобразованием, извлечением и загрузкой [TEL]) в той или иной степени всегда выполняется, но исторически сводилось к абсолютному минимуму, чтобы уменьшить влияние на исходную систему. Переход на промежуточную систему — ETL — был тогда очевидным выбором, сводящим к минимуму воздействие как на исходную, так и на целевую системы.
Тем не менее, целевые системы, особенно в облаке, практически не имеют ограничений по производительности, а целевая реляционная СУБД обладает хорошими способностями к трансформации, поэтому ELT имеет большой смысл, и да, я действительно думаю, что они дополняют друг друга, и особенно кажется, что подход, сочетающий в себе ETL и ELT, кажется для меня он является наиболее гибким и мощным, особенно если есть некоторый интеллект и автоматизация при выборе того, когда и при каких обстоятельствах функция передается с сервера ETL [т. е.], где она впервые определяется и запускается в целевой системе. Итак, абсолютно! Это не вопрос выбора между ними двумя. Я думаю, что они оба могут сосуществовать, и я думаю, что это действительно хороший подход.
Как вы гарантируете, что в ваше хранилище данных будут поступать правильные данные, которые будут оптимально объединены и преобразованы в соответствии с требованиями отчетности и аналитики? Какие советы вы бы дали организациям, которые стремятся обеспечить качество данных в своих корпоративных хранилищах данных?
О, это отличные вопросы. Я имею в виду, что качество играет центральную роль во всех формах принятия решений, основанных на данных или, я бы сказал, на более точной информации. Итак, первое, что для меня всегда — это тщательная и качественная работа по моделированию данных или информации. Я знаю, что некоторые люди поднимут руки и скажут: «О, это слишком медленно [и] слишком дорого. Давайте создадим схему при чтении». Но, честно говоря, я не думаю, что есть какой-либо другой способ получить высокосогласованные данные в вашем хранилище, кроме предварительного моделирования.
Итак, это действительно важно, и я думаю, что такое моделирование можно и нужно проводить поэтапно — гибкий поэтапный подход. Это огромная тема и, вероятно, для другого дня. Я знаю, что многие организации остановились на подходе к полноразмерному хранилищу данных, который может быть идеальным для предприятий среднего размера.
Но для более крупных предприятий обычно предпочтительнее использовать согласованное хранилище согласованных основных данных и EDW для создания и поддержания данных и информации оптимального качества. И, наконец, помимо моделирования, найм хорошей и гибкой команды моделирования, вероятно, является следующим наиболее важным аспектом внедрения первоклассной среды подготовки данных.
Я бы предположил, что в организациях среднего размера подход к автоматизации хранилища данных, вероятно, является лучшим как с точки зрения качества, так и с точки зрения стоимости, поскольку обычно он включает этап моделирования в процессе продвижения вперед.
[Скажем] эта архитектура, которая у вас есть, построена. У вас есть несколько конвейеров данных, поступающих из разных исходных систем. Вы упомянули операционные системы, возможно, потоки Интернета вещей, [так что] здесь есть много возможностей, когда вы говорите о современном предприятии. Здесь работают разные задержки данных и во многих случаях взаимозависимости. Организация всего этого, очевидно, является непростой задачей. Что, по вашему мнению, является важным элементом для правильного получения этой части уравнения?
Ну, во-первых, я хотел бы сказать, что мы всегда имели дело с несколькими конвейерами данных, поступающими из разных исходных систем с разными задержками и взаимозависимостями данных, как вы упомянули — конечно, на крупных предприятиях, с которыми я имел дело.
Я думаю, что более важным аспектом сегодня, и вы упомянули об этом, является то, что мы стремимся поглощать и анализировать огромные объемы необработанных данных, и часто это грязные данные — и неизвестно, насколько они грязные — из сети и Интернета. вещи. И такие данные имеют характеристики, сильно отличающиеся от данных операционной системы, которые я называю данными, опосредованными процессом, или для краткости PMD, которые были основными источниками данных, скажем, 10 лет назад.
Итак, учитывая эту разницу в качестве данных, я бы сказал, что попытка поместить все эти новые данные в то же хранилище данных, что и ваш PMD, является ошибкой. Вам нужны несколько столпов обработки данных. Я объяснил все это в своей книге «Деловая неразведка», так что если вы хотите нырнуть туда глубже, сделайте это. Некоторые из этих столпов будут традиционными хранилищами данных, другие будут больше похожи на озера данных, но все они, конечно, будут снабжаться конвейерами данных, как я определил ранее в интервью.
Итак, ключом к хорошей работе всего этого, конечно же, является обеспечение того, чтобы данные в этих основных компонентах были хорошо взаимосвязаны, взаимосвязаны и согласованы, в отличие от того, что мы видели в традиционных хранилищах данных, и то, что вы называете оркестровкой по конвейерам данных, является ключевой компонент в достижении этой цели.
Теперь это возвращает нас к моделированию, а также к метаданным, поскольку метаданные являются важным элементом в организации всех этих конвейеров. Теперь я предпочитаю называть это информацией о настройке контекста, или CSI, потому что этим словом «мета» в наши дни немного злоупотребляют, даже Facebook принял его.
Таким образом, такого рода информация для настройки контекста содержится и упоминается в архитектуре Data Fabric Architecture компании Gartner, и на самом деле это идея быть активным, активно поддерживаться и поддерживать внутреннюю согласованность и согласованность с меняющимся бизнесом, часто Gartner предлагает вам использовать искусственный интеллект [искусственный интеллект]. интеллект], чтобы сделать это.
Таким образом, реализация идеи активных метаданных действительно важна. Я считаю, что сегодня мы на самом деле очень далеки от этого, но нам действительно нужно сосредоточиться на этом, потому что я думаю, что это действительно либо заставит всю эту систему работать, либо она развалится.
Итак, поговорим о реальном хранилище данных и о том, где оно построено. Очевидно, что сегодня все используют свои системы бизнес-аналитики в облаке. Какие соображения следует учитывать командам корпоративных данных при построении конвейера данных для этих платформ?
Да, я имею в виду, что все говорят об облаках. С точки зрения архитектуры, я считаю, что облако — это просто еще один пул хранения, хотя и огромный и сильно распределенный, и если ваши инструменты подготовки данных поддерживают облачные источники и цели, то все в порядке, не так ли? Ну я бы сказал не совсем.
В первую очередь вы должны всегда помнить о распределенной природе облака. Я всегда говорю, что управление данными было намного проще, когда все ваши данные находились в одном мейнфрейме. Но копии данных — это проклятие управления данными, и чем больше мест и чем дальше друг от друга находятся эти копии, тем сложнее становится задача. Таким образом, облако позволяет и — в некоторой степени — способствует дублированию данных, некоторые из которых в значительной степени невидимы.
Итак, мой первый совет в отношении облака — усилить ваши команды по управлению и управлению данными, потому что они действительно понадобятся. Второе соображение — это то, что называется гравитацией данных. Откуда берутся данные?
Если данные исходят из локальной среды, то их перенос в облако потребует затрат. [И] если информация поступает из облака, обычно более эффективно хранить ее там.
Конечно, сегодня большинство предприятий имеют данные из обоих источников, поэтому не существует единого правильного ответа на вопрос, где хранить и обрабатывать ваши данные. Но очевидно, что существует давление, чтобы перенести его в облако, часто по финансовым причинам. Но вот в чем загвоздка — главное здесь следить за относительными затратами на обработку хранилища и транспортировку данных, и я думаю, что именно последнее может вас подловить, особенно когда мы говорим о подготовке данных и конвейерах данных. .
Итак, переходим к последнему вопросу, и я думаю, что это тот, который мы обходили стороной и упоминали по-разному и в некоторых предыдущих ответах, но чтобы просто получить приблизительное представление, как, по вашему мнению, автоматизация вписывается во все это? Как это может сделать процесс создания и обслуживания конвейеров данных более эффективным?
Да, я думаю, ты прав. Сейчас все указывает на автоматизацию. Как я уже сказал, я имею в виду, что являюсь большим сторонником автоматизации подготовки данных и информации. Тем не менее, я очень настороженно отношусь к автоматизации в других областях, особенно там, где принимаются жизненно важные решения, и я думаю, что нам следует быть осторожными с автоматизацией там.
Но вернемся к подготовке данных: я думаю, что все, что снижает стоимость того, что по сути является просто сантехникой, приветствуется. А автоматизацию следует применять на каждом этапе процесса, где это возможно — от первоначальной спецификации и проектирования до ежедневных операций и вплоть до текущего обслуживания и управления изменениями.
Это очень широкий и очень широкий спектр того, что нам нужно будет делать и что нам нужно автоматизировать. Знаете, я просто не делаю ни одного предостережения, основываясь на своем многолетнем опыте: автоматизация имеет тенденцию подталкивать вас к предопределенным функциям преобразования, и они великолепны! Но возможность создавать собственные преобразования, уникальные для вашей среды, часто является ключом к успеху собственных инструментов подготовки данных.
Такие потребности могут составлять всего пять процентов или меньше от [предопределенных] преобразований, но их важность часто легко недооценить, поскольку зачастую они являются наиболее важными преобразованиями с точки зрения бизнеса.
На мой взгляд, инструменты автоматизации хранилищ данных должны позволять разрабатывать и внедрять эти очень специфические процедуры преобразования в рабочий процесс. Тем не менее, автоматизация дает возможность сократить или исключить повторяющиеся и общие части процесса подготовки данных. А инструменты автоматизации хранилищ данных также дополняют человеческий аспект процесса.
Здесь я думаю об определении требований, достижении консенсуса, управлении изменениями и так далее. В этом смысле DWA немного напоминает искусственный интеллект, поскольку он содержит аспекты как автоматизации, так и расширения. Итак, я думаю, что это особенно важный аспект того, о чем нам нужно подумать.
И наконец, я всегда считал, что автоматизация хранилищ данных, такая как ETL, была неудачным выбором названия для этого класса инструментов, потому что эти инструменты делают больше, чем просто автоматизация, как я только что сказал, и они могут и должны применяться в далеком будущем. более широкий спектр систем хранения и управления данными, чем просто хранилища данных.
Все части имени имеют свои слабые стороны. Итак, какое должно быть имя? Я действительно не знаю, если вы не хотите попробовать назвать это швейцарским армейским ножом управления данными, и я думаю, что это, вероятно, хорошее место, чтобы остановиться.
Astera DW Builder: автоматизируйте конвейеры данных
Astera DW Builder — это унифицированное решение для хранения данных, которое позволяет создавать архитектуру конвейера данных на основе метаданных. Комплексная платформа предлагает среду с нулевым кодом для разработки хранилища данных на логическом уровне и автоматизации процессов проектирования и проектирования, чтобы получить ценную информацию, отвечающую вашим требованиям бизнес-аналитики.
Гибкое автоматизированное решение включает лучшие в своем классе возможности ETL и ELT, включая встроенные компоненты оркестрации рабочих процессов и планирования заданий для создания саморегулируемых конвейеров данных. взять Astera DW Builder для тест-драйва чтобы узнать, как это может помочь доставить точные и надежные данные в вашу архитектуру бизнес-аналитики и отчетности.
