Size: a a a

Инжиниринг Данных

2020 January 11
Инжиниринг Данных
Существуют NoSQL базы данных, один из типов это Graph. Вы можете полностью использовать такое решение для вашей аналитики. Запись вебинара. https://www.dataversity.net/webinar-graph-data-modeling-in-four-dimensions-outline-differences-artisanship-agility/
источник
Инжиниринг Данных
Есть идеи книг на 2020? Оставляйте в комментариях. Я планирую прочитать свои книги по консалтингу, которые нашел на сайте Harvard Business Review (McKinsey Way и тд).
источник
2020 January 13
Инжиниринг Данных
Всем привет, моя знакомая Оксана Фомина @OxanaFomina, является экспертом по мобильной аналитике. У нее есть много интересных кейсов по аналитике мобильных игр. Сейчас у нее есть время взять еще проектов, если кому интересно, пишите ей.
источник
2020 January 14
Инжиниринг Данных
Написал пост про последнюю книжку Jumpstart Snowflake. Сегодня еще предложили писать книгу под названием Data Storage for Artificial Intelligence. Я вроде как не хотел больше ничего писать, но это отличная возможность написать что-нибудь по AI, тем более что там только 3 главы для меня - Spark и Big Data.
источник
Инжиниринг Данных
Как вы поняли, python является одним из главных и удобных языков для анализа данных и инжиниринга данных. Если вы еще не знаете вот еще один канал по Python, вот что они говорят про себя: "Привет! На связи @python_academy. Ты ведь о нас пока не знаешь, да?

За плечами у нас успешные курс по чат-ботам, а также интенсив и курс по Data Science.

Мы не какая-то безликая машина по созданию курсов, мы два простых парня, Святослав и Адриан. Святослав работает дата аналитиком в Европе, специалист по анализу данных. Адриан Full-Stack разработчик и создатель популярных телеграм ботов с большим стажем.

Вместе мы приглашаем тебя на наш интенсив по чат-ботам в телеграм.

Не пропусти 👉 @python_academy"
Telegram
Python Academy
Наши чат-боты в Telegram

@CheckNicknameBot – самый молодой, однако самый популярный проект среди остальных. За два месяца набралось почти 6к пользователей без какого-либо продвижения. Суть бота понятна из его названия.

@TeleWeatherRobot – уникальный чат-бот, который распознает локацию из любого предложения, парсит прогноз погоды из Интернета и на сервере генерирует красивую картинку с полученной информацией.

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

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

Понравились боты и захотел научиться создавать своих? Тогда оставайся на канале и жди новостей )
источник
2020 January 15
Инжиниринг Данных
Хороший дил! Новая книга по Табло для превью https://playfairdata.us14.list-manage.com/track/click?u=5cddb177e419278ce1c1c874b&id=968d10f2e4&e=a66303f2b0
источник
Инжиниринг Данных
Как ты был вопрос - какие инструменты я использую? Вот мой ответ, если есть выбор конечно.

1. Что я использую для себя.
Если мне нужно сделать какой-нибудь отчетик и посмотреть метрики, я могу обойтись SQL, но лучше конечно все сделать в Tableau (альтернатива для вас это Power BI или google studio). Для табло я могу получить лицензия на год бесплатно - студенческую (просто загуглите student card или студенческий, этой картинке достаточно.

В идеале, я не люблю работать с текстовыми файлами, и все загружу в базу данных. Из бесплатных вариантов это можно использовать Azure SQL Server (год бесплатно) или я видел онлайн инстанс mysql бесплатно. Но можно и установить mysql/postgres/sql server на ноутбук. Я люблю postgres, у него синтаксис как у Redshift. Еще есть вариант Redshift - бесплатно на 2 месяца или Google BigQuery - там тоже можно до 5гб бесплатно на год. Но года 2 назад не было хорошего драйвера для ETL стороннего.

Что касается ETL, мне нравится Pentaho Data Integration, это опен сорс продукт, очень классный, но конечно тормозит, когда данных много, да и серьезные решения тоже лучше не делать, он на Java, и нужен java разработчик для поддержки. Из аналогов это Talend.

Для Data Science можно использовать RapidMiner или Orange (бесплатные версии), отлично для личного пользования.

Кстати важный вопрос! Если есть возможность работать с файлами, то я не люблю XLS, CSV, лучше выгружать данные в TSV.

2. Если бы спросили, что я бы использовал для BI/DW решения, то я бы конечно работал бы с облачными решениями. Мне нравится как развивается Google Cloud, но AWS имеет намного больше преимуществ, да и опыта у меня больше.

В качестве DW я бы сейчас не задумываясь использовал бы Snowflake. Это и хранилище данных и озеро данных, и нет проблем с масштабирванием. Как правило здесь, компании которые внедряют решения, не очень сильно считаю сколько стоит решение, поэтому я бы на цену вообще не смотрел. Если не Snowflake, то это Redshift + Athena (S3+Presto).

Для ETL я бы использовал Matillion ETL (главное преимущество для меня, что это как Табло, я отдаю его пользователям для Self Service). Но однозначно, нужен продукт, которые работает с облаком. Альтернатива мог быть AWS Glue (serverless ETL + Spark computing engine), но Glue уже не для бизнес пользователей, зато легче с DevOps. Если нужно было бы open source, то Airflow.

Для ML/Data Science это AWS Sage Maker для промышленного использования (есть Python Notebooks, то есть все на python и можо использовать TensorFlow/MXNet/Pytorch. А для настольного применения и для аналитиков это Alteryx.

Для BI - Tableau, как альтернатива Looker (cloud native). Кстати в Амазон есть команда в Алекса, которая использует лукер, они его развернули внутри своего AWS. Это какая-то гремучая сместь по сложности устаноки и настройки, как я понял такие истории хорошо заходят для промо документов, где мы пишем свои заслуги, но для меня это бред, если у всех Tableau и одновременно с этим очень пушат Amazon QuickSight.

Для стриминга - Kinesis. Очень классно работает kafka, но если с AWS, то лучше использовать cloud native приложения и я бы старался не изобретать велосипед.

FAQ:
1) Важен ли размер данных? В облаке мне соверщенно не важен размер данных.
2) Важна ли стоимость решения? Важна, и только в облаке я смогу платить только за то, что мне нужно и всегда есть возможность оптимизировать кост.
3) Что еще вожна? Важен SLA, то есть когда пользователь хочет видеть данных, близко к реальному времени (streaming) или утром следующего дня (batch). Так же важна экспертиза команды. Если все знают Microsoft, то внедрять AWS и Tableau не самый быстрый путь.
4) Я не написал про Data Quality и Data Governance. Я привык работать в оргаизациях, где очень быстрый темп, то есть нужно быстро что-то посчитать, и все быстро меняется, время на data management практики нету, это мой bias. Для страховой компании или финансовой организации это очень важный момент.
источник
Инжиниринг Данных
DevOps это Development + Operations. В общем это культура разработки ПО, цель - более короткие циклы деплоймента, повышение частоты деплоймонта, более зависимые релизы и все это к привязке бизнес процессов и целей. Другими словами это культура взаимодействия между разработчиками и operations сотрудниками.

Практики DevOps очень хорошо сформированы для ИТ, сисадминов, разработчиков, но так же используются для аналитики, хранилищ данных и тп. Очень часто команды изобретают велосипед (я сейчас изобретаю такой для своей команды). Есть ответвления - DataOps, MLOps, но все идет от DevOps. Лучше самим разобраться🤗 А вот и бесплатный курс
источник
2020 January 16
Инжиниринг Данных
Инверсная точка зрения.
источник
Инжиниринг Данных
#faketillyoumakeit #jobchange
У меня есть несколько интересных историй, про знакомых и друзей, кому я помог поменять работу или изменить даже жизнь, не знаю к лучшему или худшему. Помогать хорошо для кармы, или просто хорошо, поэтому есть несколько success stories, которые еще актуальны, говорят о том, что все в ваших руках.

История 1,2.
История 3 и 4
У меня был товарищ с завода, он меня научил работать на фрезерном станке🤩. Его звали Стас С. и у него был еще один друг Стас П, который любил говорить "доконца гандончики", после службы ВДВ. Особенно, когда мы ходили на турник или делали что-то с SAP BO.🤣

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

Все работают с большой нагрузкой и в режиме мультизадачности. Это значит, когда мы отправляем резюме, то в лучшем случае HR бегло глянет на него, найдет ключевые слова (BI, DW, SQL) и потом уже назначит следующий шаг. Но если он ведет 20 вакансий, и на каждую приходят по 20 резюме, и при этом нужно успеть попить кофе и с коллегами пообщаться (все мы люди, а не роботы), то получается, все что нужно сделать, это правильно завернуть резюме, чтобы пройти первый farewall и попасть на собеседование. Сам процесс наема это тоже очень интересный процесс, он занимает время, вам нужно отрываться от работа, и там очень много bias, особенно в компаниях, где обычно вас собеседует начальник, то есть в 80% вам надо понравиться начальнику. Я все это к тому, что сам по себе опыт, это не всегда главный критерий.

Стас П. заинтересовался в BI. Дальше все по классике, SQL, SAP BO, database и все это дело на виртуальной машине, новое резюме, несколько историй про BI проекты, и на собеседование в Lamoda. В итоге Стас П стал работать младшим BI разработчиком. Теперь самое главное пройти испытательный срок. Секрет успеха прост, мы компенсируем не знание предмета своим временем, то есть то что я могу сделать за 2 дня, он может сделать за 5 дней, но у него есть в запасе 18 часов в сутках + 2 выходных, таким образом можно все успеть и подтянуть знания. Сейчас, Стас П работает в Польше, внедряет SAP BO,  и наслаждается сельской местностью своей деревней под Варшавой, ездит на мерседесе Е класса в Беларусь и Калининград на выходных😎

Стас С. тоже пошел по такому пути, SQL, SAP BO, резюме и истории, он устроился в Перекресток - BI разработчик. Но не прошел испытательный срок. Просто ему это оказалось не интересно, и он не захотел в это развиваться. Он так до сих пор не нашел себя. Поэтому работу найти просто без опыта с выдуманным резюме, а вот удержаться сложнее, нужно обладать самомотивацией и усидчивостью.
источник
Инжиниринг Данных
Как Амазон тестирует продукты https://youtu.be/e1YwohZPFWg
источник
2020 January 17
Инжиниринг Данных
Пример решения для Amazon Redshift. Решения используют микросервисы, то есть вместо монолитного ETL, у нас много сервисовм, которые работают независимо, и все они выполняются сервисами AWS (AWS Step Function, Lambda, Batch).  Микросервисы очень хороши для приложений и ПО. Но я не люблю использовать такие решения для DW/BI, я за gentle data engineering с фокусом на скорость (fast time to merket/insights) и на бизнес пользователей. Но это моя история, я привык работать в быстро движущейся среде. Возможно в традиционных организациях, где главное стабильность, а не скорость, и где есть армия разработчиков, такие решения хорошо зайдут.

Еще один важный тренд, на примере AWS, решение можно развернуть используя шаблон CloudFormation (аналоги есть Azure, GCP). Это очень важный элемент, и если вы делаете решения в облаке, обязательно изучите вопрос шаблонов, чтобы ваше решения могло быть развернута с одного клика.
источник
Инжиниринг Данных
И если вы используете Power BI, то обязательно подпишитесь на чатик Power BI🤗
источник
Инжиниринг Данных
Вот пример Микросервисов VS монолита. Архитектура микросервисов разбивает приложение на набор маленьких loosely-coupled сервисов. Loosely coupled значит, что сервисы могут общаться через надежные API. Если один из сервисов сломается, то все решение будет продолжать работать.
источник
2020 January 19
Инжиниринг Данных
Самый большой Redshift Cluster может быть 128 нод. Я работаю с таким кластером. 128 Node типа dc2.8xlarge. Это максимально возможное кол-во нод и одновременно недостаток Redshift. 326 ТБ данных (с компрессией это в 2 раза больше данных). И этого нам не хватает. То есть вроде как облако, где можно кликнуть и удвоить мощность, а вроде и уже нельзя. Но это не главная проблема хранилище данных. Главная проблема это кол-во одновременных запросов. (concurrency). То есть кластер может одновременно обрабатывать 15-20 запросов, остальные в очередь. Есть также Work Load Manager (это можно для каждого пользователя настраивать правила, сколько может быть одновременных запросов и при каких условиях убивать плохие запросы). Самая дорогая операция - это копирование данных между нодами (data distribution), именно поэтому единственное что важно знать в аналитических хранилищах - это правила распределения данных и варианты (Distribution style, sorty key), чтобы снизить нагрузку на копирование ТБ данных по сети.

У меня была задача, пересчитать метрика за 2018 и 2019 года. Я не могу это выполнить одним запросом, так как если я запущу запрос, где данных больше 1 недели, WLM его убьет. В итоге у меня 1 запрос - это 1 день. Значит надо где-то 600 раз запустить один и тот же джоб. То есть можно это сделать programmatically. Вот когда нам нужно знать Python. Сделать цикл, который будет запускать джоб (ее API). Недолго думая, я запустил все это дело с параметром 1000 параллельных запросов.  И я сделал это несколько раз.

Я не знал несколько деталей, сколько одновременных запросов может обрабатывать Redshift от этого пользователя (оказалось 3), сколько обычно Redshift обрабатывает запросов (оказалос 1500-1800). В результате выстроилась очередь в 3500 запросов и несколько дней.

Ситуация мне напомнила книгу "Продавец Обуви" - "Вас запоминают не за правила, которым вы следуете, а за правила, которые вы нарушаете". В целом, это проблема дизайна, то есть когда строили хранилище, не знали, что с ним будет дальше. И это уже второй Redshift, который переживает сложные времена. Другая команда, имела похожие проблемы, в итоге они заменили все на Озеро Данных (S3+Athena). Но главный challenge для озера данных и big data платформ, это GDPR, то есть как удалить клиента, если он лежит в каком-то Parquet файле.
источник
Инжиниринг Данных
Еще напомнило. Самолет это Redshift, красные точки это запросы. И возможно мои запросы не были так критичны (3-4 минуты) один запрос, как запросы кого-нибудь, которые могут висеть вечно и никто не узнает про них (например, если вы запустили запрос и удалил job, и он будет вечно висеть и занимать слот)
источник
Инжиниринг Данных
Как я понял, эта книга просто бомба, The Great Mental Models. Меня поразила цена в 80 баксов за твердый переплет, их совсем мало. Но очень заинтересовала.  Никто не читал?
источник
2020 January 20
Инжиниринг Данных
Написал блог про сертификацию. Там половина в общем про сетификацию, а 2ая половина про табло. На самом деле это текст предназанчался для книги по Табло сертификации, но я указал 3 основных случая, когда нужна сертификация и почему:
1)Требование работадателя
2)Требование клиента(консалтинг)
3)Просто показать, что у нас есть скилы. Но это не очень крутой аргумент, чтобы зубрить экзамен.

Я например сдал Tableau Desktop и Server, чтобы стать Tableau Alliance Partner. Так еще сверху заплатил 3k US$, partnership fee. Теперь у меня есть Tableau Server, Desktop и Prep и 25 лицензий. Но в марте все это кончается, и будет вопрос, а стоит ли продлевать эти отношения или нет.
источник
2020 January 21
Инжиниринг Данных
Сказали, что очень классный курс - https://www.startupschool.org/. К сожалению, все инкубаторы нацелены на продуктовые компании, и я еще не встречал информации по сервисным компаниям. Оно и понятно, сложно масштабируется и зависит от команды. Если, что знаете, кидайте в комментарии.

Кстати одна из моих любимых книг по аналитике это Lean Analytics. В этой книге есть KPI по основным индустриям и примеры методологий, включая мой любимый OKR.
источник
2020 January 22
Инжиниринг Данных
Полезный коммент увидел про удаленную работу
источник