#performance #tableau-api #business-intelligence #query-performance #sqlperformance
#Производительность #tableau-api #бизнес-аналитика #запрос-производительность #Производительность sql
Вопрос:
Я использую Tableau и имею таблицу с 140 полями. Из-за размера / ширины таблицы производительность низкая. Я хотел бы удалить поля, чтобы увеличить скорость чтения, но моя пользовательская база настолько велика, что по крайней мере один человек использует каждое из полей, в то время как 90% используют одни и те же ~ 20 полей.
Каково наилучшее решение этой проблемы? (Tableau — наш инструмент BI, BigQuery — наша база данных)
Что я сделал до сих пор: в Tableau неясно, как использовать динамические источники данных, которые изменяются в зависимости от выбранного поля. В идеале я хотел бы иметь меньшие представления ИЛИ денормализованные таблицы. По мере того, как пользователи делают свой выбор в Tableau, базовые источники данных обновляются до таблицы или представления с этим полем.
Я попробовал простую версию большого представления, но она работала хуже, чем моя большая таблица, и считывала значительно больше данных (помните, я BigQuery, поэтому я очень забочусь о прочитанных байтах из-за затрат)
Комментарии:
1. Вы уверены, что проблема в ширине таблицы? Я читал документ bigquery в течение 10 секунд, и в нем не упоминалась ширина. Вы проверили, чтобы подтвердить, что более узкие таблицы работают быстрее? Разве Tableau не выбирает только те поля, которые ему нужны?
2. Спасибо @Nick. Макдермейд. Вы совершенно правы, что ширина не обязательно является проблемой. Однако большая ширина приводит к более высокой мощности в моем случае. Вот почему я хочу максимально сократить. А также true — Tableau показывает только выбранное поле. Однако, как и выше, это поле может быть в 1,5 раза длиннее из-за дополнительных полей, которые увеличивают мощность. Ценю мысль! Продолжайте в том же духе.
3. Это не только то, что Tableau показывает только поля, используемые в viz — он запрашивает только источник данных об этих полях. Источник данных Tableau можно представить как определяющий семейство возможных SQL-запросов, и этот Tableau генерирует оптимизированный SQL-запрос на основе полей, которые вы фактически использовали в этом представлении. Таким образом, наличие большого количества столбцов не обязательно является дорогостоящим.
4. Два совета 1. Если ваша база данных обеспечивает ссылочную целостность (например, отсутствие внешних ключей к несуществующим строкам), то Tableau может генерировать более эффективный SQL, если вы выберете опцию «Предположить ссылочную целостность» в меню «Данные». Особенно полезно для схем звезд и снежинок. 2. Используйте запись производительности Tableau (в меню справки) или средство просмотра журналов Tableau (приложение с открытым исходным кодом), чтобы просмотреть фактический сгенерированный SQL. Чтобы оценить производительность, вставьте ее в клиент SQL и поэкспериментируйте, посмотрите на план запроса, проверьте статистику и т. Д. — Сначала убедитесь, что сгенерированный SQL действительно является проблемой.
5. Опять же, я не эксперт по bigquery, но большая ширина приводит к более высокой мощности в моем случае , для меня не имеет смысла. Мощность — это не столбцы, а строки. Если вы не говорите, что модель данных имеет какой-то недостаток в дизайне кросс-продукта?
Ответ №1:
Предложение 1. Извлеките ваши данные.
Особенно, когда речь идет об источниках данных, которые платят за байт запроса (Big Query, Athena и т. Д.), Извлечения имеют большой смысл. В зависимости от того, насколько «свежими» должны быть данные для пользователей. (Конечно, все пользователи скажут, что «жить — это единственный путь», но немного углубитесь в это и посмотрите, что это может быть на самом деле.) Обновления могут быть запланированы всего на 15 минут. Реальная сила обновлений проявляется в форме «инкрементных обновлений», при которых добавляются только новые записи (по индексу int или date). Это отличный способ снизить затраты, если ваша база данных BigQuery разделена на разделы (что и должно быть). Поскольку экстракты Tableau содержатся внутри.гипер-файлы, структура собственного дизайна / управления Tableau, чрезвычайно быстры и идеально оптимизированы для использования в Tableau.
Предложение 2. Создайте 3 источника данных (или больше).) Сертифицируйте эти источники данных после проверки того, что они предоставляют правильную информацию. Предоставьте пользователям четкие описания.
- Исходный большой набор данных.
- Подмножество из ~ 20 полей для 90%.
- Остаток полей для 10%
- Выдержка из 1
- Выдержка из 2
- Выдержка из 3
Важно отметить, что если имена полей совпадают в каждом источнике данных (т. Е. Никогда не изменяются вручную), то пользователю должно быть легко «масштабироваться» до больших наборов данных по мере необходимости. Это означает, что они, как правило, всегда могут начинать с небольшого подмножества данных для начала их исследования, а затем использовать функцию «заменить источник данных» для переключения на другой источник данных, сохраняя при этом свои прежние представления. (Однако это не сработало бы так же хорошо, если бы вообще работало для уменьшения масштаба.)
Комментарии:
1. Спасибо за мысли. Предложение 1 определенно было бы идеальным. Однако проблема заключается в том, что создание извлечений из больших таблиц мощности в BigQuery оказалось неудачным. Для извлечения 1,5 миллионов записей требуется более 30 минут. В моей маленькой таблице 350 миллионов записей. Я склонялся к предложению 2, но надеялся избежать обслуживания нескольких таблиц. Однако я начинаю думать, что это может быть лучшим подходом.
2. Сколько времени требуется для завершения ВЫБОРА * из тех же 1,5 миллионов строк данных, что и сам BigQuery?
3. Я пытаюсь пометить вас, но у меня чертовски много времени на это. Может быть, максимум 2 минуты? У меня было много проблем с извлечением данных из BigQuery. Я обнаружил лучшую производительность в базах данных, таких как Postgres (что безумно, учитывая, насколько хорош BigQuery в целом).
4. Да, тогда удивительно, что вы увидите 30-минутное время извлечения. Как насчет сетевой архитектуры между Tableau и BigQuery? (Прокси, балансировщик нагрузки, брандмауэр и т. Д.?) Ваша сетевая команда может найти / объяснить разницу в скоростях.
5. Спасибо, это хорошая идея. Я продолжу исследование и посмотрю, можно ли сделать что-то лучше. Спасибо за помощь!