База данных Apache Drill и местоположение данных

У меня два сервера. Первый сервер (A) содержит zookeeper, базу данных mongodb и буровое долото. Второй сервер (B) содержит дистрибутив Hadoop с несколькими таблицами кустов, базой данных postgresql и другой деталью. Оба сверла могут видеть друг друга на домашних страницах сверла, так как они оба подключены к zookeeper на сервере A. Когда выполняется запрос, подобный приведенному ниже (представление dfs.lineorder состоит из данных куста и postgresql на сервере B), сверло Б становится прорабом и все выполняет. Он не делегирует части, связанные с таблицами mongodb, сверлильному станку на сервере A, поэтому 90% времени, необходимого для выполнения запроса (около 30 минут), тратится на отправку коллекции mongodb с сервера A на сервер B. Есть ли способ заставить Drillbit B делегировать часть запроса mongodb Drillbit B, или это может быть проблема с неправильной настройкой? Кроме того, можно ли настроить сверла для доступа к разным базам данных (например, когда каждое сверло имеет доступ к отдельной подсети, чтобы не все сверла могли обращаться к одним и тем же базам данных)?

Пример запроса: ВЫБЕРИТЕ СУММУ(доход) КАК доход ОТ ( ВЫБЕРИТЕ СУММУ(lo_extendedprice*lo_discount) КАК доход ИЗ dfs.tmp.lineorder, dfs.tmp.date ГДЕ lo_orderdate = d_datekey И d_year = 1993 И lo_discount МЕЖДУ 1 И 3 И lo_quantity ‹ 25 UNION ALL SELECT SUM(lo_extendedprice * lo_discount) КАК доход ОТ mongo.test.ssb_europe ssb ГДЕ ssb.orderdate.d_year = 1993 И lo_discount МЕЖДУ 1 И 3 И lo_quantity ‹ 25 );

Конфигурация (drill-override.conf):

На буровой установке A (Windows Server 2008): Drill.exec: { идентификатор кластера: "drillbits1", zk.connect: "serverA:2181", олицетворение: {enabled: true, max_chained_user_hops: 3}}

На буровой установке B (Cloudera CDH 5.8.0): Drill.exec: { идентификатор кластера: "drillbits1", zk.connect: "serverA:2181", олицетворение: {enabled: true, max_chained_user_hops: 3}}


apache-drill cache-locality
person Ivan    schedule 10.06.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Похоже, что проблема может быть в плагине хранилища MongoDB. Если запрос четко разделен на два полных подзапроса (с группировкой), оптимизатор успешно разделяет работу. Следующий запрос правильно распределяет работу между двумя сверлами.

SELECT SUM(lo_revenue), d_year, p_brand1
FROM (
    SELECT SUM(lo_revenue) AS lo_revenue, d_year, p_brand1
    FROM dfs.tmp.lineorder, dfs.tmp.`date`, dfs.tmp.part, dfs.tmp.supplier
    WHERE lo_orderdate = d_datekey
    AND lo_partkey = p_partkey
    AND lo_suppkey = s_suppkey
    AND p_category = 'MFGR#12'
    AND s_region = 'AMERICA'
    GROUP BY d_year, p_brand1
UNION ALL
    SELECT SUM(TO_NUMBER(lo_revenue, '########.##')) AS lo_revenue, ssb.orderdate.d_year AS d_year, ssb.part.p_brand1 AS p_brand1
    FROM mongo.test.ssb_europe ssb
    WHERE IsNumeric(lo_revenue)
    AND ssb.part.p_category = 'MFGR#12'
    AND ssb.supplier.s_region = 'AMERICA'
    GROUP BY ssb.orderdate.d_year, ssb.part.p_brand1
) l
GROUP BY d_year, p_brand1
ORDER BY d_year, p_brand1;
person Ivan    schedule 22.06.2017