Лучший способ хранить данные переменной длины в одном столбце - PullRequest
Новая
       10

Лучший способ хранить данные переменной длины в одном столбце

0 голосов
/ 24 мая 2019

Я ищу мнения о том, как лучше хранить некоторые данные.У меня есть некоторые данные, которые похожи на следующие: 

id  category    proportion
1   1           0.99
1   7           0.85
2   1           0.55
3   2           0.90
3   3           0.85

По сути, уникальные идентификаторы могут принадлежать к разному количеству категорий.С каждым идентификатором и категорией связана пропорция.

Я хочу сохранить эти данные в одном столбце, чтобы я мог добавить их в таблицу, где каждый идентификатор может занимать только одну строку.

Прямо сейчас я обдумывал дваJSON структуры.Рассмотрим пример id = 1.У нас было бы что-то вроде следующих двух вариантов ...

  1. Unnested: {"category1": "1", "proportion1": "0.99", "category2": "7", "proportion2": "0.85"}
  2. Вложено: {"category1": {"label": "1", "proportion": "0.99"}, "category2": {"label": "7", "proportion": "0.85"}}

I'mне слишком знаком с JSON в Престо / Афина.Варианты использования включают в себя: а) поиск идентификаторов с заданной меткой категории или б) группирование атрибутов идентификатора по отдельным меткам категории .

Например, я могу захотеть идентифицировать все идентификаторы, которые относятся к категории = 3. Я не думаю, что какая-либо из этих структур облегчит это в Афине.

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

Ответы [ 2 ]

0 голосов
/ 07 июня 2019

Моделирование данных должно быть максимально основано на шаблонах доступа к запросам.Но если вам не известны все шаблоны, то есть несколько моментов, которые следует учитывать:

  • Попробуйте использовать денормализованную таблицу, чтобы избежать большого количества объединений
  • Используйте форматы файлов Parquet / ORC поверх JSON/ CSV
  • В вашем случае Parquet может быть лучше, поскольку вы ищете вложенную структуру данных, но убедитесь, что вы не запрашиваете эти подполя вложенной структуры, чтобы избежать проблем с производительностью.

Здесь вы можете хранить идентификатор и категорию в виде двух отдельных столбцов, чтобы можно было поддерживать запрос по идентификатору или категории.

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

0 голосов
/ 28 мая 2019

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

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

Если данных не слишком много, вы также можете использовать представления для создания оптимизированных представлений для различных вариантов использования.

...