Dremio: Analisis data yang lebih mudah dan pantas

Jacques Nadeau adalah CTO dan pendiri Dremio.

Sekarang adalah masa yang tepat untuk menjadi pemaju. Selama dekad yang lalu, keputusan mengenai teknologi telah berpindah dari ruang dewan ke pemaju inovatif, yang membangun dengan sumber terbuka dan membuat keputusan berdasarkan kelebihan projek yang mendasari dan bukannya hubungan komersial yang diberikan oleh vendor. Projek-projek baru telah muncul yang memfokuskan kepada menjadikan pemaju lebih produktif, dan lebih mudah untuk dikendalikan dan dibuat skala. Ini berlaku untuk hampir setiap lapisan timbunan teknologi. Hasilnya adalah bahawa pembangun hari ini mempunyai peluang hampir tanpa had untuk meneroka teknologi baru, seni bina baru, dan model penyebaran baru.

Melihat lapisan data secara khusus, sistem NoSQL seperti MongoDB, Elasticsearch, dan Cassandra telah mendorong sampul tersebut dari segi kelincahan, skalabilitas, dan prestasi untuk aplikasi operasi, masing-masing dengan model data dan pendekatan skema yang berbeza. Sepanjang perjalanan banyak pasukan pembangunan beralih ke model perkhidmatan mikro, menyebarkan data aplikasi di banyak sistem asas yang berbeza.

Dari segi analitik, sumber data lama dan baru telah menemui jalan masuk ke dalam gabungan gudang data tradisional dan tasik data, beberapa di Hadoop, yang lain di Amazon S3. Dan kebangkitan platform streaming data Kafka mencipta cara berfikir yang sama sekali berbeza mengenai pergerakan data dan analisis data dalam gerakan.

Dengan data dalam begitu banyak teknologi yang berbeza dan format yang mendasari, analisis data moden sukar. BI dan alat analisis seperti Tableau, Power BI, R, Python, dan model pembelajaran mesin dirancang untuk dunia di mana data tinggal dalam satu pangkalan data hubungan berprestasi tinggi. Sebagai tambahan, pengguna alat ini - penganalisis perniagaan, saintis data, dan model pembelajaran mesin - menginginkan kemampuan untuk mengakses, meneroka, dan menganalisis data sendiri, tanpa bergantung pada IT.

Memperkenalkan struktur data Dremio

Alat BI, sistem sains data, dan model pembelajaran mesin berfungsi paling baik apabila data tinggal dalam satu pangkalan data hubungan berprestasi tinggi. Malangnya, bukan di situlah data hidup hari ini. Hasilnya, IT tidak mempunyai pilihan selain untuk merapatkan jurang tersebut melalui kombinasi pengembangan ETL khusus dan produk proprietari. Di banyak syarikat, timbunan analisis merangkumi lapisan berikut:

  • Pementasan data . Data dipindahkan dari pelbagai pangkalan data operasi ke satu kawasan pementasan seperti kluster Hadoop atau perkhidmatan penyimpanan awan (misalnya, Amazon S3).
  • Gudang data . Walaupun ada kemungkinan untuk menjalankan pertanyaan SQL secara langsung di Hadoop dan penyimpanan awan, sistem ini tidak dirancang untuk memberikan prestasi interaktif. Oleh itu, subset data biasanya dimuat ke gudang data hubungan atau pangkalan data MPP.
  • Kiub, jadual agregasi, dan ekstrak BI . Untuk memberikan prestasi interaktif pada set data yang besar, data harus diagregat dan / atau diindeks dengan membuat kubus dalam sistem OLAP atau tabel agregasi yang terwujud di gudang data.

Senibina pelbagai lapisan ini memperkenalkan banyak cabaran. Ia kompleks, rapuh, dan lambat, dan mewujudkan persekitaran di mana pengguna data bergantung sepenuhnya kepada IT.

Dremio memperkenalkan tahap baru dalam analisis data yang kami sebut sebagai struktur data layan diri. Dremio adalah projek sumber terbuka yang membolehkan penganalisis perniagaan dan saintis data meneroka dan menganalisis data pada bila-bila masa, tanpa mengira lokasi, saiz, atau strukturnya. Dremio menggabungkan arsitektur skala-out dengan pelaksanaan kolumnar dan percepatan untuk mencapai prestasi interaktif pada volume data apa pun, sambil memungkinkan IT, saintis data, dan penganalisis perniagaan untuk membentuk data dengan lancar sesuai dengan keperluan bisnis.

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

Dremio menggunakan penyimpanan dan pelaksanaan kolumnar berprestasi tinggi, dikuasakan oleh Apache Arrow (kolumnar dalam memori) dan Apache Parquet (kolumnar pada disk). Dremio juga menggunakan Apache Calcite untuk penguraian dan pengoptimuman pertanyaan SQL, membangun perpustakaan yang sama dengan banyak enjin berasaskan SQL lain, seperti Apache Hive.

Apache Arrow adalah projek sumber terbuka yang membolehkan pemprosesan dan pertukaran data kolumnar dalam memori. Arrow diciptakan oleh Dremio, dan merangkumi komitator dari pelbagai syarikat termasuk Cloudera, Databricks, Hortonworks, Intel, MapR, dan Two Sigma.

Dremio adalah enjin pelaksanaan pertama yang dibina dari bawah ke atas pada Apache Arrow. Secara internal, data dalam memori disimpan secara tidak teratur dalam format Arrow, dan tidak lama lagi akan ada API yang mengembalikan hasil pertanyaan sebagai buffer memori Arrow.

Pelbagai projek lain juga merangkul Arrow. Python (Pandas) dan R adalah antara projek ini, yang membolehkan para saintis data bekerja dengan lebih cekap dengan data. Sebagai contoh, Wes McKinney, pencipta perpustakaan Pandas yang popular, baru-baru ini menunjukkan bagaimana Arrow membolehkan pengguna Python membaca data ke dalam Pandas dengan harga lebih dari 10 GB / s.

Bagaimana Dremio membolehkan data layan diri

Di samping kemampuan untuk bekerja secara interaktif dengan kumpulan data mereka, jurutera data, penganalisis perniagaan, dan saintis data juga memerlukan cara untuk mengatur data sehingga sesuai untuk keperluan projek tertentu. Ini adalah perubahan mendasar dari model IT-centric, di mana pengguna data memulakan permintaan untuk set data dan menunggu IT memenuhi permintaan mereka beberapa minggu atau bulan kemudian. Dremio membolehkan model layan diri, di mana pengguna data menggunakan keupayaan kurasi data Dremio untuk mencari, mengurus, mempercepat, dan berkongsi data tanpa bergantung pada IT.

Semua keupayaan ini dapat diakses melalui UI berasaskan web moden, intuitif:

  • Cari . Dremio merangkumi katalog data terpadu di mana pengguna dapat menemui dan meneroka set data fizikal dan maya. Katalog data dikemas kini secara automatik apabila sumber data baru ditambahkan, dan ketika sumber data dan set data maya berkembang. Semua metadata diindeks dalam indeks berprestasi tinggi, dicari, dan didedahkan kepada pengguna di seluruh antara muka Dremio.
  • Kurate . Dremio membolehkan pengguna mengatur data dengan membuat set data maya. Pelbagai transformasi titik-dan-klik disokong, dan pengguna maju dapat menggunakan sintaks SQL untuk menentukan transformasi yang lebih kompleks. Ketika pertanyaan dijalankan dalam sistem, Dremio belajar tentang data, yang memungkinkan untuk mengesyorkan pelbagai transformasi seperti bergabung dan penukaran jenis data.
  • Dremio mampu mempercepat set data hingga 1000x berbanding prestasi sistem sumber. Pengguna dapat memilih set data yang mereka rasa harus lebih cepat, dan heuristik Dremio akan mempertimbangkan suara ini dalam menentukan set data mana yang akan dipercepat. Secara pilihan, pentadbir sistem secara manual dapat menentukan set data yang akan dipercepat.
  • Dremio membolehkan pengguna berkongsi data dengan selamat dengan pengguna dan kumpulan lain. Dalam model ini sekumpulan pengguna dapat berkolaborasi pada set data maya yang akan digunakan untuk pekerjaan analitik tertentu. Sebagai pilihan, pengguna boleh memuat naik data mereka sendiri, seperti spreadsheet Excel, untuk bergabung dengan kumpulan data lain dari katalog perusahaan. Pembuat set data maya dapat menentukan pengguna mana yang boleh membuat pertanyaan atau mengedit set data maya mereka. Ini seperti Google Docs untuk data anda.

Bagaimana pecutan data Dremio berfungsi

Dremio menggunakan perwakilan fizikal sumber data yang sangat dioptimumkan yang disebut Data Reflections. Reflection Store boleh hidup di HDFS, MapR-FS, penyimpanan awan seperti S3, atau penyimpanan langsung (DAS). Saiz Reflection Store boleh melebihi memori fizikal. Senibina ini membolehkan Dremio mempercepat lebih banyak data dengan kos yang lebih rendah, menghasilkan nisbah hit cache yang jauh lebih tinggi berbanding dengan seni bina memori sahaja. Refleksi Data digunakan secara automatik oleh pengoptimum berdasarkan kos pada waktu pertanyaan.

Refleksi Data tidak dapat dilihat oleh pengguna akhir. Tidak seperti kubus OLAP, jadual agregasi, dan ekstrak BI, pengguna tidak tersambung secara eksplisit ke Refleksi Data. Sebaliknya, pengguna mengeluarkan pertanyaan terhadap model logik, dan pengoptimum Dremio secara automatik mempercepat pertanyaan dengan memanfaatkan Refleksi Data yang sesuai untuk pertanyaan berdasarkan analisis kos pengoptimum.

Apabila pengoptimum tidak dapat mempercepat pertanyaan, Dremio menggunakan mesin pelaksanaan berprestasi tinggi, memanfaatkan pemprosesan dalam memori kolumnar (melalui Apache Arrow) dan penekanan maju ke sumber data yang mendasari (ketika berurusan dengan sumber RDBMS atau NoSQL).

Bagaimana Dremio menangani pertanyaan SQL

Aplikasi pelanggan mengeluarkan pertanyaan SQL kepada Dremio melalui ODBC, JDBC, atau REST. Pertanyaan mungkin melibatkan satu atau lebih kumpulan data, berpotensi berada di sumber data yang berbeza. Sebagai contoh, pertanyaan mungkin merupakan gabungan antara jadual Hive, Elasticsearch, dan beberapa jadual Oracle.

Dremio menggunakan dua teknik utama untuk mengurangkan jumlah pemprosesan yang diperlukan untuk pertanyaan:

  • Push-down ke sumber data yang mendasari . Pengoptimum akan mempertimbangkan keupayaan sumber data yang mendasari dan kos relatif. Ini kemudian akan menghasilkan rancangan yang melakukan tahap pertanyaan sama ada di sumber atau di persekitaran pelaksanaan Dremio yang diedarkan untuk mencapai rancangan keseluruhan yang paling efisien yang mungkin.
  • Pecutan melalui Refleksi Data . Pengoptimum akan menggunakan Refleksi Data untuk sebahagian pertanyaan apabila ini menghasilkan rancangan keseluruhan yang paling berkesan. Dalam banyak kes, keseluruhan pertanyaan dapat dilayan dari Refleksi Data kerana pesanan boleh menjadi lebih besar daripada memproses pertanyaan dalam sumber data yang mendasari.

Permintaan tolak turun

Dremio mampu mendorong pemprosesan ke sumber data hubungan dan bukan hubungan. Sumber data bukan hubungan biasanya tidak menyokong SQL dan mempunyai keupayaan pelaksanaan yang terhad. Sistem fail, misalnya, tidak dapat menerapkan predikat atau gabungan. MongoDB, sebaliknya, dapat menerapkan predikat dan penggabungan, tetapi tidak menyokong semua gabungan. Pengoptimum Dremio memahami kemampuan setiap sumber data. Apabila paling efisien, Dremio akan menyerahkan sebanyak mungkin pertanyaan ke sumber yang mendasari, dan melakukan selebihnya dalam mesin pelaksanaan tersebarnya sendiri.

Memunggah pangkalan data operasi

Sebilangan besar pangkalan data operasi direka untuk beban kerja yang dioptimumkan untuk menulis. Tambahan pula, penyebaran ini mesti menangani SLA yang ketat, kerana apa-apa waktu henti atau penurunan prestasi dapat mempengaruhi perniagaan dengan ketara. Akibatnya, sistem operasi sering diasingkan daripada memproses pertanyaan analisis. Dalam kes-kes ini, Dremio dapat melaksanakan pertanyaan analitik menggunakan Refleksi Data, yang memberikan pemprosesan pertanyaan yang paling efisien mungkin sambil meminimumkan dampak pada sistem operasi. Refleksi Data dikemas kini secara berkala berdasarkan dasar yang dapat dikonfigurasi berdasarkan jadual berdasarkan jadual.

Fasa pelaksanaan pertanyaan

Kehidupan pertanyaan merangkumi fasa berikut:

  1. Pelanggan mengemukakan pertanyaan kepada penyelaras melalui ODBC / JDBC / REST
  2. Perancangan
    1. Penyelaras menguraikan pertanyaan ke model hubungan universal Dremio
    2. Penyelaras mempertimbangkan statistik yang ada mengenai sumber data untuk mengembangkan rancangan pertanyaan, serta kemampuan fungsi sumber tersebut
  3. Penyelaras menulis semula rancangan pertanyaan untuk digunakan
    1. Refleksi Data yang ada, mempertimbangkan untuk membuat pesanan, membuat partisi, dan pengedaran Refleksi Data dan
    2. kemampuan sumber data yang ada
  4. Pelaksanaan
  1. Pelaksana membaca data ke dalam buffer Arrow dari sumber secara selari
    1. Pelaksana melaksanakan rancangan pertanyaan yang ditulis semula.
    2. Seorang pelaksana menggabungkan hasil dari satu atau lebih pelaksana dan mengalirkan hasil akhir kepada penyelaras
  1. Pelanggan menerima hasil dari penyelaras

Perhatikan bahawa data mungkin berasal dari Refleksi Data atau sumber data yang mendasari. Ketika membaca dari sumber data, pelaksana mengemukakan pertanyaan asli (misalnya MongoDB MQL, Elasticsearch Query DSL, Microsoft Transact-SQL) sebagaimana ditentukan oleh pengoptimum dalam fasa perancangan.

Semua operasi data dilakukan pada simpul pelaksana, yang memungkinkan sistem menskala ke banyak klien serentak dengan hanya menggunakan beberapa simpul penyelaras.

Contoh push-down pertanyaan

Untuk menggambarkan bagaimana Fabric Data sesuai dengan seni bina data anda, mari kita lihat dengan lebih dekat menjalankan pertanyaan SQL pada sumber yang tidak menyokong SQL.

Salah satu sumber data moden yang lebih popular ialah Elasticsearch. Terdapat banyak perkara yang disukai mengenai Elasticsearch, tetapi dari segi analisis, ia tidak menyokong SQL (termasuk SQL bergabung). Ini bermaksud alat seperti Tableau dan Excel tidak dapat digunakan untuk menganalisis data dari aplikasi yang dibina di gudang data ini. Terdapat projek visualisasi bernama Kibana yang popular untuk Elasticsearch, tetapi Kibana direka untuk pemaju. Ini bukan untuk pengguna perniagaan.

Dremio mempermudah untuk menganalisis data di Elasticsearch dengan alat berasaskan SQL, termasuk Tableau. Mari kita contohi pertanyaan SQL berikut untuk data perniagaan Yelp, yang disimpan di JSON:

PILIH keadaan, bandar, nama, jumlah_kaji

DARI elastik.yelp.business

DI MANA

  nyatakan TIDAK DALAM ('TX', 'UT', 'NM', 'NJ') DAN

  jumlah_kajian> 100

ORDER BY review_count DESC, negeri, bandar

TERHAD 10

Dremio menyusun pertanyaan menjadi ungkapan yang dapat diproses oleh Elasticsearch: