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 мс.

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

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

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

От чтения вокруг это не имеет смысла, и сверло должно быть быстрее! Я попробовал "REFRESH TABLE METADATA", но скорость не изменилась.

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

Любая идея, если мне нужна дополнительная настройка или что-то еще?

Спасибо!

ОТВЕТЫ

Ответ 1

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

SQL Server имеет десятилетия кода и оптимизаций, которые делают его одной из самых быстрых реляционных баз данных, работающих на одном сервере. Ваши данные хранятся эффективно, кэшируются в памяти, и запрос выполняется в одном процессе, поэтому сканирование и объединение будут очень быстрыми, особенно с такими небольшими данными.

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

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

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

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

  • Иметь (10 с) миллиарды строк или больше
  • Распространение данных на многие машины
  • Хранить неструктурированные данные, такие как JSON, в файлах без стандартной схемы
  • Хотите распределить запрос по нескольким машинам, чтобы быстрее выполнять параллельно
  • Хотите получить доступ к данным из разных баз данных и файловых систем
  • Хотите объединить данные через эти разные источники данных

Ответ 2

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

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 должен загрузить всю таблицу (т.е. фактически файл паркета), SORT IT, затем выполнить соединение.

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

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