Ele.me Büyük Veri Hesaplama Motoru Uygulaması ve Uygulaması
Özet: Ele.me BDI-Big Data Platform Ar-Ge ekibinin şu anda, esas olarak çevrimdışı gerçek zamanlı Infra ve platform aracı geliştirmeden sorumlu yaklaşık 20 çalışanı vardır. 6 kişilik çevrimdışı ekibin büyük veri kümesi ölçeğini şu şekilde sürdürmesi gerekir: Hadoop küme boyutu 1300+ HDFS stok verisi 40 + PB, Okuma 3,5 PB + / gün, Yazma 500 TB + / gün 14 W MR İş / gün, 10 W Spark İş / gün, 25 W Presto / Gün Ek olarak, şirketin her gün 400'den fazla büyük veri kümesi kullanıcısının karşılaştığı çeşitli sorunları çözmek için Hadoop, Spark, Hive, Presto ve Ele.me'nin diğer bileşenlerinin dahili sürümlerinin bakımı gereklidir.
Ele.me BDI-Big Data Platform Ar-Ge ekibinin şu anda, esas olarak çevrimdışı gerçek zamanlı Infra ve platform aracı geliştirmeden sorumlu yaklaşık 20 çalışanı vardır. 6 kişilik çevrimdışı ekibin büyük veri kümesinin ölçeğini aşağıdaki gibi koruması gerekir:
Hadoop küme boyutu 1300+
HDFS depolama verileri 40 + PB, 3,5 PB + / gün Okuma, 500TB + / gün yazma
14 W MR İşi / gün, 10 W Kıvılcım İşi / gün, 25 W Presto / gün
Ek olarak, şirketin her gün 400'den fazla büyük veri kümesi kullanıcısının karşılaştığı çeşitli sorunları çözmek için Hadoop, Spark, Hive, Presto vb. Bileşenlerin dahili sürümlerini korumak da gereklidir.
Bu makale esas olarak Ele.me büyük veri ekibinin bilgi işlem motoru girişini birleştirerek kullanıcı erişimi eşiğini nasıl düşürdüğünü açıklamaktadır. Kullanıcıların görev istisnalarını ve başarısızlık nedenlerini kendi kendilerine analiz etmelerine ve kümenin kendisi tarafından oluşturulan görev verilerinden küme bilgi işlem / depolama kaynak tüketiminin, küme durumunun ve anormal görevlerin nasıl izlenmesine izin verilir.
Birleşik motor girişi
Şu anda Ele.me, esas olarak Presto, Hive ve Spark dahil olmak üzere sorgu motorları sağlamaktadır. Spark'ın iki modu vardır: SparkThrift Server ve Spark SQL. Kylin de sürekli deneme aşamasındadır ve Druid de araştırılmaktadır. Çeşitli bilgi işlem motorlarının kendi avantajları ve dezavantajları vardır ve uygulanabilir hesaplama senaryoları farklıdır.
Kullanıcının bakış açısından, sıradan kullanıcılar güçlü bir tanıma yeteneğine sahip değildir ve öğrenme maliyeti nispeten yüksek olacaktır. Ve kullanıcı görevi yerine getirmek için motoru seçebildiğinde, kaçınılmaz olarak motor tıkanmasına neden olacak veya belirli bir motora tamamen uygun olmayan görevler gönderecek ve böylece görevin başarı oranını azaltacak olan en hızlı motora öncelik verecektir.
Yönetim açısından bakıldığında, bir büyük veri kümesi için çok fazla giriş vardır ve bu da kümenin birleşik yönetimini, yük dengelemesini, erişim denetimini ve kümenin genel dış hizmet yeteneklerini kontrol etmeyi zorlaştıracaktır. Ve erişilmesi gereken yeni bilgi işlem gereksinimleri olduğunda, bunun için ilgili istemci ortamını da dağıtmamız gerekir.
Bu duruma yanıt olarak, Ele.me büyük veri ekibi Dispatcher'ı geliştirdi. Bu bileşenin temel işlevleri aşağıdaki şekilde gösterilmektedir:
Tüm kullanıcı görevleri Dispatcher aracılığıyla gönderilir Dispatcher'da, birleşik kimlik doğrulama ve birleşik görev yürütme izleme gerçekleştirebiliriz. Ayrıca, yürütme motorlarının otomatik yönlendirmesini, her yürütme motorunun yük kontrolünü gerçekleştirebilir ve motorun bozulması yoluyla görev operasyonunun başarı oranını artırabilir.
Mantıksal mimari
Dispatcher'ın mantıksal mimarisi aşağıda gösterilmiştir:
Şu anda, kullanıcılar Dispatcher hizmetini JDBC modunda arayabilir veya Dispatcher'ı doğrudan Sürücü modunda çalıştırabilir. Dispatcher sorgu isteğini aldıktan sonra, sorguyu ilgili motora göndermek için kimlik doğrulama ve motor yönlendirme gibi işlemleri gerçekleştirir. Dispatcher ayrıca bir SQL dönüştürme modülüne de sahiptir.Presto motorundan Spark / Hive motoruna düşürürken, bu modül üzerinden Presto SQL'i otomatik olarak HiveQL'e dönüştürecektir.
Dispatcher aracılığıyla sorgu girişini birleştirmenin faydaları aşağıdaki gibidir:
Kullanıcı erişim eşiği düşüktür, her motorun nasıl kullanılacağını öğrenmeye gerek yoktur ve avantajları ve dezavantajları, yürütme motorunu manuel olarak seçmeye gerek yoktur;
Dağıtım maliyeti düşüktür ve istemciye JDBC aracılığıyla hızlı bir şekilde erişilebilir;
Birleşik kimlik doğrulama ve izleme;
Görev başarı oranını artırmak için modülü eski sürüme geçirin;
Her motorun yük dengesi;
Motor genişletilebilir.
Motor ölçeklenebilirliği temel olarak, Kylin, Druid veya diğer sorgu motorları sonradan bağlandığında, kullanıcıların bundan habersiz olabileceği anlamına gelir. Kümeye gönderilen tüm sorgular toplandığından, mevcut her bir sorgu planı için popülerlik verilerini alabilir, tüm sorgularda en çok hangi tabloların kullanıldığını, hangi tabloların sık sık sorgularla ilişkilendirildiğini ve hangi alanların sıklıkla toplama yoluyla sorgulandığını öğrenebiliriz. , Kylin sonradan bağlandığında, Küp bu veriler aracılığıyla hızla oluşturulabilir veya optimize edilebilir.
SQL portresi
Dispatcher'ın özü, SQL profil modülüdür. Temel süreç aşağıdaki gibidir:
Sorgu gönderildikten sonra, sorgu planını analiz etmek için HiveServer'a bağlanarak, geçerli sorgunun tüm meta veri bilgileri aşağıdaki gibi elde edilebilir:
Okunan veri miktarı
Okunan tablo / bölüm sayısı
Çeşitli katılma süreleri
Kaç tane ilişkili alan
Toplama karmaşıklığı
Filtre koşulu
...
Yukarıdaki meta veri bilgileri, temel olarak her bir sorguyu doğru bir şekilde tanımlayabilir ve her sorgu, bu boyutların istatistiksel bilgileri aracılığıyla farklı motorlara gönderilebilir.
Hive, SQL'i ayrıştırıp mantıksal yürütme planını optimize ettikten sonra, açıklama komutu ile görüntülenebilen optimize edilmiş bir Operatör Ağacı elde edilecektir. SQL profil verileri, aşağıdaki şekilde gösterildiği gibi bu sonuçtan çeşitli farklı Operatör işlemlerini toplayabilir:
Sezgisel bir anlayışla, okunan veri miktarının motor seçimi için çok önemli olduğunu biliyoruz. Örneğin, az miktarda veri okunduğunda, Presto en iyi performansı gösterir, büyük miktarda veri okunduğunda, Hive en kararlı olanıdır ve orta miktarda veri okunduğunda, Spark tarafından çalıştırılabilir.
İlk aşamada, veri miktarını okuyarak, Birleştirme karmaşıklığını, toplama karmaşıklığını ve diğer faktörleri birleştirerek ve kurallara dayalı yönlendirmeyi birleştirerek çeşitli bilgi işlem motorlarında da test edebilirsiniz. Yürütme sırasında, SQL profil verilerini, yürütme motorunu, sürüm düşürme bağlantısını ve her sorgunun diğer verilerini kaydedin. Bu profil verilerine dayanarak, motorun akıllı yönlendirmesini uygulamak için karar ağaçları, lojistik regresyon ve SVM gibi sınıflandırma algoritmaları kullanılabilir.Şu anda, Ele.me büyük veri ekibi bu konuda çoktan bir girişim başlattı.
Şu anda, Ele.me uygulamasında, Dispatcher tarafından tek tip olarak planlanan Ad Hoc sorgusu, ön kontrol bağlantısının eklenmesi ve başarısız olan düşürme bağlantısı nedeniyle, günlük genel başarı oranı% 99.95'in üzerindedir ve genel PT90 değeri yaklaşık 300 saniyedir. Şu anda Presto, Ad Hoc sorgu trafiğinin% 50'sini ve SparkServer modeli trafiğin% 40'ını taşır.
Küme verilerinden tam olarak yararlanın
Ele.me büyük veri kümesi her gün 25W + SparkMR görevlerini çalıştırır.Bu veriler, her Eşleyici / İndirgeyici veya Kıvılcım Görevinin çalışma durumunu kaydeder.Tamamen kullanılabilirse, çok büyük bir değer üretecektir. Kümenin kendi verilerinden tam olarak yararlanın ve veriler kümenin yapısını yönlendirir. Bu veriler yalnızca küme yöneticilerinin bilgi işlem kaynaklarını, depolama kaynak tüketimini, görev performansı analizini ve kümenin kendisinin ana bilgisayar işletim durumunu izlemesine yardımcı olamaz. Ayrıca, kullanıcıların görev başarısızlıklarının nedenlerini ve görev performansı analizini analiz etmelerine yardımcı olabilir.
Ele.me büyük veri ekibi tarafından geliştirilen Grace projesi bunun bir örneğidir.
Grace kullanım senaryoları
Küme görevi işlem durumunun ayrıntılı verilerini net bir şekilde anlamadıysanız, bir sorun oluştuğunda başınızı belaya sokmak kolaydır ve küme anormal olduktan sonra sorunu hızlı bir şekilde bulmaya devam edemezsiniz.
Kullanıcılar size sık sık sorduğunda, görevim neden başarısız oldu? Görevim neden bu kadar yavaş? Görevimin önceliğini ayarlayabilir miyim? Bana günlüğü okumamı söyleme, anlamıyorum. Sanırım herkesin kalbi kırıldı.
İzleme anormal Ad Düğümü titreşimi, yüksek ağ hızı, artan blok oluşturma ve artan blok oluşturma gecikmesi gibi alarmlar oluşturduğunda kümede çalışan anormal görev nasıl hızlı bir şekilde bulunur?
İzleme kümesinde çok fazla bekleyen görev olduğunda ve kullanıcılar görevlerin geniş bir alanda ertelendiğini bildirdiğinde, sorunun temel nedenini hızlı bir şekilde nasıl bulabilirim?
Kullanıcılar bilgi işlem kaynakları için başvurduklarında, kendilerine kaç kaynak tahsis edilmelidir? Bir kullanıcı bir görevin önceliğini artırmak için başvurduğunda, veriler konuşmak için nasıl kullanılır ve öncelik ne kadar ayarlanmalıdır? Kullanıcılar yalnızca çevrimiçi görevlerle ilgilendiğinde, artık ihtiyaç duyulmayan görevleri nasıl buluruz?
Ayrıca, her BU'nun bilgi işlem kaynağı tüketiminin gerçek zamanlı olarak nasıl görüntüleneceği ve BU kaynaklarının oranını hesaplayan BU'daki her bir kullanıcının hesaplama kaynağı tüketiminin nasıl belirtileceği. Ve her bir BU'nun görev sayısının, kaynak kullanım oranının, BU'daki her bir kullanıcının kaynak tüketiminin ve geçmiş verilerden her bir görevin kaynak tüketiminin nasıl analiz edileceği.
Aşağıdaki örnekler, Grace tarafından üretilen bazı veri grafiklerini göstermektedir. BU, kullanıcı ve görev seviyesi ile ilgili verilerin görüntülenmesi uygun değildir.
1) İzleme kuyruğu
Aşağıdaki şekilden, her kuyruğun maksimum ve minimum kaynaklarını, şu anda kullanılan kaynakları, şu anda çalışan görevlerin sayısını, bekleyen görevlerin sayısını ve kaynak kullanım oranını kolayca görebilirsiniz.Ayrıca, bu verilerin geçmiş eğilimini de görebilirsiniz.
2) Görev izleme
Görev türünü, başlangıç zamanını, çalışma süresini, tüketilen mevcut kuyruk kaynaklarının oranını ve belirtilen kuyrukta tüketilen mevcut BU kaynaklarının oranını görüntüleyebilirsiniz. Çok fazla bilgi işlem kaynağı tüketen ve uzun süre çalışan görevleri hızla bulabilir ve kuyruk engellemesinin nedenini hızla bulabilir.
3) Ana bilgisayar arıza oranını izleme
Kümedeki tüm ana bilgisayarlarda görev yürütme başarısızlık oranını izleyebilir. Mevcut izleme sistemi, ana bilgisayarın CPU'sunu, diskini, belleğini, ağını ve diğer donanım koşullarını izler. Bu donanım arızalarının en sezgisel tezahürü, bu sorunlu ana bilgisayarlara atanan görevlerin yavaş yürütülmesi veya yürütülmesidir. Çalışmakta olan görev en hassas yanıttır.Belirli bir ana bilgisayarın arıza oranının çok yüksek olduğunu tespit ettiğinde, işletmenin normal şekilde yürütülmesini sağlamak için hızlı ve otomatik bir çevrimdışını tetikleyebilir. Daha sonra, ana bilgisayar anormalliğinin nedeni, donanım izleme ile birlikte bulunabilir.
4) Görev performans analizi
Kullanıcılar kendi başlarına görev performans analizi yapabilirler.
Ve anormal maddelere göre aşağıdaki önerilere göre ayarlanabilir.
5) Görev başarısızlığının nedenlerinin analizi
Başarısız görevler için, kullanıcılar ayrıca planlama sisteminden arızanın nedenini ve ilgili çözümleri aşağıdaki yöntemlere göre hızlı bir şekilde görüntüleyebilirler Ele.me Büyük Veri ekibi, çeşitli tipik hata bilgilerini ve güncellemeleri düzenli olarak toplar ve self servis analiz bilgi tabanını korur.
Ek olarak, her görevin bilgi işlem kaynağı tüketimini GB Saatlerini gerçek zamanlı olarak, okunan ve yazılan toplam veri miktarını ve Shuffle verisi miktarını da izleyebiliriz. Ve çalışan görevlerin HDFS veri okuma ve yazma miktarı, HDFS işlenenleri vb.
Küme bilgi işlem kaynakları yetersiz olduğunda, daha fazla bilgi işlem kaynağı tüketen görevler hızlı bir şekilde bulunabilir. HDFS küme seğirmesi, okuma ve yazma zaman aşımları, vb. Gibi anormallikleri izlerken, anormal görevler de bu veriler aracılığıyla hızlı bir şekilde bulunabilir.
Bu verilere dayanarak, her kuyruğun kaynak tahsis oranını her kuyruğun görev hacmine ve kaynak tüketimini çalıştıran görev süresine göre makul şekilde optimize etmek de mümkündür.
Bu görev çalıştırma durum verilerine dayalı olarak görev profili oluşturun, görev kaynağı tüketim eğilimlerini izleyin ve görevin anormal olup olmadığını belirleyin. Görev çıktı verilerinin erişim ısısıyla birleştirildiğinde, görev önceliğini dinamik olarak ayarlamak için planlama sistemine geri beslenebilir, vb.
Grace mimarisi
Yukarıdaki örnekte kullanılan veriler Grace aracılığıyla toplanmıştır. Grace, Ele.me büyük veri ekibi tarafından geliştirilen bir uygulamadır. Esas olarak çevrimiçi MR / Spark görev çalıştıran verilerini izlemek ve analiz etmek, çalışan kuyrukları ve görev ayrıntılarını izlemek ve verileri özetlemek için kullanılır. Mantıksal yapı aşağıdaki gibidir:
Grace, Spark Streaming aracılığıyla uygulanır.Kafka'da depolanan tamamlanmış MR görevinin jhist dosyasını veya Spark görevinin olay günlüğü yolunu tüketerek, görev çalıştırma geçmişi verileri HDFS'nin karşılık gelen konumundan elde edilir ve MR / Spark görevinin ayrıntılı verileri ayrıştırıldıktan sonra elde edilir. Ardından, görev seviyesi, iş seviyesi ve aşama seviyesi hakkında özet bilgi elde etmek için bu verilere dayalı belirli bir toplu analiz gerçekleştirin. Son olarak, özelleştirilmiş Dr-Elephant sistemi, kullanıcılara bazı sezgisel optimizasyon ipuçları vermek için sezgisel algoritmalar aracılığıyla görev ayrıntılarını analiz etmek için kullanılır.
Dr-Elephant için, Grace sisteminin bir bileşeni olarak paketlemek gibi özelleştirilmiş değişiklikler de yaptık. Bağımsız bir dağıtım hizmeti modelinden dağıtılmış gerçek zamanlı analiz modeline. Veri kaynağını Grace tarafından ayrıştırılan görev ayrıntı verilerine geçirin. Her görev için ActionId izleme bağlantı bilgilerini artırın, Spark görev ayrıştırma mantığını optimize edin, yeni sezgisel algoritmalar ve yeni izleme göstergeleri vb. Ekleyin.
sonuç olarak
Büyük veri ekosistemi gittikçe daha eksiksiz hale geldikçe, farklı geçmişlere sahip daha fazla kullanıcı ekosisteme katılacak.Kullanıcıların büyük veri kaynaklarını hızlı ve rahat bir şekilde kullanabilmeleri için kullanıcıların giriş engellerini nasıl azaltabiliriz de dikkate alınması gereken konulardır.
Büyük veri kümesinde çalışan görevlerin çoğu işle ilgilidir, ancak kümenin ölçeği büyüdükçe, kümenin kendisi tarafından üretilen veriler göz ardı edilemez. Verinin bu bölümü gerçekten kümenin ayrıntılı kullanımını yansıtıyor Verinin bu bölümünü nasıl toplayıp kullanacağımızı düşünmemiz ve kümelerimizi ve görevlerimizi veri perspektifinden ölçmemiz ve gözlemlememiz gerekiyor.
Kümenin genel dağıtımına, performansına ve kararlılığına odaklanmak yeterli değildir.Kullanıcı deneyiminin nasıl iyileştirileceği, kümenin kendi verilerinin tam olarak nasıl çıkarılacağı ve verilerin büyük veri kümesinin inşasını desteklemek için nasıl kullanılacağı bu paylaşımın temasıdır.
Q ve A
S: Planlama sistemini kısaca tanıtır mısınız? On binlerce görevi yönetmek kolay değil.
A: Zamanlama sistemi oldukça karmaşıktır. Sadece birkaç anahtar noktadan bahsedin: Biri görevler arasındaki bağımlılık, diğeri kan ilişkisi, diğeri ise görevler ve örnekler, küme geri tepme basıncı, dağıtılmış zamanlama ve temel ortamın birleştirilmesidir.
Kan ilişkisi gerekli olmalıdır, çünkü kümeniz büyük olduğunda kullanıcılar görevleri yapılandırırken bağımlılıkları tamamen ekleyemezler.
Kan sistemi aracılığıyla görev analiz edilir.Kullanıcı yeni bir görevi yapılandırdığında, görevin düzenli çalışmasını sağlamak için ön bağımlılık otomatik olarak önerilir.
S: Kümenin günlük okuma ve yazma ölçeği nasıl alınır? Hadoop'un arayüzleri var mı?
A: Kümenin okuma-yazma ölçeği, daha önce açıklanan Grace tarafından toplanmıştır. Çünkü her mr görevinin veya kıvılcım görevinin HDFS verilerini okuma ve yazma hacmini analiz edeceğiz. Ayrıca, diske dökülen veri miktarını, karışık yazma miktarını, okumayı karıştırmayı ve her görev için GBHour bilgilerini içerir.
Aslında, bu verileri YARN veya Spark'ın WEB UI sayfasından görebilirsiniz.Tek yapmanız gereken, verileri gerçek zamanlı olarak analiz etmek ve toplamak. Bu aynı zamanda bu paylaşım girişinde, kümelerin veri perspektifinden çalıştırılması ve bakımının yapılmasında da bahsedilmektedir.
İş verilerine ek olarak, kümenin kendisi tarafından üretilen veriler de çok değerlidir.
S: Bu, büyük verinin kendisinin ürettiği verilerden işletim ve bakım kümesini iyileştirmek mi?
A: Evet. Veri mimarisi yönünde de uğraşıyorsanız, günlük işlerinizi hatırlayabilirsiniz. İnsan eti analizini otomasyona dönüştürdük ve biraz gerçek zamanlı ekledik.
Transfer: https://yq.aliyun.com/articles/597512?utm_content=m_51065
Bir sorun varsa, lütfen silmek için yazarla iletişime geçin
