How ZS created a multi-tenant self-service data orchestration platform using Amazon MWAA
Read: https://aws.amazon.com/blogs/big-data/how-zs-created-a-multi-tenant-self-service-data-orchestration-platform-using-amazon-mwaa/
Read: https://aws.amazon.com/blogs/big-data/how-zs-created-a-multi-tenant-self-service-data-orchestration-platform-using-amazon-mwaa/
👍1
Data Engineering Weekly #101
Read: https://www.dataengineeringweekly.com/p/data-engineering-weekly-101
Read: https://www.dataengineeringweekly.com/p/data-engineering-weekly-101
👍1
Подготовка датасета для машинного обучения: 10 базовых способов совершенствования данных
У Колумбийского университета есть хорошая история о плохих данных. Проект в сфере здравоохранения был нацелен на снижение затрат на лечение пациентов с пневмонией. В нём использовалось машинное обучение (machine learning, ML) для автоматической сортировки записей пациентов, чтобы выбрать тех, у кого опасность смертельного исхода минимальна (они могут принимать антибиотики дома), и тех, у кого опасность смертельного исхода высока (их нужно лечить в больнице). Команда разработчиков использовала исторические данные из клиник, а алгоритм был точным.
Но за одним важным исключением. Одним из наиболее опасных состояний при пневмонии является астма, поэтому врачи всегда отправляют астматиков в отделение интенсивной терапии, что приводило к минимизации уровня смертности для этих пациентов. Благодаря отсутствию смертельных случаев у астматиков в данных алгоритм предположил, что астма не так уж опасна при пневмонии, и во всех случаях машина рекомендовала отправлять астматиков домой, несмотря на то, что для них риск осложнений при пневмонии был наибольшим.
ML сильно зависит от данных. Это самый критически важный аспект, благодаря которому и возможно обучение алгоритма; именно поэтому машинное обучение стало столь популярным в последние годы. Но вне зависимости от терабайтов информации и экспертизы в data science, если ты не можешь понять смысл записей данных, то машина будет практически бесполезной, а иногда и наносить вред.
Читать: https://habr.com/ru/post/684580/
У Колумбийского университета есть хорошая история о плохих данных. Проект в сфере здравоохранения был нацелен на снижение затрат на лечение пациентов с пневмонией. В нём использовалось машинное обучение (machine learning, ML) для автоматической сортировки записей пациентов, чтобы выбрать тех, у кого опасность смертельного исхода минимальна (они могут принимать антибиотики дома), и тех, у кого опасность смертельного исхода высока (их нужно лечить в больнице). Команда разработчиков использовала исторические данные из клиник, а алгоритм был точным.
Но за одним важным исключением. Одним из наиболее опасных состояний при пневмонии является астма, поэтому врачи всегда отправляют астматиков в отделение интенсивной терапии, что приводило к минимизации уровня смертности для этих пациентов. Благодаря отсутствию смертельных случаев у астматиков в данных алгоритм предположил, что астма не так уж опасна при пневмонии, и во всех случаях машина рекомендовала отправлять астматиков домой, несмотря на то, что для них риск осложнений при пневмонии был наибольшим.
ML сильно зависит от данных. Это самый критически важный аспект, благодаря которому и возможно обучение алгоритма; именно поэтому машинное обучение стало столь популярным в последние годы. Но вне зависимости от терабайтов информации и экспертизы в data science, если ты не можешь понять смысл записей данных, то машина будет практически бесполезной, а иногда и наносить вред.
Читать: https://habr.com/ru/post/684580/
👍6🔥1
Detect and process sensitive data using AWS Glue Studio
Read: https://aws.amazon.com/blogs/big-data/detect-and-process-sensitive-data-using-aws-glue-studio/
Read: https://aws.amazon.com/blogs/big-data/detect-and-process-sensitive-data-using-aws-glue-studio/
👍1
5 этапов оптического распознавания символов на практике
Распознавание символов довольно сложная задача для компьютера. А сегодня в ней всё больше необходимости, ведь автоматизация обработки различных документов и данных ускоряет решение многих вопросов. Например, в системах банкинга, которые таким образом могут ускорить одобрение кредита или выполнение иной услуги.
В этой статье вы узнаете, как разработчики из Ренессанс Кредит решали эту задачу: https://tprg.ru/jnzF
Распознавание символов довольно сложная задача для компьютера. А сегодня в ней всё больше необходимости, ведь автоматизация обработки различных документов и данных ускоряет решение многих вопросов. Например, в системах банкинга, которые таким образом могут ускорить одобрение кредита или выполнение иной услуги.
В этой статье вы узнаете, как разработчики из Ренессанс Кредит решали эту задачу: https://tprg.ru/jnzF
👍1
Everything Bagel, часть II: версионные таблицы озера данных в lakeFS и Trino
Команда VK Cloud уже переводила статью о том, как развернуть локальный стек данных с помощью инструмента Everything Bagel. Теперь переводим вторую часть, в которой на практике разбираем, как выполнять запросы к разветвленным данным lakeFS через механизм распределенных запросов Trino.
Читать: https://habr.com/ru/post/687764/
Команда VK Cloud уже переводила статью о том, как развернуть локальный стек данных с помощью инструмента Everything Bagel. Теперь переводим вторую часть, в которой на практике разбираем, как выполнять запросы к разветвленным данным lakeFS через механизм распределенных запросов Trino.
Читать: https://habr.com/ru/post/687764/
👍1
Kafka как интеграционная платформа: от источников данных к потребителям и в хранилище (часть 2)
Привет! Продолжаю рассказ про интеграционную платформу на базе Apache Kafka и про то, как мы постарались гармонично вписать ее в непростую ИТ инфраструктуру группы НЛМК.
Напомню, что в первой части статьи были описаны соглашения об именовании топиков, подход к реализации ролевой модели и соглашение по базовой схеме данных. Здесь расскажу, как сделали универсальное охлаждение для всех данных из Kafka в корпоративное хранилище на базе Hadoop, про сервис доставки сообщений в ИС и про разработанные сервисы, доступные на нашем Self-Serves портале.
Читать: https://habr.com/ru/post/686778/
Привет! Продолжаю рассказ про интеграционную платформу на базе Apache Kafka и про то, как мы постарались гармонично вписать ее в непростую ИТ инфраструктуру группы НЛМК.
Напомню, что в первой части статьи были описаны соглашения об именовании топиков, подход к реализации ролевой модели и соглашение по базовой схеме данных. Здесь расскажу, как сделали универсальное охлаждение для всех данных из Kafka в корпоративное хранилище на базе Hadoop, про сервис доставки сообщений в ИС и про разработанные сервисы, доступные на нашем Self-Serves портале.
Читать: https://habr.com/ru/post/686778/
👍2
Подборка актуальных вакансий
— Middle / Senior System Analyst
Где: Москва, можно удалённо
Опыт: от 3 лет
— Ведущий системный аналитик
Где: Москва, можно удалённо
Опыт: от 2 лет
— Аналитик DWH
Где: Москва, можно удалённо
Опыт: от 3 лет
— Системный аналитик
Где: Москва, можно удалённо
Опыт: от 3 лет
— Ведущий системный аналитик
Где: Москва, можно удалённо
Опыт: от 3 лет
#вакансии #работа
— Middle / Senior System Analyst
Где: Москва, можно удалённо
Опыт: от 3 лет
— Ведущий системный аналитик
Где: Москва, можно удалённо
Опыт: от 2 лет
— Аналитик DWH
Где: Москва, можно удалённо
Опыт: от 3 лет
— Системный аналитик
Где: Москва, можно удалённо
Опыт: от 3 лет
— Ведущий системный аналитик
Где: Москва, можно удалённо
Опыт: от 3 лет
#вакансии #работа
👍1
Design considerations for Amazon EMR on EKS in a multi-tenant Amazon EKS environment
Read: https://aws.amazon.com/blogs/big-data/design-considerations-for-amazon-emr-on-eks-in-a-multi-tenant-amazon-eks-environment/
Read: https://aws.amazon.com/blogs/big-data/design-considerations-for-amazon-emr-on-eks-in-a-multi-tenant-amazon-eks-environment/
👍2
Talk to your data: Query your data lake with Amazon QuickSight Q
Read: https://aws.amazon.com/blogs/big-data/talk-to-your-data-query-your-data-lake-with-amazon-quicksight-q/
Read: https://aws.amazon.com/blogs/big-data/talk-to-your-data-query-your-data-lake-with-amazon-quicksight-q/
👍1
Super Protocol: трансформирует облачные вычисления для Web3
Super Protocol — это платформа конфиденциальных облачных вычислений, предназначенная для защиты данных во время их обработки. Это децентрализованная платформа на блокчейне, что означает, что ей не присущи недостатки при использовании централизованных сервисов.
В этой статье я постараюсь рассказать о Super Protocol и о том, какие задачи он позволяет решать.
Современное состояние облачных вычислений
Облачные вычисления - это предоставление вычислительной мощности (серверов, памяти, баз данных, сетей и ПО) посредством Интернет в целях аренды (как сервис). Облачные провайдеры позволяют компаниям и индивидуальным пользователям расширить их вычислительные способности. С такого рода сервисами пользователи могут хранить больше информации в облачных хранилищах, обрабатывать больше данных и использовать ПО как сервис (SaaS).
На текущий момент облачные вычисления используются повсеместно: онлайн-переводчики, онлайн-игры, платежные сервисы, видео коммуникации, сервисы навигации, онлайн-библиотеки, онлайн-почта, хранилища данных и многое другое.
За 2020 год рынок облачных вычислений вырос до $371,4 млрд. и продолжает свой бурный рост. Каждый год потребность в облачных вычислениях растет и также она растет в сфере технологий WEB 3.0. К 2025 году рынок может достичь оценки $832,1 млрд., со среднегодовым приростом в 17,5%.
В то же самое время облачные вычисления имеют ряд недостатков, которые призван устранить Super Protocol.
Недостатки централизованный сервисов, предоставляющих облачные вычисления
Читать: https://habr.com/ru/post/689120/
Super Protocol — это платформа конфиденциальных облачных вычислений, предназначенная для защиты данных во время их обработки. Это децентрализованная платформа на блокчейне, что означает, что ей не присущи недостатки при использовании централизованных сервисов.
В этой статье я постараюсь рассказать о Super Protocol и о том, какие задачи он позволяет решать.
Современное состояние облачных вычислений
Облачные вычисления - это предоставление вычислительной мощности (серверов, памяти, баз данных, сетей и ПО) посредством Интернет в целях аренды (как сервис). Облачные провайдеры позволяют компаниям и индивидуальным пользователям расширить их вычислительные способности. С такого рода сервисами пользователи могут хранить больше информации в облачных хранилищах, обрабатывать больше данных и использовать ПО как сервис (SaaS).
На текущий момент облачные вычисления используются повсеместно: онлайн-переводчики, онлайн-игры, платежные сервисы, видео коммуникации, сервисы навигации, онлайн-библиотеки, онлайн-почта, хранилища данных и многое другое.
За 2020 год рынок облачных вычислений вырос до $371,4 млрд. и продолжает свой бурный рост. Каждый год потребность в облачных вычислениях растет и также она растет в сфере технологий WEB 3.0. К 2025 году рынок может достичь оценки $832,1 млрд., со среднегодовым приростом в 17,5%.
В то же самое время облачные вычисления имеют ряд недостатков, которые призван устранить Super Protocol.
Недостатки централизованный сервисов, предоставляющих облачные вычисления
Читать: https://habr.com/ru/post/689120/
👍1
OpenAI решили распознавание речи! Разбираемся так ли это…
Вчера OpenAI выпустили Whisper. По сути они просто опубликовали веса набора больших (и не очень) рекуррентных трансформеров для распознавания речи и статью (и самое главное, в статье ни слова про compute и ресурсы). И естественно уже вчера и сегодня утром мне в личку начали сыпаться сообщения, мол всё, распознавание речи решено, все идеально классно и быстро работает, расходимся.
Постараемся разобраться под катом. Короткий ответ, если вам лень читать - для языков, кроме английского, скорее всего это далеко от правды (проверил я на русском). На английском наверное стоит сделать отдельный и чуть более подробный разбор, если эта статья наберет хотя бы 50 плюсов.
Итак, поехали!
Читать: https://habr.com/ru/post/689572/
Вчера OpenAI выпустили Whisper. По сути они просто опубликовали веса набора больших (и не очень) рекуррентных трансформеров для распознавания речи и статью (и самое главное, в статье ни слова про compute и ресурсы). И естественно уже вчера и сегодня утром мне в личку начали сыпаться сообщения, мол всё, распознавание речи решено, все идеально классно и быстро работает, расходимся.
Постараемся разобраться под катом. Короткий ответ, если вам лень читать - для языков, кроме английского, скорее всего это далеко от правды (проверил я на русском). На английском наверное стоит сделать отдельный и чуть более подробный разбор, если эта статья наберет хотя бы 50 плюсов.
Итак, поехали!
Читать: https://habr.com/ru/post/689572/
❤2👎1
Как мы строим свою платформу для аналитиков
Привет, с вами снова Галина Вакулина, и в этой статье я расскажу, как мы строим платформу для аналитиков и избавляем их от ненужной работы.
Цель нашей команды — сделать так, чтобы в Точке работать с данными было удобно и быстро. Чем меньше времени аналитик тратит на рутину, тем больше времени у него остаётся на исследования, придумывание новых метрик, построение дашбордов, проверку гипотез и просто захватывающее копание в данных.
Читать: https://habr.com/ru/post/689140/
Привет, с вами снова Галина Вакулина, и в этой статье я расскажу, как мы строим платформу для аналитиков и избавляем их от ненужной работы.
Цель нашей команды — сделать так, чтобы в Точке работать с данными было удобно и быстро. Чем меньше времени аналитик тратит на рутину, тем больше времени у него остаётся на исследования, придумывание новых метрик, построение дашбордов, проверку гипотез и просто захватывающее копание в данных.
Читать: https://habr.com/ru/post/689140/
👍2
Потери данных при репликации в аналитическое хранилище — автоматические сверки и мониторинг качества данных
Данные из боевых баз в нашей архитектуре асинхронно попадают в аналитическое хранилище (Clickhouse), где уже аналитики создают дашборды для продуктовых команд и делают выборки. Базы здоровые и под ощутимой нагрузкой: мы в день отправляем флот самолётов средней авиакомпании, несколько поездов и кучу автобусов. Поэтому взаимодействий с продуктом много.
ETL-процесс (извлечение данных, трансформация и загрузка в хранилище) часто подразумевает сложную логику переноса данных, и изначально нет уверенности в том, что данные доставляются без потерь и ошибок. Мы используем Kafka как шину данных, промежуточные сервисы на Benthos для трансформации записей и отправки в Clickhouse. На этапе создания пайплайна нужно было убедиться в отсутствии потерь с нашей стороны и корректной логике записи в шину данных.
Проверять вручную расхождения каждый раз не хотелось, кроме того мы нуждались в сервисе, который умел бы сверять новые данные по расписанию и показывать наглядно, где и какие имеются расхождения. Поэтому мы сделали сервис сверок, о котором я и расскажу, потому что готовых решений не нашёл.
Читать: https://habr.com/ru/post/689224/
Данные из боевых баз в нашей архитектуре асинхронно попадают в аналитическое хранилище (Clickhouse), где уже аналитики создают дашборды для продуктовых команд и делают выборки. Базы здоровые и под ощутимой нагрузкой: мы в день отправляем флот самолётов средней авиакомпании, несколько поездов и кучу автобусов. Поэтому взаимодействий с продуктом много.
ETL-процесс (извлечение данных, трансформация и загрузка в хранилище) часто подразумевает сложную логику переноса данных, и изначально нет уверенности в том, что данные доставляются без потерь и ошибок. Мы используем Kafka как шину данных, промежуточные сервисы на Benthos для трансформации записей и отправки в Clickhouse. На этапе создания пайплайна нужно было убедиться в отсутствии потерь с нашей стороны и корректной логике записи в шину данных.
Проверять вручную расхождения каждый раз не хотелось, кроме того мы нуждались в сервисе, который умел бы сверять новые данные по расписанию и показывать наглядно, где и какие имеются расхождения. Поэтому мы сделали сервис сверок, о котором я и расскажу, потому что готовых решений не нашёл.
Читать: https://habr.com/ru/post/689224/
👍1
Enable self-service visual data integration and analysis for fund performance using AWS Glue Studio and Amazon QuickSight
Read: https://aws.amazon.com/blogs/big-data/enable-self-service-visual-data-integration-and-analysis-for-fund-performance-using-aws-glue-studio-and-amazon-quicksight/
Read: https://aws.amazon.com/blogs/big-data/enable-self-service-visual-data-integration-and-analysis-for-fund-performance-using-aws-glue-studio-and-amazon-quicksight/
👍1
Critics, stories, and ethics
Read: https://junkcharts.typepad.com/numbersruleyourworld/2022/09/critics-stories-and-ethics.html
Read: https://junkcharts.typepad.com/numbersruleyourworld/2022/09/critics-stories-and-ethics.html
👍1
Upgrade Amazon EMR Hive Metastore from 5.X to 6.X
Read: https://aws.amazon.com/blogs/big-data/upgrade-amazon-emr-hive-metastore-from-5-x-to-6-x/
Read: https://aws.amazon.com/blogs/big-data/upgrade-amazon-emr-hive-metastore-from-5-x-to-6-x/
👍1
Run a data processing job on Amazon EMR Serverless with AWS Step Functions
Read: https://aws.amazon.com/blogs/big-data/run-a-data-processing-job-on-amazon-emr-serverless-with-aws-step-functions/
Read: https://aws.amazon.com/blogs/big-data/run-a-data-processing-job-on-amazon-emr-serverless-with-aws-step-functions/
👍1
Чего ждать от «Управления данными 2022»?
Привет, Хабр! Буквально на днях, уже на следующей неделе стартует конференция “Управление данными 2022”. Издательство "Открытые Системы" проводит мероприятие седьмой год подряд, но в 2022 году форум обещает быть особенно интересным. Почему мы решили принять в нем участие, и какие доклады, я сам бы хотел послушать, читайте под катом.
Узнать больше
Читать: https://habr.com/ru/post/690026/
Привет, Хабр! Буквально на днях, уже на следующей неделе стартует конференция “Управление данными 2022”. Издательство "Открытые Системы" проводит мероприятие седьмой год подряд, но в 2022 году форум обещает быть особенно интересным. Почему мы решили принять в нем участие, и какие доклады, я сам бы хотел послушать, читайте под катом.
Узнать больше
Читать: https://habr.com/ru/post/690026/
👍1
Data Engineering Weekly #102
Read: https://www.dataengineeringweekly.com/p/data-engineering-weekly-102
Read: https://www.dataengineeringweekly.com/p/data-engineering-weekly-102
👍1
Распознавание фейков с помощью технологий управления данными
Развитие технологий и все возрастающие объемы информации привели к тому, что слово «фейк» или «информационный фейк» прочно вошло в нашу жизнь. Всевозможные мошенники идут в ногу со временем и оперативно ставят себе на службу технологии, изобретая все новые способы влиять на людей. А значит, нам необходимо задуматься о том, как использовать накопившийся опыт и технологии управления информацией для распознавания фейков, т.е. для их автоматического отделения от реальных фактов. Сегодня мы расскажем о всем многообразии использования технологий управления данными для распознавания фейков.
Что же такое фейки?
Существует множество определений фейков, мы не будем на них останавливаться, но отметим, что в этой статье мы будем говорить не об ошибочной информации (такой как опечатки или случайно вкравшиеся неточности), а об информации искажавшейся намеренно.
Фейки можно встретить практически в любой форме — тексте, видео или аудио контенте. Поговорим сначала о последних. Для создания аудио и видео фейков существует специальный инструментарий, построенный на глубоком обучении (deep learning). Искаженные таким образом факты называются дипфейками [1, 2]. Кажется, что уже все видели их примеры — эти видеоклипы с различными знаменитостями, которые говорили или делали что-то, чего на самом деле не было (в [3] есть небольшой таймлайн с известными дипфейками), многие пранкеры используют дипфейки в своих звонках. Однако дипфейки это не развлечение, а серьезная угроза: продвинутые мошенники их уже освоили и во-всю пускают в дело [4, 5].
Читать: https://habr.com/ru/post/690206/
Развитие технологий и все возрастающие объемы информации привели к тому, что слово «фейк» или «информационный фейк» прочно вошло в нашу жизнь. Всевозможные мошенники идут в ногу со временем и оперативно ставят себе на службу технологии, изобретая все новые способы влиять на людей. А значит, нам необходимо задуматься о том, как использовать накопившийся опыт и технологии управления информацией для распознавания фейков, т.е. для их автоматического отделения от реальных фактов. Сегодня мы расскажем о всем многообразии использования технологий управления данными для распознавания фейков.
Что же такое фейки?
Существует множество определений фейков, мы не будем на них останавливаться, но отметим, что в этой статье мы будем говорить не об ошибочной информации (такой как опечатки или случайно вкравшиеся неточности), а об информации искажавшейся намеренно.
Фейки можно встретить практически в любой форме — тексте, видео или аудио контенте. Поговорим сначала о последних. Для создания аудио и видео фейков существует специальный инструментарий, построенный на глубоком обучении (deep learning). Искаженные таким образом факты называются дипфейками [1, 2]. Кажется, что уже все видели их примеры — эти видеоклипы с различными знаменитостями, которые говорили или делали что-то, чего на самом деле не было (в [3] есть небольшой таймлайн с известными дипфейками), многие пранкеры используют дипфейки в своих звонках. Однако дипфейки это не развлечение, а серьезная угроза: продвинутые мошенники их уже освоили и во-всю пускают в дело [4, 5].
Читать: https://habr.com/ru/post/690206/
👍1