Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
 Не биг ли это дата?  [new]
Ибн Хоттаб
Member

Откуда: Den marsianske sosialistiske sovjetrepublikk
Сообщений: 615
Делаем сейчас один проект. Хранилище с одной стороны как хранилище, в нем две фактовые таблицы, каждая порядка единиц миллиардов записей, но дальше начинаются нюансы: основное измерение для этих фактовых таблиц одно, и его кардинальность сейчас - около 200 миллионов, к нему подключаются остальные измерения, которых немало, из них выделяется измерение контрагентов, кардинальность которого больше миллиона, а используется оно 13 раз в разных ролях. Все измерения историчные. Экономический смысл всего этого такой: то чего 200 миллионов - это активы, которые приносят прибыли и убытки, в фактовых таблицах события, например изменения количественных параметров этих активов в некие моменты времени, например цены за которые из можно было бы в тот момент продать, или прибыль, которую актив сгенерировал, или цена за которую его реально купили/продали. Типичный сценарий использования такой: по некоторым параметрам, типа сгенерировал мало/много прибыли за период времени, не был продан до снижения цены, резко изменилась его рыночная цена, ищутся активы или их группы, а потом анализируется история каждого по отдельности, кто с ним работал, какие решения принимал и так далее. Еще стоит отметить, что данные залетают туда довольно часто, каждые несколько минут, и количество новых строк может быть порядка миллионов в день, в среднем около миллиона.

Изначально, еще до того как кардинальность достигла десятков миллионов, это было реализовано в базе Oracle, а бизнесу показывалось при помощи Oracle BI. Работало так себе, или даже правильнее сказать никак. Сейчас переделано на SSAS Tabular, хотя данные так и лежат в Oracle, работает нормально, когда данные уже в кубе, но есть другая проблема - из-за огромной кардинальности куб процессится (Process Recalc) уже больше трех часов, и понятно что это время не уменьшится, при том что мы уперлись в ограничения железа - 32 ядра, 1.5 Тб оперативки, это самый большой стандартный сервер, ничего мощнее у нас в организации нет и не будет в обозримом будущем. 3 часа это уже очень много, это означает, что пользователи перестают видеть актуальные данные, практически они их видят с 12 часовой задержкой минимум.

И вот мне подумалось, что не подходящий ли это случай для бигдатных технологий? Типа сложить все атрибуты в одну "таблицу", разложить ее на несколько серверов (мощнее чем вышеуказанный мы не можем получить, но несколько таких или меньших - вполне), и прочесывать ее ими параллельно. Придумали уже что-то такое? ActivePivot не предлагать, у нас есть на него лицензия, но у него свои заморочки, и как результат не очень хорошая репутация в организации.
28 сен 20, 22:39    [22206036]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2748
придумали, это clickhouse

Сообщение было отредактировано: 29 сен 20, 00:00
29 сен 20, 00:04    [22206058]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 34263
Блог
Ибн Хоттаб,

А может стоит просто договориться с бизнесом и сделать архивный куб, куда слить все, что старше N лет?
29 сен 20, 01:19    [22206069]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Полковник.
Member

Откуда:
Сообщений: 1901
Ибн Хоттаб,
Для начала надо бы понять что с вашим ораклом все в порядке, а потом уже фантазировать на тему бигдаты. Да и вообще бигдата это не про то, что вы тут понаписали, начинается пустая бегатня по технологиям...
29 сен 20, 14:33    [22206481]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 377
Ибн Хоттаб,

на совсем бигдате это могло бы выглядеть так:
данные как можно скорей пишутся в кафку, из кафки чем-то стриминговым, например spark streaming, читать, агрегировать на лету показатели и записывая в elasticserach или solr индекс.
кроме индекса писать еще куда-то сырые данные. если совсем бигдата с hadoop то на hdfs в виде orc или parquet файликов с тучей партишенов. тогда из индекса юзер поучает списки активов, а детали уже берет с hdfs по jdbc какой-нить cloudera impala. если партиций достаточно много, а пользователей не столь много аля in memory + mpp енжин impala неплохо справится.
попроще вариант писать детали просто в несколько mysql, просто во время записи в индекс из ид актива вычислять шарду и писать детали в нужный mysql инстанс. т.е. в индексе хранить на котором сервере(ах) детали.

Сообщение было отредактировано: 29 сен 20, 15:25
29 сен 20, 15:29    [22206524]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 34263
Блог
H5N1,

В вашей схеме все останавливается на уровне баз данных, а у автора топика проблема (по сути) со средством отображения, вот раскидаете вы все на десятки mysql, нужно же еще показать данные пользователям в правильном и удобном виде.
29 сен 20, 16:04    [22206558]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
T87
Member

Откуда:
Сообщений: 169
Ибн Хоттаб,

А вы все партиции каждый раз процессите?
29 сен 20, 16:16    [22206565]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Ибн Хоттаб
Member

Откуда: Den marsianske sosialistiske sovjetrepublikk
Сообщений: 615
T87, у нас для большинства таблиц партиционирование по дням, соответственно делаем ProcessData "сегодняшних" партиций, а потом ProcessRecalc всего куба, это все вместе занимает порядка трех часов.

Критик, не получится, это и так данные только за неполные три года, а всего их есть лет за 20.
29 сен 20, 17:32    [22206614]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 34263
Блог
Ибн Хоттаб,

А если попробовать сократить объем данных исходя из бизнес-смысла?
Например, контрагентов у вас 1 млн, из них 50% - скорее бывшие контрагенты, с которыми взаимодействовали (условно) 10 лет назад. А сейчас они просто висят в справочнике. Вынести их в отдельную сущность с тем же ключом, если будет по ним активность - автоматом переносить в основную сущность.
И т.д. для всех больших измерений.
29 сен 20, 18:14    [22206677]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Ибн Хоттаб
Member

Откуда: Den marsianske sosialistiske sovjetrepublikk
Сообщений: 615
Критик, к сожалению все что можно было сократить уже сокращено, там реально миллион контрагентов. Основная проблема, с точки зрения Tabular, это безумная кардинальность в 200 миллионов. Я знаю что вы специалист по MS стеку, не первый год на форуме, но по моему тут просто ничего не улучшить. И в принципе, все в среднем довольны тем что нам удалось выжать из SSAS, по крайней мере раньше и такого никто не мог обеспечить, в этой теме я скорее думаю о завтрашнем дне.

H5N1, если честно, не до конца понял что вы написали, потому что не со всем из перечисленного знаком, потому и отвечаю с задержкой - переваривал. :) По первой части, все понятно, у нас так ETL и организован, Kafka/Spark, только хранятся в итоге данные в Oracle. К этой части я отношения особо не имею. Я отвечаю за то что с данными происходит потом - когда они людям показываются. И вот с этого момента я не совсем понял.
29 сен 20, 23:35    [22206839]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2748
Я же говорю, сложить всё в одну таблицу и чтобы было быстро - это кликхаус. Без кафки и спарка. Бесплатно и без обрезания исторических данных.
30 сен 20, 00:13    [22206848]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 377
Ибн Хоттаб

H5N1, если честно, не до конца понял что вы написали, потому что не со всем из перечисленного знаком, потому и отвечаю с задержкой - переваривал. :) По первой части, все понятно, у нас так ETL и организован, Kafka/Spark, только хранятся в итоге данные в Oracle. К этой части я отношения особо не имею. Я отвечаю за то что с данными происходит потом - когда они людям показываются. И вот с этого момента я не совсем понял.

у вас судя по всему в оракл шли по сути сырые данные, соответственно если нужно что-то там по каким-то показателям отобрать, то в оракл уходят тяжелые агригирующие запросы.
у меня же предложение кроме записи сырых данных агрегировать показатели в отдельном индексе - в спарке налету рассчитывать изменение цены за день, за неделю, месяц, продан до снижения и т.п. соответственно для выборки использовать показатели из индекса, а не запросы в оракл.
я нечто такое видел как-то в проекте по оценке портфеля. грузились чужие данные, основные показатели писались в solr индекс, по нему пользователь говорил, что хочет прикинуть с ценами отсюда по сюда, только немецкие, и еще что-нить. приложение по индексу быстро отбирало схожие данные из давно выкупленных портфелей и говорило примерно, чего можно ждать от выбранного портфеля. можно было по итему посмотреть детали истории - историю доставали из impala. поскольку запрос в impala по деталям вел на конкретную партицию, работало достаточно быстро.
30 сен 20, 00:25    [22206851]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Dansoid
Member

Откуда:
Сообщений: 1
Ибн Хоттаб,

Да, для этого есть новые технологии, называются NewSQL.
Самый яркий представитель, как на меня, это MemSQL. Тут уже пару раз писали об ClickHouse - я думаю он еще сыроват, особенно в многомашинной конфигурации. Да и возможности запрсов подкачивают.

Да MemSQL не бесплатен, но он того стоит. Даже на кластере из двух 16-и ядерных машин вы получите невероятный буст в производительности. Бесплатная версия из трех нод (агрегатор + 2 рабочих) вполне покажет что он может. База данных готова к петабайтной нагрузке, если что. Timeseries включены и даже ничего не надо делать, просто пишите SQL, оконные функци, все что вы привыкли делать с Oracle, при условии что вы используете MySQL диалект.
30 сен 20, 01:45    [22206866]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Ибн Хоттаб
Member

Откуда: Den marsianske sosialistiske sovjetrepublikk
Сообщений: 615
Бумбараш, спасибо. С изучения этого мы и начнем, к тому же нагуглил случаи когда люди пытались подружить его с MS.

H5N1, и вам спасибо, это примерно наш случай и есть, осталось разобраться что такое Solr

Сообщение было отредактировано: 30 сен 20, 09:23
30 сен 20, 09:20    [22206904]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 377
Ибн Хоттаб


H5N1, и вам спасибо, это примерно наш случай и есть, осталось разобраться что такое Solr


Solr и elastic search под низом lucene индекс вроде имеют. Solr вроде более старый проект и заточен на java клиент, elastic более модный сейчас на rest api ориентируется.
30 сен 20, 12:52    [22207015]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3626
Бумбараш
Я же говорю, сложить всё в одну таблицу и чтобы было быстро - это кликхаус. Без кафки и спарка. Бесплатно и без обрезания исторических данных.

почему кликхаус, а не сноуфлек? или редшифт?
22 окт 20, 19:02    [22219062]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2748
Ivan Durak
Бумбараш
Я же говорю, сложить всё в одну таблицу и чтобы было быстро - это кликхаус. Без кафки и спарка. Бесплатно и без обрезания исторических данных.

почему кликхаус, а не сноуфлек? или редшифт?

потому что это базы данных, расположенные на территории потенциального противника
22 окт 20, 23:30    [22219195]     Ответить | Цитировать Сообщить модератору
 Re: Не биг ли это дата?  [new]
George Nordic
Member

Откуда: Moscow
Сообщений: 1167
Бумбараш
потому что это базы данных, расположенные на территории потенциального противника
Кафедру МИРЭА военную чувствую я...

Ivan Durak, про Snowflake и Redshift даже на этом форуме - всего с десяток упоминаний. Тяжело пока облака в России приживаются. А аналогов типа Яндекс.Снежинка / кликхаус или Мэйл.КрасныйРычаг / тарантул пока не так много, да и несколько непохожи они на указанные продукты.

С Уважением,
Георгий
23 окт 20, 10:07    [22219300]     Ответить | Цитировать Сообщить модератору
Все форумы / OLAP и DWH Ответить