lombak şehidi

Bugun Scala implicit conversions'dan bahsediyoruz. Mesela ki, bir sekilde, iki integer toplamak istedigimde soyle bisey yapmak istiyorum: scala> 1.plus(1) <console>:24: error: value plus is not a member of Int        1.plus(1)       ^ Tabi boyle bisey yok. O zaman bir case class tanimliyorum: scala> case class IntExtensions(value: Int){          |     def plus(operand: Int) = value + operand          | } defined class IntExtensions ve daha sonra: scala> IntExtensions(1).plus(1) res8: Int = 2 Bu sekilde calistirabilirim. Ama bu cok cirkin ve cok uzun. Her seferinde IntExtensions class'ini kullanmak istemiyorum. O zaman scala'nin implicit conversions guzelligini sahneye davet ediyorum: scala> import scala.language.implicitConversions import scala.language.implicitConversions ve daha sonra implicit ve fonskyion tanimliyorum ki her bir integer'e, IntExtensions muamelesi yapabileyim: scala> implicit def intToIntExtensions(value: Int) = {         | IntExt

Daha once spark paper 'den bahsetmistik. Ama daha pratik ve saniyorum ki daha az tatava icermesi ihtimaline binaen bu paper ile okumalara basliyoruz.  Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing Ozet gec chip (abstract) RDD, programcilara cluster uzerinde datigit olarak in-memory islem yapabilmeyi saglana bir soyutlama katmanidir. Bu yapiyi olusturmaktaki esas motivasyon, suanki uygulamalarin (Hadoop'u kastediyor) inefficient olarak handle ettigi iteratif uygulamalar ve interactive data-mining . Cunku iki durum icin de, datayi hafizada tutmak (Hadoop, bunun aksine her step'i diske yaziyordu), performansi kat be kat artirmaktadir.   Fault tolerance'i elde edebilmek icin, RDD'ler cok detayli state guncellemeleri yerine, kaba (coarse grained) transformasyonlara dayanan cok kisitli shared-memory sunar. (dediklerin iyi gibi ama cok da anlamadik). Buna ragmen, RDD'lerin destekledigi transformasyonlar cok genis yelpaza

Macera, aksiyon ve tansiyon... hepsi bu postta.       T ransformasyonlarin aksine, aksiyonlar lazy degildir. Bir aksyion cagrildigi an, tum hesaplamalar yapilir ve sonuc node'lardan driver programa aktarilir. Eger bir metot RDD dondurmuyor ise, aksyondur. Mesela count, integer dondurur.  Bazi aksyionlar onceliler node'larda her bir partition uzerinde calistirilarak daha sonra driver'a yonlenirler. Bu sayede mumkun oldugunca shuffle edilecek data azaltilmis olur. Mesela count'ta, oncelikler her bir partition icin count hesaplanarak sadece bu int degeri shuffle edilir. Yoksa tum data shuffle edilip driver uzerinde bunlarin count'ini almak en hafif tabirle lazlik olacaktir.  Collect En bodoslama action bu olsa gerek. Diyor ki tum distributed datayi topla bana (driver program) getir. Eger burada cok fazla data varsa driver program out of memory diye bagirarak patlatacaktir. Bir dataset'in distributed olarak tutulmasinda bir sebep olsa gerek degil mi? mesele tek bir

 Baska bir transformations kosesinde daha birlikteyiz.  mapPartitions Bizim datamiz node'lar uzerinde cluster'da dagitik durumdadir. Bunun uzerinde bir map islemi yapar isek, her bir node, kendi uzerindeki data icin her bir elemana verilen transformasyonu uygulayacaktir. Ama mesela bir database baglantisi yapilmasi gerekiyor ise bu durumda her bir item icin yeni bir database baglantisi gerekecektir. Bu da performans acisindan problem dogurur. Ama mapPartitions kullanarak, verilen bir transformasyona o partition'daki tun datayi bir seferde verebiliriz.  Cok uzattim ama boylelikle her bir partition icin sadece tek bir database baglantisi olusturma imkani yakalariz.  > sc.parallelize(1 to 100) res0: org.apache.spark.rdd.RDD[Int] = ParallelCollectionRDD[0] at parallelize at <console>:25 > scala> res0.partitions.size res1: Int = 6 scala> res0.mapPartitions(partition => {      // partition oncesi hazirlik      partition.map(item => /// biseyler yap)     //

Ya hocam birak, var mi biseyler? Datayi yuklediysek transform edelim az biraz. Bir metodun transformer olup olmadigini anlamanin bir cakal yolu da signature'une bakmaktir. Eger o da bir RDD donduruyorsa, lazy bir sekilde, orjinal RDD uzerine uygulanacak islemlerin planini olusturan bir transformer metottan baskasi degildir.  Tatavami su sekilde birakarak olaya giriyorum. Map Adi uzerinde, belli bir degere karsilik baska bir deger "map" ediyoruz. Yani bir listeyi alip her bir eleman uzerinde bir islem uygulayarak (evet layarak) yeni bir liste olusturuyoruz.  > sc.parallelize(1 to 100).map(_ *2)  dersem anlasilir herhalde.  FlatMap Bu da oncekinin daha flat hali zheuehhas. Tamam tamam. Bu metod verilen transformasyonu once tum elemanlara uygular sonra da ortaya cikan elemanlarin tamamini birlestirip flat bir list yapar. Yani, > sc.textFile("file:///C:/deneme.txt").flatMap(satir => satir.split(" ")) seklinde yaparsak, oncelike bir text dosyasi ok

Yok be olum, bu sekilde degil. Datayi arap faikten aliyorduk Spark bircok farkli mecradan data okuyabilmektedir. Normal file systems (lokal makine veya uzak makine), Amazon S3 ve HDFS gibi distributed file systems, database, distributed database ve hatta direk olarak memory'den de data yuklenebilmektedir. Spark, datanin  cigerini sokmektedir. Ayrid dosya formati olarak da, text, csv gibi plain formatlar oldugu gibi, parquet (dassagini yedigimiz) ve avro gibi de daha gelismis formatlar okunabilir.   Tatavamizi kenara birakip shell'imizi aciyoruz: > sc.parallelize(1 to 100) > res0: org.apache.spark.rdd.RDD[Int] = ParallelCollectionRDD[0] at parallelize at <console>:25 Goruldugu gibi 1'den 100'e kadar olan sayilari barindiran bir listeyi RDD icerisine yukledik. Burada bir kucuk detay da spark-shell bu olusturulan RDD'yi biz bir degiskene atamasak da, res0 adli degiskene atadi. Buna daha sonra atifta bulunabiliriz: > res0.collect > res1: Array[Int] = A

clusterda datalar yeniden dagitiliyor (shuffle) Resilient Distributed Dataset Bir clusterda node'lar uzerinde dagitilmis halde bulunan ve uzerinde paralelde islemler yapilabilen bir koleksiyondur. Spark dokumantasyonu boyle tanimliyor RDD'yi. Yani aslinda bir program yazarken normal , tek bir makinenin hafizasinda bulunan bir kolleksiyon gibi islemler yapabiliyoruz (mesele .map) ama aslinda bu veriyapisi birden fazla makinenin hafizasinda dagitik olarak bulunuyor. Bir parcasi orada bir parcasi burada falan gibi. Hatta parcalarda replikasyon var ki fault tolerant olsun. Iste bur bir soyutlama aslinda. Spark api'si tasarlanirken bu dagitik kolleksiyon uzerinde islem yapmayi sanki normal bir kolleksiyonmus gibi developer'dan sakliyor. Ama burada da bir rist var. Bazi yapilan islemler tum node'lardaki datanin birbiriyle senkronize edilmesini ya da yeniden dagitilmasini (shuffle) gerektiriyor. Eger bunlara dikkat etmezsek, cok ciddi performans kayiplari yasanabiliyor.  T

 Konsole guzel, konsol pratik, interaktif. Ben de ad-hoc queryler icin kullaniyorum ya da experimentation amacli. Ama misal ETL joblari yazmak icin girdili ciktili (I/O) uygulama yazip derleyip ortaya koymamiz lazim.  Tum spark uygulamari driver program adi verilen tek bir noktadan yonetilir. Driver, gerekli islemleri diger makinelere dagitmak gibi bir gorevi vardir. Bizim meshur sparkContext de bu driver program icerisinde calismaktadir. Driverin gorevleri arasinda: 1. Task'larin olusturulmasi: Execution planin olusturulmasi ve tasklarin worker node'lara gonderilmesi 2. Schedule edilmesi (ya da ettirilmesi) 3. Data locality'nin gozetilmesi 4. Fault tolerance:  Buradaki Cluster Manager spark'in kendi cluster manageri olabilecegi gibi YARN veya Mesos da olabilir. Ben genelde YARN ile calisildigini gordum. Bu cluster manager sayesinde bizim driver program gerekli resourcelari cluster'dan talep eder. Driver program, cluster manager'e baglandiktan sonra clusterda bu

Gecenlerde (dun aksam gece 3'lere kadar calisirken) Google scholar uzerinde denk geldigim (evet cok entel takilirim) bir makale bana gosterdi ki, bunu dusunen tek manyak ben degilmisim.  Adam demis ki,  The Future of Big Data Is …JavaScript?   Bir suru tarihi ozetleme yarak kurekten sonra demis ki, ya bu Java bir kere yaz heryerde calistir dedi ama JavaScript bundan da daha fazla bir kere yaz heryerde calistir oldu.  Ayrica data-science mevzularinda isin bir kismi da gorsellestirmede ve bunun icin genelde browser ve javascript kullaniliyor. Data isleme ve filtreleme kismi iste baska bir tech stack'de yapilip donusturulup, ancak ondan sonra browserda gorsellestirilebiliyor. Halbukisine hepsi Js ile olsa kolayca gorsellstirirsin.  Bana da mantikli geldi bir yerde. Ama oturup koca spark'i bastan Js ile implemente etmek yerine, PySpark gibi, spark ile iletisim kuracak bir ara cozum, bir binding yazilabilir gibi geldi.  Yani biz spark kodumuzu js ile yazacagiz ama bu js kodunu b

 O kadar ovdukten sonra Spark'in kurulumna gecelim.  https://spark.apache.org/downloads.html adresinden, spark versiyonu ve handi Hadoop dosya sistemine karisilik calismasi gerektigini belirtiyoruz. Spark, Hadoop'un hdfs (hadoop distributed file system) kullandigi icin, uyumlu bir versiyon secmemiz gerekiyor.  Ben simdi deneme icin windows uzerinde kurulum yapacagim. O yuzde Spark 3.0 ve Hadoop 3.2 ve uzeri destegini secip indiriyorum. Ek olarak sadece JDK gerekli.  Simdi inen tar ball'ini 7zip gibi biseyle extract edip, C drive'a kopyaliyorum. Spark'in executablelari bin klasorunde oldugu icin komut satirindan kolay calisabilmek adina C:\spark\bin yolunu environment variables'tan system path'ina ekliyorum. ve bir terminal acip (power shell), spark-shell komutunu giiyorum. Dakika 1 gol 1,   hata ile karsilasiyorum. Ama bu bir spark bug'i ve cozumu icin bize winutils.exe ve hadoop.dll dosyalari gerekli.  https://github.com/steveloughran/winutils adresinde

Daha da cok ovecegiz Problem Cok buyuk ve cesitli verileri (data volum and variety) belirli bir sure icerisinde islemek gerekiyor.  Cozum Bircok cozum var.  Grep Binlerce text dosyasi uzerinde bir grep komutu ile cok guzel data isleyebilirim. Ama bu islemi sadece tek bir bilgisayar uzerinde yapabilirim degil mi? Eger elimdeki data tek bir bilgisayara sigmayacak kadar buyukse bu secenek duser.  MapReduce Bu problemi goren yetkililer MapReduce adini verdikleri bir programlama paradigmasi ile cikip gelmisler.  Bu sayede birden fazla makine uzerinde data islemek mumkun hale gelmis. Baya bir sure de bu yapiyi kullanmislar mutlu mesut. Spark Ancak, mapreduce uygulamari yazmak cok fazla kodlama gerektirmesi, harddisk islemini cokca barindirmasi gibi  bagzi kotu taraflarini goren bir abimiz, ben hafiza bazli, abstractionlari cok guzel bir framework yazayim demis. Adini da Spark koymus. - Daha az kod yazmayi gerektiriyor. Hatta uygulamaniz dagitik calisacakmis gibi bile gorunmuyor. Cunku abstra