Инсайдерская информация о разработке современных хранилищ данных с Джеймсом Серрой

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

Для нашего третьего интервью в этой серии мы решили поговорить с человеком, который построил свою карьеру на способности выявлять, предвидеть и успешно решать эти проблемы, одновременно возглавляя проекты по хранению данных для Microsoft, а в настоящее время — для Ernst & Young. Джеймс Серра, один из ведущих мыслителей в этой области, затронул целый ряд тем: от бизнес-аналитики и архитектуры данных до больших данных и аналитики в своей популярной книге. Блог и на лекциях по всему миру.

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

 

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

Я начал много-много лет назад с базами данных, еще в 80-х. Первоначальное внимание было сосредоточено на Microsoft SQL Server, сначала SQL Server 1.0, а затем OS 2.0, в 1989 году, я думаю, это было так. Итак, это были скорее транзакционные базы данных с большим количеством обновлений, вставок и удалений.

Возможно, лет 20 назад я впервые занялся хранением данных. Я работал администратором базы данных в компании, и им было поручено построить хранилище данных. В то время я очень мало знал об этой технологии, но хранилище данных было построено на SQL Server, поэтому я принял участие в процессе. Это был один из моих первых опытов создания настоящего хранилища данных, то есть получения данных из всех этих различных источников и создания на их основе отчетов BI.

С тех пор у меня было много разных работ: я был консультантом, работая над множеством различных типов баз данных, всегда в сфере Microsoft, начиная с SQL Server, затем появился Azure, затем были база данных SQL, хранилище данных SQL, а теперь Synapse, которым я почти исключительно пользуюсь последние несколько лет.

 

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

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

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

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

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

 

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

Итак, прежде всего, я бы определил большие данные не только как размер данных, но и как тип и скорость данных. Очень многие клиенты, с которыми я работал, обрабатывают терабайты данных, которые они пытаются использовать. Но им также приходится иметь дело с данными во всех форматах, включая Parquet, CSV, JSON, а также с данными, которые они могут захотеть получать в режиме реального времени из каналов социальных сетей, таких как Twitter. Они также могут захотеть получить некоторые данные IoT. там.

Итак, теперь вам предстоит столкнуться со всеми трехскоростными типами и размерами данных. Несмотря на то, что за последние полдюжины лет или около того появились системы, способные обрабатывать большие данные, такие как, например, Azure Synapse на платформе Microsoft, все еще существует ряд других инструментов, необходимых для создания современного хранилища данных. Эти инструменты обрабатывают разнообразие, объем и размер данных. Сегодня они могут обрабатывать любую комбинацию данных, извлекать их, корректировать, очищать и обрабатывать перед созданием отчетов.

 

Что вы думаете об озере данных? Есть ли ему место в современной BI-системе? Дополняет ли оно хранилище данных или является жизнеспособной альтернативой?

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

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

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

Мы можем рассматривать озеро данных как способное обрабатывать данные независимо от размера и типа, но оно имеет некоторые ограничения. Озеро данных не подходит для чрезвычайно быстрых запросов, оно не подходит для тех типов безопасности, которые вам могут понадобиться в вашей архитектуре данных — например, низкоуровневая безопасность или безопасность на уровне столбцов, оно также может быть сложнее для вашего среднего конечного пользователя. пользователь может запрашивать данные, находящиеся в озере данных, потому что это схема при чтении, то есть это просто прославленная папка с файлами, вы можете поместить туда любые данные, и это может затруднить попытку извлечь их, если вы этого не сделаете. Иметь необходимые технические навыки. Именно здесь в игру вступает реляционная база данных, поскольку кто-то из ИТ-специалистов будет выполнять работу по объединению данных вместе с метаданными, поэтому конечному пользователю становится намного проще запрашивать их. Итак, если вы перейдете из озера данных в реляционную базу данных и из 3NF в звездообразную схему, конечные пользователи теперь смогут легко выполнять BI-аналитику с самообслуживанием, поскольку они могут просто перетаскивать поля из базы данных и создавать на их основе отчеты или запросы.

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

 

Какой аспект разработки хранилища данных вы считаете наиболее важным? Моделирование данных? Загружаете данные в хранилище данных? Обеспечиваете ли хранилище данных доступностью для ваших платформ BI?

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

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

В последние годы наблюдается большой толчок к перемещению хранилищ данных в облако на таких платформах, как Azure Synapse, Google BigQuery или Amazon Redshift. Что вы думаете о преимуществах развертывания в облаке? Рекомендуете ли вы в некоторых случаях придерживаться локальных баз данных?

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

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

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

 

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

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

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

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

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

 

Если бы вы рассматривали решение для хранения данных для клиента, какие ключевые функции вы бы хотели от него иметь?

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

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

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

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

 

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

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

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

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

Наконец, каким вы видите будущее хранилища данных? Какие крупные достижения (если таковые имеются) вы предвидите в этой области?

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

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

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

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

Комплексное решение для разработки современных хранилищ данных

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

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