Смотрим тут: https://www.nftenergy.art
Интересные участники. И конечно Вини тоже там:

Что бы все мечты сбылись. Мира, здоровья и добра!

https://medium.com/airbnb-engineering/data-quality-score-the-next-chapter-of-data-quality-at-airbnb-851dccda19c3

Автор: Кларк Райт

Введение

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

С 1,4 миллиарда кумулятивных посещений гостей на конец 2022 года рост Airbnb вынудил нас прийти к точке перегиба, где ухудшение качества данных начало препятствовать работе наших специалистов по данным. Еженедельные отчеты по метрикам были трудно подготовить в срок. Вроде бы базовые метрики, такие как “Активные объявления”, зависели от сложной сети зависимостей. Для проведения значимой работы с данными требовалось значительное институциональное знание для преодоления скрытых трудностей с данными.

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

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

Как мы могли бы распространить выигрыши и лучшие практики Midas на весь наш хранилище данных?

В этом блоге мы расскажем о нашем инновационном подходе к оценке качества данных — Оценке качества данных Airbnb (“DQ Score”). Мы расскажем, как мы разработали DQ Score, как он используется сегодня и как он будет поддерживать следующий этап обеспечения качества данных в Airbnb.

Масштабирование качества данных

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

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

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

Мы определили следующие цели для оценки:

Эволюция нашего понимания качества данных за пределами простого двоичного определения (сертифицированные против несертифицированных).
Выравнивание входных компонентов для оценки качества данных.
Обеспечение полной видим

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

Прежде чем погружаться в тонкости измерения качества данных, мы достигли согласия по видению, определив принципы направления DQ Score. При участии многофункциональной группы практиков данных мы выработали согласие по следующим основным принципам:

Полное охват — оценка может быть применена к любому активу данных офлайн-хранилища данных
Автоматизированность — сбор входных данных, определяющих оценку, на 100% автоматизирован
Действенность — оценка легко обнаруживается и используется как для производителей, так и для потребителей
Многомерность — оценку можно разложить на столбы качества данных
Эволютивность — критерии оценки и их определения могут меняться со временем
Хотя они могут показаться простыми или очевидными, установка этих принципов была критичной, поскольку они направляли каждое принятое решение в разработке оценки. Вопросы, которые в противном случае могли бы сорвать прогресс, были сопоставлены нашими принципами.

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

У нас также был ряд входных сигналов, которые более прямо измеряли качество (сертификация Midas, проверка данных, ошибки, SLA, автоматические проверки качества данных и т. д.), в то время как другие были более похожи на показатели качества (например, правильная принадлежность, хорошая гигиеничность управления, использование инструментов планирования). Были ли более явные и прямые измерения качества более ценными, чем показатели?

Руководствуясь нашими принципами, мы в конечном итоге определили четыре измерения качества данных: Точность, Надежность (Своевременность), Управление и Удобство использования. Было несколько других возможных измерений, которые мы рассматривали, но эти четыре измерения были наиболее смысловыми и полезными для наших практиков данных и имели смысл как оси улучшения, на которых нам важно и мы готовы инвестировать в улучшение наших данных вдоль этих измерений.

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

Мы также могли бы взвесить каждое измерение в соответствии с нашим восприятием его важности для определения качества. Мы учитывали 1) сколько оценочных компонентов принадлежит каждому измерению, 2) обеспечивая быстрый умственный расчет, и 3) какие элементы важны больше всего для наших практикующих, чтобы распределить 100 общих баллов между измерениями:

The “Dimensions of Data Quality” and their weights

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

Unpacking the Data Stewardship Dimension

Представление Рейтинга для Практиков

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

К счастью, у нас было два существующих инструмента, которые сделали бы это гораздо проще: Dataportal (каталог данных и пользовательский интерфейс для исследования данных Airbnb) и Unified Metadata Service (UMS). Сам рейтинг вычисляется в ежедневном автономном потоке данных, который собирает и преобразует различные элементы метаданных из наших систем данных. Завершающий этап потока данных загружает рейтинг для каждого актива данных в UMS. Подключив DQ Score к UMS, мы можем предоставлять рейтинг и его компоненты наряду с каждым активом данных в Dataportal, отправной точке для всех открытий и исследований данных в Airbnb. Оставалось только разработать его представление.

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

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

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

1. Единый высокоуровневый рейтинг от 0 до 100. Мы установили категориальные пороги “Плохо”, “Хорошо”, “Отлично” и “Превосходно” на основе анализа профилирования нашего хранилища данных, который изучал существующее распределение нашего Рейтинга DQ. Подходит для быстрой высокоуровневой оценки общего качества набора данных.

2. Измерения рейтинга, где актив может иметь идеальный балл по точности, но низкий по надежности. Полезно, когда конкретная область недостатка не проблематична (например, потребитель хочет, чтобы данные были очень точными, но не беспокоится о том, что они поступают каждый день быстро).

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

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

Full data quality score page in Dataportal

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

Full score detail presentation

Как сегодня используется рейтинг

Для производителей данных рейтинг предоставляет:

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

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

Наконец, разработав рейтинг качества данных, мы смогли предоставить единое руководство нашим производителям данных по созданию высококачественных, хотя и несертифицированных активов. Рейтинг качества данных не заменил сертификацию (например, только данные, сертифицированные Midas, могут получить рейтинг DQ > 90). Мы продолжаем сертифицировать наш самый критический поднабор данных и считаем, что сценарии использования для этих активов всегда будут обосновывать ручную проверку, строгость и поддержание сертификации. Но для всего остального рейтинг DQ укрепляет и масштабирует принципы Midas в нашем хранилище данных.

Что дальше

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

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

Благодарности

Рейтинг DQ не был бы возможен без участия нескольких кросс-функциональных и кросс-организационных коллег. К ним относятся, но не ограничиваются: Марк Стейнбрик, Читта Широлкар, Джонатан Паркс, Сильвия Томияма, Феликс Оук, Джейсон Флиттнер, Ин Пан, Логан Джордж, Вуди Чжоу, Мишель Томас и Эрик Риттер.

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

Если вас интересует такая работа, ознакомьтесь с некоторыми из наших связанных вакансий.

****************

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

Перевод ChatGPT

https://medium.com/free-code-camp/the-rise-of-the-data-engineer-91be18f1e603

В 2011 году я присоединился к Facebook в качестве инженера по бизнес-аналитике. К моменту моего ухода в 2013 году я уже был инженером по данным.
Меня не повысили и не перевели на новую должность. Вместо этого в Facebook поняли, что наша работа выходит за рамки классической бизнес-аналитики. Роль, которую мы создали для себя, представляла собой совершенно новую дисциплину.
Моя команда была на переднем крае этой трансформации. Мы разрабатывали новые навыки, новые способы ведения работы, новые инструменты и, как правило, отказывались от традиционных методов.
Мы были первопроходцами. Мы были инженерами по данным!
Инженерия данных?
Наука о данных как дисциплина проходила свой период подросткового самоподтверждения и самоопределения. В то же время инженерия данных была немного младшей сестрой, но проходила через что-то похожее. Дисциплина инженерии данных брала подсказки от своей старшей сестры, определяя себя также в противопоставлении и находя свою уникальную идентичность.
Как и у данных ученых, у инженеров по данным есть кодирование. Они высокоаналитичны и интересуются визуализацией данных.
В отличие от данных ученых и вдохновленные более зрелым родителем, программной инженерией, инженеры по данным строят инструменты, инфраструктуру, фреймворки и сервисы. Фактически можно утверждать, что инженерия данных ближе к программной инженерии, чем к науке о данных.
В отношении ранее существовавших ролей область инженерии данных может рассматриваться как суперсет бизнес-аналитики и хранилища данных, внедряя более многоэлементные элементы программной инженерии. Эта дисциплина также интегрирует специализацию вокруг операций так называемых распределенных систем “больших данных”, концепций расширенной экосистемы Hadoop, потоковой обработки и вычислений в масштабе.
В малых компаниях, где еще не формализована команда по инфраструктуре данных, роль инженера по данным может также включать в себя нагрузку по настройке и обслуживанию инфраструктуры данных организации. К этим задачам относятся установка и обслуживание платформ, таких как Hadoop/Hive/HBase, Spark и подобных.
В более крупных средах часто происходит специализация и создание формальной роли для управления этой нагрузкой, по мере роста потребности в команде инфраструктуры данных. В этих организациях автоматизация некоторых процессов инженерии данных ложится на руки как команде по инженерии данных, так и команде по инфраструктуре данных, и часто эти команды сотрудничают для решения более высокоуровневых проблем.
В то время как инженерный аспект роли расширяется, другие аспекты исходной роли бизнес-инженера становятся второстепенными. Области, такие как создание и поддержание портфелей отчетов и панелей, не являются первостепенным вниманием инженера по данным.
ETL меняется
Мы также наблюдаем общий отход от инструментов ETL с интерфейсом перетаскивания и редактирования в сторону более программного подхода. Знание продуктовых платформ, таких как Informatica, IBM Datastage, Cognos, AbInitio или Microsoft SSIS, не так распространено среди современных инженеров

по данным и заменяется более общими навыками программной инженерии, а также пониманием программных или конфигурационно-управляемых платформ, таких как Airflow, Oozie, Azkabhan или Luigi. Также довольно распространено, что инженеры разрабатывают и управляют своими собственными оркестраторами/планировщиками заданий.
Есть множество причин, почему сложные программы не разрабатываются с использованием инструментов перетаскивания и редактирования: в конечном итоге код – это лучшая абстракция для программного обеспечения. Хотя за пределами этой статьи сложно спорить на эту тему, легко предположить, что те же самые причины применимы к написанию ETL, как и к любому другому программному обеспечению. Код позволяет использовать произвольные уровни абстракции, работает с любыми логическими операциями знакомым способом, хорошо интегрируется с контролем версий, легко версионируется и сотрудничает. Факт того, что инструменты ETL эволюционировали в сторону графических интерфейсов, кажется каким-то отклонением в истории обработки данных и, безусловно, заслуживает собственного интересного блога.
Давайте подчеркнем тот факт, что абстракции, предлагаемые традиционными инструментами ETL, являются нецелевыми. Конечно, есть необходимость в абстрагировании сложности обработки данных, вычислений и хранения. Но я бы утверждал, что решение не заключается в предоставлении примитивов ETL (таких как источник/цель, агрегации, фильтрация) в форме перетаскивания и редактирования. Нужны абстракции более высокого уровня.
Например, примером нужной абстракции в современной среде данных является конфигурация экспериментов в рамках структуры тестирования A/B: какие все эксперименты? какие связанные обработки? какой процент пользователей должен быть выставлен? какие метрики ожидается, что каждый эксперимент повлияет? когда вступает в силу эксперимент? В этом примере у нас есть структура, которая получает точный, высокоуровневый ввод, выполняет сложные статистические вычисления и предоставляет вычисленные результаты. Мы ожидаем, что добавление нового эксперимента приведет к дополнительным вычислениям и результатам. Важно отметить в этом примере, что входные параметры этой абстракции не соответствуют параметрам, предлагаемым традиционным инструментом ETL, и что создание такой абстракции в интерфейсе перетаскивания и редактирования было бы невозможно.
Для современного инженера по данным традиционные инструменты ETL в значительной степени устарели, потому что логику нельзя выразить с помощью кода. В результате необходимые абстракции не могут быть выражены интуитивно в этих инструментах. Учитывая, что роль инженера по данным в значительной степени заключается в определении ETL, и зная, что для этого нужен совершенно новый набор инструментов и методологии, можно утверждать, что это заставляет дисциплину перестраиваться с нуля. Новый стек, новые инструменты, новый набор ограничений и, во многих случаях, новое поколение специалистов.

Меняющаяся модель данных

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

Вот несколько изменений, замеченных в методиках моделирования данных:

• Дальнейшая денормализация: поддержание заменителей ключей в измерениях может быть трудным и делает фактические таблицы менее читаемыми. Использование естественных, понятных человеку ключей и атрибутов измерений в фактических таблицах становится более общим, уменьшая необходимость в дорогостоящих объединениях, которые могут быть сложными для распределенных баз данных. Также следует отметить, что поддержка кодирования и сжатия в сериализационных форматах, таких как Parquet или ORC, или в базах данных, таких как Vertica, решает большинство проблем с производительностью, которые обычно сопутствуют денормализации. Эти системы научились нормализовывать данные для хранения самостоятельно.
• BLOB: современные базы данных имеют растущую поддержку для BLOB через встроенные типы и функции. Это открывает новые возможности в арсенале моделировщика данных и может позволять фактическим таблицам хранить несколько зерен одновременно, когда это необходимо.
• Динамические схемы: с появлением MapReduce, растущей популярностью хранилищ документов и поддержкой BLOB в базах данных становится проще эволюционировать схемы базы данных без выполнения DML. Это упрощает итеративный подход к хранилищу данных и устраняет необходимость в полном консенсусе и согласовании до разработки.
• Систематическое создание снимков измерений (хранение полной копии измерения для каждого цикла ETL, обычно в отдельных разделах таблицы) в качестве общего способа обработки измерений со скользящим изменением (SCD) – простой универсальный подход, требующий небольших усилий инженерии и который, в отличие от классического подхода, легко понимается при написании ETL и запросов. Также легко и относительно дешево денормализовать атрибут измерения в фактическую таблицу, чтобы отслеживать его значение в момент транзакции. В ретроспективе сложные техники моделирования SCD не интуитивны и снижают доступность.
• Соответствие, как в соответствующих измерениях и метриках, по-прежнему чрезвычайно важно в современной среде данных, но с необходимостью хранилищ данных двигаться быстро и с привлечением большего числа команд и ролей для участия в этом усилии, это менее императивно и скорее является компромиссом. Согласование и сходимость могут происходить как фоновый процесс в областях, где болевая точка расхождения становится неприемлемой.
• Также, в более общем смысле, можно утверждать, что с товаризацией циклов вычислений и с более продвинутыми пользователями данных, чем раньше, становится менее необходимым предварительное вычисление и сохранение результатов в хранилище данных. Например, можно использовать сложные задания Spark, которые могут вычислять сложный анализ по требованию, а не планироваться для включения в хранилище данных.

Роли и обязанности
Хранилище данных
Хранилище данных – это копия транзакционных данных, специально структурированная для запросов и анализа. – Ральф Кимболл
Хранилище данных – это предметно-ориентированная, интегрированная, временная и непеременная коллекция данных в поддержку процесса принятия решений управления. – Билл Инмон
Хранилище данных так же актуально, как и раньше, и инженеры по данным отвечают за мног

ие аспекты его создания и эксплуатации. Фокус инженера по данным – это хранилище данных, и он вращается вокруг него.

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

Команда по инженерии данных часто будет владеть сегментами сертифицированных, высококачественных областей в хранилище данных. В Airbnb, например, есть набор “ядреных” схем, управляемых командой инженеров данных, где четко определены и измеряются уровни обслуживания (SLA), строго следятся соглашения об именовании, бизнес-метаданные и документация высшего качества, а связанный код конвейера следует определенному набору bewt-практик.

Также роль команды по инженерии данных заключается в том, чтобы быть “центром компетенции” через определение стандартов, bewt-практик и процессов сертификации для объектов данных. Команда может эволюционировать, чтобы принимать участие или лидировать программу образования, предоставляя свои основные компетенции для помощи другим командам в становлении лучшими участниками хранилища данных. Например, у Facebook есть программа образования “Data Camp”, а Airbnb разрабатывает аналогичную программу “Data University”, где инженеры данных ведут занятия, обучая людей, как быть компетентными в области данных.

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

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

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

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

Интеграция данных

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

Разрешение SaaS определять справочные данные без интеграции и обмена общим основным ключом — это катастрофа, которую следует избегать любой ценой. Никто не хочет вручную поддерживать два списка сотрудников или клиентов в двух разных системах, а тем более заниматься нечетким сопоставлением при возвращении их данных по управлению персоналом в их хранилище данных.
Еще хуже, руководители компаний часто заключают сделки с поставщиками SaaS, не рассматривая настоящие вызовы интеграции данных. Рабочая нагрузка по интеграции систематически занижается поставщиками, чтобы облегчить продажи, и оставляет инженеров данных замешанными на неучтенной, недооцененной работе. Не говоря уже о том, что типичные API SaaS часто плохо разработаны, неясно документированы и “гибкие”: что означает, что вы можете ожидать изменений без предупреждения.

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

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

• ввод данных: сервисы и инструменты для “парсинга” баз данных, загрузки журналов, извлечения данных из внешних хранилищ или API, …
• вычисление метрик: фреймворки для вычисления и суммирования метрик, связанных с участием, ростом или сегментацией
• обнаружение аномалий: автоматизация потребления данных для оповещения о нештатных событиях или существенных изменениях тенденций
• управление метаданными: инструменты для генерации и потребления метаданных, упрощающие поиск информации в хранилище данных и вокруг него
• экспериментирование: фреймворки тестирования A/B и экспериментов часто являются ключевой частью аналитики компании с существенным компонентом инженерии данных
• инструментирование: аналитика начинается с регистрации событий и атрибутов, связанных с этими событиями, инженеры данных имеют заинтересованность в том, чтобы убедиться, что высококачественные данные захватываются вверх по потоку
• сессионизация: конвейеры, специализированные в понимании последовательности действий во времени, позволяющие аналитикам понимать поведение пользователя
  Как и программисты, инженеры данных должны постоянно стремиться автоматизировать свои рабочие нагрузки и создавать абстракции, позволяющие им подниматься по лестнице сложности. Хотя характер рабочих процессов, которые можно автоматизировать, различается в зависимости от окружения, необходимость в автоматизации обща для всех.

Навыки, необходимые для работы

Владение SQL: если английский язык — это язык бизнеса, то SQL — язык данных. Как успешно может быть предприниматель, не зная хорошо английский? Несмотря на то что технологии приходят и уходят, SQL по-прежнему стоит крепко, как лингва франка в мире данных. Инженер по данным должен быть способен выражать любую степень сложности на SQL, используя техники, такие как “коррелированные подзапросы” и оконные функции. Основы SQL/DML/DDL настолько просты, что не должны оставаться тайной для инженера по данным. Помимо декларативной природы SQL, он/она должны уметь читать и понимать планы выполнения запросов в базе данных, иметь представление о том, как работают индексы, различные алгоритмы объединения и распределенное измерение в плане выполнения.

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

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

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

В целом
За последние 5 лет, работая в Силиконовой долине в Airbnb, Facebook и Yahoo!, и взаимодействуя обширно с командами по данным различных компаний, таких как Google, Netflix, Amazon, Uber, Lyft и десятки компаний разных размеров, я замечаю растущий консенсус относительно того, каким образом “инженерия данных” развивается, и почувствовал необходимость поделиться некоторыми из моих наблюдений.
Я надеюсь, что этот материал может служить своего рода манифестом для инженерии данных, и я надеюсь вызвать реакции от сообщества, работающего в связанных областях!

Перевел chatGPT

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