Эта проблема:
- Скорость чтения Parquet Drill оказывается в 5-10 раз хуже при чтении из хранилища Azure, что делает его непригодным для больших рабочих нагрузок с данными.
- Кажется, проблема только при чтении паркета. С другой стороны, чтение CSV проходит нормально.
Давайте:
- Учетная запись хранения BLOB-объектов Azure с ~ 1 ГБ source.csv и паркетами с такими же данными.
- Хранилище файлов Azure Премиум с такими же файлами
- Папка на локальном диске, содержащая такие же файлы
- Drill выполняется на виртуальной машине Azure в одиночном режиме
Конфигурация сверла:
- Подключаемый модуль хранилища BLOB-объектов Azure, работающий как пространство имен
blob - Файлы Azure, подключенные с помощью SMB, к / data / dfs, используемому в качестве пространства имен
dfs - Папка на локальном диске, используемая как пространство имен
local
ВМ
- Стандартный E4s v3 (4 виртуальных процессора, 32 ГиБ памяти)
- 256 ГБ SSD
- Сетевая карта 2 Гбит / с
- 6400 IOPS / 96 Мбит / с
Общий доступ к файлам Azure Premium
- 1000GB
- 1000 IOPS base / 3000 IOPS Burst
- Пропускная способность 120 МБ / с
Тесты хранилища
- Измерено с
dd, данными 1 ГБ, различными размерами блоков, conv = fdatasync - Кэш FS сбрасывался перед каждым тестом чтения (
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches")
Локальный диск
+-------+------------+--------+
| Mode | Block size | Speed |
+-------+------------+--------+
| Write | 1024 | 37MB/s |
| Write | 64 | 16MBs |
| Read | 1024 | 70MB/s |
| Read | 64 | 44MB/s |
+-------+------------+--------+
Подключение SMB для файлового хранилища Azure Premium
+-------+------------+---------+
| Mode | Block size | Speed |
+-------+------------+---------+
| Write | 1024 | 100MB/s |
| Write | 64 | 23MBs |
| Read | 1024 | 88MB/s |
| Read | 64 | 40MB/s |
+-------+------------+---------+
Azure Blob
Известная максимальная пропускная способность лазурных BLOB-объектов составляет 60 МБ / с. Скорость загрузки / выгрузки ограничена целевой скоростью чтения / записи в хранилище.
Контрольные показатели сверления
- Кеш файловой системы очищался перед каждым тестом чтения.
- Производительность ввода-вывода наблюдалась с
iotop - Запросы выбраны простые только для демонстрации. Рост времени выполнения более сложных запросов линейный.
Примеры запросов:
-- Query A: Reading parquet
select sum(`Price`) as test from namespace.`Parquet/**/*.parquet`;
-- Query B: Reading CSV
select sum(CAST(`Price` as DOUBLE)) as test from namespace.`sales.csv`;
Полученные результаты
+-------------+--------------------+----------+-----------------+
| Query | Source (namespace) | Duration | Disk read usage |
+-------------+--------------------+----------+-----------------+
| A (Parquet) | dfs(smb) | 14.8s | 2.8 - 3.5 MB/s |
| A (Parquet) | blob | 24.5s | N/A |
| A (Parquet) | local | 1.7s | 40 - 80 MB/s |
| --- | --- | --- | --- |
| B (CSV) | dfs(smb) | 22s | 30 - 60 MB/s |
| B (CSV) | blob | 29s | N/A |
| B (CSV) | local | 18s | 68 MB/s |
+-------------+--------------------+----------+-----------------+
Наблюдения
- При чтении паркета будет создано больше потоков, но только процесс
cisfdберет на себя производительность ввода-вывода. - Попытка настроить производительность считывателя паркета, как описано здесь, но без каких-либо значительных результатов.
- При запросе паркета из лазурного хранилища наблюдается большой пик исходящих данных, который в несколько раз превышает размер данных паркета. Паркет имеет ~ 300 МБ, но выходной пик для одного запроса чтения составляет около 2,5 ГБ.
Заключение
- Чтение паркетов из файлов Azure почему-то замедлено до смешных скоростей.
- Чтение паркетов из Azure Blob даже немного медленнее.
- Чтение паркетов из локальной файловой системы происходит довольно быстро, но не подходит для реального использования.
- Чтение CSV из любого источника обычно использует пропускную способность хранилища, поэтому я предполагаю некоторую проблему / неправильную конфигурацию считывателя паркета.
Вопросы
- Каковы причины такого резкого снижения производительности чтения паркета из службы хранилища Azure?
- Есть ли способ его оптимизировать?
