{"id":7534,"date":"2018-10-22T07:30:20","date_gmt":"2018-10-22T10:30:20","guid":{"rendered":"http:\/\/www.fernandoquadro.com.br\/html\/?p=7534"},"modified":"2018-10-19T10:31:32","modified_gmt":"2018-10-19T13:31:32","slug":"analise-de-performance-de-big-data-entre-postgis-e-arcgis","status":"publish","type":"post","link":"https:\/\/www.fernandoquadro.com.br\/html\/2018\/10\/22\/analise-de-performance-de-big-data-entre-postgis-e-arcgis\/","title":{"rendered":"An\u00e1lise de performance de Big Data com PostGIS e ArcGIS"},"content":{"rendered":"

Esta semana estava lendo o feed do meu twitter quando me deparei com o titulo “Big Data Results<\/a>“, e resolvi entrar para espiar do que se tratava! Era um post que fazia uma an\u00e1lise com dados de Nova Iorque (t\u00e1xis) comparando a performance entre o ArcGIS e o PostGIS. Eu achei muito interessante, e resolvi traduzir, adaptar e transcrevo abaixo.<\/p>\n

O exemplo utilizado tem um arquivo de 6GB com 16 milh\u00f5es de pontos de t\u00e1xi e 263 zonas. O objetivo era determinar o n\u00famero de t\u00e1xis em cada zona, juntamente com a soma de todas as tarifas. Abaixo segue a an\u00e1lise aprofundada do que foi realizado:<\/p>\n

1. Os dados e o computador<\/strong><\/p>\n

Os dados foram obtidos da Comiss\u00e3o de T\u00e1xis e Limousines de Nova York<\/a> para outubro de 2012. Os aproximadamente 16 milh\u00f5es de pontos de t\u00e1xi e 263 pol\u00edgonos de zona de t\u00e1xi exigiram cerca de 6 GB de armazenamento. Voc\u00ea pode ver abaixo que \u00e9 realmente um grande volume de dados:<\/p>\n

\"\"<\/center><\/p>\n

O computador utilizado tem um processador i7 (4 n\u00facleos), Windows 10, unidade SSD, 12 GB de RAM e um processador de 3.0 GHz.<\/p>\n

2. O Problema<\/strong><\/p>\n

A pergunta tinha que ser respondida era: Quantos t\u00e1xis estavam para cada zona e qual era o valor total da corrida? Ent\u00e3o, para tentar responder a essa pergunta foi utilizado o ArcGIS, e Postgres\/PostGIS. Vamos ent\u00e3o as an\u00e1lises:<\/p>\n

3. ArcGIS 10.4<\/strong><\/p>\n

Como deve ser de conhecimento da maioria de voc\u00eas, o ArcGIS 10.4 \u00e9 um aplicativo de 32 bits. Ent\u00e3o, para tentar resolver esse problema foi executada uma jun\u00e7\u00e3o de tabela (AddJoin_Management) entre os pontos de t\u00e1xi e as zonas de t\u00e1xi. Para dar ao ArcGIS uma chance de lutar, foram movidos os dados para um geodatabase (assim, as camadas teriam \u00edndices espaciais). Depois de executar a jun\u00e7\u00e3o por algumas horas, o ArcGIS 10.4 relatou um erro de falta de mem\u00f3ria<\/strong>.<\/p>\n

4. ArcGIS Pro<\/strong><\/p>\n

Em seguida, o teste foi realizado com o ArcGIS Pro, que \u00e9 um verdadeiro aplicativo de 64 bits. Al\u00e9m disso, o ArcGIS Pro possui v\u00e1rias ferramentas para fazer exatamente o que era necess\u00e1rio. Um deles foi o Summarize Within<\/a>. A ESRI torna realmente f\u00e1cil fazer esse tipo de pergunta no ArcGIS Pro. Ent\u00e3o a fun\u00e7\u00e3o foi executada, e foi obtida uma tabela resultante em 1h 27m<\/strong>. Neste ponto do experimento, foi bastante satisfeito – pelo menos, houve uma resposta, e \u00e9 algo que se pode fazer durante um intervalo para o almo\u00e7o, por exemplo.<\/p>\n

5. ArcGIS Server com GeoAnalytics Server<\/strong><\/p>\n

A ESRI estava divulgando seu novo GeoAnalytics Server<\/a> (o pre\u00e7o \u00e9 de US$ 40.000 para uma implementa\u00e7\u00e3o de 4 n\u00facleos), e foi realizado o teste com ele tamb\u00e9m. Para surpresa, ele executou a consulta em cerca de 2m<\/strong>, o que \u00e9 realmente espantoso. Este produto \u00e9 projetado para grandes volumes de dados com certeza. <\/p>\n

6. Postgres\/PostGIS<\/strong><\/p>\n

Para ver como isso funcionaria no Postgres com o PostGIS a primeira coisa a ser feita foi criar uma instru\u00e7\u00e3o SQL:<\/p>\n

\r\nSELECT count(*) AS totrides,taxizones.zone, sum(taxisandy.fare_amount)\r\nFROM taxizones, taxisandy\r\nWHERE ST_Contains(taxizones.\"Geom\",taxisandy.pu_geom)\r\nGROUP BY zone\r\n<\/pre>\n
Esta consulta foi executada em 10m 27s<\/strong>. Foi um resultado satisfat\u00f3rio, afinal, essa consulta \u00e9 super simples de escrever. Mas ainda n\u00e3o \u00e9 o fim pois existem algumas maneiras de otimizar essa consulta.<\/p>\n
7. Postgres\/PostGIS Otimizado<\/strong><\/p>\n
O \u00edndice espacial j\u00e1 havia sido criado, mas havia mais duas coisas que era necess\u00e1rio fazer: esvaziar a tabela e agrupar os dados. Ent\u00e3o, o que essas consultas fazem:<\/p>\n
VACUUM <\/strong>recupera o armazenamento ocupado por tuplas mortas. Na opera\u00e7\u00e3o normal do PostgreSQL, as tuplas exclu\u00eddas ou obsoletas por uma atualiza\u00e7\u00e3o n\u00e3o s\u00e3o fisicamente removidas de suas tabelas; eles permanecem presentes at\u00e9 que um VACUUM seja realizado.<\/p>\n
O CLUSTER<\/strong> reordena fisicamente os dados no disco para que os dados que devem estar pr\u00f3ximos um do outro no banco de dados estejam realmente pr\u00f3ximos uns dos outros no disco. Em outras palavras, os pontos no Brooklyn agora est\u00e3o fisicamente armazenados no disco perto de outros pontos no Brooklyn.<\/p>\n
Ent\u00e3o, como fazer isso? Primeiro, limpe e agrupe os dados:<\/p>\n
\r\nVACUUM ANALYZE taxizones (\"Geom\"); \r\nVACUUM ANALYZE taxisandy (pu_geom);\r\nCLUSTER taxisandy USING pugeom_idx; \r\nCLUSTER taxizones USING \"Geom_x\";\r\n<\/pre>\n
Agora, executar o cluster nos pontos de t\u00e1xi de fato levou 18 minutos. Essa \u00e9 uma “despesa \u00fanica” que pagamos. Depois disso, podemos executar qualquer consulta que quisermos, repetidamente. A consulta \u00e9 um pouco mais complicada do que a anterior porque escreve os resultados em uma nova tabela:<\/p>\n
\r\nSELECT taxizones.\"Geom\", sumfare, a.zone\r\nINTO sumtable\r\nFROM taxizones, \r\n(SELECT taxizones.zone, sum(taxisandy.fare_amount) AS sumfare\r\nFROM taxizones\r\nJOIN taxisandy\r\nON ST_Contains(\"Geom\", pu_geom)\r\nGROUP BY zone) AS a\r\nWHERE taxizones.zone = a.zone\r\n<\/pre>\n
A consulta foi conclu\u00edda em 1m 40s<\/strong>. Claro, com PostGIS voc\u00ea tem que levar em considera\u00e7\u00e3o o custo: $0. <\/p>\n
Por\u00e9m, ainda \u00e9 poss\u00edvel otimizar mais essa consulta, pois algumas das zonas de t\u00e1xi s\u00e3o um pouco grandes, ent\u00e3o, a consulta de restri\u00e7\u00e3o pode demorar um pouco mais ao comparar as caixas delimitadoras (BBOX) no \u00edndice espacial. Para contornar isso, \u00e9 poss\u00edvel utilizar a fun\u00e7\u00e3o ST_SubDivide<\/a> para dividir as zonas de t\u00e1xi maiores em pol\u00edgonos menores:<\/p>\n
\"\"<\/center><\/p>\n
Isso significava que os pol\u00edgonos da minha zona de taxiamento passaram de 263 para 4.666. Agora, pensando racionalmente, quem faria<\/a> uma sobreposi\u00e7\u00e3o com 4.666 pol\u00edgonos ao inv\u00e9s de 263, que \u00e9 menor? Bem, foi o que foi feito aqui, e de 1m40s o resultado passou para 1m3s<\/strong>.<\/p>\n
Mas como foram divididos os pol\u00edgonos? Veja baixo:<\/p>\n
\r\nSELECT ST_Subdivide(\"Geom\", 50) AS geom, zone into taxisub FROM taxizones;\r\nCLUSTER taxisub USING geom_idx;\r\n<\/pre>\n
E sim, o CLUSTER mais uma vez fez uma grande diferen\u00e7a. O SQL desta vez, nos permite fazer algumas coisas inteligentes. Lembre-se, agora temos 4.666 pol\u00edgonos porque os 263 pol\u00edgonos foram subdivididos.<\/p>\n
Na consulta abaixo, a parte interna (sub consulta) \u00e9 o SQL para determinar o total de viagens e a soma das tarifas em cada pol\u00edgono dos 4.666. Assim, a parte externa da consulta est\u00e1 unindo as zonas de t\u00e1xis originais (aquele com apenas 263 pol\u00edgonos) e escrevendo para uma tabela com o resultado final.<\/p>\n
\r\nSELECT taxizones.\"Geom\" AS geom, count(id) AS numrides, sumfare, a.zone\r\nINTO sumtable\r\nFROM taxizones, \r\n   (SELECT taxisub.zone, sum(taxisandy.fare_amount) AS sumfare\r\n    FROM taxisub\r\n    JOIN taxisandy\r\n    ON ST_Contains(geom, pu_geom)\r\n    GROUP BY zone) AS a\r\nWHERE taxizones.zone = a.zone\r\n<\/pre>\n
8. Resultados: <\/strong><\/p>\n
Abaixo, a lista detalhada dos resultados obtidos nos experimentos descritos acima:<\/p>\n

\n\"\"
\n<\/center><\/p>\n
\u00c9 impressionante a forma como algumas das abordagens mais recentes conseguiram melhorar o desempenho do decorrer dos anos.<\/p>\n
9. Conclus\u00e3o<\/strong><\/p>\n
Ent\u00e3o, qual a conclus\u00e3o que podemos tirar disso tudo? Bem, os produtos GIS est\u00e3o evoluindo e agora est\u00e3o posicionados para lidar com conjuntos de dados realmente grandes de maneiras que n\u00e3o pod\u00edamos fazer antes. Estou impressionado com cada um desses produtos.<\/p>\n
Este post foi traduzido e adaptado livremente do post originalmente escrito por Arthur J. Lembo Jr, do blog GIS Advising.<\/em><\/p>\n
Fonte: GIS Advising<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Esta semana estava lendo o feed do meu twitter quando me deparei com o titulo “Big Data Results“, e resolvi entrar para espiar do que se tratava! Era um post que fazia uma an\u00e1lise com dados de Nova Iorque (t\u00e1xis)… Continue Reading →<\/a><\/p>\n","protected":false},"author":275,"featured_media":7537,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24],"tags":[217,311,212],"class_list":["post-7534","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-gis","tag-arcgis","tag-big-data","tag-postgis"],"_links":{"self":[{"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/posts\/7534","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/users\/275"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/comments?post=7534"}],"version-history":[{"count":34,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/posts\/7534\/revisions"}],"predecessor-version":[{"id":7552,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/posts\/7534\/revisions\/7552"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/media\/7537"}],"wp:attachment":[{"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/media?parent=7534"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/categories?post=7534"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fernandoquadro.com.br\/html\/wp-json\/wp\/v2\/tags?post=7534"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}