Build On Data & Analytics — Show notes

Добро пожаловать на наше первое мероприятие Build On Live Event, посвященное данным и аналитике. Эксперты AWS и друзья расскажут о самых разных темах, начиная от инженерии данных и обработки крупномасштабных данных и заканчивая аналитикой данных с открытым исходным кодом и машинным обучением для оптимизации понимания данных.

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

Это заметки с этого мероприятия, которое транслировалось в прямом эфире 7 июля 2022 года. Запись этого мероприятия доступна на нашем канале YouTube, но в этой статье я буду связывать каждый сегмент заметки с видео, так что не забудьте нажать кнопку подписки! 👏

---

Заметки по отдельным сессиям:

• Вступление и приветствие
• Что происходит в мире данных и аналитики?
• Базы данных NoSQL
• Загрузка данных Изменение захвата данных
• Качество данных, наблюдаемость данных, надежность данных
• Бессерверное будущее облачной аналитики данных
• Обработка крупномасштабных данных
• Не ETL вашего отца: ускорение модернизации и миграции ETL
• Потоковая обработка, анализ больших объемов данных
• Создание, обучение и развертывание моделей машинного обучения в Amazon Redshift Использование SQL в Amazon Redshift ML
• Использование Amazon Managed Workflows for Apache Airflow (MWAA) для планирования заданий Spark на Amazon EMR Serverless
• Объединить хранилища данных путем подключения и совместного использования различных источников данных: Пример использования в финансовой сфере
• Транзакционные озера данных с использованием Apache Hudi
• Устранение разрыва между несколькими облаками с помощью решений с открытым исходным кодом
• История и будущее аналитики данных в облаке
• Как работает команда прототипирования AWS!

Вступление и приветствие

Гость: Дэймон Кортези, представитель разработчиков в AWS

Ключевые моменты:

• Почему люди должны заботиться об аналитике данных? Ответ: Понимание.
• Все эти данные окружают нас — данные о продажах, маркетинговые данные, данные приложений и т.д. — но нам нужно найти в них смысл. Как мы можем лучше это сделать?
• Данные ценны. Нам нужно задавать вопросы о данных, чтобы принимать обоснованные решения.
• Поймите разницу между «ненужными данными» и «ценными данными».
• У нас есть проблема с данными, которые нужно регистрировать и собирать.
• Как люди должны знать, какие данные нужно собирать? Все сводится к пониманию того, какие вопросы нужно задавать на основе данных, и работе в обратном направлении.
• Самый большой сдвиг парадигмы за последние 5-10 лет заключается в том, что данные теперь хранятся в облаке, а не на компьютерах.
• Все перемещается вверх по стеку. Мы облегчаем людям работу, не требуя глубоких знаний. Теперь вы можете начать работу, просто используя SQL.
• Три ключевых шага в работе с данными: Собирать данные. Понимать данные. Храните данные в безопасности.

Перерыв на шутки: Знаете ли вы, что меньше половины всех шуток, посвященных науке о данных, ниже среднего уровня?

Что происходит в мире данных и аналитики?

Гости: Лена Холл, руководитель отдела по работе с разработчиками в Северной Америке, и Мэтт Вуд, вице-президент по бизнес-аналитике в AWS.

Ключевые моменты:

• Мэтт Вуд рассказывает о том, как он начал работать с AWS: Он работал над секвенированием генома человека в Кембридже. В прежние времена они использовали iPod для координации данных и физически доставляли их в разные места.
• В те времена отдельные геномы можно было сделать примерно за неделю. Промышленность работала с гигабайтами данных. Но с развитием событий им пришлось мыслить терабайтами — сотни терабайт в неделю.
• Они не могли получить достаточно экономически эффективную мощность в центре обработки данных, чтобы подключить дополнительные хранилища. Им пришлось задуматься о том, где хранить все эти данные. Они решили, что если у них возникла такая проблема в области генома, то, возможно, другие уже решили ее в других областях.
• Эта проблема с данными заинтересовала Мэтта в облачных вычислениях и привела его в AWS. И сегодня он здесь!
• Итак, что же такое аналитика данных? Начнем с того, что аналитика данных — это действительно беспорядочная работа. Из-за того, как собираются данные, некоторые из них организованы функционально, а иногда они хранятся логически.
• Что подразумевает управление данными? Вы хотите иметь контроль, но обычно вы можете контролировать только около 20% данных. Однако, как правило, 80% данных доступны. Таким образом, это дает творческую свободу строителям, которые могут брать эти данные и создавать на их основе приложения. Они становятся «отшлифованным драгоценным камнем», который имеет реальную ценность.
• Смена парадигмы на сетку данных: Это еще только начало, но он решает некоторые проблемы, обеспечивая командам гибкость и скорость. Идея заключается в том, что у вас есть ряд потребителей и производителей. Это дает вам много информации о данных, например, о том, кто ими владеет. Это позволяет вам брать данные и добавлять к ним ценность.
• Существуют новые передовые методы, которые дадут организациям огромный ускоряющий эффект — но не стоит бросаться на новую парадигму только потому, что так делают все остальные.
• Вопросы, которые следует задать вашей команде, когда вы думаете о данных: Каков наш уровень готовности к работе с данными? Где в нашей короне находится яркая, отполированная жемчужина, с которой мы можем что-то сделать? Где мы менее готовы? К каким данным мы хотели бы приступить раньше?
• Вы должны действительно понять, где находятся профессионалы бизнеса. Что является реальной движущей силой для организации?
• Откровенно оцените уровень знаний вашей команды, а затем со временем наращивайте его. Обучение — это стремление длиною в жизнь. Помните о том, что вам придется постоянно учиться, чтобы оставаться на уровне новейшей литературы.
• Короче говоря, хорошо оцените готовность данных, бизнес-профессионалов и то, куда вам нужно расширяться.

Базы данных NoSQL

Гость: Алекс ДеБри, AWS Data Hero

Ключевые моменты:

• Основные различия между SQL и NoSQL: Вопрос масштабирования. NoSQL обеспечивает горизонтальное масштабирование, размещая различные части данных на разных машинах. При увеличении масштаба вы просто получаете больше машин, а не большие машины.
• Сравнение различных баз данных: Dynamo vs Cassandra и Dynamo vs Mongo.
• Dynamo более авторитарна, Mongo более либертарна. Если вы не будете осторожны, вы можете потерять горизонтальное масштабирование. Хотите ли вы большей гибкости, но менее стабильной производительности, или наоборот? Продумайте модель запросов заранее, зная, что вы хотите использовать по мере развития базы данных.
• Есть два места, где Dynamo преуспевает: высокомасштабные приложения, такие как Amazon, и бессерверный мир.
• NoSQL: Вы реплицируете один и тот же фрагмент данных на нескольких машинах.
• Что такое «одна таблица»? В принципе, вы не можете объединять таблицы в базах данных NoSQL. Что вы можете сделать, так это предварительно соединить данные. В вашей единой таблице у вас нет «таблицы заказов» и «таблицы клиентов». У вас есть таблица приложений. В ней нет соединений, но она по-прежнему моделируется как реляционная база данных.
• Как влияет на производительность дизайн одной таблицы? Это помогает вам избежать множественных запросов в Dynamo.
• В главной таблице можно добиться сильной согласованности, если у вас есть условия.
• Список пожеланий Алекса к DynamoDB: Добавление более гибкой модели запросов в Dynamo. Индексирование некоторых данных, позволяющее выполнять более гибкие запросы. И, наконец, биллинг. В настоящее время существует модель предоставления и модель оплаты за запрос. Алекс хотел бы видеть их комбинацию, где вы можете установить емкость предоставления и получать счет за все, что сверх этого.

Ресурсы:

• Книга DynamoDB
• Руководство разработчика DynamoDB
• 7 общих шаблонов моделирования данных DynamoDB (FooBar Serverless YouTube)
• GraphQL, DynamoDB и однотабличный дизайн
• DynamoDB GitHub

Шуточный перерыв: Два DBA зашли в NoSQL-бар, но ушли, когда никто не позволил им объединить свои таблицы.

Data Ingestion Change Data Capture

Гости: Абхишек Гупта, главный защитник разработчиков & Штеффен Хаусманн, специалист по архитектуре решений в AWS

Ключевые моменты:

• Проблема с данными в реальном времени заключается в том, что традиционной пакетной обработки может быть недостаточно.
• Ценность информации может уменьшаться с течением времени. Чем быстрее вы сможете отреагировать, тем ценнее будет информация. Например: Как быстро магазин может реагировать на погодные условия, чтобы на складе было достаточно зонтов?
• Насколько сложнее и дороже становится работа в режиме реального времени? Ну, это может быть сложнее, чем системы, основанные на пакетной обработке данных. Все становится сложнее с точки зрения операционной деятельности. Поэтому не стоит переходить на систему реального времени только потому, что это «красиво и интересно». Вам нужна веская причина для инвестиций в поток данных в реальном времени.
• Сбор данных об изменениях: Почти во всех базах данных есть такое понятие, как журнал. Оно используется для фиксации изменений в данных и таблицах. Это полезный способ обнаружения изменений в базе данных.
• Посмотрите, как Абхишек Гупта демонстрирует захват данных об изменениях, фиксируя изменения в базе данных в режиме реального времени.
• Смотрите, как Штеффен Хаусманн демонстрирует Zeppelin, используя Change Data Capture для создания полезной аналитики в реальном времени на примере доходов.

Ресурсы:

• Семинар MSK: https://catalog.us-east-1.prod.workshops.aws/workshops/5e7795af-4545-4711-9c19-b85bfd6455a9/en-US
• Блоги: https://abhishek1987.medium.com/mysql-to-dynamodb-build-a-streaming-data-pipeline-on-aws-using-kafka-c2cf0b6e35b6
• Лучшие практики правильного определения размера кластеров Apache Kafka для оптимизации производительности и затрат: https://aws.amazon.com/blogs/big-data/best-practices-for-right-sizing-your-apache-kafka-clusters-to-optimize-performance-and-cost/.

Качество данных, наблюдаемость данных, надежность данных

Гости: Барр Мозес, генеральный директор, сооснователь Monte Carlo

Ключевые моменты:

• Данные огромны, и они ускоряются еще больше. Данные по-прежнему находятся в центре внимания. Они находятся на переднем крае стратегии.
• Компании используют данные для принятия действительно важных решений. Например: Финансовые займы и кредитование; финтех движим данными больше, чем когда-либо; такие компании, как Jet Blue, работают на данных. Они питают все продукты, и эти продукты полагаются на данные, чтобы быть точными.
• Все отрасли — от СМИ до электронной коммерции и FinTech — используют данные. Даже традиционно не ориентированные на данные компании используют их. Поэтому данные должны быть высокого качества. Они должны быть точными и заслуживающими доверия.
• Как измерить качество данных? Исторически сложилось так, что в центре внимания находились точные данные, которые очищались при получении. Но сегодня данные должны быть точными по всему стеку.
• Что такое наблюдаемость данных? Способность организации полностью понимать и доверять здоровью данных в своей системе и устранять простои данных (например, когда в 2016 году Netflix не работал в течение 45 минут из-за дублирования данных). Другими словами, неправильные данные могут стать причиной простоя приложения.
• В чем разница между Data Governance и Data Observability? Вместо этого важнее спросить: какую проблему вы пытаетесь решить?
• Наблюдаемость данных — это решение ситуаций, когда люди используют данные, но данные неверны. Например, когда цена товара на сайте неточна.
• Управление данными — это метод, с помощью которого компании пытаются лучше управлять своими данными.
• Как происходит поломка данных: Обычно это происходит из-за недопонимания между командами.
• Проблемы обнаружения данных: Команда по работе с данными должна первой узнавать о поломке данных, но зачастую она узнает об этом последней.
  • Решение: Сократите время, необходимое для решения проблемы, с недель и даже месяцев до нескольких часов.
  • Предотвращение: Можем ли мы поддерживать скорость создания, сохраняя при этом доверие к имеющимся у нас данным?
• Комплексный подход и ориентация на автоматизацию и машинное обучение помогают контролировать точность данных.

Ресурсы:

• Книга O’Reilly: https://www.montecarlodata.com/oreilly-data-quality-fundamentals-early-release
• Блог Data Downtime Blog: *www.montecarlodata.com/blog*.
• Контакт: barr@montecarlodata.com

Бессерверное будущее облачной аналитики данных

Гость: Войцех Гавронски, старший специалист по работе с разработчиками, AWS. Developer Advocate, AWS

Ключевые моменты:

• Бессерверная аналитика данных требует большого опыта и знаний.
• Почему мы вообще должны думать о бессерверной аналитике? Это не просто эффективность и скорость. Мы можем лучше использовать масштабируемость и решать операционные вопросы.
• Услуги бессерверной аналитики данных помогают облегчить кривую обучения.
• Используя предложения провайдера, вы можете сосредоточиться на разработке, а не панически наращивать опыт эксплуатации при увеличении масштаба в соответствии со спросом.
• Поскольку услуги основаны и полностью совместимы с открытым исходным кодом, вы можете спокойно выбирать между полностью управляемым сервисом и собственными операциями, что позволит вам легко менять направление.
• Согласно оценкам, к 2030 году мы будем иметь 572 ЗБ данных (1 зеттабайт — это триллион байт — да, это единица и 21 ноль). На протяжении многих лет мы постоянно генерируем огромные объемы данных, и возникает вопрос: Как в таких условиях подготовиться к решению проблем, связанных с постоянно растущим спросом на инфраструктуру, не увеличивая при этом расходы на ее содержание? Бессерверная аналитика данных ответит на эти вопросы.
• Легче начать работу, масштабировать и управлять, когда вы переходите на бессерверную аналитику — особенно если у вас нет опыта работы.
• Посмотрите, как Войтек демонстрирует трехэтапную демонстрацию: Получение данных, преобразование данных для загрузки в хранилище данных с целью получения информации и использование бессерверного подхода.
• Узнайте больше о бессерверном подходе Redshift с помощью демонстрации от Войтека.

Шуточный перерыв: Как вы называете группу инженеров по обработке данных? Кластер.

Ресурсы:

• GitHub: https://github.com/afronski/serverless-data-analytics-on-aws
• Проверьте следующие сервисы:
  • https://aws.amazon.com/msk/features/msk-serverless
  • https://aws.amazon.com/emr/serverless
  • https://aws.amazon.com/redshift/redshift-serverless
  • https://aws.amazon.com/managed-workflows-for-apache-airflow

Крупномасштабная обработка данных

Гости: Гвен Шапира, директор по продуктам, Stealth Startup

Ключевые моменты:

• «Продукт данных» — это один из тех терминов, которыми все разбрасываются. Впервые он появился в 2012 году.
• У нас есть все эти данные — как мы можем использовать их для создания хорошего пользовательского опыта?
• Плоскость управления как услуга: Сначала спросите, нужна ли вам такая архитектура. Многие люди задумываются об адаптации этой архитектурной концепции на ранних этапах, что является большим сдвигом по сравнению с тем, что было несколько лет назад.
• Control Plane as a Service дает вам возможность использовать определенные сервисы и базы данных (например, плоскости данных). Например, с DynamoDB вы можете делать практически все. Однако если вы хотите использовать ее для конкретного случая использования, необходимо приложить много усилий, чтобы перенести ту или иную проблему в DynamoDB.
• Пользовательский опыт — самое важное в аналитике сегодня. Это сдвиг по сравнению с тем, что было раньше, когда соображения конечного пользователя стояли на последнем месте.
• Рекомендации Гвен для начинающих разработчиков данных: Начните с вопроса о том, кто будет использовать продукт, и отталкивайтесь от этого. Хороший пользовательский опыт является ключевым фактором, и вы хотите, чтобы ваша инфраструктура поддерживала его.
• Сделайте свой продукт как можно более гладким и беспроблемным. Начните с клиента и всегда работайте в обратном направлении.

Ресурсы:

• Проектирование продуктов данных: 15 лиц продуктов данных немного отличаются друг от друга
• Слайды презентации
• Инфраструктура SaaS — архитектура, основанная на плоскости управления

Не ETL вашего отца: ускорение модернизации и миграции ETL

Гость: Навнит Шукла, старший архитектор решений, AWS

Ключевые моменты:

• Навнит помогает клиентам извлекать ценность из своих данных в AWS.
• ETL, что означает «извлечение, преобразование и загрузка», — это процесс интеграции данных, который объединяет данные из нескольких источников данных в единое, согласованное хранилище данных, загружаемое в хранилище данных или другую целевую систему.
• ETL является одной из самых важных частей работы с данными. Одна из самых больших проблем традиционного ETL — это получение большого количества данных из разных источников. Традиционные инструменты ETL не были созданы для масштабирования или для работы с различными данными.
• Посмотрите, как Навнит рассказывает об AWS Glue, мощном инструменте ETL. Он выполняет пакетную обработку, масштабирование и защиту за вас — все важные инструменты, которые вам нужны. Это все равно что поручить кому-то другому стирать за вас!
• Совет Навнита для начинающих специалистов по анализу данных и инженеров: Перестаньте ходить в ETL. Просто перейдите на ELT: извлечение, загрузка и преобразование. Вместо этого постройте процесс ELT. Принесите все данные как они есть, а затем сделайте преобразование поверх них.

Ресурсы:

• Веб-страница Glue (https://aws.amazon.com/glue/)
• Саммиты AWS https://aws.amazon.com/events/summits/
• AWS Big Data Blog: Проверка, развитие и контроль схем в потоках данных Amazon MSK и Amazon Kinesis с помощью AWS Glue Schema Registry
• AWS Glue: Добавление классификаторов в краулер
• Вебинар по бессерверной интеграции данных

Потоковая обработка, аналитика крупномасштабных данных

Гость: Тим Берглунд, вице-президент по работе с разработчиками, StarTree

Ключевые моменты:

• У нас происходит смена архитектурной парадигмы. Последняя крупная парадигма архитектуры программного обеспечения была в конце 80-х годов: Она называлась «клиент-сервер». Затем появился веб, но он не отошел от клиент-сервера в значительной степени.
• Сегодня архитектура, управляемая событиями, является обычным явлением. Это требует нового способа построения систем. Весь стек теперь другой.
• Kafka — это место, где живут системы, основанные на событиях.
• Данные о событиях сейчас очень ценны. Ценность этого события быстро снижается. Вы хотите реагировать сразу же. С другой стороны, накапливая контекст, вы получаете все больше и больше ценности с течением времени.
• Существует страх перед старыми инструментами, которые больше не работают, в то время как ясности в том, что такое новые инструменты, пока нет.
• Люди строят вещи дальше по стеку, потому что стек еще не поднялся им навстречу.
• Базы данных OLTP записывают транзакции в системе на постоянной основе. В базах данных OLAP вы сбрасываете большое количество данных, а затем задаете вопросы о них.
• Данные теряют свою ценность с течением времени. Например, вы можете спросить, сколько времени требуется, чтобы доставить местный Smashburger? С каждой секундой данные становятся все менее актуальными.
• Совет Тима для пользователей Cassandra или GitHub: Все меняется быстрее, чем вы думаете. Увидеть предстоящие волны можно быстрее, чем раньше.

Ресурсы:

• Perishable Insights, Forrester: https://www.forrester.com/report/Perishable-Insights-Stop-Wasting-Money-On-Unactionable-Analytics/RES135301.

Создание, обучение и развертывание моделей машинного обучения в Amazon Redshift с помощью SQL в Amazon Redshift ML

Гость: Рохит Бансал, специалист по аналитике, архитектор решений, AWS.

Ключевые моменты:

• Рохит имеет более чем двадцатилетний опыт работы в области аналитики данных.
• Что такое Redshift? Amazon Redshift — это полностью управляемая служба хранения данных петабайтного масштаба в облаке. Он предоставляет аналитикам данных возможности машинного обучения.
• Любой, кто знает SQL, может использовать Amazon Redshift для создания, обучения и развертывания ML-моделей с помощью Redshift ML на SQL.
• Зачем нам нужен Redshift ML?
  • Аналитики данных/пользователи SQL хотят использовать ML с помощью простых команд SQL без изучения внешних инструментов.
  • Специалисты по анализу данных / ML хотят упростить свой конвейер и избавиться от необходимости экспортировать данные из Amazon Redshift.
  • Специалисты BI хотят использовать возможности ML из своих SQL-запросов, используемых в приборной панели.
• Когда вы выполняете команду SQL для создания модели, Amazon Redshift ML безопасно экспортирует указанные данные из Amazon Redshift в Amazon S3 и вызывает SageMaker Autopilot для автоматической подготовки данных, выбора соответствующего предварительно созданного алгоритма и применения алгоритма для обучения модели. Amazon Redshift ML обрабатывает все взаимодействия между Amazon Redshift, Amazon S3 и SageMaker, абстрагируя шаги, связанные с обучением и компиляцией. После обучения модели Amazon Redshift ML делает ее доступной в виде SQL-функции в хранилище данных Amazon Redshift.
• Типы алгоритмов, поддерживаемых Redshift ML:
  • Модели с наблюдением типа XGBoost, Linear Learner, Multi-Layer-Percetron (MLP).
  • Тип задачи: Бинарная классификация, Многоклассовая классификация и т.д.
  • Неконтролируемая (кластеризация).
• Redshift помогает операционализировать понимание. Это решение для:
  • Аналитики данных/пользователи SQL хотят использовать ML с помощью простых команд SQL без изучения внешних инструментов.
  • Специалисты в области Data Scientists/ML хотят упростить свой конвейер и избавиться от необходимости экспортировать данные из Amazon Redshift.
  • BI-специалисты хотят использовать ML из своих SQL-запросов, используемых в Dashboard.
• Сколько стоит Redshift? Amazon Redshift ML использует существующие ресурсы кластера для прогнозирования, поэтому вы можете избежать дополнительных расходов на Amazon Redshift.
• Изменения в Redshift, которые Рохит хотел бы увидеть: В будущем планируется включить дрейф данных.
• Посмотрите, как Рохит проведет обзор Redshift. Он продемонстрирует, как легко создавать модели ML в Redshift, используя данные Redshift ML Sales.

Ресурсы:

• Amazon Redshift ML: начало работы
• Создание и обучение ML-моделей с легкостью с помощью Amazon Redshift ML

Использование Amazon Managed Workflows for Apache Airflow (MWAA) для планирования заданий Spark на Amazon EMR Serverless

Гость: Дэймон Кортези, главный специалист по работе с разработчиками, AWS

Ключевые моменты:

• Современные тенденции в области данных и аналитики: «Управляемые» озера данных с современными уровнями хранения, такими как Hudi, Iceberg и Delta. Шквал активности в середине стека (каталоги данных, потоковые сервисы) и желание двигаться вверх по стеку и абстрагироваться от сложных вещей.
• Apache Airflow облегчает вашу работу.
• Почему MWAA лучше? Почему разработчики и строители должны использовать его? Airflow может быть сложным для настройки и запуска. Но чтобы запустить производственную среду, вам нужны различные компоненты (планировщик, веб-сервер, запуск задач). Вы можете запустить его самостоятельно, но если вы хотите, чтобы среда работала за вас, то MWAA сделает это. Вы можете беспокоиться о более важных вещах.
• Существует ли стоимость MWAA? Да. Это минимум ~$70 в месяц.
• Если у вас есть небольшая среда Airflow, возможно, стоит запустить ее самостоятельно.
• EMR Serverless: Легко и быстро выполнять задания Spark и Hive на AWS.
• Чем EMR Serverless отличается от других предложений EMR (таких как EC2 / EKS)? Можно представить это как широкий спектр.
• EMR на EC2 дает вам наибольшую гибкость и контроль над конфигурацией и базовыми экземплярами. Если ваша работа имеет очень специфические характеристики и вам нужно оптимизировать базовые экземпляры (например, CPU vs Memory vs GPU) или вам нужен определенный набор ресурсов, EMR на EC2 — хороший вариант.
• EMR на EC2 также имеет самый широкий набор поддерживаемых фреймворков. Сегодня EMR на EKS поддерживает Spark, а EMR Serverless поддерживает Spark и Hive.
• Посмотрите, как Дэймон подробно описывает выполнение заданий EMR Serverless Spark с помощью Amazon Managed Workflows для Apache Airflow.
• Команда рассказывает о различиях между использованием EMR, Glue, Athena и т.д. для сбора и управления данными.

Ресурсы:

• Вы можете взглянуть на режим использования мощностей по требованию, который позволяет автоматически увеличивать лимиты в зависимости от рабочей нагрузки. Более подробная информация здесь: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html
• Обработка ошибок в DynamoDB
• https://github.com/aws-samples/emr-serverless-samples
• AWS Analytics на YouTube
• GitHub Дэймона
• Контейнеры данных на GitHub

Унифицируйте хранилища данных путем подключения и совместного использования различных источников данных: Пример использования в финансовой сфере

Гости: Джессика Хо, старший партнерский архитектор решений, и Саман Ирфан, специалист. Архитектор партнерских решений и Саман Ирфан, специалист SA в AWS

Ключевые моменты:

• Давайте поговорим об обмене данными. О каком именно обмене данными идет речь? И зачем мы это делаем?
• Один из лучших способов использования обмена данными в нашей повседневной жизни — это принятие обоснованных решений. Например, при совершении покупок: Мы можем посмотреть отзывы, то есть, по сути, другие люди делятся данными. Затем мы анализируем их. На основании этого мы решаем, стоит ли нам покупать этот товар или нет.
• Если говорить об организациях, то они могут принимать обоснованные бизнес-решения благодаря обмену данными между различными подразделениями.
• Возникает непреодолимое желание извлечь пользу из огромных данных, которыми мы располагаем. Но как мы можем получить доступ к ним безопасным и эффективным образом? Нам необходимо собрать все данные в единый источник, а затем предоставить их различным бизнес-подразделениям в соответствии с их потребностями — и все это без нарушения целостности данных.
• Например, компания Stripe производит программное обеспечение и API, которые позволяют предприятиям обрабатывать платежи, вести электронную коммерцию и т. д. Для их клиентов важно иметь доступ к этим данным, чтобы они могли понять, как работает их бизнес.
• Какие проблемы Stripe решила с помощью обмена данными? Они запустили продукт под названием Data Pipeline, и он построен на основе возможности обмена данными Redshift. Их клиенты могут получать конкретные данные, уникальные для данного клиента. Stripe постоянно ищет способы извлечения клиентами нужных им данных.
• Как мы делимся данными через Redshift? Хранилище данных используется совместно с различными вычислительными кластерами.
• Посмотрите, как Саман демонстрирует обмен данными в реальном времени на Amazon Redshift. Это очень просто и безопасно с Redshift.
• Узнайте также больше о Amazon Redshift Spectrum.
• Какую функцию Сэмэн убрал бы из системы совместного использования данных Redshift? В настоящее время данные принадлежат кластеру-производителю. Вместо этого было бы хорошо не иметь владельцев данных. Также было бы здорово сделать безболезненную миграцию в один клик.

Ресурсы:

• Бесшовный совместный доступ к данным с помощью Amazon Redshift
• AWS Big Data Blog: Быстрый и надежный ввод данных Stripe с помощью Stripe Data Pipeline для Amazon Redshift
• AWS Big Data Blog: Безопасный обмен данными Amazon Redshift между кластерами Amazon Redshift для изоляции рабочих нагрузок
• AWS Big Data Blog: Безопасный обмен данными между регионами с помощью совместного использования данных Amazon Redshift
• Целевая страница решения Stripe Data Pipeline: https://stripe.com/data-pipeline

Транзакционные озера данных с использованием Apache Hudi

Гость: Шана Шиперс, специалист SA, Analytics, AWS

Ключевые моменты:

• Шана специализируется на работе с Большими Данными в AWS.
• Определение Apache Hudi: Один термин не может охватить все. Это больше, чем формат таблиц — это транзакционная структура озера данных. Однако он добавляет функции поверх вашего озера данных, такие как индекс, транзакции, обновления на уровне записей, контроль валюты и т.д.
• Почему это важно? Мы используем озера данных все чаще и чаще, и собираем больше данных, чем когда-либо прежде. Хранилища данных становятся дорогими в масштабировании и ограничивают объем данных.
• Если мы хотим запускать машинное обучение и агрегировать данные, нам необходимо перейти к озеру данных.
• При масштабировании компании хотят знать, что их данные хороши. Мы должны обеспечить согласованность данных. Именно здесь на помощь приходит Hudi.
• Если вы сбрасываете данные в озеро данных, вы также хотите иметь возможность их удалять. Чтобы сделать это возможным, нужны такие вещи, как Hudi. Как правило, объекты в озерах данных неизменяемы. Это может отнимать много времени. Hudi управляет этим за вас.
• Hudi также управляет размером файлов.
• Apache Hudi — это инструмент с открытым исходным кодом, который позволяет использовать транзакционные элементы поверх озера данных.
• В Hudi есть два типа таблиц. Один из них отлично подходит для ввода потоковых данных. Существует множество вариантов для потокового ввода данных, включая Glue, EMR, Athena, Presto, Treno, Spark и т.д.
• Посмотрите, как Шана провела обширную демонстрацию Apache Hudi. Это трудно объяснить, но легко изучить!
• Какую функцию Шана хотела бы изменить в Apache Hudi? Чтобы можно было заносить данные в несколько таблиц с помощью Spark streahttps://hudi.apache.org/ming, и чтобы EMR автоматически конфигурировал все размеры и память для Spark, если вы используете Hudi.

Ресурсы:

• Apache Hudi
• Amazon EMR — Hudi
• Транзакционные и изменяемые озера данных на AWS — День погружения
• Apache Hudi Connector для AWS Glue

Устранение разрыва между несколькими облаками с помощью решений с открытым исходным кодом

Гости: Лотфи Мухиб, старший территориальный архитектор решений и Алекс Тарасов, старший архитектор решений в AWS

Ключевые моменты:

• Лотфи и Алекс рассказывают об Apache Nifi и Apache Hop.
• Существует множество различных типов заказчиков, некоторые из которых больше других увлечены данными. Управление или создание фреймворка самостоятельно может быть очень сложной задачей. Инструменты с открытым исходным кодом могут помочь ускорить процесс разработки и сделать его более удобным.
• Apache NiFi позволяет перемещать данные из источника A в источник B, не прибегая к обширной трансформации данных. Вы можете развернуть систему без сложного кодирования за кулисами.
• Apache Hop позволяет небольшим битам данных перемещаться между различными частями конвейера.
• И NiFi, и Hop похожи тем, что данные перемещаются из одного места в другое. Это поток данных. Они могут ускорить проекты миграции, так как нужно писать меньше кода! Они также помогают закрыть пробел, когда в управляемых услугах нет необходимых коннекторов.
• И Hop, и NiFi позволяют расширить функциональность путем добавления существующих java-библиотек и использования их в вашем конвейере данных.
• Сообщество Apache Hop проделало огромную работу по отделению собственно конвейера данных от механизма исполнения, так что он может работать на разных механизмах. Это дает гибкость в использовании управляемых сервисов, таких как EMR, для запуска конвейеров с меньшими накладными расходами на управление.
• Apache NiFi — это инструмент перемещения данных, а не мощный механизм обработки. Он помогает вам перемещать данные из одного источника в другой, применяя при этом легкие преобразования.
• Почему стоит использовать Apache NiFi, а не другие инструменты? Apache NiFi существует на рынке уже более 15 лет, достигла зрелости и имеет сильное сообщество поддержки.
• Apache NiFi также фокусируется исключительно на перемещении данных и позволяет применять механизм преобразования по вашему выбору (например, Apache Spark или любой другой механизм ETL).
• Apache NiFi позволяет следовать лучшим практикам IAM.
• Основная ценность Apache NiFi заключается в перемещении данных, поэтому он не подходит для сложных объединений, как реляционная база данных, или сложной обработки событий для потоков, как Apache Flink.
• Посмотрите, как Алекс демонстрирует Apache Hop.
• Посмотрите, как Лотфи демонстрирует Apache NiFi.

Ресурсы:

• Apache NiFi
• Apache Hop
• AWS Identity and Access Management представляет IAM Roles Anywhere для рабочих нагрузок за пределами AWS

История и будущее аналитики данных в облаке

Гости: Имтиаз Сайед, технический руководитель направления аналитики, и Ти Джей Грин, главный инженер AWS.

Ключевые моменты:

• Как развивается аналитика данных? Каким видится будущее аналитики? Пока рано говорить о ее истории, поскольку на самом деле ей не так много лет. Но эволюция была захватывающей.
• Самые большие изменения произошли за последние 25 лет. Скорость эволюции огромна.
• Все, что мы делаем сегодня, оставляет цифровой след. Возникает необходимость в обработке этих данных и получении информации для улучшения работы.
• Мы эволюционировали от домов данных к озерам данных и сеткам данных. А ведь раньше данные хранились на чем-то простом, как кассета!
• Многое изменилось: раньше Kafka был шиной сообщений, но теперь эти системы используются по-другому. Теперь Kafka используется как буфер. Связи данных должны были быть мутабельными, но теперь данные можно изменять, удалять и вставлять. У нас есть Redshift и Aurora, выполняющие функции независимого хранения памяти и масштабирования. Redshift теперь выполняет машинное обучение и потоковую передачу данных в реальном времени.
• Большим изменением, произошедшим 10 лет назад, стало начало перехода на облачные технологии. До этого мы жили в мире локальных хранилищ данных. Это было очень дорого, большие инвестиции, с которыми приходилось сталкиваться компаниям.
• Redshift был одним из пионеров использования облака в 2013 году. Вы могли просто зарегистрироваться и не покупать и не администрировать ничего самостоятельно. Цена также была очень привлекательной.
• С тех пор в этом пространстве всегда была жесткая конкуренция, что способствовало продвижению инноваций. Облако также позволяет нам масштабироваться и быть более гибкими.
• Сегодня аналитика данных используется во всех отраслях, таких как розничная торговля, здравоохранение, нефтегазовая промышленность. Она позволяет использовать ее как крупным предприятиям, так и стартапам.
• Что сегодня привлекает клиентов? Цена, производительность и простота использования. Многие из этих факторов встроены в продукты AWS.
• Например: Glue имеет функции, которые обеспечивают простоту UI/UX для работы с данными. Вам не нужно вникать в тонкости ETL.
• Большинство клиентов не хотят видеть, как делается колбаса! Они хотят, чтобы продукт работал хорошо и стоил недорого, но не хотят, чтобы им пришлось крутить кучу ручек, чтобы добиться этого. Мы берем на себя боль, чтобы облегчить жизнь клиента».
• Болевые точки перехода в облако: Это довольно сложно. Одной из основных проблем является работа с объединением всех этих данных.
• Определение ячеек данных: Возможность безопасно обмениваться данными с несколькими производителями, которые могут безопасно обмениваться данными с несколькими потребителями. Сетку данных нелегко реализовать, и она не для всех! В конечном итоге, вы захотите начать с малого и быстро масштабировать.

Перерыв на шутки: В чем разница между Богом и DBA?
Бог не считает себя DBA.

Шуточная пауза: Два менеджера разговаривают друг с другом.
Один спрашивает: «Сколько инженеров по обработке данных работает в твоей команде?».
Другой отвечает: «Половина из них».

Ресурсы:

• Amazon Redshift Re-Invented Paper

Как строит команда AWS Prototyping!

Гости: Себастьен Стормак (Sebastien Stormacq), главный специалист по работе с разработчиками, Ахмад Юссеф (Ahmmad Youssef), руководитель группы прототипирования больших данных в AWS.

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

Ахмад покажет нам, как перенести данные из Microsoft SQL Server, работающего на экземпляре EC2, в ведро Amazon S3! И все это с помощью Amazon Data Migration Service (DMS)! Волшебство 🪄

---

Спасибо всем за участие в этом замечательном мероприятии. Пожалуйста, следите за новыми подобными мероприятиями. А если вам нужна еженедельная порция Build On, присоединяйтесь к нам каждый четверг в 9 утра по тихоокеанскому времени в прямом эфире на Twitch. 😎

📅 Следите за нашей новостью, заполнив простую форму здесь!