Virtual Cube - Alih-alih OLAP

Ketika Anda melakukan yang sebaliknya dan mendapatkan yang sama ...

Memiliki tugas pemrosesan data analitis (komputasi / agregasi), Anda harus menemukan kompromi antara responsif, kecepatan, dan kenyamanan.


Beberapa sistem diindeks dan ditemukan dengan baik, yang lain dapat dengan cepat menghitung dan mengumpulkan data, sementara yang lain sederhana. Di suatu tempat, perlu untuk mengatur preloading dan pengindeksan data dengan semua kesulitan yang menyertainya, dan di suatu tempat, pengguna diberikan abstraksi model sumber dan data agregatnya di atas penyimpanan fisik dan database fisik bawaan dan eksternal yang digunakan secara langsung selama perhitungan. Bagaimanapun, pengguna, dari pemrogram hingga analis, harus melakukan pekerjaan yang relatif besar, mulai dengan menyiapkan data mentah dan menyusun kueri, menghitung model, berakhir dengan memvisualisasikan hasil pada widget, tentu saja, "Seksi" - cantik, responsif, dan dapat dipahami - jika tidak semua pekerjaan yang dilakukan akan sia-sia. Dan seringkali, seperti keberuntungan, melalui pergolakan dalam memilih solusi, kita melihat bagaimana tugas yang sederhana dan dapat dimengerti pada awalnya tumbuh menjadi monster yang menyeramkan, yang tidak berguna untuk bertarung dengan cara yang tersedia, dan kita perlu segera menciptakan sesuatu - sepeda "dengan blackjack dan pelacur" Β© Sepeda kami melaju, bahkan berputar dengan baik dan mengatasi rintangan yang hanya bisa ditebak orang sebelumnya.


Di bawah ini akan dijelaskan satu sisi dari perangkat internal asli fiksi "Rubik's Cube" - pemrosesan komputasi untuk visualisasi data interaktif.


Tugas sederhana harus diselesaikan dengan sederhana, dan yang sulit juga harus sederhana, tetapi lebih lama ...

Mulai membuat sistem dengan kekuatan kecil, kami beralih dari sederhana ke kompleks. Menciptakan konstruktor, kami yakin secara internal bahwa kami memahami dengan baik tujuan sistem, bertarung secara bersamaan dengan keinginan untuk tidak melakukan terlalu banyak dan keinginan yang berlawanan untuk mengotomatisasi segala sesuatu dan segalanya, menciptakan kerangka kerja untuk segalanya. Selain itu, salah satu kerangka kerja kami yang luar biasa siap dan bahkan diuji dalam produksi - jsBeans. Jadi, kami mulai mengembangkan sistem pemrosesan data berikutnya, yang telah berkembang dan sekarang pada saat yang sama merupakan produk mandiri - seorang desainer dan platform untuk mengembangkan seluruh kelas sistem pemrosesan data. Secara kondisional, dalam artikel kami akan menyebutnya "Rubik's Cube" untuk melakukan tanpa iklan, tetapi untuk menggambarkan menarik, menurut pendapat kami, solusi.


Kubus, irisan, pengukuran


Tugas utama - memiliki set data yang tidak terkait, termasuk database dan file eksternal yang heterogen, untuk membentuk model multidimensi dari elemen yang saling berhubungan dari data sumber dan hasil dari pemrosesan analitis mereka untuk visualisasi pada dashboard dinamis dan widget yang saling berhubungan.


Sederhananya, misalnya, sebagai dasbor yang dapat diklik:


Contoh dashboard sekolah dinilai


Model data multidimensi seperti itu dalam sistem kami disebut "Cube" dan secara harfiah mewakili koleksi abstrak kumpulan data yang dapat berubah yang disebut "Slice", yang saling terkait oleh bidang / kolom keluaran umum (ditampilkan) atau bidang internal yang disebut "Dimensi" dan digunakan untuk menyaring dan menghubungkan irisan satu sama lain.


Iris dapat direpresentasikan sebagai tabel atau tampilan virtual ( CTE ) dengan parameter dan badan permintaan variabel, tergantung pada kondisi penyaringan. Yang utama adalah bahwa data output berubah, tergantung pada kondisi pencarian konteks (di dalam widget) dan filter global, yang dibangun dengan memilih nilai pada widget dan menggunakan fungsi logika dasar (DAN / ATAU / TIDAK) dan kombinasi.


Filter global memungkinkan Anda untuk "memutar Rubik's Cube", seperti dalam video :



Jika bidang keluaran dari irisan adalah sekaligus pengukuran di irisan lain, memiliki nama yang sama, maka nilai-nilai bidang ini dirasakan oleh sistem sebagai "fakta" (jika kita berbicara tentang OLAP ), atur dalam bentuk filter global yang mengubah set data asli selama kalkulasi dan agregasi . Akibatnya, ada interaksi dinamis widget, di mana nilai indikator yang ditampilkan tergantung pada elemen dan filter yang dipilih.


Sepotong adalah sekumpulan data yang dapat diubah "dengan pengukuran" β€” awal atau hasil perhitungan analitik; dicirikan oleh bidang / kolom keluaran, daftar pengukuran yang didukung dan satu set parameter dengan nilai default; dijelaskan oleh permintaan yang relatif elegan dalam editor visual yang mendukung pemfilteran, pengurutan, pengelompokan / agregasi, persimpangan (GABUNG), serikat pekerja (UNION), rekursi, dan manipulasi lainnya.


Irisan yang saling menggunakan sebagai sumber menggambarkan struktur internal sebuah kubus, misalnya:


Contoh Struktur Kubus


Contoh alat pengiris di editor:


Contoh editor permintaan alat pengiris


Sepotong mendukung kedua pengukuran yang ditentukan secara eksplisit di bidang output dan mewarisi pengukuran dari sumber kueri - ini berarti bahwa output dari irisan dapat diubah bahkan sebagai akibat dari perubahan di sumber-sumber irisan lainnya. Dengan kata lain, hasil dari irisan dapat disaring tidak hanya oleh bidang output, tetapi juga oleh bidang internal-pengukuran sumber, di suatu tempat di kedalaman permintaan, hingga tabel database primer.


Struktur kueri diperluas dan diubah oleh sistem secara otomatis pada saat eksekusi, tergantung pada filter global dan parameter input saat ini, menyeretnya lebih dalam ke dalam kueri sesuai dengan model kubus, pengukuran yang dinyatakan, dan irisan.


Contoh filter global sederhana, secara harfiah, ketika pengguna telah melakukan atau memilih nilai pada beberapa widget:


Contoh filter global di dasbor


Filter global disimpan dalam permintaan JSON:


Contoh JSON dari filter global di badan permintaan


Permintaan datang ke sumber utama (ke database) yang sudah dalam bentuk siap, setelah melewati beberapa tahap utama:


  • Meminta perakitan, termasuk pemilihan dan penyisipan irisan optimal, dengan mempertimbangkan filter global saat ini (ketika filter tidak ada atau sederhana, Anda dapat memilih irisan sederhana / cepat; ketika filter kompleks - irisan dengan struktur yang kompleks dan pengukuran tambahan);
  • Menanamkan filter global dan menambahkan filter ke badan kueri dan subkueri;
  • Menyematkan makro dan ekspresi kueri templat;
  • Optimasi kueri, termasuk penghapusan bidang dan ekspresi yang tidak digunakan;
  • Operasi tambahan dengan kueri untuk spesifik basis data primer (misalnya, jika kita berbicara tentang SQL dan basis data tidak berisi DENGAN, maka kueri bernama yang disematkan).

Dan tahap terakhir adalah terjemahan permintaan ke format sumber utama, misalnya, dalam SQL:


Contoh permintaan akhir dengan filter terintegrasi


Ketika sumber berbeda


Sebagai aturan, semuanya sederhana dan jelas ketika Anda harus bekerja dengan satu gudang data. Tetapi, ketika ada beberapa dari mereka dan mereka pada dasarnya berbeda - Anda harus menerapkan trik yang berbeda untuk setiap tugas tertentu. Dan Anda selalu ingin memiliki solusi universal yang selalu cocok, lebih disukai di luar kotak, dengan modifikasi kecil maksimal. Untuk melakukan ini, abstraksi lain memintanya: lebih dari gudang data, pertama, mewujudkan koordinasi format dan bahasa query, dan kedua, memastikan saling ketergantungan data, setidaknya pada tingkat kondisi penyaringan tambahan dalam permintaan ke satu sumber dengan nilai dari sumber lain.


Untuk melakukan ini, kami telah mengembangkan bahasa permintaan universal, cocok untuk mewakili model virtual data kubus dan untuk bekerja dengan penyimpanan sewenang-wenang dengan syarat dengan menerjemahkan permintaan ke format dan bahasa yang diinginkan. Secara kebetulan, bahasa query, yang awalnya dimaksudkan untuk pemetaan sederhana dan penyaringan data dari berbagai sumber, dengan mudah tumbuh menjadi pencarian data dan bahasa pemrosesan yang lengkap, yang memungkinkan seseorang untuk membangun konstruksi komputasi dari yang paling sederhana hingga yang paling kompleks di beberapa halaman dan dengan banyak subquery.


Sumber dapat dibagi menjadi tiga jenis:


  1. file data yang perlu diunduh ke sistem;
  2. Basis data yang mendukung pemrosesan data lengkap dan operasi lainnya;
  3. penyimpanan yang hanya mendukung ekstraksi data dengan atau tanpa penyaringan, termasuk berbagai jenis layanan eksternal.

Semuanya tidak ambigu dengan tipe pertama - modul impor terintegrasi dalam sistem, yang mem-parsing berbagai format input dan membenamkan hasil dalam repositori. Untuk impor, konstruktor khusus juga telah dikembangkan, yang harus dibahas secara terpisah.


Tipe kedua adalah basis data mandiri, di mana Anda hanya perlu menerjemahkan permintaan asli ke format dan bahasa yang diinginkan dari permintaan, dialek.


Tipe ketiga membutuhkan setidaknya data pasca pemrosesan. Dan semua jenis pada saat yang sama juga dapat membutuhkan pemrosesan pasca - persimpangan, serikat pekerja, agregasi dan perhitungan akhir. Ini terjadi ketika pemrosesan data dalam satu database perlu dilakukan dengan mempertimbangkan hasil penyaringan di eksternal lain.


Contoh paling sederhana adalah ketika pencarian fuzzy dilakukan dalam satu database, dan pada output itu diperlukan untuk memperoleh agregasi indikator yang disimpan dalam database lain di server lain, dengan mempertimbangkan hasil pencarian.


Untuk mengimplementasikan pekerjaan skema semacam itu, algoritma sederhana diimplementasikan dalam sistem kami - permintaan awal disiapkan secara simultan oleh beberapa penerjemah, yang masing-masing dapat menolak untuk mengeksekusi permintaan ketika itu tidak kompatibel, atau mengembalikan iterator dengan data, atau mengonversi permintaan dan memulai pekerjaan dari rantai persiapan permintaan berikutnya oleh juru bahasa lain . Akibatnya, untuk satu permintaan, kami mendapatkan dari satu hingga beberapa iterator malas yang membentuk hasil yang sama, tetapi dengan cara yang berbeda, dari mana yang terbaik dipilih (sesuai dengan berbagai kriteria yang ditentukan oleh pengembang dalam konfigurasi).


Strategi pemilihan iterator ditentukan dalam konfigurasi atau parameter kueri. Saat ini, beberapa strategi utama didukung:


  • pertama, setiap, terakhir;
  • menurut jenis basis data prioritas;
  • dengan prioritas rantai yang membentuk iterator;
  • oleh fungsi berat "permintaan bobot";
  • menurut hasil pertama - semua iterator diluncurkan secara paralel dan hasil pertama diharapkan, sebagai akibatnya, iterator tercepat digunakan, sisanya ditutup.

Sebagai hasil dari kombinasi tersebut untuk satu permintaan input, kami mendapatkan beberapa opsi untuk pelaksanaannya, baik menggunakan sumber yang berbeda dan dengan strategi eksekusi yang berbeda - memilih basis data utama / target di mana bagian utama dari permintaan akan dieksekusi dan hasil akhir perakitan.


Jika target DBMS mendukung koneksi sumber eksternal, maka menjadi mungkin untuk membuat sirkuit terbalik di mana DBMS terhubung ke sistem API untuk menerima sejumlah kecil data dari sistem, misalnya, untuk menyaring volume besar "di tempat". Integrasi tersebut transparan bagi pengguna akhir dan analis - model kubus tidak berubah, dan semua operasi dilakukan secara otomatis oleh sistem.


Diagram urutan sederhana ketika menanyakan beberapa basis data terintegrasi dalam satu permintaan


Untuk kasus yang lebih kompleks, sistem mengimplementasikan interpreter kueri dalam-memori internal pada mesin database Embedded H2 yang luar biasa, yang memungkinkan pengintegrasian setiap basis data yang didukung di luar kotak. Secara harfiah, ini berfungsi seperti ini - permintaan dibagi menjadi beberapa bagian oleh kelompok sumber, dikirim untuk dieksekusi, setelah itu perakitan dan pemrosesan akhir hasilnya dilakukan dalam memori, dalam H2.


Sepintas, skema integrasi data seperti itu pada level interpreter internal tampaknya β€œsulit”, dan ini benar jika Anda harus bekerja dengan volume besar data input dan kebutuhan untuk melakukan perhitungan setelah persimpangan dan asosiasi set dari sumber eksternal. Bahkan, keadaan ini sebagian diratakan - pada saat yang sama, permintaan dijalankan oleh beberapa penangan dalam versi yang berbeda, oleh karena itu, penerjemah hanya digunakan dalam kasus yang paling ekstrim, sebagai solusi universal di luar kotak. Pada akhirnya, setiap integrasi dibatasi oleh biaya transportasi khas untuk persiapan, transmisi melalui jaringan dan menerima data, dan ini adalah tugas yang sama sekali berbeda.


Sisi teknis


Dari sisi teknis, yang, mungkin, tidak bisa dihilangkan, menyentuh topik ini, sistem juga diatur sesuai dengan prinsip - untuk melakukan lebih banyak, tetapi sederhanakan segala sesuatu sebanyak mungkin.


Sistem pemrosesan data diimplementasikan di atas kerangka klien-server jsBeans sebagai satu set modul tambahan dan proyek perakitan khusus. jsBeans, pada gilirannya, diimplementasikan di Jawa, berfungsi sebagai server aplikasi, pada umumnya merupakan sekelompok Rhino, Jetty dan Akka, dan juga mencakup teknologi kacang client-server yang dikembangkan oleh tim kami, dan perpustakaan kaya komponen yang dirakit selama beberapa tahun aplikasi yang sukses.


Rubik's Cube sepenuhnya dan sepenuhnya diimplementasikan dalam JavaScript dalam bentuk banyak js-bins (* .jsb file), beberapa di antaranya hanya beroperasi di server. Bagian lainnya adalah pada klien, dan sisanya adalah komponen komponen, berfungsi sebagai keseluruhan terdistribusi, bagian-bagian yang saling berinteraksi, transparan kepada pengembang, tetapi di bawah kendalinya. Js-bins dapat memiliki strategi kehidupan yang berbeda, misalnya, dengan atau tanpa sesi pengguna, dan banyak lagi. Kacang isomorfik, memungkinkan klien dan server untuk bekerja dengannya sebagai instance virtual dari kelas reguler. Nampan dijelaskan oleh satu file dan mencakup tiga bagian - untuk bidang dan metode yang berjalan pada klien, untuk bidang server, serta bagian bidang yang disinkronkan secara umum.


Karena artikel tersebut telah berubah menjadi kata yang tidak membuat pembaca bosan, sekarang saatnya untuk melanjutkan sampai selesai, dengan maksud untuk segera menggambarkan detail dan solusi arsitektur yang paling menarik dalam implementasi JsBeans dan proyek-proyek kami berdasarkan itu - subsistem visualisasi yang dibangun, proses analitik, perancang ontologis bidang studi, bahasa kueri, impor data, dan lainnya ...


Kenapa begitu


Ini belum pernah terjadi sebelumnya, dan di sini lagi ...

Awalnya, ada beberapa set data primer. Bidang dan tugas subjek sepenuhnya ditentukan. Tampaknya, mengapa siksaan seperti itu? Tugasnya terlihat sederhana, semua orang ingin mendapatkan hasilnya segera - terutama ketika solusi cepat muncul di permukaan, dan yang tepat membutuhkan ketekunan dan keputusan yang seimbang, mengamati pengaturan asli. Kami pergi ke arah yang berlawanan, dari solusi yang rumit dan panjang untuk yang sederhana dan cepat, di sepanjang jalan generalisasi masalah tertentu.


Syarat utama adalah bahwa dasbor baru harus dibangun dengan cepat, bahkan jika area subjek baru dan kebutuhan analitis sangat berbeda dari yang sebelumnya. Jelas Anda tidak akan menebak bahkan setengah dari persyaratan di masa depan, sistem harus lentur di tempat pertama. Menyempurnakan pustaka komponen, algoritma analitik, menghubungkan jenis sumber baru adalah bagian integral dari adaptasi sistem. Dengan kata lain, banyak yang telah bekerja - analis membangun permintaan dan dasbor, dan programmer dengan cepat menyadari kebutuhan baru untuk mereka. Dan kami, sebagai programmer, awalnya berusaha menyederhanakan pekerjaan kami di masa depan, berusaha untuk tidak merusak kegunaan.


Dan sistem itu segera dibuat universal dan adaptif - kami membangun "konstruktor dengan konstruktor", mengembangkan kerangka kerja di atas kerangka kerja yang sebelumnya dibuat dengan tujuan yang serupa, tetapi bahkan lebih umum.


Peringkat sekolah Moskow berdasarkan hasil Unified State Examination dan Olympiads adalah contoh dashboard yang dibuat dengan cara yang dijelaskan di atas dari pembongkaran dari portal data terbuka Pemerintah Moskow.


Cube-Rubik adalah platform dasar untuk pengembangan sistem informasi dan analisis. Dirancang sebagai cabang dan kelanjutan logis dari jsBeans. Ini mencakup semua modul yang diperlukan untuk menyelesaikan masalah pengumpulan, pemrosesan, analisis (komputasi dan berorientasi proses) dan visualisasi.


jsBeans adalah kerangka kerja web penuh-tumpukan isomorfik yang mengimplementasikan teknologi kacang JavaScript server-klien, yang dikembangkan dengan lisensi terbuka sebagai alat universal. Selama penggunaan, itu telah membuktikan dirinya dengan baik, dalam banyak kasus, idealnya pas ke tugas-tugas sebelum kita.

Source: https://habr.com/ru/post/id452154/


All Articles