Как спроектировать уровень хранения для требований к хранению структурированных данных

Автор Чжоу Чжаофэн по прозвищу Мулуо в Alibaba.

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

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

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

• Ориентированность на бизнес: основная логика бизнес-взаимодействия завершена.
• Крупномасштабный: использование распределенных технологий и технологий больших данных соответствует требованиям роста бизнеса и накопления данных.
• Интеллектуальность: использование технологии искусственного интеллекта (ИИ) повышает ценность данных и стимулирует бизнес-инновации.

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

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

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

Архитектура системы данных

Основные компоненты

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

Система приложений реализует основную бизнес-логику приложений и обрабатывает бизнес-данные или метаданные приложений. Система данных обобщает и обрабатывает бизнес-данные и другие данные и интегрирует их с бизнес-аналитикой (BI), рекомендациями или системами контроля рисков.

Архитектура системы содержит следующие общие основные компоненты:

• Реляционная база данных: она хранит данные для основных бизнес-операций и обрабатывает данные транзакций и является основным хранилищем данных прикладной системы.
• Высокоскоростной кэш: он кэширует результаты сложных операций или требует больших затрат на повтор для ускорения доступа.
• Поисковая система: предоставляет сложные запросы на основе критериев и полнотекстовый поиск.
• Очередь: синхронизирует обработку данных и объединяет восходящие и нисходящие компоненты для обмена данными в реальном времени. Он использует несколько основных компонентов для восходящих и нисходящих взаимосвязей между разнородными системами хранения данных, например, взаимосвязь данных между системами баз данных и системами кэширования или поисковыми системами. Кроме того, он использует очереди для извлечения данных в реальном времени и архивирования в реальном времени из онлайн-хранилища в автономное хранилище.
• Хранилище неструктурированных больших данных: оно хранит большое количество неструктурированных данных, таких как изображения или видео, и поддерживает онлайн-запросы или доступ к данным офлайн-вычислений.
• Структурированное хранилище больших данных: это относится к онлайн-базе данных, которая больше подходит для онлайн-офлайн-соединений и обеспечивает запись данных с высокой пропускной способностью и крупномасштабное хранение данных. Это помогает линейно расширить хранилище и производительность запросов. В структурированном хранилище больших данных хранятся нереляционные данные для онлайн-запросов или архивные исторические данные для реляционных баз данных, чтобы соответствовать требованиям крупномасштабного и линейного расширения. Он также хранит данные, записанные в режиме реального времени, для автономного анализа.
• Пакетные вычисления: это анализ неструктурированных данных и структурированных данных. Пакетные вычисления подразделяются на интерактивный анализ и автономные вычисления. Автономные вычисления выполняют сложный анализ крупномасштабных наборов данных, тогда как интерактивный анализ выполняет анализ в реальном времени наборов данных среднего масштаба.
• Потоковые вычисления: выполняется потоковый анализ неструктурированных и структурированных данных для создания представлений в реальном времени с малой задержкой.

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

Система производных данных

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

Компоненты хранилища для разных целей имеют восходящие и нисходящие каналы передачи данных разных типов. Вы можете классифицировать эти компоненты на основное хранилище и вторичное хранилище. Два типа хранилища предназначены для разных целей:

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

На этом этапе очень важно ответить на несколько важных вопросов: почему доступно первичное и вторичное хранилище? И возможно ли хранить, читать и записывать данные унифицированным образом, чтобы удовлетворить требования всех сценариев?

В настоящее время данные нельзя хранить, читать и записывать унифицированным образом. Механизм хранения поддерживает несколько технологий, в том числе хранилище строк или столбцов, B+Tree или дерево слияния с логической структурой (LSM-дерево), хранение неизменяемых данных, часто обновляемых данных или данных разделения на основе времени, а также проектирование для высокой производительности. -скорость случайного запроса или сканирования с высокой пропускной способностью. Более того, продукты баз данных делятся на категории TP и AP. Хотя в направлении гибридной транзакционно-аналитической обработки (HTAP) базовое хранилище по-прежнему разделено на хранилище строк и хранилище столбцов.

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

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

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

Общие режимы репликации данных, показанные на предыдущем рисунке, описываются следующим образом:

• Многократная запись на прикладном уровне: это самый простой метод реализации с наименьшей зависимостью. В этом режиме данные сначала записываются в основное хранилище, а затем во вторичное хранилище в коде приложения. Однако этот режим не очень надежен. Таким образом, он обычно применяется в сценариях, где требования к надежности данных не высоки. У этого режима много проблем. Во-первых, он не обеспечивает согласованности между данными в первичном и вторичном хранилище и не устраняет сбои записи данных. Во-вторых, потребление, связанное с записью данных, накапливается на уровне приложения, что увеличивает сложность кода и вычислительную нагрузку на уровне приложения, что в конечном итоге делает архитектуру с плохой развязкой. И, в-третьих, масштабируемость этого режима плохая, а логика синхронизации данных зафиксирована в коде, что затрудняет гибкое добавление вторичного хранилища.
• Асинхронная репликация очереди: это широко используемая архитектура. Прикладной уровень асинхронизирует и разделяет запись производных данных в очереди. И в этой архитектуре данные записываются как в основное, так и во вторичное хранилище, и только вторичное хранилище является асинхронным. Первый режим должен разрешать асинхронную запись данных в основное хранилище. В противном случае будет использоваться только второй режим. Если вы используете второй режим, вы также столкнетесь с проблемами, аналогичными тем, которые возникают в модели множественной записи на уровне приложения. Прикладной уровень поддерживает множественную запись только в основное хранилище и очереди. Очереди решают проблемы множественной записи и масштабируемости вторичного хранилища.
• Технология Change Data Capture (CDC): записывает данные в первичное хранилище, которое затем синхронизирует данные во вторичном хранилище. Этот режим наиболее удобен для прикладного уровня, и вам нужно иметь дело только с основным хранилищем. Он использует технологию асинхронной репликации очереди для синхронизации данных из основного хранилища во вторичное хранилище. Однако основное хранилище должно поддерживать технологию CDC в этом режиме. Типичным примером является комбинированная архитектура MySQL и Elasticsearch. Данные Elasticsearch синхронизируются в файлах binlog MySQL, а binlog указывает на технологию CDC MySQL.

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

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

Хороший продукт использует архитектуру деривации данных для постоянного расширения своих возможностей, делая процесс деривации прозрачным и решая проблемы синхронизации данных, непротиворечивости и соотношения ресурсов. На самом деле, большинство технических архитектур используют производные архитектуры комбинаций продуктов и должны управлять синхронизацией и репликацией данных, например, комбинации MySQL с Elasticsearch и Hbase с Solr.

Самые большие проблемы с этими комбинациями:

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

Выбор компонентов хранилища

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

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

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

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

Окончательная тенденция архитектуры хранения данных выглядит следующим образом:

1. Данные должны быть многоуровневыми.
2. Данные должны храниться в службе хранилища объектов (OSS).
3. Унифицированный механизм анализа объединяет аналитические порталы и предоставляет единый язык запросов.

Структурированное хранилище больших данных

Позиционирование

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

Ключевые требования

• Крупномасштабное хранилище данных: структурированное хранилище больших данных позиционируется как централизованное хранилище. В качестве сводки онлайновых баз данных (в режиме больших широких таблиц) или ввода и вывода автономных вычислений структурированное хранилище больших данных должно поддерживать петабайты хранения данных.
• Возможность записи с высокой пропускной способностью: данные преобразуются из онлайн-хранилища в автономное хранилище с помощью инструмента ETL в режиме синхронизации T+1 или синхронизации в реальном времени. Структурированное хранилище больших данных должно поддерживать импорт данных из нескольких онлайн-баз данных, а также экспорт большого количества наборов результатов из механизма обработки больших данных. Следовательно, структурированное хранилище больших данных должно поддерживать запись данных с высокой пропускной способностью. Как правило, для оптимизации записи используется механизм хранения.
• Широкие возможности обработки запросов к данным. Структурированное хранилище больших данных в качестве вторичного хранилища для системы вывода данных требует оптимизации эффективных онлайн-запросов. Общие оптимизации запросов включают высокоскоростные кэши, случайные запросы с высокой степенью параллелизма и малой задержкой, сложные запросы с комбинированием полей и извлечение данных. Техническими средствами оптимизации запросов являются кэширование и индексирование, при этом поддержка индексирования диверсифицирована и для разных сценариев запросов предусмотрены разные типы индексов, например, вторичные индексы на основе B+Tree для запросов по фиксированным комбинациям, R-Tree или BKD. - Пространственные индексы на основе дерева для запросов местоположения или инвертированные индексы для запросов с несколькими полями и полнотекстового поиска.
• Разделение затрат на хранение и вычисления. В настоящее время разделение хранения и вычислений является популярной архитектурной реализацией. Для общих приложений трудно получить преимущества этой архитектуры. В облачных системах больших данных разделение хранения и вычислений полностью раскрывает свои преимущества. Самым большим преимуществом разделения хранения и вычислений в распределенной архитектуре является гибкий метод управления хранилищем и вычислительными ресурсами, который значительно улучшает масштабируемость хранения и вычислений. Для управления затратами затраты на хранение и вычисления разделяются только для продуктов, реализованных на основе архитектуры с разделением хранения и вычислений. Преимущество разделения затрат на хранение и вычисления более очевидно в системе больших данных. Например, объем хранения в структурированном хранилище больших данных будет увеличиваться по мере накопления данных, но объем записи данных относительно стабилен. Поэтому возникает потребность в постоянном расширении потребностей в хранении. Однако вычислительные ресурсы, необходимые для поддержки записи данных или анализа временных данных, относительно фиксированы и доступны по запросу.
• Возможность извлечения данных: Несколько компонентов хранения должны сосуществовать в полной архитектуре системы данных. В соответствии с различными требованиями к возможностям запросов и анализа вторичное хранилище необходимо динамически расширять в системе вывода данных. Следовательно, для структурированного хранилища больших данных возможность деривации, которая расширяет вторичное хранилище, также требуется для расширения возможностей обработки данных. Независимо от того, содержит ли компонент хранилища более качественные данные, возможности получения зависят от зрелой технологии CDC.
• Вычислительная экосистема: ценность данных должна быть извлечена с помощью вычислений. В настоящее время вычисления делятся на пакетные и потоковые. Требования к структурированному хранилищу больших данных следующие:

1. Он должен иметь возможность подключаться к основным вычислительным механизмам, таким как Apache Spark и Flink, в качестве входных или выходных данных.
2. Он должен иметь возможность извлечения данных для преобразования своих данных в данные, ориентированные на анализ, в формате столбцового хранилища и сохранения данных в системе озера данных.
3. Он должен предоставлять возможности интерактивного анализа, чтобы быстрее обнаруживать ценность данных.

Первое требование является самым основным, а второе и третье — бонусными предметами.

Продукты с открытым исходным кодом

В настоящее время HBase и Cassandra являются хорошо известными структурированными продуктами для хранения больших данных с открытым исходным кодом. Cassandra — лучший продукт модели широких столбцов в категории NoSQL, который широко используется за пределами Китая. Однако давайте сосредоточимся на HBase, так как он более популярен, чем Cassandra в Китае.

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

• Архитектура разделения хранения и вычислений: она основана на HDFS на базовом уровне. Разделенная архитектура поддерживает гибкое масштабирование хранилища и вычислений, а также совместное использование вычислительных ресурсов с вычислительными механизмами, такими как Spark, для снижения затрат.
• LSM Storage Engine: предназначен для оптимизации записи и обеспечивает запись данных с высокой пропускной способностью.
• Зрелая экосистема разработчиков и доступ к основным вычислительным механизмам: HBase — это продукт с открытым исходным кодом, который разрабатывался в течение многих лет. Сообщество разработчиков является зрелым и подключается к нескольким основным вычислительным механизмам.

Однако у HBase есть несколько серьезных недостатков, которые мы не можем игнорировать:

• Слабые возможности запросов: HBase обеспечивает эффективные однострочные случайные запросы и сканирование на основе диапазона. Используйте сканирование+фильтр для запроса по сложным сочетаниям условий. В противном случае сканируется вся таблица, что крайне неэффективно. Phoenix of HBase предоставляет вторичный индекс для оптимизации запросов. Однако, как и вторичный индекс MySQL, вторичный индекс HBase используется для оптимизации запросов только в том случае, если критерии запроса соответствуют крайнему левому принципу сопоставления. Количество условий запроса, которые необходимо оптимизировать, ограничено.
• Слабые возможности получения данных: как упоминалось выше, технология CDC является основной технологией, которая поддерживает систему получения данных. HBase не реализует технологию CDC. Репликация HBase имеет возможность CDC. Однако это всего лишь механизм синхронизации данных между первичным и вторичным хранилищами в HBase. Некоторые компоненты с открытым исходным кодом, такие как Lily Indexer для синхронизации с Solr, используют свои встроенные возможности репликации, чтобы попытаться расширить технологию CDC HBase. Однако жаль, что эти компоненты не отвечают основным требованиям, таким как сохранение последовательности данных и гарантия согласованности в конечном итоге, требуемые технологией CDC, основанной на теоретическом и институциональном анализе.
• Высокая стоимость. Как упоминалось выше, одним из ключевых требований к структурированному хранилищу больших данных является разделение затрат на хранение и вычисления. Стоимость HBase зависит от стоимости ядра ЦП и стоимости дискового хранилища для вычислений. В режиме развертывания, основанном на фиксированном соотношении физических ресурсов, нельзя уменьшить минимальное соотношение ресурсов ЦП и ресурсов хранения. То есть стоимость ядра ЦП увеличивается соответственно с объемом памяти, но не рассчитывается на основе фактических вычислительных ресурсов. Только облачный бессерверный сервис обеспечивает полное разделение затрат на хранение и вычисления.
• Сложный O&M: HBase — это стандартный компонент Hadoop с основными зависимостями, Zookeeper и HDFS. HBase O&M не работает без профессиональной команды O&M.
• Плохая возможность обработки проблем с горячими точками: таблица HBase секционирована в режиме секционирования по диапазону. По сравнению с режимом разбиения по хешу, режим разбиения по диапазонам имеет самый большой недостаток, связанный с серьезными проблемами с горячими точками. HBase предоставляет большое количество передовых методов, помогающих разработчикам избегать горячих точек при разработке ключей строк для таблиц, таких как использование хэш-ключей или таблиц с солью. Однако эти два режима обеспечивают равномерное распределение данных, но не гарантируют равномерную популярность доступа к данным. Популярность доступа зависит от бизнеса. Требуется автоматический механизм, который разделяет или перемещает регион в зависимости от популярности.

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

Облачное хранилище столов Alibaba

Tablestore — это структурированный продукт для хранения больших данных, разработанный Alibaba Cloud. Для получения дополнительной информации посетите официальный сайт и прочитайте соответствующее руководство. Принцип проектирования Tablestore учитывает требования к структурированному хранению больших данных в системе данных, а также разрабатывает и реализует некоторые отличительные особенности, основанные на принципе построения системы деривации данных.

Принцип дизайна

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

• Архитектура, разделенная хранилищем и вычислениями: используется архитектура, разделенная хранилищем и вычислениями, с базовым уровнем, основанным на распределенной файловой системе Apsara, которая является основой для разделения затрат на хранение и вычисления.
• LSM Storage Engine: LSM и B+Tree — два основных механизма хранения. LSM специально оптимизирует запись данных с высокой пропускной способностью и эффективно поддерживает разделение горячих и холодных данных.
• Форма бессерверного продукта. Наиболее важным фактором разделения затрат на основе архитектуры, разделенной на системы хранения и вычисления, являются бессерверные услуги. Только бессерверные услуги обеспечивают разделение затрат на вычислительные ресурсы хранилища. В системе больших данных структурированное хранилище больших данных обычно требует регулярного крупномасштабного импорта данных из онлайновых баз данных или автономных вычислительных механизмов. Структурированное хранилище больших данных требует достаточной вычислительной мощности для достижения высокой пропускной способности записи в этом случае, тогда как в обычных случаях требуется лишь небольшая вычислительная мощность. Поэтому вычислительные ресурсы должны быть достаточно эластичными. Кроме того, в системе вывода данных первичное хранилище и вторичное хранилище обычно представляют собой гетерогенные механизмы, и их возможности чтения и записи различаются. В некоторых сценариях необходимо гибко настроить соотношение основного хранилища и вторичного хранилища. В этом случае ресурсы хранения и вычислений должны быть эластично регулируемыми.
• Возможности запросов на основе индексов: Механизм LSM имеет недостатки в возможностях запросов и требует индексов для оптимизации запросов. Для разных сценариев запросов требуются разные типы индексов. Поэтому Tablestore предоставляет различные индексы для удовлетворения требований запросов данных в различных типах сценариев.
• Технология CDC: Технология CDC в Tablestore называется Tunnel Service, которая поддерживает подписку на полные и добавочные данные в реальном времени и легко интегрируется с механизмом потоковых вычислений Flink для потоковых вычислений табличных данных в реальном времени.
• Вычислительная экосистема с открытым исходным кодом: Tablestore подключается не только к вычислительным механизмам, разработанным Alibaba Cloud, таким как MaxCompute и Data Lake Analytics (DLA), но и к основным вычислительным механизмам Flink и Spark без необходимости переноса данных.
• Интеграция потоковых и пакетных вычислений: Tablestore подключается к Spark. Это позволяет Spark выполнять пакетные вычисления для полных данных в таблице и использует технологию CDC для взаимодействия с Flink для потоковых вычислений для новых данных в таблице, реализуя интеграцию пакетных и потоковых вычислений.

Возможности хранилища таблиц

1. Диверсифицированные индексы

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

2. Туннельное обслуживание

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

Архитектура обработки больших данных

Архитектура обработки больших данных, часть архитектуры системы данных, разрабатывалась в течение многих лет и содержит некоторые базовые идеи проектирования для базовых архитектур, таких как наиболее перспективная архитектура Lambda. Лямбда-архитектура является относительно базовой архитектурой с некоторыми дефектами, на основе которых постепенно внедряются новые архитектуры, такие как Kappa и Kappa+, для решения некоторых проблем в лямбда-архитектуре. Tablestore объединяется с вычислительным движком, основанным на технологии CDC, и создает новую архитектуру Lambda Plus, основанную на архитектуре Lambda. На следующем рисунке показана архитектура Lambda Plus.

Основные идеи архитектуры Lambda заключаются в следующем:

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

Основанный на туннельном сервисе Tablestore, Tablestore полностью интегрирован с Blink в качестве источника потока, затемнения и приемника Blink. Давайте кратко рассмотрим основы архитектуры Lambda Plus.

• В архитектуре Lambda Plus данные должны записываться только в Tablestore. Платформа потоковых вычислений Blink напрямую считывает обновленные данные в таблицах в режиме реального времени через API Tunnel Service без необходимости записи в двойную очередь или самостоятельной реализации синхронизации данных.
• Что касается хранилища, архитектура Lambda Plus напрямую использует Tablestore в качестве основного набора данных. Tablestore поддерживает чтение и запись обновлений с малой задержкой в ​​онлайн-системах и предоставляет функции индексирования для эффективных запросов и извлечения данных, что приводит к высокому использованию данных.
• С точки зрения вычислений, архитектура Lambda Plus использует интегрированный вычислительный движок Blink для пакетной обработки потоков для унификации кода пакетной обработки потоков.
• На уровне представления Tablestore предоставляет диверсифицированные индексы, позволяющие свободно комбинировать несколько индексов для удовлетворения требований запросов в различных сценариях.

Резюме

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

Оригинальный источник: