|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Делаем сейчас один проект. Хранилище с одной стороны как хранилище, в нем две фактовые таблицы, каждая порядка единиц миллиардов записей, но дальше начинаются нюансы: основное измерение для этих фактовых таблиц одно, и его кардинальность сейчас - около 200 миллионов, к нему подключаются остальные измерения, которых немало, из них выделяется измерение контрагентов, кардинальность которого больше миллиона, а используется оно 13 раз в разных ролях. Все измерения историчные. Экономический смысл всего этого такой: то чего 200 миллионов - это активы, которые приносят прибыли и убытки, в фактовых таблицах события, например изменения количественных параметров этих активов в некие моменты времени, например цены за которые из можно было бы в тот момент продать, или прибыль, которую актив сгенерировал, или цена за которую его реально купили/продали. Типичный сценарий использования такой: по некоторым параметрам, типа сгенерировал мало/много прибыли за период времени, не был продан до снижения цены, резко изменилась его рыночная цена, ищутся активы или их группы, а потом анализируется история каждого по отдельности, кто с ним работал, какие решения принимал и так далее. Еще стоит отметить, что данные залетают туда довольно часто, каждые несколько минут, и количество новых строк может быть порядка миллионов в день, в среднем около миллиона. Изначально, еще до того как кардинальность достигла десятков миллионов, это было реализовано в базе Oracle, а бизнесу показывалось при помощи Oracle BI. Работало так себе, или даже правильнее сказать никак. Сейчас переделано на SSAS Tabular, хотя данные так и лежат в Oracle, работает нормально, когда данные уже в кубе, но есть другая проблема - из-за огромной кардинальности куб процессится (Process Recalc) уже больше трех часов, и понятно что это время не уменьшится, при том что мы уперлись в ограничения железа - 32 ядра, 1.5 Тб оперативки, это самый большой стандартный сервер, ничего мощнее у нас в организации нет и не будет в обозримом будущем. 3 часа это уже очень много, это означает, что пользователи перестают видеть актуальные данные, практически они их видят с 12 часовой задержкой минимум. И вот мне подумалось, что не подходящий ли это случай для бигдатных технологий? Типа сложить все атрибуты в одну "таблицу", разложить ее на несколько серверов (мощнее чем вышеуказанный мы не можем получить, но несколько таких или меньших - вполне), и прочесывать ее ими параллельно. Придумали уже что-то такое? ActivePivot не предлагать, у нас есть на него лицензия, но у него свои заморочки, и как результат не очень хорошая репутация в организации. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 22:39 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
придумали, это clickhouse ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 00:04 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб, А может стоит просто договориться с бизнесом и сделать архивный куб, куда слить все, что старше N лет? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 01:19 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб, Для начала надо бы понять что с вашим ораклом все в порядке, а потом уже фантазировать на тему бигдаты. Да и вообще бигдата это не про то, что вы тут понаписали, начинается пустая бегатня по технологиям... ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 14:33 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб, на совсем бигдате это могло бы выглядеть так: данные как можно скорей пишутся в кафку, из кафки чем-то стриминговым, например spark streaming, читать, агрегировать на лету показатели и записывая в elasticserach или solr индекс. кроме индекса писать еще куда-то сырые данные. если совсем бигдата с hadoop то на hdfs в виде orc или parquet файликов с тучей партишенов. тогда из индекса юзер поучает списки активов, а детали уже берет с hdfs по jdbc какой-нить cloudera impala. если партиций достаточно много, а пользователей не столь много аля in memory + mpp енжин impala неплохо справится. попроще вариант писать детали просто в несколько mysql, просто во время записи в индекс из ид актива вычислять шарду и писать детали в нужный mysql инстанс. т.е. в индексе хранить на котором сервере(ах) детали. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 15:29 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
H5N1, В вашей схеме все останавливается на уровне баз данных, а у автора топика проблема (по сути) со средством отображения, вот раскидаете вы все на десятки mysql, нужно же еще показать данные пользователям в правильном и удобном виде. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 16:04 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб, А вы все партиции каждый раз процессите? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 16:16 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
T87, у нас для большинства таблиц партиционирование по дням, соответственно делаем ProcessData "сегодняшних" партиций, а потом ProcessRecalc всего куба, это все вместе занимает порядка трех часов. Критик, не получится, это и так данные только за неполные три года, а всего их есть лет за 20. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 17:32 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб, А если попробовать сократить объем данных исходя из бизнес-смысла? Например, контрагентов у вас 1 млн, из них 50% - скорее бывшие контрагенты, с которыми взаимодействовали (условно) 10 лет назад. А сейчас они просто висят в справочнике. Вынести их в отдельную сущность с тем же ключом, если будет по ним активность - автоматом переносить в основную сущность. И т.д. для всех больших измерений. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 18:14 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Критик, к сожалению все что можно было сократить уже сокращено, там реально миллион контрагентов. Основная проблема, с точки зрения Tabular, это безумная кардинальность в 200 миллионов. Я знаю что вы специалист по MS стеку, не первый год на форуме, но по моему тут просто ничего не улучшить. И в принципе, все в среднем довольны тем что нам удалось выжать из SSAS, по крайней мере раньше и такого никто не мог обеспечить, в этой теме я скорее думаю о завтрашнем дне. H5N1, если честно, не до конца понял что вы написали, потому что не со всем из перечисленного знаком, потому и отвечаю с задержкой - переваривал. :) По первой части, все понятно, у нас так ETL и организован, Kafka/Spark, только хранятся в итоге данные в Oracle. К этой части я отношения особо не имею. Я отвечаю за то что с данными происходит потом - когда они людям показываются. И вот с этого момента я не совсем понял. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 23:35 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Я же говорю, сложить всё в одну таблицу и чтобы было быстро - это кликхаус. Без кафки и спарка. Бесплатно и без обрезания исторических данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2020, 00:13 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб H5N1, если честно, не до конца понял что вы написали, потому что не со всем из перечисленного знаком, потому и отвечаю с задержкой - переваривал. :) По первой части, все понятно, у нас так ETL и организован, Kafka/Spark, только хранятся в итоге данные в Oracle. К этой части я отношения особо не имею. Я отвечаю за то что с данными происходит потом - когда они людям показываются. И вот с этого момента я не совсем понял. у вас судя по всему в оракл шли по сути сырые данные, соответственно если нужно что-то там по каким-то показателям отобрать, то в оракл уходят тяжелые агригирующие запросы. у меня же предложение кроме записи сырых данных агрегировать показатели в отдельном индексе - в спарке налету рассчитывать изменение цены за день, за неделю, месяц, продан до снижения и т.п. соответственно для выборки использовать показатели из индекса, а не запросы в оракл. я нечто такое видел как-то в проекте по оценке портфеля. грузились чужие данные, основные показатели писались в solr индекс, по нему пользователь говорил, что хочет прикинуть с ценами отсюда по сюда, только немецкие, и еще что-нить. приложение по индексу быстро отбирало схожие данные из давно выкупленных портфелей и говорило примерно, чего можно ждать от выбранного портфеля. можно было по итему посмотреть детали истории - историю доставали из impala. поскольку запрос в impala по деталям вел на конкретную партицию, работало достаточно быстро. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2020, 00:25 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб, Да, для этого есть новые технологии, называются NewSQL. Самый яркий представитель, как на меня, это MemSQL . Тут уже пару раз писали об ClickHouse - я думаю он еще сыроват, особенно в многомашинной конфигурации. Да и возможности запрсов подкачивают. Да MemSQL не бесплатен, но он того стоит. Даже на кластере из двух 16-и ядерных машин вы получите невероятный буст в производительности. Бесплатная версия из трех нод (агрегатор + 2 рабочих) вполне покажет что он может. База данных готова к петабайтной нагрузке, если что. Timeseries включены и даже ничего не надо делать, просто пишите SQL, оконные функци, все что вы привыкли делать с Oracle, при условии что вы используете MySQL диалект. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2020, 01:45 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Бумбараш, спасибо. С изучения этого мы и начнем, к тому же нагуглил случаи когда люди пытались подружить его с MS. H5N1, и вам спасибо, это примерно наш случай и есть, осталось разобраться что такое Solr ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2020, 09:20 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб H5N1, и вам спасибо, это примерно наш случай и есть, осталось разобраться что такое Solr Solr и elastic search под низом lucene индекс вроде имеют. Solr вроде более старый проект и заточен на java клиент, elastic более модный сейчас на rest api ориентируется. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2020, 12:52 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Бумбараш Я же говорю, сложить всё в одну таблицу и чтобы было быстро - это кликхаус. Без кафки и спарка. Бесплатно и без обрезания исторических данных. почему кликхаус, а не сноуфлек? или редшифт? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 19:02 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ivan Durak Бумбараш Я же говорю, сложить всё в одну таблицу и чтобы было быстро - это кликхаус. Без кафки и спарка. Бесплатно и без обрезания исторических данных. почему кликхаус, а не сноуфлек? или редшифт? потому что это базы данных, расположенные на территории потенциального противника ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 23:30 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Бумбараш потому что это базы данных, расположенные на территории потенциального противника Ivan Durak, про Snowflake и Redshift даже на этом форуме - всего с десяток упоминаний. Тяжело пока облака в России приживаются. А аналогов типа Яндекс.Снежинка / кликхаус или Мэйл.КрасныйРычаг / тарантул пока не так много, да и несколько непохожи они на указанные продукты. С Уважением, Георгий ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 10:07 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Решение пришло внезапно, и не со стороны технологии. Где-то высоко наверху, настолько, что я даже не знаю кто, решили, что у нас будет Snowflake. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2021, 00:38 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб, Вот так люди (возможно) не разбирающиеся в вопросе принимают решение на основе маркетинга - а потом с этим кому-то приходится возиться.. говорят у нас есть проект который реализовывался в течении года до MVP разными людьми разбросанными во времени на разных этапах процесса разработки.. естественно у каждого был свой опыт и предпочтения.. в результате разбросанными кусками висит на всех 3-х облаках (Azure AWS GCP) - видел только его 2 части, остальные связи теряются где-то за горизонтом в виде загадочных FQDN. другому директору под ML платформу продали SAS (договор, невозвратная оплата..) при отсутствии специалистов в компании - 2 года мучились пробуя прикрутить.. может и нормальный продукт - но сопротивление чувствовалось повсюду.. в общем списали в итоге.. в принципе говорят SnowFlake хороший продукт, но так сходу конечно без оценки интегрируемости с текущей структурой, ресурсов на поддержку/разработку .. иногда немного удивительно.. хотя они-же платят в итоге, так что чем больше/шире архитектура - тем нам как-бы и лучше? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2021, 02:06 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
vikkiv в принципе говорят SnowFlake хороший продукт А вопрос по специалистам настолько острый, что остается только открывать мануалы и курить их самому. С Уважением, Георгий ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2021, 09:25 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб Решение пришло внезапно, и не со стороны технологии. Где-то высоко наверху, настолько, что я даже не знаю кто, решили, что у нас будет Snowflake. в Госдепе, где же ещё захотите вы газ из северного потока, а вам сноуфлейк отключат ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2021, 17:06 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
я же говорил сноуфлейк надо брать. Поздравляю, хороший выбор. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2021, 17:57 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб, уж коли начали эту тему, не могли бы общественность держать в курсе проекта? Очень интересно, проектов по SF раз, два и обчелся. С нас два барреля, как обычно. Ну и советом, кто во что горазд С Уважением, Георгий ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2021, 09:20 |
|
|
Start [/forum/topic.php?fid=49&msg=40003721&tid=1857061]: |
0ms |
get settings: |
31ms |
get forum list: |
10ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
56ms |
get topic data: |
16ms |
get forum data: |
4ms |
get page messages: |
1047ms |
get tp. blocked users: |
2ms |
others: | 182ms |
total: | 1360ms |
0 / 0 |