Apache Drill имеет плохую производительность по сравнению с SQL Server

Я попытался использовать apache-drill для запуска простого запроса на объединение, и скорость была не очень хорошей. мой тестовый запрос был:

SELECT p.Product_Category, SUM(f.sales)
FROM facts f
JOIN Product p on f.pkey = p.pkey
GROUP BY p.Product_Category

Где факты содержат около 422 000 строк, а продукт — 600 строк. группировка возвращается с 4 строками.

Сначала я протестировал этот запрос на SqlServer и получил результат примерно через 150 мс.

С помощью Drill я сначала попытался подключиться напрямую к SqlServer и выполнить запрос, но это было медленно (около 5 секунд).

Затем я попытался сохранить таблицы в файлы json и читать из них, но это было еще медленнее, поэтому я попробовал файлы parquet.

Я получил результат обратно в первом прогоне примерно через 3 секунды. следующий запуск был около 900 мс, а затем он стабилизировался на уровне около 500 мс.

Судя по чтению, это не имеет смысла, и сверлить нужно быстрее! Я попробовал "ОБНОВИТЬ МЕТАДАННЫЕ ТАБЛИЦЫ", но скорость не изменилась.

Я запускал это в Windows через командную строку сверла.

Есть идеи, нужна ли мне дополнительная конфигурация или что-то в этом роде?

Спасибо!


parquet performance apache-drill
person Imbar M.    schedule 19.09.2016    source источник

Ответы (2)


arrow_upward
9
arrow_downward

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

SQL Server — одна из самых быстрых реляционных баз данных. Данные эффективно хранятся, кэшируются в памяти, а запрос выполняется в одном процессе, поэтому сканирование и соединение выполняются очень быстро. У Apache Drill гораздо больше работы по сравнению с ним. Он должен интерпретировать ваш запрос в распределенный план, отправить его всем процессам бурения, которые затем ищут источники данных, получают доступ к данным с помощью соединителей, выполняют запрос, возвращают результаты на первый узел для агрегирования, а затем вы получить конечный результат.

В зависимости от источника данных, Drill, возможно, придется считывать все данные и фильтровать их по отдельности, что увеличивает время. Файлы JSON медленные, потому что они представляют собой подробные текстовые файлы, которые анализируются построчно. Parquet намного быстрее, потому что это двоичный сжатый формат хранения, ориентированный на столбцы, разработанный для эффективного сканирования, особенно когда вы обращаетесь только к определенным столбцам.

Если у вас есть небольшой набор данных, хранящийся на одном компьютере, любая реляционная база данных будет работать быстрее, чем Drill.

Тот факт, что Drill дает вам результаты за 500 мс с Parquet, на самом деле впечатляет, учитывая, сколько еще работы нужно сделать, чтобы дать вам гибкость, которую он предоставляет. Если у вас всего несколько миллионов строк, придерживайтесь SQL-сервера. Если у вас есть миллиарды строк, используйте функцию хранилища столбцов SQL Server для хранения данных в формате столбцов с отличным сжатием и производительностью.

Используйте Apache Drill, когда вы:

  • Иметь десятки миллиардов строк или более
  • Распределите данные по многим машинам
  • Хранить неструктурированные данные, такие как JSON, в файлах без стандартной схемы.
  • Хотите разделить запрос между несколькими машинами для более быстрой параллельной работы
  • Хотите получить доступ к данным из разных баз данных и файловых систем
  • Хотите объединить данные из этих разных источников данных
person Mani Gandham    schedule 31.01.2017

arrow_upward
3
arrow_downward

Одна вещь, которую люди должны понимать о том, как работает Drill, — это то, как Drill преобразует SQL-запрос в исполняемый план для извлечения и обработки данных, теоретически, из любого источника данных. Я намеренно не упомянул источник данных, чтобы люди не думали о базах данных или любой программной системе управления данными.

Drill использует подключаемые модули хранилища для чтения записей из любых данных, поддерживаемых подключаемым модулем хранилища.

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

Таким образом, Drill по умолчанию не использует какие-либо возможности источника для обработки запрошенных данных. На самом деле, источник может не поддерживать такую ​​возможность!

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

Один вопрос, который я регулярно вспоминаю, когда думаю о производительности Drill, это

Select a.CUST_ID, (Select count(*) From SALES.CUSTOMERS where CUST_ID < a.CUST_ID) rowNum from SALES.CUSTOMERS a Order by CUST_ID

Только из-за оператора сравнения > Drill должен загрузить всю таблицу (т. е. фактически файл паркета), СОРТИРОВАТЬ ЕЕ, а затем выполнить объединение.

Этот запрос занял около 18 минут, чтобы выполниться на моей машине, которая не является такой мощной машиной, но, тем не менее, нельзя игнорировать усилия, которые необходимо выполнить Drill для обработки этого запроса.

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

person Muhammad Gelbana    schedule 14.08.2017