В нашей постоянно развивающейся индустрии данных, выбор правильного инструмента может существенно повлиять на эффективность и гибкость работы. Мы недавно перешли с Dremio на Trino. Решение об этом шаге было принято после анализа и испытаний, и в этой статье я расскажу о причинах этого перехода, особенностях каждого продукта, а также о том, как это повлияет на нашу работу в рамках концепции Data Mesh.

Московский художник Даниил Кудряшов https://kudryashovdd.com/allartworks

Московский художник Даниил Кудряшов https://kudryashovdd.com/allartworks

Dremio и Trino: Основные Отличия

Dremio позиционируется как коробочный продукт, который предоставляет целый набор инструментов “из коробки”. Эта платформа позволяет пользователям выполнять аналитические запросы на больших наборах данных с использованием своего движка SQL. По своей природе Dremio старается исполнять запросы внутри себя, что зачастую приводит к необходимости выгрузки значительных объёмов данных из источника, прежде чем приступать к анализу. Это, в свою очередь, увеличивает время ожидания для пользователей и потребляет дополнительные ресурсы.

Dremio имеет свои плюсы и минусы:

Плюсы:

• Лёгкость в использовании и интеграции.
• Поддержка современных форматов данных.
• Концепция data-as-code.

Минусы:

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

И конечно отсутствие обновлений, поддержки, что фактически является тупиком в развитии для нас.

Trino

Trino, ранее известный как PrestoSQL, представляет собой SQL-движок, который отлично подходит для платформ данных, требующих высокой степени кастомизации. В отличие от Dremio, Trino выполняет запросы ровно так, как это указано в SQL, что позволяет избежать излишних выгрузок данных и оптимизировать процесс обработки запросов. Благодаря своей открытой архитектуре, Trino предоставляет гибкость в настройках и кастомизации, что является ключевым преимуществом. Trino хорошо интегрируется с такими технологиями как Iceberg и Data Build Tool, kafka и многими другими, что обеспечивает более эффективное управление данными и их структурой. Позволяет нам выполнять запросы к данным в топиках Kafka, что особенно востребовано в текущий момент, а также легко добавлять новые типы коннекторов, Dremio так не умеет.

Плюсы:

• Открытая архитектура и возможность кастомизации.
• Высокая производительность и эффективность.
• Поддержка современных форматов данных и подключений.
• Развитое сообщество и документация.

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

Минусы:

• Необходимость дополнительных настроек и конфигураций.
• Потребность в более глубоком техническом знании.

Причины Перехода

Гибкость и Настраиваемость

Одной из основных причин перехода с Dremio на Trino является гибкость и настраиваемость последнего. Trino позволяет легко адаптировать платформу данных под любые потребности, что особенно важно в рамках нашей концепции Data Mesh. Это значительно упрощает управление данными и позволяет экономить ресурсы, разделяя хранение данных от вычислительных мощностей.

Открытая Архитектура и Сообщество

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

Экономия Ресурсов

Trino требует меньших затрат на исполнение запросов, что уменьшает нагрузку на инфраструктуру и сокращает расходы. Пользователи могут обращаться с данными на любом хранении, будь то Oracle или файлы CSV, благодаря единому SQL-интерфейсу.

Безопасность и Управление

Хотя Dremio предлагал платные функции безопасности, бесплатная версия не могла удовлетворить наши требования. Trino, напротив, предлагает широкий спектр настроек безопасности, а также возможность интеграции с различными инструментами управления данными.

Поддержка и Документация

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

Влияние на Платформу

Переход на Trino позволит нам лучше следовать Data Mesh и основным принципым, а именно:

• Видимость: данные станут более доступными и легко находимыми для пользователей.
• Доступность: пользователи смогут быстро извлекать данные из различных систем и форматов.
• Понимание: наличие описаний данных поможет лучше понимать контекст и содержание.
• Связность: пользователи смогут легко использовать дополнительные атрибуты благодаря связям в данных.
• Доверие: уверенность в качестве данных будет повышена.
• Совместимость: общие представления о данных у производителей и потребителей.
• Безопасность: данные будут защищены от несанкционированного доступа и манипуляций.

Что такое Data Mesh?

Заключение

Переход с Dremio на Trino – это важный шаг на пути к улучшению нашей платформы данных. Мы уверены, что гибкость, высокая производительность и открытая архитектура Trino помогут нам достигнуть новых высот в управлении и анализе данных. Следите за новостями и присоединяйтесь к обсуждению в нашем чате поддержки!

Всем хороших выходных! Напишите в комментариях, как вам запомнился Dremio, и что вы пожелаете новому ядру на базе Trino.

Калининград, выезд БИТа

Любопытный сервис, типа гугл доков, но web3

https://beta.fileverse.io/files/485d127c-29e8-4d1b-ad1f-917318f696e0

https://fileverse.io/

Большая книга про глубокое обучение и много чего еще:
Оригинал: https://udlbook.github.io/udlbook/

@book{prince2023understanding,
author = “Simon J.D. Prince”,
title = “Understanding Deep Learning”,
publisher = “The MIT Press”,
year = 2023,
url = “http://udlbook.com”

Сама книга на сайте или тут: http://a.gavrilov.info/data/posts/UnderstandingDeepLearning_07_02_24_C.pdf

⚡️ Встречайте Kolors — диффузионная модель для генерации изображений с упором на фотореализм

Kolors — это большая диффузионная модель, опубликованная вчера командой Kuaishou Kolors.

Kolors была обучена на миллиардах пар “текст-изображение” и показывает отличные результаты в генерации сложных фотореалистичных изображений.

По результатам оценки 50 независимых экспертов, модель Kolors генерирует более реалистчиные и красивые изображения, чем Midjourney-v6, Stable Diffusion 3, DALL-E 3 и другие модели

🟡 Страничка Kolors https://kwai-kolors.github.io/post/post-2/
🟡 Попробовать https://huggingface.co/spaces/gokaygokay/Kolors
🖥 GitHub https://github.com/Kwai-Kolors/Kolors

@ai_machinelearning_big_data

Важные новости! 😎

На днях мы поделились информацией о том, что:
Специалисты нашего сообщества активно работают над новой версией OpenScaler на базе openEuler 24.03 LTS. Скоро анонсируем. Следите за новостями!

Обещание выполнено!

Представляем обновленную версию дистрибутива OpenScaler 24.03 LTS!

Ключевые нововведения:
🌟 Улучшенное ядро Linux 6
🌟 Интеллектуальное планирование и настройка с помощью алгоритмов ИИ
🌟 Расширенные возможности на различных платформах для повышения производительности и надежности приложений и многое другое.

📤 Установочные образы OpenScaler 24.03 LTS доступны для архитектур Arm и x86.

Подробнее о релизе дистрибутива OpenScaler 24.03 LTS читайте в нашем анонсе. https://openscaler.ru/2024/07/04/openscaler-23-03-release/

Хотите протестировать новую версию дистрибутива? OpenScaler 24.03 LTS уже доступен дня скачивания на официальном сайте сообщества в разделе “Загрузки”!
https://openscaler.ru/downloads/

Будем рады ответить на ваши вопросы. Загляните к нам на форум 😉
https://openscaler.ru/forum/

🖥 Woodpecker — мощный расширяемый движок CI/CD

Woodpecker ориентирован на создание конвейеров внутри контейнеров Docker

— Woodpecker полностью open-source

— Woodpecker использует контейнеры Docker; если возможностей обычного Docker-образа не хватит, можно создать плагины для расширения возможностей

— Woodpecker позволяет легко создавать несколько рабочих процессов и они могут даже зависеть друг от друга

🖥 GitHub https://github.com/woodpecker-ci/woodpecker
🟡 Доки https://woodpecker-ci.org/docs/usage/intro

Docker

🌟 Lance — современный колоночный формат данных для ML-приложений, реализованный на Rust

— pip install pylance

Lance идеально подходит для создания поисковых систем и хранилищ данных, для масштабного обучения ML-моделей, для хранения таких данных как облака точек.
Поддерживает конвертацию из Parquet в 2 строки кода, при этом он быстрее Parquet в 100 раз.
Lance можно без проблем использовать с pandas, DuckDB, Polars, pyarrow и не только.

🖥 GitHub https://github.com/lancedb/lance
🟡 Примеры использования https://lancedb.github.io/lance/examples/examples.html

@data_analysis_ml

Оригинал: https://quickwit.io/blog/quickwit-binance-story

Три года назад мы открыли исходный код Quickwit, распределенного поискового движка для работы с большими объемами данных. Наша цель была амбициозной: создать новый тип полнотекстового поискового движка, который был бы в десять раз более экономичным, чем Elasticsearch, значительно проще в настройке и управлении, и способным масштабироваться до петабайт данных.

Хотя мы знали потенциал Quickwit, наши тесты обычно не превышали 100 ТБ данных и 1 ГБ/с скорости индексации. У нас не было реальных наборов данных и вычислительных ресурсов для тестирования Quickwit в масштабе нескольких петабайт.

Это изменилось шесть месяцев назад, когда два инженера из Binance, ведущей криптовалютной биржи, обнаружили Quickwit и начали экспериментировать с ним. В течение нескольких месяцев они достигли того, о чем мы только мечтали: они успешно перенесли несколько кластеров Elasticsearch объемом в петабайты на Quickwit, достигнув при этом следующих результатов:

• Масштабирование индексации до 1,6 ПБ в день.
• Операция поискового кластера, обрабатывающего 100 ПБ логов.
• Экономия миллионов долларов ежегодно за счет сокращения затрат на вычисления на 80% и затрат на хранение в 20 раз (при том же периоде хранения).
• Значительное увеличение возможностей хранения данных.
• Упрощение управления и эксплуатации кластера благодаря хорошо спроектированной многокластерной установке.

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

Вызов Binance

Как ведущая криптовалютная биржа, Binance обрабатывает огромное количество транзакций, каждая из которых генерирует логи, важные для безопасности, соответствия и оперативных аналитических данных. Это приводит к обработке примерно 21 миллиона строк логов в секунду, что эквивалентно 18,5 ГБ/с или 1,6 ПБ в день.

Для управления таким объемом Binance ранее полагалась на 20 кластеров Elasticsearch. Около 600 модулей Vector извлекали логи из различных тем Kafka и обрабатывали их перед отправкой в Elasticsearch.

Настройка Elasticsearch в Binance

Однако эта установка не удовлетворяла требованиям Binance в нескольких критических областях:

• Операционная сложность: Управление многочисленными кластерами Elasticsearch становилось все более сложным и трудоемким.
• Ограниченное хранение: Binance хранила большинство логов только несколько дней. Их целью было продлить этот срок до месяцев, что требовало хранения и управления 100 ПБ логов, что было чрезвычайно дорого и сложно с их настройкой Elasticsearch.
• Ограниченная надежность: Кластеры Elasticsearch с высокой пропускной способностью были настроены без репликации для ограничения затрат на инфраструктуру, что компрометировало долговечность и доступность.

Команда знала, что им нужно радикальное изменение, чтобы удовлетворить растущие потребности в управлении, хранении и анализе логов.

Почему Quickwit был (почти) идеальным решением

Когда инженеры Binance обнаружили Quickwit, они быстро поняли, что он предлагает несколько ключевых преимуществ по сравнению с их текущей установкой:

• Нативная интеграция с Kafka: Позволяет инжектировать логи непосредственно из Kafka с семантикой “ровно один раз”, что дает огромные операционные преимущества.
• Встроенные преобразования VRL (Vector Remap Language): Поскольку Quickwit поддерживает VRL, нет необходимости в сотнях модулей Vector для обработки преобразований логов.
• Объектное хранилище в качестве основного хранилища: Все проиндексированные данные остаются в объектном хранилище, устраняя необходимость в предоставлении и управлении хранилищем на стороне кластера.
• Лучшее сжатие данных: Quickwit обычно достигает в 2 раза лучшего сжатия, чем Elasticsearch, что еще больше сокращает занимаемое место индексами.

Однако ни один пользователь не масштабировал Quickwit до нескольких петабайт, и любой инженер знает, что масштабирование системы в 10 или 100 раз может выявить неожиданные проблемы. Это не остановило их, и они были готовы принять вызов!

Поиск в 100 ПБ, вызов принят

Масштабирование индексации на 1,6 ПБ в день

Binance быстро масштабировала свою индексацию благодаря источнику данных Kafka. Через месяц после начала пилотного проекта Quickwit они индексировали на нескольких ГБ/с.

Этот быстрый прогресс был в значительной степени обусловлен тем, как Quickwit работает с Kafka: Quickwit использует группы потребителей Kafka для распределения нагрузки между несколькими модулями. Каждый модуль индексирует подмножество партиций Kafka и обновляет метахранилище с последними смещениями, обеспечивая семантику “ровно один раз”. Эта установка делает индексаторы Quickwit безсостоятельными: вы можете полностью разобрать свой кластер и перезапустить его, и индексаторы возобновят работу с того места, где они остановились, как будто ничего не произошло.

Однако масштаб Binance выявил две основные проблемы:

• Проблемы со стабильностью кластера: Несколько месяцев назад протокол переговоров Quickwit (называемый Chitchat) с трудом справлялся с сотнями модулей: некоторые индексаторы покидали кластер и возвращались, делая пропускную способность индексации нестабильной.
• Неоднородное распределение нагрузки: Binance использует несколько индексов Quickwit для своих логов, с различной пропускной способностью индексации. Некоторые имеют высокую пропускную способность в несколько ГБ/с, другие – всего несколько МБ/с. Алгоритм размещения Quickwit не распределяет нагрузку равномерно. Это известная проблема, и мы будем работать над этим позже в этом году.

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

Настройка Quickwit в Binance

После нескольких месяцев миграции и оптимизации Binance наконец достигла пропускной способности индексации в 1,6 ПБ с 10 кластерами индексации Quickwit, 700 модулями, запрашивающими около 4000 vCPU и 6 ТБ памяти, что в среднем составляет 6,6 МБ/с на vCPU. На заданной теме Kafka с высокой пропускной способностью этот показатель увеличивается до 11 МБ/с на vCPU.

Следующий вызов: масштабирование поиска!

Один поисковый кластер для 100 ПБ логов

С Quickwit, способным эффективно индексировать 1,6 ПБ ежедневно, вызов сместился к поиску по петабайтам логов. С 10 кластерами Binance обычно потребовалось бы развернуть модули поиска для каждого кластера, что подрывало одно из преимуществ Quickwit: объединение ресурсов поиска для доступа к общему объектному хранилищу всех индексов.

Чтобы избежать этой ловушки, инженеры Binance придумали умный обходной путь: они создали унифицированное метахранилище, реплицируя все метаданные из метахранилища каждого кластера индексации в одну базу данных PostgreSQL. Это унифицированное метахранилище позволяет развернуть один единственный централизованный поисковый кластер, способный искать по всем индексам!

Многокластерная установка Quickwit

На данный момент Binance управляет разумно размером кластером из 30 модулей поиска, каждый из которых запрашивает 40 vCPU и 100 ГБ памяти. Чтобы дать вам представление, вам нужно всего 5 поисковиков (8 vCPU, 6 ГБ запросов памяти) для нахождения иголки в стоге сена в 400 ТБ логов. Binance выполняет такие запросы на петабайтах, а также запросы агрегации, отсюда и более высокие запросы ресурсов.

Заключение

В целом, миграция Binance на Quickwit была огромным успехом и принесла несколько существенных преимуществ:

• Сокращение вычислительных ресурсов на 80% по сравнению с Elasticsearch.
• Затраты на хранение сократились в 20 раз при том же периоде хранения.
• Экономически жизнеспособное решение для управления большими объемами логов, как с точки зрения затрат на инфраструктуру, так и эксплуатации.
• Минимальная настройка конфигурации, эффективно работающая после определения правильного количества модулей и ресурсов.
• Увеличение хранения логов до одного или нескольких месяцев в зависимости от типа лога, улучшение возможностей внутренней диагностики.

В заключение, миграция Binance с Elasticsearch на Quickwit была захватывающим шестимесячным опытом между инженерами Binance и Quickwit, и мы очень гордимся этим сотрудничеством. Мы уже запланировали улучшения в сжатии данных, поддержке многокластерных систем и лучшем распределении нагрузки с источниками данных Kafka.

Большое спасибо инженерам Binance за их работу и идеи в ходе этой миграции <3

Как насчет 6000 процессоров на одной карте pcie?

Суперкомпьютер на кристалле вступает в строй: одна PCIe-карта содержит более 6000 ядер RISC-V с возможностью масштабирования до более чем 360 000 ядер, но стартап до сих пор не раскрывает информацию о ценах.

https://www.techradar.com/pro/supercomputer-on-a-chip-goes-live-single-pcie-card-packs-more-than-6000-risc-v-cores-with-the-ability-to-scale-to-more-than-360000-cores-but-startup-still-remains-elusive-on-pricing

InspireSemi объявила об успешном завершении дизайна и передаче в производство компании TSMC ускорителя вычислений Thunderbird I. Этот высокодифференцированный “суперкомпьютерный кластер на кристалле” оснащен 1536 пользовательскими 64-битными ядрами RISC-V CPU, специально разработанными для высокоуровневых научных вычислений и обработки сложных данных.

Thunderbird I предназначен для широкого спектра вычислительно-емких приложений, от искусственного интеллекта и машинного обучения до графовой аналитики. Используя открытый стандарт RISC-V CPU ISA, он позволяет упростить разработку и интеграцию в существующие технологические фреймворки, предоставляя доступ к надежной экосистеме программного обеспечения, библиотек и инструментов.

Планируется выпуск PCIe-карты. Архитектура чипа включает высокоскоростную mesh-сеть, которая обеспечивает значительную пропускную способность и минимальную задержку при коммуникации между ядрами, что важно для приложений, полагающихся на синхронизированные операции в нескольких потоках. Эта эффективная сетевая интеграция управляет взаимодействиями внутри массива ядер чипа и систем памяти, обеспечивая оптимальную производительность без распространенных узких мест. Предстоящий выпуск продукта будет включать серверную PCIe-карту, на которой размещены четыре чипа Thunderbird, предоставляя более 6000 взаимосвязанных 64-битных ядер CPU. Эта конфигурация оснащена для обработки двойной точности, необходимой для многих высокопроизводительных вычислительных приложений в таких областях, как климатология, медицинские исследования и сложные симуляции. Рон Ван Делл, генеральный директор InspireSemi, сказал: «Мы гордимся достижением нашей инженерной и операционной команды в завершении дизайна Thunderbird I и отправке его нашим партнерам по производству мирового класса, TSMC, ASE и imec, для производства. Мы ожидаем начать поставки клиентам в четвертом квартале».

Однако пока нет информации о цене. InspireSemi также подчеркивает энергоэффективность Thunderbird I, что перенято из его первоначальной разработки для энергочувствительных блокчейн-приложений. Компания заявляет, что этот подход предлагает более экологичную альтернативу традиционным GPU для дата-центров.