Query grid что это

Обновлено: 03.07.2024

Querygrid requires JRE 7 (or higher). Teradata Database 15 has JRE 7 pre-installed along with the JRE 6. In order to change JRE run below code snippet on any of the Teradata nodes:

We recommend to use G1 collector with the following properties:

You must ensure that you have enough memory for query and IO buffers. In case of frequent GC invocations try to increase JVM heap size.

In Teradata Database JVM properties can be set with using *cufconfig*. Provided properties will be applied for all of the Teradata nodes. Below is the set of properties which are a good start point of configuring your JVM.

In Presto you can change JVM properties with editing the jvm.config file. It can be easily distributed across the cluster using the presto-admin utility. Please refer to presto-admin documentation for more details.

Upload¶

Please upload a package zip (teradata-to-presto-driver.zip) file on Teradata and Presto systems and unzip it.

the driver jar file
the installation bash script
the rpm file to be installed on Presto cluster
the sample properties files to be copied on Presto cluster
this documentation

Installation on Presto¶

Use Teradata provided distribution of Presto (version 0.127t), installed with presto-admin tool.
Install the querygrid-presto-connector rpm

Copy properties/querygrid.properties to /etc/opt/prestoadmin/connectors.
In /etc/opt/prestoadmin/connectors/querygrid.properties replace <PRESTO-HOST> with the actual Presto coordinator hostname or IP reachable by Teradata.
Deploy Querygrid connector configuration using presto-admin

Make sure that Querygrid connector is installed

Driver installation¶

To see a full list of supported options type the following:

install - installs the querygrid driver
uninstall - uninstall the querygrid driver
create_teradata_to_presto_server - creates foreign server which will be using querygrid driver
drop_server - drops foreign server

Once you have all needed information you can install the driver with the following command:

All values used in command examples must be replaced with values corresponding to your environment.

After this step you need to create a foreign server (you can skip static configuration).

Static driver configuration¶

Currently there are following static configurable properties shared across all foreign servers:

data-exchange.server.buffer-size - query results write buffer size. Buffer is shared between all the queries that are in progress. Defaults to: 2GB.
data-exchange.server.port - querygrid server port. Defaults to: 21337.
data-exchange.client.buffer-size - query results read buffer size. Buffer is shared between all the queries that are in progress. Defaults to: 2GB.

Static properties can be set for both Presto and Teradata.

In order to change static property for Presto you must edit the querygrid connector configuration file ( /etc/opt/prestoadmin/connectors/querygrid.properties ). To apply your changes you must distribute new properties file to all Presto nodes and restart the Presto server:

In order to change static property for Teradata you must set JVM system property in the following format: -Dt2p.property.name=value . Properties for Teradata JVM can be set using the cufconfig utility. To apply your changes you must restart the Teradata database using the tpareset command.

Buffer sizes must be specified in human readable data size notation: 100MB, 1GB, 1TB

Foreign server creation¶

To create a foreign server issue the following command:

By default hive catalog is queried. You can specify another one via server_catalog:

If the network bandwidth is the bottleneck, data compression may increase throughput at the cost of increased CPU utilization. Data compression can be enabled for a particular foreign server using the compression parameter.

LZ4 and SNAPPY compression algorithms are available. Both algorithms are focused on compression and decompression speed. Compression ratio and compression speed may vary for different queries and data sets.

Presto database credentials can be changed using the presto_user and presto_password parameters:

Depending on your workflow you may want to adjust a foreign server parameter presto_writer_count. If your general workload consists of running large queries with low concurrency, please set it to higher value. However, if your workload contains running concurrent queries, you may need to lower it. This property controls how many threads will be used by Presto per each QueryGrid query. If your Presto cluster has 64 cores per machine, to fully utilize all of those cores with 4 concurrent queries you need to set presto_writer_count to at least 16. By default the number of concurrent writers is set to 8.

If you need to set any server options, follow the convention in the command below (note last option):

To see full list of server configuration parameters please see Configuration parameters section.

Usage of foreign servers¶

Calling bteq command on teradata¶

Once you have installed the querygrid driver and created a foreign server, play around with them by running the bteq command on the teradata host (logged in as the querygrid driver user) followed by a few sql queries:

Once you are logged on teradata data warehouse you can run the SQL examples below.

To see the list of schemas (databases) of a foreign server¶

To see the list of tables in schema (database)¶

To see the list of columns of a table from a foreign server¶

Select query (import path)¶

Insert into query (export path)¶

Drop foreign servers¶

To remove foreign server you can:

Uninstall Driver¶

Once you dropped all foreign servers, you are able to uninstall driver:

After the uninstall you have to restart your Teradata Database. It can be done with:

Or you can run uninstall task with the restart parameter:

Configuration parameters¶

MaximumTextLength - (default: 4096) an integer which determines maximum length in characters of text which could be transferred between databases (Teradata and Presto)
MaximumBinaryLength - (default: 4096) an integer which determines maximum length of binary data in bytes which could be transferred between databases (Teradata and Presto)
ReadTimeout - (default: 2h) determines the maximum amount of time waiting for query results. It is recommended to increase this value for the queries that require complex computation before returning any data.

WriteTimeout - (default: 1h) determines maximum amount of time waiting for consumer to consume the results. It is recommended to increase this value for the queries that require complex computation after consuming the data.

QueryTimeout - (default: 1h) determines maximum amount of time waiting for the remote query to finish after data transfer is finished. It is recommended to increase this value for the INSERT INTO queries which insert the data into the slow consuming connectors.

Note

Sample timeout values: 10s, 5m, 2h.

To see how to use above parameters see Foreign server creation section.

Technical specification¶

Type support¶

The following table refers to type handling/conversion between Presto query engine and Teradata. Type handling can differ between presto connectors or even between storage types within a connector. Please refer to a specific presto connector documentation for more details. For example presto-hive connector maps all integral types to Presto BIGINT type.

Type in Presto	Type in Teradata	Notes
BOOLEAN	BYTEINT
BIGINT	BIGINT
DOUBLE	REAL
VARCHAR	VARCHAR	Values exceeding MaximumTextLength will be truncated
DATE	DATE
TIMESTAMP	TIMESTAMP
VARBINARY	VARBYTE	Error thrown on values exceeding MaximumBinaryLength
JSON	VARCHAR
ARRAY	VARCHAR	Serialized to/from json
MAP	VARCHAR	Serialized to/from json
ROW	VARCHAR	Serialized to json in import path. Writing ROW values to Presto is not supported

Known issues/limitations¶

We should provide alias explicitly to make it work.

Currently QueryGrid is limited to run 20 concurrent queries. However, if your queries are long running or taking a lot of resources (e.g. big result set) it is advised to run even less than 20 queries. Otherwise you may get an Teradata error:

In order to run INSERT INTO queries with the high presto_writer_count you must change *node-scheduler* settings in Presto config.properties file as well

*MAX_SPLITS_PER_TASK_PER_NODE* must equal or greater than presto_writer_count
*MAX_SPLITS_PER_NODE* must be equal or greater than presto_writer_count multiplied by the number of queries that are supposed to be run concurrently

High presto_writer_count can cause high CPU utilization. If the Presto starts to fail with the timeout related issue try to decrease presto_writer_count.

In case of getting the Another instance of the Querygrid driver is still running. error please restart your Teradata instance with the tpareset reason command.

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

Какие-то приложения на большие таблицы не рассчитаны и «зависают» при попытке открыть на просмотр/редактирование таблицу с миллионами записей. Иные отказываются от использования грида с вертикальной полосой прокрутки в пользу постраничного отображения или предлагают пользователю лишь иллюзию, что при помощи полосы прокрутки можно быстро перейти к нужной (хотя бы к самой последней) записи.

Мы расскажем об одном из возможных методов реализации табличного элемента управления, обладающего свойствами Log(N)-быстрого 1) первоначального отображения 2) прокрутки на всём диапазоне записей 3) перехода к записи с заданным уникальным ключом. Всё это — при двух ограничениях: 1) записи могут быть отсортированы только по индексированному набору полей и 2) collation-правила базы данных должны быть известны алгоритму.

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

Основной принцип

прокрутка — отображение записей, соответствующих положению бегунка полосы прокрутки,
переход к записи, заданной по комбинации ключевых полей.

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

Другой подход заключается в «перекладывании» вычислений на СУБД: выборку записей для отображения в окне прокрутки осуществлять при помощи конструкций вида select… limit… offset . , позиционирование — сводить к select… и count(*). Однако и offset, и count(*) связаны с перебором записей внутри сервера, они имеют в общем случае скорость выполнения O(N), и потому неэффективны при большом числе записей. Частый их вызов приводит к перегрузке сервера БД.

Итак, нам нужно реализовать систему, которая не требовала бы полной закачки данных в память и при этом не перегружала бы сервер неэффективно выполняющимися запросами. Для этого поймём, какие запросы являются эффективными, а какие — нет.

Запрос A. Найти первую и последнюю запись в наборе данныx:
Запрос B. Найти h первых записей с ключом, большим или равным данному значению K:

Запрос C Подсчитать общее количество записей в наборе данных:
Запрос D. Подсчитать число записей, предшествующих записи с ключом, большим или равным данному:

«Угадывание» зависимости первичного ключа от номера записи

На время представим себе, что первичный ключ нашей таблицы имеет всего одно целочисленное поле (далее мы снимем это ограничение).

Пусть каждому положению бегунка полосы прокрутки соответствует целое число от 0 до , где — общее число записей в таблице, — число строк, умещающихся на одной странице в гриде. Если бегунок полосы прокрутки выставлен в положение , то это означает, что при отрисовке грида необходимо пропустить первых записей в таблице, а затем вывести записей. Это как раз то, за что отвечают ключевые слова offset и limit в PostgreSQL, и при большом числе записей мы не можем ими пользоваться. Но если бы некоторым «волшебным» образом мы бы могли за быстрое время уметь вычислять функцию и обратную ей функцию , связывающую первичный ключ и число записей с ключом, меньшим данного, то тогда при помощи запроса B, подставляя туда значение , мы могли бы быстро получать набор записей для отображения пользователю. Задача перехода к нужной записи решалась бы таким образом: т. к. первичный ключ заранее известен, его сразу можно использовать в качестве параметра быстрого запроса B, а полосу прокрутки следовало бы установить в положение . Поставленная задача была бы решена!

(Заметим, что запрос D, вызываемый с параметром k, как раз возвращает значение , но 1) он медленный и 2) нам нужно уметь вычислять как , так и обратную ей.)

Естественно, функция целиком определяется данными в таблице, поэтому, чтобы точно восстановить взаимозависимость значений ключа и номера записи, необходимо прочесть из базы в оперативную память все ключи через одного: для корректного срабатывания запроса B в промежуточных точках можно считать, что (вспомним замечательное свойство запроса B). Это уже лучше, чем запоминать все подряд ключи, но всё ещё недостаточно хорошо, т. к. требует O(N) времени и оперативной памяти для первоначального отображения таблицы. К счастью, можно обойтись гораздо меньшим значением точно известных точек для функции , и чтобы понять это, нам потребуется небольшой комбинаторный анализ возможных значений .

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

Таким образом, если каждый из возможных вариантов считать равновероятным, то вероятность того, что для заданного значения имеется ровно записей с ключом, строго меньшим , задаётся отношением , известным как гипергеометрическое распределение. Для , картина выглядит вот таким образом:

Свойства гипергеометрического распределения хорошо известны. В случае всегда , а на отрезке среднее значение линейно зависит от k:

Дисперсия значения имеет форму перевернутой параболы с нулями на краях отрезка и максимумом посередине

(Грубо можно считать, что средняя ошибка меньше, чем .)

Расчёт значений по вышеприведённым формулам для , показывает такую картину для возможных минимальных и максимальных (красные линии), среднего (голубая линия) значений , а также границ среднеквадратичного отклонения (серая область):

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

Если теперь для какого-то , станет известно новое точное значение , мы можем добавить пару к интерполяционной таблице и при помощи кусочной интерполяции получить уточнённый расчёт значения для решения задачи прокрутки, а применяя обратную кусочную интерполяцию, вычислять уточнённое значение при решении задачи позиционирования. С каждой накопленной точкой дипазон возможных расхождений будет сужаться, и мы будем получать всё более и более точную картину для функции .

Если ключевых полей несколько и типы данных не INT

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

функцию-нумератор , переводящую набор значений полей произвольных типов в натуральное число,
обратную ей функцию , переводящую натуральное число обратно в набор значений полей, .

Говоря языком математики, биекция должна устанавливать изоморфизм порядка между множеством возможных значений наборов полей и множеством натуральных чисел. Заметим: для того, чтобы задача поиска подходящей была математически разрешима, важно, чтобы множества возможных значений полей были конечными. К примеру, между множеством всех лексикографически упорядоченных пар натуральных (пар действительных) чисел и множеством натуральных (действительных) чисел невозможно построить изоморфизм порядка. Разумеется, множество всех возможных значений любого машинного типа данных является конечным, хотя и очень большим.

При наличии обратимой функции-нумератора и обратимой функции-интерполятора ,

прокрутка грида сводится к вычислению значений ключевых полей , где — положение вертикальной полосы прокрутки, после чего быстрый запрос к БД находит первых записей, больших или равных ,
позиционирование сводится к считыванию первых записей из БД по заранее известным значениям , и к вычислению положения бегунка полосы прокрутки .

Схема взаимодействия процедур

На этом этапе мы можем отвлечься от математики и разобраться собственно с алгоритмической частью. Общая схема взаимодействия процедур системы показана на рисунке ниже. Использована «приблизительная UML Activity» нотация, при этом сплошной стрелкой показана последовательность выполнения процедур, а пунктирной стрелкой — асинхронный вызов в отдельном потоке выполнения:

Допустим, что пользователь изменил положение бегунка вертикальной полосы прокрутки (см. в левый нижний угол диаграммы). Интерполятор вычисляет значение номера комбинации значений ключевых полей () с типом BigInteger. На основе этого значения нумератор восстанавливает комбинацию ключевых полей .

Здесь важно понимать, что на данном этапе в полях не обязательно будут находиться значения, действительно присутствующие в базе данных: там будут лишь приближения. В строковых полях, например, будет бессмысленный набор символов. Тем не менее, благодаря замечательному свойству запроса B, вывод из базы данных строк с ключами, большими или равными набору , окажется приблизительно верным результатом для данного положения полосы прокрутки.

Если пользователь отпустил полосу прокрутки и какое-то время не трогал её, асинхронно (в отдельном потоке выполнения) запускается запрос D, определяющий порядковый номер записи, а значит, и точное положение полосы прокрутки, которое соответствует тому, что отображено пользователю. Когда запрос будет завершён, на основе полученных данных будет пополнена интерполяционная таблица. Если к этому моменту пользователь не начал снова прокручивать таблицу, вертикальный бегунок «отскочит» на новое, уточнённое положение.

При переходе к записи последовательность вызовов процедур происходит в обратную сторону. Т. к. значения ключевых полей уже известны, для пользователя запросом B сразу извлекаются данные из базы. Нумератор вычисляет , и затем интерполятор определяет приблизительное положение полосы прокрутки как . Параллельно, в асинхронном потоке выполнения, выполняется уточняющий запрос, по результатам которого в интерполяционную таблицу добавляется новая точка. Через секунду-другую бегунок полосы прокрутки «отскочит» на новое, уточнённое положение.

Чем больше пользователь будет «бродить» по данным вертикальным бегунком, тем больше точек будет собираться в интерполяционной таблице и тем меньше будут «отскоки». Практика показывает, что достаточно всего 4-5 удачных точек в интерполяционной таблице, чтобы «отскоки» стали очень малы.

Экземпляр класса-интерполятора должен хранить в себе промежуточные точки монотонно растущей функции между множеством 32-битных целых чисел (номеров записей в таблице) и множеством объектов типа BigInteger (порядковых номеров комбинаций значений ключевых полей).

Сразу же после инициализации грида необходимо в отдельном потоке выполнения запросить общее количество записей в таблице, чтобы получить корректное значение . До того момента, как это значение будет получено при помощи выполняющегося в параллельном потоке запроса, можно использовать некоторое значение по умолчанию (например, 1000) — это не повлияет на корректность работы.

Интерполятор должен уметь за быстрое по количеству интерполяционных точек время вычислять значение как в одну, так и в другую сторону. Однако заметим, что чаще требуется вычислять значение порядкового номера комбинации по номеру записи: такие вычисления производятся много раз за секунду в процессе прокрутки грида пользователем. Поэтому за основу реализации модуля интерполятора удобно взять словарь на основе бинарного дерева, ключами которого являются номера записей, а значениями — порядковые номера комбинаций (класс TreeMap<Integer, BigInteger> в языке Java).

Ясно, что по заданному номеру такой словарь за логарифмическое время находит две точки (), между которыми строит прямую интерполяцию функции . Но тот факт, что растёт монотонно, позволяет за быстрое время производить и обратное вычисление. В самом деле: если дан номер комбинации , , поиск кусочного сегмента, в котором лежит , можно произвести в словаре методом дихотомии. Отыскав нужный сегмент, мы производим обратную интерполяцию и находим номер , соответствующий .

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

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

Заключение к первой части

Итак, мы разобрались, как в целом устроена наша система: основными её частями являются интерполятор и нумератор, а также полностью обсудили реализацию интерполятора. Чтобы завершить решение задачи, необходимо теперь реализовать нумератор — биекцию , увязывающую наборы значений ключевых полей, возможно, состоящих из дат, строки, отсортированных при помощи Unicode collation rules и т. п. с растущими в том же порядке числами.

2016: Модернизирована QueryGrid

15 сентября 2016 года Teradata сообщила о выпуске релиза версии QueryGrid.

Продуктом предоставлена возможность анализировать данных из разнородных, мультисистемных хранилищ данных. В QueryGrid следующего поколения ожидается мощная базовая архитектура с принципиальными усовершенствованиями, среди которых:

один соединитель для каждой целевой системы для обеспечения непротиворечивого синтаксиса и логики работы вне зависимости от того, в какой системе формируется запрос
системные сервисы, в том числе усиленная безопасность, шифрование и мониторинг производительности

Усовершенствования в Teradata QueryGrid следующего поколения будут доступны для заказа начиная с 4-го квартала 2016 года.

Поддержка Oracle Database

7 октября 2014 года компания Teradata объявила о полноценной поддержке системой Teradata QueryGrid передачи данных для анализа между базами данных Teradata и Oracle, это позволяет пользователям хранилищ данных Teradata объединить аналитическую информацию с БД Oracle.

Обновленный функционал

ПО Teradata QueryGrid поддерживает работу с БД Oracle.

Teradata QueryGrid в основе Data Fabric

6 ноября 2014 года компания Teradata представила универсальную структуру данных (Data Fabric) на платформе Teradata QueryGrid.

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

Структура Teradata QueryGrid

Универсальная структура данных взаимосвязана с различными системами. Она обеспечивает гибкость и помогает в выборе файловых и операционных систем, типов данных, аналитических механизмов и характеристик архитектуры систем, соответствующих бизнес-целям. Посредством её организуется безопасное, оптимальное выполнение запросов в рамках нескольких механизмов обработки и хранилищ.

Новые возможности универсальной структуры данных Teradata QueryGrid помогают:

реализовать взаимодействие между базами данных Teradata

Компании могут воспользоваться преимуществами семейства платформ Teradata, учитывающих специфику рабочих нагрузок, соединяющих различные системы в бизнес-целях, обеспечивая производительность, доступность и ценность данных, а также масштабируя аналитическую экосистему эффективным и экономичным образом. Системы Teradata взаимодействуют так, чтобы постоянно гарантировать максимальную производительность, необходимую для выполнения SLA-соглашений, управляя балансировкой рабочих нагрузок систем. Работа с системой проста, как для администраторов, так и для пользователей, посредством единой панели наблюдения за использованием кросс-платформенных ресурсов через интегрированный план выполнения запроса и общим инструментам администрирования. Компании получают преимущества мультисистемной среды Teradata и простоту использования одной системы.

взаимодействовать между базой данных Teradata и базой данных Teradata Aster

QueryGrid дополняет возможности БД Teradata современными встроенными функциями Teradata Aster, включая nPath, Graph и Sessionize. Простота интеграции позволяет пользователям БД Teradata вызывать функции Aster в SQL-запросах. Одной команды достаточно для управления данными с использованием более 100 встроенных аналитических функций.

исполнять адаптивный оптимизатор (Adaptive Optimizer)

Адаптивный оптимизатор в рамках БД Teradata обеспечивает высочайшую производительность запросов, выполняемых по нескольким системам разных поставщиков, использующим разные технологии. Это достигается за счет динамического сбора статистики при возвращении результатов запросов с удаленных систем. Эти результаты сочетаются со ступенчатым планированием запросов, чтобы получившиеся в результате запросы выполнялись быстро и эффективно, даже когда данные извлекаются из систем с разными технологиями, например из реляционных БД Oracle, Hadoop или NoSQL MongoDB.

Возможности универсальной структуры данных станут доступными после обновления QueryGrid и Teradata Database в конце 4 квартала 2014 года.

В рамках продукта практикуется подход к мультисистемной аналитике, предоставляя пользователям возможность работать самостоятельно со своими данными и аналитикой при помощи SQL. Пользователи могут применять свой опыт и навыки SQL, получая необходимые им аналитики без дополнительного обучения.

Представление QueryGrid: Teradata-Hadoop (2013)

Teradata QueryGrid помогает автоматизировать и оптимизировать использование аналитических систем посредством распределения обработки данных по всем платформам:

Teradata QueryGrid

Teradata QueryGrid - продукт расширения возможностей «озера данных» Hadoop и одновременно инструмент аналитики.

24 апреля 2014 года Teradata сообщила о своём предложении решения для анализа больших объемов данных Teradata QueryGrid.

Это решение - единственный программный продукт, на 24 апреля 2014 года, оптимизирующий процессы анализа данных в масштабах предприятия и за его пределами.

Teradata QueryGrid предоставляет пользователям простой и непосредственный доступ к данным и процессам аналитики в различных системах с помощью всего одного запроса в базу данных Teradata Database или Teradata Aster Database. Teradata QueryGrid задействует аналитические механизмы и файловые системы, чтобы реализовать оценку и анализ данных без использования специальных инструментов или другого вмешательства ИТ-специалистов. Это решение сводит к минимуму необходимость в перемещении и копировании данных, позволяя обрабатывать данные там, где они хранятся.

База данных Teradata Database 15, поддерживающая QueryGrid, обеспечивает двустороннее перемещение данных и их каскадную обработку в Hadoop, Aster Database и других базах данных. Из базы данных Teradata Database можно отправлять запросы на доступ к данным, их фильтрацию и возврат подмножеств из Hadoop, Aster Database и других сред в Teradata Database для дополнительной обработки. В анализ могут быть включены данные из Teradata Database и Hadoop.

Архитектура данных Teradata Unified Data Architecture, объединяющая в себе Teradata Database, платформу Teradata Aster Discovery Platform и технологию Hadoop, позволяет Teradata QueryGrid расширять и дополнять запросы в базы данных Teradata и Aster, предоставляя пользователям полезную аналитическую информацию.

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

Возможности Teradata QueryGrid станут доступны пользователям в третьем квартале 2014 года.

Technical specification¶

Type support¶

Type in Presto	Type in Teradata	Notes
BOOLEAN	BYTEINT
BIGINT	BIGINT
DOUBLE	REAL
VARCHAR	VARCHAR	Values exceeding MaximumTextLength will be truncated
DATE	DATE
TIMESTAMP	TIMESTAMP
VARBINARY	VARBYTE	Error thrown on values exceeding MaximumBinaryLength
JSON	VARCHAR
ARRAY	VARCHAR	Serialized to/from json
MAP	VARCHAR	Serialized to/from json
ROW	VARCHAR	Serialized to json in import path. Writing ROW values to Presto is not supported

Приветствуем CSS Container Queries

За последние шесть лет моей работы в качестве front-end разработчика я не был так рад появлению CSS фитчи, как сейчас. Прототип container queries теперь доступен в Chrome Canary. Благодаря усилиям таких умных людей, как Miriam Suzanne и других.

Я помню, что видел много шуток по поводу поддержки CSS container queries, но они наконец-то появились. В этой статье я расскажу вам, зачем нужны container queries, как они облегчат вам жизнь, а главное, вы увидите более мощные компоненты и разметки.

Если вы взволнованы так же, как и я, то давайте начнем. Вы готовы?

Проблема с CSS Media Queries

*CSS Media Queries - Медиа запросы

Веб-страница состоит из различных разделов и компонентов, и мы делаем их отзывчивыми с помощью CSS media queries. В этом нет ничего плохого, но это имеет свои ограничения. Например, мы можем использовать media query, чтобы показать минимальную версию компонента на мобильном устройстве по сравнению с десктопом.

Зачастую отзывчивый веб-дизайн не имеет отношения к области просмотра или размеру экрана. Речь идет о размере контейнера. Рассмотрим следующий пример:

У нас есть очень типичная разметка компонента карточки, которая имеет две вариации:

Cтековая (см. в сторону)

Горизонтальная (см. основную)

Существует множество способов реализовать это в CSS, но наиболее распространенный из них выглядит следующим образом. Нам нужно создать базовый компонент, а затем сделать его вариации.

Обратите внимание, что мы создали класс .c-article--horizontal для работы с горизонтальной версией компонента. Если ширина области просмотра больше 46rem, то компонент должен перейти в горизонтальную вариацию.

Это не плохо, но почему-то это заставляет меня чувствовать себя немного ограниченным. Я хочу, чтобы компонент реагировал на ширину родительского компонента, а не на область просмотра браузера или размер экрана.

Предположим, что мы хотим использовать стандартную .c-card в главной секции. Что произойдет? По сути, карточка расширится до ширины родительского компонента и, таким образом, будет слишком большой. Смотрите следующий рисунок:

Это проблема, и мы можем решить ее с помощью CSS container queries (ура, наконец-то). Однако, прежде чем погрузиться в них, позвольте мне дать вам представление о результате, который мы хотим получить.

Нам нужно указать компоненту, что если ширина его родительского компонента больше 400px, то он должен переходить на горизонтальный стиль. Вот как будет выглядеть CSS:

Как CSS Container Queries помогают нам?

Внимание: CSS container queries пока поддерживаются только в Chrome Canary под экспериментальным флагом.

С помощью CSS container queries мы можем решить вышеописанную проблему и сделать компонент Fluid. Это значит, что мы можем поместить компонент в родительский, и он превратится в сложенную версию, или поместить его в широкий компонент, и он превратится в горизонтальную версию. Опять же, все это не зависит от ширины области просмотра.

Вот как я себе это представляю.

Фиолетовый контур представляет собой ширину родительского компонента. Обратите внимание, что когда происходит увеличение, компонент адаптируется к этому. Разве это не потрясающе? В этом и заключается сила CSS container queries.

Как работают Container Queries?

Теперь мы можем поэкспериментировать с Chrome Canary container queries . Чтобы активировать их, перейдите по адресу chrome://flags и найдите "container queries", а затем запустите их.

Первым шагом будет добавление свойства contain . Поскольку компонент адаптируется в зависимости от ширины родительского компонента, нам нужно указать браузеру, что необходимо перерисовывать только затронутую область, а не всю страницу. С помощью свойства contain мы можем сообщить браузеру об этом заранее.

Значение inline-size означает, что нужно реагировать только на изменение ширины родительского компонента. Я пробовал использовать block-size, но это пока не работает. Пожалуйста, поправьте меня, если я ошибаюсь.

Это первый шаг. Мы определили элемент .o-grid__item в качестве родительского элемента для содержащегося в нем .c-article.

Следующим шагом будет добавление стилей, необходимых для работы container queries.

@container - это элемент .o-grid__item, а min-width: 400px- его ширина. Мы можем даже пойти дальше и добавить больше стилей. Вот видео о том, чего можно добиться для компонента карточки:

Здесь есть следующие стили:

По умолчанию - вид, похожий на карточку.

Горизонтальная карточка с небольшой миниатюрой.

Горизонтальная карточка с большой миниатюрой.

Если родительский компонент слишком большой, то это будет как hero-стиль с указанием на то, что это тематическая статья.

Давайте разберемся с вариантами использования CSS container queries.

Использование кейсов для CSS Container Queries

Container Queries и CSS Grid auto-fit

В некоторых случаях использование auto-fit в CSS grid может привести к неожиданным результатам. Например, компонент будет слишком широким, и его содержимое будет трудно прочитать.

Чтобы немного прояснить ситуацию, вот наглядный пример, показывающий разницу между auto-fit и auto-fill в CSS grid (CSS сетка).

Обратите внимание, что при использовании auto-fit элементы расширяются, заполняя доступное пространство. Однако в случае auto-fill элементы сетки не будут увеличиваться, и вместо них появится свободное пространство (пунктирный элемент в крайнем правом углу).

Возможно, вы сейчас подумаете, какое отношение это имеет к CSS container queries? Так вот, каждый элемент сетки является контейнером, и когда он расширяется ( когда мы используем auto-fit), нам нужно, чтобы компонент менялся соответственно.

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

Это изменится, когда количество статей станет меньше, смотрите, что произойдет. Чем меньше статей, тем шире они становятся. Причина в том, что используется auto-fit. Первый вариант выглядит хорошо, но последние два (2 в ряду, 1 в ряду) выглядят не очень хорошо, так как они слишком широкие.

Что если каждый компонент статьи будет изменяться в зависимости от ширины его родительского компонента? Таким образом, мы сможем получить преимущество auto-fit. Вот что нам нужно сделать:

Если ширина элемента сетки больше 400px, то статья должна переходить на горизонтальный стиль.

Вот как мы можем это сделать:

Кроме того, мы хотим отображать статью с hero-секцией, если это единственный элемент в сетке.

Вот и все. У нас есть компонент, который реагирует на ширину своего родительского компонента, и он может работать в любом контексте. Разве это не потрясающе?

Боковая и основная панель

*Сайдбар - боковая панель

Зачастую нам нужно настроить компонент так, чтобы он работал в контейнерах небольшой ширины, например как <aside>.

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

Как вы видите на рисунке, у нас есть новостная лента, которая находится в двух разных контекстах:

Без container queries невозможно ничего сделать, пока у нас не появится класс вариаций в CSS, например, .newsletter--stacked или что-то подобное.

Я знаю, что мы можем заставить элементы свернуться в случае недостатка места с помощью flexbox, но этого недостаточно. Мне нужно гораздо больше контроля, чтобы:

Скрыть определенные элементы

Сделать кнопку во всю ширину

Вот видео с результатом.

Пагинация

Я обнаружил, что пагинация хорошо подходит для использования container queries. Изначально мы можем использовать кнопки "Предыдущий" и "Следующий", затем мы можем скрыть их и продемонстрировать полную пагинацию, если у нас достаточно места.

Взгляните на следующий рисунок.

Чтобы управлять вышеуказанными состояниями, нам нужно сначала поработать над стилем по умолчанию (сложенные кнопки), а затем поработать над двумя другими состояниями.

Карточка профиля

Вот еще один пример, который идеально подходит для использования в нескольких контекстах. В зависимости от состояния, оно может подходить для небольшой области просмотра и таких контекстов, как боковая панель или для более крупных контекстов, например, для размещения в 2-col сетке.

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

Формирование элементов

Я пока не углублялся в использование форм, но один из вариантов, который у меня на уме, - это переход от горизонтального расположения меток к сложенному.

Попробуйте сами в демо-версии ниже. Просмотрите демо-версию на CodePen.

Тестирование компонентов

Теперь, когда мы рассмотрели несколько случаев использования CSS container queries, как мы можем протестировать компонент? К счастью, мы можем сделать это с помощью свойства CSS resize родительского компонента.

Я узнал об этой технике, прочитав эту замечательную статью Bramus Van Damme.

Легко ли дебаггить сontainer queries в DevTools?

Короткий ответ - нет. Вы не можете увидеть что-то вроде @container (min-width: value). Я думаю, что это вопрос времени, и это будет поддерживаться.

Можно ли предусмотреть запасной вариант?

Да! Конечно. Определенными способами можно обеспечить возврат. Вот две замечательные статьи, которые объясняют, как это сделать:

Решения Container Query с помощью CSS Grid и Flexbox (Container Query Solutions with CSS Grid and Flexbox ) от Stephanie Eckles

Container Queries уже на подходе (Container Queries are actually coming) от Andy Bell

Заключение

Мне понравилось узнавать о CSS container queries и экспериментировать с ними в браузере. Я знаю, что они еще официально не поддерживаются, но сейчас самое время поработать с ними в браузере.

Так как мы front-end разработчики, часть нашей работы заключается в тестировании и помощи тем, кто работает над внедрением таких функций. Чем больше мы тестируем, тем меньше проблем мы увидим, когда это будет поддерживаться во всех основных браузерах.

Спасибо, что прочитали.

Я написал электронную книгу

Я рад сообщить вам, что написал электронную книгу о дебаггинге CSS.

В преддверии старта курса "HTML/CSS" приглашаем всех желающих на бесплатный демо-урок «CSS Reset — ненужный артефакт или спасательный круг». На этом вебинаре рассмотрим, зачем нам CSS Reset, что такое рендеринг и как браузер рендерит страницу.

Читайте также: