Get best of the week

Dari mana kami membuat JET BI. Arsitektur Sistem Kecerdasan Bisnis tanpa penyimpangan lirik



Dalam posting sebelumnya, saya berbicara tentang evolusi sistem BI dan bagaimana kami memahami bahwa lebih baik membuat platform Anda sendiri daripada beradaptasi dengan yang sudah ada.

Hari ini, seperti yang dijanjikan, saya berbicara tentang arsitektur platform baru kami, yang, saya harap, akan menjadi solusi yang baik untuk membangun sistem BI apa pun.

Arsitektur fungsional


Dalam sistem, dua "Core" utama dapat dibedakan secara fungsional.

Inti dari visualisasi dan BI ( tim dan saya menyebutnya "pembaca") Terlibat dalam fakta bahwa itu menyaring data, menghitung fakta dan pengukuran, menghitung dan menyimpan agregat, dll. Secara umum - OLAP paling biasa. Dukungan untuk komputasi dalam memori juga tersedia. Tempat terpisah ditempati oleh mesin ETL yang kami kembangkan, mendukung kedua metode pemuatan standar (misalnya, SQL, kueri MongoDB, membongkar dari file Excel, dll.), Dan memuat apa pun dari mana saja menggunakan skrip JS. Bagaimana sebenarnya? Faktanya adalah bahwa kita "mengikat" JS loader dengan API khusus, yang tujuannya adalah untuk menyediakan seperangkat metode yang mudah dipelajari yang paling diminati untuk permintaan ke sumber yang berbeda, serta transformasi data (misalnya, memindahkan, menggabungkan, menambahkan kolom terhitung, berbagai jenis fungsi matematika dan statistik).

Bahasa

Javascript? Kamu gila?

Mungkin ...

Tetapi pilihan JS sebagai bahasa dan penolakan terhadap penemuan sepeda lain, seperti yang sering terjadi pada platform BI, bukanlah kebetulan. Popularitas bahasa itu sendiri, kesederhanaan perkembangannya (setidaknya untuk tugas-tugas ETL) dan sejumlah besar spesialis di pasar ternyata menjadi faktor penentu bagi kami. Secara umum, menurut ideologi platform kami, mesin ETL mirip dengan mekanisme "memuat skrip" yang digunakan, misalnya, di QlikView, kecuali untuk bahasa tempat skrip ini ditulis. Saya berharap bahwa banyak vendor platform BI cepat atau lambat akan datang ke bahasa pemrograman universal, tetapi untuk sekarang kami bekerja dengan apa yang ada.

Inti dari logika bisnis.Ini lebih merupakan kerangka kerja yang mengkonsolidasikan arsitektur perangkat lunak dan menyediakan sejumlah API universal yang dengannya Anda dapat menambahkan komponen analitis informasi terapan tambahan ke sistem.

Dari apa yang sudah kita miliki, kita dapat mencatat:

  • Konstruktor dan pawang untuk formulir entri data
  • Bagaimana-jika pemodelan dan analisis lingkungan
  • Sistem Manajemen Pesanan
  • Repositori Dokumen Elektronik
  • Modul proyek dan manajemen proyek

Saya ingin menekankan bahwa komponen ini ada dalam sistem karena suatu alasan dan tidak menjalani kehidupan mereka sendiri. Mereka terkait erat satu sama lain dan langsung dengan sistem visualisasi dan pelaporan. Bahkan, mereka menjadi pemasok atau konsumen data untuk itu. Misalnya, dari sistem manajemen pesanan, Anda dapat membuat laporan sederhana dari awal dari awal dari awal yang menampilkan status semua pesanan dan daftar orang-orang malas yang paling jahat. Dan dari modul manajemen proyek, dapatkan data tentang proyek-proyek yang paling "macet" dan identifikasi alasan keterlambatannya.

Arsitektur teknis


Backend aplikasi berjalan di bawah Node.JS, menyelingi sejumlah komponen asli yang kritis (dalam hal kinerja). Seperti aplikasi Node.JS apa pun, sistem dapat dikelompokkan, kemas dan disebarkan di lingkungan apa pun yang memenuhi persyaratan Node.

Untuk menyimpan metadata, Anda dapat menggunakan sebagian besar DBMS relasional populer, kami paling sering menggunakan PostgreSQL. Basis data menyimpan semua informasi meta tentang laporan, panel kontrol, proses ETL, modul tambahan, dll. Sistem ini juga dapat digunakan sebagai alat untuk mengisi penyimpanan data pihak ketiga. Untuk sejumlah kecil data, Anda dapat mengatur visualisasi dalam mode ROLAP, yaitu langsung dari sistem sumber. Sesuatu seperti "model asosiatif" dari QlikView juga ada. Jika Anda memilih dua set data atau lebih sebagai sumber data untuk visualizer, maka mereka akan digabungkan sesuai dengan nama kolom menjadi satu set.

Frontend adalah SPA klasik tentang Bereaksi, perpustakaan terkait dan modul tambahan dari JET BI itu sendiri. Komunikasi dengan backend terjadi melalui REST yang paling umum, bagian dari kode adalah isomorfik, yaitu digunakan oleh bagian depan dan belakang. Semua kode adalah ES7 dengan tipe anotasi (Aliran), dijalankan melalui Babel. Kami mengabaikan naskah untuk Flow, karena ketika kami pertama kali memulai, yang terakhir menyimpulkan jenis yang sedikit lebih baik.

Cukup sering (dalam sekitar 80% kasus) kita mengambil modul open-source yang siap pakai dan tidak membuat modul kita sendiri (di backend sedikit lebih jarang). Ini menyederhanakan dan mengurangi biaya pengembangan dan dukungan, tetapi sedikit mengurangi fleksibilitas. Ada kesalahan perhitungan, setelah itu beberapa perpustakaan akhirnya masih harus ditulis ulang sendiri.

Kesimpulan


Pada akhirnya, saya ingin mengatakan bahwa saya, sebagai seorang arsitek, senang bahwa "kerangka kerja" sistem ternyata cukup solid dan stabil di satu sisi, dan di sisi lain, universal dan dengan margin fleksibilitas yang cukup (walaupun ada banyak perpustakaan open-source yang disebutkan di atas). Ini seperti pohon Natal, di mana kami selalu menggantung mainan baru. Lagi pula, pohon itu harus tahan terhadap mainan dari berbagai varietas dan garis, dan pada saat yang sama tidak jatuh di bawah beratnya. Menurut pendapat saya, keseimbangan ini telah dicapai di JET BI, yang memberikan keyakinan bahwa rencana kami untuk pengembangan sistem akan dilaksanakan.

Albert Nurutdinov, Arsitek, Jet Infosystems

More articles:


All Articles