Comments 13
Но это так… Погуглим.
С увеличением объемов обрабатываемой информации в случае большой кардинальности справочников использование счетчиков в качестве суррогатных ключей становится проблемой с точки зрения производительности, т.к. при загрузке фактов необходимо определить значение суррогатного ключа по довольно большому справочнику.
Переводим на русский язык с хранилищного. Кто-то так спроектировал справочники, что триггеры не успевают вставлять уникальные значения, либо путаются, когда вставляется хоть сколько-то сложная структура данных. Решение автора: давайте отделим то, что можно оценить и найти сразу в виде конкретных значений хэш-функции, от тех значений, которые в справочниках отсутствуют, поэтому не могут быть загружены сразу. Сразу возникает вопрос: а не проще ли сразу было спроектировать измерения так, чтобы коллизии физически не могли наступить? Как бы хорошие примеры этого в книжках описаны: вспомогательная универсальная развязка для набора ранее неопределимых значений, наличие таблицы-справочника с основными оперативными хэшами, иные дополнительные искусственные приемы тоже сравнительно неплохи для хранилищ среднего и малого размера. Вот уже и в новых версиях Oracle (18, 19, 21) они входят в оборот СУБД как система обработки метаданных таблиц-измерений. И не надо ничего лишнего городить. И еще, вдогонку, приложение Oracle Real User Experience решает задачу по конструированию воронки продаж на основании вызова пользователем страниц интернет-магазина (и любого сложного сайта) прямо из коробки, то есть индексация пути пользователя является частью его функционала. К пользе перехода на новый софт заметим, что 12.1 была первой версией с колоночным хранением in-memory.
какие еще триггеры в DWH ? ну и по сути как раз автор и показывает как сделать так чтобы коллизии не были проблемой.
Buffer the data warehouse from operational changes. Surrogate keys enable
the warehouse team to maintain control of the DW/BI environment rather
than being whipsawed by operational rules for generating, updating, deleting,
recycling, and reusing production codes. In many organizations, historical
operational codes, such as inactive account numbers or obsolete product
codes, get reassigned after a period of dormancy. If account numbers get
recycled following 12 months of inactivity, the operational systems don’t miss
a beat because their business rules prohibit data from hanging around for that
long. But the DW/BI system may retain data for years. Surrogate keys provide
the warehouse with a mechanism to differentiate these two separate instances
of the same operational account number. If you rely solely on operational
codes, you might also be vulnerable to key overlaps in the case of an acquisi-
tion or consolidation of data.
Цитата по книге: Kimball "The Data Warehouse Toolkit 3rd Edition" стр. 99 английского издания, ISBN: 978-1-118-53080-1
Не очень понимаю, как комментарий выше относится к тому, что написано в статье.
Поясню на примере. У вас на входе есть информация кликах сайта. Одна из характеристик клика - параметр User Agent, который представляет собой строку довольно большой длины. Хранить ее непосредственно в таблице фактов невыгодно, значит надо делать справочник и суррогатный ключ для него. Просто перенумеровывать все возможные значения по производительности хуже, чем использовать хэш функцию. Но хэш функция может давать дубли, которые надо обрабатывать.
Например, ORA_HASH() для следующих двух строк дает одно значение ключа:
"Opera/5.0 (Linux (Wine); U; Linux i686; en-us) Chrome/41.6.250.668 Safari/587.44"
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.88 (KHTML, like Gecko) Chrome/54.0.1608.78 Safari/537.88"
Я с трудом представляю, где вы функцией "ORA_HASH is a function that computes a hash value for a given expression. This function is useful for operations such as analyzing a subset of data and generating a random sample" с параметрами ORA_HASH(string, max_bucket,seed_value), где по дефолту max_bucket = 4294967295, seed_value = 4294967295 в промышленном коде по одной строке будете разделять User Agent, если действительно легко получается коллизия. Давайте чуть проще сделаем: select ORA_HASH('Opera/5.0 (Linux (Wine); U; Linux i686; en-us) Chrome/41.6.250.668 Safari/587.44',2,5) from dual; вернет 1, а select ORA_HASH('Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.88 (KHTML, like Gecko) Chrome/54.0.1608.78 Safari/537.88',2,5) from dual; вернет 0. Как печально указано в статье https://danischnider.wordpress.com/2017/01/24/how-to-build-hash-keys-in-oracle/ "The probability of two input values with the same hash key is quite high. With 9300 input rows, the probability is 1%, with 50’000 rows already 25%, and with 77’000 rows 50%." Дальше там про другие способы генерации написано очень хорошо с примерами кода.
Поэтому я привел ссылку на приложение Oracle Real User Experience сделанное специально для описываемой вами задачи и более того - заточенное на анализ web приложения целиком.
А может просто делать хд в колоночной аналитической базе с кэшируемым наборов суррогатных ключей? :)
Спасибо за ссылку на статью. Очень подробно описано, какие алгоритмы хэширования применять для генерации суррогатных ключей. Если бы знал о ней ранее, вставил бы ссылку в своем посте.
Большинство компаний идет по пути применения MD5, принимая риск того, что коллизии возможны, но они пренебрежимо малы.
Мне было интересно решить задачу обработки коллизий, что позволило использовать фунцию с большей вероятностью дублей.
Не претендую на единственно верное решение. Поделился со всеми, т.к. описания подхода обработки дублей ранее не видел. Алгоритм апробовали на реальной системе и он показал свою применимость и эффективность.
Тем более не готов сравнивать на одной доске точечный алгоритм с решением класса Enterprise - Oracle Real User Experience. Может быть поделитесь опытом внедрения на Российском рынке?
Использование хеш-значений с обработкой коллизий в качестве суррогатных ключей в справочниках DWH