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

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

И вот мне подумалось, что не подходящий ли это случай для бигдатных технологий? Типа сложить все атрибуты в одну "таблицу", разложить ее на несколько серверов (мощнее чем вышеуказанный мы не можем получить, но несколько таких или меньших - вполне), и прочесывать ее ими параллельно. Придумали уже что-то такое? ActivePivot не предлагать, у нас есть на него лицензия, но у него свои заморочки, и как результат не очень хорошая репутация в организации.

T87, у нас для большинства таблиц партиционирование по дням, соответственно делаем ProcessData "сегодняшних" партиций, а потом ProcessRecalc всего куба, это все вместе занимает порядка трех часов.

Критик, не получится, это и так данные только за неполные три года, а всего их есть лет за 20.

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

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

Бумбараш, спасибо. С изучения этого мы и начнем, к тому же нагуглил случаи когда люди пытались подружить его с MS.

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

Решение пришло внезапно, и не со стороны технологии. Где-то высоко наверху, настолько, что я даже не знаю кто, решили, что у нас будет Snowflake.

Бумбараш, Мы по газу - чистый экспортер :) И по нефти пока тоже.

George Nordic, Да, я напишу что получится.

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