Всем привет и хорошего дня. 30 августа HPE официально анонсировали выход новой версии Вертики. Можно отметить, что продукт уже достиг той поры зрелости, когда вместо огромного перечня новой функциональности на первом месте присутствует расширение и оптимизация существующей. Так же четко наблюдается плотная интеграция с продуктами и сервисами в определенных направлениях.

Что же я имею ввиду?

Облака




Во-первых, это интеграция с MS Azure Cloud. Это позволит использовать Вертику в облаках MS. В последнее время я вижу большой задел дружбы HPE и MS. Помимо Azure, для Вертики расширили поддержку VS Studio и улучшили работу драйверов под ADO.NET.

Меня дружба между Вертикой и MS определенно радует, надеюсь она будет развиваться дальше.

Джунгли



Во-вторых, Вертика продолжает тесно вгрызаться в мир Hadoop-а. Если в более ранних версиях, Вертика могла только загружать данные с HDFS определенных форматов, то постепенно она научилась работать со всеми форматами файлов, таких как ORC и Parquet, подключать файлы как внешние таблицы, а потом и хранить свои данные в ROS контейнерах прямо на HDFS.

В новой версии была проведена значительная оптимизация скорости работы с HDFS, каталогом метаданных и парсингом этих форматов.

Мне кажется, чтобы Вертика могла стать частью Hadoop среды, этого мало. Именно поэтому в новой версии добавили новый тип лицензирования Вертики… по количеству нод хадупа и возможность строить кластер Вертики прямо на Hadoop кластере.

Как это выглядит:

image

Идея состоит в том, что Вертика работает прямо в кластере Hadoop, имеет прямой доступ к данным на HDFS и так же хранит свои данные на HDFS. Лицензируется в таком случае кластер Вертики по количеству нод. Менеджеры HPE обещают, что стоимость лицензии будет вкуснее, однако пока мне цена лицензии не известна. Так что поживем, увидим.


Где Hadoop, там и Spark. В новой версии добавлена полноценная поддержка работы с Spark. Можно копировать данные из Спарка в таблицы Вертики, можно обратно из Вертики переносить данные в Спарк.


Интеграция с Apache Kafka уже была добавлена с версии 7.2. Однако выяснилось, что есть множество проблем, которые мешают полноценной работе коннектора Вертики с Кафкой. В 8 версии выложены обновленные версии библиотек работы с Кафкой. Я искренне надеюсь, что они закроют все найденные проблемы и народ перестанет открывать кейсы.

Машинное обучение



Поддержка машинного обучения появилась еще в версии 7.2. Однако оно было «сбоку» — лежало отдельной библиотекой и не интегрировалось полностью с метаданными Вертики. Видимо «тема пошла», так как в новой версии Machine Learning уже сразу интегрируется в сервер, доступно после инсталляции, наравне со всеми полноценно присутствует в слое метаданных, а функции входят в состав стандартных. Пожелаем же Вертике и дальше развиваться и обучаться в этом несомненно перспективном направлении.

Всякие фишечки



Фишечек на удивление мало. Видимо фантазия инженеров Вертики наконец то выдохлась. С точки зрения оптимистов, наверное это не плохо — меньше новых фишечек, меньше багов.

Но все равно в новой версии появились такие интересные вещи, как:

• Функция копирования таблиц COPY_TABLE, которая позволяет зашарить данные одной таблице как часть в другой. Что интересно, потом при изменении данных у каждой таблицы появится разный набор данных. Достигается это за счет общего использования ROS контейнеров между 2 таблицами. Что не менее интересно, для лицензии Вертика посчитает объем для каждой таблицы, даже если данные у обеих таблиц физически хранятся только один раз.
• Для SELECT в секции FROM добавлено ключевое слово TABLESAMPLE, которое позволит вернуть указанный процент части данных в случайном порядке записей.
• Параметр IDLESESSIONTIMEOUT позволит отстреливать сессии, которые долго висят и ничего не делают. Давно мечтал о таком параметре.
• Выпущена новая версия Python API для доступа к Вертике. Это всегда приятно, народу на Питоне работает с Вертикой много.
• Добавлена поддержка мульти язычности для Text Search. Заявляют, что поддерживают разбор текстов даже на азиатских языках. Надеюсь кириллицу они тоже смогли победить.

В заключение


Как и я писал в начале, могу тоже самое написать и в окончание моей статьи — поступательное движение наблюдается в основном на интеграцию с облаками и сервисами. Хочется более подробно узнать про лицензирование «Vertica on Hadoop». Мне кажется это интересным вариантом для задач, где первичная информация собирается на Hadoop, перемалывается и далее загружается в сервер Vertica для дальнейшей работы с помощью его аналитических функций и машинного обучения.

P.S. Очень приятно, что название новой версии FrontLoader созвучно названию нашего продукта доставки данных в Вертику EasyLoader. И не менее приятно, что именно сейчас, когда мы учим наш EasyLoader управлять загрузкой данных между HFDS и Vertica, восьмая версия расширила применение Вертики на Хадупе. Так сказать, вовремя.
Поделиться с друзьями
-->

Комментарии (14)


  1. InfiniteCode
    09.09.2016 02:42

    Боже упаси использовать вертику. Сейчас ищем интенсивно альтернативу, такой глючный продукт еще поискать нужно.


    1. SLASH_CyberPunk
      09.09.2016 10:49
      +1

      А аргументы можно написать? На текущий момент данная БД очень сильный инструмент…


      1. InfiniteCode
        09.09.2016 20:14

        Она сильный инструмент потому, что изначально была основана на Postgres. Относительно проблем, их за четыре года експлуатации насобирался целый воз. Из самого недавнего что вылезало:
        — восстановление базы из бекапа требует не просто такой же конфигурации кластер, а идентичный, вплоть до IP адресов, благо хоть на Мак адрес не опираются.
        — полная не совместимость одной версии с другой. Надавний минорный апдейт с 7.1 до 7.2 сделал все бекапы непригодными. Инкрементальный бекап отпал, начало снова зажовывать в бекап все ТБайты базы…
        — отличие в минорной версии драйверов делает их непригодными. Про обратную совместимость вообще нет смысла говорить. К примеру нельзя возпользоваться vsql клиентом для подключения к предыдущим версиями, иногда для поддержки приходилось рыскать чтобы найти старый какой нибудь vsql чтобы подключиться к базе.
        — Кафка это вообще парад счастья, тут можно даже не перечислять. Вместо того чтобы обновлять позицию в очереди, они умудряются зафлудить таблицу десятками тысяч записей. Исходные данные, один топик, одна флекс таблица. Данных прошло через кафку порядка 2 тысяч сообщений. При этом вертика умудрилась зафлудить таблицу свою системную в 10 тысяч записей за два выходных.

        Такое сырое и абсолютно не корпоративное добро еще поискать нужно. Сейчас, с покупкой HP, их хотя бы приводят к чему то, потому что до покупки был совсем мрак.


        1. InfiniteCode
          09.09.2016 20:22

          Еще в копилку из недавнего.

          — Copy Cluster ведет себя отвратительно. Он нам скопировал кластер, но в нем какие то данные отсутствовали. Мы долго не понимали в чем проблема, оказалось нужно просто раз 10 запустить его, чтобы оно наконецто докопировало все данные.


        1. ascrus
          09.09.2016 20:45

          Full Backup Restore to an Alternate Cluster — разве не позволяет восстановить бакуп на другой кластер, естественно с таким же количеством нод, но другими сетевыми адресами?

          По поводу дров и vsql меня тоже всегда удивляло, что новые версии дров не видят старые версии БД. Однако в обратку все работает замечательно, старые дрова работают с новыми версиями кластера, мне лично этого вполне хватает, какой вас смысл постоянно на новые дрова переводить софт, если старые работают?

          Ну а Кафка… только от нас кейсов для наших клиентов к ТП Вертики открыто несколько штук. Мы с HP совместно работаем над решением проблем, очень надеемся, восьмая версия их закроет.

          P.S. Я работал с Вертикой «до» покупки и «после». Насчет «мрака» не согласен. Функциональности было тогда меньше, интеграции с продуктами никакой, но зато все работало как швейцарские часы. Зря вы на команду инженеров Вертики так. И тех поддержка тогда напрямую работала, я мог списаться с разработчиками и быстро узнать/решить проблему чуть ли не в Скайпе. Сейчас все это идет через линии поддержки и прямой связи до разработчиков мы получаем очень редко, хотя все таки получаем.


          1. InfiniteCode
            09.09.2016 20:51

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

            Проблема с софтом была в том что из-за обратной несовместимости одно тянуло другое. К примеру, захотели использвать кафку, оно потребовало за собой вертику обновить, отвалились тогда дрова на клиентах везде. Хотя, что той кафки то, читаешь из очереди, обновляешь позицию, ложат в базу тем же COPY. Это вообще никаких обновлений не должно требовать. Там еще проявилась потом проблема, у нас не смогло слинковать очередь из Кафки с Таблицей. Вываливалось на уровней драйвера, хотя потом такой же линк только итеративно с alter таблицы сработал.

            По поводу до, работало как часы потому, что Postgres за основу там был. Но нормальных тулзов для администрирования там не было, сейчас кое-что со скрипом начинает зарождаться.

            Я думаю что список может быть куда длинней, это я по памяти написал то, что наш системщик выкопал. Но каждый раз при словах, что нужно что-то сделать с вертикой, у него нервный тик начинается :) Хотя всегда рад поделать что-нибудь для других реляционных баз.


            1. ivanko
              14.09.2016 07:45

              > Нет, требуют идентичные адреса. Абсурдно, нельзя рядом в той же сети поставить такой же кластер.
              Наверное, вы имеете ввиду, что вертика требует идентичные адреса для interconnect/control. На мой взгляд, это мелкое неудобство, поскольку public может быть любым, а interconnect/control все равно должен быть от public отделен ( да и пошире ему сеть нужна 10Gb). Мы у себя разруливаем это через VLAN-ы.


        1. alexzaitsev
          13.09.2016 11:51

          «Вы не любите кошек? Вы просто не умеете их готовить» (с)

          Для начала замечу, что HP купили Вертику в 2011 (когда у Вертики уже были сотни счастливых корпоративных клиентов в US), то есть Вы все время работали с HP-шной уже версией и багами. После покупки основные разработчики, получив хорошие деньги, разбежались, и не удивительно, что в новой (относительно core Vertica) функциональности находят не мало проблем. На то она и новая.

          Еще замечу, что от PostreSQL там только диалект SQL и вроде некоторые вещи, связанные с планировщиком запросов. Вертика выросла из http://db.lcs.mit.edu/projects/cstore/. Поэтому говорить о «Postgres за основу» — это несколько неправда. Вертиковцы бы очень обиделись :)

          Вертиковский подход к бекапам отличается от традиционного. Если внимательно почитать документацию и это осознать, то проблем не будет. Во-первых, при грамотной конфигурации у управлении кластером бекап в принципе не сильно нужен. За шесть лет промышленной эксплуатации нам ни разу не пришлось использовать бекап (и ни разу данные, конечно же, не были потеряны), хотя мы меняли сервера, кластеры, датацентры и пр. Во-вторых, бекап делается на уровне файловой системы (банальным rsync), из чего логично вытекают ограничения на идентичный кластер и т.д. (зачем восстанавливать бекап в неидентичный кластер — я не очень понимаю, и не уверен, что у других распределенных RDBMS тут сильно лучше).

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

          Может быть, стоит сменить не БД, а системщика? Честно, менее проблемной базы я не встречал, а мне пришлось поработать с большинством крупных. А уж «вес» проблем по отношению к достоинствам и вовсе минимален.

          Впрочем, я свое мнение не навязываю, просто делюсь. Мы тоже пробуем переехать с Вертики, но отнюдь не из-за технических проблем.


          1. ascrus
            13.09.2016 13:43

            Тут я присоединюсь к Саше. Работаю с Вертикой с 2010 года, одна из самых беспроблемных СУБД, если не считать последние года и фишечки. Тут делаем проще, как и с классическими СУБД — не сразу их начинаем использовать, а ждем некоторое количество патчей. Да собственно говоря и фишечки то они сторонние — неужели кто то мешает самостоятельно разработать свое ПО, которое в реалтайм будет осуществлять захват с той же Кафки и лить данные в Вертику. Делается просто. Зато под конкретно заточенную задачу работает всяко лучше, чем универсальные «коннекторы». Это в принципе к любому СУБД относится. Здесь разве что коннекторы Хадупа у Вертики рулят, так как позволяют закачивать данные с HDFS многопоточно ноды к нодам, с кластера MPP в кластер MPP.


          1. InfiniteCode
            13.09.2016 18:43

            Я бы тоже, наверное, решил, что стоит сменить системщика, но к сожалению его многолетний опыт работы в HIPPA compliant компаниях, а также работа с U.S. Securities and Exchange Commission над разнообразными расследованиями не позволяют пока мне усомнится в нем.

            Бекап через rsync это прекрасно, но это по сути и есть отсутствие нормального бекапа. Случаев когда нужен нормальный бекап уйма, начиная от возможности разворачивать на других платформах, до банального второго кластера рядом с основным, когда нужно тестировать нагрузку перед использованием новой версии ПО (клонирование данных и отправка по двум адресатам).

            Плюрализм мнений это хорошо.


    1. ascrus
      09.09.2016 12:36
      +1

      такой глючный продукт еще поискать нужно.

      Ну я совершенно не согласен с такой постановкой утверждения. Кроме багов с Кафкой я никаких других в области работы самого сервера, а так же с Хадупом или Флексом не сталкивался. А про Кафку я поэтому и написал в статье. Так что примеры в студию :)


      1. InfiniteCode
        09.09.2016 20:45

        Отписался выше с примерами.


    1. Keramblock
      10.09.2016 15:55

      Какие варианты рассматриваете?


      1. InfiniteCode
        13.09.2016 18:50

        Вариантов на самом деле немного. Пока смотрим на тривиальные замены, в стиле redshift. Прийдется слишком много переделывать, поэтому займет какое то время, пока найдем альтернативу.