[Перевод] Шестая платформа данных: новое слово в хранении и обработке данных
Скорее всего, в ближайшие 3–5 лет появятся новые интеллектуальные приложения для работы с данными, и для них понадобится новый тип современной платформы. Мы называем ее «шестая платформа данных».
Раньше описывали эту концепцию при помощи метафоры «Uber для всех». Так мы называли системы программного обеспечения для цифрового представления бизнеса. Разные данные, например о людях, местах и объектах, поступают в эту модель и объединяются в ней в связное целое. Исходя из этой информации, компании принимают решения и действуют в реальном времени. Мы утверждали, что это будет коммерческая готовая к использованию программа — в каждом конкретном случае не понадобится нанимать тысячи разработчиков, которые будут создавать кастомное решение.
Команда VK Cloud перевела статью об этой самой «шестой платформе данных». Это переработка подкаста Breaking Analysis с гостем Райаном Блю — одним из создателей и председателем комитета по управлению проектами Apache Iceberg. Он соучредитель и генеральный директор компании Tabular Technologies Inc., основанной создателями Iceberg и разработавшей универсальное открытое табличное хранилище, которое подключается к любому уровню вычислительных ресурсов.
Эволюция методов управления открытыми хранилищами и ее влияние на современные платформы данных
Нагляднее всего понять эволюцию платформ данных можно по этой картинке:
Пять современных платформ данных и решения, входящие в их состав, а также несколько разработчиков шестой платформы. Сегодня Amazon Web Services и развивающиеся модульные платформы — преимущественно кастомные продукты и инструменты, которые могут дорасти до платформы
Традиционные платформы данных привязывают к себе заказчиков, ведь исторически они контролируют клиентские данные. Хотя на уровне архитектуры хранение и вычислительные операции могут быть представлены раздельно, они всё же эффективно интегрированы друг с другом. Благодаря такой интеграции поставщик платформы полностью контролирует и размещенные данные, и разные рабочие нагрузки с ними. Из-за необходимости передавать данные по пайплайнам этот контроль охватывает бизнес-аналитику, дата-инжиниринг и машинное обучение.
Рост популярности открытых хранилищ данных подстегивает конкуренцию. Независимость в управлении хранением данных и разрешениями на доступ открывает перед клиентами широкий выбор и, вне зависимости от контроля над данными, вынуждает поставщиков конкурировать друг с другом за каждую рабочую нагрузку, опираясь на ценность для бизнеса, которую они приносят.
В будущем для обмена данными на предприятии понадобится открытое хранилище, где в одном экземпляре данных можно будет выполнять чтение и запись. Это подстегнет формирование поставщиками стандартов информационного обмена на предприятиях.
Некоторые участники формирующегося рынка современных платформ данных и картина будущей конкуренции:
Возможно, Snowflake превзойдет конкурентов как наиболее производительный сервис бизнес-аналитики.
DBT Labs обеспечит экономичное управление пайплайнами данных с помощью таких инструментов, как PySpark или Spark SQL на AWS EMR.
Databricks может стать наиболее подходящим решением для конструирования признаков и машинного обучения на совместно используемых данных.
Даже в области бизнес-аналитики мы наблюдаем конкуренцию. Такие инструменты, как семантический слой dbt и AtScale, могут кешировать регулярно получаемые метрики запросов, обеспечивая синхронизацию разрешений с СУБД.
Ближайшие задачи и трудности, связанные с хранением данных
Серьезная проблема модульных хранилищ — поиск оптимального баланса governance между СУБД или механизмами обработки запросов и платформами с открытым хранилищем. Например, между Iceberg и другими открытыми табличными форматами.
Станут ли модульные компоненты вроде Iceberg и Starburst дополнением к нынешним платформам, или клиенты будут собирать из них полностью альтернативные решения?
Есть большая разница между нашими нынешними платформами и представлением об интеллектуальном приложении данных, работающем в реальном времени. Вот главные вопросы по этой теме:
Заменят ли подключаемые модули компонентов вроде Iceberg компоненты сегодняшних платформ данных?
Или заказчики будут использовать их для сборки альтернативных платформ?
Каковы плюсы и минусы открытого модульного варианта (если он в принципе возможен) и интегрированного, как правило, более простого, но в целом более дорогого решения?
Ответы на эти вопросы довольно простые. Да, платформы постепенно становятся модульными. Возьмем, к примеру, Google, Microsoft, Amazon и в какой-то мере Databricks и Snowflake. Эти платформы — уже не единая система, не единый механизм или уровень хранения. Это сложные системы, включающие очень разнообразные продукты. Вы ведь уже обратили внимание на механизмы Hadoop и Microsoft Synapse? Это ведь Spark. Он также входит в состав платформы Databricks. На сегодняшний день перед Snowflake стоит важнейшая задача: решить, как предоставлять данные людям, которые хотят вместе с ним использовать Spark. Так что эти монолитные системы уже распадаются на модули, превращаясь в совокупность проектов, которые работают вместе.
Но сколько нам еще ждать, пока эти компоненты начнут слаженно работать друг с другом, и что должно измениться?
Оценка ETR: расходы на сервисы компаний большой пятерки + Oracle
Данные опроса «Планы по расходам на современные технологии» компании ETR отражают присутствие на рынке крупнейших создателей платформ данных и уровень расходов на их платформы. По оси X отложена распространенность среди клиентов. По оси Y — уровень расходов
На графике представлена информация о расходах на ведущие платформы данных в облаке. Этот срез информации показывает предложения по базам и хранилищам данных, отфильтрованные по клиентам облачных провайдеров. Мы включили в график Oracle из уважения к королю баз данных, который и сейчас агрессивно инвестирует, расширяя возможности своих платформ. Кроме того, таким образом мы уточняем актуальный контекст, поскольку Oracle — это зрелая компания, занимающая заметную долю рынка.
Ось Y отражает суммарный балл или уровень расходов. Он показывает процент клиентов — участников опроса (N = 1165 клиентов облачных провайдеров), которые тратят больше на платформу конкретного поставщика. Ось X с надписью Overlap (Пересекающиеся значения) отражает присутствие в датасете и определяется количеством клиентов, связанных с конкретным поставщиком, деленным на общее количество в секторе. Горизонтальную ось можно рассматривать как показатель присутствия на рынке.
Красная пунктирная линия на уровне 40% — это показатель повышения скорости расходов на платформу.
Вот на что стоит обратить внимание:
Из-за макроэкономических факторов практически все платформы данных столкнулись с пертурбациями, сдерживающими расходы клиентов.
Как показано на оси X, благодаря большому парку оборудования, на котором установлены его решения, Microsoft остается вездесущим. Возможно, в опросе часто фигурирует SQL Server (отсюда красная звездочка).
Самый высокий суммарный балл у Databricks, но можно сказать, что он только формируется, потому что его SQL-хранилище данных появилось на рынке совсем недавно.
Последние несколько кварталов Snowflake продолжает проникать на рынок по оси X, но его суммарный балл резко пошёл вниз. По результатам анализа это объясняется не оттоком клиентов или снижением расходов с их стороны, а скорее долей клиентов Snowflake, которые фиксируют размер расходов, а не повышают их.
У уникального набора сервисов баз данных AWS сохраняется высокий суммарный балл, и их доля остается внушительной.
Как видно, Oracle занимает существенную долю рынка, но, в сущности, живет за счет парка оборудования, на котором установлено его программное обеспечение.
Напомним, что эти данные не отражают уровень расходов. Скорее они показывают процент клиентов, которые предпринимают те или иные действия, связанные с расходами: добавить новые ресурсы, потратить больше, зафиксировать расходы, потратить меньше, уйти к другому поставщику.
Формирующиеся компоненты шестой платформы данных
Опрос компании ETR «Формирующиеся технологии» (ETS). Ось X — осведомленность потребителя о продукте. Ось Y — суммарный показатель настроений
Еще одна особенность датасета компании ETR видна из опроса ETS — это возможность измерить настроение и осведомленность потребителя в отношении продуктов непубличных компаний. На рисунке выше мы выделили сведения по четырем основным создателям шестой платформы данных: Fivetran, DBT Labs, Starburst и AtScale. Ломаная линия Starburst показывает положительную динамику с ноября 2020-го. У всех четырех компаний сходная траектория. Это одна из причин, по которой мы выделили именно их.
Суммарный показатель настроений отражает процент клиентов, которые планируют перейти на платформу. Он не учитывает клиентов, которые, например, не планируют пользоваться платформой.
Среди компонентов формирующейся шестой платформы данных Starburst, DBT, Fivetran и AtScale демонстрируют рост осведомленности пользователей и отличаются приемлемым или высоким суммарным показателем настроений.
Мы относимся к этим компаниям как к основным создателям и индикаторам формирующейся шестой платформы данных. На данный момент еще неясно, имеется ли у них финансирование, концепция, принципы реализации и жизнеспособность, достаточные для создания шестой платформы.
Распад интегрированных платформ данных на модули и появление модулей от разных поставщиков
Поставщики интегрированных систем поддержали открытые хранилища, потому что им хотелось получить доступ к большему объему данных. Но как только клиенты перешли на открытые хранилища, их данные вырвались из ловушки изолированного хранилища поставщика.
Если взять Databricks и Snowflake, им нужен доступ ко всем данным. Это создает у них мощный стимул поддерживать проекты вроде Iceberg. Недавно Databricks и Snowflake анонсировали поддержку Iceberg, и это позиция поставщика монолитных решений. Два года назад никто не мог представить, что Snowflake реализует полную поддержку такого проекта.
Это был настоящий сюрприз. Другие поставщики могут конкурировать в этой сфере, потому что они берут все чужие проекты и упаковывают их как готовую архитектуру данных. Вот что очень важно: у этих проектов общее хранилище. Для поставщиков хранилищ, таких как Snowflake, преимущество состоит в том, что они получают доступ ко всем данным, которые не хранятся в Snowflake.
Но еще важнее точка зрения покупателя или пользователя: никто больше не хочет иметь дело с разрозненными, изолированными данными. Всем нужен подход как у Microsoft Fabric. Людям нужен доступ к одним и тем же наборам информации с помощью разных инструментов и средств, будь то ноутбук разработчика с программой на Python или — на другом конце спектра — хранилище Snowflake. Очень важен общий доступ к данным. На уровне выше происходят интеграции вроде Fivetran, когда операции записи выполняются непосредственно в таблицы Iceberg.
Три основных вопроса про появление шестой платформы данных
От Hadoop (изолированная система) к Snowflake (интегрированная система): в чем значение перемен для удобства использования, стоимости и ценности
Для сложной архитектуры Hadoop, предназначенной для высоких нагрузок, требовались специализированные знания, часто от внешних консультантов или внутрикорпоративных экспертов в пресловутых «лабораторных халатах». Несмотря на многообещающие перспективы, Hadoop не удалось завоевать значительную популярность из-за нескольких факторов:
Как следствие, индустрия данных потянулась к более интегрированным платформам типа Snowflake.
Особенности Snowflake. Это интегрированное решение предоставляет уникальные преимущества. Но по сведениям, поступившим с недавнего саммита Snowflake, в отношении платформы наблюдается некоторая напряженность:
Клиенты и партнеры по экосистеме указывают, что компании всё чаще выполняют инжиниринг данных за пределами Snowflake, прежде всего по соображениям стоимости.
Snowflake возражает, что максимальной ценности можно достичь, выполняя такие задачи в Snowpark. При этом они выделяют преимущества интегрированной TCO, заложенные в подходе Snowflake.
В постоянно развивающейся сфере работы с данными мы видим движение от атомарной и фрагментарной экосистемы Hadoop к высокоинтегрированным системам сегодняшнего дня, например Snowflake. Впереди нас ждут и другие кардинальные перемены. Недавно появившиеся тренды поднимают принципиальные вопросы об удобстве использования, стоимости и ценности в современном ландшафте данных.
От Hadoop к Snowflake. Актуальное положение дел:
По данным ETR, популярность Snowflake снижается; особенно заметно падает доля заказчиков, увеличивающих расходы, и процент новых заказчиков.
И всё же конкурентное предложение Snowflake остается весьма коммерчески привлекательным.
Каковы последствия этих перемен для удобства использования, стоимости и ценности? Вера в открытые модульные решения крепка, но остается вопрос: как на пересечении интегрированности и модульности возникает будущее платформ данных?
Чтобы углубиться в этот вопрос, нужно «рассмотреть под микроскопом» особенности открытой модульной системы и преимущества интегрированного подхода и понять: может ли модульность открытых систем воспроизвести преимущества интегрированной системы? Как эти элементы задают будущую траекторию развития платформ данных — это всё еще тема яростных дискуссий и активных исследований.
Наиболее серьезное изменение в архитектуре СУБД и бизнес-модели за последние десять лет — это появление общего хранилища, с данными которого работают разные продукты.
Хотя с архитектурной точки зрения хранилище и вычислительные ресурсы были разделены, де-факто в решениях поставщиков они были интегрированы.
Как только ваши данные оказывались у поставщика, он становился владельцем всех ваших будущих рабочих нагрузок.
Новый «модульный подход» унаследовал дух эпохи Hadoop, когда вы исходили из того, что у обработчиков пакетных, потоковых и специальных задач есть доступ к одним и тем же данным.
Самая кардинальная перемена в базах данных за последние десять лет, а то и больше, — это общий доступ баз к хранилищу. И эта концепция пришла к нам как раз из Hadoop, ведь мы исходили из того, что разные потоковые, пакетные или специальные обработчики должны использовать одни и те же датасеты. Создавая Iceberg и другие форматы, мы опирались именно на эту идею.
И именно это подстегнуло появление решений, которые обеспечивают совместный доступ к данным. Что касается стоимости и удобства использования, кардинальные изменения бизнес-модели затронули практически каждого закрепившегося на рынке поставщика баз, который ориентировался на модель Oracle.Собственно, это даже не модель Oracle. Просто хранилище и вычислительные ресурсы всегда были так тесно связаны, что невозможно было отделить их друг от друга.
Забрав себе рабочие нагрузки, забрав себе датасеты, вы в любом случае получали заказы и на будущие вычислительные ресурсы, вне зависимости от того, было ли ваше решение объективно лучше для клиента в плане производительности, стоимости и т. п. Благодаря появлению совместного доступа к данным можно перемещать рабочие нагрузки, не перебрасывая информацию, не беспокоясь о ее безопасности и синхронизации между разными продуктами.
Все эти проблемы мешали выбирать для данных подходящий механизм, наиболее эффективный или наиболее экономичный. Так что этот переход на открытые и, в частности, независимые хранилища значительно повысит ценность и экономичность работы с данными.
А что насчет governance?
Когда у вас общее хранилище, вы конкурируете с другими решениями за вычислительные ресурсы, которые лучше всего справятся с этой рабочей нагрузкой. Но кто-то же все-таки должен управлять этими данными.
Для начала давайте дадим определение термину governance. Это обеспечение выполнения многими пользователями операций чтения и записи. Возможно, вы вводите данные в разные таблицы, но кто-то же должен применять разрешения и более широкие политики governance. Недостаточно просто сказать: «Мы стандартизировали табличный формат».
Каким-то образом нужно гарантировать, что всё в порядке. Так какие сервисы нужны, чтобы всё было в порядке, будь то поддержка транзакций, разрешения или governance в широком смысле слова? Что нужно внедрить бок о бок с этими открытыми данными, чтобы все могли ими пользоваться?
Я считаю, что средства контроля доступа — это одно из самых больших белых пятен. Когда экосистема Hadoop переехала в облако и начала использовать S3 и другие объектные хранилища, я стал относить к ней и озера данных. Так вот, механизм доступа — это большой пробел у озер и хранилищ с общим доступом к данным в целом. Пару слов на правах рекламы: это как раз то, чем занимается моя компания Tabular. Мы создаем независимую платформу данных, которая обеспечивает их безопасность, что бы вы ни использовали для доступа к ним — от процесса Python до Starburst. Это действительно важно. Если у вас взаимосвязаны уровень хранилища и уровень обработки запросов, запрос поступает на уровень обработки, потому что этот уровень понимает запрос и может ответить: «Вы пытаетесь использовать столбец, к которому у вас нет доступа». В более современной шестой платформе данных, которую мы сейчас обсуждаем, предоставление доступа должно переместиться на уровень хранилища. Так мы сможем действительно обеспечить универсальную работу этих механизмов контроля доступа без синхронизации между Starburst, Snowflake, Microsoft, Databricks и другими решениями, используемыми на уровне обработки запросов.
Какую роль в появлении шестой платформы данных сыграют стандарты Iceberg?
Вполне возможно, шестая платформа данных не будет каким-то отдельным продуктом.
Скорее всего, все нынешние поставщики стандартизируют определенные компоненты.
Если Snowflake и Databricks смогут договориться насчет Iceberg, скорее всего, это станет стандартом для всех.
Остается, конечно, стандартизировать еще представления, шифрование, взаимодействие с каталогами и т. п.
Шестая платформа данных — это когда все участники обеспечивают совместный доступ к информации в контексте одной архитектуры.
«Шестая платформа данных» — вполне подходящее название. На самом деле никто пока не знает, как она будет называться. Нельзя пока точно сказать, будет ли это отдельный продукт. Суть в том, что пять компаний, о которых вы говорили, плюс Oracle, IBM и другие компании стандартизируют определенные компоненты в рамках этой архитектуры.
Разумеется, будет одно общее хранилище. Вполне возможно, что именно Iceberg и станет этим форматом общего хранилища как наиболее распространенный формат. Если Databricks и Snowflake смогут о чем-то договориться, то это будет стандарт де-факто. Нам еще предстоит увидеть, о чем мы сможем договориться по мере формирования всё новых стандартов в сообществе Iceberg.
Мы занимаемся созданием общих представлений, стандартизированного шифрования, способов взаимодействия с каталогом вне зависимости от того, кто им владеет или работает с ним. Это будут действительно важные компоненты шестой платформы, ведь это будет некий сплав продуктов всех этих компаний, и совместный доступ к данным станет частью архитектуры.
Но многие платформы еще не доросли до концепции «Uber для всех». Может быть, это подход на перспективу и надо подождать еще несколько лет.
Мы обсуждали выразительность графовых баз данных и гибкость реляционных запросов. Мы видели, что Fauna может в реальном времени синхронизировать данные в нескольких документах. Из-за всех этих моментов нам кажется, что у кого-то из пяти компаний появятся новые соперники. Как поддерживать целостность данных, какой уровень стека за это отвечает? И вслед за этим возникает еще целый ряд вопросов. Виден ли сейчас путь увеличения транзакционной целостности, или транзакционная модель, которая сможет в реальном времени работать с данными, поступающими в разные таблицы? Чтобы можно было направить запрос в реальном времени, который будет учитывать исторический контекст. Кто обеспечивает целостность данных и, в сущности, «целостность доступа»? Где границы и есть ли они? Всё это будет в диспетчере хранилища?
Сначала о транзакциях. У форматов открытых данных, к которым я отношу только Delta и Iceberg, в сущности, есть транзакционный протокол, позволяющий безопасно модифицировать данные, не задумываясь, что вдруг кто-то в этот момент тоже меняет их или читает. Это умеют делать два Open-Source-формата. Так что эту проблему уже решили. Но тогда мы получаем другую проблему: они делают это, записывая всё в объектное хранилище и разъединяя версии, а это, по сути, процесс пакетной обработки. И вот тут возникает несоответствие между современной потоковой обработкой, которая является микропакетной потоковой операцией, и эффективностью. Поскольку в каждый момент нужно выполнять commit в таблицу, а каждый отдельный commit подразумевает больше работы.
Чтобы приблизиться к реальному времени, вы просто делаете больше работы и усложняете этот процесс. Мы наблюдаем по крайней мере линейный, а может быть, и экспоненциальный рост затрат по мере приближения к режиму реального времени. В силу базовых экономических показателей нецелесообразно в долгосрочной перспективе делать продукт, который всегда будет работать в реальном времени. Это извечная корреляция между задержкой и пропускной способностью. Если вам нужна низкая задержка, то у вас будет более низкая пропускная способность. Если вы согласны на большую задержку, то у вас выше пропускная способность и, соответственно, выше эффективность. Так что создавать потоковые приложения и приложения, в которые постоянно поступают данные, конечно, станет легче.
Думаю, это позволит создать надежное хранилище для шестой платформы данных. Интересно будет понаблюдать за взаимодействием между потоковыми приложениями, работающими в реальном времени, и слиянием этих данных и данных из озера или хранилища.
Помимо Tabular и Iceberg, какие компоненты могут обеспечить ценность, сопоставимую с ценностью интегрированной системы: пример Netflix
Uber описывали свой подход к этой корреляции не как к уникальному набору приложений, а как к сочетанию разных элементов данных — пассажирам, водителям, ETA, тарифам за проезд и т. п. Это своего рода отраслевые приложения 4.0. Да, потенциал есть, но всегда казалось, что его нужно применять к мейнстримным компаниям.
Помимо Iceberg и Tabular, какие компоненты поддержат свободу выбора и модульность в этом мире? Каковы значимые моменты для современных платформ данных? Как будут развиваться приложения, поддерживающие модель реального мира? Если вам нужна система достоверных данных в реальном времени, вы будете использовать операционную базу данных. А если вам нужна система исторических достоверных данных, это будет отдельная аналитическая система.
Мы пытаемся ликвидировать разрозненность данных между платформами. По сути, всё крутится вокруг некоторых механизмов, поддерживающих работу приложений в режиме реального времени, приложений с задержкой в доли секунды. Так что не думаю, что в скором времени нам удастся объединить эти миры. Но я глубоко верю в удобство использования. Так что на самом деле нам надо не столько объединить эти миры, сколько сделать так, чтобы казалось, будто нам это удалось. Отдельные системы могут создавать сценарии использования, преодолевающие эту границу. Это классически удалось Netflix с помощью логов, которые поступали из наших приложений. Мы получали телеметрические данные и логи из выполняемых приложений, на которых держится платформа Netflix во всём мире. Нам нужен доступ к этой информации с задержкой в миллисекунды. Iceberg не работал в реальном времени и не мог это обеспечить. Мы всё хранили в памяти, потому что это был наиболее разумный подход. Мы по-другому работали с приложениями с историческими данными. И у пользователя не возникало никаких неудобств. Мы отправляли запрос к выполняющемуся приложению и получали свежие логи с задержкой в миллисекунды. Но если надо, можно было получить и данные двухлетней давности.
Как скрыть различия между актуальными и ретроспективными данными для удобства работы разработчика?
В Netflix бэкенд приложения отвечал за получение всех логов почти в реальном времени, а также за управление перемещениями в Iceberg исторических и хранящихся в памяти актуальных данных. Мы потратили много сил на создание приложения по работе с данными, которое было бы совместимым с обоими хранилищами. Так что бэкенд приложения отвечал за получение всех логов почти в реальном времени, за их хранение и за перемещение между памятью и Iceberg.
В Iceberg мы разделяем технические метаданные, необходимые для корректных операций чтения и записи в этом формате, и метаданные более высокого уровня. К последним мы относим информацию о бизнес-операциях, средства контроля доступа, нашу политику RBAC и так далее. Это более высокий уровень, который мы не включаем даже в Open-Source-проект Iceberg. Технических метаданных достаточно для управления Open-Source-проектом. Нам нужно поверх этого проекта создавать структуры более высокого уровня.
Простота интегрированных систем vs модульность открытых решений: взаимодополнение или взаимоисключение
Этот рисунок — попытка проиллюстрировать, что сейчас происходит на рынке. Слева показано мировоззрение, в основе которого устройства или платформы данных. Это может быть Redshift или Snowflake. Тогда, чтобы добиться простоты и производительности, которые требовались заказчику, современные технологии предполагали интеграцию всех элементов
Но по мере того как технологии становятся более зрелыми, мы движемся к модульным конструкциям. И именно хранилища становятся модульными в первую очередь. Теперь мы можем предложить стандартизированный интерфейс для таблиц, будь то Iceberg, Delta или Hudi. И Райан как раз говорит о том, что разрешения должны идти нога в ногу с этими изменениями. И сюда же прилагается некий объем поддержки транзакций.
Мы разбираем ранее интегрированную СУБД на части. Это не значит, что у вас обязательно должны быть все компоненты от разных поставщиков. Давайте просто вкратце их перечислим. Панель управления оркестрирует работу. Это может быть DBT, Dagster, Airflow или Prefect. Самая сложная часть — это оптимизатор запросов, которому можно просто сказать, что вам нужно, а он сам придумает, как это сделать. И это тоже часть Snowflake и Azure Synapse, Fabric или Databricks, которые создали собственные Databricks SQL, отдельно от Spark execution engine. Механизм выполнения — это своего рода SDK не-SQL«ного типа получения данных. Именно таким был исходный механизм Spark. Сейчас у Snowflake есть API, но мы полагаем, что они делают собственный оптимизатор запросов.
Есть уровень метаданных, который выходит за рамки просто технических метаданных. В сущности, мы как раз обсуждали с Райаном, что с их помощью мы описываем data estate и всё, что нужно знать о том, как всё это вместе работает. Это похоже на AtScale с его семантическим слоем. А еще есть Atlan, Alation, Collibra, своего рода каталоги для пользователей и администраторов.
Мы начинаем разбирать на части то, что когда-то было СУБД. Так, в свое время Snowflake разобрали на части решения Oracle, в которых вычислительные ресурсы и хранилище были объединены. Они отделили вычислительные ресурсы от хранилища, а теперь, по мнению Райана, мы разделяем вычислительные ресурсы на множество компонентов, чтобы использовать разные инструменты для разных рабочих нагрузок и чтобы все они работали с общим data estate, когда данные не встроены и не находятся в ловушке одной платформы или одного механизма.
Заключительные мысли
Нам нужна и общая модульность, и простота. Всем нужны модульные системы, это совершенно ясно. Простота всегда идет следом. Базы данных — это как источник электропитания для приложений. У них всегда был разрыв между кодом и тем, кто и что контролирует. А мы просто добавляем уровни.
Мы довольно четко представляем себе границы между базой данных и приложением поверх нее, это отлаженный процесс. Мы снова разделяем уровни, на этот раз хранилища и вычислительных ресурсов. Но нам однозначно нужно и то и другое. И вот здесь на первый план выходят вещи, которыми занимается сообщество Apache Iceberg. Мы стандартизируем взаимодействие с каталогами, обеспечиваем безопасность этого уровня и говорим: «Вот так можно сохранять идентичность при пересечении границы».
А еще мы перемещаем сервисы базы данных с уровня запросов на уровень хранилища. А за модульностью должна последовать простота, например решения с использованием OAuth. Мы продвигаем инновационное использование OAuth для подключения механизма обработки запросов к уровню хранилища, чтобы можно было просто щелкнуть кнопкой мыши и получить ответ администратора: «Да, я готов предоставить Starburst доступ к этому хранилищу данных».
Эта простота использования — единственное, что поможет реализовать модульность. Большая ошибка экосистемы Hadoop заключалась в нехватке простоты и удобства. Мы смогли ощутить ее преимущества, только создавая уровень за уровнем и повышая зрелость продуктов, пока, наконец, не появилась простота. Так что это неотъемлемая часть пути, которым мы идем.
