powered by simpleCommunicator - 2.0.16     © 2024 Programmizd 02
Map
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Не биг ли это дата?
25 сообщений из 46, страница 1 из 2
Не биг ли это дата?
    #40003694
Ибн Хоттаб
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Делаем сейчас один проект. Хранилище с одной стороны как хранилище, в нем две фактовые таблицы, каждая порядка единиц миллиардов записей, но дальше начинаются нюансы: основное измерение для этих фактовых таблиц одно, и его кардинальность сейчас - около 200 миллионов, к нему подключаются остальные измерения, которых немало, из них выделяется измерение контрагентов, кардинальность которого больше миллиона, а используется оно 13 раз в разных ролях. Все измерения историчные. Экономический смысл всего этого такой: то чего 200 миллионов - это активы, которые приносят прибыли и убытки, в фактовых таблицах события, например изменения количественных параметров этих активов в некие моменты времени, например цены за которые из можно было бы в тот момент продать, или прибыль, которую актив сгенерировал, или цена за которую его реально купили/продали. Типичный сценарий использования такой: по некоторым параметрам, типа сгенерировал мало/много прибыли за период времени, не был продан до снижения цены, резко изменилась его рыночная цена, ищутся активы или их группы, а потом анализируется история каждого по отдельности, кто с ним работал, какие решения принимал и так далее. Еще стоит отметить, что данные залетают туда довольно часто, каждые несколько минут, и количество новых строк может быть порядка миллионов в день, в среднем около миллиона.

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

И вот мне подумалось, что не подходящий ли это случай для бигдатных технологий? Типа сложить все атрибуты в одну "таблицу", разложить ее на несколько серверов (мощнее чем вышеуказанный мы не можем получить, но несколько таких или меньших - вполне), и прочесывать ее ими параллельно. Придумали уже что-то такое? ActivePivot не предлагать, у нас есть на него лицензия, но у него свои заморочки, и как результат не очень хорошая репутация в организации.
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40003712
Бумбараш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
придумали, это clickhouse
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40003721
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ибн Хоттаб,

А может стоит просто договориться с бизнесом и сделать архивный куб, куда слить все, что старше N лет?
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40003995
Полковник.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ибн Хоттаб,
Для начала надо бы понять что с вашим ораклом все в порядке, а потом уже фантазировать на тему бигдаты. Да и вообще бигдата это не про то, что вы тут понаписали, начинается пустая бегатня по технологиям...
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40004027
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ибн Хоттаб,

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

В вашей схеме все останавливается на уровне баз данных, а у автора топика проблема (по сути) со средством отображения, вот раскидаете вы все на десятки mysql, нужно же еще показать данные пользователям в правильном и удобном виде.
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40004048
T87
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ибн Хоттаб,

А вы все партиции каждый раз процессите?
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40004079
Ибн Хоттаб
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
T87, у нас для большинства таблиц партиционирование по дням, соответственно делаем ProcessData "сегодняшних" партиций, а потом ProcessRecalc всего куба, это все вместе занимает порядка трех часов.

Критик, не получится, это и так данные только за неполные три года, а всего их есть лет за 20.
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40004100
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ибн Хоттаб,

А если попробовать сократить объем данных исходя из бизнес-смысла?
Например, контрагентов у вас 1 млн, из них 50% - скорее бывшие контрагенты, с которыми взаимодействовали (условно) 10 лет назад. А сейчас они просто висят в справочнике. Вынести их в отдельную сущность с тем же ключом, если будет по ним активность - автоматом переносить в основную сущность.
И т.д. для всех больших измерений.
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40004157
Ибн Хоттаб
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критик, к сожалению все что можно было сократить уже сокращено, там реально миллион контрагентов. Основная проблема, с точки зрения Tabular, это безумная кардинальность в 200 миллионов. Я знаю что вы специалист по MS стеку, не первый год на форуме, но по моему тут просто ничего не улучшить. И в принципе, все в среднем довольны тем что нам удалось выжать из SSAS, по крайней мере раньше и такого никто не мог обеспечить, в этой теме я скорее думаю о завтрашнем дне.

H5N1, если честно, не до конца понял что вы написали, потому что не со всем из перечисленного знаком, потому и отвечаю с задержкой - переваривал. :) По первой части, все понятно, у нас так ETL и организован, Kafka/Spark, только хранятся в итоге данные в Oracle. К этой части я отношения особо не имею. Я отвечаю за то что с данными происходит потом - когда они людям показываются. И вот с этого момента я не совсем понял.
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40004162
Бумбараш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я же говорю, сложить всё в одну таблицу и чтобы было быстро - это кликхаус. Без кафки и спарка. Бесплатно и без обрезания исторических данных.
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40004164
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ибн Хоттаб

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

у вас судя по всему в оракл шли по сути сырые данные, соответственно если нужно что-то там по каким-то показателям отобрать, то в оракл уходят тяжелые агригирующие запросы.
у меня же предложение кроме записи сырых данных агрегировать показатели в отдельном индексе - в спарке налету рассчитывать изменение цены за день, за неделю, месяц, продан до снижения и т.п. соответственно для выборки использовать показатели из индекса, а не запросы в оракл.
я нечто такое видел как-то в проекте по оценке портфеля. грузились чужие данные, основные показатели писались в solr индекс, по нему пользователь говорил, что хочет прикинуть с ценами отсюда по сюда, только немецкие, и еще что-нить. приложение по индексу быстро отбирало схожие данные из давно выкупленных портфелей и говорило примерно, чего можно ждать от выбранного портфеля. можно было по итему посмотреть детали истории - историю доставали из impala. поскольку запрос в impala по деталям вел на конкретную партицию, работало достаточно быстро.
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40004166
Dansoid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ибн Хоттаб,

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

Да MemSQL не бесплатен, но он того стоит. Даже на кластере из двух 16-и ядерных машин вы получите невероятный буст в производительности. Бесплатная версия из трех нод (агрегатор + 2 рабочих) вполне покажет что он может. База данных готова к петабайтной нагрузке, если что. Timeseries включены и даже ничего не надо делать, просто пишите SQL, оконные функци, все что вы привыкли делать с Oracle, при условии что вы используете MySQL диалект.
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40004187
Ибн Хоттаб
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бумбараш, спасибо. С изучения этого мы и начнем, к тому же нагуглил случаи когда люди пытались подружить его с MS.

H5N1, и вам спасибо, это примерно наш случай и есть, осталось разобраться что такое Solr
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40004241
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ибн Хоттаб


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


Solr и elastic search под низом lucene индекс вроде имеют. Solr вроде более старый проект и заточен на java клиент, elastic более модный сейчас на rest api ориентируется.
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40010986
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бумбараш
Я же говорю, сложить всё в одну таблицу и чтобы было быстро - это кликхаус. Без кафки и спарка. Бесплатно и без обрезания исторических данных.

почему кликхаус, а не сноуфлек? или редшифт?
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40011046
Бумбараш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan Durak
Бумбараш
Я же говорю, сложить всё в одну таблицу и чтобы было быстро - это кликхаус. Без кафки и спарка. Бесплатно и без обрезания исторических данных.

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

потому что это базы данных, расположенные на территории потенциального противника
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40011103
Фотография George Nordic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бумбараш
потому что это базы данных, расположенные на территории потенциального противника
Кафедру МИРЭА военную чувствую я...

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

С Уважением,
Георгий
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40041884
Ибн Хоттаб
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Решение пришло внезапно, и не со стороны технологии. Где-то высоко наверху, настолько, что я даже не знаю кто, решили, что у нас будет Snowflake.
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40041905
Фотография vikkiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ибн Хоттаб,

Вот так люди (возможно) не разбирающиеся в вопросе принимают решение на основе маркетинга - а потом с этим кому-то приходится возиться..
говорят у нас есть проект который реализовывался в течении года до MVP разными людьми разбросанными во времени на разных этапах процесса разработки..
естественно у каждого был свой опыт и предпочтения..
в результате разбросанными кусками висит на всех 3-х облаках (Azure AWS GCP) - видел только его 2 части, остальные связи теряются где-то за горизонтом в виде загадочных FQDN.
другому директору под ML платформу продали SAS (договор, невозвратная оплата..) при отсутствии специалистов в компании - 2 года мучились пробуя прикрутить.. может и нормальный продукт - но сопротивление чувствовалось повсюду.. в общем списали в итоге..

в принципе говорят SnowFlake хороший продукт, но так сходу конечно без оценки интегрируемости с текущей структурой, ресурсов на поддержку/разработку .. иногда немного удивительно.. хотя они-же платят в итоге, так что чем больше/шире архитектура - тем нам как-бы и лучше?
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40041940
Фотография George Nordic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vikkiv
в принципе говорят SnowFlake хороший продукт
Кстати, да. Наши клиенты очень хвалят, причем многие из них используют SF не для аналитики, а для решения оптимизационных задач. Ну, значит, прямая дорога и в Attunity, как к лучшему партнеру SnowFlake - так у них есть специальное решение по загрузке данных в их облако . Кстати, у них своих ЦОДов нет - они на AWS.

А вопрос по специалистам настолько острый, что остается только открывать мануалы и курить их самому.

С Уважением,
Георгий
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40042254
Бумбараш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ибн Хоттаб
Решение пришло внезапно, и не со стороны технологии. Где-то высоко наверху, настолько, что я даже не знаю кто, решили, что у нас будет Snowflake.


в Госдепе, где же ещё
захотите вы газ из северного потока, а вам сноуфлейк отключат
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40043431
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я же говорил сноуфлейк надо брать.

Поздравляю, хороший выбор.
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40043532
Фотография George Nordic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ибн Хоттаб, уж коли начали эту тему, не могли бы общественность держать в курсе проекта? Очень интересно, проектов по SF раз, два и обчелся. С нас два барреля, как обычно. Ну и советом, кто во что горазд

С Уважением,
Георгий
...
Рейтинг: 0 / 0
Не биг ли это дата?
    #40043648
Ибн Хоттаб
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бумбараш, Мы по газу - чистый экспортер :) И по нефти пока тоже.

George Nordic, Да, я напишу что получится.
...
Рейтинг: 0 / 0
25 сообщений из 46, страница 1 из 2
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Не биг ли это дата?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]