введение
Привет всем, яChinaManor, В дословном переводе означает китайский кодовый фермер. Надеюсь, я смогу стать асфальтоукладчиком на пути национального возрождения, культиватором в области больших данных и обычным, но не посредственным человеком.
Серия статей «Быстрое понимание» посвящена быстрому началу работы и освоению нового компонента больших данных, чтобы помочь новичкам понять технологию больших данных.
Портал статей:
Статья, которая поможет вам быстро начать работу с Docker
Быстрый старт Hbase (установка и развертывание)
Это вторая часть серии для быстрого понимания: Краткое понимание того, что такое Куду.
Представляем Куду
В последние два года KUDU все шире используется на платформах больших данных.В архитектурах больших данных Alibaba, Xiaomi, NetEase и других компаний,
КУДУ имеет незаменимый статус.
Введение
До Куду большие данные в основном хранились двумя способами:
Статические данные:
Механизм HDFS используется в качестве механизма хранения, который подходит для сценариев анализа больших данных в автономном режиме с высокой пропускной способностью;
Ограничения таких сохраненных данных не могут быть прочитаны случайным образом;
Динамические данные:
Использование HBase и Cassandra в качестве механизмов хранения подходит для произвольного чтения и записи сценариев больших данных;
Ограничением этого типа хранилища является то, что пропускная способность пакетного чтения значительно уступает HDFS, что не подходит для сценариев пакетного анализа данных;
Из приведенного выше анализа видно, что два типа данных совершенно различны с точки зрения методов хранения, что приводит к совершенно разным сценариям использования, но в реальных сценариях
Границы могут быть не столь четкими.Что же выбрать перед лицом сценариев больших данных, которые требуют как случайного чтения и записи, так и пакетного анализа?
В этом сценарии один механизм хранения не может удовлетворить бизнес-требованиям, и для удовлетворения этого требования необходимо сочетание нескольких инструментов для работы с большими данными.
Как показано на рисунке выше, данные записываются в HBase в режиме реального времени, и обновления данных в реальном времени также выполняются в HBase.Чтобы соответствовать требованиям OLAP,
Регулярно (обычно T+1 или T+H) записывайте данные HBase в виде статических файлов (например, Parquet) и импортируйте их в механизм OLAP (например:
HDFS). Эта архитектура может удовлетворять сценариям, требующим произвольного чтения и записи, а также поддерживает анализ OLAP, но имеет следующие недостатки:
Структура сложная. С архитектурной точки зрения потоки данных между HBase, очередью сообщений и HDFS включают слишком много ссылок и затрат на эксплуатацию и обслуживание.
очень высоко. Кроме того, каждая ссылка должна обеспечивать высокую доступность, и необходимо поддерживать несколько копий, а также существует определенная трата места для хранения. Наконец
Данные хранятся в нескольких системах, что создает проблемы для политик безопасности данных и мониторинга.
Низкая своевременность. Экспорт данных из HBase в статические файлы осуществляется периодически, как правило, этот период составляет один день (или один час).
Сроки не очень высокие.
Трудно иметь дело с последующими обновлениями. В реальных сценариях данные всегда будут поступать с опозданием. Если данные были ранее загружены из HBase
При экспорте в HDFS сложно обрабатывать вновь поступившие измененные данные, одно из решений — применить новые изменения к исходным данным, а затем перезаписать их.
Опять же, но по высокой цене.
Чтобы решить эти проблемы вышеупомянутой архитектуры, Kudu появился на свет. Позиционирование Kudu — Fast Analytics on Fast Data,
Это механизм хранения больших данных, который поддерживает как произвольное чтение и запись, так и анализ OLAP.
Как видно из рисунка выше, KUDU — это компромиссный продукт, который уравновешивает случайность между HDFS и HBase.
производительность для машинного чтения и записи и пакетного анализа. С момента рождения KUDU можно проиллюстрировать точку зрения: разработка базовой технологии часто является вершиной
Технологии, ориентированные на бизнес и не связанные с бизнесом, скорее всего, будут воздушными замками.
Новое оборудование оборудования
Технология памяти (ОЗУ) развивается очень быстро, она становится все дешевле и больше. Количество клиентов Cloudera
Согласно отчетам, серверы, развернутые их клиентами, которые в 2012 году имели только 32 ГБ ОЗУ на узел, теперь выросли до
128 ГБ или 256 ГБ оперативной памяти. Обновления на устройствах хранения также очень быстрые, и нередко развертывание SSD на многих обычных серверах.
HBase, HDFS и другие инструменты Hadoop постоянно совершенствуются, чтобы приспособиться к обновлениям оборудования. Тем не мение,
По сути, HDFS была основана на GFS в 2003 году, а HBase — на BigTable в 2005 году. В то время узкое место системы в основном зависело от скорости основного диска.
Тратить. Когда скорость диска низкая, основной причиной недостаточной загрузки ЦП является узкое место, вызванное скоростью диска, когда скорость диска увеличивается
Позже коэффициент использования ЦП увеличивается, и ЦП часто становится в это время узким местом системы. HBase и HDFS были очень сложными из-за их возраста.
Модификации сделаны из базовой архитектуры, в то время как Kudu основан на новом дизайне, поэтому он может лучше использовать ОЗУ, ресурсы ввода-вывода и оптимизировать
Оптимизация использования ЦП.
Это можно понять следующим образом: по сравнению с предыдущей системой в Kudu снижена загрузка ЦП, улучшено использование операций ввода-вывода и более полно используется оперативная память.
Что такое Куду
Apache Kudu — это механизм хранения с открытым исходным кодом от Cloudera, который может одновременно обеспечивать произвольное чтение и запись с малой задержкой и эффективное распределение данных.
аналитические способности. Это новый компонент, который сочетает в себе возможности HDFS и HBase с новыми промежуточными компонентами хранения.
Kudu поддерживает горизонтальное масштабирование и совместим с современными популярными запросами и анализом больших данных, такими как Cloudera Impala и Apache Spark.
Инструменты тесно связаны.
Сценарии применения куду
Многие функции Kudu аналогичны HBase, который поддерживает запросы и изменение ключей индекса. Когда-то считалось, что Cloudera основана на HBase.
Внесите изменения, но вывод таков, что изменения в HBase очень велики, а модель данных Kudu и дисковое хранилище отличаются от HBase. HBase
Он сам по себе успешен для большого количества других сценариев, поэтому модифицировать HBase, скорее всего, будет неблагодарно. Наконец Cloudera решила разработать
совершенно новая система хранения.
1. Сильные характеристики для сканирования, так и для случайного доступа, чтобы помочь клиентам упростить комплекс Гибридные архитектуры (для тех составных сценариев, которые имеют как случайные доступа, так и сканирование пакетных данных)
2. Высокая эффективность ЦП для максимизации окупаемости инвестиций наших клиентов. создание в современных процессорах (сценарии с высокими вычислениями)
3. Высокая эффективность ввода-вывода для использования современного постоянного хранилища (с использованием высокопроизводительных устройств хранения
оборудования, в том числе используя больше памяти)
4. Возможность обновления данных на месте, чтобы избежать посторонней обработки и перемещения данных (Поддержка обновления данных, чтобы избежать повторной миграции данных)
5. Возможность поддержки кластеров с репликацией «активный-активный», охватывающих несколько центров обработки данных. в географически удаленных местах (поддерживает резервное копирование данных в режиме реального времени и запросы в разных регионах)
Куду Архитектура
Подобно HDFS и HBase, Kudu использует один мастер-узел для управления метаданными кластера и использует произвольные
Ряд узлов Tablet Server (сопоставимых для понимания роли RegionServer в HBase) используются для хранения фактических данных. может министерство
Разверните несколько главных узлов, чтобы повысить отказоустойчивость. Данные таблицы таблицы разделены на 1 или более планшетов, планшет развернут
Предоставлять услуги чтения и записи данных в Tablet Server.
модель данных
Модель данных KUDU аналогична модели данных традиционной реляционной базы данных.Кластер KUDU состоит из нескольких таблиц, и каждая таблица состоит из нескольких таблиц.
В таблице, состоящей из полей, должен быть указан первичный ключ, состоящий из нескольких (>=1) полей, как показано ниже:
Каждое поле в таблице KUDU строго типизировано, а не все поля, которые считаются байтами, как в HBase. Преимущество в том, что
Чтобы сэкономить место, кодируя разные типы данных по-разному. В то же время, поскольку сценарий использования KUDU — это OLAP-анализ,
Наличие типа данных также более удобно для инструментов последующего анализа.
Table (таблица): таблица table — это данные, хранящиеся на планшетном сервере подчиненного узла Kudu. Таблица имеет схему и заполнена
Локально упорядоченный первичный ключ. Таблица разделена на сегменты, называемые планшетами.
Планшет:
1), планшет — это непрерывный сегмент таблицы, планшет — это горизонтальная часть таблицы Куду, аналогичная гугловской.
Планшет Bigtable или регион HBase.
2) Каждый планшет хранит определенный непрерывный диапазон данных (ключей), причем диапазоны двух планшетов не будут пересекаться.
Все планшеты таблицы содержат все ключевые пробелы этой таблицы. с другими механизмами хранения данных или реляционными базами данных
Раздел (перегородка) аналогичен.
3), данный планшет является резервным для нескольких планшетных серверов и в любой заданный момент времени, где
Одна реплика является планшетом-лидером, а другие реплики — планшетами-ведомыми.
4) Каждый планшет одновременно имеет только одну копию лидера, эта копия предоставляет пользователям операции модификации, а затем результаты модификации
Результат синхронизируется с последователем.
5) Подписчик предоставляет только услугу чтения, а не услугу модификации. Протокол Raft используется между репликами для достижения высокого
Доступность, когда узел, на котором находится лидер, выходит из строя, последователи переизбирают лидера. Другой аспект протокола Raft
Одна роль заключается в реализации согласованности. Операция модификации лидера клиентом должна быть синхронизирована с узлами N/2+1.
Операция считается успешной.
Стратегия разделения
Подобно большинству механизмов хранения больших данных, таблицы KUDU разделяются по горизонтали, а таблицы KUDU разделяются по горизонтали и хранятся в нескольких разделах.
в таблетках. Однако, по сравнению с другими механизмами хранения, KUDU предлагает более богатые и гибкие стратегии разделения данных.
Разделение по диапазону, разделение в соответствии с диапазоном значений поля, HBase использует этот метод.
Пример 1: границ нет, данные разделены на 20150101 и 20160101, а данные разделены на три части
Пример 2: Граница [(2014-01-01), (2017-01-01)], разделенная на 2015-01-01 и 2016-01-01
Преимущество Range Partitioning заключается в том, что при пакетном чтении данных большую часть операций чтения можно превратить в одну и ту же табличку.
Последовательное чтение может повысить скорость чтения данных. И разделите в соответствии с диапазоном, очень удобно проводить расширение раздела.
Недостатком является то, что запись данных в одном и том же диапазоне будет приходиться на один планшет, давление записи высокое, а скорость низкая.
Разделение по хэшу, разделение в соответствии со значением хэша поля, Cassandra использует этот метод.
В следующем случае таблица метрик секционируется в соответствии с хэшем хоста и метрики, а данные записываются в четыре сегмента.
В отличие от Range Partitioning, запись данных будет равномерно распределена по каждому планшету из-за Hash-разделения.
, скорость записи высокая. Однако эта стратегия не подходит для сценариев последовательного чтения, поскольку данные разбросаны, а последовательное чтение требует
Данные в каждой табличке читаются и объединяются отдельно, пропускная способность низкая, а раздел Hash не справляется с расширением раздела.
KUDU позволяет пользователям указать правило разделения диапазона и несколько правил раздела Hash для таблицы, как показано на следующем рисунке:
Комбинация многоуровневых хеш-разделов, как показано на следующем рисунке:
Столбчатое хранилище
KUDU — это механизм хранения столбцов, и его методы хранения данных следующие:
Базы данных, хранящиеся в столбцах, очень подходят для сценариев OLAP, и их характеристики следующие:
Преимущества: при запросе небольшого количества столбцов меньше операций ввода-вывода и высокая скорость; высокая степень сжатия данных; это удобно для оптимизации производительности движка запросов: отложенная материализация, прямая Сжатые данные и векторизованное выполнение связанных операций.
Недостатки: производительность снижается при слишком большом количестве столбцов запроса (KUDU рекомендует, чтобы количество столбцов не превышало 300); не подходит для сценариев OLTP.
Общая структура
В КУДУ есть две роли:
Mater Server: отвечает за управление кластером, управление метаданными и другие функции.
Tablet Server: отвечает за хранение данных и предоставляет услуги чтения и записи данных.
Для достижения отказоустойчивости разделов, как и в случае с другими продуктами для работы с большими данными, для каждой роли в KUDU можно задать определенные параметры. Количество (3 или 5) экземпляров. Согласованность данных между репликами обеспечивается протоколом Raft. Протокол Raft похож на ZAB, оба Является инженерно упрощенной версией протокола Paxos.
На приведенной выше диаграмме показан кластер Kudu с тремя ведущими и несколькими планшетными серверами, каждый из которых поддерживает несколько серверов.
планшет. В нем показано, как использовать консенсус Raft, чтобы разрешить лидера и ведомого для главных и планшетных серверов.
Документация:Тяжелое чтение. Apache.org/docs/index. …
Кроме того, планшетный сервер может быть ведущим для одних планшетов и подчиненным для других планшетов. лидер с
Отображены золотым цветом, а подписчики — синим. Вот несколько основных понятий:
роль роль
Лидер Мастер-кластера, отвечающий за управление кластером, управление метаданными и другие функции
Младший брат в кластере Tablet Server отвечает за хранение данных и предоставляет услуги чтения и записи данных.
Сервер планшетов хранит таблицу планшетов и обслуживает планшеты клиентов.
Для данного планшета один планшетный сервер выступает в качестве ведущего, а другие планшетные серверы — в качестве ведущего.
Доработанный экземпляр этого планшета.
Только лидер обслуживает запросы на запись, тогда как лидеры или последователи обслуживают запросы на чтение для каждой службы.
Планшетный сервер может обслуживать несколько планшетов, а планшет может использоваться несколькими
Обслуживают планшетные серверы.
Таблица (table) Таблица — это данные, хранящиеся на планшетном сервере Kudu. Таблицы имеют схему и глобальный порядок
первичный ключ. Таблица разделена на сегменты, называемые планшетами.
Планшет Таблетка — это непрерывный сегмент стола, а планшет — это горизонтальная перегородка стола куду, аналогичная
Планшет для google Bigtable или регион для HBase. Каждая таблетка хранит определенное непрерывное
диапазон данных (ключ) и диапазон между любыми двумя табличками не пересекаются. Таблица всех планшетов
Содержит все ключевые пробелы этой таблицы. с другими механизмами хранения данных или реляционными базами данных
перегородка (раздел) аналогична. Данный планшет резервируется на нескольких планшетных серверах и
В любой момент времени одна из реплик считается планшетом-лидером. Любая реплика может читать
выборки для обслуживания и записи должны быть достигнуты между набором планшетных серверов, обслуживающих планшеты
последовательность.
Задача планшетного сервера очень тяжелая, он отвечает за все операции, связанные с данными, включая хранение, доступ, сжатие, а также
Отвечает за репликацию данных на другие машины. Из-за особой структуры Tablet server его задача слишком тяжелая, поэтому он имеет следующие ограничения:
Kudu поддерживает до 300 серверов, рекомендуется, чтобы количество серверов Tablet не превышало 100.
Рекомендуется, чтобы каждый планшетный сервер содержал не более 2000 планшетов (включая подписчиков).
Рекомендуется, чтобы каждая таблица содержала не более 60 планшетов (включая подписчиков) на каждом планшетном сервере.
Каждый сервер Tablet управляет до 8 ТБ данных
В идеале лидер планшета должен соответствовать одному ядру ЦП, чтобы обеспечить оптимальную производительность сканирования
Взаимодействие с клиентом Куду
Когда клиент KUDU взаимодействует с сервером, он сначала получает метаданные от главного сервера, а затем переходит к планшетному серверу.
Чтение и запись данных, как показано ниже:
Визуализатор куду
Как использовать Куду:Тяжелое чтение. Apache.org/docs/VELO…
Способ 1. Вы можете работать с таблицей Kudu через клиент Java, клиент C++ и клиент Python, но вам необходимо создать клиент и написать приложение.
программа;
Способ 2. Вы можете интегрировать Kudu и Spark через пакет Kudu-Spark и написать приложения Spark для работы с таблицами Kudu;
KuduContext, интегрирует объекты экземпляра контекста Kudu и инкапсулирует данные в виде RDD.
SparkSession, чтение данных из таблицы Kudu, инкапсулированных как DataFrame
Способ 3: Вы можете выполнять интерактивные операции с таблицей Kudu через оболочку Impala, поскольку в Impala 2.8 и выше
Интегрированные операции для Kudu.
Непосредственное определение данных таблицы Impala, хранящихся в Kudu, внутренняя интеграция
Сама платформа Kudu предоставляет команду kudu для управления кластером Kudu, расположенным в каталоге $KUDU_HOME/bin.
Kudu-Plus - это инструмент визуализации для Kudu, адреса GitHub:GitHub.com/X Чунгуан/…
Kudu-plus — это инструмент для визуального управления Kudu.Хотя Kudu представляет собой столбчатую базу данных, ее можно выразить в виде реляционного числа.
В некоторых случаях визуальное управление проще. KuduPlus включает манипулирование таблицами и данными
В качестве ограничений это может помочь лучше понять Куду. Особенности текущей версии перечислены ниже:
Адрес для скачивания: Ссылка:disk.baidu.com/is/1_v X0ww AI…Код извлечения: 7ltk
Суммировать
Выше приведено полное содержание платформы больших данных Kudu, если она вам полезна, вы также можетеобращать внимание~