Небольшой ролик про девайсы AWS и автомобиль для транспортировки данных в облака. А вы как думали, можно загрузить несколько петабайтов в облако?

Всем знают, что обычно при создании хранилищ данных, нужно подумать о модели данных. Есть много вариантов - Dimensional Modelling  via Kimball, 3rd Normal Form via Inmon, Data Vault and so on. На собеседованиях часто спрашивают в чем разница и какие техники существуют. Вот одна из статей на эту тему.

С другой стороны, бизнесу нужен результат здесь и сейчас, у них нет времени ждать пока вы создадите нужную модель данных. И часто, все модели вообще игнорируются, и это не смертельно. Если вы смоглы помочь бизнесу быстро получить результат, это намного лучше, чем согласовывать модель данных несколько месяцев. Опасность в том, что нет модели = нет порядка, вы создаете хаус внутри хранилища, и только вы знаете, где что находится. Так что это такая грань, и вам решать как быть.  Я в этой ситуации использую ELT tool Matillion, который помогает мне разрабатывать быстро и включать в работу бизнес пользователей.

Например в Алексе, где я сейчас, именно такая ситуация, за последние несколько лет мой департамент Applied Modelling and Data Science нагородил много кастомных решений, и теперь все хором говорят, что им нужна правильная модель данных, а что в ней должно быть и почему, никто не знает.  Ну я могу им рассказывать, как модель данных важна, и мы понимаем друг друга с полу слова😆 Так же у другой команды есть Redshift кластер, в котором 128 нод, это максимально возможный кластер и он не справляется с объемом и кол-вом запросов. И в этой ситуации решение - это микс хранилища данных и озера данных, то есть уйти от реляционной модели данных, где есть в этом необходимость. Что в принципе и сделал Amazon.com в течение последних трех лет под названием проекта Rolling Stone. Все реляционные базы данных Оракл были заменены на AWS DynamoDB (NoSQL).  

И последнее, про модели данных. Как правило, когда мы говорим о модели данных, мы подразумиваем релационную модель данных (Schema on Write), то есть у нас есть система источник, база данных с таблицами, и таргет, хранилище данных с таблицами, с помощью ETL/ELT мы загружаем данные ИЗ сорса В таргет. Если у нас, в таблице в системе источнике добавится столбец, или поменяется тип данных, то все сломается, так как данные изменились, а схема нет. Поэтому есть альтернатива - Schema on Read, то есть мы можем обновлять схему каждый раз, когда меняется источник и ничего не сломается. Обычно это в случие неструктурированных данных. Более подробно можно почитать в Snowflake Ebook.

А вы уже добавили в резюме?

Вакансия в Австрии, визу дают. Больше деталей не знаю.

Работает консультантом? Вот список книг, который (возможно) даст вам новые идеи. Я заказал себе все книжки. Кстати использовал Абебукс (Амазон дочка) которая продает б/у книги по 4-5 долларов вместо 20-30.

google.com: Migrating Teradata and other data warehouses to BigQuery.
https://cloud.google.com/blog/products/data-analytics/migrating-teradata-and-other-data-warehouses-to-bigquery

Workbook: The Tableau Chart Catalog
https://public.tableau.com/views/TheTableauChartCatalog/TableauChartExamples?:embed=y&:display_count=yes&:origin=viz_share_link&:showVizHome=no

Хотел поделиться новостью, будем делать первый ивент с Майкрософт в Ванкувере про Azure Data Platform на весь день!https://dwiad.ticketleap.com/data-warehouse-in-a-daysept2019/

Dice Insights: Data Analyst: Necessary Skills, Education, Training, Résumé.
https://insights.dice.com/2019/08/07/data-analyst-education-training-resume/

Как вы знаете, есть два основных типа загрузки данных в хранилище данных(или озеро данных), это batch (грузим пачками раз в сутки или в час) и streaming (поток данных). Как правило ETL/ELT поддерживает только batch. Для стрима нужно использовать другие решения. Самое популярное это Apache Kafka. Ее коммерческая версия это Confluent. Так же у облачных провайдеров есть свои решения. Самое популярное AWS Kinesis. А вот и ссылка с туториал по кафке

Большие данные стали ещё больше

Вы слышали про DevOps? Это понятие пришло из разработки ПО, по простому это как мы разрабатываем ПО, есть ли у нас версионность кода, можно ли вместе менять код, где хранить код, как мы разделяем тест и прод и ТП. Это важно и в аналитике, часто когда мы меняем код (ETL, DW, BI) мы легко можем все поломать и бизнес пользователи не довольны. Отсюда и DevOps для аналитики. Для предикативных моделей тоже важно. https://www.red-gate.com/simple-talk/sql/database-devops-sql/introduction-to-devops-devops-and-the-database/

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

Полезный гайд как в питоне работать с экселельными файлами https://towardsdatascience.com/intro-to-reading-and-writing-spreadsheets-with-python-b635ae514ab8