Bu gönderi, GoDaddy'de Yazılım Mühendisliği Müdürü Raphey Holmes ve Baş Yazılım Geliştirme Mühendisi Jason Mackay ile birlikte yazılmıştır.

GoDaddy, dünyanın dört bir yanındaki girişimciler için dünyanın en büyük hizmet platformudur ve dünya çapındaki 20 milyondan fazla müşteriden oluşan topluluklarını ve her yerdeki girişimcileri onlara çevrimiçi büyümeleri için ihtiyaç duydukları tüm yardımı ve araçları sağlayarak güçlendirir. GoDaddy'nin sağlam, doğrulanmış ve özelleştirilebilir bir makine öğrenimi özellik yönetimi çözümüne ihtiyacı var ve bu çözümü seçti Amazon SageMaker Özellik Mağazası benzersiz veri boru hatları ve güncelleme programları ile düzinelerce özellik grubundaki binlerce özelliği yönetmek için. Özellik Mağazası, içeriğin kişiselleştirilmesinden dolandırıcılığın önlenmesine ve müşterilerin mükemmel alan adını bulmasına yardımcı olmaya kadar her şeyi kapsayan, makine öğrenimi (ML) modellerinin doğru eğitimini ve dağıtımını desteklemek için GoDaddy'nin belirli bir zamandaki sorguları kullanmasına olanak tanır.

Özellik Mağazası, özellik grupları tanımlamanıza, toplu alım ve akış alımını kullanmanıza, son derece doğru çevrimiçi tahminler için tek haneli milisaniye gecikmeyle özellikleri almanıza ve eğitim için belirli bir zamanda doğru veri kümelerini çıkarmanıza olanak tanır. Bu altyapı yeteneklerini oluşturmak ve sürdürmek yerine, verileriniz büyüdükçe ölçeklenen, ekipler arasında özellik paylaşımına olanak tanıyan ve veri bilimcilerin oyunun kurallarını değiştiren iş kullanım senaryoları için makine öğrenimi odaklı harika ürünler oluşturmaya odaklanmasına izin veren, tam olarak yönetilen bir hizmet alırsınız. Ekipler artık sağlam özellikler sunabilir ve bunları farklı ekipler tarafından oluşturulabilecek çeşitli modellerde yeniden kullanabilir.

Bu gönderide, GoDaddy ve AWS mimarlarından oluşan ortak ekip olarak, ölçeklenebilir bir şekilde yeniden kullanılabilir özellik gruplarına karşı belirli bir noktada yapılan sorguları kullanarak doğru eğitim veri kümeleri oluşturmak için Feature Store'un ve Apache Spark'ın işlem gücünün nasıl kullanılacağını açıklıyoruz.

Belirli bir noktada doğru sorgular kullanarak veri sızıntısını önleyin

Makine öğreniminde, veri sızıntısı veya hedef sızıntısı, yanlışlıkla model eğitiminde tahmin sırasında mevcut olmayan verileri kullanıyor. Sızıntı ince olabilir ve tespit edilmesi zor olabilir, ancak iş üzerindeki etkisi önemli olabilir. Sızıntı olan modeller, geliştirme aşamasında gerçekçi olmayan bir şekilde iyi performans gösterir, ancak bunlar, gelecekteki verilerden yararlanmadan üretimde zayıf model doğruluğu sağlar.

Zamana bağlı özelliklere sahip sızıntı, çok çeşitli kullanım durumlarında ortaya çıkabilir. Örneğin, akciğer hastalığını tahmin eden bir model, bir hastanın ilaç kullanımı veya cerrahi prosedürlerle ilgili özellikleri kullanabilir. Bir web sitesindeki bir öneri modeli, hangi tekliflerin o müşteri için en çekici olacağını tahmin etmek için müşteri siparişlerini kullanabilir. Bu özellikler doğru kullanıldığında geçerlidir, ancak veri bilimcileri, özellik değerlerinin yalnızca hedef gözlemlenmeden önce bilinebilecek veriler kullanılarak oluşturulduğundan emin olmalıdır. Örneğin, bir hastaya t1 zamanında teşhis konulduysa, bir eğitim veri seti oluşturulurken ilaçlar veya t1'in ötesindeki hastane ziyaretleriyle ilgili veriler hariç tutulmalıdır.

Peki, veri bilimi ekipleri, eğitimli modellerine gelecekteki verileri sızdırmamalarını sağlarken zengin bir makine öğrenimi özellikleri seti nasıl sağlar? Şirketler, bu model eğitimi sorununu çözmeye yardımcı olmak için özellik deposu kullanımını giderek daha fazla benimsiyor. Güçlü bir özellik deposu, eksiksiz bir özellik değerleri geçmişine sahip bir çevrimdışı mağaza sağlar. Özellik kayıtları, belirli bir zamanda doğru sorguları desteklemek için zaman damgalarını içerir. Veri bilimcileri, o zamanın ötesindeki verileri dahil etme şansı olmadan, belirli bir zamanda mevcut olabilecek tam özellik değerleri kümesini sorgulayabilir.

Zaman içinde bir özellik sorgusu kavramını açıklamak için bir diyagram kullanalım. Bir dizi tarihsel işlem üzerinde bir dolandırıcılık saptama modeli eğittiğimizi hayal edin. Her işlemin, tüketici, satıcı ve kredi kartı gibi işleme dahil olan çeşitli varlıklarla ilişkili özellikleri vardır. Bu varlıklar için özellik değerleri zamanla değişir ve farklı programlarda güncellenir. Gelecekteki özellik değerlerinin sızmasını önlemek için, belirli bir zamanda yapılan bir sorgu, her bir özelliğin her işlem zamanında mevcut olan durumunu alır ve daha sonra değil. Örneğin, t2 zamanındaki işlem yalnızca t2 zamanından önce mevcut olan özellikleri kullanabilir ve t1'deki işlem, t1'den büyük zaman damgalarındaki özellikleri kullanamaz.

Aşağıdaki diyagramda ortaya çıkan eğitim veri kümesi, bir zaman noktası sorgusunun, yalnızca gelecekte bilinebilecek değerlerden kaçınarak her işlem için doğru bir özellik değerleri kümesi döndürdüğünü gösterir. Geçmişten doğru değer kümesini güvenilir bir şekilde almak, model performansının gerçek dünyadaki işlemlerle karşı karşıya kaldığında zarar görmemesini sağlar.

Konsepti bir adım daha sağlamlaştırmak için, sizi veri sızıntısından korumayan diğer iki sorgu türünü ele alalım:

• En son özellik değerlerini alın – Her özellik için mevcut olan en son özellik değerlerini basitçe döndüren bir sorgu düşünün. Böyle bir sorgu toplu puanlama veri kümesi oluşturmak için iyi çalışsa da, sorgu yanlışlıkla t1 ve t2'deki işlemler için mevcut olmayan verileri sızdırarak çok zayıf bir eğitim veri kümesi sağlar.
• Özellikleri belirli bir zaman damgasından itibaren alın – Benzer şekilde, tek bir zaman damgasından itibaren tüm özellik verilerini döndüren bir sorgu, her eğitim veri kümesi girişi için ayrı bir zaman damgası kullanmak yerine tüm kayıtları tek tip olarak ele aldığından, uygun olmayan bir eğitim veri kümesi oluşturur. Lafta zamanda yolculuk yetenekleri deneyleri denetlemek ve çoğaltmak için harikadır. Bununla birlikte, her eğitim kaydı için değişen olay zaman damgalarını hesaba katmadığı için, zaman yolculuğu doğru eğitim veri kümesi çıkarımı için çözüm sağlamaz.

Genel makine öğrenimi yaşam döngüsünün bir parçası olarak belirli bir zamanda sorgular

Aşağıdaki diyagram, belirli bir zaman noktasındaki sorguların genel makine öğrenimi yaşam döngüsüne nasıl uyduğunu gösterir. Diyagram, özellik dönüşümlerini gerçekleştiren ve özellik kayıtlarını Feature Store'a alan bir dizi otomatikleştirilmiş özellik ardışık düzeniyle başlar. Bireysel özellik grupları için işlem hatları bağımsızdır ve değişen programlarda çalışabilir. Bir özellik grubu her gece yenilenirken, diğeri saatlik olarak güncellenebilir ve üçüncüsü, kaynak veriler bir giriş akışına ulaştığında tetiklenen güncellemelere sahip olabilir; Apache Kafka konu veya aracılığıyla Amazon Kinesis Veri Akışları.

Özellik gruplarınızın yapılandırmasına bağlı olarak, ortaya çıkan özellikler, otomatik senkronizasyonla bir çevrimiçi mağazada, bir çevrimdışı mağazada veya her ikisinde birden kullanıma sunulur. Çevrimdışı mağaza, güvenli ve ölçeklenebilir bir özellikler deposu sağlayarak, veri bilimcilerin tam bir özellik değerleri geçmişiyle merkezi olarak yönetilebilen bir dizi özellik grubundan eğitim ve doğrulama veri kümeleri veya toplu puanlama veri kümeleri oluşturmasına olanak tanır.

Belirli bir nokta sorgusunun sonucu, daha sonra doğrudan bir makine öğrenimi algoritmasıyla veya bir makine öğrenimi algoritmasına girdi olarak kullanılabilen bir eğitim veri kümesidir. Adaçayı Yapıcı eğitimi Görev. Bir zaman noktası sorgusu etkileşimli olarak çalıştırılabilir. Apache Spark gibi bir ortam SageMaker not defteri or Amazon EMR not defteri. Büyük ölçekli eğitim veri kümeleri için bu sorguları bir SageMaker İşleme Herhangi bir altyapıyı yönetmek zorunda kalmadan işi çok eşgörünümlü bir kümeye ölçeklendirmenizi sağlayan iş.

Bu gönderide belirli bir zamanda sorguların bir Apache Spark uygulamasını göstermemize rağmen, Amazon Atina başka bir alternatif sunar. Athena ile seçim kriterlerinizi içeren geçici bir tablo oluşturabilir ve ardından bu kriterleri çevrimdışı mağaza özelliği gruplarınıza eklemek için SQL'i kullanabilirsiniz. SQL sorgusu, her eğitim veri kümesi satırı için hedeflenen olay zamanından daha eski olan en son özellik değerlerini seçebilir.

Otomatik toplu ardışık düzenlerin nasıl oluşturulacağını öğrenmek için bkz. Amazon SageMaker ile özellik mühendisliği ardışık düzenlerini otomatikleştirin. Akış özelliği ardışık düzenleri hakkında daha fazla bilgi için bkz. Neredeyse gerçek zamanlı olarak ML destekli kararlar vermek için Amazon SageMaker Feature Store ile akış beslemesini kullanma.

Özellik Mağazası zaman damgaları

Çevrimdışı mağazaya karşı belirli bir zamanda doğru sorguların nasıl gerçekleştirileceğini incelemeden önce, SageMaker'ın her özellik grubu için çevrimdışı mağaza şemasında sağladığı üç farklı zaman damgasının tanımını ve amacını anlamak önemlidir:

• Etkinlik zamanı – İşlem süresi, bir müşterinin sipariş verdiği zaman veya yeni bir sigorta talebinin oluşturulduğu zaman gibi, özellik kaydıyla ilişkili müşteri tanımlı zaman damgası. Bu özelliğin özel adı, özellik grubu oluşturulduğunda belirtilir ve bu zaman damgasının doldurulmasından müşterinin kullanım kodu sorumludur.
• API çağırma süresi – SageMaker'ın özellik deposuna bir özellik kaydı yazmak için API çağrısını aldığı zaman. Bu zaman damgası, SageMaker tarafından otomatik olarak doldurulur. api_invocation_time özelliği.
• Yazma zamanı – Özellik kaydının çevrimdışı mağazada kalıcı olduğu zaman. Bu zaman damgası her zaman API başlatma süresinden daha uzundur ve SageMaker tarafından otomatik olarak doldurulur. write_time özelliği.

Kullanım durumunuza bağlı olarak, doğru özellik değerleri seçmek için SageMaker'daki zaman damgası alanlarının bir kombinasyonunu kullanabilirsiniz. Bir eğitim veri kümesindeki her örneğin, müşteri tanımlı bir olay zamanı ve bir kayıt tanımlayıcısı vardır. Bir zaman noktası sorgusunda özellik geçmişine karşı eğitim etkinlikleri listesine katıldığınızda, örneğe özgü olay zaman damgasından sonra gerçekleşen tüm kayıtları yok sayabilir ve kalan kayıtlardan en yenisini seçebilirsiniz. Etkinlik zamanı alanı, bu birleştirmenin anahtarıdır. Standart bir kullanım durumunda, kalan en son kaydın seçilmesi yeterlidir. Bununla birlikte, bir özellik değeri, bir özellik dolgusunun parçası olarak düzeltildi veya revize edildiyse, çevrimdışı mağaza, aynı olay zamanı ve kayıt tanımlayıcısına sahip birden çok kayıt içerir. Hem orijinal kayıt hem de yeni kayıt mevcuttur ve her birinin farklı bir yazma süresi vardır. Bu durumlar için, bir zaman noktası sorgusu şu komutu kullanabilir: write_time özellik veya api_invocation_time özelliği, bir eşitlik bozucu olarak düzeltilmiş özellik değerinin döndürülmesini sağlar.

Belirli bir zamanda doğru sorgu uygulama

Artık kavramları açıkladığımıza göre, Feature Store ve Apache Spark kullanarak belirli bir zamanda sorguları verimli bir şekilde gerçekleştirmenin uygulama ayrıntılarına geçelim. Aşağıdakileri kullanarak bunu kendi hesabınızda deneyebilirsiniz. GitHub repo. Bu havuz, üç Jupyter not defteri artı özellik gruplarımızı oluşturmak için kullanılan bazı şema dosyalarını içerir. Bu bölümde, size bir sorgu uygulamasının iç işleyişini gösteriyoruz. Not defterinde, bunu birkaç parametreyi geçmek kadar basit hale getiren yeniden kullanılabilir bir işlev de sunuyoruz:

def get_historical_feature_values ( fg_name: str, entity_df: DataFrame, spark: SparkSession, allowed_staleness_days: int = 14, remove_extra_columns: bool = True) -> DataFrame:

Zaman içinde nokta sorgumuzun uygulanması SageMaker, Jupyter not defterleri ve Apache Spark'ı (PySpark) kullanır. Ara verilerin çoğu depolanır Kıvılcım Veri Çerçeveleri, bize bu veri kümesini manipüle etmek, filtrelemek ve azaltmak için güçlü yerleşik yöntemler sağlar, böylece sorgu verimli bir şekilde çalışır. Spark'ın ortamımızda düzgün çalışmasını sağlamak için, Spark oturumunu fazladan sürücü belleği ve yürütücü çekirdeği tahsis edecek şekilde yapılandırıyoruz:

spark = (SparkSession .builder .config("spark.driver.extraClassPath", classpath) .config("spark.executor.memory", '1g') .config('spark.executor.cores', '16') .config("spark.driver.memory",'8g') .getOrCreate())

Ardından, tahmin etmek istediğimiz dolandırıcılık etiketi anlamına gelen hedefle birlikte ham kredi kartı işlemlerini içeren geçmiş işlem veri setini yüklüyoruz. Bu veriler öncelikle işlemin bir parçası olan öznitelikleri içerir ve aşağıdaki sütunları içerir:

 |-- tid: string (nullable = true) |-- event_time: string (nullable = true) |-- cc_num: long (nullable = true) |-- consumer_id: string (nullable = true) |-- amount: double (nullable = true) |-- fraud_label: string (nullable = true)

Belirli bir zaman noktasında sorgu çalıştırma ihtiyacı, belirli bir işlemle ilgili her zaman mükemmel bilgiye sahip olamamaktan kaynaklanır. Örneğin, her işlem olayı için eksiksiz bir toplu özellikler setimiz olsaydı, bu verileri doğrudan kullanabilirdik. Çoğu kuruluş, her olay için bu tür verileri oluşturamaz, bunun yerine, bu toplamları belki saatlik veya günlük olarak hesaplayan periyodik işler yürütür.

Bu gönderi için, 1 aya yayılan zaman dilimimizde her gün için bir toplama işlevi çalıştırarak bu günlük anlık görüntüleri simüle ediyoruz. Toplama kodu, biri kredi kartı numarasına göre, diğeri tüketici kimliğine göre dizine eklenen iki veri çerçevesi oluşturur. Her veri çerçevesi, 1-7 günlük yeniden inceleme dönemleri için veriler içerir. Bu veri kümeleri, toplu özelliklerimizin anlık görüntülerini oluşturan periyodik iş çalıştırmalarını simüle eder ve bunlar çevrimdışı depoya yazılır. Aşağıdaki ekran görüntüsü, periyodik olarak oluşturulan toplu tüketici özelliklerinin bir örneğidir.

Belirli bir noktadaki sorgumuz için girdi kriterlerini hazırlamak için, istenen her eğitim veri kümesi satırı için bir satır içeren bir varlık veri çerçevesi oluşturarak başlıyoruz. Varlık veri çerçevesi, her biri o eğitim satırı için kesme süremizi temsil eden bir olay zamanı ile eşleştirilmiş ilgili tüketici kimliklerini tanımlar. Tüketici kimliği, tüketici özellik grubundaki özellik verileriyle birleştirmek için kullanılır ve işlem olay zamanı, daha yeni özellik değerlerini filtrelememize yardımcı olur. Örneğimiz için, belirli bir haftadaki geçmiş işlemlerin bir alt kümesini ararız:

last_1w_df = spark.sql('select * from trans where event_time >= "2021-03-25T00:00:00Z" and event_time <= "2021-03-31T23:59:59Z"')
cid_ts_tuples = last_1w_df.rdd.map(lambda r: (r.consumer_id, r.cc_num, r.event_time, r.amount, int(r.fraud_label))).collect()
entity_df = spark.createDataFrame(cid_ts_tuples, entity_df_schema)

Bu, belirli bir noktadaki sorgumuzu yönlendiren aşağıdaki varlık veri çerçevesini üretir.

Çevrimdışı mağazaya karşı sorgulama yapmak için şunu bilmemiz gerekir: Amazon Basit Depolama Hizmeti (Amazon S3) özellik grubumuzun konumu. biz kullanıyoruz describe_feature_group o konumu aramak için yöntem:

feature_group_info = sagemaker_client.describe_feature_group(FeatureGroupName=CONS_FEATURE_GROUP)
resolved_offline_store_s3_location = feature_group_info['OfflineStoreConfig']['S3StorageConfig']['ResolvedOutputS3Uri'] # Spark's Parquet file reader requires replacement of 's3' with 's3a'
offline_store_s3a_uri = resolved_offline_store_s3_location.replace("s3:", "s3a:")

Önceki kodda, S3A dosya sistemi istemcisi. Bu istemci, S3 nesnelerine erişim için en son yamalara ve performans geliştirmelerine sahip olmamızı sağlar.

Şimdi, önceki koddan S3 konumunda Parquet biçiminde depolanan çevrimdışı mağazadan verileri okumak için Spark kullanıyoruz:

feature_store_df = spark.read.parquet(offline_store_s3a_uri)

Aşağıdaki çıktı, çevrimdışı depodan okunan verilerin şemasını gösterir. SageMaker tarafından otomatik olarak doldurulan birkaç ek alan içerir: bu gönderide daha önce tanımlandığı gibi zaman damgası alanları (write_time, api_invocation_time), geçici bir silme işareti (is_deleted) ve tarih-zaman bölümleme alanları (year, month, day, ve hour).

 |-- consumer_id: string (nullable = true) |-- num_trans_last_7d: long (nullable = true) |-- avg_amt_last_7d: double (nullable = true) |-- num_trans_last_1d: long (nullable = true) |-- avg_amt_last_1d: double (nullable = true) |-- event_time: string (nullable = true) |-- write_time: timestamp (nullable = true) |-- api_invocation_time: timestamp (nullable = true) |-- is_deleted: boolean (nullable = true) |-- year: integer (nullable = true) |-- month: integer (nullable = true) |-- day: integer (nullable = true) |-- hour: integer (nullable = true)

The is_deleted öznitelik, başvurulan kayıt tanımlayıcısı için bir Boolean geçici silme göstergesidir. Eğer DeleteRecord yöntemi çağrıldığında, yeni bir kayıt eklenir. is_deleted çevrimdışı mağazada bayrak True olarak ayarlandı. Tarih-zaman bölümleme alanları, çevrimdışı depoya yazılan bireysel veri dosyalarını ayırmak için kullanılır ve istenen bir zaman çerçevesine giderken veya bir veri alt kümesini okurken kullanışlıdır.

Belirli bir zaman noktası sorgusunun performansını optimize etmek için, genel ölçütlerimizi karşılamayan tüm kayıtları hemen filtreleyebiliriz. Çoğu durumda, bu optimizasyon ileriye taşıdığımız kayıt sayısını büyük ölçüde azaltır ve bu nedenle sonraki birleştirmeleri daha verimli hale getirir. Zaman çerçevesi sınırımıza uymayan tüm verileri bırakmak için bir min/maks zaman penceresi kullanırız. Kullanışlı olamayacak kadar eski kayıtları dahil etmememizi sağlamak için bir bayatlık penceresi de ekledik. Bayatlık penceresinin uygun uzunluğu, kullanım durumunuza özeldir. Aşağıdaki koda bakın:

# NOTE: This filter is simply a performance optimization
# Filter out records from after query max_time and before staleness # window prior to the min_time.
# Doing this prior to individual {consumer_id, joindate} filtering # speeds up subsequent filters for large scale queries. # Choose a "staleness" window of time before which we want # to ignore records
allowed_staleness_days = 14 # Eliminate history that is outside of our time window # This window represents the {max_time - min_time} delta, # plus our staleness window # entity_df used to define bounded time window
minmax_time = entity_df.agg(sql_min("query_date"), sql_max("query_date")).collect()
min_time, max_time = minmax_time[0]["min(query_date)"], minmax_time[0]["max(query_date)"] # Via the staleness check, we are actually removing items when # event_time is MORE than N days before min_time
# Usage: datediff ( enddate, startdate ) - returns days filtered = feature_store_active_df.filter( (feature_store_active_df.event_time <= max_time) & (datediff(lit(min_time), feature_store_active_df.event_time) <= allowed_staleness_days)
)

Artık sonuçları yalnızca istenen eğitim veri kümemizin parçası olan tüketici kimliklerine (varlıklarımız) indirgemek için filtrelenmiş veri kümesini varlık veri çerçevesiyle birleştirmeye hazırız. Bu iç birleşim kullanır consumer_id bir birleştirme anahtarı olarak, böylece diğer tüketiciler için işlemleri kaldırır:

t_joined = (filtered.join(entity_df, filtered.consumer_id == entity_df.consumer_id, 'inner') .drop(entity_df.consumer_id)

Bu, hedeflenen her eğitim satırı için tüketici özellik grubumuzdaki tüm toplu öznitelikleri içeren gelişmiş bir veri çerçevesiyle sonuçlanır. Seçtiğimiz zaman penceresinin dışındaki işlemleri hâlâ kaldırmamız gerekiyor. Bu pencere, ilgilenilen olay zamanından daha geç olmayan ve seçilen bayatlık payımızdan daha erken olmayan zaman olarak tanımlanır. Bu sefer pencere filtrelemesi, seçtiğimiz eğitim satırları listemizin parçası olan her bir öğeye karşı çalıştırılır. drop_future_and_stale_df adlı sonuçlarla birlikte aşağıdaki filtre koduna bakın:

# Filter out data from after query time to remove future data leakage.
# Also filter out data that is older than our allowed staleness # window (days before each query time) drop_future_and_stale_df = t_joined.filter( (t_joined.event_time <= entity_df.query_date) & (datediff(entity_df.query_date, t_joined.event_time) <= allowed_staleness_days))

Nihai eğitim veri kümemizde, varlık kimliği başına birden çok toplu kayda izin vermek istiyoruz (tek bir tüketici tarafından birden çok kredi kartı işlemi düşünün), ancak işlem başına yalnızca bir kayıt tutmak istiyoruz. Bu nedenle, tüketici kimliğinden ve sorgu zaman damgasından yapılan bileşik bir anahtar oluşturuyoruz: {x.consumer_id}-{x.query_date}. Bu adım, her bileşik anahtar için yalnızca en son toplu kaydın kalmasını sağlar. Bunu safça yapmak (gerçek bir sıralama işlemi kullanarak) pahalı olacaktır. Bunun yerine, bunu Spark RDD'ye iletilen özel bir indirgeme kullanarak uygulayabiliriz. reduceByKey(), büyük veri kümeleri için çok iyi ölçeklenir. Aşağıdaki koda bakın:

# Group by record id and query timestamp, select only the latest # remaining record by event time,
# using write time as a tie breaker to account for any more # recent backfills or data corrections. latest = drop_future_and_stale_df.rdd.map(lambda x: (f'{x.consumer_id}-{x.query_date}', x)) .reduceByKey( lambda x, y: x if (x.event_time, x.write_time) > (y.event_time, y.write_time) else y).values()
latest_df = latest.toDF(drop_future_and_stale_df.schema)

Nihai sonuçlarımızı görüntülemek için, görüntülemek ve referans olarak belirli sütunları seçebiliriz. test_consumer_id orijinal veri çerçevemizden alınmıştır:

latest_df.select('consumer_id', 'query_date', 'avg_amt_last_7d', 'event_time', 'write_time') .where(latest_df.consumer_id == test_consumer_id) .orderBy(col('query_date').desc(),col('event_time').desc(), col('write_time').desc()) .show(15,False)

Eğitim için ihtiyaç duymadığımız sütunları da bırakabiliriz:

cols_to_drop = ('api_invocation_time','write_time','is_deleted','cc_num','year','month','day','hour') latest_df = latest_df.drop(*cols_to_drop)

Aşağıdaki ekran görüntüsü, belirli bir zaman dilimindeki sorgumuzun nihai sonuçlarının bir örneğidir. Bu sonuçlar, yalnızca geçmişten özellikleri seçtiğimizi ve gelecekteki değerleri sızdırmadığımızı açıkça gösteriyor. Her kaydın olay zamanı, sorgu zaman damgasından daha erken olduğundan, yalnızca gelecekte bilinebilecek özellikleri kullanmadan en son özelliklere sahip olmamızı sağlar.

Bu, geçmiş sorguyu tamamlar ve artık her bir eğitim işlemi için bir zaman noktası sorgusunu temsil eden doğru bir eğitim veri setine sahibiz.

Sonuç

Bu gönderide, belirli bir zamanda doğru sorgu kavramını tanımladık ve etkili makine öğrenimi modellerinin eğitiminde bu sorguların önemini açıkladık. Feature Store ve Apache Spark kullanarak geçmiş özellik verilerini kullanmanın etkili ve tekrarlanabilir bir yolunu gösterdik. Umarız deneyerek verdiğimiz kod, ve kendi veri kümelerinizde deneyin. Her zamanki AWS Destek kişileriniz aracılığıyla veya Amazon SageMaker Tartışma Forumu.

Yazarlar Hakkında

paul hargis çabalarını AWS, Amazon ve Hortonworks dahil olmak üzere çeşitli şirketlerde Makine Öğrenimi üzerine yoğunlaştırdı. Teknoloji çözümleri oluşturmaktan ve ayrıca insanlara bundan en iyi şekilde nasıl yararlanacaklarını öğretmekten hoşlanıyor. AWS'deki görevinden önce, Amazon.com'un uluslararası alışveriş yapanlar için deneyimi iyileştirmesine yardımcı olan Amazon İhracat ve Genişletmeleri için baş mimardı. Paul, müşterilerin gerçek dünyadaki sorunları çözmek için makine öğrenimi girişimlerini genişletmelerine yardımcı olmayı sever.

  Raphey Holmes GoDaddy'nin Makine Öğrenimi platformu ekibinde bir mühendislik yöneticisidir. Kariyerini değiştirmeden önce, lisede fizik öğretmeni olarak on yıl çalıştı ve hâlâ öğretme ve öğrenmeyle ilgili her şeyi seviyor. Ekli resme bakın.

Jason Mackay GoDaddy Makine Öğrenimi Ekibinde GoDaddy'de Müdür SDE'dir. İşletim sistemleri, paralel/eşzamanlı/dağıtılmış sistemler, biçimsel diller, yüksek performanslı kriptografi, büyük veri ve makine öğrenimini kapsayan yazılım endüstrisinde 25 yıldır yer almaktadır.

Mark Roy AWS için Başlıca Makine Öğrenimi Mimarıdır ve müşterilerin AI / ML çözümleri tasarlamasına ve oluşturmasına yardımcı olur. Mark'ın çalışması, temel ilgi alanı bilgisayarla görme, derin öğrenme ve kurum genelinde ML'yi ölçeklendirmeye yönelik çok çeşitli makine öğrenimi kullanım örneklerini kapsar. Sigorta, finansal hizmetler, medya ve eğlence, sağlık hizmetleri, kamu hizmetleri ve imalat dahil birçok sektördeki şirketlere yardım etti. Mark, ML Uzmanlık Sertifikası da dahil olmak üzere altı AWS sertifikasına sahiptir. Mark, AWS'ye katılmadan önce, 25 yılı finansal hizmetler dahil olmak üzere 19 yılı aşkın süredir mimar, geliştirici ve teknoloji lideriydi.

Plato Ai. Web3 Yeniden Düşünüldü. Güçlendirilmiş Veri Zekası.

Erişmek için buraya tıklayın.

Kaynak: https://aws.amazon.com/blogs/machine-learning/build-accurate-ml-training-datasets-using-point-in-time-queries-with-amazon-sagemaker-feature-store-and- apache-spark/