Запрос Vertica между датами из PySpark - PullRequest
Новая
       44

Запрос Vertica между датами из PySpark

0 голосов
/ 14 февраля 2019

У меня Spark 1.6 работает на Python 3.4, извлекает данные из моей базы данных Vertica для работы с ним по приведенному ниже запросу, Spark DataFrames поддерживают предикатное нажатие с исходниками JDBC, но термин предикат используется в строгом смысле SQL.Это означает, что он охватывает только предложение WHERE.Более того, похоже, что он ограничен логическим соединением (нет IN и OR, я боюсь) и простыми предикатами, он показывает эту ошибку: java.lang.RuntimeException: Опция 'dbtable' не указана

БД содержитбольшие объемы данных около 100 миллиардов, и я не могу получить данные, а spark1.6 не позволяет мне использовать только запрос dbtable в качестве schema.table, и я получил следующую ошибку: 

java.lang.RuntimeException: Option 'dbtable' not specified

sc = SparkContext(conf=conf)
sqlContext = SQLContext(sc)

url = "*******"
properties = {"user": "*****", "password": "*******", "driver": "com.vertica.jdbc.Driver" }

df = sqlContext.read.format("JDBC").options(
    url = url,
    query = "SELECT date(time_stamp) AS DATE, (subscriber) AS IMSI, (server_hostname) AS WEBSITE, (bytes_in) AS DOWNLINK, (bytes_out) AS UPLINK,(connections_out) AS CONNECTION FROM traffic.stats WHERE DATE(time_stamp) between '2019-01-25' AND '2019-01-29'",
    **properties
).load()

df.show()

Я пробовал приведенный ниже запрос, но безрезультатно. Это занимает много времени без использования функции предела. 

query = "SELECT date(time_stamp) AS DATE, (subscriber) AS IMSI, (server_hostname) AS WEBSITE, (bytes_in) AS DOWNLINK, (bytes_out) AS UPLINK,(connections_out) AS CONNECTION FROM traffic.stats WHERE date(time_stamp) between '2019-01-27' AND '2019-01-29'"
df = sqlContext.read.format("JDBC").options(
    url = url,
    dbtable="( " + query + " ) as temp",
    **properties
).load()

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

Я попытался сократить время, установив больше условий и ограничений, но он отказался от условий $ \, даже если удалить условия, которые он дает мне, «Подзапрос в FROM должен иметь псевдоним», это запрос: 

SELECT min(date(time_stamp)) AS mindate,max(date(time_stamp)) AS maxdate,count (distinct date(time_stamp)) AS noofdays, (subscriber) AS IMSI, (server_hostname) AS WEBSITE, sum(bytes_in) AS DL, sum(bytes_out) AS UL, sum(connections_out) AS conn from traffic.stats where SUBSCRIBER like '41601%' and date(time_stamp) between '2019-01-25' and '2019-01-29'and signature_service_category = 'Web Browsing' and (signature_service_name = 'SSL v3' or signature_service_name = 'HTTP2 over TLS') and server_hostname not like '%.googleapis.%' and server_hostname not like '%.google.%' and server_hostname <> 'doubleclick.net'  and server_hostname <> 'youtube.com'  and server_hostname <> 'googleadservices.com'  and server_hostname <> 'app-measurement.com' and server_hostname <> 'gstatic.com' and server_hostname <> 'googlesyndication.com' and server_hostname <> 'google-analytics.com'  and server_hostname <> 'googleusercontent.com'  and server_hostname <> 'ggpht.com'  and server_hostname <> 'googletagmanager.com' and server_hostname is not null group by subscriber, server_hostname

1 Ответ

0 голосов
/ 15 февраля 2019

Если запрос занимает более часа для фильтрации между диапазонами дат, вам следует подумать о написании прогноза. 

CREATE PROJECTION traffic.status_date_range
(
  time_stamp,
  subscriber,
  server_hostname,
  bytes_in,
  bytes_out,
  connections_out
)
AS
  SELECT
    time_stamp,
    subscriber,
    server_hostname,
    bytes_in,
    bytes_out,
    connections_out
  FROM traffic.stats
  ORDER BY time_stamp
SEGMENTED BY HASH(time_stamp) ALL NODES;

Создание такого прогноза для конкретного запроса, как этот, может добавить значительный объем дискового пространства., но если производительность действительно важна для вас, то, возможно, она того стоит.

Я бы также рекомендовал разбить таблицу на части, если вы еще этого не сделали.В зависимости от того, сколько разных дат у вас есть в таблице traffic.stats, вы можете не захотеть разбивать их по дням.Каждый раздел создает как минимум 1 контейнер ROS (а иногда и больше).Поэтому, если у вас есть 1024 или более различных дат, Vertica даже не позволит вам разбивать по дате, в этом случае вы можете разбить по месяцам.Если вы используете Vertica 9, то вы можете воспользоваться преимуществами иерархического разбиения (вы можете прочитать об этом здесь ).

Я бы предостерег от реорганизации таблицы после выполнения оператора ALTER TABLEдля добавления предложения раздела потребуется значительное количество дискового пространства, поскольку Vertica записывает данные в новые файлы.Как только это будет сделано, таблица займет примерно столько же места, сколько сейчас, но в процессе ее разбиения дисковое пространство может стать довольно большим.

...