|
Не биг ли это дата?
|
|||
---|---|---|---|
#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 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Бумбараш, Мы по газу - чистый экспортер :) И по нефти пока тоже. George Nordic, Да, я напишу что получится. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2021, 13:30 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб George Nordic, Да, я напишу что получится. Спасибо! Если триалка на attunity будет нужна - обращайтесь, попробую выбить. В synapse уже вовсю льем, есть проекты в РФ. в SF не пробовали. Но, думаю, и бесплатными можно попробовать, nifi там, например. С Уважением, Георгий ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2021, 14:08 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Начал пробовать Snowflake. Первое впечатление - в высшей степени странное поделие. Очень напоминает ActivePivot в самом что ни на есть нехорошем смысле. Дают сразу доступ через веб интерфейс, в нем можно делать запросы к каким-то тестовым наборам данных, ни о чем. Далее оказывается, что условно родной коннектор есть только для PowerBI, SSAS может коннектиться только через ODBC. Причем почему-то только через 32-битный. Сам интерфейс настройки ODBC драйвера напоминает поделку студента (и ранний Apache Kylin). Там поля одинакового размера и кнопка ОК снизу. Все поля - это просто текстовые поля, такого типа вбил сервер выбери базы из имеющихся нету. Кнопки Test connection нету, проверить на этом этапе правильно ли вбиты данные невозможно, в поле proxy ожидаемый формат строки предполагает указание логина и пароля прямым текстом. Мне корректно заполнить эту форму с первого раза не удалось - оказалось что в одном из полей нужно написать заклинание externalbrowser, иначе не работает. То что не работает видно из сообщения об ошибке в PowerBI/SSAS вида многонепонятныхбуквSSLErrorмногонепонятныхбукв. То что против этого помогает заклинание externalbrowser, именно так, маленькими буквами в одно слово, вбитое в определенное поле, мне подсказали специально обученные индийские мудрецы, сам я, конечно, такого уровня просветления не достиг. Отдельным абзацем упомяну шифрование, чтобы его обеспечить нужно совершенно ритуальным образом получить сертификат и скопипастить его (1500 байт) в текстовый файл cacert.pem, который лежит в определенной подпапке той папки куда встал ODBC-драйвер. По умолчанию эта папка доступна на запись только администратору, но для низших каст есть особый ритуал - скопировать этот файл в другое место (доступное), скопипастить туда сертификат, а потом при настройке соединения в Excel/PowerBI/SSAS в connection parameters добавлять путь к своему суррогатному файлу. Причем в случае SSAS, если сделать Script as.. connection'а, этот параметр заменяется звездочками и как он должен правильно выглядеть в XMLA непонятно. ODBC драйвер работает невиданным мною ранее образом: он отправляет REST запросы на Snowflake сервер открывая при этом окно браузера с URL типа сервер:каждый_раз_новый_порт/token=многомногобукв. В моей мегамодели берущей данные из Snowflake одна таблица, на источнике в ней 6 строк и 3 колонки, чтобы ее отпроцессить таких запросов отправляется штук 10 и занимает это пару минут. Сперва я пытался настроить соединение с SSAS сервера, то есть, используя в качестве workspace для VS нормальный SSAS, с установленным ODBC драйвером Snowflake. Это мне не удалось, при том что PowerBI и Excel с того же сервера работали. Тогда я попробовал integrated workspace, на той же машине, и он заработал. Открывая окна браузера при каждом обращении к Snowflake драйверу. Таковы итоги первого дня. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2021, 00:50 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб Начал пробовать Snowflake ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2021, 14:34 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Приключение продолжается. Удалось настроить соединение с Snowflake, теперь это выглядит так: SSAS подключается к Snowflake как линкед серверу в MS SQL, через OLE ODBC провайдер, берет оттуда данные, в import mode, ну и все. Это не совсем то что я себе представлял, однако SSAS Tabular в DirectQuery mode не может получить никаких преимуществ по той простой причине, что не умеет динамически формировать запросы. Ему же надо сначала прочитать партицию, жестко определенную, единственную, потому что больше одной DQ нельзя использовать. А если в той партиции терабайт данных, то и выполнять любой запрос он будет не меньше времени чем требуется чтобы вычитать терабайт данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2021, 14:55 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
snowflake+ssas это антипаттерн. Сноуфлейк нужен именно для того чтобы заменить mssql+ssas целиком. В этом его смысл. Забивать им гвозди смысла ноль ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2021, 15:32 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ivan Durak, Я не в стартапе каком-то модном работаю, а в системно значимом банке :) Забивать гвозди чем попало - это наше все, миграция - хлеб, реструктуризация - масло, еще есть икра, но NDA не позволяет рассказать что это. Потому и 3 месяца перерыв между сообщениями, потому и SSAS + Snowflake. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2021, 15:50 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб, Спасибо, очень познавательно и интересно. А как вообще Snowflake может быть в системно-значащем банке? А если враги таки решаться отключить облако??? Он же (SF) вроде не умеет on premise , или все таки умеет? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2021, 09:18 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
sergeyns, Я простой ведущий четототам эксперт, мне таких вещей знать не полагается. Мне полагается выживать в условиях массового применения жестоких и необычных способов использования программного обеспечения. Не с моими рабоче-крестьянскими мозгами пытаться проникнуть в замыслы энтерпрайз архитектов в странных, на вид неудобных костюмах, медленно, неуклюже и причудливо пишущих бесформенные кошмарные архитектурные документы в непостижимых темных оупенспэйсах вне времени. Я могу только предполагать, что идея заключается в том, что когда, и если, данные клубясь и бурля переползут в Snowflake, все эти сотни терабайт, которые сейчас в Oracle, MS SQL, DB2, Teradata и множестве нереляционных последствий попыток внедрения всякой фигни, то наступит светлое будущее, и миграция на какое-то BI средство поверх, неизвестное мне, облачное, недосягаемо величественное, не имеющее аналогов в мире, и все такое. Насчет опасности облаков, да, Snowflake не бывает on premise, я не знаю как они там договорились, но факт, у нас появилось первое облачное хранилище, а ведь еще всего только 2021 год на дворе. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2021, 11:14 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
как же так, неужели в божественных западных банках такой же распил на технологиях не может быть, ах, ох ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2021, 11:56 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб Oracle, MS SQL, DB2, Teradata Ибн Хоттаб Мне полагается выживать в условиях массового применения жестоких и необычных способов использования программного обеспечения. Не с моими рабоче-крестьянскими мозгами пытаться проникнуть в замыслы энтерпрайз архитектов в странных, на вид неудобных костюмах, медленно, неуклюже и причудливо пишущих бесформенные кошмарные архитектурные документы в непостижимых темных оупенспэйсах вне времени. С Уважением, Георгий ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2021, 12:03 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Случайно заметил боковым зрением что Моша закончил в Google с BigQuery, ушел "работать" CTO в FireBolt уже как с пару месяцев.. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.08.2021, 02:25 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
В предыдущих сериях *музыка из Игры Престолов, или Бригады, на выбор*. Менеджеры проекта кажется начали что-то подозревать, к этому их подтолкнула необходимость заказывать серваки с памятью терабайтных объемов, которые все равно не вместят все данные, которые бизнес хочет хранить. Как же так, спраживают они, получается мы весь мусор сбрасываем в хоронилище на Snowflake, а потом весь тот же мусор, считая всеми любимую колонку Address_line_5, пытаемся залить в SSAS, может можно сделать как-то по другому? Тем временем, в параллельном измерении (на другом этаже), в процессе исследования альтернативных способов показывать те же данные из Snowflake зафиксировано восстание машин: State: HY000. Code: 43119. [nQSError: 43119] Query Failed: (HY000) State: HY000. Code: 16001. [nQSError: 16001] ODBC error state: 42000 code: 904 message: SQL compilation error: error line 1 at position 16 invalid identifier 'T111111.SHORT_NAME'. (HY000) State: HY000. Code: 16014. [nQSError: 16014] SQL statement preparation failed. (HY000) SQL Issued: SELECT 0 s_0, "SNOWTEST"."Dim_counterparty_alias"."SHORT_NAME" s_1 FROM "SNOWTEST" FETCH FIRST 65001 ROWS ONLY А если конкретно: [2093-08-20T09:26:15.580+11:00] [OBIS] [TRACE:2] [] [] [ecid: ] [sik: ssi] [tid: 23c0] [messageid: USER-111111] [requestid: 8fd000d] [sessionid: 8fd0000] [username: ******] -------------------- Sending query to database named SNOWTEST (id: <<807087>>), connection pool named SNOWPOOL, logical request hash ebf17fb0, physical request hash 5d5e629d: [[ select distinct T111111."SHORT_NAME" as c1 from "DIM_COUNTERPARTY" T111111 ]] [2093-08-20T09:26:16.330+11:00] [OBIS] [TRACE:2] [] [] [ecid: ] [sik: ssi] [tid: 23c0] [messageid: USER-222222] [requestid: 8fd000d] [sessionid: 8fd0000] [username: ******] -------------------- Query Status: [nQSError: 16014] SQL statement preparation failed. [[ [nQSError: 16001] ODBC error state: 42000 code: 904 message: SQL compilation error: error line 1 at position 16 invalid identifier 'T111111.SHORT_NAME'. [nQSError: 43119] Query Failed: ]] Выглядит так, что в Snowflake SQL нельзя "DIM_COUNTERPARTY" T111111, как Oracle BI любит. Хотя может это и ошибочное впечатление, на следующей неделе записали меня на добровольно-обязательное обучение по Snowflake, вот и узнаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2021, 10:52 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб, интересный сериал. ждем нового сезона. ssas на оракле после лейка на snowflake финал может быть совсем неожиданным ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2021, 11:50 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Прошел 4-дневный курс молодого снеговика. Выдали табельную морковку в pdf формате. Удалось подключить SSAS к Snowflake, пишу "удалось" потому что это не какой-то там простой процесс: 1) Путаница с драйверами. Есть 32 и 64 бита, оказалось что надо ставить оба, причем в определенной последовательности. 2) Головоломка с SSH, надо править регистри. 3) Головоломка с AuthenticationKind. 4) Native query is not supported, похожая проблема наблюдалась с BigQuery. Попутно разобрался с подключением OBIEE, та же проблема что и п.4 выше, но решается в настройках. Производительность на 2XL warehouse впечатляющая получилась, агрегация по 4 измерениям из таблицы на 200 млн строк 2-3 секунды. А есть ведь еще болше XL. Попробовал подключить Qlikview (десктоп v.12.5) если в память грузить все как обычно, Direct Discovery почему то не работает, no rows пишет. Ну и наконец, после длительной медитации я увидел будущее. Это поразительно насколько далеко может завести людей жадность - они способны разработать аж целый собственный BI, только чтобы не вынимать свои руки из чужих карманов. Называется Snowsight, (будет) доступен бесплатно. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 15:32 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб, если будт вопросы по Snowflake, буду рад помочь. У вас RSA есть или всё сами? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2021, 13:09 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Сделайте нормальное партиционирование и не нервничайте. Внедрения биг даты тут лучше избегать, пока возможно - просто поверьте на слово - начнёте внедрять биг дату - во первых это затянется, во вторых с первого раза сделаете криво, в третих - биг дата тут не нужна просто... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 02:44 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
2wheels, Есть RSA. Спасибо, вопросы непременно будут. Продолжение сериала. Все вроде как приходит к тому, о чем я и говорил в изначальном посте этой темы. Данные складываются в одну таблицу в Snowflake, точнее по одной на каждую предметную область, а потом используются двумя способами, оба извращенные, но с перспективой лечения. Первый способ: они заливаются из Snowflake в SSAS в память, при таком раскладе только подмножество, потому что память не резиновая. В таком случае Snowflake используется просто как среда хранения, однако по сравнению с тем что было до того, Oracle и MS SQL, есть преимущества по скорости заливки. Второй способ интереснее: directQuery. С ним есть проблемы, например то что официально коннектора, который бы позволял использовать directQuery со Snowflake нет ни для SSAS, ни для PBI Server. Пока это решается через линкед сервер, с потерей производительности, но приезжал тут культпросвет и сказали, что рано или поздно каждому дадут по PBI в облаке, по 12 квадратных серверов на лицо, к 2030 году уж точно, и будет там в облаке и горячая вода, и центральное отопление, и xmla endpoint, и даже directQuery и гибридные модели. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 11:39 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ибн Хоттаб официально коннектора, который бы позволял использовать directQuery со Snowflake нет ни для SSAS, ни для PBI Server. Все интернеты пестрят темами о том что таки конектор есть для PBI https://www.mssqltips.com/sqlservertutorial/9293/power-bi-and-snowflake/ или https://docs.microsoft.com/en-us/power-bi/connect-data/desktop-connect-snowflake ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 18:16 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ivan Durak Все интернеты пестрят темами о том что таки конектор есть для PBI https://www.mssqltips.com/sqlservertutorial/9293/power-bi-and-snowflake/ или https://docs.microsoft.com/en-us/power-bi/connect-data/desktop-connect-snowflake наверняка как с mariadb (mysql) есть только для десктопа, а на gateway коннектора нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 19:03 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
vikkiv Случайно заметил боковым зрением что Моша закончил в Google с BigQuery, ушел "работать" CTO в FireBolt уже как с пару месяцев.. Название огонь) интересно, взлетит ли ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 19:27 |
|
Не биг ли это дата?
|
|||
---|---|---|---|
#18+
Ivan Durak Ибн Хоттаб официально коннектора, который бы позволял использовать directQuery со Snowflake нет ни для SSAS, ни для PBI Server. Все интернеты пестрят темами о том что таки конектор есть для PBI https://www.mssqltips.com/sqlservertutorial/9293/power-bi-and-snowflake/ или https://docs.microsoft.com/en-us/power-bi/connect-data/desktop-connect-snowflake Они работают с десктопом и в облаке, с сервером on premise нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2021, 11:10 |
|
|
Start [/forum/topic.php?all=1&fid=49&tid=1857061]: |
0ms |
get settings: |
22ms |
get forum list: |
11ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
44ms |
get topic data: |
15ms |
get forum data: |
3ms |
get page messages: |
1510ms |
get tp. blocked users: |
2ms |
others: | 212ms |
total: | 1829ms |
0 / 0 |