lombak şehidi

Hayir.  Su aralar araftayim. Hatta ki nasil bir araf, kitalar arasi. AWS calisiyorum bu aralar. Ama henuz yazamiyorum. Yazmaya/yayinlamaya ara verince gercekten insanin eli gitmiyor. Bu postu da zaten bu yuzden yaziyorum. To get the ball rolling. Neler Ogreniyoruz ? AWS ozelinde olsa da IaC (infrastructure as code) olaylari gercekten muazzam. Yillardir cloud ile ic ice olsam da, gercek anlamda cloud avantajlarini gormek icin IaC olaylarina gozatmak gerek. Neden daha once cikarmadilar bilmiyorum ama CDK (cloud development kit) gercekten inanilmaz. Python ile infrastructure yaziyorsunuz, testleri de cabasi. Lambda kullanarak kodumuzu da python ile yaziyoruz ve boylece fullstack uygulamalari aws uzerine deploy etmek tek satir cli komutuna bakiyor: cdk deploy . Bu kisim kendi basina bir blog post hakediyor sonuna kadar.  AWS Networking CDK guzel ama, biraz da AWS internals ogrenmek gerekiyor. Her zaman en zorlandigim konu networking olmustur. Belki de formal bir CS egitimim olmadigi icin o

gRPC server yazacagiz ve serverimizin cok guclu (o da ne demekse) olmasini istiyoruz. Bu yuzden, bir sekilde gelen requestleri paralel olarak isleyebilen bir yapiya ihtiyacimiz var. Python threading malum, CPU intensif isler icin uygun degil cunku GIL sebebiyle ayni anda birden fazla Python kodu calistirilamiyor. Dolayisi ile mevzubahis CPU gerektiren islemler ise, Python threading aslinda tek thread gibi davraniyor.  Bu durumda official ornege bakabiliriz. Tamam Python threading'de GIL engeli var ama multi-process yapar isek boyle bir engel yok. Ne de olsa her bir process kendi GIL'ine sahip olacak. Ama burada da yuku processlere nasil dagitaracagimiz problemi akillara geliyor.  Port Sharing Resmi ornekte, yuk dagitma islemini butun process'leri ayni porta bind ederek saglamislar. Bu sayede yuk TCP katmaninda, isletim sisteminin Kernel seviyesinde yapilmis oluyor. Port uzerine gelen istekler, TCP katmani tarafindan bu portu dinleyen processlere bir round-robin yapisi sekli

Buyuk resmi gor yigenim. Gelin birlikte sifirdan bir scala ve sbt kullarak, multi project bir yapida Play projesi olusturalim. 1. Play  Play, JVM'de kabul gormus bir web application framework'u. Ilk baslangicta, kendi basina calisacak cok basit bir Play projesi olsutralim. IntelliJ kullaniyorum, yeni bir sbt projesi  olustuyorum. Daha sonra build.sbt uzerinde su sekilde eklemeler yapacagiz:      name := "play-standalone"      version := "0.1"      scalaVersion := "2.13.8"    lazy val root = (project in file ( "." ))      .enablePlugins( PlayScala )      .settings(      name := """cok sukseli api projesi""" ,      organization := "com.lombak" ,      version := "1.0-SNAPSHOT" ,      scalaVersion := "2.13.6" ,      libraryDependencies ++= Seq (      guice ,      "org.scalatestplus.play" %% "scalatestplus-play" % "5.0.0&qu

Emr uzerinde Jupyter notebook calistirmak cok kolay. Tek yapmamiz gereken SageMaker console'a giderek yeni bir notebook olusturmak. Buradaki tek puruz, ekstra bir Jar dosyasindan spark job import etmek ve jupyter notebook uzerinde calismak.  Yapmamiz gereken sey, Jar dosyamizi s3 uzerinde bir yere kopyalayip, daha sonra Jar'i jupyter notebook'a import etmek. %%configure -f {     "conf": {          "spark.jars.packages": "com.jsuereth:scala-arm_2.11:2.0,ml.combust.bundle:bundle-ml_2.11:0.13.0,com.databricks:dbutils-api_2.11:0.0.3"     },     "jars": [           "//s3 jar yolu"     ] } Bu sayede yolunu verdigimiz Jar (lar) icerisinde spark job'larini notebook uzerinde claistirabilir ve cok keyifli bir development environment olusturabiliriz.  Happy hacking.

Cok fazla tatavaya girmeden son donemde karsialstigim bir problemle ilgili cozumumu paylasmak istiyorum. Neden Zeppelin? Oncelikle neden ve ne sekilde zeppelin kullaniyorum? Aslinda tabi ki production-grade uygulamalari zeppelin ile gelistirmiyoruz. sbt bazli baya duz IntelliJ ile gelistirdigimiz scala / spark uygulamalari var. Ancak bazi durumlar oluyor ki, bir metodu alip incelemek istiyorum. Farkli inputlar ile ne gibi sonuclar veriyor gormek istiyorum. Yani elimizdeki mevcut scala / spark projesi ile biraz oynamak istiyorum.  Bunun icin oncelikle scala projesini assemble ederek (sbt assembly plugin kullaniyorum), zeppelin'deki spark interpereter'e import ediyorum. Daha sonra zeppelin notebooklar icerisinde bu projeimin istedigim kisimlarini import ederek cagirabiliyorum.  Gorsellestirme onemli bir mevzumuzdur Ve bir noktada bu sonuclari gorsellestirmem gerekiyor. Ozellikle spatial data ile ugrasirken 2d scatter plot guzel gidiyor diyebilirim. Ancak scala tarafinda bunu cize

 Buradayim arkadaslar, bir yere gittigimiz yok (henuz).  Bu postun amaci, olmedigimi ozellikle kendime gosterebilmek ve de blog yazma konusuna tekrar isinabilmek. Simdi siteye baktim da 3 aydir yeni post gelmemis. Peki ben ne yaptim 3 ayrdir ? - AWS uzerinde daha fazla calismaya basladim. EMR'da Spark calistirmak ile alakali yazacagim seyler var. - Spark performans optimizasyonu ve hatta Spark uzerinde buyuk spatial verilerin islenmesi esnasinda performans optimizasyonu konularinda calistim. Sonuclari paylasacagim.  Onumuzdeki 12 aylik donem icerisinde algoritma calismalarina biraz ara vermeyi planliyorum. Daha ziyade tekrardan big-data ve devops konularina odaklanacagiz. Gorusmek uzere.

Baya bir suredir devlog yazmiyorum. Yine bir solukta okuyacaginiz bir devops / dataops macerasi ile karsinizdayiz.   Day 1 Is yerinde tamamen iki farkli ortamda calismak durumundayiz. Birtanesi is yaptigimiz sirketin super secure data-centeri otekisi de kendi sirketimizin on-premises makinesi. Bu iki farkli ortam uzerinde dagilmis bir airflow pipeline'a ihtiyac var. Bakalim nelerle karsilacagiz.  Diyelim ki is yaptigimiz sirket X, kendi sirket makinemiz ise Y.  X'ten Y'ye rest api , ssh veya baska hicbir sekilde ulasilamiyor. Ama Y'den X'e ssh yapilabiliyor.  Ama airflow dag X'te basladigi icin, X'ten Y'ye bir trigger gerekiyor. Tersi olsa kolaydi cunku ssh imkani var Y'den X'e. Durum asagi yukari soyle: Tek iletisimimiz sshfs uzerinden mount edilebilen MapRFS olarak gozukuyor. Simdi plan su: 1. X'teki DAG, isi bittigi ve Y'dekini trigger etmek istedigi zaman MaprFS uzerinde belirlenmis bir lokasyona bir dosya olusturacak 2. Y'deki ma

Baaazi dosyalari isleyerek baaazi output ureten bir pipelinimiz var.  Bu dosyalari hizli isleyebilmek icin, python'da yazdigimiz uygulamayi dockerize edip, k8s uzerinde paralel calistiriyoruz. Ancak elle yapiyoruz bu isi. Ne kadar da amelece.  Simdi bunu alip, Airflow ile otomatize edelim. 1. Gun Mevcut Yontem Halihazirda dosyalari manuel olarak 20 farkli klsore boluyoruz. Daha sonra 20 farkli Pod kaldirip bu klasorleri parametere olarak veriyoruz. Klasorler de ayrica distributed bir file storeage uzerinde bulunuyor, volume mount ile hallediyoruz. Haliyle pod icerisinde calisan python uygulamasi sadece kendine verilen yol'daki dosyalari isliyor. Boylece kimse kimsenin isine karismadan butun dosyalari paralel olarak isliyoruz.   Ama otomatize edebilmek icin cok da iyi bir yontem degil.  1. Elle (veya hatta otomatize olarak) dosyalari klasorlere bolmek istemiyorum 2. Pipeline'i kolay bir sekilde trigger edebilmek istiyorum 3. Parallesim'i kolayca ayarlayabilmek istiyorum