- kedy0
- Katılım
- 14 Eyl 2021
- Mesajlar
- 379
- Tepkime puanı
- 322
- Şehir
- İstanbul
Discord'da Veri Platformu ekibi, Discord'un herkesin ait olduğu yeri bulması için alan yaratmasına yardımcı olmak için kuruluşa verileri analiz etme, anlama ve kullanma yetkisi verir. Kuruluşun her bölümü verileri kullanır: kötü aktörleri ve zararlı toplulukları belirlemek için; kritik ürün ve strateji kararlarını bildiren içgörüler elde etmek; ve makine öğrenimi modellerinin etkinliğini eğitmek ve değerlendirmek. Ham ürün etkileşim verilerinin düzenli ve titiz analizi olmadan, şirket stratejisi hakkında geniş ölçekte bilinçli kararlar verme yeteneğimiz ciddi şekilde eksik olacaktır.
Ham veriler bize üretim veri deposu ihracatı ve ürün telemetri verileri olarak gelir (şu ana kadar 15 trilyondan fazla kayıt ve günlük milyarlarca kayıt). Discord daha küçük bir şirketken ve veri kullanım durumları daha basitken, ideal olmasa da, doğrudan ham verilerden çalışmak veya gerektiğinde bazı yararlı veri kümelerini manuel olarak önceden hesaplamak biraz makuldü. Bugün, bulutta 30.000 vCPU ile petabaytlarca veriyi saatte bir işliyoruz. Kullanışlı olması için ham verilerin temizlenmesi, anonimleştirilmesi ve ardından 30'dan fazla petabaytlık veri ambarımızda (Google BigQuery kullanıyoruz) önceden hesaplanmış binlerce tablodan oluşan karmaşık bir şemaya dönüştürülmesi gerekir.
Bu yazı itibariyle, Veri Platformu ekibinin ham verileri almaktan ve erişilebilir kılmaktan sorumlu kısmı sekiz kişiden oluşuyor ve aşağıda açıklanan tarih boyunca sayımız daha da azdı. Takımın Discord'un geri kalanına göre büyüklüğü göz önüne alındığında, kendi kendine hizmet eden ve mümkün olduğunca otomatik olan bir sistem oluşturmak önemliydi. Bu, petabaytlarca ham veriyi yapılandırılmış bir veri ambarına nasıl dönüştürdüğümüzün ve bunu sürdürmek için inşa ettiğimiz ve dahili olarak Derived olarak anılan sistemimizin hikayesidir.
Gereksinimler ve Yaklaşım
İhtiyacımız olan şey, önceden hesaplanmış verilerden oluşan karmaşık bir Yönlendirilmiş Döngüsel Grafiği (DAG) sürdürmek için bir sistemdi. Bizim durumumuzda bu, BigQuery veri ambarımızdaki türetilmiş tablolardan oluşan bir DAG anlamına geliyordu:
- Türetilmiş bir tablo, esas olarak, girdi bağımlılıkları olarak DAG'da öncül tablolara sahip olabilen bir veri dönüşümünü temsil eder: başka bir deyişle, türetilmiş bir tablo tanımı, ham verilere veya diğer türetilmiş tablolara başvuran bir SQL SELECT ifadesi olarak düşünülebilir.
- DAG'ın yukarıdan aşağıya aktığını varsayarsak, DAG'ın en üstünde ham veri kaynakları ve arama tablolarının olacağı düşünülebilir; ortada, yeniden kullanılabilir "altın" çekirdek veri tablolarının bir çekirdek seti, ör. platformlar vb. arasında normalleştirilmiş günlük kayıtlar; ve DAG'ın alt kısmına doğru, doğrudan analizde, BI araçlarında veya makine öğrenimi modellerinde tüketilmesi amaçlanan tablolar.
- DAG binlerce tablo içerebilir, bu nedenle ölçeklenmesi gerekir.
Sistem bir dizi teslim edilebilir dönüm noktasına bölünecek olsa da, nihai sistemin aşağıdaki gereksinimleri karşılamasını istedik:
1- Tablo güncellemeleri, yeni veriler mevcut olur olmaz (ancak daha erken değil!)
2- Her tablo için mutasyonların denetim izini sürdürmek.
3- Veri kökenini ve bir veri kataloğunu güçlendirmek için temel öğeler dahil.
4- Tablolarda yapılan değişiklikler, mühendislik, veri bilimi ve makine öğrenimi gibi paydaş ekipler için self servis ve sezgisel olmalıdır.
5- Veri erişim kontrollerinin farkındalığı ve ölçeklenebilir gizlilik politikası uygulaması sağlar.
6- Discord'un kullanıcıya yönelik ürününde kullanılmak üzere türetilmiş verileri üretim veri depolarına otomatik olarak aktarabilme.
7- Discord'un altyapı ortamı bağlamında kullanımı basit ve kolaydır.
dbt, Airflow ve Looker gibi mevcut çözümler yukarıdakilerin bazılarını çözerken, nihayetinde, veri gizliliği/erişimi konusunda sistemlerimizle güzel bir şekilde bütünleşecek ve bize kullanım durumlarını genişletme esnekliği verecek daha özel bir çözüm istediğimize karar verdik. analizlerin ötesinde.
Toplu işleri planlamak ve daha basit veri kümelerini işlemek için zaten Airflow kullanıyorduk, ancak aşağıdaki sınırlamaları bulduk:
1- Yazma işleri karmaşıktı ve kullanıcının Python, SQL ve Airflow hakkında derin bir anlayışa sahip olmasını gerektiriyordu. Bu, DAG değişikliklerinin self servis olması şartımızı ihlal etti.
2- Farklı zamanlamalarda birbirine bağlı olan zamanlama sorguları hakkında akıl yürütmek zordu (örneğin, haftalık olarak zamanlanan bir tablonun ne zaman güncelleneceğini ve aylık olarak güncellenen bir tablodan okunan bir tablonun ne zaman güncelleneceğini bilmek?).
3- Tablo yapınızı bağımlılık grafiğinde tam olarak nereye ekleyeceğinizi bilmek ve bunun diğer tablolar üzerindeki etkisini anlamak kolay değildi (örneğin, sahip olduğunuz tabloların ne zaman doldurulması gerektiğini bilmek, çünkü başka bir ekibin sahip olduğu önceki veri kümeleri eksik, bozuk veriler getirdi veya veriler içeriyordu). değişiklikler).
4-Mevcut bir tabloya veri ekleyen veya verileri birleştiren artımlı veri yapıları için mantık yazmak, özellikle tüm olası yeniden oluşturma ve doldurma koşullarını hesaba katarken, hataya açıktı ve kopya makarnaydı.
Gereksinimlerimizi göz önünde bulundurarak, mevcut sorunlu noktaları gözlemleyerek ve mevcut çözümlerden ilham alarak aşağıdaki tasarım seçimlerini yaptık:
1- Kullanıcıların türetilmiş tabloları tanımlamak için yalnızca SQL bilmesi gerekir.
2- Kullanıcıların DAG'ın belirli yapısı hakkında bilgi sahibi olmalarına gerek yoktur: sistem DAG'yi SQL içinden çıkaracaktır.
3- Eksiksiz bir değişiklik geçmişi ve mevcut üretim konfigürasyonlarının kolay aranması için her şey git'te olmalıdır.
4- Sistem, veri işlemeyi mevcut veri anonimleştirme sistemlerimizle entegre etmelidir.
5- Meta veri geçmişi ve her tablonun mevcut durumu, izleme, köken ve performans araçları oluşturmak için erişilebilir bir biçimde saklanmalıdır.
6- Veri onarım işlemleri (dolgular) kolay olmalı ve verilerin tüm veri ambarı genelinde tutarlı olmasını sağlamalıdır.
1- Tablo güncellemeleri, yeni veriler mevcut olur olmaz (ancak daha erken değil!)
2- Her tablo için mutasyonların denetim izini sürdürmek.
3- Veri kökenini ve bir veri kataloğunu güçlendirmek için temel öğeler dahil.
4- Tablolarda yapılan değişiklikler, mühendislik, veri bilimi ve makine öğrenimi gibi paydaş ekipler için self servis ve sezgisel olmalıdır.
5- Veri erişim kontrollerinin farkındalığı ve ölçeklenebilir gizlilik politikası uygulaması sağlar.
6- Discord'un kullanıcıya yönelik ürününde kullanılmak üzere türetilmiş verileri üretim veri depolarına otomatik olarak aktarabilme.
7- Discord'un altyapı ortamı bağlamında kullanımı basit ve kolaydır.
dbt, Airflow ve Looker gibi mevcut çözümler yukarıdakilerin bazılarını çözerken, nihayetinde, veri gizliliği/erişimi konusunda sistemlerimizle güzel bir şekilde bütünleşecek ve bize kullanım durumlarını genişletme esnekliği verecek daha özel bir çözüm istediğimize karar verdik. analizlerin ötesinde.
Toplu işleri planlamak ve daha basit veri kümelerini işlemek için zaten Airflow kullanıyorduk, ancak aşağıdaki sınırlamaları bulduk:
1- Yazma işleri karmaşıktı ve kullanıcının Python, SQL ve Airflow hakkında derin bir anlayışa sahip olmasını gerektiriyordu. Bu, DAG değişikliklerinin self servis olması şartımızı ihlal etti.
2- Farklı zamanlamalarda birbirine bağlı olan zamanlama sorguları hakkında akıl yürütmek zordu (örneğin, haftalık olarak zamanlanan bir tablonun ne zaman güncelleneceğini ve aylık olarak güncellenen bir tablodan okunan bir tablonun ne zaman güncelleneceğini bilmek?).
3- Tablo yapınızı bağımlılık grafiğinde tam olarak nereye ekleyeceğinizi bilmek ve bunun diğer tablolar üzerindeki etkisini anlamak kolay değildi (örneğin, sahip olduğunuz tabloların ne zaman doldurulması gerektiğini bilmek, çünkü başka bir ekibin sahip olduğu önceki veri kümeleri eksik, bozuk veriler getirdi veya veriler içeriyordu). değişiklikler).
4-Mevcut bir tabloya veri ekleyen veya verileri birleştiren artımlı veri yapıları için mantık yazmak, özellikle tüm olası yeniden oluşturma ve doldurma koşullarını hesaba katarken, hataya açıktı ve kopya makarnaydı.
Gereksinimlerimizi göz önünde bulundurarak, mevcut sorunlu noktaları gözlemleyerek ve mevcut çözümlerden ilham alarak aşağıdaki tasarım seçimlerini yaptık:
1- Kullanıcıların türetilmiş tabloları tanımlamak için yalnızca SQL bilmesi gerekir.
2- Kullanıcıların DAG'ın belirli yapısı hakkında bilgi sahibi olmalarına gerek yoktur: sistem DAG'yi SQL içinden çıkaracaktır.
3- Eksiksiz bir değişiklik geçmişi ve mevcut üretim konfigürasyonlarının kolay aranması için her şey git'te olmalıdır.
4- Sistem, veri işlemeyi mevcut veri anonimleştirme sistemlerimizle entegre etmelidir.
5- Meta veri geçmişi ve her tablonun mevcut durumu, izleme, köken ve performans araçları oluşturmak için erişilebilir bir biçimde saklanmalıdır.
6- Veri onarım işlemleri (dolgular) kolay olmalı ve verilerin tüm veri ambarı genelinde tutarlı olmasını sağlamalıdır.
Birinci Versiyon: Uygulanabilir Asgari Ürün
İlk teslimat için en yüksek öncelikli hedefler, veri dönüşümlerini git'e dönüştürmek, verilerin ambar genelinde tutarlı olmasını sağlamak ve veri işlemlerini basitleştirmekti. Aşağıdakileri oluşturduk:
Türetilmiş tablolar, Jinja şablonlama biçimindeki dosyalar kullanılarak SQL tarafından tanımlanır. Her tablo kendi dosyasında yapılandırılır ve git'te saklanır.
Çerçeve, tablo yapılandırmalarına dayalı olarak bağımlılıkların DAG'sini oluşturacak ve veri ambarını oluşturacak ve işlerin planlanması, görselleştirme ve izleme için Airflow'tan yararlanacaktır.
Tabloları doğru bir şekilde yeniden oluşturmak ve doldurmak için temel bir komut satırı aracı oluştururduk.
MVP'nin kapsamını yönetmek için, karmaşık bağımlılık çözümleme mantığından kaçınmak için tabloları güncelleme planına göre (örneğin saatlik, günlük, haftalık veya aylık) gruplandırmaya karar verdik. Buradaki ödün, tabloları farklı güncelleme programlarıyla kolayca karıştıramamamızdı.
Üç farklı stratejiden biri kullanılarak belirtilen tablo oluşturma davranışı, tabloların nasıl oluşturulduğu, artırıldığı ve doldurulduğu konusunda talimat verir:
Değiştir: tüm tabloyu düzenli bir programla değiştirin.
Ekle: düzenli bir programa göre bir tabloya aşamalı olarak veri ekleyin.
Birleştir: gelen verileri, yapılandırılmış kriterlere göre mevcut verilerle birleştirin. Bu strateji öncelikle, "bir kullanıcının ilk mesaj gönderdiği zaman" veya "bir kullanıcının bir Discord topluluk sunucusuna en son katıldığı zaman" gibi kullanıcı özelliklerini bölümlere ayırmak istediğimiz kohort analizini destekleyen tablolarla kullanılır.
Böylece Derived doğdu ve aşağıda gösterildiği gibi mimarimize uydu:
Sürüm İki: Kullanıcı Ergonomisi
MVP, DAG oluşturma, tablolar oluşturma ve veri ambarını yönetme teknolojisini kanıtladı, ancak şirket genelindeki insanlar, süreç hala çok karmaşık ve belirsiz olduğu için Veri Mühendislerinin yardımı olmadan yeni Türetilmiş Tablolar oluşturmak için mücadele etti. Bu nedenle, bir sonraki yineleme için, kullanıcıların kolayca yeni tablolar oluşturmaları ve doğrudan kodlarının yanında belgeler yazabilmeleri için basit bir kullanıcı arabirimi oluşturmaya odaklandık.
Özellikleri:
Kullanıcıların SQL yazmaya odaklanabilmeleri ve yalnızca tablonun ne sıklıkta çalışması gerektiğine ve üzerinde çalışması gereken veri penceresine (zaman aralığı) ilişkin birkaç özelliği öğrenmeleri için YAML formatı tanıtıldı.
Kullanıcının DAG'ın belirli yapısı ve bağımlılıkları hakkında bilgi sahibi olması gerekmemesi için herhangi bir zamanlama, pencere ve strateji kombinasyonuna sahip tablolar arasında etkinleştirilen bağımlılıklar.
Bu yineleme için kabul ettiğimiz bir sınırlama, tablo meta verilerinin hala Airflow'ta saklanıyor olması ve onarım işlemlerini yapmak için airflow dag'ı duraklatmamızı gerektirmesiydi. Ek olarak, yeniden oluşturmalardan sonra tablo durumunu hava akışı meta verileriyle senkronize etmek karmaşıktı.
Tablo tanımı ana dalla birleştirildiğinde, Derived tabloyu oluşturacak ve başlangıçta mevcut tüm verilerle dolduracaktır. Sonraki her çalıştırma için, mevcut tabloya bir saatlik veri ekler - BigQuery terimleriyle bir MERGE işlemi. Ayrıca, aşağıda görebileceğiniz gibi, tablo ve sütun tanımları için belgeler, tablo tanımıyla birlikte yaşar ve tablo işlevselliği ile dokümantasyon arasındaki kayma olasılığını en aza indirir.
| columns: | |
| - [user_id, INT64, NOT NULL, 'Pseudonymized user id with data governance policies applied'] | |
| - [timestamp, TIMESTAMP, NOT NULL, 'Time when the user most recently added a friend on Discord'] | |
| - [hour_pt, TIMESTAMP, NOT NULL, 'Descriptions are added to database schemas so they appear in the BigQuery UI'] | |
| description: 'The table description used in data discovery tooling and generated documentation' | |
| category: 'Category for organizing generated documentation' | |
| strategy: merge # Merge means to incrementally update or insert records into the table based on the merge_keys and merge_mode | |
| merge_keys: [user_id] # The table will have at most one record per user, if the user has no record then insert it otherwise update the existing record | |
| merge_mode: keep_newest # If the user already has a record in the table then update it with the most recent friend added | |
| merge_timestamp: timestamp # Determine the most recent friend added based on timestamp in the update_relationship event | |
| schedule: daily # Incrementally update this table once per day | |
| window: daily # Add one day of source data each run | |
| partition_by: hour_pt # Partition the BigQuery table by hour_pt | |
| cluster_by: [user_id] # Sort each partition by user_id | |
| timezone: pt # Timestamps are pacific timezone and daily aggregates are pacific timezone days | |
| dataset: user_cohorts # BigQuery dataset | |
| sql: | | |
| SELECT | |
| user_id, | |
| max(timestamp) as timestamp, | |
| TIMESTAMP_TRUNC(max(timestamp), HOUR) AS hour_pt, | |
| FROM events.update_relationship | |
| WHERE timestamp >= @start_day_utc # Derived injects timestamps based on data availability of predecessor dependencies | |
| AND timestamp < @end_day_utc # start_day_utc and end_day_utc are computed based on incremental, rebuild, and backfill operations | |
| AND type = 'add_friend' | |
| GROUP BY user_id |
Bu standartlaştırılmış arabirimi benimsemenin bir başka yararı da, kullanıcıları etkilemeden yapılandırmanın altında yatan sistemler üzerinde hızlı bir şekilde yineleme yapmamız için bir soyutlama katmanı sağlamasıdır.
Üçüncü Sürüm: Otomasyon
Sürüm İki, yardım almadan tablolar oluşturmak için Veri Bilimi ekiplerimizin kilidini başarıyla açtı ve ilk yıl içinde yüzlerce tablo oluşturdular. Bu başarı ile birlikte yeni bir dizi sorun ortaya çıktı:
Yeni tablolar oluşturmak kolaydı, ancak tabloları güncellemek için Veri Mühendisleri tarafından manuel adımlar gerekiyordu: DAG oluşturma/yeniden oluşturma işlemleri otomatik değildi ve mühendisler tarafından tetiklenmesi gerekiyordu. Bu bakım görevleri nispeten basit olsa da zaman aldı ve benimseme arttıkça daha sık gerçekleşti.
SQL hatası içeren tek bir tablo, tüm tabloların ilerlemesini engeller ve benimseme arttıkça hatalar daha sık hale gelir: Test takımları, oluşturulan SQL'in tüm kombinasyonlarını veya tablolar arasındaki bağımlılıkları kapsamlı bir şekilde test etmedi. En kötü yanı, verilerle ilgili yanlış varsayımlar nedeniyle hataların üretimde çalışana kadar sık sık ortaya çıkmaması ve Veri Mühendislerinin sık sık verileri doldurmasını ve tabloları onarmasını gerektirmesiydi.
Veri ambarı (BigQuery), kullanıcıya yönelik hizmetlerin milisaniye gecikme gereksinimleri için optimize edilmediğinden, uygulama özelliklerini güçlendirmek için Türetilmiş öngörüleri kullanmak zordu.
Bu nedenle Sürüm Üç, dağıtımların güvenilirliğini artırmaya ve Türetilmiş tabloların yeniden oluşturulmasını/onarımını otomatikleştirmeye odaklandı. Bunu başarmak için kullanıcı ergonomisine, teste ve genel otomasyona odaklandık:
Test yapmak:
Kullanıcıların yeni tablolar geliştirirken test edebilmelerini istedik, bu nedenle aşağıdakileri uyguladık:
Yerel geliştirme için kullanıcılar, gerçek tablo yapılandırmalarını yüklemek ve tüm DAG genelinde bağımlılıkları doğrulamak için bir komut satırı arabirimi (CLI) kullanabilir.
Kullanıcılar, tablo çıktısını doğrulamak için CLI'den gölge üretim verileri üzerinde tablolarının test sürümlerini de oluşturabilirler.
Bir çekme talebi oluşturulduktan sonra, sürekli entegrasyon (CI), kullanıcıların çekme talebini birleştirmeden önce değişikliklerini gerçek verilerle yeniden doğrulayabilmeleri için tüm yeni tabloları bir gölge üretim ortamına dağıtır.
Otomasyon:
Derived'in İkinci Sürümünde, tablonun meta verileri Airflow'ta izlendi ve veri bakım işlemleri sırasında bir dizi manuel adımla sonuçlandı (örneğin, DAG'yi duraklatmak, işlemi çalıştırmak ve ardından tablonun gerçek durumunu Airflow meta verileriyle senkronize etmek için gerekli bir dolgu ).
Veri işlemlerini otomatikleştirmek için, Derived'in ne zaman tamir edileceğine, yeniden oluşturulacağına ve tablolara veri ekleneceğine bağımsız olarak karar verebilmesi için tablo durumu izlemeyi Airflow'tan bir meta veri günlüğüne taşıdık. Örneğin, aylık bir tabloya bağlı olan saatlik bir tablo için verilerin onarılması gerekiyorsa (örneğin, topluluk kümeleri için aylık olarak belirlenen saatlik metrikler -- "oyun toplulukları bu ay nasıl gidiyor?"), Derived şunları yapacak kadar akıllıdır: sadece saatlik tabloyu yeniden oluşturun.
Tablo düzeyinde daha ayrıntılı durum izleme, paralel hesaplamaların kilidini de açar, böylece bir üst süreç 900'den fazla tabloyu sıralarken ve zamanlarken engellemez, tüm tablolar, türetilmiş içgörüleri veri ambarı ve yukarısında tutarlı tutmak için aynı anda ve istendiği kadar sıklıkta çalışabilir -veri kaynaklarıyla güncel. Her tablo güncelleyici kendi Kubernetes Pod'u olarak dağıtılır: bir pod başlatıldığında aşağıdaki adımlardan geçer:
Yönetmekle görevli olduğu tablo için meta veri günlüğünü yeniden oynatır.
Tablonun öncül bağımlılıklarından meta veri durumu ister.
Mevcut güncellemeleri uygular.
Yaptığı eylemleri tablonun meta veri günlüğüne yazar ve ardından kapanır.
Meta veri günlüğü BigQuery'de bulunur ve ayrıntılı izleme, performans analizi ve veri kökeni sağlar. Tablo en son ne zaman güncellendi? gibi izleme sorularını yanıtlar. Tablodaki veriler ne kadar yeni? Performans analizi için, sorgu yürütme ayrıntıları için meta veri günlüğünü BigQuery information_schema'sına bağlarız; ve her tablo için metrikler hakkında rapor vermek. Veri kökeni, tablolar güncellendiğinde öncül bağımlılıkları izleyerek meta veri günlüğünden elde edilebilir, böylece tüm köken, meta veri günlüğünden geçilerek yeniden oluşturulabilir.
Kullanıcıya Yönelik Özelliklerin Güçlendirilmesi:
Şimdiye kadar Derived, yalnızca sorgu yanıt süreleri bir saniyeden uzun olan BigQuery veri kümelerinde (büyük veri işleme için tasarlanmış bir veri ambarı) çalışıyordu. Uygulama özelliklerini güçlendirmek için, özellikle uygulama akışının olduğu makine öğrenimi özellikleri için yanıt sürelerinin çok daha hızlı olması gerekir: bir kullanıcı isteği alın, bir özellik seti oluşturmak için birden fazla Türetilmiş veri kümesini sorgulayın ve ardından bir tahmin yapın ve kullanıcıya yanıt verin bir saniyenin altında. Bunun için, yönetişim sistemlerinin uygulanabilmesi ve Türetilmiş veri kümesinin hızlı uygulama sunma sorguları için tasarlanmış bir veritabanında bulunabilmesi için BigQuery'den Scylla'ya otomatik olarak dışa aktarmak üzere Derived'e yeni bir yapılandırma seçeneği ekledik.
Çözüm
Sürüm Üç'ü bir yıldan fazla bir süredir üretimde kullanıyoruz. Başarmak için belirlediğimiz orijinal yedi hedefi gerçekleştirdik...
✓ Tablo güncellemeleri, yeni veriler elde edilir edilmez (ancak daha erken değil!)
✓ Türetilmiş veri kümelerinde mutasyonların denetim izini sürdürür.
✓ Veri kökenini ve veri kataloğu araçlarını güçlendirmek için ilkel öğeleri içerir.
✓ DAG'da yapılan değişiklikler, mühendislik, veri bilimi ve makine öğrenimi gibi paydaş ekipler için self-servis ve sezgisel olmalıdır.
✓ Veri erişim kontrollerinin farkındadır ve ölçeklenebilir gizlilik politikası uygulaması sağlar.
✓ Discord'un kullanıcıya yönelik ürününde kullanılmak üzere türetilmiş verileri üretim veri depolarına otomatik olarak aktarabilme.
✓ Discord ortamı bağlamında kullanımı basit ve kolaydır.
... ancak yolculuk sona ermedi, artık üretimde binlerce tablo var ve ekip genellikle çok karmaşık veri kümeleri oluşturmak için Derived'i kullanan ilgili kullanıcılardan geri bildirim ve öneriler alıyor. Sistem, trilyonlarca veri noktasından günlük petabaytlarca veriyi işler ve Derived'in performansını ve özellik setini geliştirmeye devam ediyoruz. Şu anda bir Sürüm Dört üzerinde çalışıyoruz - buradaki proje adlarımızla çok yaratıcıyız ve gelecek yinelemelerde daha fazla içgörü paylaşmayı dört gözle bekliyoruz.
Vay! Bu çok fazla bilgiydi ve ekip için oldukça maceralıydı! Büyük veri setleri ile çalışmak aklınıza geliyorsa, sizi iş ilanları sayfamıza göz atmaya ve başvurmaya davet ediyoruz.
Bu makale tarafımca Discord Blog sitesinden çevirilmiştir.
