Merhaba Habr! OTUS'ta yeni kurs akışına kayıtlar şu anda açık . Kursun başlaması beklentisiyle, geleneksel olarak sizin için ilginç materyallerden oluşan bir çeviri hazırladık.
Her gün yüz milyondan fazla insan dünyada olup bitenleri öğrenmek ve tartışmak için Twitter'ı ziyaret ediyor. Her tweet ve diğer her kullanıcı eylemi, Twitter'ın dahili veri analizine uygun bir etkinlik oluşturur. Yüzlerce çalışan bu verileri analiz edip görselleştiriyor ve deneyimlerini geliştirmek, Twitter Veri Platformu ekibi için en önemli önceliklerden biri.
Çok çeşitli teknik becerilere sahip kullanıcıların verileri keşfedebilmesi ve iyi performans gösteren SQL tabanlı analiz ve görselleştirme araçlarına erişebilmesi gerektiğine inanıyoruz. Bu, veri analistleri ve ürün yöneticileri de dahil olmak üzere daha az teknik kullanıcıdan oluşan yepyeni bir grubun verilerden içgörü elde etmesine ve Twitter'ın yeteneklerini daha iyi anlamalarına ve kullanmalarına olanak tanıyacak. Twitter'da veri analitiğini bu şekilde demokratikleştiriyoruz.
Araçlarımız ve dahili veri analizi yeteneklerimiz geliştikçe Twitter'ın da geliştiğini gördük. Ancak hâlâ geliştirilebilecek yerler var. Haşlanma gibi mevcut araçlar programlama deneyimi gerektirir. Presto ve Vertica gibi SQL tabanlı analiz araçlarının geniş ölçekte performans sorunları vardır. Ayrıca verileri, sürekli erişim olmadan birden fazla sisteme dağıtma sorunumuz da var.
Geçen yıl duyurmuştuk , içinde bölümlerimizin bir kısmını aktarıyoruz Google Cloud Platform'da (GCP). Google Cloud araçlarının şu sonuca vardık: Twitter'da analitiği, görselleştirmeyi ve makine öğrenimini demokratikleştirmeye yönelik girişimlerimizde bize yardımcı olabilir:
- : SQL motoru tabanlı kurumsal veri ambarı hızı, basitliği ve üstesinden gelmesiyle ünlü .
- Google Dokümanlar benzeri ortak çalışma özelliklerine sahip büyük veri görselleştirme aracı.
Bu makalede bu araçlarla ilgili deneyimlerimizi öğreneceksiniz: Ne yaptık, ne öğrendik ve bundan sonra ne yapacağız. Artık toplu ve etkileşimli analizlere odaklanacağız. Bir sonraki makalede gerçek zamanlı analitiği tartışacağız.
Twitter Veri Depolarının Tarihçesi
BigQuery'ye dalmadan önce Twitter'da veri depolamanın geçmişini kısaca anlatmakta fayda var. 2011 yılında Vertica ve Hadoop'ta Twitter veri analizi yapıldı. MapReduce Hadoop işlerini oluşturmak için Pig'i kullandık. 2012 yılında Pig'i, karmaşık işlem hatları oluşturma yeteneği ve test kolaylığı gibi avantajlara sahip bir Scala API'sine sahip olan Scalding ile değiştirdik. Ancak SQL ile daha rahat çalışan birçok veri analisti ve ürün yöneticisi için bu oldukça zorlu bir öğrenme süreciydi. 2016 civarında Presto'yu Hadoop verilerine SQL arayüzü olarak kullanmaya başladık. Spark, kendisini anlık veri bilimi ve makine öğrenimi için iyi bir seçim haline getiren bir Python arayüzü sundu.
2018'den bu yana veri analizi ve görselleştirme için aşağıdaki araçları kullanıyoruz:
- Üretim konveyörleri için haşlama
- Özel veri analizi ve makine öğrenimi için Scalding ve Spark
- Özel ve etkileşimli SQL analizi için Vertica ve Presto
- Zaman serisi ölçümlerine düşük etkileşimli, keşfedici ve düşük gecikmeli erişim için Druid
- Veri görselleştirme için Tableau, Zeppelin ve Pivot
Bu araçların çok güçlü yetenekler sunmasına rağmen, bu yetenekleri Twitter'da daha geniş bir kitleye sunmakta zorluk çektiğimizi gördük. Platformumuzu Google Cloud ile genişleterek analiz araçlarımızı tüm Twitter için basitleştirmeye odaklanıyoruz.
Google'ın BigQuery Veri Ambarı
Twitter'daki birçok ekip BigQuery'yi bazı üretim hatlarına zaten dahil etti. Uzmanlıklarından yararlanarak BigQuery'nin yeteneklerini tüm Twitter kullanım örnekleri için değerlendirmeye başladık. Amacımız BigQuery'yi tüm şirkete sunarak Data Platform araç seti içerisinde standartlaştırıp desteklemekti. Bu birçok nedenden dolayı zordu. Büyük hacimli verileri güvenilir bir şekilde almak, şirket çapında veri yönetimini desteklemek, uygun erişim kontrollerini sağlamak ve müşteri gizliliğini sağlamak için bir altyapı geliştirmemiz gerekiyordu. Ekiplerin BigQuery'yi etkili bir şekilde kullanabilmesi için kaynak tahsisi, izleme ve ters ibrazlara yönelik sistemler de oluşturmamız gerekiyordu.
Kasım 2018'de BigQuery ve Data Studio'nun şirket çapındaki alfa sürümünü yayınladık. Twitter çalışanlarına, temizlenmiş kişisel veriler içeren, en sık kullanılan e-tablolarımızdan bazılarını sunduk. BigQuery, mühendislik, finans ve pazarlama gibi çeşitli ekiplerden 250'den fazla kullanıcı tarafından kullanıldı. Son zamanlarda, planlanan istekleri saymazsak ayda yaklaşık 8 PB işleyerek yaklaşık 100 bin istek çalıştırıyorlardı. Çok olumlu geri bildirimler aldıktan sonra ilerlemeye ve BigQuery'yi Twitter'daki verilerle etkileşimde birincil kaynak olarak sunmaya karar verdik.
Burada Google BigQuery veri ambarı mimarimizin üst düzey bir şemasını bulabilirsiniz.
Dahili Cloud Replicator aracını kullanarak şirket içi Hadoop kümelerindeki verileri Google Cloud Storage'a (GCS) kopyalıyoruz. Daha sonra şunu kullanan işlem hatları oluşturmak için Apache Airflow'u kullanırız: "» GCS'den BigQuery'ye veri yüklemek için. GCS'de Parquet veya Thrift-LZO veri kümelerini sorgulamak için Presto'yu kullanıyoruz. BQ Blaster, HDFS Vertica ve Thrift-LZO veri kümelerini BigQuery'ye yüklemeye yönelik dahili bir Haşlama aracıdır.
Aşağıdaki bölümlerde kullanım kolaylığı, performans, veri yönetimi, sistem sağlığı ve maliyet alanlarındaki yaklaşımımızı ve uzmanlığımızı tartışıyoruz.
Kullanım kolaylığı
Yazılım kurulumu gerektirmemesi ve kullanıcıların sezgisel bir web arayüzü aracılığıyla erişebilmesi nedeniyle kullanıcıların BigQuery'yi kullanmaya başlamasının kolay olduğunu gördük. Ancak kullanıcıların projeler, veri kümeleri ve tablolar gibi kaynaklar da dahil olmak üzere GCP'nin bazı özelliklerine ve kavramlarına aşina olması gerekiyordu. Kullanıcıların başlamalarına yardımcı olmak için eğitim materyalleri ve öğreticiler geliştirdik. Kazanılan temel anlayışla kullanıcılar, Data Studio'da veri kümelerinde gezinmeyi, şema ve tablo verilerini görüntülemeyi, basit sorgular çalıştırmayı ve sonuçları görselleştirmeyi kolay buldu.
BigQuery'ye veri girişi hedefimiz, HDFS veya GCS veri kümelerinin tek tıklamayla sorunsuz şekilde yüklenmesini sağlamaktı. düşündük (Airflow tarafından yönetiliyor) ancak Etki Alanı Kısıtlı Paylaşım güvenlik modelimiz nedeniyle kullanamadık (bununla ilgili daha fazla bilgiyi aşağıdaki Veri Yönetimi bölümünde bulabilirsiniz). BigQuery iş yüklerini düzenlemek için Google Veri Aktarım Hizmeti'ni (DTS) kullanmayı denedik. DTS'nin kurulumu hızlı olmasına rağmen bağımlılıklara sahip işlem hatları oluşturmak için esnek değildi. Alfa sürümümüz için GCE'de kendi Apache Airflow çerçevemizi oluşturduk ve onu üretimde çalışmaya ve Vertica gibi daha fazla veri kaynağını destekleyebilmeye hazırlıyoruz.
Verileri BigQuery'ye dönüştürmek için kullanıcılar, planlanmış sorguları kullanarak basit SQL veri ardışık düzenleri oluşturur. Bağımlılıklara sahip karmaşık çok aşamalı işlem hatları için kendi Airflow çerçevemizi veya Cloud Composer'ı aşağıdakilerle birlikte kullanmayı planlıyoruz: .
Proizvoditelnost
BigQuery, büyük miktarda veriyi işleyen genel amaçlı SQL sorguları için tasarlanmıştır. İşlemsel bir veritabanının gerektirdiği düşük gecikme süreli, yüksek verimli sorgulara veya uygulanan düşük gecikme süreli zaman serisi analizine yönelik değildir. . Etkileşimli analitik sorguları için kullanıcılarımız bir dakikadan kısa yanıt süreleri beklemektedir. BigQuery kullanımımızı bu beklentileri karşılayacak şekilde tasarlamamız gerekiyordu. Kullanıcılarımıza öngörülebilir performans sağlamak amacıyla, proje sahiplerinin sorguları için minimum alan ayırmasına olanak tanıyan, müşterilerin sabit ücret esasına göre kullanımına sunulan BigQuery işlevinden yararlandık. BigQuery, SQL sorgularını yürütmek için gereken bilgi işlem gücü birimidir.
Her biri yaklaşık 800 TB veri işleyen 1'den fazla sorguyu analiz ettik ve ortalama yürütme süresinin 30 saniye olduğunu gördük. Ayrıca performansın büyük ölçüde slotumuzun farklı proje ve görevlerde kullanılmasına bağlı olduğunu da öğrendik. Üretim kullanım senaryoları ve çevrimiçi analiz performansını korumak için üretim ve geçici slot rezervlerimizi net bir şekilde tanımlamamız gerekiyordu. Bu, slot rezervasyonları ve proje hiyerarşisi tasarımımızı büyük ölçüde etkiledi.
Önümüzdeki günlerde çevirinin ikinci bölümünde veri yönetimi, işlevsellik ve sistemlerin maliyetinden bahsedeceğiz ama şimdi herkesi davet ediyoruz. Bu süre zarfında kurs hakkında ayrıntılı bilgi edinebilecek ve uzmanımız Egor Mateshuk'a (Kıdemli Veri Mühendisi, MaximaTelecom) sorular sorabileceksiniz.
Daha fazla oku:
Kaynak: habr.com