Начал пробовать 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 драйверу.

Таковы итоги первого дня.

Приключение продолжается. Удалось настроить соединение с Snowflake, теперь это выглядит так: SSAS подключается к Snowflake как линкед серверу в MS SQL, через OLE ODBC провайдер, берет оттуда данные, в import mode, ну и все. Это не совсем то что я себе представлял, однако SSAS Tabular в DirectQuery mode не может получить никаких преимуществ по той простой причине, что не умеет динамически формировать запросы. Ему же надо сначала прочитать партицию, жестко определенную, единственную, потому что больше одной DQ нельзя использовать. А если в той партиции терабайт данных, то и выполнять любой запрос он будет не меньше времени чем требуется чтобы вычитать терабайт данных.

Ivan Durak, Я не в стартапе каком-то модном работаю, а в системно значимом банке :) Забивать гвозди чем попало - это наше все, миграция - хлеб, реструктуризация - масло, еще есть икра, но NDA не позволяет рассказать что это. Потому и 3 месяца перерыв между сообщениями, потому и SSAS + Snowflake.

sergeyns, Я простой ведущий четототам эксперт, мне таких вещей знать не полагается. Мне полагается выживать в условиях массового применения жестоких и необычных способов использования программного обеспечения. Не с моими рабоче-крестьянскими мозгами пытаться проникнуть в замыслы энтерпрайз архитектов в странных, на вид неудобных костюмах, медленно, неуклюже и причудливо пишущих бесформенные кошмарные архитектурные документы в непостижимых темных оупенспэйсах вне времени. Я могу только предполагать, что идея заключается в том, что когда, и если, данные клубясь и бурля переползут в Snowflake, все эти сотни терабайт, которые сейчас в Oracle, MS SQL, DB2, Teradata и множестве нереляционных последствий попыток внедрения всякой фигни, то наступит светлое будущее, и миграция на какое-то BI средство поверх, неизвестное мне, облачное, недосягаемо величественное, не имеющее аналогов в мире, и все такое.

Насчет опасности облаков, да, Snowflake не бывает on premise, я не знаю как они там договорились, но факт, у нас появилось первое облачное хранилище, а ведь еще всего только 2021 год на дворе.

В предыдущих сериях *музыка из Игры Престолов, или Бригады, на выбор*. Менеджеры проекта кажется начали что-то подозревать, к этому их подтолкнула необходимость заказывать серваки с памятью терабайтных объемов, которые все равно не вместят все данные, которые бизнес хочет хранить. Как же так, спраживают они, получается мы весь мусор сбрасываем в хоронилище на 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, вот и узнаю.

Прошел 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, (будет) доступен бесплатно.

2wheels, Есть RSA. Спасибо, вопросы непременно будут.


Продолжение сериала. Все вроде как приходит к тому, о чем я и говорил в изначальном посте этой темы. Данные складываются в одну таблицу в Snowflake, точнее по одной на каждую предметную область, а потом используются двумя способами, оба извращенные, но с перспективой лечения. Первый способ: они заливаются из Snowflake в SSAS в память, при таком раскладе только подмножество, потому что память не резиновая. В таком случае Snowflake используется просто как среда хранения, однако по сравнению с тем что было до того, Oracle и MS SQL, есть преимущества по скорости заливки. Второй способ интереснее: directQuery. С ним есть проблемы, например то что официально коннектора, который бы позволял использовать directQuery со Snowflake нет ни для SSAS, ни для PBI Server. Пока это решается через линкед сервер, с потерей производительности, но приезжал тут культпросвет и сказали, что рано или поздно каждому дадут по PBI в облаке, по 12 квадратных серверов на лицо, к 2030 году уж точно, и будет там в облаке и горячая вода, и центральное отопление, и xmla endpoint, и даже directQuery и гибридные модели.

Они работают с десктопом и в облаке, с сервером on premise нет.