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

Вышедшая чуть больше месяца назад ChatGPT уже успела нашуметь: школьникам в Нью-Йорке запрещают использовать нейросеть в качестве помощника, её же ответы теперь не принимаются на StackOverflow, а Microsoft планирует интеграцию в поисковик Bing - чем, кстати, безумно обеспокоен СЕО Alphabet (Google) Сундар Пичаи. Настолько обеспокоен, что в своём письме-обращении к сотрудникам объявляет "Code Red" ситуацию. В то же время Сэм Альтман, CEO OpenAI - компании, разработавшей эту модель - заявляет, что полагаться на ответы ChatGPT пока не стоит.

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

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

Привет! Меня зовут Илья Макаров, я работаю архитектором решений и в статье расскажу про архитектуру цифровой платформы НЛМК, из каких компонент, помимо Apache Kafka, она состоит, к каким соглашениям по именованию топиков и договоренностям по передаче данных мы пришли, как всем этим управляем.

А это сразу ссылка на часть 2.

Зачем менять ZooKeeper на встроенный лог Apache Kafka® для управления метаданными? В этой статье вы узнаете, зачем нужна была эта замена, какие преимущества даёт протокол консенсуса на основе кворума, вроде Raft, и как работает контроллер кворума поверх протоколов KRaft.

Привет, Хабр! Меня зовут Евгений Ненахов, я работаю в центре Big Data МТС Digital. В этой статье я расскажу о том, как мы создали универсальный инструмент потоковой обработки данных и построили с его помощью мощную систему стриминга. Если вам интересна обработка данных – добро пожаловать под кат!

Разрабатываете приложения с применением Apache Kafka? Мы собрали для вас статьи, которые помогут освоить инструмент, познакомят с рабочими кейсами с использованием ПО. Делимся пользой и свежими идеями, подборками книг и реализованными задумками.

Очень часто приходится слышать, что Sqoop — это серебряная пуля для загрузки данных большого объёма с реляционных БД в Hadoop, особенно с Oracle, и Spark-ом невозможно достигнуть такой производительности. При этом приводят аргументы, что sqoop — это инструмент, заточенный под загрузку, а Spark предназначен для обработки данных.

Меня зовут Максим Петров, я руководитель департамента "Чаптер инженеров данных и разработчиков", и я решил написать инструкцию о том, как правильно и быстро загружать данные Spark, основываясь на принципах загрузки Sqoop.

Первичное сравнение технологий

В нашем примере будем рассматривать загрузку данных из таблиц OracleDB.

Рассмотрим случай, когда нам необходимо полностью перегрузить таблицу/партицию на кластер Hadoop c созданием метаданных hive.

Данная статья обобщает базовые шаги по установке и началу работы с PySpark Structured Streaming при участии брокера сообщений Kafka. Предполагается, что читатель уже знаком с языком программирования Python и сервисом Kafka.

При помощи PySpark Structured Streaming можно быстро разрабатывать масштабируемые сервисы обработки данных в реальном времени. Такой подход позволяет в короткие сроки сделать выгодное предложение клиенту, вовремя заметить аномалию в системе или же отображать актуальные данные.

По материалам статьи Craig Freedman: Summary of Join Properties

Следующая таблица суммирует характеристики трех операторов соединения, которые были описаны в моих трех предшествующих статьях.

Проблема пакетной загрузки данных в HBase и способы решения

Статья посвящена проблеме быстрой загрузки большого объема данных в HBase, когда стандартные методы вставки в таблицу не дают должной производительности. Опытом в ее решении и возникших в процессе трудностях и хотелось бы поделиться в рамках данной статьи.

По материалам статьи из блога Craig Freedman: Parallel Nested Loops Join

SQL Server распараллеливает соединение вложенных циклов (Nested Loops Join), распределяя в случайном порядке строки внешней таблицы по потокам вложенных циклов. В данном случае, речь идёт о строках, которые поступают первыми, и мы их видим вверху, на графическом плане запроса. Например, если на входе соединения вложенных циклов имеется два потока, каждый поток получит приблизительно половину строк. Потоки проходятся по строкам внутренней таблицы соединения (то есть, по строкам, поданным во вторую очередь, мы их видим ниже в плане запроса), точно по такому же алгоритму, как это было бы реализовано в сценарии с последовательной обработкой строк. Таким образом, для каждой обрабатываемой потоком строки внешней таблицы, поток обеспечивает соединение своей внутренней таблицы, используя эту строку в качестве источника коррелированных параметров. Это позволяет потокам работать независимо друг от друга. При этом для внутренней таблицы соединения вложенных циклов SQL Server не добавляет операторы параллелизма и работу с ней не распараллеливает.

Перевод Ирины Наумовой

_{Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp}

По материалам статьи: «Resolving PAGELATCH Contention on Highly Concurrent INSERT Workloads».

Авторы: Thomas Kejser, Lindsey Allen, Arvind Rao и Michael Thomassy

Недавно, мы проводили лабораторные испытания в Microsoft Enterprise Engineering Center, при которых использовалась большая рабочая нагрузка, характерная для OLTP систем. Целью этой лабораторной работы было определить, что случится при увеличении числа процессоров с 64 до 128, при обслуживании Microsoft SQL Server интенсивной рабочей нагрузки (примечание: эта конфигурация была ориентирована на релиз Microsoft SQL Server 2008 R2). Рабочая нагрузка представляла собой хорошо распараллеленные операции вставки, направляемые в несколько больших таблиц.

Рабочая нагрузка масштабировалась до 128 процессорных ядер, но в статистике ожиданий было очень много кратких блокировок PAGELATCH_UP и PAGELATCH_EX. Средняя продолжительность ожидания была десятки миллисекунд, и таких ожиданий было очень много. Такое их количество оказалось для нас неожиданностью, ожидалось, что продолжительность не будет превышать несколько миллисекунд.

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

Всем привет.

Мы продолжаем цикл публикаций о том, как наша BI-платформа «Форсайт» работает с данными. В этой статье мы бы хотели поговорить о том, как выйти за рамки привычного online analytical processing (OLAP) и с помощью enterprise BI погрузиться в проблематику «Fixed format reporting». Какие средства и возможности дает BI-платформа для 100% точного воспроизведения шаблона официальной отчётности? Как это можно сделать с помощью трансформации и виртуализации данных многомерных ROLAP-кубов? Расскажем о том, как в платформе «Форсайт» на уровне бизнес-логики и семантического слоя можно выполнить аналоги реляционных операций view, join, group by и т.п. Итак, за всеми этими подробностями добро пожаловать под кат!

В FunBox мы делаем продукты для мобильных операторов: различные порталы, геосервисы, платежи, мобильную рекламу и многое другое.  Один из наших проектов построен на микросервисной архитектуре. Основная функциональность связана с обработкой потоков событий, поэтому мы выбрали событийно-ориентированную архитектуру. Для организации централизованного, масштабируемого и быстрого механизма обмена сообщениями используем Apache Kafka. Это популярная платформа для решения подобных задач, плюс у неё есть интерфейс для организации потоковой обработки событий.

Привет, меня зовут Алексей Белявцев и я ETL-архитектор в X5 Group. Наши объёмы данных соизмеримы с крупнейшими международными компаниями и требуют специального ухода и содержания, что накладывает определённый отпечаток на специфику используемых решений. Я не планирую грузить вас описанием детальной архитектуры (всё равно её нельзя публиковать), скриптами загрузки (их тем более) и другими скучными подробностями технической реализации, которые в достатке присутствуют во всех data-driven компаниях, а хочу заглянуть в будущее и попытаться представить архитектуру, удовлетворяющую всем потенциально возможным требованиям, масштабируемую, отказоустойчивую и просто приятную во всех отношениях.

Речь пойдёт о практиках сборки данных (подготовка снастей и поиск водохранилища), а также о нахождении оптимальной точки раздачи данных (лунке в зимний сезон или просто удачного места в рогозе) в реалиях очень big data, сотен систем-источников (СИ) и петабайтах данных (примерно как порыбачить в океане). Цель изложения заключается в консолидации и структурировании информации по теме и размышлениях об идеализированной архитектуре в зависимости от потребностей подразделений компании в данных. Будут высказаны предположения по опережающему развитию архитектуры под новые требования бизнеса третьего десятилетия 21 века, при этом многие из затронутых тем на текущем этапе развития направления являются более чем holywar-ными, причём подходы, успешно использующиеся в одних компаниях, могут быть провальны в других и наоборот (зависит от многих факторов).

Kafka нельзя назвать новым продуктом на рынке ПО. Прошло примерно 10 лет с того времени, как компания разработчик LinkedIn выпустила его в свет. И хотя к тому времени на рынке уже были продукты со схожей функциональностью, но открытый код и широкая поддержка экспертного сообщества прежде всего в лице Apache Incubator позволила ему быстро встать на ноги, а впоследствии составить серьезную конкуренцию альтернативным решениям.

Традиционно Kafka рассматривался как набор сервисов для приема и передачи данных, позволяющий накапливать, хранить и отдавать данные с крайне низкой задержкой и высокой пропускной способностью. Этакий надежный и быстрый (да и в общем-то наиболее популярный на данный момент) брокер сообщений по этой причине весьма востребован во множестве ETL процессов. Преимущества и возможности Kafka многократно обсуждались, в том числе и на Хабре. К тому же, статей на данную тематику весьма много на просторах интернета. Не будем повторять здесь достоинства Kafk-и, достаточно посмотреть на список организаций, выбравших этот продукт  базовым инструментом для технических решений. Обратимся к официальному сайту, согласно которому на данный момент Kafka используется тысячами компаний, в том числе более 60% компаний из списка Fortune 100. Среди них Box, Goldman Sachs, Target, Cisco, Intuit и другие [1].

На сегодняшний день Apache Kafkaне без оснований часто признается лучшим продуктом на рынке систем по передаче данных. Но Kafka не только интересен в качестве брокера сообщений. Огромный интерес он представляет и в силу того, что на его основе возникли и развиваются многие специфические программные продукты, которые позволяют Kafka существенным образом расширить возможности. А это свою очередь позволяет ему уверено продвигаться в новые области ИT рынка.