ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 125
Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 62
Abonament PDF

OpenStreetMap în epoca Spark

Adrian Bona
adrian.bona@telenav.com
PROGRAMARE

OpenStreetMap este o hartă considerată o Wikipedia a hărților. Există foarte multă informație online despre acest proiect, chiar și cărți pe această temă, dar nu vom discuta despre istoria OSM. Ne propunem să vă oferim o descriere generală a setului impresionant de date care stă la baza OSM și a modului în care o astfel de hartă mare poate fi analizată prin intermediul unor tehnologii moderne precum Apache Spark.

O scurtă anatomie a OpenStreetMap

Unul din motivele pentru care OSM a ajuns până în acest punct este faptul că este un model simplu pentru reprezentarea datelor. Există doar trei tipuri de entități:

Fiecare entitate poate avea mai multe etichete (tags) (de exemplu, o cale marcată cu highway=residential ne arată că e vorba de un drum rezidențial).

De asemenea, se stochează informație adițională despre utilizatorul care a adăugat fiecare entitate, cât și momentul adăugării acesteia.

Cât de mare este OpenStreetMap?

Datele sunt disponibile, în două formate:

Proiectul OSMstats arată evoluția zilnică a hărții.

Este OpenStreetMap accesibilă pentru lumea Big Data?

Poate fi dificil să începeți să lucrați cu OpenStreetMap la scară mare. Acum câțiva ani eram uimiți să vedem colegii așteptând ore sau zile pentru a încărca părți din OSM în PostgreSQL pe mașini imense. Era totuși normal ... pentru că nu era Big Data.

Între timp, am început să lucrăm cu diverse analize geo-spațiale în cadrul unor proiecte experimentale folosind tehnologii Big Data din lumea Hadoop. Dar din nou, felul în care sunt organizate datele OSM ne-a constrâns să folosim o unealtă numită osmosis rulată pe un fișier uriaș PBF pentru a extrage doar anumite părți de interes și salvarea acestora în fișiere CSV, ca ulterior acestea să fie folosite în cadrul unor joburi MapReduce. Chiar dacă acest lucru funcționează, nu are cel mai bun randament. 

Ulterior, când am început să utilizăm la scară mare Apache Spark, aveam nevoie de o soluție generală pentru a reprezenta toate datele OSM. Soluția pe care am ales-o, a fost să folosim un format în coloană numit Apache Parquet

Convertorul este disponibil la adresa: github.com/adrianulbona/osm-parquetizer

Cât de rapidă este conversia?

Mai puțin de un minut pentru romania-latest.osm.pbf și ~3 ore (pe un laptop cu SSD) pentru planet-latest.osm.pbf.

Care este rolul tehnologiei Spark în această poveste?

Convertorul menționat mai sus are ca intrare un singur fișier și nu doar convertește datele, ci le și împarte în trei fișiere, unul pentru fiecare tip de entitate OSM - fiecare fișier reprezentând în fond o colecție de date structurate (un tabel). Schemele tabelelor sunt următoarele:

node
 |-- id: long
 |-- version: integer
 |-- timestamp: long
 |-- changeset: long
 |-- uid: integer
 |-- user_sid: string
 |-- tags: array
 |    |-- element: struct
 |    |    |-- key: string
 |    |    |-- value: string
 |-- latitude: double
 |-- longitude: double

way
 |-- id: long
 |-- version: integer
 |-- timestamp: long
 |-- changeset: long
 |-- uid: integer
 |-- user_sid: string
 |-- tags: array
 |    |-- element: struct
 |    |    |-- key: string
 |    |    |-- value: string
 |-- nodes: array
 |    |-- element: struct
 |    |    |-- index: integer
 |    |    |-- nodeId: long

relation
 |-- id: long
 |-- version: integer
 |-- timestamp: long
 |-- changeset: long
 |-- uid: integer
 |-- user_sid: string
 |-- tags: array
 |    |-- element: struct
 |    |    |-- key: string
 |    |    |-- value: string
 |-- members: array
 |    |-- element: struct
 |    |    |-- id: long
 |    |    |-- role: string
 |    |    |-- type: string

Încărcarea datelor în Apache Spark devine acum extrem de simplă:

val nodeDF = sqlContext.read.parquet(
  "romania.osm.pbf.node.parquet")

nodeDF.createOrReplaceTempView("nodes")

val wayDF = sqlContext.read.parquet(
  "romania.osm.pbf.way.parquet")

wayDF.createOrReplaceTempView("ways")

val relationDF = sqlContext.read.parquet(
  "romania.osm.pbf.relation.parquet")

relationDF.createOrReplaceTempView("relations")

Să considerăm următoarea cerință:

Pentru cei mai activi contributori OSM, să se prezinte distribuția muncii acestora în timp.

În cazul utilizării Spark DataFrames API, o posibilă soluție este următoarea:

val nodeDF = nodeDF
  .withColumn("created_at", ($"timestamp" / 1000)
  .cast(TimestampType))
  .createOrReplaceTempView("nodes")

val top10Users = nodeDF.groupBy("user_sid")
  .agg(count($"id").as("node_count"))
  .orderBy($"node_count".desc)
  .limit(10)
  .collect
  .map({ case Row(user_sid: String, _) => user_sid })

nodeDF.filter($"user_sid".in(top10Users: _*))
  .groupBy($"user_sid", year($"created_at").as("year"))
  .agg(count("id").as("node_count"))
  .orderBy($"year")
  .registerTempTable("top10UsersOverTime")

Dacă se folosește Spark SQL:

select 
  user_sid, 
  year(created_at)) as year,
  count(*) as node_count
from 
  nodes
where 
  user_sid in (
      select user_sid from (
        select 
          user_sid, 
          count(*) as c 
        from 
          nodes 
        group by 
          user_sid 
        order by 
          c desc 
        limit 10
      )
  )
group by 
  user_sid, 
  year(created_at)
order by 
  year

Ambele soluții sunt echivalente și returnează rezultatele din figura de mai jos. Chiar dacă exemplele au fost ilustrate doar în cadrul unei zone restrânse, de interes pentru comunitatea locală de editori OSM, nimic nu ne oprește acum să executam exact aceleași interogări în mod scalabil pentru toată planeta.

VIDEO: NUMĂRULUI 125

Sponsori

  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Colors in projects

VIDEO: EXTRA