привет.
отвечаемс!

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

2. инструмент для визуального представления и/или исследования данных из разных систем их хранения.

3. нет! хотя могут пригодиться

4. базово, построить первые визуализации на понятных данных можно за 1 час. а далее — зависит от задач и плотности работы. есть у табло онлайн-уроки, + есть на русском курсы и марафончики (в том числе и бесплатные)

по обучению:

https://stepik.org/course/56280/promo

и
tableau.pro/marathon42

Alexandra, спасибо большое 😊.

У меня был опыт с  Qlickview, но как пользователя отчетов.

А здесь в чате профи, как я понимаю,  которые на уровне строителей отчётов творят, не просто дашбордов, но и выбора метрик, на основании которых отслеживаются результаты.
Верно? 🙂

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

Привет
Использую JDBC драйвер для RedShift, пытаюсь сделать extract - зависает. На стороне RedShift запрос уже отработал, на стороне Tableau никого сетевого или дискового I/O нет, окошко с экстрактом весит вечно.

Настройки JDBC:
TCPKeepAliveMinutes=5

Если делается экстракт с использованием ODBC драйвера, все работает ОК, но производительность у него много медленнее

ODBC ~ 280Mbps
JDBC ~ 1Gbps

Может у кого есть опыт в  том как затюнить ODBC или может была аналогичная проблема с JDBC

OS: Windows Server 2019
Tableau: 2020.2

🙂 Да, видно, что активная группа. Спасибо за инфо! Большое 🙂

ODBC ~ 280Mbps
JDBC ~ 1Gbps

вроде у Табло нативные драйвера для redshift есть, зачем jdbc использовать?

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

ODBC ~ 280Mbps
JDBC ~ 1Gbps

сколько строк вы загружаете в экстракт?

200 000 000

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

в parquet формате, он весит ~ 600mb, он лежит на s3
пользователи тащат его через spectrum
финальный hyperfile весит в районе 2гб, и как говорят пользователи, с ним отлично работается
момент который в данном случае напрягает их - время экстракта ~ 120мин

причина в том что когда spectrum распаковывает parquet и передает его по odbc / jdbc на Tableau, его размер ~ 140gb

там очень много пустых колонок  типа varchar(16838)

я не dba или не Tableua-Man, но так сложились карты что в моих интересах помочь решить проблему с долгим экстрактом
по этому загуглил чатик и вот решил спросить, может у кого был опыт оптимизации фетча данных из redshift

про оптимизации JDBC не подскажу, но если вы скроете лишние колонки перед созданием экстракта, Табло не будет добавлять их в запрос. Тогда объем будет поменьше.

да я тоже об этом думал, но юзеры боятся что то потерять (хотя я думаю они понятия не имеют о том что там в этих ~ 80 колонок, но хотят они все)

тогда сделайте 2 подключения - с урезанным набором колонок на экстракте и полное онлайн.

я бы посомтрел в сторону сети для начала - какой пинг между декстопом и базой?

ODBC ~ 280Mbps
JDBC ~ 1Gbps

а логи при этом пишутся?