Всем добрый день.
Пытаюсь сделать так, чтобы в msas можно было создать rolap куб, смотрящий на hive (big data). К сожалентю не вижу oledb провайдеров до hive, а odbc не поддерживается в msas.

Вопрос: как пройти эту стенку?

Дедушка,

читал я эту статью. Майкрософт не хочет поддерживать в студии своей свой родной драйвер
OLE DB Provider for ODBC, который у них есть с непотятно каких времен.
Почему не поддерживают - мне лично не понятно.

Поэтому эти ребята пошли через ж...: они сделали linked server на SQL Server-е, который работает
через "MS OLE DB Provider for ODBC", а потом из analysis лезут на этот linked server.

А теперь смотрите фокус на картинке ниже.
Оказывается, сторонний производитель может нормально сделать OLEDB мост на ODBC.

Но все-таки там есть какая-то проблемка в самом analysis - читайте следующий пост.

вот что получаю при попытке добавить таблицу в DSV

насколько я понял, из папки D:\DATA\SQL2008\MSAS10_50.SQL2008\OLAP\bin\Cartridges\
используется какой-то из картриджей, что по сути представляет из себя трансформатор в SQL из XML-я DSV.

И ясно, что analysis использует не тот картридж.

Если посмотреть в каждый картридж, то там есть строчки




что-то типа "используй меня, если провайдер называется начиная с ...".
И понятно, что надо просто сделать аналогичный.

Идеи по тому, как это сделать, у меня есть. Сейчас главный вопрос - как отследить то, какой SQL ушел на Hive...

Критик,

см. картинку.

я то почему-то начинаю догадываться почему оно так.

DSV любит делать врапперы типа

select * from (select * from table)

где внутри - ваш запрос, а вовне - еще один селект. Но такое работать на Hive не будет, потому что Hive любит чтобы было имя в подселекта, например

select * from (select * from table) x

Но это гипотеза. Я пока-что как слепой - не вижу какие SQl запросы уходят на Hive.
Можете подсказать где аналог SQL Profiler?

Критик, спасибо.
В аттаче - ODBC трасса.

В ней я не вижу прямого текста запроса select * from webloganalytics

хотя название самой таблицы webloganalytics встречается.
Такое ощущение, что SQL запрос "разбирает" на куски сам ODBC, или же студия перед тем, как послать запрос, вместо того, чтобы его просто послать, делает разбор селекта и пытается вытянуть еще какую-то информацию о таблице (типа метаданных или что-то в этом роде).

Вижу в трассе ODBC

devenv 1f08-1d54 ENTER SQLTablesW
HSTMT 0x0376FAF0
WCHAR * 0x0015BAB0 [ -3] "hive\ 0"
SWORD -3
WCHAR * 0x00000000 <null pointer>
SWORD -3
WCHAR * 0x0015BEB0 [ -3] "webloganalytics\ 0"
SWORD -3
WCHAR * 0x00000000 <null pointer>
SWORD -3


дальше идет текст типа DESC TABLE, DESC TYPE (отсюда и догадываюсь, что студия все-таки запрашивает метаданные таблицы),

видно, что возвращается список полей с описаниями


а потом вдруг

devenv 1f08-1d14 EXIT SQLSetStmtOption with return code -1 (SQL_ERROR)
HSTMT 0x0377B288
UWORD 12 <SQL_USE_BOOKMARKS>
SQLPOINTER 1 <SQL_UB_ON>

DIAG [HY024] [Hortonworks][ODBC] (10280) Invalid attribute value. (10280)


Оно как бы похоже на то, что Hive не знает что такое SQL_USE_BOOKMARKS.
То есть, либо devenv не имеет права спрашивать SQL_USE_BOOKMARKS (потому что devenv должен знать, что это нельзя спрашивать), либо же реализация ODBC драйвера хреновая.

Надо читать как работает ODBC чтобы понять что такое SQL_USE_BOOKMARKS

Блин, вот паззл....

здесь http://msdn.microsoft.com/en-us/library/ms716496(v=vs.85).aspx
вижу

The SQL_GET_BOOKMARK statement option has been deprecated in ODBC 3.x. For an ODBC 3.x driver to work with ODBC 2.x applications that use SQL_GET_BOOKMARK, it must support SQL_GET_BOOKMARK. For an ODBC 3.x driver to work with ODBC 2.x applications, it must support setting SQL_USE_BOOKMARKS to SQL_UB_ON and should expose fixed-length bookmarks


То есть, похоже на то, что разработчики Hive сделали свой ODBC драйвер по формату ODBC 3.x., а вот дядьки из OpenLink, которые писали OLEDB to ODBC Bridge (которым я пользуюсь) рассчитывают на стандарт ODBC 2.x.

Не знаю насколько это все логично, но надо теперь выяснять в разработчиков бриджа.

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

Может кто-нибуть подскажет какой-то другой переходник от OLEDB в ODBC?

Критик,

я это уже понял.

Написал пост в форум OpenLink
http://boards.openlinksw.com/support/viewtopic.php?f=8&t=6335
буду ждать что они ответят.

Здесь одно из трех:
а) либо накосячили разработчики Hive
б) либо накосячили разработчики ODBC драйвера к hive
в) либо накосячили OpenLink - не смотрят на то, какая версия ODBC драйвера, и пускают не ту команду.

Сейчас уже поздно, у меня голова не варит хорошо, чтобы понять где именно баг. Но то, что он есть - это точно.

К стати, менял Hortonworks ODBC for Hive на Microsoft ODBC for Hive и на Cloudera ODBC for Hive - результат тот же.

Критик,

да вот знаете что странно, это то, что если екселем напрямую коннектится - то он успешно берет данные из ТОЙ ЖЕ таблицы, которую я пытаюсь добавить в студии.

И вот смотрим вторую трассу - см. аттач.

Нету в ней вызовов
SQLSetStmtOption SQL_USE_BOOKMARKS
SQLGetDiagRecW SQL_HANDLE_STMT

на которых собственно ODBC драйвер и вылетает с ошибкой
[Hortonworks][ODBC] (10280) Invalid attribute value


То есть, получается, что этот "универсальный" OLEDB to ODBC Bridge от OpenLink делает что-то лишнее, чего мог бы и не делать (ну раз екселю этого не надо делать, чтобы взять данные, то зачем это openlink-мосту?)

Тут или кланяться openlink-ам и просить их исправить (или параметр добавить) чтобы команды не посылались,

или попробовать найти сорсы Hive ODBC (подозреваю, что они общие, ибо летит то-же самое и в Майкрософтовском ODBC) и поправить эти сорсы, чтобы тупо игнорировали эти ненужные команды,

или обращаться к разработчикам ODBC и просить, чтобы поддержку этих штук обеспечили (что понятно, что маловероятно).

Пока что не знаю что легче всего, и что даст результат.

Если посмотреть сюда
https://cwiki.apache.org/confluence/display/Hive/HiveODBC#HiveODBC-BuildingandSettingUpODBCComponents

то написано черным по белому

SQLSetStmtOption - NOT supported

Я понимаю, что Hortonworks и Simba вместе делали свою альтернативную версию, но не думаю, что они бы добавляли поддержку этой команды. Я думаю они занимались только оптимизацией.

Ну а эту команду точно запускает openlink oledb to odbc bridge.

Другой вопрос: зачем он это делает? то ли от безисходства (если от devenv.exe через OLEDB идет запрос "сделай что-то вот такое", то и мост имеет какой-то алгоритм, который этот запрос пытается трансформировать в ODBC вызовы), то ли от неправильного алгоритма. Скорее второе, потому что Ексель, который напрямую идет на ODBC, почему-то не собирается эту команду дергать, и ему хватает всего.

На утро пришла мне в голову альтернативная идея: а что если использовать родной .NET Data Provider for ODBC вместо сторонних OLEDB for ODBC?

Но есть одна незадачка - см. картинку: почему-то в Analysis Services .NET Data provider for ODBC не отображается.

Если проводить параллель с .NET Data provider for Vertica (который есть и там, и там), то можно сделать один вывод: есть какой-то интерфейс, который классы вертики ("C:\Program Files (x86)\Vertica Systems\ADO.NET\Vertica.Data.dll" ) имплементируют и выставляют во внешний мир, в то время как у стандартного .net data provider for odbc его нет.

Самое простое, что можно сделать - это написать класс-враппер над Майкрософтовским .NET Data Provider for ODBC (используя его же внутри) и выставвить нужный интерфейс. Пока что не знаю только какой интерфейс и куда прописать инфу, чтобы его увидел Analysis Services...

Критик,

да читал я теорию.

Вы смотрите в конерь: никто из разработчиков Hive не будет делать под него ни .NET провайдера, ни OLEDB провайдера.
Все будут делать только ODBC.

Значит мне надо как-то сдлеать так, чтобы MSAS, который умеет коннектиться к .net data provider или же к oledb provider, коннектился именно к .net или к oledb и не "морочил себе голову" о том что делает этот .net или oledb провайдер. Это уж, извините, не их дело.

Лучшим "передастом" может быть родной Microsoft .NET Data Provider for ODBC. Но у него нету каких-то интерфейсов, или он не зарегистрирован где-то, где должен быть зарегистрирован. И поэтому студия его не видит.


Значит берем в руки C#, пишем классы типа AdvancedODBCNetProvider, которые будут использовать родной Microsoft .NET Data Provider for ODBC, добавляем недостающие интерфейсы, регистрируем где надо - и проблема решена. Вот только в интернете фиг найдещь описание того, как сделать собственный .net data provider и куда его прописывать...

Но зато примеры есть. Тот же Oracle .NET Data provider - у него есть xcopy версия ODAC121012Xcopy_32bit.zip , а в ней bat-файл, где идет весь код прописывания "куда-надо". Придется посидеть и почитать как другие сделали.

Пробовал также искать программой what changed что меняется после инсталляции Вертики. Вижу список файлов


Начал читать код регистрилки Ораклового .net data provider-а - тоже наблюдаю подобное: прописывание в GAC собственно dll-ки провайдера, и прописывание файлов политик. По реестру не вижу ничего (пока что).

У нас разработчики ничем не хуже, чем в Оракла и у Вертики. Если можно им - то можно и нам.

кириллk,

дело не кончилось. оно пошло в другом направлении.

Я вот себе подумал, а зачем мне собственно MS Analysis Services?

По сути мне нужен не MOLAP, мне нужен ROLAP. Почему так? Потому что связка будет следующей:

Business Analysis Tool (или другой клиент)
->
[connect через xmla, mdx]
->
ROLAP server
->
[трансформация mdx в sql]
->
SparkSQL / Impala / Presto / любой другой БЫСТРЫЙ движок поверх данных в Hive.


И вопрос на засыпку: а чего собственно я должен использовать именно майкрософтовский (R)OLAP сервер? на нем что, свет клином сошелся? Еще и им деньги плати за лицензии на MSAS при том, что они не могут свой .NET for ODBC нормально написать и интефейcы все паблишнуть...

В связи с этим я в данный момент исследую Mondrian. У него есть один недостаток: это всего лишь движок, и надо хелпер-штучки сделать: веб-приложение, публикующее его сервлет, и может еще что-то. Но есть также один большой плюс: open source.

Сейчас у меня с Mondrian полезли разные баги, пока не понял то ли это баги в мондриане, то ли это я неправильно что-то сконфигурировал. Но с ним легче работать, чем с майкрософтом, потому что и сам mondrian - open source, и JDBC провайдер, которым он идет на hive - тоже open source. Баги можно отловить быстро.

Короче, будут новости - сообшу. Я в процессе.

Ну что же, коллеги, результат есть: имеем коннект из Excel pivot table в Mondrian, оттуда в Spark SQL.
Пока что все на БД Foodmart (затянутую в Hive), завтра буду пробовать на более реальной БД.

Есть желающие потом (когда добьюсь результата) протестировать на своих реальных big data данных?
Если да - присылайте заявки в ibobak at gmail dot com, будем сотрудничать.