Прошу прощения, у меня искаженное представление о нормальности :)… «Локальный джойн со словарем» в моем восприятии это JOIN, который может быть локализован в одной машине. Одна машина, в реалиях 18 года, может иметь 512Гб оперативной памяти и может быть весьма мощной. Там совершенно нормально может пройти локальный JOIN со словарем в 1 млрд. строк. Другое дело, когда нужно соединять несколько таблиц в десятки и сотни млрд. строк. Отвечая на вопрос, зачем платить за Вертику: чтобы соединять таблицы, не смотря на их размер. Все нужно уметь джойнить со всем.
Потому что хотели делать ad-hoc аналитику?
Вопрос про альтернативу в такой постановке я бы сначала предварил другим вопросом:
— а вы можете привести пример организации с сотнями 100Тб данных, которая успешно сделала ad-hoc аналитику на hdfs + spark sql, без MPP баз? Я бы с ними с радостью подискутировал.
Я бы сказал, что нет, и вот почему. В один год в нашу Вертику прилетает чуть больше 2Пб данных (метрика на кликстриме). И так уже больше 5 лет, а данных в итоге 176Тб в горячем слое + ~300Тб в архивной зоне.
Это происходит из-за логического сжатия: если произошло 10к событий с одного большого URL, мы сохраним его только раз, а дальше будем использовать INT ключ. И так почти со всем: мы добавляем в хранилище только действительно новые данные, только реально изменившиеся поля. Из-за этого записи намного меньше, а чтения — сначала больше, а потом тоже меньше. В реальности почти все запросы упираются не в диск, а в оперативку, в которой кешируются выборки для lookup.
По вопросам:
1. Есть cold storage с реализованной схемой подгрузки в быструю зону.
2. В Вертике? События раскладываются по множеству таблиц 6НФ. Новые версии попадают в те же таблицы, что и старые, но у новых новые атрибуты летят в новые таблицы. Про это большая статья тут есть, про грибницу: habr.com/company/avito/blog/322510
3. Конечно. Ради этого все и делается. funnel из полудюжины таблиц+данные из платежных систем+результаты прогнозов и результаты рекламных рассылок. Только так и получается нормальная аналитика.
4. Все отдельно. 6 нормальная форма, все описано в статье про грибницу.
Конечно можно джойнить таблицы, если правая (словарь) маленькая.
Цитата из официальной документации ClickHouse:
The right table (the subquery result) resides in RAM. If there isn't enough memory, you can't run a JOIN.
И это только первая проблема. Вторая возникает, когда ClickHouse шардирован на несколько таблиц, и нужно сделать JOIN больших таблиц, шардированных по разному (нужна ресегментация данных). Эту проблему можно частично решить конструкцией Global, но только, опять же, для маленьких таблиц.
Для производительности мы материализуем атрибуты, использующиеся для идентификации анкора, вместе с суррогатным ключем анкора, и из этой материализации — расшифровываем, старый ли это анкор, или нужно добавить новый.
Спасибо :)
1. Либо по Кимбалу, либо еще более денормализованные, в единую таблицу. Tableau предпочитает минимум таблиц :) Таблиц — 160, примерно 15Тб. Про это будет следующая статья, с графиками.
2… Видимо, тоже следующая статья :)… Без PIT таблиц. Несколько подходов, все на основе оконных функций, либо через WITH, либо через join подзапросов. Выглядит немного тяжеловесно (в случае десятков таблиц), но очень единообразно, поэтому в реальности такой код обычно пишут формулы Excel. Размер кода, боюсь, будет слегка великоват для комента, поэтому — в следующей большой публикации :)
Бизнес пользователи боятся кучи таблиц.
Опять же, в денормализванной таблице проще навернуть бизнес-логику.
Например, платежи можно представить тремя разными образами из одних и тех же сырых данных (сырые платежи, завершенные платежи, отраженные в фин-отчетности). Проще сделать три денормализованных таблицы платежей для разных подразделений. Меньше риск запутаться.
Это же колоночная база (!).
Даже при запросе 5 из 50 денормализованных простой селект будет быстрее.
Нормализация нужна для хранения. Если у вас с начала времен и до тепловой смерти вселенной будет 50 столбцов — одна денормализованная таблица выгоднее. Веселье начинается, когда у вас, например, у объявления сначала появляется метро, потом оно становится историчным, а потом разрешают вводить несколько метро (много-ко-многим). И такое за год-другой может произойти с дюжинами полей. В 2013 у нас у событий веб-лога было 30 атрибутов. Сейчас 90…
1. Суррогат — автоинкремент. Identity в Vertica. Натуральные — либо в атрибутах, либо в особом поле в анкоре. Тут уже нюансы реализации.
2. Google Sheet + автогенерация документации для Confluence.
3… Постараюсь рассказать в следующих статьях :)
Факт (линк) с ценой в атрибуте: постарайтесь смоделировать ситуацию, когда у вас у факта меняется цена И ссылка на измерение. Например, для продажи — неправильный товар и неправильная цена.
Подскажу: проблема в том, что факт идентифицируется ссылками на измерение.
Т.е. честная полная историчность приводит к изменению идентификатора.
Проблему можно решить, но тут огромный риск ошибиться.
А у чека номер есть :)
Конечно, извлечение из единой денормализованной таблицы работает быстрее. Но не принципиально быстрее. Описанная стратегия сегментации гарантирует очень высокую эффективность join-а атрибутов отдой сущностив рамках нашей кластерной MPP базы.
В нашей практике мы делаем денормализованные витрины, где храним, например актуальные ФИО+ИНН+перс. данные людей. Но только актуальные. Кому нужна историчность, ретроспектива, люди работают уже с полностью историчными нормализованными таблицам атрибутов.
Становятся реальными не только slow changing dimensions, но и slow changing facts. Историчность становится очень простой, доступной для включения в любой точке — как в измерениях, так и в фактах.
SQL, NoSQL, MapReduce… и SAP Hana. Явления одного порядка, кто же спорит.
Самая востребованная технология для BigData — in memory (Sap HANA, Oracle Exadata), 30%
Ну да. Вообще огонь. Свою первую таблицу то видели, про размер базы больших данных? Еще можно свой же список технологий у Big Data проектов в России посмотреть. Это пенсионный фонд России 30% дал?
Вопрос про альтернативу в такой постановке я бы сначала предварил другим вопросом:
— а вы можете привести пример организации с сотнями 100Тб данных, которая успешно сделала ad-hoc аналитику на hdfs + spark sql, без MPP баз? Я бы с ними с радостью подискутировал.
Это происходит из-за логического сжатия: если произошло 10к событий с одного большого URL, мы сохраним его только раз, а дальше будем использовать INT ключ. И так почти со всем: мы добавляем в хранилище только действительно новые данные, только реально изменившиеся поля. Из-за этого записи намного меньше, а чтения — сначала больше, а потом тоже меньше. В реальности почти все запросы упираются не в диск, а в оперативку, в которой кешируются выборки для lookup.
1. Есть cold storage с реализованной схемой подгрузки в быструю зону.
2. В Вертике? События раскладываются по множеству таблиц 6НФ. Новые версии попадают в те же таблицы, что и старые, но у новых новые атрибуты летят в новые таблицы. Про это большая статья тут есть, про грибницу: habr.com/company/avito/blog/322510
3. Конечно. Ради этого все и делается. funnel из полудюжины таблиц+данные из платежных систем+результаты прогнозов и результаты рекламных рассылок. Только так и получается нормальная аналитика.
4. Все отдельно. 6 нормальная форма, все описано в статье про грибницу.
Цитата из официальной документации ClickHouse:
The right table (the subquery result) resides in RAM. If there isn't enough memory, you can't run a JOIN.
И это только первая проблема. Вторая возникает, когда ClickHouse шардирован на несколько таблиц, и нужно сделать JOIN больших таблиц, шардированных по разному (нужна ресегментация данных). Эту проблему можно частично решить конструкцией Global, но только, опять же, для маленьких таблиц.
1. Либо по Кимбалу, либо еще более денормализованные, в единую таблицу. Tableau предпочитает минимум таблиц :) Таблиц — 160, примерно 15Тб. Про это будет следующая статья, с графиками.
2… Видимо, тоже следующая статья :)… Без PIT таблиц. Несколько подходов, все на основе оконных функций, либо через WITH, либо через join подзапросов. Выглядит немного тяжеловесно (в случае десятков таблиц), но очень единообразно, поэтому в реальности такой код обычно пишут формулы Excel. Размер кода, боюсь, будет слегка великоват для комента, поэтому — в следующей большой публикации :)
Опять же, в денормализванной таблице проще навернуть бизнес-логику.
Например, платежи можно представить тремя разными образами из одних и тех же сырых данных (сырые платежи, завершенные платежи, отраженные в фин-отчетности). Проще сделать три денормализованных таблицы платежей для разных подразделений. Меньше риск запутаться.
Прибыльный?
Даже при запросе 5 из 50 денормализованных простой селект будет быстрее.
Нормализация нужна для хранения. Если у вас с начала времен и до тепловой смерти вселенной будет 50 столбцов — одна денормализованная таблица выгоднее. Веселье начинается, когда у вас, например, у объявления сначала появляется метро, потом оно становится историчным, а потом разрешают вводить несколько метро (много-ко-многим). И такое за год-другой может произойти с дюжинами полей. В 2013 у нас у событий веб-лога было 30 атрибутов. Сейчас 90…
2. Google Sheet + автогенерация документации для Confluence.
3… Постараюсь рассказать в следующих статьях :)
Подскажу: проблема в том, что факт идентифицируется ссылками на измерение.
Т.е. честная полная историчность приводит к изменению идентификатора.
Проблему можно решить, но тут огромный риск ошибиться.
А у чека номер есть :)
В нашей практике мы делаем денормализованные витрины, где храним, например актуальные ФИО+ИНН+перс. данные людей. Но только актуальные. Кому нужна историчность, ретроспектива, люди работают уже с полностью историчными нормализованными таблицам атрибутов.
SQL, NoSQL, MapReduce… и SAP Hana. Явления одного порядка, кто же спорит.
Самая востребованная технология для BigData — in memory (Sap HANA, Oracle Exadata), 30%
Ну да. Вообще огонь. Свою первую таблицу то видели, про размер базы больших данных? Еще можно свой же список технологий у Big Data проектов в России посмотреть. Это пенсионный фонд России 30% дал?
Пока от них недостаточно пестрит в глазах.
Надо попробовать сделать упрощенную и на русском…