Привет! Меня зовут Антон Поляков, и я разрабатываю аналитическое хранилище данных и ELT-процессы в ManyChat. 

Несколько лет назад мы выбрали Snowflake как сервис для нашей дата-платформы. С ростом объемов данных до сотен миллионов строк (спойлер: а затем и до десятков миллиардов), мы задались вопросом: «Как тратить меньше времени на расчет запросов для ежедневной отчетности?». Идеальным вариантом было использование материализованных представлений, позволяющих обращаться к предварительно вычисленным результатам расчета витрин гораздо быстрее, чем к исходным данным.

Мы могли отдать управление нашим пайплайном таким популярным сегодня инструментам для трансформации данных, как, например, dbt, Matillion или Dataform. Однако, в начале 2020 года ни у одного из них не было возможности тонкой кастомизации под нужды Snowflake и ManyChat. К тому же, нам не хотелось платить за еще один сторонний инструмент. Так, мы приняли решение изобрести собственный велосипед для работы с материализацией данных. Именно об этом я сегодня и расскажу.

Про принципы Solid написано немало, в том числе на Хабре. Показывали в картинках, рассказывали на примерах.  

Так чем же будет отличаться эта статья, спросите вы? А мы скажем: подходом. Сначала мы расскажем про ситуации, которые порой возникают на проектах, как код разрастается, становится сложнее и как сделать так, чтобы этот самый код не потерял в качестве и был читаем. 

Интуитивное понимание Нормального распределения

Привет, %username%! Меня зовут Кирилл Фурзанов, я Data Scientist в Сбере, участник профессионального сообщества NTA. При формировании витрин данных и датасетов в экосистеме Hadoop одним из важных вопросов является выбор оптимального способа хранения данных в hdfs. Рассмотрим один из важных вопросов при создании витрины – выбор соответствующего формата файла для хранения.

• пишут код;
  
• отлаживают, тестируют;
  
• после этого упаковывают в jar;
  
• отправляют на Linux, и оно работает.
  

• чужеродное;
  
• проприетарное;
  
• собирается не из исходников;
  
• поставляется какими-то jar-архивами;
  
• «отъедает» всю память на сервере;
  
• вообще, ведёт себя не по-человечески.
  

1. Массивно-параллельная архитектура (англ. massive parallel processing, MPP)

2. Колоночное хранение (англ. columnar store)

Без долгих вступлений, сразу к делу.

Знаете ли вы, что в Snowflake можно создавать объекты с пустыми именами? Например: CREATE DATABASE ""; CREATE SCHEMA ""."";

Это работает на момент публикации и потенциально создаёт массу проблем для внешних систем, которые не ожидают такого поворота. Также это обычно приводит в восторг админов DWH.

Более интересные и практичные советы под катом.

Apache Spark – фреймворк для обработки больших данных, который давно уже стал одним из самых популярных и часто встречаемых во всевозможных проектах, связанных с Big Data. Он удачно сочетает в себе скорость работы и простоту выражения своих мыслей разработчиком.

Разработчик работает с данными на достаточно высоком уровне и, кажется, что нет ничего сложного в том, чтобы, например, соединить два набора данных, написав всего одну строку кода. Но только задумайтесь: что происходит в кластере при соединении двух наборов данных, которые могут и не находится целиком на каком-либо из узлов кластера? Обычно Spark со всем справляется быстро, но иногда, а особенно, если данных действительно много, необходимо все-таки понимать – что происходит уровнем ниже и использовать это знание, чтобы помочь Spark работать в полную силу.

Существует большое количество методов для автоматического сбора и обработки больших объемов данных из веб-ресурсов. Однако иногда недоступно извлечение данных с помощью автоматизированного кода, выполняющего GET-запросы с последующим парсингом HTML-кода, и его преобразованием в необходимый формат, также, как и все смежные методы. В таких случаях на помощь может прийти эмулятор действия пользователя («кликер», «бот», «робот»).

Машинное обучение (ML) становится эффективным, когда его модели внедряются в производство. С другой стороны, организации обычно недооценивают сложность и проблемы внедрения машинного обучения в производство, выделяя большую часть своих ресурсов на разработку ML и рассматривая машинное обучение как обычное программное обеспечение.

В итоге программы машинного обучения не приносят результатов, что приводит к потере денег, нерациональному использованию ресурсов, а для преодоления этой проблемы разрабатывается концепция MLOps.

Во многих популярных курсах машинного и глубокого обучения вас научат классифицировать собак и кошек, предсказывать цены на недвижимость, покажут еще десятки задач, в которых машинное обучение, вроде как, отлично работает. Но вам расскажут намного меньше (или вообще ничего) о тех случаях, когда ML-модели не работают так, как ожидалось.

Частой проблемой в машинном обучении является неспособность ML-моделей корректно работать на большем разнообразии примеров, чем те, что встречались при обучении. Здесь идет речь не просто о других примерах (например, тестовых), а о других типах примеров. Например, сеть обучалась на изображениях коровы, в которых чаще всего корова был на фоне травы, а при тестировании требуется корректное распознавание коровы на любом фоне. Почему ML-модели часто не справляются с такой задачей и что с этим делать – мы рассмотрим далее. Работа над этой проблемой важна не только для решения практических задач, но и в целом для дальнейшего развития ИИ.

История Bash Today - сервиса бронирования площадок для мероприятий в Москве и Санкт-Петербурге , основанного в 2015 г.

Серьёзная проблема для сервиса бронирований — прямые платежи от клиентов площадкам по заявкам, пришедшим через маркетплейс. Из-за этого компания лишается своей комиссии. Стандартные инструменты выявления подобных схем, такие как опрос пользователей, сбор обратной связи после мероприятий и так далее, имеют ограниченную эффективность, так как осуществляются случайным образом. Поэтому нашей R&D-команде была поставлена задача повысить эффективность проверок с помощью алгоритмов AI.

Всем привет! Наша команда SberIDP занимается задачей извлечения сущностей и фактов из текстовых данных. В банке исторически обрабатывается большое число неструктурированных документов и автоматизация в этой области позволяет сэкономить много времени и ресурсов, а также улучшить клиентский путь. Например, с помощью предварительной обработки документов мы ускорили выдачу кредитов до 7 минут.

Современные методы, основанные на глубинном обучении, требуют от сотен до тысяч примеров для получения приемлемого качества в задачах NER. Сегодня мы разберем направление Few-Shot, которое позволяет решать данную задачу всего лишь на нескольких примерах, и поделимся результатами наших экспериментов. Мы смогли достичь state-of-the-art результатов на датасете Few-NERD и выложили полученные веса на HuggingFace для всех желающих.

Недавно я с удивлением обнаружил, что, оказывается, толковых туториалов по Oracle Application Express (он же APEX, он же апекс, но не путать с языком apex, который используется в Salesforce) в природе не существует.

Это не самая распространенная технология, конечно, но, тем не менее, довольно востребованная. Есть десятки блогов об апексе (англоязычные, в основном), пара тысяч вопросов на Stackoveflow, специальный раздел по апексу на официальных форумах оракла, сам апекс существует уже 15 лет и все время развивается. Я был уверен, что и хороших туториалов полно. Но нет!

Мне тут же пришла в голову гениальная мысль восполнить этот пробел.

Оглавление

Почему существующие туториалы — плохие
Вводная информация
Обзор IDE
    App builder
        Страница приложения
        Application properties
        Shared Components
        Page Designer
    SQL Workshop
        Object Browser
        SQL Commands