Amalan pembinaan platform kejuruteraan ciri masa nyata yang menyepadukan penstriman dan batching

Artikel ini terutamanya berkongsi amalan platform dan pengalaman pembinaan pasukan projek Alibaba Cloud FeatHub dalam pembangunan kejuruteraan ciri.

Perkongsian ini dibahagikan kepada empat bahagian Bahagian pertama secara amnya memperkenalkan senario, matlamat, titik kesakitan dan cabaran yang dihadapi oleh FeatHub dalam pembangunan ciri, penggunaan, pemantauan dan perkongsian. proses; Bahagian kedua memperkenalkan amalan idea seni bina FeatHub dan konsep teras berkaitan bahagian ketiga memperkenalkan penggunaan asas API, fungsi pengkomputeran asas dan amalan kod senario sampel semasa penggunaan FeatHub, serta pengoptimuman prestasi dan masa hadapan; matlamat pengembangan serta pembinaan bersama komuniti sumber terbuka, ia menyediakan pembelajaran, pembangunan dan penggunaan projek itu juga akan berkongsi fungsi main balik data sejarah FeatHub, sokongan luar talian, dekat talian, pemprosesan dan sokongan untuk komponen huluan dan hiliran Alibaba Cloud.

1. Mengapa FeatHub diperlukan

1 Senario sasaran

(1) Ahli sains data yang memerlukan persekitaran Python

<.>Kebanyakan program inferens dan latihan pembelajaran mesin yang popular hari ini pada asasnya ditulis oleh saintis data dalam Python, seperti TensorFlow, PyTorch dan scikit-lear yang popular digunakan dalam beberapa senario pembelajaran mesin tradisional, dsb. Kami berharap dapat menyokong saintis data dalam terus menggunakan Python yang biasa untuk menulis kod kejuruteraan ciri untuk melengkapkan pembangunan dan penggunaan pautan pembelajaran mesin hujung ke hujung, dan menggunakan perpustakaan dalam ekosistem Python yang mereka kenali.

(2) Hasilkan ciri masa nyata

Semakin banyak aplikasi pembelajaran mesin sedang dibangunkan dalam arah masa nyata, dan kecekapan serta ketepatan pembelajaran mesin boleh dipertingkatkan melalui masa nyata pemprosesan. Untuk mencapai matlamat, ciri masa nyata perlu dihasilkan. Ini bukan sahaja tentang mendapatkan ciri pertanyaan dalam masa nyata, tetapi juga menjana ciri dalam masa nyata. Contohnya, jika anda perlu mendapatkan bilangan klik pengguna dalam dua minit terakhir dalam masa nyata, anda perlu menggunakan enjin pengkomputeran penstriman untuk melengkapkan pengiraan ciri masa nyata.

(3) Penyelesaian sumber terbuka diperlukan untuk menyokong penggunaan berbilang awan

Semakin banyak syarikat kecil dan sederhana berharap untuk mencapai penggunaan berbilang awan untuk mendapatkan jaminan keselamatan pengeluaran dan mendapatkan pembidaan di kalangan vendor awan. Oleh itu, penyelesaian kami tidak memerlukan pengguna untuk mengikat vendor awan, tetapi membenarkan pengguna memilih secara bebas antara vendor awan yang berbeza, malah menggunakan operasi kejuruteraan ciri dalam awan peribadi.

Ini adalah beberapa syarat yang diharapkan dapat dipenuhi oleh projek FeatHub apabila ia ditubuhkan.

2. Titik kesakitan kejuruteraan ciri masa nyata

Hari ini, banyak syarikat sedang membangunkan operasi kejuruteraan ciri masa nyata. Terdapat beberapa titik kesakitan, meliputi keseluruhan kitaran hayat ciri, termasuk pembangunan, penggunaan, pemantauan dan perkongsian seterusnya.

(1) Pembangunan adalah sukar

① Ciri traversal

Dalam peringkat pembangunan, rangka kerja ciri masa nyata Apache Flink adalah digunakan lebih banyak , kerana Flink pada asasnya ialah standard de facto untuk pengkomputeran aliran masa nyata, tetapi menggunakan Flink atau rangka kerja yang serupa untuk membangunkan ciri masa nyata memerlukan penyelesaian kesukaran traversal ciri. Ramai saintis data tidak mempunyai pengalaman untuk menyelesaikan traversal ciri, dan memerlukan banyak masa dan kos pembelajaran untuk menyelesaikan masalah sedemikian, yang merupakan titik kesakitan utama dalam peringkat pembangunan.

(2) Penggunaan adalah sukar

① Terjemahan manual diperlukan

Banyak syarikat akan mempunyai pasukan platform khusus untuk menterjemahkan kerja Python satu proses yang ditulis oleh saintis data ke dalam boleh diagihkan Pekerjaan Flink atau Spark boleh dilaksanakan secara manual untuk mencapai pelaksanaan berprestasi tinggi dan ketersediaan tinggi. Proses terjemahannya akan meningkatkan panjang keseluruhan kitaran hayat pembangunan. Dan kerana ia memerlukan tenaga kerja tambahan untuk melakukan kerja penterjemahan, ia meningkatkan kos pembangunan dan seterusnya membawa kemungkinan untuk memperkenalkan pepijat. Logik selepas kumpulan orang lain menterjemah kerja saintis data mungkin tidak konsisten dengan logik asal, yang akan membawa lebih banyak beban kerja penyahpepijatan.

(3) Pemantauan adalah sukar

① Perubahan dalam pengedaran ciri

Keseluruhan kualiti dan kecekapan kerja kejuruteraan ciri bukan sahaja bergantung pada sama ada kerja itu mempunyai pepijat, tetapi juga bergantung pada pengedaran berangka data input huluan yang memenuhi ciri tertentu, seperti dekat dengan pengedaran berangka data semasa latihan. Prestasi inferens banyak pekerjaan menurun, selalunya disebabkan oleh perubahan dalam pengedaran data yang dihasilkan oleh pekerjaan huluan. Dalam kes ini, pembangun perlu menjejaki keseluruhan pautan, segmen demi segmen untuk melihat tempat pengedaran data ciri telah berubah dan melihat sama ada latihan semula atau pembetulan pepijat diperlukan berdasarkan situasi tertentu. Beban kerja yang berlebihan bahagian tenaga kerja ini juga merupakan titik kesakitan.

(4) Perkongsian adalah sukar

① Penduaan kerja pembangunan

Walaupun pasukan pembangunan dan senario banyak kerja pengiraan ciri adalah berbeza, serupa atau definisi ciri yang sama sebenarnya digunakan. Banyak syarikat tidak mempunyai saluran yang baik untuk pasukan berbeza dalam syarikat untuk bertanya dan menggunakan semula ciri sedia ada. Ini menyebabkan pasukan berbeza sering perlu melakukan pembangunan berulang, malah perlu menjalankan kerja berulang kali untuk menjana beberapa ciri untuk ciri yang sama. Ini membawa pembaziran tenaga kerja dan sumber pengkomputeran/storan, kerana lebih banyak pengkomputeran, memori dan ruang storan diperlukan untuk menjana ciri yang sama.

② semantik betul titik dalam masa

Untuk membolehkan semua orang memahami apa itu persimpangan ciri, rajah di atas menunjukkan Contoh mudah untuk menggambarkan masalah ini. Jadual di bahagian atas sebelah kiri angka ialah ciri gelagat pengguna, yang menyatakan bilangan klik dalam dua minit terakhir untuk pengguna dengan ID yang diberikan pada nod masa yang berbeza. Bilangan klik ini boleh membantu kami membuat kesimpulan sama ada pengguna akan mengklik pada iklan. Untuk menggunakan ciri ini untuk latihan, biasanya perlu untuk menggabungkan ciri ke dalam beberapa set data pengguna dengan Label. Jadual di sebelah kiri bawah rajah menunjukkan set data beberapa sampel positif dan negatif sama ada pengguna benar-benar mengklik pada iklan tersebut, menandakan sampel positif atau sampel negatif yang dijana oleh pengguna pada titik berbeza dalam masa. Untuk menggabungkan ciri dalam kedua-dua set data ini untuk membentuk set data latihan, biasanya perlu untuk menyambung ciri berdasarkan ID pengguna sebagai kunci. Jika anda hanya melakukan Table Join tanpa mengambil kira cap masa, masalah persimpangan ciri mungkin berlaku. Contohnya, pada 6:03 minit, bilangan klik pengguna dalam 2 minit terakhir hendaklah 10, tetapi nilai ciri yang diperoleh dengan penyambungan mungkin 6 dari 7:00 minit. Persimpangan ciri seperti ini akan membawa penurunan dalam kesan penaakulan sebenar. Hasil gabungan dengan semantik betul titik dalam masa hendaklah seperti yang ditunjukkan dalam rajah di bawah:

Untuk mengelakkan persilangan ciri apabila menyambung sampel, untuk rajah kiri dalam Untuk setiap sekeping data dalam jadual , nilai ciri yang cap masanya lebih kecil daripada dan paling hampir dengan cap masa dalam jadual kiri harus ditemui antara ciri berbilang versi jadual dimensi dan disambungkan ke dalam set data latihan yang dijana akhir. Penggabungan sedemikian dengan semantik betul titik dalam masa akan menghasilkan set data latihan yang ditunjukkan di sebelah kanan rajah di atas. Untuk titik masa yang berbeza, terdapat nilai ciri yang sepadan yang dihasilkan dalam dua minit terakhir. Set data latihan yang dijana dengan cara ini boleh meningkatkan prestasi latihan dan inferens.

3. Senario teras Kedai Ciri

Seterusnya, FeatHub, sebagai Kedai Ciri, cuba menyelesaikan masalah pada setiap peringkat pembangunan keseluruhan ciri kitaran dan alatan yang disediakan.

(1) Pembangunan ciri

Dalam peringkat pembangunan ciri, FeatHub akan menyediakan SDK yang sangat mudah digunakan berdasarkan Python, membolehkan pengguna menyatakan logik pengiraan ciri dengan ringkas. Pengiraan ciri pada asasnya ialah ETL bagi sesuatu ciri. Perkara yang paling penting semasa fasa pembangunan ialah kemudahan penggunaan dan kesederhanaan SDK.

(2) Pengerahan ciri

Dalam fasa penggunaan ciri, FeatHub akan menyediakan enjin pelaksanaan untuk melaksanakan penggunaan logik pengiraan ciri berprestasi tinggi, kependaman rendah, dan boleh menyambung kepada ciri yang berbeza kedai-kedai. Perkara yang paling penting dalam fasa penggunaan ialah prestasi enjin pelaksanaan dan keupayaan untuk menyambungkan kedai ciri yang berbeza.

(3) Penggera Ciri

Dalam fasa pemantauan ciri, untuk memudahkan pembangun mengesan perubahan dalam pengedaran nilai ciri tepat pada masanya dan bertindak balas terhadapnya, FeatHub akan menjana beberapa penunjuk biasa pada masa hadapan untuk merangkumi perkara biasa isu kualiti ciri Contohnya, perkadaran ciri dengan nilai yang menyalahi undang-undang, atau purata ciri, dan penggera dikeluarkan berdasarkan penunjuk ini untuk memberitahu orang yang bertanggungjawab untuk menyiasat punca perubahan pengedaran ciri yang berkaitan dan membuat respons untuk mengekalkan kesan penamat. -ke-hujung pautan disyorkan.

(4) Perkongsian Ciri

Dalam peringkat perkongsian ciri, FeatHub akan menyediakan pendaftaran ciri dan keupayaan carian pada masa hadapan untuk menyokong pembangun daripada pasukan berbeza dalam syarikat yang sama untuk menanyakan ciri yang mereka inginkan . belum wujud dan menggunakan semula definisi ciri ini dan data ciri yang telah dijana.

Gambar di atas menggambarkan ciri teras FeatHub. Semasa fasa pembangunan, FeatHub boleh menyediakan SDK yang mudah digunakan yang menyokong penyambungan ciri, pengagregatan ciri dan logik lain dengan semantik betul titik dalam masa. Semasa fasa penggunaan, FeatHub boleh menyokong penjanaan ciri berkemampuan tinggi, kependaman rendah, menyokong menggunakan Flink sebagai enjin pelaksanaan untuk mengira ciri, dan boleh menyokong sistem storan berbilang ciri, yang membolehkan pengguna bebas memilih jenis storan yang mereka mahu gunakan. Semasa fasa pemantauan, FeatHub akan dapat menyediakan penunjuk masa nyata untuk memantau perubahan dalam pengedaran ciri, termasuk pemantauan luar talian dan masa nyata, untuk memudahkan pembangun mencari masalah tepat pada masanya. Dalam peringkat perkongsian, FeatHub akan menyediakan UI Web dan SDK yang mudah digunakan untuk menyokong pembangun mendaftar, mencari dan menggunakan semula ciri.

Sudah ada beberapa projek Kedai Ciri wakil dalam medan Kedai Ciri, seperti Feathr, yang sumber terbuka oleh LinkedIn pada awal tahun ini, dan Feast, yang telah menjadi sumber terbuka selama bertahun-tahun. Kami menyiasat projek ini dan mendapati ia tidak sesuai untuk mencapai senario sasaran yang kami cadangkan.

Berbanding dengan penyelesaian sedia ada, FeatHub membawa nilai tambahan termasuk:

① SDK Python yang ringkas dan mudah digunakan. SDK FeatHub merujuk kepada SDK projek Gedung Ciri sedia ada, menyokong fungsi teras projek ini dan meningkatkan lagi keupayaan pengabstrakan dan kemudahan penggunaan SDK

② menyokong pendirian. pembangunan dan eksperimen sahaja. Pembangun tidak perlu menyambung ke gugusan Flink atau Spark yang diedarkan untuk menjalankan percubaan, tetapi hanya perlu menggunakan CPU atau sumber memori pada satu mesin untuk membangun dan mencuba, dan boleh menggunakan algoritma pembelajaran mesin pada satu mesin seperti scikit-belajar.

③ Enjin pelaksanaan boleh ditukar tanpa mengubah suai kod. Selepas pengguna melengkapkan pembangunan pada satu mesin, enjin pelaksanaan satu mesin boleh ditukar kepada enjin pelaksanaan teragih seperti Flink atau Spark tanpa mengubah suai kod yang menyatakan logik pengiraan ciri. Menggunakan Flink sebagai enjin pelaksanaan membolehkan Feathhub menyokong pengiraan ciri masa nyata berkemampuan tinggi dan kependaman rendah. FeatHub akan terus menyokong penggunaan Spark sebagai enjin pelaksanaan pada masa hadapan, membolehkan pengguna memperoleh prestasi daya pemprosesan yang berpotensi lebih baik dalam senario luar talian dan bebas memilih enjin pelaksanaan yang paling sesuai mengikut senario.

④ Menyediakan keupayaan pengembangan untuk enjin pelaksanaan. FeatHub bukan sahaja menyokong Flink dan Spark sebagai enjin pelaksanaan, tetapi juga menyokong pembangun untuk menyesuaikan enjin pelaksanaan dan menggunakan enjin pelaksanaan yang dibangunkan secara dalaman syarikat untuk ciri ETL.

⑤ Kod ini adalah sumber terbuka, membenarkan pengguna memilih vendor awan secara bebas untuk menggunakan FeatHub atau menggunakannya dalam awan peribadi.

2. Seni bina FeatHub dan konsep teras

1. Lapisan atas menyediakan satu set Python SDK untuk menyokong sumber data yang ditentukan pengguna, titik akhir data dan logik pengiraan ciri. Ciri yang ditakrifkan oleh SDK boleh didaftarkan dalam pusat metadata ciri, membenarkan pengguna dan pekerjaan lain membuat pertanyaan dan menggunakan semula ciri, malah menganalisis lebih lanjut keturunan ciri berdasarkan metadata ciri. Takrif ciri termasuk sumber dan sinki ciri, serta logik pengiraan biasa, seperti panggilan UDF, penyambungan ciri, pengagregatan berdasarkan atas tingkap dan tingkap gelongsor, dsb. Apabila perlu untuk menjana ciri yang ditentukan pengguna, FeatHub akan menyediakan beberapa Pemproses Ciri terbina dalam, iaitu, enjin pelaksanaan, untuk melaksanakan logik pengiraan ciri sedia ada. Apabila pengguna perlu melakukan percubaan pada satu mesin, mereka boleh menggunakan Pemproses Tempatan untuk menggunakan sumber pada mesin tunggal tanpa menyambung ke kluster jauh. Apabila anda perlu menjana ciri masa nyata, anda boleh menggunakan Flink Processor untuk melengkapkan pengiraan ciri penstriman kependaman tinggi dan kependaman rendah.

Pada masa hadapan, Perkhidmatan Ciri yang serupa dengan Fungsi Lambda juga boleh disokong untuk melaksanakan pengiraan ciri dalam talian, dan ia boleh disambungkan kepada Spark untuk melengkapkan pengiraan ciri luar talian berdaya tinggi. Enjin pelaksanaan boleh antara muka dengan sistem storan ciri luar talian dan dalam talian yang berbeza, seperti menggunakan Redis untuk storan ciri dalam talian, HDFS untuk storan ciri luar talian dan Kafka untuk storan ciri talian dekat.

Gambar di atas menunjukkan cara FeatHub digunakan oleh pengguna dan bersambung dengan latihan pembelajaran mesin hiliran dan program inferens Pengguna atau pembangun akan menggunakan SDK untuk menyatakan ciri yang mereka inginkan mengira , dan kemudian menyerahkannya kepada enjin pelaksanaan untuk digunakan. Selepas ciri dikira, ciri tersebut perlu dikeluarkan ke kedai ciri, seperti Redis dan HDFS. Program latihan luar talian pembelajaran mesin boleh membaca data secara langsung dalam HDFS untuk latihan kelompok. Program inferens pembelajaran mesin dalam talian boleh terus membaca data dalam Redis untuk inferens dalam talian.

2. Konsep teras

Rajah di atas menunjukkan hubungan antara konsep teras dalam FeatHub. TableDescriptor mewakili koleksi ciri. TableDescriptor boleh menghasilkan TableDescriptor baharu melalui transformasi logik.

TableDescriptor terbahagi kepada dua kategori. FeatureTable menyatakan jadual dengan alamat fizikal tertentu, contohnya, ia boleh menjadi jadual dalam Redis atau jadual dalam HDFS. FeatureViews ialah jadual logik yang tidak semestinya mempunyai alamat fizikal Ia biasanya diperoleh daripada Jadual Ciri selepas satu siri penukaran rentetan logik.

FeatureView mempunyai 3 subkelas berikut:

① DerivedFeatureView Barisan jadual ciri output dan jadual ciri inputnya (iaitu sumber) pada asasnya adalah satu dengan satu . Ia boleh menyokong ungkapan logik penukaran satu baris (cth. penambahan, penolakan, pendaraban dan pembahagian), atas logik pengagregatan tetingkap dan logik penyambungan ciri. Ia boleh digunakan untuk menjana data latihan. Sebagai contoh, dalam contoh yang diperkenalkan sebelum ini, jika anda perlu menggabungkan sampel latihan dengan ciri daripada jadual dimensi berbeza untuk mendapatkan data latihan sebenar, anda boleh menggunakan DerivedFeatureView untuk melengkapkan ini.

② SlidingFeatureView menyokong ciri menyatakan yang dikira dengan tetingkap gelongsor. Baris jadual ciri keluarannya dan jadual ciri inputnya tidak semestinya satu dengan satu. Ini kerana nilai ciri yang dikira oleh tetingkap gelongsor akan berubah dari semasa ke semasa walaupun tiada input baharu. SlidingFeatureView boleh digunakan untuk mengekalkan ciri yang dijana masa nyata dan mengeluarkannya ke kedai ciri dalam talian, seperti Redis, untuk inferens dalam talian. Sebagai contoh, kami boleh menggunakan SlidingFeatureView untuk mengira bilangan kali setiap pengguna mengklik pada halaman web tertentu dalam dua minit terakhir dan mengemas kini nilai ciri kepada Redis dalam masa nyata Kemudian pautan pengesyoran iklan boleh menanyakan nilai ciri ini dalam talian untuk alasan dalam talian.

③ OnDemandFeatureView boleh digunakan dengan Perkhidmatan Ciri untuk menyokong pengiraan ciri dalam talian. Contohnya, apabila menggunakan Amap, pembangun mungkin ingin mengira kelajuan dan arah pergerakan pengguna berdasarkan lokasi fizikal semasa pengguna dan lokasi fizikal apabila permintaan terakhir dihantar, selepas menerima permintaan pengguna, untuk membantu dalam pengesyoran keputusan. Ciri ini mesti dikira dalam talian apabila menerima permintaan pengguna. OnDemandFeatureView boleh digunakan untuk menyokong senario sedemikian.

Transform menyatakan logik pengiraan ciri. FeatHub pada masa ini menyokong 5 jenis logik pengiraan ciri berikut:

① Ungkapan membolehkan pengguna menyatakan satu baris logik pengiraan ciri berdasarkan bahasa DSL. Keupayaan ekspresinya hampir dengan pernyataan pilih dalam bahasa SQL, dan ia boleh menyokong penambahan, penolakan, pendaraban dan pembahagian serta panggilan fungsi terbina dalam, membolehkan pembangun yang biasa dengan SQL untuk bermula dengan cepat.

② Sertai menyatakan logik penyambungan ciri. Pembangun boleh menentukan maklumat seperti nama jadual dimensi dan nama ciri yang akan disambungkan.

③ PythonUDF menyokong fungsi Python yang ditentukan pengguna untuk mengira ciri.

④ OverWindow menyatakan logik pengagregatan Over window. Contohnya, apabila menerima satu baris data, pengguna ingin mengagregatkan 5 baris data sebelumnya dan mengira bilangan keping data yang sepadan dengan peraturan tertentu.

⑤ SlidingWindow menyatakan logik pengagregatan tetingkap gelongsor.

Seperti yang anda boleh lihat daripada rajah di atas, biasanya tugas ETL ciri akan membaca ciri daripada jadual sumber ciri, menjana ciri baharu melalui logik pengiraan berbilang ciri dan The generated ciri adalah output ke jadual hasil ciri. Jadual sumber ciri boleh disambungkan ke kedai ciri yang berbeza, seperti FileSystem, Kafka, Hive, dsb. Begitu juga, jadual hasil ciri juga boleh disambungkan ke storan ciri seperti FileSystem, Kafka dan Redis.

Pemproses termasuk LocalProcessor, FlinkProcessor dan SparkProcessor, yang boleh menggunakan sumber fizikal yang berdiri sendiri, gugusan Flink yang diedarkan dan gugusan Spark yang diedarkan masing-masing untuk melaksanakan logik pengiraan ciri yang ditentukan pengguna.

3. Paparan API FeatHub

1. Fungsi pengiraan ciri

Selepas memperkenalkan seni bina dan konsep teras FeatHub, kami akan Beberapa contoh program digunakan untuk menunjukkan ekspresif dan kemudahan penggunaan FeatHub SDK. Untuk SDK pembangunan ciri, keupayaan terasnya ialah cara menyatakan logik pengiraan ciri baharu. FeatHub SDK menyokong penyambungan ciri, pengagregatan tetingkap, panggilan fungsi terbina dalam dan keupayaan Python tersuai Pada masa hadapan, ia juga akan menyokong panggilan UDF berdasarkan JAVA atau C++.

Gambar di atas menunjukkan coretan kod penyambungan ciri. Dalam contoh ini, diandaikan bahawa terdapat data sampel positif dan negatif asal dalam HDFS, yang merekodkan gelagat pembelian pengguna. Kami ingin mendapatkan lagi harga produk apabila pengguna membeli setiap produk. Jadual price_updates mengekalkan data tentang perubahan harga produk. Setiap kali harga produk berubah, satu baris data akan dijana dalam jadual price_updates, termasuk ID produk dan harga produk terkini. Kita boleh menggunakan JoinTransform dan menetapkan table_name=price_updates, feature_name=price, dan key=item_id untuk menyatakan logik penyambungan ciri yang sepadan. Dengan cara ini, FeatHub boleh mencari baris dengan item_id yang diberikan dalam price_updates dan mencari nilai harga yang paling sesuai berdasarkan cap masa untuk menyambungkannya ke dalam jadual data sampel.

Coretan kod pengagregatan atas tetingkap menunjukkan cara menggunakan OverWindowTransform untuk mengira ciri. Pengguna boleh menggunakan expr=”item_counts * price” dan agg_fun=”SUM” untuk mengira jumlah penggunaan dalam tetingkap masa terkini berdasarkan kuantiti dan harga item yang dibeli. Panjang tingkap ialah 2 minit. group_by_keys=["user_id"] bermakna kami akan mengira jumlah penggunaan yang sepadan secara berasingan untuk setiap pengguna.

​Penggabungan tetingkap gelongsor adalah serupa dengan Pengagregatan atas tetingkap Satu-satunya perbezaan dalam API ialah saiz_langkah boleh ditentukan tambahan. Jika step_size=1 minit, tetingkap akan meluncur dan menjana nilai ciri baharu setiap minit.

Coretan kod panggilan fungsi terbina dalam menunjukkan cara menggunakan bahasa DSL untuk menyatakan penambahan, penolakan, pendaraban, pembahagian dan panggilan UDF. Katakan data input mengandungi cap masa pengambilan dan penghantaran teksi. Kita boleh menukar cap masa untuk mengambil dan menurunkan penumpang kepada masa zaman jenis integer dengan memanggil fungsi terbina dalam UNIX_TIMESTAMP, dan kemudian menolak masa zaman yang diperolehi untuk mendapatkan panjang setiap perjalanan, yang boleh digunakan sebagai ciri untuk latihan dan inferens seterusnya.

Dalam coretan kod yang dipanggil oleh PythonUDF, pengguna boleh menyesuaikan fungsi Python untuk melaksanakan pemprosesan sewenang-wenangnya pada ciri input, seperti menjana rentetan huruf kecil.

Melalui coretan kod di atas, kita dapat melihat bahawa API FeatHub agak mudah dan mudah digunakan. Pengguna hanya perlu menetapkan parameter yang diperlukan untuk logik pengiraan tanpa mengetahui butiran enjin pemprosesan.

2. Contoh senario

Dalam senario sampel di atas, pengguna mempunyai dua sumber data. Peristiwa Pembeliannya mengandungi data sampel produk yang dibeli oleh pengguna, yang boleh datang daripada Kafka atau FileSystem Peristiwa Harga Item mengandungi data tentang perubahan harga produk. Setiap kali harga item berubah, satu baris data akan dijana dalam Peristiwa Harga Item, termasuk ID item dan harga item terkini. Kami berharap untuk setiap sampel data pengguna yang membeli produk, kami boleh mengira jumlah penggunaan pengguna dalam dua minit terakhir apabila tingkah laku itu berlaku dan menggunakannya sebagai ciri untuk membantu membuat kesimpulan sama ada pengguna akan membeli produk tertentu . Untuk menjana ciri ini, anda boleh menggunakan logik pengiraan yang diterangkan dalam rajah di atas untuk menggabungkan ciri harga terlebih dahulu dalam Peristiwa Harga Item untuk Membeli Acara menggunakan item_id sebagai join_key. Kemudian agregat berdasarkan tetingkap masa dan menggunakan user_id sebagai group_by _keys untuk mengira jumlah penggunaan setiap pengguna dalam dua minit terakhir.

3. Contoh kod

Coretan kod di atas menunjukkan langkah-langkah yang perlu dilengkapkan untuk contoh aplikasi FeatHub.

① Pertama, pengguna perlu mencipta FeatHubClient dan menetapkan processor_type. Jika ia adalah percubaan tempatan, ia boleh ditetapkan kepada Setempat. Jika ia adalah penggunaan pengeluaran teragih jauh, ia boleh ditetapkan kepada Flink.

② Pengguna perlu mencipta Sumber untuk membaca data Contohnya, anda boleh menggunakan FileSystemSource untuk membaca data dalam sistem storan luar talian, atau menggunakan KafkaSource untuk membaca data masa nyata dalam sistem storan dekat talian. Dalam FileSystemSource, pengguna boleh menentukan maklumat seperti format_data, skema, lokasi fail, dsb. Perlu diingat bahawa pengguna boleh menyediakan medan_setem masa dan format_setem masa untuk menyatakan lajur yang mewakili masa dalam jadual sumber data dan format penghuraian yang sepadan masing-masing. FeatHub akan menggunakan maklumat ini untuk melengkapkan pengiraan ciri titik dalam masa yang betul untuk mengelakkan masalah persimpangan ciri.

③ Pengguna boleh mencipta FeatureView untuk menyatakan logik penyambungan dan pengagregatan ciri. Jika anda ingin sambung, pengguna boleh menggunakan item_price_events.price untuk menyatakan ciri yang anda ingin sambung. FeatHub akan mencari jadual bernama item_price_events dan mendapatkan ciri bernama harga daripadanya. Pengguna juga boleh menggunakan OverWindowTransform untuk melengkapkan pengagregatan Over window dan mentakrifkan ciri bernama total_payment_last_two_minutes. Di mana window_size=2 minit bermakna menggunakan ungkapan yang ditentukan dan fungsi agregat untuk mengira ciri untuk data dalam masa dua minit.

④ Untuk FeatureView yang ditentukan, jika pengguna ingin membangun dan bereksperimen secara tempatan, dan menggunakan perpustakaan algoritma scikit-learn untuk latihan pada satu mesin, dia boleh menggunakan to_pandas() API Untuk memasukkan data ke dalam memori mesin tunggal dalam format Pandas DataFrame.

⑤ Apabila pengguna perlu melengkapkan penggunaan pengeluaran ciri, mereka boleh menggunakan FileSystemSink untuk menentukan storan ciri luar talian untuk menyimpan data. Kemudian panggil execute_insert() untuk mengeluarkan ciri kepada Sink yang ditentukan.

Nilai asas FeatHub adalah untuk menyediakan SDK untuk memudahkan pengguna membangunkan ciri dan enjin pelaksanaan untuk mengira ciri. Selain itu, FeatHub juga akan menyediakan pengoptimuman prestasi enjin pelaksanaan, membolehkan pengguna memperoleh lebih banyak faedah semasa fasa penggunaan ciri. Contohnya, untuk ciri berdasarkan pengagregatan tetingkap gelongsor, jika pada masa ini anda menggunakan API Flink asli untuk mengira, Flink akan mengeluarkan nilai ciri yang sepadan pada setiap saiz_langkah gelongsor, tidak kira sama ada nilai ciri telah berubah. Untuk tetingkap gelongsor dengan window_size=1 jam dan step_size=1 saat, Flink mungkin mengeluarkan nilai ciri yang sama dalam kebanyakan kes. Ini akan membazir trafik rangkaian, storan hiliran dan sumber lain. FeatHub menyokong pengguna untuk mengkonfigurasi gelagat tetingkap gelongsor, membenarkan tetingkap gelongsor hanya mengeluarkan ciri apabila nilai ciri berubah untuk mengoptimumkan penggunaan sumber kerja pengiraan ciri.

Selain itu, FeatHub akan mengoptimumkan lagi memori dan penggunaan CPU bagi tingkap gelongsor. Dalam sesetengah senario, pengguna akan menerima banyak ciri tetingkap gelongsor yang serupa. Ciri-ciri ini hanya berbeza dalam saiz tetingkap. Sebagai contoh, kami mungkin ingin mendapatkan jumlah amaun yang dibelanjakan oleh setiap pengguna untuk pembelian dalam 1 minit, 5 minit dan 10 minit terakhir. Jika API Flink asli digunakan untuk pengiraan, tugas itu mungkin menggunakan tiga operator pengagregatan untuk mengira ketiga-tiga ciri ini masing-masing. Setiap operator pengagregatan akan mempunyai ruang memori yang berasingan. Memandangkan data dan logik pengiraan yang diproses oleh pengendali ini mempunyai pertindihan yang besar, FeatHub boleh menggunakan pengendali tersuai untuk melengkapkan pengiraan ciri ini secara seragam untuk mencapai matlamat menjimatkan memori dan sumber CPU.

FeatHub kini merupakan sumber terbuka di GitHub dan boleh menyokong beberapa fungsi LocalProcessor dan FlinkProcessor asas. Kami akan menambah baik lagi fungsi teras FeatHub untuk memudahkan pembangunan dan pelaksanaan kejuruteraan ciri pengguna. Ini termasuk menyokong storan luar talian dan storan dalam talian yang lebih biasa digunakan, dok dengan Notebook, menyediakan UI Web untuk menggambarkan metadata ciri, menyokong pengguna untuk mendaftar, mencari dan menggunakan semula ciri, dan menyokong penggunaan Spark sebagai enjin pelaksanaan FeatHub.

Asas kod FeatHub: ​https://github.com/alibaba/FeatHub​

Sampel kod FeatHub:​https://github.com/flink-extended/FeatHub-examples​

Pangkalan kod FeatHub kini diletakkan dalam direktori github/alibaba. Untuk memudahkan semua orang belajar menggunakan FeatHub dan mencari serta merujuk kepada coretan kod dengan pantas yang memenuhi keperluan senario yang diperlukan, kami menyediakan contoh kod tambahan dalam pustaka kod flink-extended/feathub-examples, yang anda boleh bebas menggunakan dan mencuba. Semua orang dialu-alukan untuk memberikan maklum balas dan menyumbang PR.

4. Sesi Soal Jawab

S1: Semasa penyertaan point_in_time, adakah persimpangan ciri disebabkan oleh kelewatan gangguan data atau penulisan manual Join?

J1: Pada dasarnya, walaupun data tidak tersusun, jika medan cap waktu tidak diambil kira semasa menyertai, ia boleh menyebabkan tidak teratur. Dalam senario sebenar, data sumber mungkin juga tidak teratur. Pada masa ini, anda boleh menggunakan strategi tera air yang serupa dengan yang terdapat dalam Flink untuk menunggu data lewat tiba dan mengurangkan kesan keterlaluan pesanan. Di samping itu, kami boleh menggunakan kerja luar talian biasa untuk mengisi semula data ciri dalam talian, dengan itu mengurangkan lagi kesan gangguan data.

S2: Selepas FeatHub dilancarkan, bagaimana untuk menjana data latihan lepas dan ciri yang sepadan dengannya? Adakah FeatHub menyokong main balik data sejarah?

A2: FeatHub API boleh menyokong main balik, tetapi bahagian fungsi ini belum lagi disahkan pengeluaran. FeatHub akan menyokong penggunaan Flink dan Spark sebagai enjin pelaksanaan, jadi keupayaan pengkomputeran Flink dan Spark boleh digunakan semula untuk melengkapkan main balik data sejarah. Sebagai contoh, kita boleh memulakan kerja Spark, menetapkan Sumber untuk memproses semua data pada HDFS pada bulan lalu, melaksanakan penyambungan ciri yang ditentukan dan logik pengagregatan, dan kemudian mengeluarkan ciri yang dikira.

S3. FeatHub hanya bertanggungjawab untuk pengiraan ciri luar talian, bagaimana untuk memproses beberapa ciri dalam talian?

A3: Pengiraan ciri dibahagikan kepada luar talian, garisan hampir dan dalam talian Flink ialah enjin pelaksanaan garisan hampir yang boleh mengira ciri seperti bilangan klik pengguna dalam 5 terakhir. minit dalam masa nyata Pada masa yang sama pengiraan luar talian juga boleh disokong. Oleh itu FeatHub boleh menyokong pengiraan ciri luar talian dan garisan dekat. FeatHub merancang untuk menyokong pengiraan ciri dalam talian pada masa hadapan, menggunakan seni bina berdasarkan Perkhidmatan Ciri untuk mengira ciri yang dinyatakan oleh OnDemandFeatureView.

S4: FeatHub menyediakan perkhidmatan dalam Alibaba Cloud Apakah sokongan ekologi huluan dan hiliran semasa, seperti ODPS, dsb.?

A4: FeatHub akan menyokong semua Source/Sink yang disokong oleh Flink, termasuk ODPS, Holo dan perkhidmatan lain yang disediakan oleh Alibaba Cloud. Pada masa ini FeatHub hanya menyokong Kafka dan FileSystem. Kami akan menambah lebih banyak sokongan storan secara beransur-ansur.

Atas ialah kandungan terperinci Amalan pembinaan platform kejuruteraan ciri masa nyata yang menyepadukan penstriman dan batching. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!