{{l10n_strings.DRAG_TEXT_HELP}}

{{article.content_lang.display}}

{{l10n_strings.AUTHOR_TOOLTIP_TEXT}}

Типы измерений

Типы измерений

Эта страница относится к параметру типа , который является частью меры.

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

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

view: view_name {
measure: field_name {
type: measure_field_type
}
}

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

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

Каждый тип меры попадает в одну из следующих категорий. Эти категории определяют, выполняет ли тип меры агрегирование, тип полей, на которые может ссылаться этот тип меры, и можно ли отфильтровать тип меры с помощью параметра Filters :

• Агрегатные меры : Типы агрегированных мер выполняют агрегирование, например сумма и среднее . Агрегированные меры могут ссылаться только на измерения, но не на другие меры. Это единственный тип меры, который работает с параметром Filters .
• Неагрегированные меры : Неагрегированные меры, как следует из названия, представляют собой типы мер, которые не выполняют агрегирование, например номер и да нет . Эти типы мер выполняют простые преобразования и, поскольку они не выполняют агрегирования, могут ссылаться только на агрегированные меры или ранее агрегированные измерения.Вы не можете использовать параметр Filters с этими типами мер.
• Меры Post-SQL : Меры Post-SQL — это особые типы мер, которые выполняют определенные вычисления после того, как Looker сгенерировал запрос SQL. Они могут ссылаться только на числовые меры или числовые измерения. Вы не можете использовать параметр Filters с этими типами мер.

Тип	Категория	Описание
среднее	Агрегат	Создает среднее (среднее) значений в столбце
средний_дистинкт	Агрегат	Правильно генерирует среднее (среднее) значений при использовании денормализованных данных. Полное описание см. В приведенном ниже определении.
счетчик	Агрегат	Создает количество строк
count_distinct	Агрегат	Создает количество уникальных значений в столбце
дата	Неагрегат	Для мер, содержащих даты
список	Агрегат	Создает список уникальных значений в столбце
макс.	Агрегат	Создает максимальное значение в столбце
медиана	Агрегат	Создает медианное значение (среднее значение) значений в столбце
median_distinct	Агрегат	Правильно генерирует медианное значение (среднее значение) значений, когда соединение вызывает разветвление. Полное описание см. В приведенном ниже определении.
мин.	Агрегат	Создает минимальное значение в столбце
номер	Неагрегат	Для мер, содержащих числа
процент_предыдущего значения	Post-SQL	Создает процентную разницу между отображаемыми строками
процентов от общей суммы	Post-SQL	Создает процент от суммы для каждой отображаемой строки
процентиль	Агрегат	Создает значение в указанном процентиле в столбце
percentile_distinct	Агрегат	Правильно генерирует значение в указанном процентиле, когда соединение вызывает разветвление. Полное описание см. В приведенном ниже определении.
итого	Post-SQL	Создает промежуточную сумму для каждой отображаемой строки
строка	Неагрегат	Для показателей, содержащих буквы или специальные символы (как в MySQL GROUP_CONCAT функция)
сумма	Агрегат	Создает сумму значений в столбце
sum_distinct	Агрегат	Правильно генерирует сумму значений при использовании денормализованных данных. Полное описание см. В приведенном ниже определении.
да нет	Неагрегат	Для полей, которые покажут, правда ли что-то или нет
внутренний	Неагрегат	УДАЛЕНО 5.4 Заменено на тип: номер

тип: среднее усредняет значения в заданном поле. Это похоже на функцию SQL AVG .Однако, в отличие от написания необработанного SQL, Looker будет правильно вычислять средние значения, даже если соединения вашего запроса содержат разветвления.

Параметр sql для типа : средние меры могут принимать любое допустимое выражение SQL, которое приводит к столбцу числовой таблицы, измерению LookML или комбинации измерений LookML.

Тип : поля среднего значения могут быть отформатированы с использованием параметров value_format или value_format_name .

Например, следующий LookML создает поле с именем avg_order путем усреднения измерения sales_price , а затем отображает его в денежном формате (1234 доллара.56):

measure: avg_order { тип: средний sql: $ {sales_price} ;; value_format_name: usd }

тип: average_distinct предназначен для использования с денормализованными наборами данных. Он усредняет неповторяющиеся значения в данном поле на основе уникальных значений, определенных параметром sql_distinct_key .

Это продвинутая концепция, которую можно более четко пояснить на примере. Рассмотрим денормализованную таблицу, подобную этой:

В этой ситуации вы можете видеть, что для каждого заказа есть несколько строк. Следовательно, если вы добавите простой тип : среднее значение для столбца order_shipping , вы получите значение 16.00, хотя фактическое среднее значение составляет 15,00.

# НЕ будет вычислять правильное среднее значение measure: avg_shipping { тип: средний sql: $ {order_shipping} ;; }

Чтобы получить точный результат, вы можете объяснить Looker, как он должен идентифицировать каждый уникальный объект (в данном случае каждый уникальный порядок), используя параметр sql_distinct_key . Этот вычислит правильную сумму 15,00:

# Подсчитает правильное среднее measure: avg_shipping { тип: average_distinct sql_distinct_key: $ {order_id} ;; sql: $ {order_shipping} ;; }

Обратите внимание, что каждое уникальное значение sql_distinct_key должно иметь только одно соответствующее значение в sql .Другими словами, приведенный выше пример работает, потому что каждая строка с order_id из 1 имеет тот же order_shipping из 10,00, каждая строка с order_id из 2 имеет тот же order_shipping из 20,00, и скоро.

Поля type: average_distinct можно отформатировать с помощью параметров value_format или value_format_name .

тип: count выполняет подсчет таблицы, аналогично функции SQL COUNT .Однако, в отличие от написания необработанного SQL, Looker будет правильно вычислять счетчики, даже если соединения вашего запроса содержат разветвления.

Меры типа: count не поддерживают параметр sql , поскольку мера типа : count выполняет подсчет таблиц на основе первичного ключа таблицы. Если вы хотите выполнить подсчет таблицы для поля, отличного от первичного ключа таблицы, используйте показатель типа : count_distinct .

Например, следующий LookML создает поле number_of_products :

view: products { measure: number_of_products { тип: количество Drill_fields: [product_details *] # необязательно } }

Очень часто при определении меры типа : count предоставляют параметр Drill_fields (для полей), чтобы пользователи могли видеть отдельные записи, составляющие счетчик, при нажатии на нее.

Когда вы используете меру типа : count в Explore, визуализация помечает результирующие значения именем представления, а не словом «Count». Чтобы избежать путаницы, мы рекомендуем использовать множественное число для имени вашего представления, выбрав Показать полное имя поля в разделе Series в настройках визуализации или использовать view_label с версией во множественном числе имени вашего представления.

Если вы хотите выполнить COUNT (а не COUNT_DISTINCT ) для поля, которое не является первичным ключом, вы можете сделать это, используя показатель типа : число .Дополнительные сведения см. В статье Справочного центра «Разница между типами мер count и count_distinct ».

Вы можете добавить фильтр к показателю типа : подсчитать с помощью параметра Filters .

тип: count_distinct вычисляет количество различных значений в заданном поле. Он использует функцию SQL COUNT DISTINCT .

Параметр sql для типа : count_distinct меры могут принимать любое допустимое выражение SQL, которое приводит к столбцу таблицы, измерению LookML или комбинации измерений LookML.

Например, следующий LookML создает поле number_of_unique_customers , которое подсчитывает количество уникальных идентификаторов клиентов:

measure: number_of_unique_customers { тип: count_distinct sql: $ {customer_id} ;; }

Вы можете добавить фильтр к мере типа : count_distinct , используя параметр Filters .

тип: дата используется с полями, содержащими даты.

Параметр sql для мер type: date может принимать любое допустимое выражение SQL, которое приводит к дате.На практике этот тип используется редко, поскольку большинство агрегатных функций SQL не возвращают даты. Одним из распространенных исключений является MIN или MAX измерения даты.

Например, следующий LookML создает поле most_recent_order_date , беря максимальное значение из поля order_date :

measure: most_recent_order_date { тип: дата sql: MAX ($ {order_date}) ;; convert_tz: нет }

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

Вы можете использовать параметр datatype с type: date , чтобы повысить производительность запроса, указав тип данных даты, которые использует ваша таблица базы данных.

тип: список создает список различных значений в данном поле. Это похоже на функцию MySQL GROUP_CONCAT .

Нет необходимости включать параметр sql для типа : список мер . Вместо этого вы воспользуетесь параметром list_field , чтобы указать измерение, из которого вы хотите создавать списки.

Использование:

view: view_name {
measure: field_name {
type: list
list_field: my_field_name
}
}

Например, следующий LookML создает меру name_list на основе измерения name :

measure: name_list { тип: список list_field: имя }

Обратите внимание на следующее для списка :

• Список Тип меры не поддерживает фильтрацию.Вы не можете использовать параметр , фильтры для меры типа : список .
• Список Тип меры нельзя ссылаться с помощью оператора подстановки ($). Вы не можете использовать синтаксис $ {} для ссылки на меру type: list .

Поддерживаемые диалекты базы данных для списка

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

тип: max находит наибольшее значение в заданном поле. Он использует функцию SQL MAX .

Параметр sql для типа : макс. меры могут принимать любое допустимое выражение SQL, которое приводит к столбцу числовой таблицы, измерению LookML или комбинации измерений LookML. Это будет , а не работать с датами; вместо этого см. пример типа type: date выше.

тип: макс. поля могут быть отформатированы с использованием параметров value_format или value_format_name .

Например, следующий LookML создает поле с именем large_order , просматривая измерение sales_price , а затем отображает его в денежном формате (1234,56 доллара США):

measure: large_order { тип: макс sql: $ {sales_price} ;; value_format_name: usd }

В настоящее время вы не можете использовать тип : max меры для строк или дат, но вы можете вручную добавить функцию MAX для создания такого поля, например:

measure: latest_name_in_alphabet { тип: строка sql: MAX ($ {name}) ;; }

тип: median возвращает среднее значение для значений в данном поле. Это особенно полезно, когда в данных есть несколько очень больших или малых выбросов, которые могут исказить простое среднее (среднее) данных.

Рассмотрим такую ​​таблицу:

Для удобства просмотра таблица отсортирована по стоимости, но это не влияет на результат. В то время как средний тип вернет 42 (сложение всех значений и деление на 5), тип медианы вернет среднее значение: 20,00.

Если имеется четное количество значений, то среднее значение рассчитывается путем взятия среднего из двух значений, ближайших к средней точке.Рассмотрим такую ​​таблицу с четным числом строк:

Медиана, среднее значение, составляет (20 + 80) / 2 = 50 .

Медиана также равна значению 50-го процентиля.

Параметр sql для мер type: median может принимать любое допустимое выражение SQL, которое приводит к столбцу числовой таблицы, измерению LookML или комбинации измерений LookML.

тип: медианные поля могут быть отформатированы с помощью параметров value_format или value_format_name .

Пример

Например, следующий LookML создает поле с именем median_order путем усреднения измерения sales_price , а затем отображает его в денежном формате ($ 1,234.56):

measure: median_order { тип: срединный sql: $ {sales_price} ;; value_format_name: usd }

Что необходимо учитывать при медиане

Если вы используете median_distinct для поля, участвующего в разветвлении, Looker попытается вместо этого использовать median_distinct . Однако medium_distinct поддерживается только для определенных диалектов. Если median_distinct недоступен для вашего диалекта, Looker возвращает ошибку. Поскольку медиана может считаться 50-м процентилем, ошибка указывает на то, что диалект не поддерживает отдельные процентили.

Поддерживаемые диалекты базы данных для медианы

Для того, чтобы Looker поддерживал медианный тип в вашем проекте Looker, диалект вашей базы данных также должен его поддерживать. В следующей таблице показано, какие диалекты поддерживают тип median в Looker 21.20:

Когда в запросе задействовано разветвление, Looker пытается преобразовать медиану в median_distinct . Это успешно только в диалектах, поддерживающих median_distinct .

Используйте тип : median_distinct , если ваше соединение включает разветвление. Он усредняет неповторяющиеся значения в данном поле на основе уникальных значений, определенных параметром sql_distinct_key . Если у меры нет параметра sql_distinct_key , Looker пытается использовать поле primary_key .

Рассмотрим результат запроса, объединяющего таблицы «Позиция заказа» и «Заказ»:

В этой ситуации вы можете видеть, что для каждого заказа есть несколько строк. Этот запрос включал разветвление, потому что каждый заказ соответствует нескольким элементам заказа. median_distinct принимает это во внимание и находит медиану между различными значениями 10, 20 и 50, так что вы получите значение 20.

Чтобы получить точный результат, вы можете объяснить Looker, как он должен идентифицировать каждый уникальный объект (в данном случае каждый уникальный порядок), используя параметр sql_distinct_key . Это позволит рассчитать правильную сумму:

measure: median_shipping { тип: median_distinct sql_distinct_key: $ {order_id} ;; sql: $ {order_shipping} ;; }

Обратите внимание, что каждое уникальное значение sql_distinct_key должно иметь только одно соответствующее значение в параметре sql меры.Другими словами, приведенный выше пример работает, потому что каждая строка с order_id из 1 имеет тот же order_shipping из 10, каждая строка с order_id из 2 имеет тот же order_shipping из 20, и скоро.

Поля type: median_distinct можно отформатировать с помощью параметров value_format или value_format_name .

Что нужно учитывать для

Тип меры medium_distinct поддерживается только для определенных диалектов.Если median_distinct недоступен для диалекта, Looker возвращает ошибку. Поскольку медиана может считаться 50-м процентилем, ошибка указывает на то, что диалект не поддерживает отдельные процентили.

Поддерживаемые диалекты базы данных для

Для того, чтобы Looker поддерживал тип median_distinct в вашем проекте Looker, ваш диалект базы данных также должен его поддерживать. В следующей таблице показано, какие диалекты поддерживают тип median_distinct в Looker 21.20:

тип: min находит наименьшее значение в заданном поле. Он использует функцию SQL MIN .

Параметр sql для типа : минимальные меры могут принимать любое допустимое выражение SQL, которое приводит к столбцу числовой таблицы, измерению LookML или комбинации измерений LookML. Это будет , а не работать с датами; вместо этого см. пример типа type: date выше.

type: min можно отформатировать с помощью параметров value_format или value_format_name .

Например, следующий LookML создает поле с именем smallest_order , просматривая измерение sales_price , а затем отображает его в денежном формате (1234,56 доллара США):

measure: smallest_order { тип: мин sql: $ {sales_price} ;; value_format_name: usd }

В настоящее время вы не можете использовать тип : min меры для строк или дат, но вы можете вручную добавить функцию MIN для создания такого поля, например:

measure: early_name_in_alphabet { тип: строка sql: MIN ($ {name}) ;; }

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

Параметр sql для мер type: number может принимать любое допустимое выражение SQL, которое приводит к числу или целому числу.

тип: число Поля могут быть отформатированы с использованием параметров value_format или value_format_name .

Например, следующий LookML создает меру с именем total_gross_margin_percentage на основе агрегированных показателей total_sale_price и total_gross_margin , а затем отображает ее в процентном формате с двумя десятичными знаками (12,34%):

measure: total_sale_price { тип: сумма value_format_name: usd sql: $ {sale_price} ;; } measure: total_gross_margin { тип: сумма value_format_name: usd sql: $ {ross_margin} ;; } measure: total_gross_margin_percentage { тип: число value_format_name: процент_2 sql: $ {total_gross_margin} / NULLIF ($ {total_sale_price}, 0) ;; }

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

Что нужно учитывать для типа

При использовании типа следует учитывать несколько важных моментов: число меры:

• Мера типа : число может выполнять арифметические действия только с другими мерами, но не с другими измерениями.
Симметричные агрегаты
• Looker не будут защищать агрегатные функции в SQL типа меры : число при вычислении через соединение.
• Фильтры Параметр нельзя использовать с показателями типа : число , но документация фильтры объясняет обходной путь.
• тип: номер меры не будут предлагать пользователям предложения.

тип: percent_of_previous вычисляет процентную разницу между ячейкой и предыдущей ячейкой в ​​ее столбце.

Параметр sql для типа : процент_из_предыдущих мер должен ссылаться на другую числовую меру.

тип: процент_предыдущих полей можно отформатировать с помощью параметров value_format или value_format_name . Однако процентные форматы параметра value_format_name не работают с измерениями типа : percent_of_previous . Эти процентные форматы умножают значения на 100, что искажает результаты предыдущего вычисления в процентах.

В следующем примере этот LookML создает меру count_growth на основе меры count :

measure: count_growth { тип: percent_of_previous sql: $ {count} ;; }

В пользовательском интерфейсе Looker это будет выглядеть так:

Обратите внимание, что процент_из_предыдущих значений зависят от порядка сортировки.Если вы измените сортировку, вы должны повторно запустить запрос, чтобы пересчитать процент_предыдущих значений . В тех случаях, когда запрос вращается, percent_of_previous выполняется по строке, а не по столбцу. В настоящее время вы не можете изменить это поведение.

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

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

Параметр sql для типа : percent_of_total меры должны ссылаться на другую числовую меру.

тип: процент_поля_общего можно отформатировать с помощью параметров value_format или value_format_name . Однако процентные форматы параметра value_format_name не работают с измерениями типа : percent_of_total . В этих процентных форматах значения умножаются на 100, что искажает результаты вычисления процент_полного_общего .

В следующем примере этот LookML создает меру percent_of_total_gross_margin на основе меры total_gross_margin :

measure: percent_of_total_gross_margin { тип: percent_of_total sql: $ {total_gross_margin} ;; }

В пользовательском интерфейсе Looker это будет выглядеть так:

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

Кроме того, percent_of_total меры вычисляются после того, как данные возвращены из вашей базы данных. Это означает, что вы не должны ссылаться на меру percent_of_total внутри другой меры; поскольку они могут быть рассчитаны в разное время, вы можете не получить точных результатов. Это также означает, что меры percent_of_total не могут быть отфильтрованы.

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

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

Если вычисленное значение не является целым числом

Looker округляет вычисленное значение в большую сторону и использует его для определения возвращаемого значения данных. В этом примере набора из 19 результатов тестов 75-й процентиль будет обозначен как 19 * 0,75 = 14,25, что означает, что 75% значений находятся в первых 14 значениях данных — ниже 15-й позиции. Таким образом, Looker возвращает 15-е значение данных (87), превышающее 75% значений данных.

Если вычисленное значение является целым числом

В этом немного более сложном случае Looker возвращает среднее значение данных в этой позиции и следующее значение данных.Чтобы понять это, рассмотрим набор из 20 результатов тестов, 75-й процентиль будет идентифицирован как 20 * 0,75 = 15, что означает, что значение данных на 15-й позиции является частью 75-го процентиля, и нам нужно вернуть значение, которое выше 75% значений данных. Возвращая среднее значение 15-й позиции (82) и 16-й позиции (87), Looker обеспечивает это 75%. Это среднее (84,5) не существует в наборе значений данных, но будет больше 75% значений данных.

Обязательные и необязательные параметры

Используйте ключевое слово процентиль: , чтобы указать дробное значение, то есть процент данных, который должен быть ниже возвращаемого значения. Например, используйте процентиль: 75 , чтобы указать значение на 75-м процентиле в порядке данных, или процентиль: 10 , чтобы вернуть значение на 10-м процентиле. Если вы хотите найти значение в 50-м процентиле, вы можете указать процентиль: 50 или просто использовать тип медианы.

Параметр sql для мер типа : процентиль может принимать любое допустимое выражение SQL, которое приводит к столбцу числовой таблицы, измерению LookML или комбинации измерений LookML.

тип: процентиль поля могут быть отформатированы с помощью параметров value_format или value_format_name .

Пример

Например, следующий LookML создает поле с именем test_scores_75th_percentile , которое возвращает значение 75-го процентиля в измерении test_scores :

measure: test_scores_75th_percentile { тип: процентиль процентиль: 75 sql: $ {ТАБЛИЦА}. результаты теста ;; }

Что нужно учитывать при

Если вы используете процентиль для поля, участвующего в разветвлении, Looker попытается вместо этого использовать процентиль_distinct . Если percentile_distinct недоступен для диалекта, Looker возвращает ошибку. Для получения дополнительной информации см. Поддерживаемые диалекты для percentile_distinct .

Поддерживаемые диалекты базы данных для

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

Тип : percentile_distinct — это специализированная форма процентиля, которую следует использовать, когда ваше соединение включает разветвление. Он использует неповторяющиеся значения в данном поле на основе уникальных значений, определенных параметром sql_distinct_key . Если у меры нет параметра sql_distinct_key , Looker пытается использовать поле primary_key .

Рассмотрим результат запроса, объединяющего таблицы «Позиция заказа» и «Заказ»:

В этой ситуации вы можете видеть, что для каждого заказа есть несколько строк. Этот запрос включал разветвление, потому что каждый заказ соответствует нескольким элементам заказа. percentile_distinct принимает это во внимание и находит значение процентиля, используя различные значения 10, 20, 50, 70 и 110. 25-й процентиль вернет второе отличное значение, или 20, а 80-й процентиль вернет среднее значение четвертое и пятое различные значения, или 90.

Обязательные и необязательные параметры

Используйте ключевое слово процентиль: , чтобы указать дробное значение.Например, используйте процентиль: 75 , чтобы указать значение на 75-м процентиле в порядке данных, или процентиль: 10 , чтобы вернуть значение на 10-м процентиле. Если вы пытаетесь найти значение на 50-м процентиле, вы можете вместо этого использовать тип median_distinct .

Чтобы получить точный результат, укажите, как Looker должен идентифицировать каждый уникальный объект (в данном случае каждый уникальный порядок) с помощью параметра sql_distinct_key .

Вот пример использования percentile_distinct для возврата значения на 90-м процентиле:

measure: order_shipping_90th_percentile { тип: percentile_distinct процентиль: 90 sql_distinct_key: $ {order_id} ;; sql: $ {order_shipping} ;; }

Обратите внимание, что каждое уникальное значение sql_distinct_key должно иметь только одно соответствующее значение в параметре sql меры.Другими словами, приведенный выше пример работает, потому что каждая строка с order_id из 1 имеет тот же order_shipping из 10, каждая строка с order_id из 2 имеет тот же order_shipping из 20, и поэтому на.

Поля type: percentile_distinct можно отформатировать с помощью параметров value_format или value_format_name .

Что нужно учитывать для

Если percentile_distinct недоступен для диалекта, Looker возвращает ошибку. Для получения дополнительной информации см. Поддерживаемые диалекты для percentile_distinct .

Поддерживаемые диалекты базы данных для

Для того, чтобы Looker поддерживал тип percentile_distinct в вашем проекте Looker, ваш диалект базы данных также должен его поддерживать. В следующей таблице показано, какие диалекты поддерживают тип percentile_distinct в Looker 21.20:

тип: running_total вычисляет совокупную сумму ячеек по столбцу.Его нельзя использовать для расчета сумм по строке, если только строка не является результатом поворота.

Параметр sql для типа : running_total measure должен ссылаться на другой числовой показатель.

type: running_total поля могут быть отформатированы с помощью параметров value_format или value_format_name .

Например, следующий LookML создает меру cumulative_total_revenue на основе меры total_sale_price :

measure: cumulative_total_revenue { тип: running_total sql: $ {total_sale_price} ;; value_format_name: usd }

В пользовательском интерфейсе Looker это будет выглядеть так:

Обратите внимание, что running_total значения зависят от порядка сортировки. Если вы измените сортировку, необходимо повторно запустить запрос, чтобы повторно вычислить значения running_total . В случаях, когда запрос вращается, running_total выполняется по строке, а не по столбцу. Если это нежелательно, добавьте направление : «столбец» к определению меры.

Кроме того, running_total меры вычисляются после того, как данные возвращены из вашей базы данных. Это означает, что вы не должны ссылаться на меру running_total внутри другой меры; поскольку они могут быть рассчитаны в разное время, вы можете не получить точных результатов.Это также означает, что running_total меры не могут быть отфильтрованы.

тип: строка используется с полями, содержащими буквы или специальные символы.

Параметр sql для мер type: string может принимать любое допустимое выражение SQL, которое приводит к строке. На практике этот тип используется редко, поскольку большинство агрегатных функций SQL не возвращают строки. Одним из распространенных исключений является функция MySQL GROUP_CONCAT , хотя Looker предоставляет тип : список для этого варианта использования.

Например, следующий LookML создает поле category_list путем объединения уникальных значений поля с именем category :

measure: category_list { тип: строка sql: GROUP_CONCAT ($ {category}) ;; }

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

тип: сумма складывает значения в заданном поле. Это похоже на функцию SQL СУММ .Однако, в отличие от написания необработанного SQL, Looker будет правильно вычислять суммы, даже если соединения вашего запроса содержат разветвления.

Параметр sql для мер type: sum может принимать любое допустимое выражение SQL, которое приводит к столбцу числовой таблицы, измерению LookML или комбинации измерений LookML.

Поля тип: сумма могут быть отформатированы с помощью параметров value_format или value_format_name .

Например, следующий LookML создает поле с именем total_revenue путем добавления измерения sales_price , а затем отображает его в денежном формате ($ 1,234.56):

measure: total_revenue { тип: сумма sql: $ {sales_price} ;; value_format_name: usd }

тип: sum_distinct предназначен для использования с денормализованными наборами данных. Он складывает неповторяющиеся значения в данном поле на основе уникальных значений, определенных параметром sql_distinct_key .

Это продвинутая концепция, которую можно более четко пояснить на примере. Рассмотрим денормализованную таблицу, подобную этой:

Код позиции заказа	Код заказа	Заказать Доставка
1	1	10. 00
2	1	10,00
3	2	20,00
4	2	20,00
5	2	20,00

В этой ситуации вы можете видеть, что для каждого заказа есть несколько строк. Следовательно, если вы добавите простой показатель типа : сумма для столбца order_shipping , вы получите в сумме 80.00, хотя на самом деле общая собранная стоимость доставки составляет 30,00.

# НЕ будет рассчитывать правильную сумму доставки measure: total_shipping { тип: сумма sql: $ {order_shipping} ;; }

Чтобы получить точный результат, вы можете объяснить Looker, как он должен идентифицировать каждый уникальный объект (в данном случае каждый уникальный порядок), используя параметр sql_distinct_key . Этот вычислит правильную сумму 30,00:

# Подсчитает правильную сумму доставки measure: total_shipping { тип: sum_distinct sql_distinct_key: $ {order_id} ;; sql: $ {order_shipping} ;; }

Обратите внимание, что каждое уникальное значение sql_distinct_key должно иметь только одно соответствующее значение в sql .Другими словами, приведенный выше пример работает, потому что каждая строка с order_id из 1 имеет тот же order_shipping из 10,00, каждая строка с order_id из 2 имеет тот же order_shipping из 20,00, и скоро.

Поля type: sum_distinct можно отформатировать с помощью параметров value_format или value_format_name .

тип: yesno создает поле, которое указывает, является ли что-то истинным или ложным.Значения отображаются как Да и Нет в пользовательском интерфейсе исследования.

Параметр sql для типа : да нет Мера принимает допустимое выражение SQL, которое принимает значение ИСТИНА или ЛОЖЬ . Если условие оценивается как ИСТИНА , Да, отображается пользователю; в противном случае отображается № .

Выражение SQL для типа: да нет меры должны включать только агрегаты, что означает агрегаты SQL или ссылки на меры LookML.Если вы хотите создать поле yesno , которое включает ссылку на измерение LookML или выражение SQL, которое не является агрегацией, используйте измерение с типом : yesno , а не мерой.

Аналогично мерам с типом : число , мера с типом : да, нет не выполняет агрегирования; он просто ссылается на другие агрегаты.

Например, показатель total_sale_price ниже представляет собой сумму общей продажной цены позиций заказа в заказе. Вторая мера под названием is_large_total — это , тип: yesno . Мера is_large_total имеет параметр sql , который оценивает, превышает ли значение total_sale_price 1000 долларов США.

measure: total_sale_price { тип: сумма value_format_name: usd sql: $ {sale_price} ;; Drill_fields: [деталь *] } measure: is_large_total { описание: «Сумма заказа превышает 1000 долларов?» тип: да нет sql: $ {total_sale_price}> 1000 ;; }

Если вы хотите сослаться на поле типа : yesno в другом поле, вы должны рассматривать поле type: yesno как логическое (другими словами, как если бы оно уже содержало истинное или ложное значение).Например:

measure: is_large_total { описание: «Сумма заказа превышает 1000 долларов?» тип: да нет sql: $ {total_sale_price}> 1000 ;; } } # Это верно measure: reward_points { тип: число sql: CASE WHEN $ {is_large_total} THEN 200 ELSE 100 END ;; } # Это НЕ правильно measure: reward_points { тип: число sql: CASE WHEN $ {is_large_total} = ‘Yes’ THEN 200 ELSE 100 END ;; }

Определения графиков заработной платы | CSU

Как отображать категории WooCommerce в вашем меню — Max Mega Menu

В этой статье мы рассмотрим шаги, необходимые для отображения категорий WooCommerce в вашем меню.

Шаг 1. Включите категории WooCommerce

Перейдите в «Внешний вид »> «Меню » и разверните раздел «Параметры экрана» в правом верхнем углу страницы. Включите «Категории продуктов» и «Теги продуктов».

Создайте пункт меню «Магазин», затем добавьте категории продуктов в качестве пунктов подменю.

Если вы добавили описание в категории продуктов, оно также будет перенесено в описание пункта меню, когда вы добавите его в меню. Вы можете удалить описания на этом этапе:

Сохраните меню.

Наведите курсор на пункт меню «Магазин» и нажмите синюю кнопку мегаменю. Установите «Режим отображения подменю» на «Мега-меню — Макет сетки».

Макет сетки будет автоматически заполнен элементами подменю (в данном случае нашими категориями продуктов). Разложите эти элементы в 4 столбца.

Наше меню теперь выглядит так:

Шаг 4. Добавление значков в категории

На этом этапе мы добавим пользовательские значки в наши пункты меню WooCommerce.Эта функция является частью Max Mega Menu Pro. Пользователи бесплатного плагина могут вместо этого выбрать дашиконы.

Наведите указатель мыши на пункт меню «Nokia» и нажмите синюю кнопку мегаменю.

На вкладке «Настройки» установите для параметра «Положение значка» значение «Сверху» и сохраните настройки.

На вкладке «Значок» выберите пользовательский значок и установите соответствующий размер.

Сохраните пользовательский значок и повторите этот шаг для остальных категорий продуктов.

После добавления значков наше меню выглядит так:

Шаг 5. Стилизация текста

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

Если вы предпочитаете настраивать стиль для своих элементов индивидуально (не затрагивая другие элементы второго уровня в вашем меню), вы можете использовать настраиваемый стиль элементов.

Результат

QBarCategoryAxis Class | Графики Qt 5.15,7

Документация по функциям-членам

QBarCategoryAxis :: QBarCategoryAxis (родительский объект QObject *

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

Этот сигнал выдается при изменении категорий оси.

Примечание: Сигнал уведомления для категорий свойств.

Этот сигнал выдается при изменении количества категорий оси.

Примечание: Сигнал уведомителя для подсчета свойств.

Этот сигнал выдается при изменении значения оси max .

Примечание: Сигнал извещателя для собственности макс.

Этот сигнал выдается при изменении значения оси мин. .

Примечание: Сигнал извещателя для собственности мин.

Этот сигнал выдается при изменении значения оси мин. или макс. .

Уничтожает объект оси.

void QBarCategoryAxis :: append (const QStringList &

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

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

void QBarCategoryAxis :: append (const QString &

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

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

QString QBarCategoryAxis :: at (int

Возвращает категорию , индекс . Индекс должен быть действительным.

QStringList QBarCategoryAxis :: Categories ()

Возвращает категории.

Примечание. Функция получения для категорий свойств.

См. Также setCategories ().

void QBarCategoryAxis :: clear ()

Удаляет все категории. Устанавливает максимальное и минимальное значения диапазона оси в QString :: null.

Примечание: Эта функция может быть вызвана через мета-объектную систему и из QML. См. Q_INVOKABLE.

int QBarCategoryAxis :: count () const

Возвращает количество категорий.

Примечание. Функция получения для подсчета свойств.

void QBarCategoryAxis :: insert (int

Вставляет категорию на ось с индексом . Категория должна быть допустимой строкой QString, и ее нельзя дублировать. Если категория добавляется к другим категориям в начале или в конце, минимальные и максимальные значения на оси обновляются соответственно.

QString QBarCategoryAxis :: max () const

Возвращает максимальную категорию.

Примечание: Функция получения для свойства макс.

См. Также setMax ().

QString QBarCategoryAxis :: min () const

Возвращает минимальную категорию.

Примечание: Функция получения для свойства мин.

См. Также setMin ().

void QBarCategoryAxis :: remove (const QString &

Удаляет категории с оси. Удаление категории, которая в настоящее время устанавливает максимальное или минимальное значение на оси, повлияет на диапазон оси.

void QBarCategoryAxis :: replace (const QString &

Заменяет старых в категории на новых в категории . Если oldCategory не существует на оси, ничего не делается. newCategory должна быть допустимой строкой QString, и ее нельзя дублировать. Если минимальная или максимальная категория заменяется, минимальные и максимальные значения на оси обновляются соответственно.

void QBarCategoryAxis :: setCategories (const QStringList и

Устанавливает категорий и отбрасывает старые.Диапазон оси настраивается для соответствия первой и последней категории в категориях .

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

Примечание: Функция установки для категорий свойств.

См. Также категории ().

void QBarCategoryAxis :: setMax (const QString &

Устанавливает максимальную категорию на max .

Примечание: Функция установки для свойства макс.

См. Также max ().

void QBarCategoryAxis :: setMin (const QString &

Устанавливает минимальную категорию на мин. .

Примечание: Функция установки для свойства мин.

См. Также мин ().

void QBarCategoryAxis :: setRange (const QString &

Устанавливает диапазон оси от minCategory до maxCategory .

Переопределения: QAbstractAxis :: type () const.

Возвращает тип оси.

TRI POINTE HOMES НАИЛУЧИЛИ НАИЛУЧШИЕ ПОЧЕТЫ В ПЯТИ КАТЕГОРИЯХ по номеру

ОСТИН, 16 июля 2021 г. (ГЛОБАЛЬНАЯ ИНФОРМАЦИЯ) — Tri Pointe Homes, Inc. (NYSE: TPH), одна из крупнейших строительных компаний в США, получила пять наград на конкурсе 2021 MAX (Marketing and Advertising Excellence) Awards. Строитель получил высшие награды за лучший индивидуальный план этажа для одной семьи, лучший интерьерный мерчандайзинг отдельно стоящего дома, лучшую дизайнерскую студию, лучший специалист года в области дизайна логотипов и маркетинга. Компания Tri Pointe Homes также была четырехкратным финалистом ежегодного гала-концерта, спонсируемого Ассоциацией строителей жилья (HBA) Совета по продажам и маркетингу Большого Остина.

«Я очень горжусь нашей командой и признанием, полученным на конкурсе MAX Awards», — сказал Три. Президент подразделения Pointe Homes Брайан Гавел. «Эти достижения возможны благодаря страстной культуре, которая пронизывает все аспекты нашего бизнеса, дает возможность нашим сотрудникам любить то, что они делают, и мотивирует их работать на высшем уровне.”

В Rancho Sienna, жилом комплексе площадью 500 акров, расположенном в Джорджтауне, штат Техас, Tri Pointe Homes выиграла премию MAX за лучший индивидуальный дом на одну семью по цене менее 349 999 долларов. Полутораэтажный дом площадью 2410 квадратных футов, названный The Fairfield, включает четыре спальни и 3,5 ванных комнаты с основным люксом на первом этаже. Семейная комната открытой планировки, кухня, обеденная зона и просторный лофт предоставляют достаточно места для отдыха, игр, готовки, еды и многого другого. Этот план был хорошо принят благодаря открытой планировке и просторному внутреннему пространству, поэтому на него приходилась четверть всех планов, выбранных соседними клиентами, которые были распроданы через шесть месяцев после представления.

В Capital Collection Tri Pointe Homes в Брайсоне строитель получил премию MAX за лучший интерьерный мерчандайзинг особняка по цене от 350 000 до 499 000 долларов. Предназначенный для молодых семей, активных взрослых и впервые переезжающих покупателей — и на него приходится треть всех продаж с момента открытия сообщества — дизайн дома Allendale является одним из самых универсальных планов, предлагаемых Tri Pointe Homes в Брайсоне, новое спроектированное мастером сообщество в Леандере, штат Техас. Модель площадью 2199 квадратных футов была продана Five Star Interiors с учетом простора и сбалансированности и включает в себя изготовленную на заказ дверь сарая из черного железа, собачью будку под лестницей, место для встреч на чердаке, уединенный кабинет и многое другое.

Награда MAX за лучшую дизайнерскую студию досталась Tri Pointe Homes площадью 4000 квадратных футов класса A, которая открылась в Остине в сентябре 2019 года. Разработана Interior Logic Group, чтобы сделать дизайн простым, приятным и вдохновляющим для широкого и разнообразного Профиль клиента, дизайн-студия предоставляет клиентам возможность улучшить и персонализировать свои дома с помощью дополнительных дизайнерских функций и элементов. Именно сюда клиенты приходят для сотрудничества с опытными консультантами по дизайну, а также для выбора и окончательной отделки напольных покрытий, столешниц, освещения, сантехники, арматуры, систем шкафов, обработки окон, стилей шкафов и многого другого.

Кроме того, Шелби Уотсон, специалист по цифровому маркетингу в Tri Pointe Homes, была названа специалистом по маркетингу года. Компания также выиграла премию MAX за лучший логотип для строителя, разработанный Ketchum.

Признавая лучших в области жилищного строительства, девелопмента, продаж и маркетинга, в этом году на конкурс было подано около 400 заявок во всех категориях. Церемония награждения 2021 MAX Awards состоялась 26 июня на распроданном мероприятии в центре Остина.

Для получения дополнительной информации посетите www.TriPointeHomes.com.

О Tri Pointe Homes

Tri Pointe Homes® (NYSE: TPH), одна из крупнейших застройщиков США, является публичной компанией и признанным лидером в области обслуживания клиентов, инновационного дизайна и экологически ответственной деловой практики. Компания строит дома и сообщества премиум-класса в 10 штатах, имея тесные связи с обслуживаемыми ею сообществами — некоторым уже целое столетие.Tri Pointe Homes сочетает в себе финансовые ресурсы, технологические платформы и проверенное лидерство национальной организации с региональной проницательностью, давними связями с общественностью и гибкостью уполномоченных местных команд. Tri Pointe выигрывал несколько наград Builder of the Year, последняя из которых — в 2019 году, и вошла в список 100 самых быстрорастущих компаний журнала Fortune за 2017 год. Tri Pointe Homes также стала отличным местом для работы с сертификацией ™ в 2021 году. Основываясь на наследии, которое было создано более 25 лет назад под названием Trendmaker, Tri Pointe Homes является отмеченным наградами лидером в секторе недвижимости в метро Остина. .Для получения дополнительной информации посетите TriPointeHomes.com.

• Коллекция Capital в Bryson_Allandale Model_014_Living 3

 
 Семейства машин | Документация по Compute Engine | Google Cloud 
 В этом документе описаны семейства машин, серии и типы машин.
который вы можете выбрать для создания экземпляра виртуальной машины (ВМ) с
ресурсы, которые вам нужны.Когда вы создаете виртуальную машину, вы выбираете тип машины из
семейство машин, которое определяет ресурсы, доступные этой виртуальной машине. Есть
несколько семейств машин, из которых вы можете выбрать, и каждое семейство машин
организованы в серии машин и предопределенные типы машин в каждой серии. Например, в серии N2 в семействе машин общего назначения вы можете
выберите тип машины  n2-standard-4 .
 Поддержка всех серий машин
вытесняемые виртуальные машины, за исключением
серия станков М2.
  Примечание:  Это список
семейств компьютеров Compute Engine. Для подробного объяснения
каждой семьи, см. следующие страницы:
 общего назначения
 — лучшее соотношение цены и качества для различных рабочих нагрузок.
 Оптимизировано для вычислений
 — высочайшая производительность на ядро ​​в Compute Engine
 и оптимизирован для рабочих нагрузок с интенсивными вычислениями.
 с оптимизацией памяти
 — идеально подходит для рабочих нагрузок с интенсивным использованием памяти, предлагая больше памяти на
 Core, чем другие семейства машин, с объемом памяти до 12 ТБ.
 Оптимизирован для ускорителя
 — идеальный вариант для архитектуры Compute Unified Device с массовым распараллеливанием. (CUDA) вычислительные рабочие нагрузки, такие как
 машинное обучение (ML) и высокопроизводительные вычисления (HPC). Эта семья
 лучший вариант для рабочих нагрузок, требующих графических процессоров.
 Таким образом, в этом документе описаны следующие термины:
  Семейство компьютеров : тщательно подобранный набор конфигураций процессоров и оборудования
оптимизирован для конкретных рабочих нагрузок.При создании экземпляра виртуальной машины вы выбираете
предопределенный или нестандартный тип машины из предпочитаемого вами семейства машин.
  Серия : семейства машин далее классифицируются по сериям и поколениям.
Например, серия N1 среди машин общего назначения является более старой.
версия серии N2. Как правило, поколения машинной серии используют более высокую
номер для описания нового поколения. Например, серия N2 новее
поколение серии N1.
  Тип машины : Каждая серия машин имеет предварительно определенные типы машин, которые
предоставить набор ресурсов для вашей виртуальной машины. Если предопределенный тип машины не
удовлетворить ваши потребности, вы также можете создать
нестандартный тип машины.
 Попробуйте сами 
 Если вы новичок в Google Cloud, создайте учетную запись, чтобы оценить, как
 Compute Engine работает в реальном мире
 сценарии.Новые клиенты также получают 300 долларов в качестве бесплатных кредитов для запуска, тестирования и
 развертывать рабочие нагрузки.
 Попробуйте Compute Engine бесплатно
 Биллинг 
 Вам будет выставлен счет за ресурсы, которые использует экземпляр виртуальной машины. Виртуальные машины оплачиваются как
описано в
Страница цен на инстансы ВМ. Конкретно,
вам выставляется счет за каждый виртуальный ЦП и ГБ памяти отдельно, как описано в
модель биллинга на основе ресурсов.
Применимые скидки, такие как
скидки на длительное использование и
скидки на обязательное использование
применять.
 Чтобы увидеть расчетные почасовые и ежемесячные затраты для каждого типа машины, см.
Цены на инстансы ВМ.
 Категории семейств машин 
 Семейство универсальных машин   предлагает несколько серий машин с лучшим соотношением цены и качества для
разнообразие рабочих нагрузок.
 Оптимизированная по стоимости серия машин E2 включает до 32 виртуальных ЦП и до
128 ГБ памяти, максимум 8 ГБ на виртуальный ЦП. Серия машин E2 имеет
предопределенная платформа ЦП, работающая либо на процессоре Intel, либо на втором
поколение процессоров AMD EPYC Rome. Процессор подбирается под вас, когда
вы создаете виртуальную машину. Эта серия машин предоставляет различные вычислительные ресурсы для
самая низкая цена на Compute Engine, особенно в сочетании с
скидки за обязательное использование.
 Серия машин
 N2 имеет до 128 виртуальных ЦП, 8 ГБ памяти на каждый виртуальный ЦП и
доступно на платформах ЦП Intel Ice Lake и Cascade Lake.
 Машины серии
 N2D имеют до 224 виртуальных ЦП, 8 ГБ памяти на каждый виртуальный ЦП и
доступно на платформах AMD EPYC Rome второго поколения.
 Серия машин
 Tau T2D имеет до 60 виртуальных ЦП, 4 ГБ памяти на каждый виртуальный ЦП и
доступен на процессорах AMD EPYC Milan третьего поколения. Тау T2D
серия машин имеет отключенную потоковую передачу кластера, поэтому vCPU
эквивалентно всему ядру.
 Машины серии
 N1 имеют до 96 виртуальных ЦП, 6,5 ГБ памяти на каждый виртуальный ЦП и
доступно на Intel Sandy Bridge, Ivy Bridge, Haswell, Broadwell и Skylake
Платформы ЦП.
 Серии E2 и N1 — это машины с общим ядром. Типы машин в этих сериях имеют таймшер физический
ядро, которое может быть рентабельным методом для работы небольших, не связанных с ресурсами
интенсивные приложения.
 E2: предлагает 2 виртуальных ЦП на короткие периоды пакетной передачи.
 N1: предлагает типы машин  f1-micro  и  g1-small  с общим ядром
 которые имеют до 1 виртуального ЦП, доступного на короткие периоды пакетной передачи.
 Семейство компьютеров , оптимизированных для вычислений  имеет самую высокую производительность на ядро ​​в Compute Engine и
оптимизирован для рабочих нагрузок с интенсивными вычислениями.Серия машин в этом семействе
работает на масштабируемом процессоре Intel (Cascade Lake) и может поддерживать до 3,8
Всеядерный турбо ГГц.
 ВМ C2 предлагают до 60 виртуальных ЦП, 4 ГБ памяти на каждый виртуальный ЦП и
 доступно на платформе ЦП Intel Cascade Lake.
 Виртуальные машины
 C2D предлагают до 112 виртуальных ЦП, 4 ГБ памяти на каждый виртуальный ЦП и
 доступно на платформе AMD EPYC Milan третьего поколения.
 Семейство машин  с оптимизацией памяти  имеет серии машин, которые идеально подходят для рабочих нагрузок с интенсивным использованием памяти.Эта семья
предлагает больше памяти на ядро, чем любое другое семейство машин, с объемом до 12 ТБ
объем памяти.
 Семейство машин , оптимизированных для ускорителей  идеально подходит для вычислительных рабочих нагрузок с массовым распараллеливанием Compute Unified Device Architecture (CUDA),
такие как машинное обучение (ML) и высокопроизводительные вычисления (HPC).
Это семейство — оптимальный выбор для рабочих нагрузок, требующих графических процессоров.
 Семейство машин и рекомендации по сериям 
 В следующей таблице приведены рекомендации для различных рабочих нагрузок.
 Тип нагрузки
  Рабочие нагрузки общего назначения 
  Оптимизированные рабочие нагрузки 
 Оптимизация затрат
 Сбалансированный
 Оптимизированное масштабирование
 с оптимизацией памяти
 Оптимизированные для вычислений
 Оптимизированный для ускорителя
 E2
 N2, N2D, N1
 Тау Т2Д
 М2, М1
 C2, C2D
 A2
 Ежедневные вычисления по более низкой цене
 Сбалансированное соотношение цены и качества для широкого диапазона форм виртуальных машин
 Лучшая производительность / стоимость для горизонтально масштабируемых рабочих нагрузок
 Рабочие нагрузки сверхвысокой памяти
 Сверхвысокая производительность для рабочих нагрузок с интенсивными вычислениями
 Оптимизирован для высокопроизводительных вычислительных рабочих нагрузок
 Веб-обслуживание
 Обслуживание приложений
 Приложения для бэк-офиса
 Малые и средние базы данных
 Микросервисы
 Виртуальные рабочие столы
 Среда разработки
 Веб-обслуживание
 Обслуживание приложений
 Приложения для бэк-офиса
 Средне-большие базы данных
 Кэш
 Медиа / потоковое видео
 Горизонтальное масштабирование рабочих нагрузок
 Веб-обслуживание
 Контейнерные микросервисы
 Транскодирование медиафайлов
 Крупномасштабные Java-приложения
 Средне-большие базы данных в памяти, такие как SAP HANA
 Базы данных в памяти и аналитика в памяти
 Microsoft SQL Server и аналогичные базы данных
 Рабочие нагрузки, связанные с вычислениями
 Высокопроизводительное веб-обслуживание
 Gaming (игровые серверы AAA)
 Показ объявлений
 Высокопроизводительные вычисления (HPC)
 Транскодирование медиафайлов
 AI / ML
 Обучение ML с поддержкой CUDA и вывод
 HPC
 Массовые параллельные вычисления
 См. Рекомендации VM
чтобы узнать, как правильно выбрать тип машины для вашей рабочей нагрузки.
 После создания виртуальной машины вы можете использовать рекомендации  по настройке прав  для оптимизации
утилизация ресурсов. Для получения дополнительной информации см.
Применение рекомендаций по типу машины для экземпляров ВМ.
 Сравнение серий машин 
 Используйте следующую таблицу для сравнения каждого семейства машин и определения
какой из них подходит для вашей рабочей нагрузки. Если после просмотра этого раздела,
вы все еще не уверены, какая семья лучше всего подходит для вашей рабочей нагрузки, начните с
семейство универсальных машин.См. Платформы ЦП для получения подробной информации о
все поддерживаемые процессоры.
 Чтобы узнать, как ваш выбор влияет на производительность постоянных дисков
подключены к вашим виртуальным машинам, см.
Настройка постоянных дисков и виртуальных машин.
 Серия машин
 виртуальных ЦП
 Память (на каждый виртуальный ЦП)
 Процессоры
 Пользовательские ВМ
 Локальные SSD
 Постоянные скидки
 вытесняемые виртуальные машины
 E2  *  Общего назначения
 2–32
 0. 5–8 ГБ  † 
 Skylake
 Broadwell
 Haswell
 AMD EPYC Рим
 Есть
 №
 №
 Есть
 E2  *  с общим ядром
 0,25–1
 0,5–8 ГБ
 Skylake
 Broadwell
 Haswell
 AMD EPYC Рим
 Есть
 №
 №
 Есть
 N2 Общего назначения
 2–128
 0.5–8 ГБ
 Есть
 Есть
 Есть
 Есть
 N2D  ‡  Общего назначения
 2–224
 0,5–8 ГБ
 AMD EPYC Рим
 AMD EPYC Милан
 Есть
 Есть
 Есть
 Есть
 T2D общего назначения
 1–60
 4 ГБ
 №
 №
 №
 Есть
 N1 Общего назначения
 1–96
 0. 95–6,5 ГБ
 Skylake
 Broadwell
 Haswell
 Песчаный мост
 Ivy Bridge
 Есть
 Есть
 Есть
 Есть
 N1 с общим ядром
 0,2–0,5
 3,0–3,4 ГБ
 Skylake
 Broadwell
 Haswell
 Ivy Bridge
 Песчаный мост
 №
 №
 Есть
 Есть
 C2 Оптимизированные для вычислений
 4–60
 4 ГБ
 №
 Есть
 Есть
 Есть
 C2D с оптимизацией для вычислений
 2–112
 4 ГБ
 №
 Есть
 №
 Есть
 M1 Megamem с оптимизацией памяти
 96
 14. 9 ГБ
 №
 Есть
 Есть
 Есть
 M1 Ultramem с оптимизацией памяти
 40–160
 28,3 ГБ
 №
 №
 Есть
 Есть
 M2 Ultramem с оптимизацией памяти
 208–416
 28,3 ГБ
 №
 №
 Есть
 №
 A2 Оптимизированный для ускорителя high-gpu
 12–96
 7 ГБ
 №
 Есть
 №
 Есть
 A2 Мега-графический процессор, оптимизированный для ускорителей
 96
 14 ГБ
 №
 Есть
 №
 Есть
  *  Для ВМ E2 ваш процессор выбран за вас. 
  †  ВМ E2 поддерживают до 128 ГБ памяти. 
  ‡  Стандартные и высокопроизводительные виртуальные машины N2D имеют до 224 виртуальных ЦП. 
 графических процессора и виртуальных машин 
 Графические процессоры
 используются для ускорения рабочих нагрузок. Вы можете подключать графические процессоры к виртуальным машинам только с помощью
Серия станков N1
или машины серии А2.
Графические процессоры не поддерживаются машинами других серий.
 виртуальных машин с меньшим количеством графических процессоров ограничено максимальным количеством виртуальных ЦП. В
как правило, большее количество графических процессоров позволяет создавать экземпляры с большим количеством
виртуальных ЦП и памяти.Для получения дополнительной информации см.
Графические процессоры на Compute Engine.
 Что дальше 
 .