Mengapa Anda harus menggunakan Presto untuk analitik ad hoc

Presto! Ini bukan hanya mantra untuk menggairahkan audiens Anda setelah trik sulap, tetapi juga nama yang semakin sering digunakan saat membahas cara mengaduk data besar. Meskipun ada banyak penerapan Presto di alam liar, teknologinya - mesin kueri SQL terdistribusi yang mendukung semua jenis sumber data - tetap asing bagi banyak pengembang dan analis data yang dapat memanfaatkan penggunaannya.

Pada artikel ini, saya akan membahas Presto: apa itu, dari mana asalnya, bagaimana perbedaannya dari solusi data warehousing lainnya, dan mengapa Anda harus mempertimbangkannya untuk solusi big data Anda.

Presto vs. Sarang

Presto berasal dari Facebook pada tahun 2012. Bersumber terbuka pada tahun 2013 dan dikelola oleh Presto Foundation (bagian dari Linux Foundation), Presto telah mengalami peningkatan popularitas yang stabil selama bertahun-tahun. Saat ini, beberapa perusahaan telah membangun model bisnis di sekitar Presto, seperti Ahana, dengan penawaran analitik ad hoc berbasis PrestoDB.

Presto dibangun sebagai sarana untuk memberikan akses kepada pengguna akhir ke kumpulan data yang sangat besar untuk melakukan analisis ad hoc. Sebelum Presto, Facebook akan menggunakan Hive (juga dibuat oleh Facebook dan kemudian disumbangkan ke Apache Software Foundation) untuk melakukan analisis semacam ini. Seiring bertambahnya kumpulan data Facebook, Hive dianggap kurang interaktif (baca: terlalu lambat). Ini sebagian besar karena dasar dari Hive adalah MapReduce, yang, pada saat itu, membutuhkan kumpulan data perantara untuk disimpan ke HDFS. Itu berarti banyak I / O ke disk untuk data yang akhirnya dibuang. 

Presto mengambil pendekatan berbeda untuk mengeksekusi kueri tersebut untuk menghemat waktu. Alih-alih menyimpan data perantara pada HDFS, Presto memungkinkan Anda untuk menarik data ke dalam memori dan melakukan operasi pada data di sana alih-alih menyimpan semua set data perantara ke disk. Jika kedengarannya tidak asing, Anda mungkin pernah mendengar tentang Apache Spark (atau sejumlah teknologi lain di luar sana) yang memiliki konsep dasar yang sama untuk menggantikan teknologi berbasis MapReduce secara efektif. Dengan menggunakan Presto, saya akan menyimpan data di tempatnya (di Hadoop atau, seperti yang akan kita lihat, di mana saja) dan menjalankan eksekusi dalam memori di seluruh sistem terdistribusi kami, mengacak data antar server sesuai kebutuhan. Saya menghindari menyentuh disk apa pun, yang pada akhirnya mempercepat waktu eksekusi kueri.

Bagaimana Presto bekerja

Berbeda dari gudang data tradisional, Presto disebut sebagai mesin eksekusi kueri SQL. Gudang data mengontrol bagaimana data ditulis, di mana data itu berada, dan bagaimana data itu dibaca. Setelah Anda memasukkan data ke gudang, akan sulit untuk mendapatkannya kembali. Presto mengambil pendekatan lain dengan memisahkan penyimpanan data dari pemrosesan, sambil memberikan dukungan untuk bahasa kueri SQL ANSI yang sama dengan yang biasa Anda gunakan.

Pada intinya, Presto mengeksekusi kueri melalui kumpulan data yang disediakan oleh plug-in, khususnya Konektor. Konektor menyediakan sarana bagi Presto untuk membaca (dan bahkan menulis) data ke sistem data eksternal. Konektor Hive adalah salah satu konektor standar, menggunakan metadata yang sama yang akan Anda gunakan untuk berinteraksi dengan HDFS atau Amazon S3. Karena konektivitas ini, Presto adalah pengganti drop-in untuk organisasi yang menggunakan Hive saat ini. Ia mampu membaca data dari skema dan tabel yang sama menggunakan format data yang sama - ORC, Avro, Parquet, JSON, dan banyak lagi. Selain konektor Hive, Anda akan menemukan konektor untuk Cassandra, Elasticsearch, Kafka, MySQL, MongoDB, PostgreSQL, dan banyak lainnya. Konektor dikontribusikan ke Presto setiap saat, memberikan Presto potensi untuk dapat mengakses data di mana pun ia berada.

Keuntungan dari model penyimpanan terpisah ini adalah bahwa Presto dapat memberikan tampilan gabungan tunggal dari semua data Anda - di mana pun ia berada. Hal ini meningkatkan kemampuan kueri ad hoc ke tingkat yang belum pernah dicapai sebelumnya, sekaligus memberikan waktu kueri interaktif pada kumpulan data Anda yang besar (selama Anda memiliki infrastruktur untuk mencadangkannya, di tempat atau di awan).

Mari kita lihat bagaimana Presto diterapkan dan bagaimana cara menjalankan kueri Anda. Presto ditulis dalam Java, dan oleh karena itu membutuhkan JDK atau JRE untuk dapat memulai. Presto digunakan sebagai dua layanan utama, Koordinator tunggal dan banyak Pekerja . Layanan Koordinator secara efektif adalah otak dari operasi, menerima permintaan kueri dari klien, mengurai kueri, membuat rencana eksekusi, dan kemudian menjadwalkan pekerjaan yang harus dilakukan di banyak layanan Pekerja. Setiap Pekerja memproses sebagian dari keseluruhan kueri secara paralel, dan Anda dapat menambahkan layanan Pekerja ke penerapan Presto agar sesuai dengan permintaan Anda. Setiap sumber data dikonfigurasikan sebagai katalog , dan Anda bisa membuat kueri sebanyak mungkin katalog yang Anda inginkan di setiap kueri.

Ahana

Presto diakses melalui driver JDBC dan terintegrasi dengan hampir semua alat yang dapat terhubung ke database menggunakan JDBC. Antarmuka baris perintah Presto, atau CLI, sering kali menjadi titik awal saat mulai menjelajahi Presto. Bagaimanapun, klien terhubung ke Koordinator untuk mengeluarkan kueri SQL. Kueri tersebut diurai dan divalidasi oleh Koordinator, dan dibuat menjadi rencana eksekusi kueri. Rencana ini merinci bagaimana kueri akan dieksekusi oleh pekerja Presto. Rencana kueri (biasanya) dimulai dengan satu atau beberapa pemindaian tabel untuk menarik data dari penyimpanan data eksternal Anda. Kemudian ada serangkaian operator untuk melakukan proyeksi, filter, penggabungan, pengelompokan berdasarkan, perintah, dan semua jenis operasi lainnya. Rencana diakhiri dengan hasil akhir yang ditetapkan dikirim ke klien melalui Koordinator.Rencana kueri ini sangat penting untuk memahami bagaimana Presto menjalankan kueri Anda, serta mampu membedah kinerja kueri dan menemukan potensi kemacetan.

Contoh kueri presto

Mari kita lihat kueri dan rencana kueri yang sesuai. Saya akan menggunakan kueri TPC-H, alat pembandingan umum yang digunakan untuk database SQL. Singkatnya, TPC-H mendefinisikan satu set tabel dan kueri standar untuk menguji kelengkapan bahasa SQL serta sarana untuk mengukur berbagai database. Data dirancang untuk kasus penggunaan bisnis, yang berisi pesanan penjualan item yang dapat disediakan oleh persediaan dalam jumlah besar. Presto menyediakan Konektor TPC-H yang menghasilkan data dengan cepat - alat yang sangat berguna saat memeriksa Presto.

PILIH

  SUM (l.extendedprice * l.discount) pendapatan AS

DARI lineitem l

DIMANA

  l.shipdate> = DATE '1994-01-01'

   DAN l. Tanggal pengiriman <DATE '1994-01-01' + INTERVAL '1' YEAR

   DAN l. Diskon ANTARA .06 - 0.01 DAN .06 + 0.01

   DAN l. Kuantitas <24;

Ini adalah kueri nomor enam, yang dikenal sebagai Kueri Perubahan Pendapatan Peramalan. Mengutip dokumentasi TPC-H, "kueri ini menghitung jumlah peningkatan pendapatan yang akan dihasilkan dari penghapusan diskon di seluruh perusahaan tertentu dalam rentang persentase tertentu di tahun tertentu."

Presto memecah kueri menjadi satu atau beberapa tahapan, juga disebut fragmen , dan setiap tahapan berisi beberapa operator . Operator adalah fungsi tertentu dari rencana yang dijalankan, baik pemindaian, filter, gabungan, atau pertukaran. Pertukaran sering memecah tahapan. Pertukaran adalah bagian dari rencana di mana data dikirim melalui jaringan ke pekerja lain di cluster Presto. Ini adalah cara Presto mengelola untuk memberikan skalabilitas dan kinerjanya - dengan membagi kueri menjadi beberapa operasi yang lebih kecil yang dapat dilakukan secara paralel dan memungkinkan data untuk didistribusikan kembali ke seluruh cluster untuk melakukan penggabungan, pengelompokan, dan pengurutan kumpulan data. Mari kita lihat rencana kueri terdistribusi untuk kueri ini. Perhatikan bahwa rencana kueri dibaca dari bawah ke atas.

 Fragmen 0 [SINGLE]

     - Output [pendapatan] => [jumlah: ganda]       

             pendapatan: = jumlah   

         - Agregat (FINAL) => [jumlah: ganda]         

                 jumlah: = "presto.default.sum" ((sum_4))          

             - LocalExchange [SINGLE] () => [jumlah_4: ganda]  

                 - RemoteSource [1] => [sum_4: double]      

 Fragmen 1 

     - Agregat (PARTIAL) => [sum_4: double]  

             sum_4: = "presto.default.sum" ((expr))  

         - ScanFilterProject [table = TableHandle {connectorId = 'tpch', connectorHandle = "lineitem: sf1.0", layout = "Opsional [lineitem: sf1.0]"}, grouped = false, filterPredicate = ((diskon BETWEEN (DOUBLE 0,05) ) AND (DOUBLE 0,07)) AND ((kuantitas) = ​​(DATE 1994-01-01)) AND ((shipdate) [expr: double]

                 expr: = (extendedprice) * (diskon)   

                 extendedprice := tpch:extendedprice

                 discount := tpch:discount         

                 shipdate := tpch:shipdate 

                 quantity := tpch:quantity  

This plan has two fragments containing several operators. Fragment 1 contains two operators. The ScanFilterProject scans data, selects the necessary columns (called projecting) needed to satisfy the predicates, and calculates the revenue lost due to the discount for each line item. Then a partial Aggregate operator calculates the partial sum. Fragment 0 contains a LocalExchange operator that receives the partial sums from Fragment 1, and then the final aggregate to calculate the final sum. The sum is then output to the client.

When executing the query, Presto scans data from the external data source in parallel, calculates the partial sum for each split, and then ships the result of that partial sum to a single worker so it can perform the final aggregation. Running this query, I get about $123,141,078.23 in lost revenue due to the discounts.

      revenue       

----------------------

 1.2314107822830005E8

As queries grow more complex, such as joins and group-by operators, the query plans can get very long and complicated. With that said, queries break down into a series of operators that can be executed in parallel against data that is held in memory for the lifetime of the query.

As your data set grows, you can grow your Presto cluster in order to maintain the same expected runtimes. This performance, combined with the flexibility to query virtually any data source, can help empower your business to get more value from your data than ever before — all while keeping the data where it is and avoiding expensive transfers and engineering time to consolidate your data into one place for analysis. Presto!

Ashish Tadose is co-founder and principal software engineer at Ahana. Passionate about distributed systems, Ashish joined Ahana from WalmartLabs, where as principal engineer he built a multicloud data acceleration service powered by Presto while leading and architecting other products related to data discovery, federated query engines, and data governance. Previously, Ashish was a senior data architect at PubMatic where he designed and delivered a large-scale adtech data platform for reporting, analytics, and machine learning. Earlier in his career, he was a data engineer at VeriSign. Ashish is also an Apache committer and contributor to open source projects.

Forum Teknologi Baru menyediakan tempat untuk mengeksplorasi dan mendiskusikan teknologi perusahaan yang sedang berkembang secara mendalam dan luas. Pemilihannya subjektif, berdasarkan pilihan teknologi yang kami yakini penting dan paling menarik bagi pembaca. tidak menerima jaminan pemasaran untuk publikasi dan berhak untuk mengedit semua konten yang dikontribusikan. Kirim semua pertanyaan ke [email protected]