lombak şehidi

Scala-test bizlere testleri taglama ve daha sonra bu taglara gore filtreleyerek calistirma imkani sunuyor. Ornek olarak bazi testler yavas seklinde etiketlenebilir ve gerektigi zamanlarda bu testler calistirilmayabilir. Testi gozardi etme Default olarak tanimlanmis bir tag ise ignore . Bunu direk kullanmaya baslayabilirsiniz ve o test gozardi edilecektir.  ignore should "soyledir boyledir" in {     // baya bi testler ama ignore edilecek } sbt test ile calistirdigimizda bu testin yesil yerine sari olarak gectigini ve yaninda IGNORED yazdigini gorecegiz.  Kendi tagimizi uretiyoruz Tag tanimlamak icin Tag traitini extend eden bir object yaratmamiz yeterli. Daha sonra bunu teste eklerken her style trait (yani kullandigimiz test stili) kendi yontemini sunar. import org.scalatest.Tag object DatabaseTesti extends Tag("com.mycompany.tags.DbTest") Daha sonra ornegin FlatSpec'te bu tagi bir teste eklemek istersek: "Acayip database" should "degisik olaylar

Bu dizide genel olarak scala ve spark projelerini nasil test ederiz buna deginecegiz.  Scala Test Gunumuzde scala projelerinde defacto testing kutuphanesi olarak  scala-test kutuphensini  kullaniliyor. Birkac noktaya burada deginelim: - Scala-test birden fazla testing stiline izin vermektedir. Ancak bir proje icerisinde bunlari karisik olarak kullanmak onerilmez. Proje baslangicinda secilen bir stil tum unit testlerde uygulanmasi daha verimli olur.  - Farkli test kategorileri icin (ornek olarak unit testing ve acceptance testing) farkli test stilleri kullanilabilir. Hatta bu sayede developer teste baktigi zaman bunun hangi tip test oldugunu daha iyi anlayabilir.  - Assertion, matcher, mixin ve trait gibi mekanikler tum test stillerinde ayni sekilde calismaktadir. Yani testin icini degistirmeye gerek yoktur.  - Scala-test'in dokumantasyonda onerdigi yontem unit ve intergration testing icin FlatSpec ve de acceptance test icin ise FeatureSpec seklinde. Bu testing stillerine bir goz at

Hadoop distributed computing frameworkune genel olarak bir goz atacagiz. Neler var? - HDFS - MapReduce -Yarn Big data da bana mi big? Facbook'un toplamda 300 Petabyte data store ettigi ve gunde 600 terabyte datayi isledigi soyleniyor. Her ay Facook'a 1 milyar kisi log-in oluyor. Her gun 2.7 milyar like veriliyor. Her gun 300 milyon resim Facebook'a yukleniyor.  NSA toplamda 5 exabyte data sakladigi soyleniyor. Gunde 30 petabyte data isledigi ve internet trafiginin %1.6 sini takip ettigi bunlara web aralamalari , ziyaret edilen siteler, telefon konusmalari, kredi karti ve hesap hareketleri finansal ve saglik bilgileri de dahil.  Babalarin babasi Goole ise toplamda 15 exabyte veri barindirdigi soyleniyor. Her gun 100 petabyte datayi isliyor. 60 trilyon web sayfasini indexinde barindiriyor. Her ay toplamda 1 milyardan fazla arama yapiliyor. Her saniye 2.3 milyon arama demek oluyor.  Bigdata sistem gereksinimleri - Storerage : Bigdata sistemlerinde cok fazla data olur (surpris

 Airflow ile bir dag icerisinde paralelde tasklar calistirabiliriz evet bu dogru. Ancak kac taski anyni anda paralel calistirabilirz bu birkac seye bagli.  1- Executor Hangi executor'u kullaniyorsunuz? Airflow'u lokal olarak kurdugunuzda default olarak SequentialExecutor kullaniyor. Ki bu da zaten paralel calistirma imkani vermiyor. Yine lokalde tek makinede ama birden fazla task calistirmak istersek bu sefer LocalExecutor kullanabiliriz. Zaten gerisi ( CeleryExecutor, DaskExecutor, KubernetesExecutor, CeleryKubernetesExecutor ) paralel calistirma uzerine kurulu. Ozet olarak en az LocalExecutor ile calisiyor olmamiz lazim ki paralelizasyon ayarlamasi yapabilelim.  2- Airflow paralelizm Tum daglarda (ayni anda birden fazla dag da calisabilir sonucta) ayni anda toplamda kac paralel task calisabilecegini oncelikle ayarlamamiz gerekiyor. Cunku bir ust limit. Bunu ayarlamanin 2 yolu var. Birincisi airflow.cfg dosyasindan bu ayari degistirebiliriz ya da airflow scheduler start olmad

Daha once dosya ve klasor izinleri ne gozatmistik. Bu gorece kisa postta ise, genel olarak linuxun kullanici ve gruplari nasil yonettigi hakkinda konusacagiz. Kullanicilar Sistemde tanimli kullanicilarla ilgili bilgi almak icin passwd dosyasi incelenebilir.  $ cat /etc/passswd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin ... Adinda password gecse de parola icermeyen bu dosya bize sistemdeki kullanicilarin bir listesini verir. Kullanici adindan sonra gelen x, o kullanicinin sisteme bir parola ile login oldugunu gosterir. Ornegin root kullanicisindan parola olmadigini goruyoruz. Daha sonra userID ve groupID numaralari geliyor. Takiben kullanicinin home directory'si ve son olarak da default shell path'ini goruyoruz.  Peki neden bu kadar fazla kullanici tanimli ve garip isimleri var? Bu kullanicilar sistem kullanicilari olup bazi tasklar bu kullanicilar uzerinden yerine getirilir.  Gruplar Benzer sekilde /etc/g

Bu postta linux sistem kaynaklarini ve bu kaynaklari kullanan processleri monitor etme konularina deginecegiz.  Sistem Bilgisi Monitor edemedigimiz birseyi iyilestiremeyiz. Bu yuzden /proc klasoru ile basliyoruz. Bu klasor, sistem ile ilgili bilgilerin tutuldugu virtual files barindirir. Ornek olarak RAM ile alakali bilgileri su sekilde gorebiliriz: $ ls /proc -r--r--r-- 1 root  root    0 Jan 20 06:42 cgroups -r--r--r-- 1 root  root    0 Jan 20 06:42 cmdline -r--r--r-- 1 root  root    0 Jan 20 06:42 cpuinfo -r--r--r-- 1 root  root    0 Jan 20 06:42 filesystems -r--r--r-- 1 root  root    0 Jan 20 06:42 interrupts -r--r--r-- 1 root  root    0 Jan 20 06:42 loadavg -r--r--r-- 1 root  root    0 Jan 20 06:42 meminfo ... $ cat meminfo  MemTotal:       66929712 kB MemFree:        40141688 kB Buffers:           34032 kB Cached:           188576 kB ... Benzer sekilde cpuinfo dosyasi da cpu ile ilgili bilgiler barindirmaktadir. Bu dosyalar system specs'leri anlamada isimize yarar. Ancak sist

The File Mode Dosya modu, uc farkli izin barindiri. User, group ve others. Her biri icin de uc farkli moda sahiptir: Read, Write ve Execute. Ornek olarak sistemdeki hosts dosyasinin izinlerini inceleyelim: :~/lnx$ ls -l /etc/hosts -rw-r--r-- 1 root root 539 Jan 16 05:39 /etc/hosts Ilk karakter listelenen ogenin tipini belirtir. Bunlar: - : dosya d : directory p : named pipe l : symlink b : block device c : character device s : socket Bu karakterden sonra 3 karakterden olusan 3 obek bulunur. Her bir obek aslinda read, write ve execute yetkilerini temsil eder. Eger yetki var ise karakteri gosterilir, yetki yok ise (-) yani dash gosterilir. Okuma yazma yetkisi olan ama execute yetkisi olmayan bir obek su sekilde gorunecektir: rw- Bu sekilde 3 karakterle gostermek yerine bir sayi ile de gosterilebilir. Her bir yertkiyi bir bit olarak dusunursek, yukaridaki obek su sekle donusur: 110 Bu da sayi olarak 0 + 1*2 + 1*2^2 = 6 olur.  Bu sekilde 3 farkli obek var demistirk. Birincisi, bu dosyanin

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

- Kalk yerine yat olm, boynun agrir Oncelikle proje artifactlarini package etmemiz gerekiyor. Bunun icin sbt-native-packager pluginini kullanacagiz. Birkac adim izlemek gerekiyor: 1. project/plugins.sbt dosyasina plugini ekle 2. Packaging formatini tanimla 3. plugin tarafindan saglanan Setting'i calistir Project klasoru altina plugins.sbt dosyasi olusturuyoruz. Icrigi su sekilde: addSbtPlugin("com.typesafe.sbt" %% "sbt-native-packager" % "1.3.21") Paketlemeye gecmeden son adim olarak da, build.sbt dosyasinda iki proje icin de enablePlugin metodu ile sbt-native-packager pluginini JavaAppPackaging formatini kullanacak sekilde konfigure ediyoruz.  lazy val sansOyunlari = project      .dependsOn(api)      .enablePlugins(JavaAppPackaging)      .settings(           libraryDependencies ++= Dependencies.sansOyunlariDependecies      ) Simdi stage komutu ile paketlemeye gecebiliriz. stage, sbt-native-packager tarafindan saglanan bir task.  sbt:hello_sbt> ;cl