Схема звездочки, суррогатные ключи

У нас есть большие и широкие плоские файлы с данными телеметрии. Они приезжают каждый день.

Я собираюсь создать звездную схему в базе данных ADLA, которая будет заполнена данными из этих больших больших файлов. (похоже, ADLA DB предоставляет множество функций (в отличие от необработанного ADLS): индексы, статистика, сжатие, управление распределением ...)

Для генерации суррогатных ключей мы можем использовать:

  1. row_number
  2. хеширование

А как насчет хеширования? Какие функции мы можем использовать для его реализации? (Я думаю о C #)


azure-data-lake u-sql
person churupaha    schedule 16.03.2017    source источник
comment
Это не ответ на ваш вопрос. Но подумал, что стоит упомянуть, что с тем, что вы предлагаете, вам нужно иметь дело с тем фактом, что в настоящее время вы не можете ОБНОВЛЯТЬ или УДАЛИТЬ в USQL из таблиц ADL. Вероятно, вам нужно будет больше смотреть на разделы, если вам нужна возможность повторного запуска.   -  person Paul Andrew    schedule 17.03.2017
comment
Да, я понимаю. Я собираюсь использовать разбиение по дате для таблиц FactXXX.   -  person churupaha    schedule 17.03.2017

Ответы (1)


arrow_upward
2
arrow_downward

Сначала я хотел бы понять, почему вы хотите использовать суррогатный ключ.

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

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

Что касается реализации ваших собственных хэш-функций, C # имеет несколько встроенных хеш-функций, или вы можете написать свои собственные. Например, метод C # Object.GetHashCode.

person Michael Rys    schedule 19.03.2017
comment
У нас есть данные временной шкалы телеметрии, хранящиеся в CSV. Эти CSV-файлы широкие (много столбцов). Ожидается, что они будут большими, но я могу контролировать размер каждого в пределах 1–4 ГБ (как ожидает движок ADLA). Я хочу постепенно загружать эти данные в базу данных ADLA, чтобы использовать такие функции, как: разделы, распределения, совместимые объединения / агрегаты, статистика и т. Д. Кроме того, эти данные очень избыточны и широки (много столбцов). Невозможно создать единую схему распределения для плоской широкой таблицы, чтобы обеспечить объединение / группировку по совместимости для всех основных запросов. Я хочу разложить плоскую структуру на звездную схему. - person churupaha; 28.03.2017
comment
В этом случае у нас будет несколько Fact-таблиц, которые будут разделять некоторые Dim-таблицы. Эти таблицы фактов не будут такими широкими, как исходная плоская таблица, и я смогу выбрать правильную схему распределения в каждом конкретном случае. Также это должно привести к уменьшению размера набора данных. Кроме того, эти таблицы фактов будут состоять почти полностью из целых чисел, а не из больших строк (как у нас в плоской схеме). Это должно дать преимущества для агрегатов (или нет? По крайней мере, это было верно для Azure DWH). Чтобы реализовать звездную схему, мне нужен способ создания суррогатных ключей для DimTables. Я могу использовать row_number или какое-то хеширование. - person churupaha; 28.03.2017
comment
Это не должно нарушать распределение ценности по сравнению с исходными данными. Потому что, если у нас есть в исходной плоской таблице столбец со значениями 'Biiiiig string 1', 'Biiiiig string 1', 'Biiiiig string 1', 'Biiiiig string 2', 'Biiiiig string 3', то они будут заменены суррогатными целыми числами. 1, 1, 1, 2, 3 - person churupaha; 28.03.2017
comment
Это то, что и почему я буду делать. Будет здорово, если вы это прокомментируете. Спасибо, как всегда. - person churupaha; 28.03.2017
comment
Думаю, ваш подход имеет смысл. Убедитесь, что ключи кластера и схемы распределения согласованы и предназначены для наиболее распространенных соединений / запросов. Дайте мне знать, если у вас появятся вопросы после его внедрения. - person Michael Rys; 29.03.2017
comment
я реализовал это. он дал мне следующие преимущества: степень сжатия 4,8 - 5 (source_size / star_sch_tables_size). сжатие зависит от избыточности наших исходных данных. большая часть запросов выполняется в 4-5 раз быстрее при сравнении raw и star схемы; также я могу согласовать свои распределения таблиц с запросами; а мы сэкономим на пространстве / iops / cpu. также я могу эмулировать вторичные индексы, если это будет необходимо, я создам тонкую таблицу с только необходимыми столбцами и правильно проиндексирую / распределю ее и буду использовать тонкую таблицу вместо базовой исходной таблицы ... я интегрирую свои скрипты в ADF трубопровод :) - person churupaha; 02.05.2017
comment
также я могу выполнять частичное агрегирование данных таблиц фактов с помощью целочисленных ключей, затем объединять результаты с необходимыми нечеткими таблицами, а затем полностью агрегировать небольшой частичный набор данных результатов по нечетким свойствам (это почти все большие строки); (похоже, что оптимизатор U-SQL иногда может создать план выполнения с той же логикой для звездообразной схемы без какого-либо явного переписывания запроса) - person churupaha; 02.05.2017