Замечательный SQL｜Новые идеи для оптимизации дедуплицированных кубических вычислений

[Предварительный просмотр прямой трансляции] Облачная виртуальная машина за 99 юаней × Собственная облачная архитектура за 9 юаней √

введение

SQL в настоящее время является наиболее распространенным языком запросов к базам данных. Его функции и возможности намного сложнее, чем обычно используемый "SELECT * FROM tbl". Производительность хорошего SQL и плохого SQL может быть в десятки или тысячи раз. Чтобы написать SQL, который может учитывать как производительность, так и простоту использования, выходит за рамки простого понимания количества новых функций и новых способов написания, но также требует глубокого понимания процесса обработки данных, а затем разработки хорошего процесса обработки данных. .

Поэтому я хотел бы запустить эту серию статей и назвать ее «Фантастический SQL».Я надеюсь начать с реальных случаев и поделиться с вами некоторыми новыми решениями и идеями обработки SQL-данных, а также смоделировать понимание сути проблемы. в процессе. Надеюсь, вам всем понравится~.

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

1. Описание сцены

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

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

Существует ситуация, когда пользователь использовал Alipay для оплаты один раз в городе Ханчжоу утром, а затем снова использовал Alipay для оплаты в автономном режиме, когда он отправился в город Шаосин днем. Затем при подсчете количества ежедневных платящих пользователей в измерении «Провинция + город» оно должно быть в измерениях городов Ханчжоу и Шаосин. Оно должно быть дедуплицировано пользователем, и это может быть только измерение 1 провинции Чжэцзян. В этом случае обычно необходимо выполнить предварительный расчет данных в виде Куба, при этом каждую комбинацию измерений необходимо дедуплицировать, поскольку она не подлежит накоплению. Сценарий в этой статье представляет собой примерно куб дедупликации.

2. Общие методы реализации

При прямом расчете каждая комбинация размеров рассчитывается отдельно. Например, можно создать отдельно несколько таблиц с такими комбинациями измерений, как провинция, провинция+город, провинция+город+район и т. д. Для каждой таблицы рассчитываются только фиксированные размеры. Затем происходит расширение и пересчет данных, например Union All или Lateral View Explode или функция расчета куба MaxCompute.Посредством расширения данных реализуется метод расчета данных, который удовлетворяет нескольким комбинациям измерений, как показано на рисунке ниже.

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

3. Анализ производительности

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

В реальных экспериментах мы обнаружили, что в процессе расчета кубов дедупликации более 80 % вычислительных затрат уходит на расширение и передачу данных. Например, чтобы извлечь сценарии основных показателей, необходимо рассчитать количество платящих пользователей в различных комбинационных измерениях.В реальном эксперименте большой объем данных в 10 миллиардов данных увеличился почти в 10 раз, размер данных промежуточного результата увеличился со 100 ГБ до 1 ТБ, а объем данных увеличился с 10 миллиардов до почти 130 миллиардов. Большая часть вычислительных ресурсов и времени вычислений тратится на расширение и передачу данных. Если фактическое измерение комбинации еще больше увеличится, размер расширения данных также будет увеличен.

4. Новая идея

Для начала давайте разберем проблему: ядро вычислительного процесса куба дедупликации разделено на две части: расширение данных + дедупликация данных. Расширение данных решает проблему строки данных, удовлетворяющей одновременному вычислению нескольких размерных комбинаций.Блок дедупликации данных завершает окончательную статистику дедупликации.Основное решение по-прежнему связано с необходимостью соответствия исходных данных результирующим данным. Объем вычислений для самой дедупликации данных увеличится, а расширение данных усугубит эту ситуацию, поскольку в процессе перемешивания необходимо дизассемблировать и передать большой объем данных. В процессе расчета данных данные сначала расширяются, а затем агрегируются.Кроме того, увеличивается строковое содержание самих данных на китайском и английском языках, что приводит к большому объему затрат на расчет и передачу данных.

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

4.1.Основная идея

Основная идея расчета показана выше. Обычный метод расчета куба расширения данных требует расширения и повторного агрегирования данных. Число комбинированных измерений, необходимых для получения статистики результатов, кратно расширению данных, так же, как «провинция, провинция + город». " выше. Если объединить два измерения, ожидается, что данные увеличатся в 2 раза.

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

4.2 Логическая реализация

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

номер заказа	ID пользователя	дата платежа	Провинция	Город	К оплате
2023111101	U001	2023-11-11	Провинция Чжэцзян	Ханчжоу город	1.11
2023111102	U001	2023-11-11	Провинция Чжэцзян	Шаосин город	2.22
2023111103	U002	2023-11-11	Провинция Чжэцзян	Ханчжоу город	3.33
2023111104	U003	2023-11-11	Провинция Цзянсу	Нанкин город	4.44
2023111105	U003	2023-11-11	Провинция Чжэцзян	город Вэньчжоу	5,55
2023111106	U004	2023-11-11	Провинция Цзянсу	Нанкин город	6,66

Общий ход программы выглядит следующим образом.

ШАГ 1: Извлеките необходимые элементы из подробных данных (т. е. сгруппируйте по соответствующему полю), чтобы получить набор измерений.

ШАГ 2: Создайте куб из полученного набора измерений и закодируйте строки куба материала (при условии, что требуются два комбинированных измерения провинции, провинции + города ), которые можно реализовать с помощью функции куба ODPS, а затем отсортировать по сгенерированная комбинация измерений куба. Сгенерируйте уникальный код.

Исходное измерение: провинция	Исходное измерение: провинция	Размерность куба: провинция	Размерность куба: город	Идентификатор строки куба (может быть создан путем сортировки)
Провинция Чжэцзян	Ханчжоу город	Провинция Чжэцзян	все	1
Провинция Чжэцзян	Ханчжоу город	Провинция Чжэцзян	Ханчжоу город	2
Провинция Чжэцзян	Шаосин город	Провинция Чжэцзян	все	1
Провинция Чжэцзян	Шаосин город	Провинция Чжэцзян	Шаосин город	3
Провинция Чжэцзян	город Вэньчжоу	Провинция Чжэцзян	все	1
Провинция Чжэцзян	город Вэньчжоу	Провинция Чжэцзян	город Вэньчжоу	4
Провинция Цзянсу	Нанкин город	Провинция Цзянсу	все	5
Провинция Цзянсу	Нанкин город	Провинция Цзянсу	Нанкин город	6

ШАГ 3: Закодируйте строки куба и запишите их обратно в данные пользователя в соответствии с отношениями сопоставления. Это можно реализовать с помощью Mapjoin.

номер заказа	ID пользователя	дата платежа	Провинция	Город	Агрегированный идентификатор куба
2023111101	U001	2023-11-11	Провинция Чжэцзян	Ханчжоу город	[1,2]
2023111102	U001	2023-11-11	Провинция Чжэцзян	Шаосин город	[1,3]
2023111103	U002	2023-11-11	Провинция Чжэцзян	Ханчжоу город	[1,2]
2023111104	U003	2023-11-11	Провинция Цзянсу	Нанкин город	[5,6]
2023111105	U003	2023-11-11	Провинция Чжэцзян	город Вэньчжоу	[1,4]
2023111106	U004	2023-11-11	Провинция Цзянсу	Нанкин город	[5,6]

ШАГ 4. Подведите итоги к пользовательскому измерению, визуализируйте поле набора идентификаторов куба, чтобы удалить дубликаты (вы можете использовать DISTINCT массива).

ШАГ5: Рассчитайте количество в соответствии с идентификатором куба (поскольку ШАГ 4 уже удалил дублирование, нет необходимости удалять дублирование здесь); затем восстановите измерения в соответствии с отношениями отображения.

Идентификатор куба	Индикатор количества пользователей, размещающих заказы	Размерность восстановления куба: провинция	Размер восстановления куба: город
1	3	Провинция Чжэцзян	все
2	2	Провинция Чжэцзян	Ханчжоу город
3	1	Провинция Чжэцзян	Шаосин город
4	1	Провинция Чжэцзян	город Вэньчжоу
5	2	Провинция Цзянсу	все
6	2	Провинция Цзянсу	Провинция Цзянсу

Конец~

4.3.Реализация кода

WITH 
-- 基本的明细数据表准备
base_dwd AS (
  SELECT   pay_no
          ,user_id
          ,gmt_pay
          ,pay_amt
          ,prov_name
          ,prov_code
          ,city_name
          ,city_code
  FROM tmp_user_pay_order_detail
)
-- 生成多维Cube,并进行编码
,dim_cube AS (
  -- Step02:CUbe生成
  SELECT *,DENSE_RANK() OVER(PARTITION BY 1 ORDER BY cube_prov_name,cube_city_name) AS cube_id 
  FROM (
    SELECT dim_key
          ,COALESCE(IF(GROUPING(prov_name) = 0,prov_name,'ALL'),'na') AS cube_prov_name             
          ,COALESCE(IF(GROUPING(city_name) = 0,city_name,'ALL'),'na') AS cube_city_name 
    FROM (
      -- Step01:维度统计
        SELECT  CONCAT(''
                       ,COALESCE(prov_name ,''),'#' 
                       ,COALESCE(city_name     ,''),'#' 
                ) AS dim_key
                ,prov_name
                ,city_name
        FROM base_dwd
        GROUP BY prov_name
        ,city_name
    ) base
    GROUP BY dim_key
            ,prov_name
              ,city_name
    GROUPING SETS (
           (dim_key,prov_name)
          ,(dim_key,prov_name,city_name)
    )
  )
)
-- 将CubeID回写到明细记录上,并生成UID粒度的中间过程数据
,detail_ext AS (
  -- Step04:指标统计
  SELECT   user_id
          ,ARRAY_DISTINCT(SPLIT(WM_CONCAT(';',cube_ids),';')) AS cube_id_arry
  FROM (
    -- Step03:CubeID回写明细
    SELECT  /*+ MAPJOIN(dim_cube) */ 
          user_id
        ,cube_ids
    FROM (
        SELECT   user_id
                ,CONCAT(''
                       ,COALESCE(prov_name,''),'#' 
                      ,COALESCE(city_name,''),'#' 
                 ) AS dim_key
        FROM base_dwd
    ) dwd_detail
    JOIN (
        SELECT dim_key,WM_CONCAT(';',cube_id) AS cube_ids
        FROM dim_cube 
        GROUP BY dim_key
    ) dim_cube
    ON dwd_detail.dim_key = dim_cube.dim_key
  ) base
  GROUP BY user_id
)
-- 指标汇总并将CubeID翻译回可理解的维度
,base_dws AS (
  -- Step05:CubeID翻译
  SELECT cube_id
        ,MAX(prov_name) AS prov_name
        ,MAX(city_name    ) AS city_name
        ,MAX(uid_cnt      ) AS user_cnt
  FROM (
      SELECT cube_id              AS cube_id
            ,COUNT(1)             AS uid_cnt
            ,CAST(NULL AS STRING) AS prov_name
            ,CAST(NULL AS STRING) AS city_name
      FROM detail_ext
      LATERAL VIEW EXPLODE(cube_id_arry) arr AS cube_id
      GROUP BY cube_id
      UNION ALL 
      SELECT CAST(cube_id AS STRING) AS cube_id
            ,CAST(NULL AS BIGINT) AS uid_cnt
            ,cube_prov_name       AS prov_name
            ,cube_city_name       AS city_name    
      FROM dim_cube
  ) base 
  GROUP BY cube_id
)
-- 大功告成,输出结果！！！
SELECT   prov_name
        ,city_name
        ,user_cnt
FROM base_dws
;

Фактический процесс выполнения (просмотр журнала ODPS) показан ниже.

4.4.Экспериментальные результаты

Слева — новый склад на базе решения для маркировки Cube. В процессе эксперимента экспериментальные данные были увеличены с 10 миллиардов до 20 миллиардов, а количество размерностей комбинаций увеличено с исходных 25 до 50. Вся операция заняла 18 минут.Если бы только данные с таким же количеством и размерностями комбинаций, как исходные данные были рассчитаны, общий прогон расчета можно контролировать в течение 10 минут.

Справа — старый склад, рассчитанный на основе данных по инфляции. Экспериментальные данные установлены на уровне 10 миллиардов, количество измерений комбинаций — 25, промежуточные данные расширятся до 130 миллиардов+, размер данных резко увеличится до 1ТБ+, а общая операция займет 47 минут. Если это решение будет расширено до 20 миллиардов данных x 50 комбинационных измерений нового метода, данные промежуточного процесса расширятся до 400 миллиардов+, размер данных увеличится до 3ТБ+, а общий показатель вычислений достигнет 2,5+ часов.

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

4.5. Краткое описание плана

Для распространенных методов расчета куба, основанных на расширенных данных, размер расчета данных и объем передачи обрабатываемых данных будут линейно увеличиваться с количеством объединенных измерений. Чем больше объединенных измерений, тем больше ресурсов и траекторий движения потребляется при расширении данных и передаче в случайном порядке. эксперимент, 10 миллиардов экспериментальных данных x 25 сценариев комбинаций измерений, процесс обработки данных расширился до 130 миллиардов+, а размер данных увеличился со 100 ГБ до 1 ТБ. Когда объем данных и количество комбинаций измерений еще больше увеличиваются, весь процесс расчета в принципе сложно выполнить.

Чтобы решить проблему большого количества данных процесса, генерируемых в процессе расширения данных, мы действуем в обратном порядке, основываясь на идее маркировки данных.Сначала данные агрегируются в степень детализации UID.В процессе требуемая комбинация измерений преобразуется в кодированные числа и присваивается подробным данным.Все данные процесса расчетаВ форме конвергенции и агрегирования процесс расчета данных является стабильным и не будет резко увеличиваться по мере дальнейшего увеличения комбинации измерений. В ходе эксперимента экспериментальные данные были увеличены с 10 миллиардов до 20 миллиардов+, размеры комбинаций были увеличены с исходных 25 до 50, а общая операция контролировалась примерно за 18 минут. Если используется тот же объем данных и используется старая схема расширения данных, данные промежуточного процесса расширятся до 400 миллиардов+, размер данных увеличится до 3ТБ+, а общее время выполнения вычислений достигнет 2,5 часов+.

Подводя итог, можно сказать, что общая производительность текущего решения действительно выше, чем улучшения, достигнутые в прошлом, и не будет значительно увеличиваться с увеличением комбинаций размеров. Однако текущее решение имеет и недостатки, а именно понятность и ремонтопригодность кода.Хотя процесс расчета маркировки не фиксирован, но требует процесса инициализации процесса и понимания в целом.На данный момент невозможно реализовать обычный UnionAll/ Cube и другие решения легко читать и писать. Кроме того, когда количество объединенных измерений очень мало (т. е. кратность расширения данных невелика), разница в производительности между ними невелика. В это время рекомендуется использовать исходное обычное решение для расчета куба. ; но когда количество объединенных измерений достигает десятков раз, вы можете Идея использования этого метода данных для изменения показателей сжимается. Ведь преимущество в производительности в это время начинает становиться заметным, а количество измерений комбинации взвешиваются.Это решение имеет большие преимущества в производительности.

5. Другие варианты

BitMap-решение. Основная идея заключается в использовании неаддитивных показателей данных через кумулятивно рассчитанную структуру данных для приблизительного достижения эффекта кумулятивных показателей. Конкретный план процесса реализации заключается в кодировании идентификатора пользователя и сохранении его в структуре BitMap.Например, двоичный бит указывает, существует ли пользователь и потребляет 1 бит. Когда статистика измерения сводится, структура данных BitMap объединяется и подсчитывается.

Решение HyperLogLog. По сравнению с точной дедупликацией Distinct производительность неточной дедупликации данных значительно улучшена.

Производительность этих двух решений значительно улучшена по сравнению с обычными вычислениями Cube, но решение BitMap требует кодирования и хранения UID, используемого для статистики дедупликации, что для обычных пользователей является более дорогостоящим для понимания и реализации, если оно не интегрировано на уровне системы. Функциональность, реализация которой в противном случае обычно требовала бы дополнительной разработки кода. Основным недостатком решения HyperLogLog является неточная статистика данных.

Автор｜Jiaer

Исходная ссылка

Эта статья является оригинальным контентом Alibaba Cloud и не может быть воспроизведена без разрешения.