Teradata – СУБД, параллельная от рождения

    Приветствуем, уважаемые Хабравчане. Последнее время на Хабре стало мелькать название компании Teradata в тех или иных вопросах. И, увидев возможный интерес, мы решили рассказать немного о том, что же такое СУБД Teradata, от первого лица. Мы планируем подготовить небольшую серию статей о самых интересных, на наш взгляд, технических особенностях СУБД и работы с ней. Если у вас есть опыт работы с Teradata или в вашей компании используется наша платформа и у вас есть вопросы – подкидывайте их, и мы либо ответим на них в комментариях, либо подготовим соответствующую полноценную статью. А начнем с небольшого обзора. Для знакомства, так сказать.

    Параллелизм


    СУБД Teradata была создана в 1976 году и многие концепции, заложенные в ее фундамент, актуальны и по сей день. Teradata реализовала дизайн, отличный от главенствующей на тот момент архитектуры мэйнфреймов. Это была идея объединения в сеть вычислительных модулей, работающих параллельно. Приятным дополением к такой архитектуре стало значительное удешевление систем.
    Идея параллельной обработки дала Teradata возможность линейно масштабировать производительность, объемы обрабатываемых данных и количество пользователей. Что же такое «параллельная обработка»?
    Двое друзей в 10 часов вечера в субботу ужинали и пили пиво, когда один из них сказал, что у него есть дело и он должен уйти. На вопрос друга, что это за дело, он ответил: «Стирка». Друг негодовал по этому поводу: «Как это можно… вечером уйти… чтобы стирать?..» На что получил объяснение: «Если я пойду стирать завтра, то мне повезет, если будет свободна одна из 10 машин в прачечной самообслуживания. Мне нужно постирать белья на 10 загрузок, и на это уйдет весь день. Если же я пойду сейчас, когда все отдыхают, я смогу использовать все стиральные машины и закончу стирку за полтора часа».
    Эта история описывает то, что называется параллельной обработкой. Teradata выполняет загрузку, архивирование и обработку данных параллельно. В зависимости от конфигурации Teradata позволяет выполнять сотни, тысячи операций одновременно.

    Логическое представление архитектуры Teradata


    Руководитель хора готовился к концерту. Внезапно он остановился и обратился к хору со словами «Говорил ли я вам, что несколько лет назад я руководил другим хором, мы работали над этим же произведением и они сделали ту же ошибку, которую делаете сейчас вы? Знаете ли вы, что это за ошибка?» Голос из хора ответил: «Один и тот же руководитель!»
    Многие проекты построения хранилища реализованы на архитектурах, которые не предназначены для этого. Многие компании часто удивляются провалам таких проектов, хотя они изначально не имели шанса на успех. Руководству компаний необходимо понимание, которое позволит выбрать те технологии поддержки принятия решений, которые будут соответствовать масштабу бизнеса.
    Приведенная ниже диаграмма представляет собой логическую архитектуру Teradata.



    Основное назначение компонентов, представленных на диаграмме:
    PE – Parsing Engine, отвечает за контроль сессии и обработку запросов пользователя;
    AMP – Access Module Processor, отвечает за извлечение данных с ассоциированного с ним диска;
    BYNET – Среда обмена сообщениями между компонентами системы.
    Teradata относится к классу систем, называемых MPP (англ. Massively parallel processing), и имеет архитектуру Shared nothing, в рамках которой отдельные узлы системы не имеют общих ресурсов. А сама СУБД является реляционной.
    На верхнем уровне процесс выполнения запроса в Teradata выглядит следующим образом:
    • Пользователь, подключаясь к системе Teradata, устанавливает соединение с Parsing Engine (PE). После того как соединение установлено, он может выполнять запросы SQL.
    • PE проверяет синтаксис полученного SQL-запроса, права пользователя на доступ к информации и создает план выполнения запроса для выполнения компонентом Access Module Processor (AMP).
    • PE через BYNET направляет шаги плана AMP'ам на выполнение.
    • AMP’ы извлекают необходимую информацию с ассоциированных с ними дисков и возвращают ее PE через BYNET. AMP’ы выполняют свою работу параллельно.
    • PE возвращает результат пользователю.

    PE и AMP объединяются термином VPROC, или виртуальный процессор.

    Для того чтобы запросы обрабатывались максимально эффективно, данные должны быть распределены между AMP'ами максимально равномерно. Есть исключения, но о них мы расскажем в одной из следующих статей. Данные распределяются на основании собственного hash-алгоритма обработки полей, входящих в Primary index таблицы. Причем алгоритм хэширования реализован так, что на основании значения хэша можно понять номер AMP’а, на котором находится строка. Помимо основной цели, это также очень ускоряет поиски по значению.

    Технические детали по составу hash'a
    В современных версиях платформ Teradata результат хэша представляет собой 32-битную последовательность. В ее рамках заложены идентификаторы AMP’a (единица параллелизма системы) и собственно строки. Допустим, нам надо обработать запись со значением 7202. Схема определения ее хэша и того, на какой AMP следует поместить строку, выглядит следующим образом.


    Таким образом, AMP’ы – это рабочие лошадки, которые отвечают за свой кусок данных. Но часто бывают задачи, когда для выполнения запроса требуется перераспределение данных. Пример – join двух таблиц, которые распределены по разным ключам. Тогда в дело вступает BYNET. BYNET отвечает за коммуникацию между компонентами системы, и в том числе за передачу данных между AMP’ами. Он может с умопомрачительной скоростью передавать массивы данных между узлами. Не трудно догадаться, какая нагрузка ложится на BYNET. Поэтому отцы-основатели технологии заложили в нее хороший потенциал и сделали своим ноу-хау. В платформах Warehouse Appliance этот компонент может быть реализован софтверно поверх Ethernet. В более серьезных платформах Active Enterprise Data Warehouse это отдельный аппаратный модуль, ибо с такими объемами Ethernet уже не эффективен.
    Лицом к клиентам стоит PE – parsing engine. Это компонент (а точнее, набор компонентов), в функции которого входит первоначальная обработка поступающих запросов, контроль выполнения и отправка ответов. В его состав входят 3 модуля: парсер, оптимизатор, диспетчер.
    Как нетрудно догадаться, парсер отвечает за парсинг запроса, проверку прав доступа и прочий семантический контроль. Оптимизатор оценивает возможные варианты выполнения запроса и выбирает наиболее эффективный. Ходят слухи, что код оптимизатора занимает более 1 млн строк, а где-то в районе Rancho Bernardo сидит группа людей, которая не занимается ничем, кроме совершенствования логики оптимизатора от версии к версии. И да, нельзя не сказать – в Терадате нет хинтов. Поэтому если разработчик считает, что его план лучше, чем тот, что определил оптимизатор, то это еще придется доказать, а не просто приставить к порту «пистолет» и сказать: «+use_hash». И, как показывает практика, оптимизатор оказывается прав.
    А диспетчер отвечает за разбитие выбранного плана на шаги и контроль последовательности/параллельности их выполнения, отдавая указания на AMP’ы через BYNET.

    Так что если вкратце, то логически работа системы выглядит примерно таким образом. В следующих постах мы думали рассказать об особенностях работы со статистикой в СУБД, может, коснуться вопросов физического моделирования и поговорить об инструментах автоматической балансировки нагрузки. А вы что скажете о возможных интересных темах?
    Teradata
    Company
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 30

      +1
      Забавно. Но фактически архитектура крайне незатейлива во всем, кроме пресловутого 1M строк оптимизатора, о котором рассказано, как о черном ящике ((
        0
        Архитектура Shared Nothing, которая в целом описана в статье, и правда не сильно затейлива. Но есть такое выражение — «Дьявол в мелочах». Если рассматривать каждый компонент внимательно, то вокруг него находится множество вопросов, которые закрываются порой интереснейшими решениям. Подробное описание всего займет не одну сотню страниц и явно утомит читателя. Если что-то конкретное интересует больше чем остальное — спрашивайте смело :)
        +3
        А каким образом реализована поддержка ACID?
          0
          Атомарность поддерживается транзакционными механизмаи и журналами. В Терадате существует целый ряд журналов. В частности есть Transient Journal, служащий для того, чтобы обеспечивать возможность отката транзакций. В нем содержится описание состояния затронутых данных до начала операции. И в случае отката транзакции, состояние восстанавливается из него.

          Согласованность обеспечивается через обычные check'и перед сообщением об успешном завершении операции.

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

          Транзакционность работает в том числе за счет WAL логов, в которые дублируются изменения данных и в ключевые моменты (например, коммиты) лог принудительно скидывается на диск. Так в том числе обеспечивается Надежность.
            0
            PE в системе всегда один? Как работают транзакции, если в рамках одной транзакции затрагиваются данные на нескольких нодах хранения?
              +2
              На узле может быть запущено несколько PE. Приведенная в статье схема — схема узла.
              Что касается транзакций, то каждый AMP ведет транзакционный журнал и сохранят в нем before images «своих» строк таблиц.
                0
                Как разруливается ситуация, когда с разных PE запускаются 2 транзакции, которые выполняются на нескольких AMP одновременной (одних и тех же), обе транзакции пытаются обновить одни и те же строки? Если одна из них откатывается — как откатываются данные на остальных AMP?

                То есть из своего опыта кажется, что транзакции должны быть распределёнными, что-то типа PAXOS или ZAB. Что в Teradata?
                  0
                  2 сессии, вне зависимости от того, с каким узлом они установлены, не могут одновременно модифицировать одни и те же строки. Это обеспечивается механизмом блокировок.

                  Безусловно, как блокировки, так и транзакции координируются в MPP системе.
                    0
                    То есть всё таки не shared nothing? Можно подробностей про координацию транзакций?
                      0
                      Каждый AMP отвечает за блокировки «своих» строчек данных. Если AMP получил запрос на блокировку одних и тех же данных от двух PE (или даже от двух сессий на одном и том же PE), то эти блокировки ставятся в очередь — на каждом AMPе, независимо друг от друга.

                      Теперь о координации между AMPами:

                      PE осуществляет диспетчеризацию плана запроса.

                      Фиксация транзакций происходит отдельным шагом в конце плана выполнения запроса. Это очень похоже на двух-фазный commit в том смысле, что к этому моменту все AMPы уже готовы сделать commit, и поступает отдельное сообщение от PE к AMPам для фиксации транзакции.

                      Откат транзакций — также через PE. Если какой-то AMP столкнулся с ошибкой данных, требующей отката транзакции, то он сообщает об этом PE. Далее PE отправляет AMPам сообщение, что нужно откатить транзакцию. Каждый AMP откатывает свои изменения, и снимает блокировки.

                      Насчет «shared nothing»: выполнение запросов осуществляется параллельно, но выполнение фиксации/отката транзакции требует синхронизации.
                        0
                        А кто в этой схеме разруливает перекрёстные блокировки, ведущие к дедлокам? В варианте с 2 одновременными запросами, блокирующими одни и те же данные на разных AMP, кто следит за тем, что блокировки встанут в очередь в одинаковом порядке?
                          +1
                          Локально на AMP-ах обнаружение взаимных блокировок запускается через фиксированные 30-ти секундные интервалы.
                          Глобальное обнаружение взаимных блокировок запускается на PE через периоды, определенные в настройках (по умолчанию 4 минуты).
                          При обнаружении взаимной блокировки производится откат “младшей” транзакции.
                            0
                            К словам Евгения также хочу добавить следующее:
                            «Каждый AMP отвечает за блокировки «своих» строчек данных» — работает в ситуации RowHash Lock, в более тяжелом случае необходима блокировка всей таблицы (Table Lock). В этой ситуации используется техника Pseudo Table Lock: каждой таблице присваивается ответственный за неё AMP, и когда запрос хочет работать с таблицей, PE запрашивает у ответственного AMPа, не занята ли таблица другим.
            +4
            Статья — как фиговый листок.

            Рассказали бы что-нибудь захватывающее, например как Майкл Стоунбрейкер срался на страницах ACM Communications с адептами NoSQL, как Teradata попыталась вскочить в уходящий поезд MapReduce, купив Aster, сколько вы даёте откатов и на каких полях для гольфа продаются ваши продукты.

            ;-0
              0
              Да, действительно, на Хабре давно уже никому не нужны технические статьи, а вот скандалы-интриги-расследования всегда в цене, пример всем известного местного сотрудника Тематических Медиа с именем на «а», и его коллег, показывающих то, что скрыто, крайне убедителен.
                0
                Ну, такие статьи точно никому не нужны.
              +1
              Мне интересно будет послушаь про статистику и отсутствие хинтов.
              Например, есть табличка с миллиардом записей и индексированное поле в ней, содержащее, например, пару тысяч уникальных значений с очень неравномерным распределением по количеству — по некоторым значениям всего пару строк, по другим десятки тысяч и т.д
              Как оптимизатор поймет, когда использование индекса будет эффективно, а когда быстрее просмотреть таблицу целиком, если в where есть условие для этого поля?
                +1
                По индексированным полям собирается статистика. Это гистограммы, показывающие распределение количества строчек по диапазонам значений. Для каждого диапазона фиксируются его границы, общее количество строчек в диапазоне, модальное значение, количество строк на модальное значение, и т.д. Далее для конкретного условия where Оптимизатор смотрит нужный диапазон значений для той константы, которая указана в условии where, и делает оценку количества значений.

                В Вашем примере среднее количество строчек на значение равно 500 тыс. (миллиард записей разделить на пару тысяч уникальных значений). Если есть какие-то пиковые значения, то они попадут в модальные значения, и Оптимизатор будет знать об них точную информацию. В остальных случаях, делаются оценки. Понятно, что сильно неравномерное распределение по количеству влияет на точность оценок.

                Отсутствие хинтов — это когда пользователи пишут только SQL-запрос. Хинты — это когда пользователи пишут как SQL-запрос, так и план выполнения для него. Как правило, для большинства пользователей первый случай удобнее.

                Если какой-то план неоптимален и «хочется написать хинты» — то, как правило, это либо отсутствует статистика, либо устаревшая статистика.

                Для указанного выше примера, я бы предложил уточнить постановку задачи — какая таблица рассматривается (проводки, CDRы, ...), есть ли партиционирование (по времени), какая колонка имеет сильно неравномерное распределение по количеству строчек. Для конкретной задачи всегда удобнее найти нужное решение.
                  0
                  А что с устаревшей статистикой?
                  В MS SQL, например, сталкивался с такой ситуацией — процедура, которая работает в нескольких потоках и активно добавляет записи в таблицу в начале выполнения и очищает таблицу в конце выполнения через некоторое время просто перестает выполняться — статистику «перекашивает», и процедура намертво зависает. Помогает ей только сброс статистики с таблицы.
                  Возможна ли здесь такая ситуация?
                    +1
                    После глобальных изменений данных (изменилось >10% строк) рекомендуется вручную пересобирать статистику. Однако Teradata и сама сможет определить, что статистика устарела, сравнив гистограмму статистики с семплом, взятым с одного AMPа. В этом случае статистика не будет использоваться и оптимизатор будет использовать эвристики.
                      0
                      ребят, никакая статитстика никогда не бывает полной — у оптимизатора нет полной информации о том сколько записей вернёт каждый подзапрос в плане, особенно если критерии отбора достаточно сложные. Из-за этого оптимизатор выбирает неправильный порядок соединений.

                      Можно написать оптимизатор на 100 млн строк кода, но с этим ничего не сделаешь — до выполнения запроса данных у оптимизатора нет. А разработчик обычно это знает.

                      Не спорю что в 99% случаев оптимизатор разберётся и без советов разработчика. Но ручками лазить всё равно приходится. Нужны ли обязательно хинты, когда лезешь ручками — обсуждаемо. А так тезис автора напомнил SAP facts: «SAP StreamWork has a fully automated mode that does the business decisions for you»
                        +1
                        Вспомнилась старая фраза: есть ложь, есть наглая ложь и есть статистика :)
                        Задача оптимизатора (и его качество), на мой взгляд, во многом заключается в том, чтобы максимально повысить вероятность (те самые 99%) в которых никуда лазить не надо. А в тех случаях когда приходится лазить, то в Терадате это лечится, так сказать, органически, путем предоставления оптимизатору недостающей информации. И все счастливы :)
                        0
                        «2 копейки» в дополнение: в случае обнаружения устаревшей статистики, эвристика будет использоваться для неиндексированных колонок, для индексированных — статистика, полученная семплированием
                  0
                  Для начала хотел бы поять главное -для каких задач хороша Терадата по сравнению скажем с MS SQL и для каких плоха? И не говорите, что для всех хороша.

                  ERP?
                  Система построения отчётов?
                  Фэйсбукоподобный интернет проект?

                  А то вы как-то сразу от дирижёров к хэшам и оптимизаторам.

                  Навскидку (на самом деле ничего не знаю про Терадату) есть подозрение, что это очередная СУБД из 70х с 1% рынка и лицензиями по 100К, хочет получить 1.01% рынка, при помощи обсуждения гик-порно в социальных сетях.
                    0
                    Если кто-то скажет, что Терадата хороша для абсолютно всех задач, то я смело поставлю минус в карму. Терадата это анализ больших объемов данных. Может ли она быть OLTP? Технически — вполне. Но на практике стремления к такому нет. Зачем пытаться завоевывать область, в которой MPP системе по архитектуре сложно конкурировать с транзакционками?
                    Терадата хороша для быстрой обработки больщущих объемов данных. Залил сотенку терабайт данных и можно крутить и анализировать их как хочешь. Всей конторой. Одновременно. Если петабайт есть, так вообще прекрасно. Узлы в параллель будут пытаться находить и обрабатывать данные.

                    Терадата это Хранилища Данных. В каком-то из документов на сайте видел фразу «Data warehousing it’s not just something we do – it’s all we do». Кастомная аналитика, отчеты, аналитический CRM, data mining — лишь небольшой список задач, которые хорошо решаются с помощью СУБД Терадата. Фейсбукоподобный интернет проект я бы лично на Терадате делать не стал, и пусть Цукерберг меня осудит если захочет.

                    Сравнивать с другими СУБД — дело неблагодарное, и холливор начнется, потому что у каждого свои задачи и свои данные. И никто не будет прав или не прав на 100%. Но есть официальные мероприятия называемые benchmark. Это когда в системы разных вендоров заливаются одни и те же данные, готовятся одни и те же запросы. Дальше берется что-нибудь типа jMeter и системы начинают меряться [censored] производительностью. Составляются отчеты, на каких типах запросов какая система показала какие времена откликов, как выбирала данные, как вставляла и т.п. Результаты показываются заказчику, который был заинтересован в дуэли и он делает для себя вывод, какая система подходит лучше именно для его задач и для его данных. Т.к. данные и задачи для benchmark берутся из его среды.
                      +1
                      en.wikipedia.org/wiki/Teradata#Customers
                      Если смотреть с точки зрения бизнес юзера DWH (т.е. аналитика) большой плюс Терадаты в ее оптимайзере — не надо никаких хинтов (как в Оракле) и можно писать джойны на десятки и сотни таблиц. Ну и параллелизм, которого нет в MySQL.
                      + что сказано mrz0diak habrahabr.ru/company/teradata/blog/160821/#comment_5548911
                      0
                      В платформах Warehouse Appliance этот компонент(BYNET) может быть реализован софтверно поверх Ethernet. В более серьезных платформах Active Enterprise Data Warehouse это отдельный аппаратный модуль, ибо с такими объемами Ethernet уже не эффективен.
                      А еще Teradata может его эмулировать для SMP (single node platform) если у нас Teradata Express Edition, ведь сам физический слой и не нужен.
                        0
                        Всё верно. В SMP редакции СУБД как правило не стоит вопрос обеспечения максимальной производительности. И в версиях для виртуальных машин (Teradata Virtual Machine Edition) так же физический слой не нужен, реализация исключительно на уровне ПО.
                        0
                        mrz0diak О тред еще живой. У меня вопрос, я вот пишу диплом на тему оптимизации запросов в Teradata, насколько то, что я проверю на Teradata`e express edition, поднятой очевидно на виртуалке, будет соответствовать реальности, ведь там будет только два AMP`a? Включая, но не ограничиваясь влиянием индексов на распределение данных и времени запросов.
                          0
                          Скажем так: отличаться будет. Первое что приходит в голову — оптимизатор принимает те или иные решения в т.ч. основываясь на статистике по количествую записей и их объему. Поэтому при тех же параметрах физ. модели (PI, SI, партиции и пр.) но при совершенно другом объеме данных и решения оптимизатора могут быть другими. Плюс на Express Edition не будет учтено влияние таких вещей как Teradata Intelligent Memory, Teradata Virtual Storage, которые есть на аппартно-программной версии Teradata.
                          Так что в принципе отличия будут, но на мой взгляд не критичные в рамках дипломной работы.

                        Only users with full accounts can post comments. Log in, please.