Хранение вложенного HashMap в HBase
Прошу прощения за мое невежество, но я относительно новичок в HBase и не могу этого понять. Я хочу хранить следующие вложенные HashMap в HBase:
Map<String, Map<String, Map<String, Double>>>
Я не могу понять схему таблицы HBase.
Индекс строки, очевидно, будет строковым значением в самой внешней карте. Однако я не думаю, что HBase допускает вложенные семейства столбцов (хотя допускается любое количество столбцов на семейство столбцов)
Также из ответа здесь я узнал, что вложенные сущности не могут иметь вложенные сущности в HBase.
Чтобы дать вам представление о размере данных:
1) Внутренняя карта (Map<String, Double>) будет иметь только 3 ключа.
2) Средняя карта (Map<String, Map<String, Double>>) будет иметь около 100 ключей.
3) Внешняя карта (Map<String, Map<String, Map<String, Double>>>) может иметь около 20-30 миллионов ключей.
Любая помощь приветствуется.
Изменить 1: В основном, количество, которое я хочу сохранить, относится к конкретному productId, сколько количеств было продано на местном, зональном или национальном уровне с определенного склада. productId является ключом для внешней карты. warehouseID - это ключ для средней карты. Местный / зональный / национальный является ключом для самой внутренней карты.
Редактировать 2: Данные будут заполнены и прочитаны в задании на карте. По сути, для каждого идентификатора продукта warehouseId x (локальный / зональный / национальный: на данный момент назовем это saleType) количество требуется в качестве входных данных для другой операции. Я также думал о сохранении данных в productId x warehouseId x saleType granularity в файле csv и считывании их из сопоставленного задания.
3 ответа
Учитывая ваши правки, я бы избегал использования HBase (хотя мне это нравится). Кажется, что вам не нужен произвольный доступ к вашим данным, и полное сканирование таблицы и полная запись таблицы на каждой итерации - не лучшее использование HBase.
Я предполагаю, что у вас уже есть кластер Hadoop. Наилучшим вариантом, вероятно, является хранение данных в плоском формате непосредственно в HDFS (A SequenceFile, Avro или других форматах сериализации). Кроме того, я не уверен, какие инструменты вы используете, но я предполагаю, что для базового агрегирования подсчетов Hive будет простым вариантом запуска).
Один из способов решения этой проблемы - (key1, key2, key3) -> двойная карта. У вас есть ключи, семейства столбцов и квалификаторы как способы описания вашей структуры. Вы можете поместить все три части ключевого кортежа как сцепленный row_key для действительно высокой таблицы, хотя это не очень хорошо сработает.
у вас есть до 9 миллиардов кортежей. У вас есть хорошее представление о данных. Первый вопрос, который у меня возник бы, это: "Как вы будете запрашивать данные и получать к ним доступ чаще всего?" Если вы ищете конкретные значения, а не наборы, то, возможно, 9 миллиардов строк имеют смысл. Если чаще, то нет, вы ищете все внутренние данные для одного внешнего ключа, тогда, возможно, самый внешний ключ в виде row_key и (middle)_(inner) в качестве классификатора столбца могут работать. В последнем случае вы можете использовать QualifierFilter с компаратором регулярных выражений для дальнейшей фильтрации ответа.
Как я понял, у вас большой набор данных, область для разделов, а также требуется быстрый поиск, так что вы можете использовать формат паркета в HDFS. Который предоставит вам столбчатое хранилище с разделами и поддержкой сжатия. Также вы можете читать данные через любые другие фреймворки, такие как спарк, дрель и т.д.