User
WITH w AS NOT MATERIALIZED (
SELECT *
FROM very_very_big_table
)
SELECT *
FROM w AS w1
JOIN w AS w2
ON w1.key = w2.ref
WHERE w2.key = 123;Сегодня в репозиторий PostgreSQL упал комит, позволяющий управлять поведением обработки подзапросов CTE, а именно: теперь можно явно указывать, будет ли подзапрос материализовываться отдельно или же выполняться как часть одного большого запроса.
Это войдет в PostgreSQL 12, и это big deal. Давайте рассмотрим, почему
Так получилось, что я провожу довольно много собеседований на должность веб-программиста. Один из обязательных вопросов, который я задаю — это чем отличается INNER JOIN от LEFT JOIN.
Чаще всего ответ примерно такой: "inner join — это как бы пересечение множеств, т.е. остается только то, что есть в обеих таблицах, а left join — это когда левая таблица остается без изменений, а от правой добавляется пересечение множеств. Для всех остальных строк добавляется null". Еще, бывает, рисуют пересекающиеся круги.
Я так устал от этих ответов с пересечениями множеств и кругов, что даже перестал поправлять людей.
Дело в том, что этот ответ в общем случае неверен. Ну или, как минимум, не точен.
Многие из вас читали предыдущую статью про то, как неправильная визуализация для объяснения работы JOIN-ов в некоторых случаях может запутать. Круги Венна не могут полноценно проиллюстрировать некоторые моменты, например, если значения в таблице повторяются.
При подготовке к записи шестого выпуска подкаста "Цинковый прод" (где мы договорились обсудить статью) кажется удалось нащупать один интересный вариант визуализации. Кроме того, в комментариях к изначальной статье тоже предлагали похожий вариант.
Все желающие приглашаются под кат
В этой статье мы рассказываем об основах и применении одного из самых мощных законов статистики - теоремы Байеса.
Мы продемонстрируем применение правила Байеса на очень простом, но практичном примере тестирования на наркотики и реализуем расчеты на языке програмирования Python. Мы также проиллюстрируем, как ограничения теста влияют на прогнозируемую вероятность и что в тесте необходимо улучшить, чтобы получить результат с высокой степенью достоверности.
Мы также покажем истинную силу байесовских рассуждений и как несколько байесовских вычислений можно объединить в цепочку, чтобы вычислить общую апостериорную вероятность.
Полное руководство по созданию DAG в Apache Airflow DAG, позволяющих создать конвейер данных из разных источников, запускаемый в определенные периоды времени с заданной логикой. Первая часть. Источник: DAGs: The Definitive Guide от astronomer.io
Добро пожаловать в полное руководство по Apache Airflow DAG, представленное командой Astronomer. Эта электронная книга охватывает все, что вам нужно знать для работы с DAG, от строительных блоков, из которых они состоят, до рекомендаций по их написанию, динамической генерации, тестированию, отладке и многому другому. Это руководство, написанное практикующими для практикующих.
Все об использовании шаблонов в Airflow с примерами кода. Продолжение серии публикаций astronomer.io
Настоятельно рекомендую к прочтению книги от ребят из Intercom, которые подойдут для продактов любого уровня: Intercom On Starting Up и Intercom on Оnboarding. Книги хорошо описывают как процесс разработки онлайн-продуктов, так и дальнейший процесс работы с его пользователями и трафиком. Ну и не могу не посоветовать своё собственное пособие для всех начинающих продактов «Продукт-менеджемент: от идеи до продукта».
Всем привет! Меня зовут Валерия Дымбицкая, я технический руководитель команды дата-инженеров в OneFactor. В этой статье я расскажу о том, как мы научились автоматически подбирать параметры для Spark-приложений на основе логов.
Проблема, которую мы решали, может встретиться при регулярном, предсказуемом, интенсивном использовании Hadoop-кластера. Я расскажу, как мы простыми средствами сделали рабочую автономную систему тюнинга, сэкономив в итоге 15-16% ресурсов кластера. Вас ждут детали с примерами кода.
В первой половине статьи я расскажу про то, какая перед нами стояла задача, и разберу ключевые пункты для её решения. Во второй половине будет рассказ о том, как это решение подготовить к работе на продуктиве и что мы из этого всего получили.
Зачем нам вообще понадобился автоматический тюнинг?
Начнём с инфраструктуры. Сетап у нас "классический": ограниченный Hadoop-кластер из купленных серверов. В нём на тот момент, когда мы начали всё это делать, было около 30Тб RAM и 5к CPU. В этом кластере запускается множество разноплановых приложений на Apache Spark и в какой-то момент им стало тесновато. Всё больше приложений висели в PENDING значительное время, потребление памяти утроилось за последние 4 месяца. Сохранять такую тенденцию не хотелось.
Довольно много приложений были от продукта Лидогенерация. Базово он устроен так: есть список номеров телефонов (база) и есть Spark ML Pipeline, который каким-то образом отбирает из этой базы лидов абонентов для некоего целевого действия – например, для предложения продукта клиенту. База может меняться от раза к разу. Вот такую пару из
Upd. 11.06.2022 Многие заинтересовались генерацией изображений нейросетями. Вот Colab (интерактивная среда для запуска кода) для рисования картинок в стиле pixel art по текстовому описанию. Просто запускайте, ближе к концу увидете ячейку для ввода текста. Примеры картинок из Colab'а в комментариях.
Два года назад я начал делать небольшой проект, связанный с обработкой текстов на иностранных языках. Он постепенно развивался и стал использоваться лингвистами в НКРЯ, а энтузиасты сохранения малых языков используют его для расширения своих параллельных корпусов.
Сегодня же я расскажу как при помощи него создать полноценную параллельную книгу на разных языках. Книга будет красиво сверстана в PDF, иметь содержание, обложку и две выровненные по смыслу колонки текста. Такие книги служат отличным подспорьем при изучении иностранного языка. Найти их, однако, не так просто, и скорее всего это будут книги для детей или избранная классика. Полный пример готовой книги можно посмотреть здесь. Под капотом у приложения NLP модели, поддерживаемых языков более ста.
Проект открытый и любой может в нем поучаствовать. Во многом благодаря сообществу и вашему участию он за несколько лет дошел до сегодняшнего дня. В общем штука годная, давайте уже посмотрим, что к чему.
Привет! Меня зовут Клоков Алексей, сегодня поговорим о пет-проектах по анализу данных. Идея написать эту статью родилась после многочисленных вопросов о личных проектах в сообществе Open Data Science (ODS). Это третья статья на Хабре, до этого был разбор алгоритма SVM и анонс крутого NLP курса от ребят из DeepPavlov. В этой статье вы найдете идеи для новых петов и другие полезности. Итак, разберем частые вопросы и дадим определение пет-проекта:
По многочисленным просьбам делюсь своим способом сделать недорогую стационарную высоконапорную систему увлажнения воздуха. Ниже будет описана конкретная система, работающая в моей квартире с 2016 года, с фотографиями и подробностями. Похожим образом по моей рекомендации было сделано ещё с десяток подобных систем разного масштаба.
Большая книга по теории, большая книга не только по теории, подкасты и Стэнфордский курс — под катом 6 рекомендаций для изучения от наших Data Scientist'ов Лаборатории машинного обучения.
Я немного преувеличил с количеством — часто я был «вторым пилотом» на собеседованиях. Но какой-то опыт проведения собеседований у меня всё- таки есть, ведь только за 3 месяца весны я провел 150 собесов. В статье я выделил некоторые важные моменты от которых зависит — скажу я кандидату «Да» или «Нет», и собрал очень субъективные рекомендации как проходить собесы. Но учитывая то, какое количество людей через меня прошло, статья будет полезна тем, кто только начал проводить собеседования, кому это только предстоит, и тем, у кого впереди поиск работы.
