https://blog.devgenius.io/comparison-of-the-open-source-query-engines-trino-and-starrocks-cf959049f9ab

В этом посте мы хотим сравнить Trino, популярный распределенный движок для выполнения аналитических запросов на больших объемах данных с интерактивными задержками, с StarRocks.
Источники информации

Мы консультировались с участниками StarRocks (Хэнг Чжао, член TSC StarRocks; Дориан Чжэн, активный участник StarRocks). Что касается Trino, мы использовали веб-сайт Trino и поиск в Google для исследования различных тем. Мы сравнили последние версии обоих продуктов на октябрь 2023 года.
Возрождение Trino/Presto

Изначально Presto был задуман и разработан в Facebook (теперь известном как Meta) для того, чтобы позволить их аналитикам выполнять интерактивные запросы в их обширном хранилище данных Apache Hadoop. Проект, возглавляемый Мартином Траверсо, Дэйном Сандстромом, Дэвидом Филлипсом и Эриком Хуангом, начался в 2012 году как решение для преодоления ограничений Apache Hive, который ранее использовался для SQL-аналитики в обширном хранилище данных Facebook, но оказался слишком медленным для обширных потребностей компании. Presto был публично внедрен в Facebook в том же году и позже был представлен в виде open source в ноябре 2013 года.

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

• Мог эффективно обрабатывать большие наборы данных и сложные запросы (по сравнению с другими технологиями, доступными на тот момент).
  a. Конкретно, гораздо быстрее, чем технология MapReduce, такая как Apache Hive, которая тогда была актуальной.
  b. Мог подключаться к множеству различных источников данных: в частности, подключаться к нескольким базам данных одного типа с возможностью объединения наборов данных между базами данных (например, горизонтальное масштабирование экземпляров баз данных).
• Мог масштабироваться для удовлетворения потребностей крупных организаций: Facebook продемонстрировал, что Presto может работать, и другие технологические “единороги” быстро приняли его для своих потребностей в хранилище данных.
• Open Source: кто не хочет, чтобы кто-то другой проводил исследования и разработку программного обеспечения за “бесплатно”?

Проект Presto претерпел значительные изменения за десятилетие. В 2018–2019 годах, после ухода оригинальных основателей из Facebook, проект разделился на две ветки: PrestoDB и PrestoSQL. Это разделение было ответом на изменяющиеся потребности и направление сообщества Presto.
Trino возник из ветви PrestoSQL. В январе 2021 года PrestoSQL был переименован в Trino. Trino сохранил свои корни в обработке данных большого объема, принимая архитектуру Massively Parallel Processing (MPP) и разрабатываясь на Java. Это отличало его от традиционных фреймворков MapReduce, улучшая его способность эффективно обрабатывать и обрабатывать большие объемы данных.

Изменение требований пользователей

С момента появления Trino/Presto они удовлетворительно соответствовали большинству потребностей пользователей в анализе данных на тот момент. Тем не менее стоит отметить, что требования пользователей к анализу данных по-прежнему постоянно меняются и развиваются. Это особенно явно после того, как мир был завоеван мобильным интернетом и приложениями SaaS, с пользовательским анализом и аналитикой в реальном времени, становящимися важными трендами для предприятий.
Основные проявления этого тренда следующие:

• Предприятия надеются иметь более производительные системы запросов для удовлетворения потребности в запросах с низкой задержкой на огромных объемах данных. Ни один пользователь не хочет ждать больше трех секунд перед экраном.
• Предприятия нуждаются в возможности поддерживать сотни, а то и тысячи человек, одновременно проводящих запросы и анализ данных. Постоянно растущее количество пользователей стало толчком для этого спроса.
• Предприятия стремятся к своевременному анализу последних данных и использованию результатов анализа для направления последующей работы.
  В нынешнюю постпандемическую эпоху, как сохранить издержки и улучшить эффективность работы в такой неблагоприятной экономической обстановке? Это еще один вопрос, на который каждое предприятие должно ответить.

Именно из-за этих новых трендов несколько инженеров баз данных начали новый проект базы данных в 2020 году, названный StarRocks, и официально открыли его исходный код в сентябре 2021 года. StarRocks был передан в Linux Foundation в начале 2023 года. Хотя он существует недолго, влияние StarRocks, кажется, стремительно растет. В настоящее время сотни крупных предприятий по всему миру используют StarRocks в производственных средах.

Смотря на сценарии использования, у StarRocks и Trino/Presto есть значительная степень пересечения. Просто говоря, StarRocks более подходит для сценариев, ориентированных на конечного пользователя с низкой задержкой, в то время как Trino/Presto более подходит для аналитических сценариев, включающих извлечение данных из нескольких источников данных одновременно.

Сходства между Trino и StarRocks
У StarRocks и Trino много сходств в технических характеристиках.

Massively Parallel Processing (MPP)
Обе системы используют MPP в качестве своей распределенной среды выполнения. В этой среде запрос разбивается на множество логических и физических блоков выполнения и выполняется одновременно на нескольких узлах. В отличие от шаблона scatter-gather, используемого многими другими продуктами для аналитики данных в их распределенных вычислительных средах, MPP может использовать больше ресурсов для обработки запросов. Из-за этой среды обе системы могут использоваться для работы с петабайтами данных, и сотни крупных компаний уже используют эти системы в своих производственных средах.

Cost-based Optimizer (CBO)
У обеих систем есть Cost-based Optimizer. В запросах с многотабличным объединением, помимо исполнителя запроса, оптимизированные планы выполнения также могут сыграть ключевую роль в улучшении производительности запроса. Благодаря CBO обе системы могут поддерживать различные функции SQL, включая сложные запросы, объединения и агрегации. Как Trino, так и StarRocks успешно прошли тесты TPC-H и более сложного теста TPC-DS.

Pipeline Execution Framework
У обеих систем есть Framework выполнения конвейера. Основная цель Framework выполнения конвейера – улучшение эффективности использования многозадачных ресурсов в запросе на одном компьютере. Его основные функции охватывают три аспекта:

• Снижение стоимости планирования задач для различных вычислительных узлов в запросе.
• Увеличение использования процессора при обработке запросов.
• Автоматическая настройка параллелизма выполнения запросов для полного использования вычислительной мощности многозадачных систем, тем самым повышая производительность запроса.

ANSI SQL Support
Обе системы соответствуют ANSI SQL. Это означает, что аналитики могут использовать язык запросов, с которым они наиболее знакомы в своей повседневной работе, без необходимости дополнительных затрат на обучение. Инструменты бизнес-аналитики, которыми часто пользуются предприятия, также легко интегрируются с StarRocks или Trino.

Различия между Trino и StarRocks
Хотя есть некоторые сходства в технической реализации, мы также видим некоторые явно различные технические характеристики между этими двумя видами систем.

Векторизированный движок запросов

StarRocks – это нативный векторизированный движок, реализованный на C++, в то время как Trino реализован на Java и использует ограниченную технологию векторизации. Технология векторизации помогает StarRocks более эффективно использовать вычислительную мощность ЦП. Этот тип движка запросов обладает следующими характеристиками:

• Полностью использует эффективность управления данными в столбцах. Такой движок запросов читает данные из колоночного хранилища, и способ управления данными в памяти, а также способ обработки операторов данных, является колоночным. Такие движки могут более эффективно использовать кэш ЦП, повышая эффективность выполнения ЦП.
• Полностью использует SIMD-инструкции, поддерживаемые ЦП. Это позволяет ЦП завершать больше вычислений данных за меньшее количество тактовых циклов. Согласно данным, предоставленным StarRocks, использование векторизированных инструкций может улучшить общую производительность в 3-10 раз.
• Более эффективно сжимает данные, что значительно снижает использование памяти. Это делает такой тип движка запросов более способным обрабатывать запросы с большим объемом данных.

Фактически Trino также исследует технологию векторизации. У Trino есть некоторый SIMD-код, но он отстает по сравнению с StarRocks по глубине и охвату. Trino все еще работает над улучшением своих усилий по векторизации (см. https://github.com/trinodb/trino/issues/14237). Проект Velox в Meta направлен на использование технологии векторизации для ускорения запросов Trino. Однако до сих пор очень мало компаний официально использовали Velox в производственных средах.

Материализованный вид

У StarRocks есть несколько функций материализованных видов, которых у Trino нет. Материализованный вид – это продвинутый способ ускорения общих запросов. Как StarRocks, так и Trino поддерживают создание материализованных видов; однако у StarRocks есть возможность:

• Автоматически переписывать запросы для улучшения производительности запроса. Это означает, что StarRocks автоматически выбирает подходящие материализованные виды для ускорения запросов. Пользователям не нужно переписывать свои SQL-запросы, чтобы использовать материализованные виды.
• Выполнять обновление материализованного вида на уровне раздела, что позволяет пользователю добиться лучшей производительности и масштабируемости при снижении потребления ресурсов.
• Возможность записи материализованных видов на локальный диск вместо удаленного диска/хранилища. Это означает, что пользователи могут использовать высокую производительность локального диска. Локальное хранилище использует собственный колоночный формат хранения StarRocks, который лучше поддерживает выполнение векторизированного движка запросов.

У Trino в настоящее время нет этих функций:

• Отсутствие автоматической функции переписывания запросов. Пользователю нужно затратить много времени на переписывание запросов.
• Необходимость выполнять обновление материализованного вида для всей таблицы при изменении данных.
• Невозможность записи материализованных видов на локальный диск.
• Идет обсуждение о том, как улучшить “свежесть” материализованного вида.

Система кэширования

Система кэширования в StarRocks сложнее, чем в Trino. StarRocks реализует кластер-осведомленный кэш данных на каждом узле. Этот кэш использует комбинацию памяти и диска, которую можно использовать для промежуточных и конечных результатов запроса. В результате этого компонента StarRocks имеет возможность кэшировать метаданные Apache Iceberg на локальных дисках для лучшей производительности запросов. StarRocks также поддерживает предварительное заполнение кэша, установку приоритетов кэша и установку черных списков кэша.

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

кэша результатов. В то время как обычный кэш результатов эффективен только для идентичных запросов, кэш запросов также может ускорять запросы, которые не являются точными копиями. Согласно тестам инженеров разработки StarRocks, кэш запросов может улучшить эффективность запроса в 3-17 раз.

Система кэширования Trino работает только на уровне памяти. Это делает ее очень быстрой и предполагает использование более многочисленных и крупных виртуальных машин с памятью. Ведется работа по поддержке кэширования на локальном диске для “горячего кэша”.
Подробнее читайте по ссылкам https://github.com/trinodb/trino/pull/16375 и https://github.com/trinodb/trino/pull/18719.

Производительность соединения

Как Trino, так и StarRocks могут поддерживать сложные операции соединения. Однако StarRocks способен предоставить более высокую производительность. Это происходит потому, что, помимо векторизированного движка запросов, StarRocks также обладает некоторыми специальными техническими возможностями.
Переупорядочивание соединений – это техника, которая может быть использована для улучшения производительности запросов к базе данных, включающих множественные соединения. Она работает путем изменения порядка выполнения соединений.
Стоимость выполнения запроса соединения зависит от размера таблиц, участвующих в соединении, и порядка выполнения соединений. Переупорядочивая соединения, можно найти более эффективный план соединения. Переупорядочивание соединений может выполняться оптимизатором или может быть указано вручную пользователем. Оптимизатор обычно пытается переупорядочить соединения для минимизации стоимости запроса.
Существует несколько различных алгоритмов, которые могут использоваться для переупорядочивания соединений. Некоторые из наиболее распространенных алгоритмов, реализованных в StarRocks, включают:

• Жадный алгоритм: Жадный алгоритм работает путем повторного выбора пары таблиц с наименьшей стоимостью соединения и их объединения.
• Алгоритм динамического программирования: Алгоритм динамического программирования работает построением таблицы, содержащей стоимость соединения каждой пары таблиц. Затем алгоритм использует эту таблицу для поиска оптимального плана соединения.
• Алгоритм исчерпания: Техника выполнения соединений данных, особенно подходящая для больших наборов данных. Он работает разбиением операции соединения на более мелкие, более управляемые задачи, что позволяет выполнять соединения с наборами данных, которые слишком велики для помещения в память.
• Переупорядочивание соединений слева-направо: Эвристический алгоритм, используемый для оптимизации порядка соединений в запросе. Алгоритм начинает с самой маленькой таблицы и затем рекурсивно соединяет ее с следующей по размеру таблицей, пока все таблицы не будут соединены.
• Алгоритм ассоциативности соединения: Техника оптимизации порядка соединений в запросе. Он работает путем использования свойства ассоциативности соединений, которое утверждает, что порядок соединений можно изменить без влияния на результат.
• Алгоритм коммутативности соединения: Техника оптимизации порядка соединений в запросе. Он использует свойство коммутативности соединений, которое утверждает, что порядок операндов соединения можно изменить без влияния на результат.
  В целом StarRocks реализует (по последним данным) на 5 алгоритмов больше, чем Trino.

Еще одной важной особенностью StarRocks для производительности соединения является фильтрация во время выполнения. Фильтрация во время выполнения – это техника, которая может использоваться для улучшения производительности операций соединения данных. Она работает путем фильтрации строк из одной таблицы до их соединения с другой таблицей на основе условия соединения. Это может значительно снизить объем данных, который необходимо обработать, что может привести к значительному улучшению производительности.

Поддержка локальных и глобальных фильтров во время выполнения
Осведомленность о перемешивании
Отправка максимума/минимума, в фильтр в хранилище
Оценка стоимости на основе
Поддержка кэша фильтров во время выполнения
Передача фильтра во время выполнения в обе стороны
SIMD-фильтр Блума
Адаптивный выбор фильтров во время выполнения соединения
Поддержка фильтрации во времени выполнения с несколькими столбцами

Наконец, StarRocks может поддерживать соединение с соседним распределением. Соединение с соседним распределением – это тип соединения, при котором таблицы, участвующие в соединении, хранятся на тех же узлах распределенного кластера базы данных. Это может значительно улучшить производительность операции соединения, поскольку данные не нужно передавать между узлами для обработки.

Высокая доступность

У StarRocks есть два типа узлов, каждый из которых способен достигнуть высокой доступности через конкретные стратегии. Узлы Front End являются безсостоятельными, и высокую доступность можно достичь, развернув нечетное количество узлов Front End. Эти узлы используют протокол Raft для выбора лидера среди себя. Узлы Back End поддерживают механизм с множественными репликами, обеспечивая, что отказ любого узла не влияет на работу системы. Таким образом, StarRocks может выполнять горячие обновления системы. Во время обновления системы онлайн-сервисы системы не будут затронуты.

Trino не имеет встроенной поддержки высокой доступности (HA). Координатор Trino – единственная точка отказа в системе. Если этот узел выходит из строя, вся система становится недоступной. Это означает, что при каждом обновлении системы онлайн-сервисы Trino должны быть приостановлены на определенное время. До сих пор проект Trino не предложил решения этой проблемы. Подробнее читайте по ссылке https://github.com/trinodb/trino/issues/391.

Источники данных и открытые форматы таблиц

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

StarRocks поддерживает чтение как для Apache Iceberg, Apache Hudi, Apache Hive, так и для Delta Lake. Кроме того, StarRocks также поддерживает ограниченные возможности записи в Apache Iceberg. Результаты бенчмарк-тестирования показывают, что StarRocks работает быстрее в качестве движка запросов для озер данных. Trino поддерживает чтение и запись как для Apache Iceberg, Apache Hudi, Apache Hive, так и для Delta Lake. Согласно дорожной карте StarRocks, возможности записи в открытые озера данных будут улучшены в ближайшее время.

Возможности Data Lakehouse StarRocks

Именно благодаря этим уникальным техническим особенностям StarRocks может предоставить пользователям более полный опыт работы с Lakehouse. Использование StarRocks для прямого запроса данных из озер данных позволяет достигнуть производительности, сравнимой с хранилищами данных. Это позволяет строить множество бизнес-приложений напрямую на озерах данных, устраняя необходимость импорта данных в хранилища данных для анализа. Система кэширования StarRocks может использовать локальное хранилище вычислительных узлов для кэширования данных, транспарентно ускоряя производительность запросов. Пользователям не нужно создавать дополнительные конвейеры для управления передачей данных.

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

Совмещая различные уникальные технологии, StarRocks действительно достигает пользовательского и высокопроизводительного опыта с открытым исходным кодом в сфере озер данных.

Бенчмарк

Команда StarRocks провела бенчмарк-тестирование на наборе данных TPC-DS объемом 1 ТБ. Они использовали StarRocks и Trino для запроса одной и той же копии данных, хранящихся в формате таблицы Apache Iceberg с файлами Parquet. Результат заключается в том, что общее время ответа на запрос в Trino медленнее в 5,54 раза по сравнению с StarRocks. Подробнее см. по ссылке https://www.starrocks.io/blog/benchmark-test

Вывод

Trino/Presto — это очень известный движок запросов с открытым исходным кодом. Когда у предприятий есть несколько источников данных и необходимо анализировать данные из этих источников единым образом, Trino является подходящим выбором. По сравнению с Trino, StarRocks — это новый движок запросов с открытым исходным кодом, обладающий множеством инновационных и уникальных решений. Используя StarRocks в качестве движка запросов для озер данных, клиенты могут легко достичь высокопроизводительного опыта запросов. Более того, клиенты могут использовать различные методы для дополнительного ускорения запросов, достигая более низкой задержки и более высокой конкурентоспособности. StarRocks также отличный выбор для запросов к озерам данных.

Перевод сделал ChatGPT

https://medium.com/@ashokgr/data-in-the-future-54e7ed1a6874

Caution: Непреднамеренный заголовок-кликбейт...
Отказ от ответственности: Любое сходство с существующими сценариями/решениями чисто случайно (т.е. преднамеренно, случайно), и этот контент следует читать с ложкой сахара, я имею в виду соли... Прекратите читать, когда не понимаете, и свяжитесь со мной, я постараюсь объяснить, если смогу.

Фото Drew Beamer на Unsplash

Я вернулся после короткого перерыва. Кажется, отпуск (?) был полезным, и я избавился от большей части цинизма, который я нес в своей серии рассказов. Этот контент наполнен фактами с добавлением сарказма (не мой лучший, но вы можете винить в этом мой отпуск).
Введение
Вы когда-нибудь слышали о Гипотезе Гайи? Айзек Азимов предложил свою собственную версию, описывая планету Гайя в своей серии “Фонд”. Я считаю Азимова своим гуру в области современных вычислений. Почему? Потому что он писал о планете, где существует коллективное сознание и память, где последняя информация распределяется среди умов говорящих поселенцев, а более старая информация распределяется среди животных, деревьев/растений, даже воды и камней. Вы можете задать любой вопрос говорящему поселенцу, и он отправит вопрос соответствующим умам и соберет необходимую информацию для ответа. Звучит знакомо? Это Тиринг данных и распределенные вычисления!!! Написано еще в 1980-х годах!!! (Я прочитал эту серию в 2000-х годах.) Разве это не круто? Э? Э? Э? Если вам не кажется, вы можете заняться любовью самим к себе... подождите, Роберт Ладлум написал это в своем романе. В любом случае, вернемся к Азимову.
Примечание: Мне следовало бы прочитать серию “Фонд” снова перед тем, как написать этот контент... надеюсь, что я смогу вспомнить достаточно.
Будущее
Гари Селдон наблюдал за кампусом своего любимого университета Стрилинга через окно своего космического транспорта, на котором он собирался приземлиться. Он только что вернулся после посещения всех 19 поселенческих планет, которые были частью его любимого проекта за последние 30 лет. Он хотел, чтобы эти космические транспорты были быстрее, хотя он путешествовал всего лишь <1 миллисекунду на Warp 10. Такова была его нетерпеливость.
Паря по коридорам университета к своему офису, Гари злился на себя, размышляя, как могли быть такими неточными его расчеты Психоистории?
30 лет назад он выбрал несколько отдаленных планет для проведения своего эксперимента по управлению и процветанию. Его подход был очень прост:
Выбрать благородного министра для руководства делами планеты.
Создать Ресурсный обзорный комитет, который будет оценивать любую новую потребность и план, тщательно рассматривая каждое предложение по добыче и использованию ресурсов планеты.
Очень простые/четкие правила для управления деятельностью министра и комитета обзора.
Единственная цель – процветание граждан планеты путем использования ее ресурсов.
Во время своего последнего визита он заметил, что все вышло из-под контроля, и исполнение плана было в разрухе. Он хотел узнать, что пошло не так с его расчетами Психоистории, которые никогда не ошибались.
Ситуация
15 лет назад Гари посетил все 19 планет и предсказал, что на каждой из них будут свои доли дураков/тупиц и даже предателей. Но он никогда не ожидал, что на планетах будут непросы (должен ли я торговать этим?), то есть граждане с отрицательным прогрессивным взглядом, которые могут свергнуть целые планеты (не регрессивные люди, но прогрессивные во всех неправильных направлениях... О боже, только что я описал пробужденных?). Дураки, предатели и непросы были под влиянием коррумпированных поставщиков открытых технологий, которые продали им змеиное масло (данные – новое змеиное масло?). Это привело к следующему на каждой планете:
Неуправляемая добыча ресурсов планеты и их хранение в огромных океанах ресурсов.
Игнорирование Комитета обзора, а параллельно к нему начал работать тень-параллельный Ресурсный комитет, управляемый беспомощными людьми на основе надежд и ожиданий славы.
Планета тратила в 5–10 раз больше денег, чем требовалось для вероятной будущей готовности, которая так и не реализовалась.
И недавно те же технологические поставщики вернулись с новым змеиным маслом о том, как использовать добываемые ресурсы с новым подходом, который был просто стандартизацией/формализацией дерьмового подхода, уже принятого ранее.
В общем, высокие расходы с нулевой/минимальной ценностью.
Гари должен был докопаться до сути этого!!!

Анализ
Гари держал в руке Прайм Радиант, чтобы проверить, что пошло не так с его расчетами 30 лет назад. Черт побери! Анализ путешествия во времени был возможен только в течение 30 дней по умолчанию (максимум, который, в каком-то смысле, был бы дороже, чем мозги Гари). Гари подумал, давайте пересчитаем расчет, в конце концов, у его Прайм Радиант было 2²⁴ наносерверов с неограниченным объемом ОЗУ. Для этого анализа требовалось стакан 200-летнего виски с планеты Скатч, красивой страны с удивительными замками и акцентом.
Его повторный запуск был инициирован, и он начал размышлять о Райтоне (версия на Расте 1.999.999²⁴ + среда Python версии 1.99²⁴, написанная на Расте) — кто, черт возьми, заставляет разработчиков Райтона писать сложные операции с наборами данных с хэшированием/слиянием/вложенными соединениями? Что не так с этими людьми?

Пока он размышлял о том, стоило ли ему использовать Snowplow вместо этой ерунды, он почувствовал, как наносерверы в его мозгу уносятся вдаль. Черт возьми, опция автомасштабирования его среды Theta Lake + Park врывалась в наносерверы в его мозгу. Он хлебнул виски, чтобы убить несколько клеток мозга и остановить это автомасштабирование. Ему следовало лучше знать, чтобы сбросить конфигурации, и он с облегчением вздохнул, что не выбрал Snowplow, который автомасштабировался бы в 2 раза с каждым запросом до (2⁶⁵⁵³⁶ + 2) наносерверов и поглотил бы все его мозговые клетки за несколько секунд... Фью! Мог бы пропустить этот напиток Скатч, подумал он.

Результаты и завершение
Он был раздражен и решил использовать Психоисторию для расчета и предсказания того, когда будет выпущен новый/эффективный фреймворк обработки данных. В любом случае, он установил опции автомасштабирования на 1–2²⁴ (мин. и макс.), чтобы убедиться, что Прайм Радиант справится со всей нагрузкой. Он понял, что неоднозначные результаты потребуют его секретного запаса. Он пошел в свой шкаф, взял свое любимое виски и обнаружил результаты, которые были беспокойными:

Он использовал неверный алгоритм для корреляции наборов данных. Я – тот чертов Райтон-разработчик, заставленный создавать эти соединения наборов данных, он подумал, может быть, ему не следовало использовать установку Theta-Lake & Park для запуска своих алгоритмов психоистории, с его отвратительной производительностью вставки строки за строкой и новым определением ACID, он размышлял.

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

Он быстро свел результаты в qmail и устроил их с движением глаз: Галактическое Предприятие мертво, Первый Фонд истинен на сегодняшний день.

С правильными алгоритмами на месте, он закончил свой отчет с предсказанием (чертов 2023 год, он будет предсказательным только до тех пор, пока проект Сингулярности не станет реальностью), что Второй и Третий Фонды будут созданы для пошагового успеха, но гораздо лучше.

Хари дал большой глоток своего 10045-летнего Хибики, компилируя qmail. Он был удовлетворен содержанием и опустил голову на стол, закрыл глаза, чтобы отправить qmail с использованием автоматической отправки, чтобы больше не открывать глаза.

Заключение: Никакого. Если вы разобрались в том, что было описано, дай вам пять. Если нет, удачи. Я – энтузиаст по технологиям/данным (нагруженный термин) с опытом около 25 лет в области разработки приложений и архитектуры решений данных. Вы можете связаться со мной по адресу ashokgr@gmail.com в отношении моего контента, и, пожалуйста, учтите – я провожу несколько часов в неделю обсуждая данные с друзьями/связями и буду отвечать, когда это возможно.

Перевод выполнил чат гпт :)

https://medium.com/@jordan_volz/is-it-time-for-composable-data-systems-aaa72e0aa9bd

В 1970 году Эдгар Ф. Кодд опубликовал работу “Реляционная модель данных для крупных общих банков данных” во время работы исследователем в IBM. Эта влиятельная статья стала началом бурного развития систем обработки данных в течение десятилетий, что продолжается и по сей день. Среди тех, кто был вдохновлен этой статьей, были Майкл Стоунбрейкер и Ларри Эллисон, которые немедленно начали реализовывать реляционную модель в системах обработки данных, которые позже стали известными как Oracle и Ingres (позже Postgres — т.е. после Ingres). Фактически любая современная система обработки данных обязана значительной благодарностью работе Кодда.

Одной из характерных черт этих ранних систем было то, что они были монолитами: эти системы были очень тесно интегрированы от верха до низа, обрабатывая все — от пользовательского интерфейса (например, SQL), где пользователи указывают операции для выполнения, до вычисления этих операций и хранения данных. Когда мы рассматриваем контекст, в котором эти системы были созданы, логично, что они были разработаны как монолиты; те, кто создавал системы обработки данных в 1970-х годах, фактически строили их с нуля, поскольку не существовало общего набора инструментов для их создания. Естественно, эти разработчики создавали все сами, что означало, что каждая система хорошо работала внутри себя, но практически не существовало совместимости между системами (даже появление SQL в качестве основного интерфейса для реляционных баз данных заняло некоторое время — что сегодня мы принимаем как должное).

Стонхендж, оригинал монолитов.

Переместимся на три десятилетия после статьи Кодда, и произошли существенные изменения в технологии и обществе. Мы онлайн, web 2.0 в полном разгаре, и данные повсюду. Системы стали крупнее, быстрее и мощнее. Системы управления реляционными базами данных (RDBMS) прошлого уступили место базам данных MPP, затем “большим данным” и распределенным системам. SQL как лингва франка данных уступил место Python и R. Монолитные системы обработки данных также уступили место... еще более монолитным системам обработки данных. Некоторое время мы пытались убедить себя, что “озера данных” — это нечто другое, но роза под другим именем...

Прошло уже пять десятилетий со времени статьи Кодда, но дизайн систем обработки данных сегодня существенно не изменился. Большинство систем обработки данных по-прежнему действуют как монолиты, где разработчики систем по сути многократно воссоздают общие внутренние компоненты. Кроме того, многие системы обработки данных работают по довольно узнаваемым шаблонам — возможно, из-за обратной разработки конкурентов, набора разработчиков из установленных продуктов или создания новой компании/продукта для создания более современной системы с меньшим техническим долгом. Однако то, что не сильно улучшилось, — это взаимодействие между системами, но это не должно вызывать удивление, поскольку почти никогда не в интересах поставщика оперировать таким образом.

За последние два десятилетия выделились два основных тренда в технологии, которые существенно повлияли на мир данных:

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

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

Проблемы с монолитными системами обработки данных
Монолитные системы не являются по своей сути плохими. Позвольте мне честно сказать это. И, конечно же, они лучше, чем отсутствие системы вообще. Создание системы обработки данных не просто и не прямолинейно, поэтому тот, кто сумел это сделать, заслуживает много похвал. Мое основное возражение к монолитным системам — и их более спорному кузену, “силосу данных” — заключается в том, что фундаментальное предположение, на котором все они строятся, просто не верно для современного предприятия: “Все ваши данные находятся в этой системе”.

Пятьдесят лет назад это действительно было верным утверждением. Почти каждая компания только начинала работу с данными, поэтому каждая система данных была более или менее первой системой данных для этой компании, что означало, что это также была система, в которой “все данные”. Сегодня это не соответствует положению дел большинства компаний в их стратегии данных. Обычно у компаний есть несколько уровней устаревших систем, которые устарели, но не выведены из строя. Это могут быть старые продукты, старые приобретения, новые приобретения, операции теневого IT, целый набор заброшенных проектов по искусственному интеллекту и так далее. Данные распределены по множеству различных систем, нет недостатка в языках, написанных для работы с данными (SQL, Python, R, Scala, Java, Julia и т. д.), и все меньше и меньше людей, понимающих, как работают эти старые системы. То, что я все чаще встречаю на практике в современных командах по обработке данных, даже когда ваша система данных работает невероятно хорошо, результаты, которые вы получаете, часто неудовлетворительны, потому что в ней отсутствуют все данные, которые вам нужны на повседневной основе.

Ожидания также были более умеренными в прошлом, чем они сейчас. Пятьдесят лет назад сделать что-либо с данными было победой. Сегодня все намного сложнее, поскольку компании пытаются использовать большие языковые модели (LLM), чтобы создавать приложения с генеративным искусственным интеллектом ко-пилота во всех своих продуктах. Увеличившаяся сложность просто мутит воду и продолжает углублять разрыв между данными и пониманием бизнеса.

Появляется поставщик, предлагающий крутую, современную систему обработки данных. Эта система, безусловно, будет быстрее любых ваших существующих систем, проще в использовании и дешевле! Звучит как удачный случай, не так ли? Ну, на самом деле, нет. Правда в том, что эта система, возможно, будет работать так, как заявлено, только если вы сможете:
а) Мигрировать свои данные в эту систему.
б) Переобучить свою команду обработки данных на использование новой системы.
в) Переписать ваши существующие рабочие нагрузки в новом интерфейсе.

Переоснащение всегда сопряжено с огромными издержками на переключение и представляет собой значительные вложения, как в терминах времени, так и денег. Даже если вы решите взять на себя трудности и выполнить миграцию данных в полностью новую систему обработки данных, вам придется снова столкнуться с таким же выбором не ранее, чем через 5–10 лет.

Грубо говоря, для бизнеса крайне сложно изменить свою стратегию данных. Даже стартапы, которые существуют всего несколько лет, накапливают огромное количество технического долга за короткое время. Успех стартапа лишь означает, что он быстро накапливает большие объемы данных, находясь в условиях нехватки персонала — настоящий рецепт катастрофы. Компании с большим стажем более удачливы, но они просто замедленно двигаются под тяжестью десятилетий технического долга. Бросать еще больше монолитных систем в огонь в 2023 году не может быть решением.

Удивительно, что миграция не решила всех наших проблем. (С любезного разрешения dilbert.com)

Переход в облако также ничего не исправил; теперь мы просто используем монолиты в облаке. В первые дни облако обещало оптимизированные и упрощенные рабочие процессы за счет разделения вычислений и хранения. Это хороший базовый принцип, но в конечном итоге это не прерывает цикл монолитных систем, потому что данные все еще заключены в технологию поставщика для большинства случаев использования. Например, я часто не могу разумно запросить свои данные в платформе X с заданием, выполняемым в платформе Y. Даже если это возможно, мне все равно придется заплатить много штрафов (не говоря уже о более высоких счетах) за попытки разрушить стены и придется смириться с неоптимальной производительностью. Системы не созданы с учетом этого пути в качестве основного, и пользователи платят цену, когда их решения начинают выходить за границы возможного.

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

Для современной организации данных монолитные системы уже не подходят. Так в чем же альтернатива? Композиционные системы обработки данных, построенные на открытых стандартах обработки данных.
Обзор композиционных систем обработки данных
Систему обработки данных можно разбить на 3 основные части:
Хранилище данных: часть, которая хранит данные, доступные пользователям.
Движок данных: часть, которая выполняет операции с данными, как указано пользователями.
Пользовательский интерфейс: часть, с которой взаимодействуют пользователи для инициирования операций. Обычно предоставляется в виде языкового интерфейса или API.
В монолитных системах эти компоненты практически не разделены. Система была построена для использования определенным образом, и потребители системы должны смириться с выбором разработчиков. Используя систему, вы неявно фиксируете свой выбор для хранилища данных, движка данных и пользовательского интерфейса.

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

Представьте себе инженера данных, который пишет рабочий процесс Apache Spark на Java, который считывает данные из внутренней базы данных Oracle и выгружает данные в хранилище S3. Затем ученый по данным создает систему рекомендаций с использованием этих данных на Python и сохраняет результаты в транзакционной базе данных для использования в приложении, предназначенном для конечного пользователя. Для многих компаний сегодня такой рабочий процесс легко мог бы включать три или более систем обработки данных, и интеграция была бы довольно сложной, но в композиционной системе обработки данных это было бы совершенно нормально.

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

1. Модульность: Каждый компонент в системе данных легко может быть заменен другим компонентом того же типа (например, слой хранения).
2. Автономность: Компоненты должны быть разработаны так, чтобы не требовать использования других компонентов.
3. Стандартизированные API: Компоненты должны использовать стандартный набор API для облегчения передвижения данных по системе.
4. Расширяемость: Компоненты должны позволять пользователям легко расширять функциональность, не требуя переписывания всего компонента.

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

Если бы вы начали создавать композиционную систему обработки данных, вы, возможно, обнаружили бы проблему: на самом деле довольно сложно создать ее с нуля. Быстро возникают несколько проблем:

1. При создании движка, как мы вообще можем обрабатывать любой тип пользовательского интерфейса, который пользователи могли бы хотеть использовать? Кажется, что любой новый интерфейс/язык потребует значительной работы по разработке.
2. Точно так же, как мы можем обрабатывать любое произвольное хранилище данных?
3. После того как мы разрушаем систему обработки данных, как мы затем снова соединяем эти разрывы, чтобы предоставить пользователям приятный опыт? Это сложные вопросы, и я считаю, что именно этот пропасть удерживала нас в области монолитных систем обработки данных в последние пятьдесят лет.

Однако композиционные системы обработки данных возможны сегодня благодаря появлению открытых стандартов в этой области, которые могут соединить эти разрывы. Два из них, в частности, предоставляют необходимый клей, который делает эту систему возможной: Apache Arrow и Substrait.

Apache Arrow начался как встроенное столбцовое представление данных, но проект существенно вырос за годы, и с добавлением компонентов, таких как Arrow Flight, Flight SQL и ADBC. Теперь доступно множество инструментов для помощи системам в эффективном общении, и, таким образом, передача данных в формате Arrow никогда не была такой простой. Таким образом, Arrow может очень эффективно действовать как связующее звено между слоем хранения и двигателем в композиционной системе обработки данных при условии:

1. Слой хранения данных поддерживает создание и прием данных в формате Arrow.
2. Двигатель данных может принимать и обрабатывать данные Arrow.

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

Substrait — это кросс-языковая спецификация для операций обработки данных, или так называемое “промежуточное представление” (IR) для реляционной алгебры. Это означает, что вместо управления сетью соединений между интерфейсами и двигателями композиционная система обработки данных должна только указать:

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

Собрав все вместе, мы приходим к нашему первому чертежу для композиционной системы обработки данных:

Теория хороша только в том случае, если ее лучше всего применять, поэтому естественно возникает вопрос “Работает ли это на практике?” Неудивительно, что многие высокотехнологичные компании уже строят композиционные системы обработки данных на основе Apache Arrow и Substrait. Например, в недавней презентации Two Sigma обсуждается использование Arrow и Substrait, вместе с Acero, для создания системы стриминговой фичификации. Meta также недавно открыла код Velox, унифицированного двигателя выполнения, который работает с Substrait и Arrow и, очевидно, может использоваться для начала создания основ композиционной системы. Кроме того, новая база данных DuckDB, пользующаяся популярностью, совпадающим образом поддерживает как Substrait, так и Arrow.

Velox использует открытые стандарты для построения композиционного двигателя обработки данных.
Композиционная система обработки данных варится уже довольно долгое время и теперь, похоже, пришло идеальное время для ее появления. Большинство компаний уже накопили достаточный технический долг, чтобы количество данных необходимых решений, которые могут легко работать с различными слоями хранения. Рост принятия облака подчеркивает разделение вычислений и хранения, что является естественной точкой входа для композиционных систем. Кроме того, появление открытых стандартов, таких как Apache Arrow и Substrait, означает, что создание и использование композиционных систем стало намного проще, чем это было бы всего пять лет назад. Это значительное изменение в архитектуре данных, которое принесет радикальные выгоды для потребителей.

Преимущества композиционных систем обработки данных:

1. Гибкость:
   • Композиционные системы предоставляют пользователям максимальную гибкость. Общие жалобы от конечных пользователей монолитных систем включают: a) Отсутствие поддержки предпочитаемого ими языка работы (например, SQL-системы, которые не имеют интеграции с API для dataframe, или системы на основе API для dataframe, не обладающие хорошей поддержкой SQL, R против Python и т.д.) и b) Реалистичные сценарии использования требуют данных, заточенных под более чем одну систему. В композиционных системах пользователи получат свободу работать на выбранном ими языке и легко подключаться к разным источникам данных. Это повышает производительность команд обработки данных, поскольку они могут придерживаться знакомого интерфейса для всех своих работ и не сталкиваются с барьерами между системами данных.

2. Производительность:
   • Не секрет, что многие системы данных затянуты техническим долгом, который сложно и дорого устранить. С течением времени системы данных теряют свою “современность” и, вероятно, будут превзойдены более новыми системами по производительности. Это явление мы видели много раз за последние пятьдесят лет, и нет причин считать, что оно прекратится в ближайшее время. Для компаний, которые заинтересованы в получении передовой производительности от своих систем данных, это означает, что они постоянно оценивают новые системы и переносят рабочие нагрузки на новые системы, предлагающие лучшую производительность. Многие также сталкиваются с дополнительной сложностью или ухудшением пользовательского опыта только потому, что производительность для них настолько важна. Системы передового уровня, оптимизированные под производительность, часто не сосредотачиваются на обеспечении отличного пользовательского опыта. Результатом является множество своевременных и дорогостоящих миграций данных, переписывание рабочих процессов и общее напряжение в команде обработки данных, так как им трудно следовать современным тенденциям. Принятие композиционной платформы обработки данных позволило бы этим организациям минимизировать нарушения в потоках данных, сохраняя при этом использование передовых технологий. Предположим, что выходит новый слой хранения, обещающий значительное улучшение времени доступа и ускорение нескольких рабочих процессов. Команда данных может начать использовать его, не переписывая рабочих процессов или изменяя двигатель, просто переместив некоторые данные и попробовав его. Или, если появляется новый двигатель, обещающий значительный прирост производительности для ключевых рабочих процессов, его легко можно заменить, не изменяя кода рабочего процесса или перемещая данные. Фактически, композиционные системы обработки данных упрощают оптимизацию собственных рабочих процессов вокруг производительности и всегда позволяют использовать последние достижения в проектировании систем обработки данных.

3. Управление затратами:
   • Вместе с повышенной гибкостью и увеличением производительности композиционные системы обработки данных предоставляют потребителям гораздо больший контроль над затратами на систему. Монолиты, по определению, представляют собой комплексные предложения, и потребители, вероятно, платят за функции, которые они не используют, и/или застревают при использовании дорогостоящих и сложных проприетарных компонентов, которые позднее трудно мигрировать. Композиционные системы предоставляют модульные компоненты, что позволяет организациям данных более детально соответствовать дизайн системы своим потребностям. Для компаний, которые хотят получить максимальную производительность, они могут решиться на роскошный двигатель с поддержкой поставщика и использовать хранилища данных с открытым исходным кодом и интерфейсы пользователя. Это также позволяет компаниям более легко использовать преимущества достижений в области аппаратного ускорения, которые распространяются в последние несколько лет и которые должны значительно снизить общую стоимость владения (TCO) их систем данных

.

4. Инкрементальное принятие:
   • Композиционные системы обработки данных позволяют организациям постепенно переходить к новому подходу, перемещая определенные нагрузки, сохраняя при этом другие рабочие процессы на традиционных системах, если они работают хорошо. Если что-то не сломано, не чините. Однако во многих рабочих процессах обработки данных должно быть достаточно проблем, оправдывающих изучение композиционных систем. Это низкорискованное предложение с ограниченным недостатком, поскольку оно не нарушает существующие рабочие процессы, и пользователи могут легко начать, дополнив свои собственные среды, вместо того чтобы сталкиваться с еще одной дорогостоящей миграцией.

5. Удобство оптимизации:
   • Модульный характер композиционных систем позволяет более гибко подстраивать систему под конкретные потребности, включая выбор оптимальных компонентов для каждой части системы. Это дает пользователям больше возможностей для оптимизации и эффективного использования своих данных.

6. Постепенное внедрение:
   • Композиционные системы данных позволяют организациям постепенно переходить к новому подходу, перемещая определенные рабочие нагрузки, сохраняя при этом другие процессы на традиционных системах, если они хорошо функционируют. Это обеспечивает гибкость внедрения и минимизирует риски, связанные с переходом к новой системе.

Чтобы узнать больше:

Voltron Data предоставляет отличный обзор композиционных систем, который стоит прочитать всем, кто интересуется этой темой и хочет начать что-то новое с своими данными.

Перевод с GPT 3.5

curl wttr.in/Moscow

23 июля 1983 года “Боинг-767” авиакомпании “Air Canada” (бортовой номер 604) был неправильно заправлен топливом ☝️

В то время Канада переходила на литры и все стороны, участвовавшие в пересчетах керосина на дозаправку банально облажались.
Итог – в один прекрасный момент самолет на высоте 8000 метров превратился в замечательный 132-тонный, движущийся исключительно по инерции, контейнер. Без двигателей и половины приборов (отключились, поскольку работали от двигателей). Единственное, что работало в самолете – это аварийный ветрогенератор, благодаря которому поддерживалось давление в гидравлической системе. Право, я не знаю, как себя чувствовали 69 обитателей железного ящика, оказавшиеся на такой высоте.
Второй пилот Морис Квинтал, полистав инструкцию, не обнаружил раздела “Что делать, если вырубились все движки, а жить хочется”. Поскольку КВС Боб Пирсон в свое время занимался планеризмом а выбора все равно не было – решили планировать до ближайшего аэродрома.
Проблема была в подсчете скорости снижения – работал только спидометр, который показывал падение скорости от начальных 900 км/ч. На конец полета, скажу сразу, упал до 400 км/ч. Альтиметр (показывающий высоту) отключился. С помощью механического резервного прикинули, что снижаются со скоростью 1,5 км на 19 км полета.
Квинтал сказал, что знает хорошее заведение с блэк-джеком, старую авиабазу неподалеку (примерно 8000 метров вниз и чуть вбок). База называлась Гимли . Квинтал когда-то дембельнулся с этой базы и уговорил командира свернуть к местам боевой славы. Но в тот день у фортуны было игривое настроение.
На поле бывшей авиабазы организация “Виннипег Спортс Кар Клаб” устроила в честь субботы тусовку, с гонками на той самой ВВП. Сама полоса для этих целей использовалась регулярно, в центре даже был разделительный барьер, позволяющий проводить параллельные гонки. По краям полосы народ пил пиво, жарил мясо и всячески наслаждался жизнью, даже не предполагая какой супрайз может свалиться на их головы. В принципе, Пирсон мог в одиночку выпилить весь данный “клаб” из списка существующих организаций.
Не знаю насколько нескучно было в салоне в процессе снижения, но вот дальше началась истинная веселуха. Во первых нужно было выпустить шасси. С этой целью самолет встряхнули. Шасси выпали. Две задние стойки даже встали на замок. Пассажиры, думаю, начали о чем-то догадываться. Появились первые кирпичи.
Для посадки Боб Пирсон использовал (как я понимаю, единственный раз в мировой истории) в процессе посадки большого авиалайнера прием из арсенала планеристов. Называется он “скольжение на крыло”, он же “sideslip”. Эта милая процедура выглядит так: самолет ставится “на крыло” и у пассажиров есть выбор: смотреть в нижний иллюминатор на землю, в верхний на небо, но при этом продолжать срать кирпичами. Нос самолета, кстати, уводится в сторону от курса.Скорость, соответственно, падает до нужной. Состояние пассажиров “от щастья, что они это испытали” не передается описанию.
Уверен, что не меньше кирпичей появилось на аэродроме имени товарища Гимли, когда они увидели аэробус, направляющийся к ним, положение крыльев которого не предвещало, что садиться вообще входит в его планы. Но, в последний момент самолет выровнялся и опустился на полосу. Передняя стойка подломилась и он весело начал приближаться к тусовке автолюбителей. Надо сказать, что в момент посадки скорость была 320 км/ч, так что субботние гонки однозначно выиграл экипаж Пирсон-Квинтал.
Под спецэффекты в виде дымящихся и лопающихся колес, и шлейфа искр из-под гондолы самолет направился к автолюбителям. Чтобы они лучше могли рассмотреть посадку во всех деталях, он подъехал поближе. Как пишут, остановился в 30 метрах от группы встречающих.
Далее все получилось просто и буднично: скинули надувные трапы, выгнали пассажиров наружу, чтобы проветрить салон. Начавшийся пожар потушили автолюбители обычными автомобильными огнетушителями.
Причиной нескольких легких травм, полученных пассажирами, была не посадка. А поспешная высадка из заднего аварийного выхода. Хвост был слишком высоко и при скатывании по трапу банально не хватило высоты.
Квинтал в 1989 года сдал экзамен на КВС и летал на многих самолетах, как уверяют, и на борту №604 тоже. Пирсон в 1993 вышел на пенсию.
Ремонт самолета сделали на аэродроме Гимли за 2 дня. И он своим ходом улетел на базу, где полный ремонт обошелся в 1 млн долларов. Вскоре он вернулся в строй и использовался до января 2008 года.

https://ru.wikipedia.org/wiki/Планёр_Гимли

What Is Data Mesh?

А еще недавно вышла книга на русском про дата мех (мех как то пушистее звучит)

Статейка:
https://a.gavrilov.info/data/posts/Introduction%20to%20StarRocks:%20a%20New%20Modern%20Analytical%20Database%20%7C%20by%20Javier%20Ramos%20%7C%20ITNEXT.pdf

https://www.starrocks.io

StarRocks, a Linux Foundation project, is a next-generation sub-second MPP OLAP database for full analytics scenarios, including multi-dimensional analytics, real-time analytics, and ad-hoc queries. InfoWorld’s 2023 BOSSIE Award for best open source software.

https://github.com/rilldata/rill

Качаем, ставим, запускаем:

curl -s https://cdn.rilldata.com/install.sh | bash
rill start my-rill-project

Можно еще статейку полистать:
https://a.gavrilov.info/data/posts/Unlocking%20Data%20Insights%20with%20Rill:%20A%20Comprehensive%20Guide%20to%20Streamlined%20Data%20Analytics%20%7C%20by%20Felix%20Gu.pdf

🤌 DuckDB inside

Смотрим тут:
https://www.figma.com/file/SABujfIEwzpa1NuWiVS3RR/The-Product-Map-3.0?type=whiteboard&node-id=111-1506

Статья с хабра про выбор баз данных
https://habr.com/ru/articles/775574/

Смотрим тут: https://perthirtysix.com/tool/visualizing-american-inflation

https://perthirtysix.com/tool/visualizing-american-inflation

Или копию pdf тут: https://a.gavrilov.info/data/posts/How%20Far%20Would%20$1%20From%201999%20Go%20Today%3F.pdf

https://github.com/adsblol/globe_history

✈️🗄 Historical data for all aircrafts traces known to adsb.lol. Openly licensed.

https://github.com/adsblol/globe_history/

This is a database for the day of 2023-12-09 of all aircraft known to adsb.lol.
GitHub Release: v2023.12.09-planes-readsb-staging-0
GitHub Download Link: https://github.com/adsblol/globe_history/releases/tag/v2023.12.09-planes-readsb-staging-0
Uploaded on: 2023-12-10
Original Path: /var/globe_history/2023/12/09
Pod of origin: planes-readsb-staging-0

It was made by readsb (https://github.com/wiedehopf/readsb)


This database is made available under the Open Database License:
    http://opendatacommons.org/licenses/odbl/1.0/.
    Attached locally: LICENSE-ODbL.txt

This is made possible by the adsb.lol feeders.
If you want to help, please consider increasing coverage by adding a feeder:
    https://adsb.lol/feed

By feeding adsb.lol, you agree to the extent possible under law,
to waive all copyright and related or neighboring rights to your data, associating your work with the CC0 license.
    https://creativecommons.org/publicdomain/zero/1.0/
    Attached locally: LICENSE-CC0.txt

ps: может понадобиться декодер https://github.com/wiedehopf/readsb