K
hadoop это еще не предел, вот когда тебя на s3 + kubernetes выгоняют...
Minio?
Size: a a a
2019 November 24
АЖ
Minio?
ну если так, то минио и опеншифт
S
Кстати про тренды интересная дискуссия. Все началось с заявления, что MPP базы подменяют хадуп-спарк, потому что лучше используют локальность данных и в целом с текущими технологиями проще стало хранить нужные объемы локально и даже в памяти. С другой стороны был комментарий, что DWH и витрины не всегда нужны и/или заменяются сервисами на данных. Вот последнее интересно, в этом случае производительность менее важна? можно привести примеры сервисов на данных? есть ли соответсвенно тренд витрины на данных -> сервисы на данных?
Подменяют там, где мало данных по количеству или маленькое разнообразие по источникам. Если у тебя 200 гиговые таблички - зачем спарк. И один оракл в источнике.
Но пока хадупчик бесплатен в отличие от любой самой завалящей мпп, его по прежнему будут ставить.
Но пока хадупчик бесплатен в отличие от любой самой завалящей мпп, его по прежнему будут ставить.
DG
ClickHouse бесплатен ;-)
DU
Да и greenplum тоже
ТС
да и Druid тоже)
VS
ClickHouse бесплатен ;-)
На кх dwh строите? 😂
VS
И где-то читал, что друид тоже не для этих целей...
A
Да и greenplum тоже
он живет без платной поддержки? сколько человекочасов в месяц своих инженеров на него уходит?
DU
он живет без платной поддержки? сколько человекочасов в месяц своих инженеров на него уходит?
слышал, что используют без поддержки, деталей не знаю
A
слышал ругань на него, любопытно на живых пользователей посмотреть, как оно им
DG
На кх dwh строите? 😂
Если говорить про меня лично, то я не строил никогда, а сейчас к DWH вообще отношение имею косвенное. Но знаю вполне успешные кейсы, когда единственным хранилищем данных является CH, и он же витрина и база для репортов и аналитики.
VS
Если говорить про меня лично, то я не строил никогда, а сейчас к DWH вообще отношение имею косвенное. Но знаю вполне успешные кейсы, когда единственным хранилищем данных является CH, и он же витрина и база для репортов и аналитики.
Кликстримы онли, да
2019 November 25
EN
Доброе утро.
Проблема. Есть джоин на двух датаферймах, но один из них со skew.
Как правильно "посолить" ключ, чтобы вычисления были равномерно при джионе?
Или как генерируется правильный "хэш", который будет и для "больших" ключей давай нормальное число партиций и для "малых" ключей тоже? В общем вопросы ...🤷♀️
Проблема. Есть джоин на двух датаферймах, но один из них со skew.
Как правильно "посолить" ключ, чтобы вычисления были равномерно при джионе?
Или как генерируется правильный "хэш", который будет и для "больших" ключей давай нормальное число партиций и для "малых" ключей тоже? В общем вопросы ...🤷♀️
ЛР
Не совсем понятно, что значит сервис на данных?
Имеется в виду предосталение данных через некое API. При этом наличие витрины не исключается. Это немного другой паттерн доступа к данным. Для DWH специфично витрина + BI. витрина + сервис - это другой паттерн. И третий паттерн вообще без витрины (расчет на лету) - это для позапросного интерфейса. Архитектурно все три выстраиваются по разному.
VS
Имеется в виду предосталение данных через некое API. При этом наличие витрины не исключается. Это немного другой паттерн доступа к данным. Для DWH специфично витрина + BI. витрина + сервис - это другой паттерн. И третий паттерн вообще без витрины (расчет на лету) - это для позапросного интерфейса. Архитектурно все три выстраиваются по разному.
Ну мне кажется сервисы именно как DWH не нужны в большинстве своем, они скорее нужны, когда на основе данных из DWH что-нибудь идет в бек/фронт, например, ML задачи
DZ
DG
Доброе утро.
Проблема. Есть джоин на двух датаферймах, но один из них со skew.
Как правильно "посолить" ключ, чтобы вычисления были равномерно при джионе?
Или как генерируется правильный "хэш", который будет и для "больших" ключей давай нормальное число партиций и для "малых" ключей тоже? В общем вопросы ...🤷♀️
Проблема. Есть джоин на двух датаферймах, но один из них со skew.
Как правильно "посолить" ключ, чтобы вычисления были равномерно при джионе?
Или как генерируется правильный "хэш", который будет и для "больших" ключей давай нормальное число партиций и для "малых" ключей тоже? В общем вопросы ...🤷♀️
Ну тут много вариантов. Какой выбрать, зависит от типа ключа, кол-ва данных и запроса. Иногда даже не надо делать соль, а просто разбить на два запроса: первый без skew ключа, второй с ключом (только для этого ключа), и потом объединить результаты. Если данных не слишком много, то оно может сконвертится в map side join (он же broadcast hash join).
Еще вариант, с заменой ключа на случайное число, которое находится вне множества других ключей, но имеет тот же тип. Хорошо работает, с null. Допустим у вас есть long user_id (который всегда > 0), но который может быть null. И нулей 20%. Тогда можно просто заменить null на случайное отрицательное число, а потом преобразовать обратно в null, в конце.
Ну и варианты с репликацией.
Вот тут преза, в которой это хорошо разжевано.
https://www.slideshare.net/databricks/smart-join-algorithms-for-fighting-skew-at-scale
Еще вариант, с заменой ключа на случайное число, которое находится вне множества других ключей, но имеет тот же тип. Хорошо работает, с null. Допустим у вас есть long user_id (который всегда > 0), но который может быть null. И нулей 20%. Тогда можно просто заменить null на случайное отрицательное число, а потом преобразовать обратно в null, в конце.
Ну и варианты с репликацией.
Вот тут преза, в которой это хорошо разжевано.
https://www.slideshare.net/databricks/smart-join-algorithms-for-fighting-skew-at-scale
