#BigData #HBase
⭕️Сегодня рассмотрим, как выполняются операции чтения и записи в Apache HBase, а также с помощью каких приемов можно их ускорить.
Как рассчитать оптимальное количество регионов в таблице, зачем отключать версионирование, почему размер ключа строки должен быть небольшим и еще 7 полезных лайфхаков для администратора HBase-кластера
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/best-practices-to-optimize-hbase.html

#bigdata #hbase #обработкаданных #статьи
🔥Горячие точки в Apache HBase и 7 способов их устранения

Apache HBase представляет собой колоночно-ориентированное мультиверсионное хранилище типа key-value поверх HDFS и обеспечивает возможности Google BigTable для Hadoop.
Как и другие NoSQL-базы, HBase использует интересные проектные решения относительно хранения данных.
Данные в HBase хранятся в таблицах, проиндексированных первичным ключом (RowKey), для каждого из которых может иметься неограниченный набор атрибутов (колонок).

При создании таблицы записей следует учитывать аспекты, которые влияют на производительность HBase:

✔️Количество регионов на таблицу записей, т.е. диапазона записей, соответствующих определенному диапазону первичных ключей, идущих подряд друг за другом
✔️Дизайн ключа строки, т.е. как создается уникальный идентификатор (UUID)
✔️Количество групп колонок
✔️Разделение
✔️Долговечность

Некорректная настройка какого-либо из этих элементов снизит производительность загрузки данных. Также могут возникнуть горячие точки (hotspotting), когда только один из узлов кластера загружен (высокая загрузка ЦП), а остальные простаивают.

Горячие точки в HBase случаются из-за архитектурных особенностей хранения данных в этой NoSQL-СУБД, т.е. неправильного дизайна ключа строки.
Строки в HBase сортируются лексикографически по ключу строки. Этот дизайн оптимизирован для сканирования, позволяя хранить связанные строки или строки, которые будут считываться вместе. Поэтому плохо спроектированные ключи строк приводят к возникновению горячих точек.
Чтобы избежать этого, следует спроектировать ключ строки так, чтобы данные равномерно распределялись по всем регионам на всех узлах кластера HBase. При этом ключи строк надо определить так, чтобы строки, которые действительно должны находиться в одном и том же регионе, находились в одном регионе, но в целом данные записывались в несколько регионов кластера.

Как это сделать, рассмотрим далее - «7 способов предотвратить hotspotting»
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/what-is-hbase-hotspotting-and-how-to-avoid-it-7-ways.html

#bigdata #HBase #статьи
✅Плюсы Apache HBase для kNN-алгоритмов
Напомним, Apache HBase является колоночно-ориентированной мультиверсионной NoSQL-СУБД типа key-value. Она работает поверх HDFS и обеспечивает возможности Google BigTable для Hadoop. Благодаря колоночно-ориентированной структуре хранения данных, Apache HBase работает очень быстро. А возможности этой СУБД эффективно обрабатывать огромные объемы данных смягчают недостатки kNN-метода, который изначально не предназначен для работы с большими выборками.
Запуск kNN-алгоритмов на данных в HBase поможет найти наиболее похожие элементы, что пригодится в рекомендательных и AML-системах (Anti-Money Laundering), а также в задачах обработки естественного языка, распознавания изображений, классификации текстов и анализе временных рядов.
Благодаря распределенному характеру HBase, запускаемые на ней kNN-алгоритмы становятся высокопроизводительными и выгодными с экономической точки зрения. Также эти аналитические приложения отлично масштабируются, могут работать с огромными объемами данных и сложными запросами, которые в Apache HBase выражаются не через SQL-инструкции, а в виде кода MapReduce.
Повысить эффективность работы kNN-алгоритмов в Apache HBase помогут следующие рекомендации:
❗️использовать оптимизированные структуры данных, такие как деревья, чтобы улучшить точность вычислений
❗️добавить предварительное вычисление расстояний, чтобы сократить время выполнения программы
❗️распараллелить вычисления между несколькими ядрами ЦП или узлами кластера
❗️выбор наилучшую метрику расстояния, релевантную вычисляемому типу данных
❗️настроить гиперпараметры алгоритма, задав оптимальное значение k. Если количество соседей для алгоритма kNN слишком велико, может случиться переобучение модели и рост вычислительных затрат. Если количество соседей слишком мало, точность алгоритма будет слишком мала из-за зашумления данных.
❗️включить кэширование промежуточных результатов, чтобы повторно использовать их в сложных вычислениях, сокращая время пересчета расстояний между точками данных.

@BigDataSchool_ru
https://www.bigdataschool.ru/blog/knn-algorithm-on-data-in-hbase-for-machine-learning.html

#DataScience #HBase #статьи
Как сохранить данные из памяти Memgraph на диск с GQLAlchemy
Напомним, Memgraph — это высокопроизводительная графовая СУБД с открытым исходным кодом, которая хранит и обрабатывает данные в памяти. Потребление памяти для хранения графа в Memgraph зависит от множества переменных, но это можно оценить. Пустой экземпляр Memgraph в Ubuntu x86 потребляет около 75 МБ памяти из-за базовых накладных расходов во время выполнения. После загрузки набора данных потребление памяти возрастает до 260 МБ. Во время активной работы графовой СУБД память используется для хранения графа и выполнения запросов к нему. Потребление памяти для выполнения запроса монотонно увеличивается во время выполнения и освобождается после его завершения. Рекомендуется иметь в два раза больше оперативной памяти, чем объем, который занимает фактический набор данных графа.
Впрочем, хранить данные в памяти не всегда удобно, поскольку размер ОЗУ всегда ограничен. Поэтому имеет смысл хранить на диске свойства графа, которые напрямую не задействованы в графовых алгоритмах. Для этого в Memgraph есть Python-библиотека с открытым исходным кодом GQLAlchemy.
GQLAlchemy представляет собой средство сопоставления графов и объектов (Object Graph Mapper, OGM), обеспечивая связь между объектами графовой СУБД и Python. Помимо Memgraph, GQLAlchemy также поддерживает и Neo4j. OGM позволяет разработчику вместо запросов Cypher писать объектно-ориентированный код, который OGM автоматически преобразует. На практике это очень удобно, поскольку в больших графах есть узлы с множеством метаданных, которые не используются в графовых вычислениях. Графовые СУБд вообще не очень эффективно работают с большими строками или Parquet-файлами. Обойти это ограничение можно, используя отдельную реляционную СУБд или NoSQL-хранилище типа key-value для связи больших свойств с идентификатором узла. Это простое решение легко реализовать, но сложно поддерживать. Вместо этого проще использовать библиотеку GQLAlchemy, которая с версии 1.1 позволяет определить, какие свойства хранить в графовой базе данных, а какие — в постоянном хранилище на диске. Это можно задать однократно в определении модели и больше не беспокоиться о том, правильно ли сохранены или загружены свойства из нужного источника.
Библиотека GQLAlchemy построена на основе Pydantic и обеспечивает моделирование объектов, проверку, сериализацию и десериализацию данных. Она позволяет определить классы Python, которые сопоставляются с объектами графа, такими как узлы и отношения в графовой базе. Каждый такой класс имеет свойства или поля, содержащие данные об объектах графа.
Таким образом, граф будет занимать меньше места в памяти, а графовые алгоритмы будут работать быстрее.
Далее поговорим про персистентность Redis.
@BigDataSchool_ru
https://bigdataschool.ru/blog/how-to-save-data-from-memory-to-disk-in-memgraph-and-redis.html