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

Мы запустили нашу платформу автоматизации хранилищ данных нового поколения (DWA), Astera Построитель хранилища данных это ускоряет и упрощает разработку хранилищ данных. Это унифицированное решение на основе метаданных, которое позволяет организациям проектировать, разрабатывать и развертывать хранилища данных корпоративного уровня за считанные дни.

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

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

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

Я думаю, что большинство клиентов отошли от каскадного подхода, при котором они тратят много времени на сбор требований. Они перешли на гибкий водопадный тип разработки, и во многом это связано с инструментами, появившимися в последнее время. Если вы посмотрите на что-то вроде инструментов бизнес-аналитики, я обнаружил, что клиенты теперь используют этот инструмент для определения бизнес-требований, а не кто-то из ИТ-специалистов идет к клиенту и говорит: «Хорошо, каковы ваши требования? Давайте снесем это, давайте что-нибудь построим», вернитесь и узнайте, что это неправильно, и пусть этот цикл продолжится. Теперь они говорят: «Эй, используйте прототип, а мы будем использовать его в качестве бизнес-требований».

Современные инструменты отчетности ETL позволяют легко создавать прототипы и создавать эти требования. А если нет, то обычно это: «Эй, нам нужна быстрая победа. Давайте начнем что-то создавать и покажем ценность того, что мы создали, и заинтересуем людей и конечных пользователей». В большинстве случаев это [помогает] разблокировать бюджеты, а затем вы также на раннем этапе привлекаете этих конечных пользователей, так что вы чувствуете, что они являются частью того, что вы там строите, и тогда они могут что-то получить. ценности, поэтому вы выбираете что-то, что вы можете сделать в краткосрочной перспективе и имеет большую ценность, и затем вы получаете это.

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

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

Что вы думаете о хранилищах данных? Считаете ли вы, что это скоро вытеснит объемное моделирование как предпочтительный метод, или все имеет свое место? 

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

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

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

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

Говоря немного о перспективе многомерного моделирования данных, как вы думаете, какую роль должны играть метаданные? Считаете ли вы, что платформа, основанная на метаданных, может принести пользу при проектировании хранилища данных? И если да, то как?   

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

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

Итак, давайте создадим каталог метаданных и создадим инструмент обнаружения данных на рынке, где любой конечный пользователь сможет сказать: «Эй, мне нужно создать что-то, используя этот конкретный тип данных. Интересно, есть ли оно у нас? Давайте зайдем в каталог и посмотрим, есть ли он там». Мы [теперь] можем мгновенно получить доступ к этим данным и избежать дублирования.

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

Итак, это еще одна вещь, которую, я думаю, вы начнете замечать благодаря наплыву людей, которые каталогизируют не только данные, но и наборы данных. Я думаю, вы увидите, что интеграция с каталогами данных означает: «Эй, просто [это] может быть достаточно круто, что я вижу, что у нас есть данные о клиентах и ​​​​данные о продуктах, но, возможно, кто-то уже создал этот набор данных. Возможно, кто-то уже создал на основе этого отчет и информационную панель, и я могу быстро использовать это вместо того, чтобы изобретать велосипед».

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

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

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

[Предположим] данные попадают в модель. Как я могу убедиться, что он очищен и я правильно соединяю данные? Самая главная причина неудач проектов хранилищ больших данных, которую я вижу, — это недостаток времени на управление данными.

Они предоставляют набор данных, и вы просто говорите: «Отлично, я собираюсь использовать этот набор данных», а затем говорите: «Подождите минутку! Эти данные неверны». Если это ваше первое впечатление, вы сразу же потеряли уверенность. Они не будут доверять ничему, что вы получите, поэтому вам придется потратить много времени, прежде чем проверять эти данные, чтобы убедиться, что набор данных верен.

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

Что вы думаете по поводу утверждения о том, что надежная проверенная модель схемы хранилища данных соответствует общей высококачественной архитектуре хранилища данных?

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

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

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

Учитывая технологию MPP и столбчатое хранилище, видите ли вы тенденцию использования модели OBT с одной большой таблицей для отчетности и аналитики поверх многомерной модели?

Ну, MPP, для тех, кто не знает, это множественная параллельная обработка. Итак, идея в том, что я могу создавать запросы, выполнение которых может занять часы в качестве SMP [симметричной многопроцессорной обработки] или типичного решения, и разместить их в системе MPP, и они будут выполняться где-то от 20 до 100 раз быстрее. там. Это можно сделать с помощью таблиц третьей нормальной формы. Еще лучше это можно сделать со звездообразной схемой, но я видел потрясающие результаты для большого количества данных, даже со многими различными соединениями.

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

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

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

Я за ярлыки. Итак, когда я разговаривал с клиентами, это было: «Ну, погодите! То, о чем вы говорите… Я думаю, вы могли бы использовать здесь некоторые инструменты автоматизации и сторонние продукты. Да, это дополнительные расходы, но экономия времени и точность, которую вы можете получить от этого, могут того стоить, так что да, я полностью за эти сторонние инструменты.

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

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

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

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

Есть ли какие-нибудь напутственные слова, которые вы хотите оставить нам?

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

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

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

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

Создание этих проектов требует много времени, и вы не хотите, чтобы это произошло через несколько месяцев, а другие компании говорят: «У нас есть этот новый продукт и новая функция», а вы говорите: «О, стоит ли это делать?» мы знаем об этом?» и я говорю это потому, что большая часть моей работы заключалась в том, чтобы люди были осведомлены о том, что будет дальше.

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

Автоматизация проектирования хранилищ данных с помощью Astera Построитель хранилища данных

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

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