Как ты был вопрос - какие инструменты я использую? Вот мой ответ, если есть выбор конечно.
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. Для страховой компании или финансовой организации это очень важный момент.
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. Лучше самим разобраться🤗 А вот и бесплатный курс
Практики DevOps очень хорошо сформированы для ИТ, сисадминов, разработчиков, но так же используются для аналитики, хранилищ данных и тп. Очень часто команды изобретают велосипед (я сейчас изобретаю такой для своей команды). Есть ответвления - DataOps, MLOps, но все идет от DevOps. Лучше самим разобраться🤗 А вот и бесплатный курс
#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 разработчик. Но не прошел испытательный срок. Просто ему это оказалось не интересно, и он не захотел в это развиваться. Он так до сих пор не нашел себя. Поэтому работу найти просто без опыта с выдуманным резюме, а вот удержаться сложнее, нужно обладать самомотивацией и усидчивостью.
У меня есть несколько интересных историй, про знакомых и друзей, кому я помог поменять работу или изменить даже жизнь, не знаю к лучшему или худшему. Помогать хорошо для кармы, или просто хорошо, поэтому есть несколько 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 разработчик. Но не прошел испытательный срок. Просто ему это оказалось не интересно, и он не захотел в это развиваться. Он так до сих пор не нашел себя. Поэтому работу найти просто без опыта с выдуманным резюме, а вот удержаться сложнее, нужно обладать самомотивацией и усидчивостью.
Пример решения для Amazon Redshift. Решения используют микросервисы, то есть вместо монолитного ETL, у нас много сервисовм, которые работают независимо, и все они выполняются сервисами AWS (AWS Step Function, Lambda, Batch). Микросервисы очень хороши для приложений и ПО. Но я не люблю использовать такие решения для DW/BI, я за gentle data engineering с фокусом на скорость (fast time to merket/insights) и на бизнес пользователей. Но это моя история, я привык работать в быстро движущейся среде. Возможно в традиционных организациях, где главное стабильность, а не скорость, и где есть армия разработчиков, такие решения хорошо зайдут.
Еще один важный тренд, на примере AWS, решение можно развернуть используя шаблон CloudFormation (аналоги есть Azure, GCP). Это очень важный элемент, и если вы делаете решения в облаке, обязательно изучите вопрос шаблонов, чтобы ваше решения могло быть развернута с одного клика.
Еще один важный тренд, на примере AWS, решение можно развернуть используя шаблон CloudFormation (аналоги есть Azure, GCP). Это очень важный элемент, и если вы делаете решения в облаке, обязательно изучите вопрос шаблонов, чтобы ваше решения могло быть развернута с одного клика.
Amazon
Orchestrate an ETL process using AWS Step Functions for Amazon Redshift | Amazon Web Services
Modern data lakes depend on extract, transform, and load (ETL) operations to convert bulk information into usable data. This post walks through implementing an ETL orchestration process that is loosely coupled using AWS Step Functions, AWS Lambda, and AWS…
И если вы используете Power BI, то обязательно подпишитесь на чатик Power BI🤗
Telegram
Power BI Group RU
Правила: https://t.me/PBI_Rus/7 (там же ссылки на профильные группы и материалы)
(@LebedevDmitry)
(@LebedevDmitry)
Самый большой 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 файле.
У меня была задача, пересчитать метрика за 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, и он будет вечно висеть и занимать слот)
Написал блог про сертификацию. Там половина в общем про сетификацию, а 2ая половина про табло. На самом деле это текст предназанчался для книги по Табло сертификации, но я указал 3 основных случая, когда нужна сертификация и почему:
1)Требование работадателя
2)Требование клиента(консалтинг)
3)Просто показать, что у нас есть скилы. Но это не очень крутой аргумент, чтобы зубрить экзамен.
Я например сдал Tableau Desktop и Server, чтобы стать Tableau Alliance Partner. Так еще сверху заплатил 3k US$, partnership fee. Теперь у меня есть Tableau Server, Desktop и Prep и 25 лицензий. Но в марте все это кончается, и будет вопрос, а стоит ли продлевать эти отношения или нет.
1)Требование работадателя
2)Требование клиента(консалтинг)
3)Просто показать, что у нас есть скилы. Но это не очень крутой аргумент, чтобы зубрить экзамен.
Я например сдал Tableau Desktop и Server, чтобы стать Tableau Alliance Partner. Так еще сверху заплатил 3k US$, partnership fee. Теперь у меня есть Tableau Server, Desktop и Prep и 25 лицензий. Но в марте все это кончается, и будет вопрос, а стоит ли продлевать эти отношения или нет.
Medium
The Role of Professional Certification
Why do you need a Visual Analytics certification?
Сказали, что очень классный курс - https://www.startupschool.org/. К сожалению, все инкубаторы нацелены на продуктовые компании, и я еще не встречал информации по сервисным компаниям. Оно и понятно, сложно масштабируется и зависит от команды. Если, что знаете, кидайте в комментарии.
Кстати одна из моих любимых книг по аналитике это Lean Analytics. В этой книге есть KPI по основным индустриям и примеры методологий, включая мой любимый OKR.
Кстати одна из моих любимых книг по аналитике это Lean Analytics. В этой книге есть KPI по основным индустриям и примеры методологий, включая мой любимый OKR.
Amazon
Lean Analytics: Use Data to Build a Better Startup Faster
Libro usado en buenas condiciones, por su antiguedad podria contener señales normales de uso
Weekly Business Review или WBR или Wall of Numbers - еженедельные встречи в Амазон, где обсуждаются метрики. Амазон же data-drive компания. Что это из себя представляет? Прежде всего отчет (обычно без графиков и визуализации, вообще) в формате PDF (экспорт из Tableau в лучшем случае) или просто Excel (в 80%). Вот вам ирония, самая data driven компания смотрит в статические отчеты и делает это раз в неделю. Отсюда напрашиваются выводы:
1) Для бизнес метрик и целей, нужно ли нам делать near real time data pipelines? Конечно нужны, но все зависит от задачи и требований.
2) Нужно ли нам смотреть на наши показатели 5 раз в день, каждый день? Важно держать руку на пульсе для операционных метрик, но там нужно настраивать систему оповещения (alert) если что-то отклонилось от нормы.
3) Нужно ли нам много красиво графиков? Доказано, что визуализацию лучше цифр. Но бизнес лидеры предпочитаю смотреть на цифры.
4) Нужны ли нам дорогие инструменты визуализации и аналитики? Для статистических отчетов типа WBR нет. Но для анлитиков, которые ковыряются в данных (deep dive), нужны.
Вывод простой, неважно каким образом мы строим отчеты, и что используем. Они должны помогать бизнесу делать их работу - смотреть на данные и принимать решения, которые нацелены всего на 3 цели:
1) Увеличить прибыль
2) Снизить издержки
3) Снизить риски
Пример WBR слайда. Обычно это 50 страниц, где могут смотреть на одни и теже метрики в разных разрезах. Всегда готовят 50 слайдов, но обсуждают только 10, которые важно обсудить. Перед встречей нужно, написать callouts (что значимого случилось), после встречи часто нужно делать deep dive, и объяснить отклонения, во многих случаях это ошибка в ETL (нет инструментов data quality, notifications).
Абсолютно все делают такие отчеты, и многие изобретают велосипед.
1) Для бизнес метрик и целей, нужно ли нам делать near real time data pipelines? Конечно нужны, но все зависит от задачи и требований.
2) Нужно ли нам смотреть на наши показатели 5 раз в день, каждый день? Важно держать руку на пульсе для операционных метрик, но там нужно настраивать систему оповещения (alert) если что-то отклонилось от нормы.
3) Нужно ли нам много красиво графиков? Доказано, что визуализацию лучше цифр. Но бизнес лидеры предпочитаю смотреть на цифры.
4) Нужны ли нам дорогие инструменты визуализации и аналитики? Для статистических отчетов типа WBR нет. Но для анлитиков, которые ковыряются в данных (deep dive), нужны.
Вывод простой, неважно каким образом мы строим отчеты, и что используем. Они должны помогать бизнесу делать их работу - смотреть на данные и принимать решения, которые нацелены всего на 3 цели:
1) Увеличить прибыль
2) Снизить издержки
3) Снизить риски
Пример WBR слайда. Обычно это 50 страниц, где могут смотреть на одни и теже метрики в разных разрезах. Всегда готовят 50 слайдов, но обсуждают только 10, которые важно обсудить. Перед встречей нужно, написать callouts (что значимого случилось), после встречи часто нужно делать deep dive, и объяснить отклонения, во многих случаях это ошибка в ETL (нет инструментов data quality, notifications).
Абсолютно все делают такие отчеты, и многие изобретают велосипед.
Попробовал использовать хабр и перевел статью про озеро данных. Уже вижу комментарии под постом как в анектоде: "На форуме пишут, не подскажите, где купить хороших яблок?", А в ответ: "Зачем вам яблоки? Лучше груши" или "Опять вы со своими яблоками, уже всем надоели ваши яблоки" и другие упрёки, это очень у нас такой менталитет🤠 если есть чего по делу можно написать поподробней, рассказать, чтобы другим было понятно и полезно. В общем это был эксперимент. Кстати комментарий с рекламой облаков меня поставил в ступр, я нахожусь в другом рынке и конечно у меня bias в сторону того, что я использую в Амазон, rock your data и в целом в моей индустрии. А возможно это как писать про то, что уже надоели со своими машинами во времена, когда форд изобрел автомобиль, может облака это тоже прогресс? В общем если нравиться и полезно, ставьте лайк, если есть чего добавить расскажите так чтобы было всем понятно, а если нет, можно мимо пройти🥂
Хабр
Нужно ли нам озеро данных? А что делать с хранилищем данных?
Это статья перевод моей статьи на medium — Getting Started with Data Lake, которая оказалась довольно популярной, наверное из-за своей простоты. Поэтому я решил...
Слышали вы про H20? Это платформа для data science и ml. И это open source. https://youtu.be/BtnugVpu7V8
YouTube
5 Key Considerations in Picking an AutoML Platform
AutoML platforms and solutions are quickly becoming the dominant way for every enterprise that is looking to implement and scale their ML and AI projects. As Forrester pointed out, these tools are trying to automate the end-to-end life cycle of developing…