Comments 6
Уважаемые коллеги, обратите внимание: внес небольшие правки в статью касательно новых типов проекций. Было ошибочно указано, что оптимизатор самостоятельно может увидеть, что под запрос подходят такого типа проекции и воспользоваться этими проекциями. Как выяснилось, на самом деле оптимизатор не может это сделать, нужно просто в запросе вместо имени таблицы явно указать имя созданной проекции, чтобы запрос отработал именно по ней. На самом деле вы можете в запросах вместо имен таблиц явно указывать и простые проекции, получается этакий аналог хинта использования индексов. Но в большинстве случаев это вредно, так как оптимизатор производя выбор использования нужной проекции, может анализировать не только метаданные, но и состояние и нагрузку кластера. Ну а новые проекции уже получается являются чистой материализацией новых данных на основе существующих в таблице, именно поэтому к ним и нужно обращаться явно.
Прошу прощения за эту неточность.
Прошу прощения за эту неточность.
Спасибо за статью!
Добавьте пожалуйста тэги: Big Data, Vertica, а то плохо ищется
Добавьте пожалуйста тэги: Big Data, Vertica, а то плохо ищется
Алексей, привет. Спасибо за обзор. Как всегда, подробно и хорошо.
Привет. Спасибо!
Вот руки не дойдут еще статьи написать, информации полезной полно, но мы сейчас full-time на развитие софта автоматической загрузки в Вертику с первоисточников, никак не вырву денек. По Хадупу сейчас Вертику интегрируем, народ с флекс таблицами активно возиться, по разработке на Java своих UDF опыт уже неплохой, например сделали библиотеку функций маскирования данных, что позволяет клиентам для своих интеграторов выгружать данные из прода в дев зоны маскируя персональные данные и снимая вопросы разворачивания похожих на правду стендов для разработки на них интеграторами решений для них.
Кстати скоро выложим наш лоадер на HP Market Place, документация основная готова, не хватает демо примеров по настройке работы. Для Community Вертики можно будет спокойно использовать, идеальная связка получится для среднего бизнеса для построения своих аналитических хранилищ данных до 1 тб на отказоустойчивом 3 нодовом кластере на абсолютно бесплатном полнофункциональном ХД + так же бесплатном софте выгрузке-загрузке данных без требования кодирования или разработки ETL задач. Скорость построения пилотов и рабочих решений для небольших хранилищ получается космическая ;)
Вот руки не дойдут еще статьи написать, информации полезной полно, но мы сейчас full-time на развитие софта автоматической загрузки в Вертику с первоисточников, никак не вырву денек. По Хадупу сейчас Вертику интегрируем, народ с флекс таблицами активно возиться, по разработке на Java своих UDF опыт уже неплохой, например сделали библиотеку функций маскирования данных, что позволяет клиентам для своих интеграторов выгружать данные из прода в дев зоны маскируя персональные данные и снимая вопросы разворачивания похожих на правду стендов для разработки на них интеграторами решений для них.
Кстати скоро выложим наш лоадер на HP Market Place, документация основная готова, не хватает демо примеров по настройке работы. Для Community Вертики можно будет спокойно использовать, идеальная связка получится для среднего бизнеса для построения своих аналитических хранилищ данных до 1 тб на отказоустойчивом 3 нодовом кластере на абсолютно бесплатном полнофункциональном ХД + так же бесплатном софте выгрузке-загрузке данных без требования кодирования или разработки ETL задач. Скорость построения пилотов и рабочих решений для небольших хранилищ получается космическая ;)
Странно, что эта статья не вызвала интереса. Может, не попала в нужный хаб? Я обычно ставил еще в «Администрирование баз данных», там много народу читает.
С сомнением отношусь к софту, который автоматизирует загрузку из произвольных источников, но думаю, что вы знаете, что делаете :) Маскировка персональных данных — это хорошая идея. Но не вижу проблемы в лоб захэшировать персональные данные через SQL. В чем суть вашего решения?
С сомнением отношусь к софту, который автоматизирует загрузку из произвольных источников, но думаю, что вы знаете, что делаете :) Маскировка персональных данных — это хорошая идея. Но не вижу проблемы в лоб захэшировать персональные данные через SQL. В чем суть вашего решения?
Маскировка интеллектуальная, умеет заменять адреса, ФИО, номера счетов и ИНН, телефоны и т.д. — то есть максимально выдавать данные приближенные к тому, что ожидается в бизнес логике по полю. Для этого внутри есть англоязычные словарики по разным бизнес сущностям и алгоритмы формирования в нужном формате значений. В отличие от рандом и хэш значений это очень помогает при разработке BI отчетов и позволяет интеграторам клиентов работать все таки с бизнес данными, пусть и «левыми», а не мешаниной цифр и букв. Не все пока полностью реализовано, но библиотека развивается и кстати используется нашим лоадером, который позволяет грузить в Вертику данные сразу маскируя нужные поля без промежуточных операций и гарантируя, что в ХД уже по любому не запишется даже в промежуточные таблицы персонализированных данных. Достаточно по нужным полям указать, как их нужно маскировать и в ХД уже автоматом попадут замаскированные данные.
А вообще в комментах всего не перескажешь, что сделали — это и лоадер, который как полноценным DSL получился, позволяющим описать обычным конфигом сложную прогрузку данных или перемещение файлов на файловых системах и веб шедулер с мониторингом и управлением на множестве серверов задач по расписаниям, аналог коммерческого Кварца или Таленда. Хадуп сейчас активно подтягиваем и вот с VoltDB начинаем работу. Весело в общем ;)
А вообще в комментах всего не перескажешь, что сделали — это и лоадер, который как полноценным DSL получился, позволяющим описать обычным конфигом сложную прогрузку данных или перемещение файлов на файловых системах и веб шедулер с мониторингом и управлением на множестве серверов задач по расписаниям, аналог коммерческого Кварца или Таленда. Хадуп сейчас активно подтягиваем и вот с VoltDB начинаем работу. Весело в общем ;)
Sign up to leave a comment.
Новая версия HP Vertica: Dragline 7.1