Dremio: Analisis data yang lebih sederhana dan lebih cepat

Jacques Nadeau adalah CTO dan salah satu pendiri Dremio.

Sekarang adalah waktu yang tepat untuk menjadi pengembang. Selama dekade terakhir, keputusan tentang teknologi telah berpindah dari ruang rapat ke pengembang inovatif, yang membangun dengan sumber terbuka dan membuat keputusan berdasarkan manfaat dari proyek yang mendasarinya daripada hubungan komersial yang disediakan oleh vendor. Proyek-proyek baru telah muncul yang berfokus pada membuat pengembang lebih produktif, dan lebih mudah untuk dikelola dan diskalakan. Ini berlaku untuk hampir setiap lapisan tumpukan teknologi. Hasilnya adalah saat ini pengembang memiliki peluang yang hampir tak terbatas untuk mengeksplorasi teknologi baru, arsitektur baru, dan model penerapan baru.

Melihat lapisan data secara khusus, sistem NoSQL seperti MongoDB, Elasticsearch, dan Cassandra telah mendorong batasan dalam hal ketangkasan, skalabilitas, dan kinerja untuk aplikasi operasional, masing-masing dengan model data dan pendekatan skema yang berbeda. Dalam prosesnya, banyak tim pengembangan beralih ke model layanan mikro, menyebarkan data aplikasi ke banyak sistem dasar yang berbeda.

Dalam hal analitik, sumber data lama dan baru telah menemukan jalan mereka ke dalam campuran gudang data tradisional dan data lake, beberapa di Hadoop, dan lainnya di Amazon S3. Dan kebangkitan platform streaming data Kafka menciptakan cara berpikir yang sama sekali berbeda tentang pergerakan data dan analisis data yang sedang bergerak.

Dengan data dalam begitu banyak teknologi berbeda dan format yang mendasari, analitik pada data modern sulit dilakukan. Alat BI dan analitik seperti Tableau, Power BI, R, Python, dan model pembelajaran mesin dirancang untuk dunia tempat datanya berada dalam satu database relasional berkinerja tinggi. Selain itu, pengguna alat ini - analis bisnis, ilmuwan data, dan model pembelajaran mesin - menginginkan kemampuan untuk mengakses, menjelajahi, dan menganalisis data sendiri, tanpa ketergantungan pada TI.

Memperkenalkan data fabric Dremio

Alat BI, sistem sains data, dan model pembelajaran mesin bekerja paling baik saat data berada dalam satu database relasional berkinerja tinggi. Sayangnya, data bukanlah tempat tinggal hari ini. Akibatnya, TI tidak punya pilihan selain menjembatani kesenjangan itu melalui kombinasi pengembangan ETL khusus dan produk berpemilik. Di banyak perusahaan, tumpukan analitik mencakup lapisan berikut:

  • Pementasan data . Data dipindahkan dari berbagai database operasional ke dalam satu area penahapan seperti klaster Hadoop atau layanan penyimpanan cloud (misalnya, Amazon S3).
  • Gudang data . Meskipun dimungkinkan untuk mengeksekusi kueri SQL langsung di Hadoop dan penyimpanan cloud, sistem ini tidak dirancang untuk memberikan kinerja interaktif. Oleh karena itu, sebagian dari data biasanya dimuat ke dalam gudang data relasional atau database MPP.
  • Kubus, tabel agregasi, dan ekstrak BI . Untuk memberikan kinerja interaktif pada kumpulan data besar, data harus diagregasi sebelumnya dan / atau diindeks dengan membangun kubus di sistem OLAP atau tabel agregasi terwujud di gudang data.

Arsitektur multi-layer ini menghadirkan banyak tantangan. Ini kompleks, rapuh, dan lambat, serta menciptakan lingkungan di mana konsumen data sepenuhnya bergantung pada TI.

Dremio memperkenalkan tingkatan baru dalam analisis data yang kami sebut sebagai data fabric swalayan. Dremio adalah proyek open source yang memungkinkan analis bisnis dan ilmuwan data untuk mengeksplorasi dan menganalisis data apa pun kapan pun, terlepas dari lokasi, ukuran, atau strukturnya. Dremio menggabungkan arsitektur scale-out dengan eksekusi dan akselerasi kolom untuk mencapai kinerja interaktif pada volume data apa pun, sekaligus memungkinkan TI, ilmuwan data, dan analis bisnis untuk membentuk data secara mulus sesuai dengan kebutuhan bisnis.

Dibangun di atas Apache Arrow, Apache Parquet, dan Apache Calcite

Dremio menggunakan penyimpanan dan eksekusi kolom berkinerja tinggi, didukung oleh Apache Arrow (berbentuk kolom dalam memori) dan Apache Parquet (berbentuk kolom pada disk). Dremio juga menggunakan Apache Calcite untuk penguraian SQL dan pengoptimalan kueri, membangun di pustaka yang sama seperti banyak mesin berbasis SQL lainnya, seperti Apache Hive.

Apache Arrow adalah proyek open source yang memungkinkan pemrosesan dan pertukaran data dalam memori berbentuk kolom. Panah dibuat oleh Dremio, dan termasuk pelaku dari berbagai perusahaan termasuk Cloudera, Databricks, Hortonworks, Intel, MapR, dan Two Sigma.

Dremio adalah mesin eksekusi pertama yang dibangun dari bawah ke atas di Apache Arrow. Secara internal, data dalam memori dipertahankan off-heap dalam format Arrow, dan akan segera ada API yang mengembalikan hasil kueri sebagai buffer memori Arrow.

Berbagai proyek lain telah menggunakan Arrow juga. Python (Pandas) dan R adalah di antara proyek-proyek ini, yang memungkinkan ilmuwan data bekerja lebih efisien dengan data. Misalnya, Wes McKinney, pencipta pustaka Pandas yang populer, baru-baru ini mendemonstrasikan bagaimana Arrow memungkinkan pengguna Python membaca data ke dalam Pandas dengan kecepatan lebih dari 10 GB / dtk.

Bagaimana Dremio mengaktifkan data swalayan

Selain kemampuan untuk bekerja secara interaktif dengan dataset mereka, data engineer, business analyst, dan data scientist juga membutuhkan cara untuk melakukan kurasi data agar sesuai dengan kebutuhan proyek tertentu. Ini adalah perubahan mendasar dari model berpusat pada IT, di mana konsumen data memulai permintaan untuk set data dan menunggu TI untuk memenuhi permintaan mereka beberapa minggu atau bulan kemudian. Dremio memungkinkan model layanan mandiri, di mana konsumen data menggunakan kemampuan kurasi data Dremio untuk secara kolaboratif menemukan, mengkurasi, mempercepat, dan berbagi data tanpa bergantung pada TI.

Semua kemampuan ini dapat diakses melalui UI berbasis web yang modern, intuitif:

  • Temukan . Dremio menyertakan katalog data terpadu tempat pengguna dapat menemukan dan menjelajahi kumpulan data fisik dan virtual. Katalog data secara otomatis diperbarui ketika sumber data baru ditambahkan, dan sebagai sumber data dan set data virtual berkembang. Semua metadata diindeks dalam indeks berkinerja tinggi, dapat dicari, dan diekspos ke pengguna di seluruh antarmuka Dremio.
  • Kurasi . Dremio memungkinkan pengguna untuk melakukan kurasi data dengan membuat kumpulan data virtual. Berbagai transformasi tunjuk dan klik didukung, dan pengguna tingkat lanjut dapat menggunakan sintaks SQL untuk menentukan transformasi yang lebih kompleks. Saat kueri dijalankan dalam sistem, Dremio belajar tentang data, memungkinkannya untuk merekomendasikan berbagai transformasi seperti penggabungan dan konversi tipe data.
  • Dremio mampu mempercepat set data hingga 1000x melebihi kinerja sistem sumber. Pengguna dapat memilih kumpulan data yang menurut mereka harus lebih cepat, dan heuristik Dremio akan mempertimbangkan suara ini dalam menentukan kumpulan data mana yang akan dipercepat. Secara opsional, administrator sistem dapat secara manual menentukan kumpulan data mana yang akan dipercepat.
  • Dremio memungkinkan pengguna untuk berbagi data dengan aman dengan pengguna dan grup lain. Dalam model ini sekelompok pengguna dapat berkolaborasi pada set data virtual yang akan digunakan untuk pekerjaan analitik tertentu. Bergantian, pengguna dapat mengunggah data mereka sendiri, seperti spreadsheet Excel, untuk bergabung ke kumpulan data lain dari katalog perusahaan. Pembuat kumpulan data virtual dapat menentukan pengguna mana yang dapat membuat kueri atau mengedit kumpulan data virtual mereka. Ini seperti Google Docs untuk data Anda.

Cara kerja akselerasi data Dremio

Dremio menggunakan representasi fisik yang sangat dioptimalkan dari data sumber yang disebut Refleksi Data. Reflection Store dapat hidup di HDFS, MapR-FS, penyimpanan cloud seperti S3, atau penyimpanan terpasang langsung (DAS). Ukuran Reflection Store dapat melebihi memori fisik. Arsitektur ini memungkinkan Dremio untuk mempercepat lebih banyak data dengan biaya yang lebih rendah, menghasilkan rasio cache hit yang jauh lebih tinggi dibandingkan dengan arsitektur tradisional yang hanya menggunakan memori. Refleksi Data secara otomatis digunakan oleh pengoptimal berbasis biaya pada waktu kueri.

Refleksi Data tidak terlihat oleh pengguna akhir. Tidak seperti kubus OLAP, tabel agregasi, dan ekstrak BI, pengguna tidak secara eksplisit menyambungkan ke Refleksi Data. Alih-alih, pengguna mengeluarkan kueri dengan model logis, dan pengoptimal Dremio secara otomatis mempercepat kueri dengan memanfaatkan Refleksi Data yang sesuai untuk kueri berdasarkan analisis biaya pengoptimal.

Ketika pengoptimal tidak dapat mempercepat kueri, Dremio menggunakan mesin eksekusi terdistribusi berkinerja tinggi, memanfaatkan pemrosesan kolom dalam memori (melalui Apache Arrow) dan push-down lanjutan ke sumber data yang mendasarinya (saat menangani sumber RDBMS atau NoSQL).

Bagaimana Dremio menangani kueri SQL

Aplikasi klien mengeluarkan kueri SQL ke Dremio melalui ODBC, JDBC, atau REST. Kueri mungkin melibatkan satu atau beberapa kumpulan data, berpotensi berada di sumber data yang berbeda. Misalnya, kueri dapat berupa gabungan antara tabel Hive, Elasticsearch, dan beberapa tabel Oracle.

Dremio menggunakan dua teknik utama untuk mengurangi jumlah pemrosesan yang diperlukan untuk kueri:

  • Mendorong ke bawah ke sumber data pokok . Pengoptimal akan mempertimbangkan kemampuan sumber data yang mendasari dan biaya relatif. Ini kemudian akan menghasilkan rencana yang melakukan tahapan kueri baik di sumber atau di lingkungan eksekusi terdistribusi Dremio untuk mencapai rencana keseluruhan yang paling efisien.
  • Akselerasi melalui Refleksi Data . Pengoptimal akan menggunakan Refleksi Data untuk bagian-bagian kueri saat ini menghasilkan rencana keseluruhan yang paling efisien. Dalam banyak kasus, seluruh kueri bisa dilayani dari Refleksi Data karena mereka bisa menjadi urutan besarnya lebih efisien daripada memproses kueri di sumber data yang mendasarinya.

Query push-down

Dremio mampu mendorong pemrosesan menjadi sumber data relasional dan non-relasional. Sumber data non-relasional biasanya tidak mendukung SQL dan memiliki kemampuan eksekusi terbatas. Sistem file, misalnya, tidak dapat menerapkan predikat atau agregasi. MongoDB, di sisi lain, dapat menerapkan predikat dan agregasi, tetapi tidak mendukung semua gabungan. Pengoptimal Dremio memahami kemampuan setiap sumber data. Ketika paling efisien, Dremio akan mendorong sebanyak mungkin kueri ke sumber yang mendasarinya, dan melakukan sisanya di mesin eksekusinya sendiri yang terdistribusi.

Membongkar database operasional

Sebagian besar database operasional dirancang untuk beban kerja yang dioptimalkan untuk penulisan. Selain itu, penerapan ini harus mengatasi SLA yang ketat, karena waktu henti atau kinerja yang menurun dapat memengaruhi bisnis secara signifikan. Akibatnya, sistem operasional sering kali diisolasi dari pemrosesan kueri analitik. Dalam kasus ini, Dremio dapat menjalankan kueri analitik menggunakan Refleksi Data, yang menyediakan pemrosesan kueri seefisien mungkin sambil meminimalkan dampak pada sistem operasional. Refleksi Data diperbarui secara berkala berdasarkan kebijakan yang dapat dikonfigurasi pada tabel demi tabel.

Fase eksekusi kueri

Kehidupan kueri mencakup fase-fase berikut:

  1. Klien mengajukan pertanyaan ke koordinator melalui ODBC / JDBC / REST
  2. Perencanaan
    1. Koordinator mem-parsing kueri ke dalam model relasional universal Dremio
    2. Koordinator mempertimbangkan statistik yang tersedia pada sumber data untuk mengembangkan rencana kueri, serta kemampuan fungsional sumber
  3. Koordinator menulis ulang rencana kueri yang akan digunakan
    1. Refleksi Data yang tersedia, mempertimbangkan pemesanan, partisi, dan distribusi Refleksi Data dan
    2. kemampuan yang tersedia dari sumber data
  4. Eksekusi
  1. Pelaksana membaca data ke dalam buffer Panah dari sumber secara paralel
    1. Pelaksana menjalankan rencana kueri yang ditulis ulang.
    2. Satu pelaksana menggabungkan hasil dari satu atau lebih pelaksana dan mengalirkan hasil akhir ke koordinator
  1. Klien menerima hasil dari koordinator

Perhatikan bahwa data mungkin berasal dari Refleksi Data atau sumber data yang mendasarinya. Saat membaca dari sumber data, pelaksana mengirimkan kueri asli (misalnya, MongoDB MQL, Elasticsearch Query DSL, Microsoft Transact-SQL) sebagaimana ditentukan oleh pengoptimal dalam fase perencanaan.

Semua operasi data dilakukan pada node pelaksana, memungkinkan sistem untuk menskalakan banyak klien secara bersamaan hanya dengan menggunakan beberapa node koordinator.

Contoh query push-down

Untuk menggambarkan bagaimana Data Fabric cocok dengan arsitektur data Anda, mari kita lihat lebih dekat cara menjalankan kueri SQL pada sumber yang tidak mendukung SQL.

Salah satu sumber data modern yang lebih populer adalah Elasticsearch. Ada banyak hal yang disukai tentang Elasticsearch, tetapi dalam hal analitik, Elasticsearch tidak mendukung SQL (termasuk gabungan SQL). Itu berarti alat seperti Tableau dan Excel tidak dapat digunakan untuk menganalisis data dari aplikasi yang dibangun di atas penyimpanan data ini. Ada proyek visualisasi bernama Kibana yang populer untuk Elasticsearch, tetapi Kibana dirancang untuk pengembang. Ini tidak benar-benar untuk pengguna bisnis.

Dremio memudahkan analisis data di Elasticsearch dengan alat berbasis SQL apa pun, termasuk Tableau. Mari kita ambil contoh kueri SQL berikut untuk data bisnis Yelp, yang disimpan di JSON:

PILIH negara bagian, kota, nama, review_count

DARI elastic.yelp.business

DIMANA

  nyatakan NOT IN ('TX', 'UT', 'NM', 'NJ') AND

  review_count> 100

ORDER BY DESC review_count, negara bagian, kota

BATAS 10

Dremio mengompilasi kueri menjadi ekspresi yang dapat diproses oleh Elasticsearch: