Эта статья взята изГруппа внешнего мониторинга Alibaba Cloud, Пожалуйста, укажите источник
Эта статья представляет собой выступление Пэна Вейчуня, технического эксперта группы внешнего мониторинга Alibaba Cloud, на GMTC (Global Front-end Technology Conference), состоявшейся в Пекине 21 июня 2018 г. Сессия производительности и мониторинга днём было очень хорошо, они сидели на земле три круга, и многие говорили, что вообще не могли втиснуться. Сначала сфотографируйте место происшествия.
Текст начинается здесь~
Добрый день всем, сегодня я представляю вам тему «Лучшие практики мониторинга фронтенда в эпоху большого фронтенда».
Позвольте сначала представиться: меня зовут Пэн Вейчунь, мое английское имя Холден, цветочное имя Али — Лю Манки, все называют меня Братом Обезьяны. Это изоморфная структура Alibaba с открытым исходным кодом.beidouАвтор , в настоящее время является техническим руководителем клиентской системы Alibaba Cloud.
То, чем я делюсь сегодня, разделено на три части
* Первая часть — «Новые изменения в мониторинге внешнего интерфейса в эпоху большого внешнего интерфейса», в которой описываются некоторые новые перспективы и передовые взгляды на мониторинг внешнего интерфейса за последние годы.
* Вторая часть «Передовой опыт внешнего мониторинга» с точки зрения использования знакомит с различными вариантами использования системы внешнего мониторинга.
* Последним является «Архитектура системы внешнего мониторинга Ali Cloud ARMS», в котором кратко анализируется, как реализована система внешнего мониторинга Alibaba Cloud.
Перейдем к нашей первой ссылке, новым изменениям во фронтенд-мониторинге в эпоху большого фронтенда.
Чтобы понять новые изменения во внешнем мониторинге, вы должны сначала посмотреть, какие изменения произошли во внешнем интерфейсе за эти годы.
* Первое — это рождение Gmail, открывшее эру SPA.
* Такие фреймворки, как Backbone/Angular, привносят шаблон MVVM и в то же время превращают JS из языка сценариев в инженерный язык.
* React Native/Weex переводит мобильную разработку из гибридного режима в режим кросс-энд разработки.
* Появление Node.js открывает перед интерфейсом больше возможностей.
Внешний интерфейс претерпел потрясающие изменения за эти годы, что он принесет в мониторинг? Рассмотрим следующие вопросы
* Можно ли адаптировать традиционную модель мониторинга к новой технологии? такие как статистика PV
* Как рассчитать первый экран в SPA-режиме?
* Какие проблемы кросс-энд разработка ставит перед мониторингом?
* Является ли приемлемым режим отчетности внешнего мониторинга на стороне Node.js?
* Далее я обсужу с вами один или два из них
В первые годы SPA был так популярен, и мы также попробовали его в бизнесе.Опыт значительно улучшился, но бизнес-сторона жаловалась, что PV упал.
Так что же вызвало падение PV? В эпоху прямого бэкенда каждый раз, когда мы взаимодействуем, мы запрашиваем новую страницу из бэкенда, и PV, естественно, высок.После перехода в режим SPA большое количество запросов страниц становится внутренней маршрутизацией или внутренним переходом страницы. . Как это решить? Для нас это не сложно, большинство маршрутов фреймворка реализованы на основе хэшей, нам нужно только прослушивать изменения хэшей и сообщать PV один раз после каждого изменения. Также есть небольшое количество маршрутов, которые не реализованы на основе хеширования, например angular, для которого требуется облегченный хак pushState и replaceState
Это идеально?
Рассмотрим следующие случаи
* Для новостного веб-сайта каждый раз, когда вы его читаете, он будет открываться для обновления и загрузки нового контента.Это время считается как PV или несколько раз?
* На странице со списком продуктов Tmall после прочтения экрана прокрутка вверх приведет к загрузке нового экрана Должен ли PV учитываться один или несколько раз?
* Бэкенд Alibaba Cloud Post всегда открыт и проверяется сотни раз в неделю, это считается за один PV или за каждую проверку?
* Если вы снова заходите в браузер через несколько часов с незакрытыми вкладками браузера, следует ли снова считать PV?
* При поиске информации быстро переключайтесь между вкладками браузера.Хотите засчитывать PV один раз в процессе переключения?
На самом деле есть много других сценариев, которые появляются один за другим.Как считать PV, оставляем каждому для размышления и не будем расширяться.
Далее мы исследуем тему, которая больше всего интересует всех: производительность. Давайте сначала посмотрим на набор нашей статистики.Показатель кликабельности страницы Taobao Wangpu постепенно снижался с 85% до 82% по мере увеличения времени загрузки.Не стоит недооценивать эти 3%.При таком большом объеме Али, 3% Это означает огромную коммерческую ценность С точки зрения внешнего мониторинга, как рассчитывается первый экран?
Еще в эпоху подсечно-огневого земледелия я вообще ничего не хотел, я просто делал себе одежду и еду. Это этап ручной маркировки: ручная маркировка, маркировка новой даты() в заголовке и узле первого экрана соответственно, вычисление разницы как первого экранного времени и добавление setTimeout(new Date(), 0) для маркировки первый экран время взаимодействия
При быстром развитии интерфейса ручной режим управления уже давно не может удовлетворить спрос. Чтобы помочь разработчикам лучше измерять и улучшать веб-производительность, группа производительности W3C представила API синхронизации навигации, который поможет нам автоматически и точно решить проблему тестирования производительности. Давайте рассмотрим это примерно. API производительности содержит [Выгрузить предыдущую страницу] ] [Перенаправление] [Кэш приложения] [Разрешение доменного имени DNS] [Соединение TCP] [Страница запроса] [Ответ] [Обработка страницы] Наконец, запускается событие загрузки.Обычно мы используем domContentLoaded в качестве первого времени экрана. Chrome первым поддерживает, IE следует за ним
Мы долгое время наслаждались производительными API, но поскольку модель SPA преобладает, мы вернемся и посмотрим, достаточно ли стандарта W3C. Давайте сначала рассмотрим случай, который представляет собой историю управления продуктом Alibaba Cloud. Весь процесс загрузки разделен на три части: 1. Загрузка исходной пустой страницы оболочки 2. Загрузка ресурсов JS и асинхронный запрос данных 3. Внешний рендеринг основной части в середине. Согласно стандарту W3C, время первого экрана должно составлять 1106 мс, а фактическое время первого экрана — 1976 мс, то есть время, когда страница отображается после завершения асинхронного извлечения данных. Почему такая большая разница? На самом деле распространенность SPA приводит к тому, что стандарт W3C теряет свой первоначальный смысл.
В ответ на эту ситуацию гугл маяк предложил концепцию FMP, сначала означающую раскраску, то есть когда основной контент виден, так что же такое основной контент?Выводы у всех могут быть разные
Сначала сделайте предположение: основной контент = точка с наибольшим приращением элемента в рендеринге страницы.
Сначала проверьте через чехол Fliggy
гипотеза установлена
Затем проведите проверку на примере ручного даосизма.
Гипотеза не верна
Так в чем же причина того, что наша гипотеза неверна?
* Первый - виден элемент или нет, влияние невидимых элементов на пользователя в основном 0
* Во-вторых, эквивалентно ли воздействие каждого элемента на страницу? Это приводит к весу, и разные элементы используют разные веса для расчета влияния.Интерфейсный мониторинг Alibaba Cloud
Согласно приведенному выше поправочному коэффициенту. Мы переработали алгоритм и рассчитали баллы за каждое изменение. Давайте посмотрим, как реализован алгоритм?
Он разделен на три этапа, как показано на рисунке.
1. Следите за изменениями элементов страницы
2. Пройдитесь по каждому новому элементу и подсчитайте сумму баллов этих элементов.
3. Если элемент виден, оценка равна 1 * вес (вес), если элемент не виден, оценка равна 0
Обход вновь добавленных элементов и вычисление того, видны ли они каждый раз, требует очень много производительности. Фактически используется алгоритм поиска в глубину: если виден дочерний элемент, то родительский элемент виден и больше не вычисляется. Аналогичным образом, если виден последний элемент, то и предшествующие элементы того же уровня также видны. Алгоритм поиска в глубину значительно повысил производительность.
Возьмите предыдущий случай Taobao, чтобы проверить это снова.
После улучшений третий экран, как и ожидалось, получил наивысшую оценку за основной контент.
Так что же будет со следующей статистикой экрана? На самом деле, ответственность за подсчет времени в верхней части страницы лежит на браузере, и лучше всего, чтобы браузер справился с этим. В настоящее время статистика W3C на первом экране находится на стадии предложения, и ожидается, что W3C снова стандартизирует ее. Вы можете увидеть последний прогресс на github
Из-за нехватки места другие новые изменения в интерфейсе мониторинга не будут расширены. После разговора о стольких новых изменениях в интерфейсном мониторинге, как лучше всего открыть интерфейсный мониторинг?
Это ведет к нашей второй ссылке «Оптимальные методы внешнего мониторинга».
Я суммирую это с выражением «Что делать, если». Я часто думаю [если бы только деньги можно упасть в небо], [если только был робот, чтобы помочь мне написать код]. Таким же образом, каждый раз, когда версия выпущена, я волнуюсь, и я не знаю, могут ли пользователи использовать его нормально. (Вы будете думать в это время) Было бы здорово, если бы у меня могли бы глаза, чтобы помочь мне следить за системой; каждый раз, когда я ошибаюсь, пользователь жалуется и обратная проблема. На самом деле, когда пользователь активно обратная связь Проблема, воздействие уже очень велико: (в это время вы будете думать), если только я мог бы поймать ошибку в первую очередь;
Реально были такие случаи, в два-одиннадцать утра дежурил два года назад, вдруг приходят оповещения по электронной почте и смс, потом указывают, чтобы открыть детали
Обнаружено, что на диаграмме тенденции успеха интерфейса количество запросов к интерфейсу значительно увеличилось, наряду с резким падением показателя успеха, а затем проверьте модуль агрегации информации об ошибках и обнаружил, что наиболее частая информация об ошибках [ конфликт правил транзакции].После тщательного расследования я, наконец, выяснил, что причина в том, что правила скидок Double Eleven в конфигурации операции противоречили обычным правилам скидок, что привело к сбою размещения заказа. Наконец, в 4:00 была применена аварийная разблокировка, чтобы устранить конфликт и снять тревогу.
Это приводит к одной из лучших практик: упреждающему мониторингу. Конечно, содержание активного мониторинга ограничивается не только процентом успешных попыток API, но и частотой ошибок JS. Подытожим немного процесс: сначала настройте правила оповещения, потом можно спать спокойно, если возникнут какие-то проблемы, система сразу нас уведомит, а затем точно локализует проблему через модуль кластеризации ошибок. В очередной раз ошибка исправлена.
Возвращаясь к нашему [что если], при оптимизации производительности иногда общая производительность уже хорошая, но небольшое количество пользователей считают ее очень медленной: (на этот раз вы подумаете) Если вы можете знать, что случилось с медленным пользователем было бы хорошо
В это время нам нужно использовать [Performance Sample Distribution], открыть страницу производительности страницы и проверить распределение образцов производительности в каждом интервале между 0 и 60 секундами.Из диаграммы распределения видно, что большинство пользователей загружают в 2 секунд в течение 10 секунд, у очень небольшого числа пользователей время страницы составляет около 10 секунд.
Перетащите ползунок ниже, чтобы сузить временной диапазон примерно до 10 секунд, после чего система отфильтрует медленные сеансы продолжительностью около 10 секунд.
Нажмите, чтобы развернуть медленный сеанс, вы можете не только увидеть основную информацию о медленном сеансе, такую как тип сети и т. д., но также увидеть полную каскадную диаграмму загрузки ресурсов, вы можете четко увидеть, какие ресурсы вызывают замедление всего сеанса. вниз . Из этого мы можем извлечь вторую лучшую практику: медленное отслеживание сеансов.
Вернитесь к нашему [что, если], иногда пользователь отправляет отзыв, а определенная функция дает сбой и не может быть использована.В настоящее время вы не знаете, о какой ошибке сообщает пользователь, поэтому вам нужно звоните еще раз Пользователи, также должны научить пользователей делать скриншоты ошибок и отправлять их вам через инструменты разработчика браузера. Отпусти меня.В это время пользователь, вероятно, потому что система слишком прогнила, и это уже невыносимо.Он уже закрыл страницу и поклялся никогда больше не использовать эту сломанную систему. (Вот когда вы думаете) Было бы неплохо знать, какую ошибку сообщил пользователь
Не бойся, откройВнешний мониторинг Aliyun[Сведения о доступе] Найдите идентификатор пользователя, и вы сможете напрямую увидеть, какие ошибки сообщил пользователь в процессе доступа.
Иногда я получаю основную информацию, когда пользователь сообщает об ошибке, и я знаю, что сообщил пользователь, но когда я отлаживаю это на своем компьютере, я все равно не могу воспроизвести это. В это время я должен общаться с пользователем еще раз и пусть пользователь еще раз ее опишет?На самом деле, пользователь мог забыть, что нужно сделать, чтобы воспроизвести ошибку. (Именно тогда мы думаем) Если бы мы только могли воспроизвести поведение пользователя.
[Видео-демонстрация] Мы будем симулировать устранение ошибки пользователя на месте. Левая сторона - это фактический рабочий экран пользователя. Чтобы лучше отобразить эффект, я буду отображать поведение пользователя на правом экране в режиме реального времени.
* Шаг 1: Смоделируйте пользователя для выполнения ряда операций на странице Taobao, таких как движение мыши, прокрутка страницы, поиск и т. д.
* Шаг 2: Предположим, вдруг возникла определенная ошибка, тогда система сохранит записанное поведение пользователя на сервере.
* Шаг 3: Разработчик запрашивает поведение ошибки через идентификатор сеанса и, наконец, восстанавливает его. Вы можете видеть, что левый экран больше не работает, а правый экран восстанавливает все поведение, которое раньше было неправильным.
Всем должно быть интересно, как достигается такая крутая способность? Далее мы раскроем техническую архитектуру внешней системы мониторинга Alibaba Cloud.
Начиная с исправления ошибок, которое всех больше всего интересует, вы можете догадаться, была ли вся страница записана как видео. На самом деле это не так, видео слишком большое, отправить видео на сервер по ошибке невозможно, что является серьезной тратой пользовательских ресурсов. Сначала посмотрите на принципиальную схему (следите за стрелками слева направо)
* Во-первых, каждый сеанс имеет уникальный идентификатор сеанса, который является связующим звеном между всеми действиями.
* Во-вторых, поведение пользователя разделено на две части: одна — действия пользователя, такие как скольжение мышью, щелчки, прокрутка страницы и т. д., а другая — смена страницы. Оба они вместе называются поведением пользователя и записываются в одну и ту же очередь.
* В начале система запишет начальную страницу как первый кадр, который является единственной полной записью страницы.
* Для пользовательских операций мы будем записывать ключевую информацию, такую как тип события, положение мыши и т. д., и сохранять ее в очередь.
* Для изменений страницы мы запустим mutationObserve, чтобы прослушивать изменения страницы, и каждый раз записывать только измененную часть и сохранять ее в очереди.
* Будь то событие или изменение страницы, это эквивалентный кадр, и каждый кадр будет иметь текущее время, а основная информация, такая как интервал времени из предыдущего кадра, будет восстановлена пользователем.
* При возникновении ошибки SDK отправляет очередь в систему мониторинга и очищает текущую очередь.
* В соответствии с записанной очередью поведения, конец восстановления воспроизводит их один за другим в зависимости от времени. Конечным результатом является эффект, похожий на видео.
Вам может показаться, что этого недостаточно, далее я расскажу вам об общей архитектуре системы внешнего мониторинга Alibaba Cloud ARMS.
Во-первых, он разделен на три домена слева направо. Это домен сбора журналов, домен анализа журналов и домен аварийных сигналов мониторинга. В домене сбора журналов клиент передает информацию на сервер Nginx через SDK, а служба журналов SLS запускает агент на сервере Nginx для синхронизации информации журнала.Когда журнал поступает в SLS, это эквивалентно большому резервуар. Затем, посредством расчета вычислительного движка в реальном времени, часть результатов сохраняется в HBase, а другая часть результатов сохраняется в сервисе журналов SLS для поиска.
Наконец, данные передаются на внешний интерфейс через Restful API, а внешний интерфейс отображает панель данных.
Ощущается ли это очень просто?Есть поговорка "Глядя на горы и бегая мертвыми лошадьми", кажется, что горы перед тобой, но даже если ты оседлаешь лошадь, ты устанешь. Итак, давайте вместе разгадаем его тайну.
Далее мы сосредоточимся на области сбора журналов, которая тесно связана с работой студентов переднего плана.По сравнению с отраслью, наша коллекция журналов по-прежнему имеет много замечательных моментов. Например:
* Тихий сбор: для доступа к SDK требуется только одна строка кода, а все запросы API, загрузка ресурсов, ошибки JS, производительность и т. д. автоматически отслеживаются. Устраняет громоздкую конфигурацию.
* Модульное тестирование + автоматизированное тестирование: Целью фронтенд-мониторинга является отслеживание нештатных ситуаций во фронтенде, а не привнесение новых исключений на страницу.Это наш итог.Для этого у нас есть полное модульное тестирование и автоматизированное тестирование для обеспечения целостности самого SDK.
* (изоляция ошибок SDK): Но на самом деле ни одна система не может гарантировать, что она не допустит ошибок.Если SDK сам сообщает об ошибке, у нас также есть механизм изоляции исключений, чтобы гарантировать, что ошибка не повлияет на работу бизнеса. .
Я не буду вдаваться в подробности об этом содержании, поэтому я сосредоточусь на том, как внешний интерфейс Alibaba Cloud преодолевает ограничения и элегантно создает журналы отчетов.
Как мы все знаем, черновик консультации по http rfc2616 предусматривает, что браузер может иметь только 2 соединения для доменного имени одновременно. Однако отчеты будут срабатывать PV, UV, ajax-запросы, логические ошибки JS, загрузка ресурсов страницы и т. д. В то же время двух подключений явно недостаточно, что может привести к перегрузке сети и задержке отчетов.
Позже в исправленном черновике rfc7230 это ограничение убрали, указывалось только количество ограничений, но конкретное количество не указывалось, и браузер фактически ослабил ограничение. Например, Chrome — это 6 подключений одновременно.
Однако запрос занимает соединение, а иногда и 6 соединений недостаточно.
Вы можете подумать, раз в спецификации не указано, сколько нужно ограничить, то почему браузер должен ограничивать 6? На самом деле, это также из соображений справедливости и безопасности.Если количество не ограничено, в теории клиент может занять большое количество ресурсов сервера и даже перегрузить сервер.
Как пробить лимит? Есть хитрость: обновитесь до http2 и используйте функцию мультиплексирования h2
В одном соединении можно открыть несколько потоков, а данные можно передавать в обоих направлениях, легко преодолевая ограничение в 6 параллельных потоков.
* Подумайте об этом: эффективно ли хэшировать ресурсы под разными доменными именами в эпоху http1? На самом деле, вместо повышения производительности это увеличивает нагрузку на соединение.
Достаточно ли этого, чтобы преодолеть ограничение в 6 участников? Давайте посмотрим на другую часть, которую легко упустить из виду: потеря заголовка http.
* В HTTP-запросе каждый запрос будет содержать серию заголовков запроса для описания запрошенных ресурсов и функций. Заголовок не сжимается, и каждый запрос занимает 200-800 байт, а если принести относительно большой куки, то он даже превысит 1К.
* Наш фактический размер данных журнала составляет всего 10-50 байт, а потребление заголовка составляет более 90%
*Кроме того, по статистике Htpp Archive, в среднем сотни запросов на страницу, а в шапке расходуется все больше трафика
* Самое фатальное то, что такая информация, как UserAgent, меняется не часто, а передавать каждый запрос — серьезная трата.
Опять же, используя сжатие заголовка h2. Давайте посмотрим на сравнение эффекта от использования h1 и h2.
Размер запроса под h1 составляет 295 байт, а под h2 всего 18 байт, размер всего 1/16, а время запроса также уменьшено с 6 мс до 4 мс.
Это удивительно, так что давайте быстро посмотрим, как реализовано сжатие заголовков http2:
* Во-первых, в протоколе предустановлен статический словарь для представления общих полей заголовков, например, на рисунке 2 — это метод get. Раньше нужно было отправлять полную пару ключ-значение, а теперь нужно только отправить номер.значительно уменьшен в размере.
* Во-вторых, клиент и сервер будут совместно поддерживать динамическую таблицу Для чего используется динамическая таблица? Например, такое как useragent, значение useragent для каждого пользователя отличается и не может быть помещено в статическую таблицу для согласования. Однако для одного и того же пользовательского сеанса юзерагент не изменится.Такое значение будет сохранено в динамической таблице путем согласования между клиентом и сервером.После первой передачи необходимо передать только одну из динамических таблиц в последующие Подойдет кодировка.Это в случае с 62 и 63 на картинке. Чем больше запросов отправлено в соединении, тем больше значений в динамической таблице можно обогатить, и чем дальше назад, тем лучше производительность запроса (доказывает, что метод хеширования доменного имени нежелателен)
* Существует также случай, когда значение всегда изменяется и не может быть сохранено в динамической таблице. В настоящее время его можно сжать только напрямую. В h2 используется алгоритм сжатия Хаффмана, который может сжимать числа или символы до 5 байтов в самом коротком, а максимальная степень сжатия составляет 37,5%.
На самом деле, кроме компрессии головы, есть много способов уменьшить громкость, например,
* Используйте http 204, чтобы вернуть ответ без тела ответа
* Используйте почтовый запрос для объединения нескольких журналов и совместного использования заголовков запросов.
* Многие URL-адреса файлов часто появляются в стеке вызовов ошибок, занимая много места, вы можете рассмотреть возможность их извлечения в переменную
Отношение времени, часть сбора журнала заканчивается здесь.
Далее давайте рассмотрим основную часть системы мониторинга: вычисления в реальном времени.
Вычисления в реальном времени используют потоковые вычисления, которые уже хорошо зарекомендовали себя в отрасли.Давайте кратко рассмотрим эту концепцию.
Это классическая структурная схема, представляющая потоковые вычисления. Она состоит из двух компонентов: кран — носик, представляющий источник данных, и молния, представляющая логику обработки. Здесь есть две важные особенности.
* Во-первых, это гибкость вычислительной мощности.Если поступает большее количество журналов, можно динамически распределять больше вычислительной мощности, чтобы обеспечить производительность вычислений в реальном времени.
* Во-вторых, противодавление. Каждый вычислительный узел может противодействовать вычислительному узлу верхнего уровня в соответствии со своей ситуацией загрузки, чтобы добиться более разумного распределения вычислительных задач.
Подумайте об этом: как получить агрегированные данные с ограниченными условиями в режиме реального времени из массивных журналов? Как показано на рисунке, я хочу получить тренд [симулируемая страница] в [провинция Гуандун] [последние 24 часа] [скорость доступа] в режиме реального времени.
Проанализируйте, если вам нужно нарисовать такую диаграмму тренда, рисуйте одну точку каждый час, вам нужно взять значение 24 точек, написать SQL для каждого узла, чтобы усреднить подходящие данные,
Если объем данных невелик, выборка данных 24 раза едва ли допустима с точки зрения производительности.
Однако, как система SASS, система мониторинга будет подключена ко многим проектам, и постоянно будет передаваться большой объем данных. Система также накапливает огромные объемы данных. Сколько времени нужно, чтобы получить узел? Для справки, для офлайн-вычислений требуется около 15 минут, 24 узла, и предполагается, что это займет 6 часов. Это явно неприемлемо. ТотИнтерфейсный мониторинг Alibaba CloudКак получить данные в режиме реального времени?
Для этого необходимо использовать наш артефакт обработки больших данных dataCube (куб данных).Давайте проанализируем, как куб данных решает задачу в реальном времени.
Как показано на рисунке: возьмите в качестве примера три измерения браузера, устройства и географической области, чтобы сформировать трехмерный куб данных. Каждая ячейка в кубе представляет агрегированные данные.
Пожалуйста, посмотрите на сетку, где цифра 3 на картинке, 3 представляет трехмерность, то есть совокупное количество устройств Vivo и браузеров Chrome в Пекине.
Посмотрите на цифру 2 на желтой грани.Желтая грань представляет агрегацию измерения браузера, то есть агрегацию устройств Vivo в Шанхае, включая все браузеры.
Посмотрите на цифру 0 в правом нижнем углу, которая представляет собой измерение 0, то есть все агрегаты, включая все браузеры, все устройства и все регионы.
Секрет куба данных заключается в предварительном расчете значений всех сеток.В следующий раз, когда вы захотите взять значение, просто возьмите определенное значение куба данных.По сути, это способ изменения пространства во времени .
Глядя на наш реальный сценарий обработки, после вычисления метаданных потоком куб данных будет генерироваться каждую минуту, час и день. И этот куб данных имеет целых 90 измерений. Возвращаясь к предыдущему случаю, если я хочу ограничить ряд условий, чтобы получить 24-часовой график тренда, мне нужно только вынуть маленькую сетку в указанной позиции в 24 кубах данных. Время вычислений может быть значительно сокращено до второго уровня.
[Пример для размышления] Куб данных по существу вычисляет результаты всех возможных комбинаций заранее, а количество результатов представляет собой декартово произведение.Если значение определенного измерения очень велико (например, идентификатор продукта в URL-адресе сведений о продукте Taobao постоянно меняется, в результате чего значение url) Их десятки миллионов), что напрямую приводит к взрыву измерений. Как это решить?
Из-за нехватки времени, на сегодняшней теме все. Заинтересованные студенты могут присоединиться к нашей группе технического обмена, спасибо.
Эта статья взята изГруппа внешнего мониторинга Alibaba Cloud, Пожалуйста, укажите источник