Bukan tanpa alasan bahwa rekan-rekan yang lebih berpengalaman, dengan kepala mereka dipenuhi serangga dan dari rambut beruban ini, merenungkan penyebaran paket "kontainer" dalam "kubus" yang sangat cepat pada lusinan server dalam "bahasa modis" dengan dukungan bawaan untuk I / O non-pemblokiran asinkron - senyum sederhana ... Dan mereka diam-diam terus membaca ulang "man ps", mempelajari kode sumber "nginx" hingga keluar dari mata mereka dan tes unit tulis-tulis-tulis. Rekan kerja tahu bahwa yang paling menarik akan ada di depan, ketika "semua ini" satu malam menjadi taruhan di Malam Tahun Baru. Dan hanya pemahaman mendalam tentang sifat unix, tabel status TCP / IP yang dipelajari dan algoritme pencarian sortir dasar akan membantu mereka. Untuk menghidupkan kembali sistem di bawah lonceng.
Oh ya, saya sedikit teralihkan, tapi saya harap saya berhasil menyampaikan keadaan antisipasinya.
Hari ini saya ingin berbagi pengalaman kami dalam menerapkan tumpukan yang nyaman dan murah untuk DataLake, yang menyelesaikan sebagian besar tugas analitis di perusahaan untuk divisi struktural yang sama sekali berbeda.
Beberapa waktu yang lalu, kami sampai pada pemahaman bahwa perusahaan membutuhkan semakin banyak buah dari produk dan analisis teknis (belum lagi buah ceri di kue dalam bentuk pembelajaran mesin) dan untuk memahami tren dan risiko, semakin banyak yang perlu dikumpulkan dan dianalisis. lebih banyak metrik.
Analisis teknis dasar di Bitrix24
Beberapa tahun yang lalu, bersamaan dengan peluncuran layanan Bitrix24, kami secara aktif menginvestasikan waktu dan sumber daya dalam menciptakan platform analitik yang sederhana dan andal yang akan membantu kami melihat masalah infrastruktur dengan cepat dan merencanakan langkah selanjutnya. Tentu saja, diinginkan untuk menggunakan alat yang sudah jadi dan sesederhana dan semudah mungkin. Hasilnya, nagios dipilih untuk pemantauan dan munin untuk analitik dan visualisasi. Sekarang kami memiliki ribuan cek di nagios, ratusan grafik di munin dan kolega setiap hari dan berhasil menggunakannya. Metriknya jelas, grafiknya jelas, sistem telah bekerja dengan andal selama beberapa tahun dan pengujian serta grafik baru secara teratur ditambahkan ke dalamnya: kami menjalankan layanan baru - kami menambahkan beberapa pengujian dan grafik. Semoga berhasil.
Langsung bekerja - analitik teknis lanjutan
Keinginan untuk menerima informasi tentang masalah "secepat mungkin" membawa kami ke eksperimen aktif dengan alat yang sederhana dan mudah dipahami - pinba dan xhprof.
Pinba mengirimi kami statistik paket UDP tentang kecepatan bagian halaman web dalam PHP dan dimungkinkan untuk melihat online di penyimpanan MySQL (pinba dilengkapi dengan mesin MySQL-nya sendiri untuk analitik acara cepat) daftar singkat masalah dan menanggapinya. Dan xhprof dalam mode otomatis memungkinkan pengumpulan grafik eksekusi dari halaman PHP paling lambat dari klien dan menganalisis apa yang dapat menyebabkan hal ini - dengan tenang, menuangkan teh atau sesuatu yang lebih kuat.
Beberapa waktu yang lalu, toolkit ini dilengkapi dengan mesin lain yang cukup sederhana dan mudah berdasarkan algoritma pengindeksan terbalik, yang diterapkan dengan sempurna di pustaka Lucene legendaris - Elastic / Kibana. Ide sederhana menulis multi-threaded dokumen ke indeks terbalik Lucene berdasarkan kejadian di log dan dengan cepat mencarinya menggunakan divisi faceted ternyata sangat berguna.
Terlepas dari jenis visualisasi yang agak teknis di Kibana dengan konsep tingkat rendah yang "mengalir ke atas" seperti "ember" dan bahasa yang baru ditemukan dari aljabar relasional yang belum terlupakan, alat tersebut mulai membantu kami dengan baik dalam tugas-tugas berikut:
- Berapa banyak kesalahan PHP yang dimiliki klien Bitrix24 di portal p1 dalam satu jam terakhir, dan yang mana? Pahami, maafkan, dan perbaiki dengan cepat.
- - 24 , /?
- ( C PHP), ? segfaults?
- PHP? : «out of memory»? .
Inilah contoh konkretnya. Meskipun pengujian yang cermat dan multi-level, klien, dengan kasus yang sangat non-standar dan data input yang rusak, mengalami kesalahan yang mengganggu dan tidak terduga, bunyi sirene dan proses perbaikan cepatnya dimulai:
Selain itu, kibana memungkinkan Anda untuk mengatur pemberitahuan peristiwa tertentu dan dalam waktu singkat telah menjadi alat di perusahaan menggunakan lusinan karyawan dari berbagai departemen - dari dukungan teknis dan pengembangan hingga QA.
Menjadi mudah untuk memantau dan mengukur aktivitas setiap divisi di dalam perusahaan - alih-alih menganalisis log secara manual di server, cukup dengan mengatur penguraian log dan mengirimnya ke cluster elastis sekali, untuk menikmati, misalnya, merenungkan di dasbor kibana jumlah anak kucing berkepala dua yang terjual dicetak pada 3-d printer untuk bulan lunar terakhir.
Intelijen Bisnis Dasar
Semua orang tahu bahwa kecerdasan bisnis di perusahaan sering kali dimulai dengan penggunaan yang sangat aktif, ya, ya, Excel. Tapi, yang utama adalah itu tidak berakhir di situ. Cloud Google Analytics menambahkan bahan bakar ke dalam api - Anda cepat terbiasa dengan hal-hal yang baik.
Dalam perusahaan kami yang berkembang secara harmonis, "nabi" yang bekerja lebih intensif dengan data yang lebih besar mulai muncul di sana-sini. Kebutuhan akan laporan yang lebih dalam dan beragam mulai muncul secara teratur, dan berkat upaya orang-orang dari berbagai departemen, solusi sederhana dan praktis telah diselenggarakan beberapa waktu lalu - kombinasi ClickHouse dan PowerBI.
Untuk waktu yang cukup lama, solusi fleksibel ini banyak membantu, tetapi lambat laun ia mulai memahami bahwa ClickHouse bukanlah karet dan tidak dapat dipermainkan seperti itu.
Di sini penting untuk dipahami dengan baik bahwa ClickHouse, seperti Druid, seperti Vertica, seperti Amazon RedShift (yang didasarkan pada postgres), adalah mesin analitik yang dioptimalkan untuk analitik yang cukup nyaman (jumlah, agregasi, minimum-maksimum per kolom dan sedikit gabungan ), karena diatur untuk secara efisien menyimpan kolom dalam tabel relasional, tidak seperti MySQL dan database lain (berorientasi baris) yang kita kenal.
Faktanya, ClickHouse hanyalah sebuah "database" data yang lebih luas, dengan penyisipan titik yang tidak terlalu nyaman (seperti yang dimaksudkan, semuanya baik-baik saja), tetapi analitik yang bagus dan serangkaian fungsi hebat yang menarik untuk bekerja dengan data. Ya, Anda bahkan dapat membuat cluster - tetapi Anda memahami bahwa paku palu dengan mikroskop tidak sepenuhnya benar, dan kami mulai mencari solusi lain.
Permintaan python dan analis
Ada banyak developer di perusahaan kami yang menulis kode hampir setiap hari selama 10-20 tahun di PHP, JavaScript, C #, C / C ++, Java, Go, Rust, Python, Bash. Ada juga banyak administrator sistem berpengalaman yang telah selamat dari lebih dari satu bencana yang benar-benar luar biasa yang tidak sesuai dengan hukum statistik (misalnya, ketika sebagian besar disk dalam raid-10 dihancurkan oleh sambaran petir yang kuat). Dalam kondisi seperti itu, untuk waktu yang lama tidak jelas apa itu "analis python". Python seperti PHP, hanya namanya sedikit lebih panjang dan jejak zat yang mengubah pikiran sedikit lebih kecil di kode sumber penerjemah. Namun, karena semakin banyak laporan analitis dibuat, pengembang berpengalaman mulai semakin menyadari pentingnya spesialisasi sempit pada alat seperti numpy, pandas, matplotlib, seaborn.
Peran yang menentukan kemungkinan besar dimainkan oleh karyawan yang tiba-tiba pingsan karena kombinasi kata "regresi logistik" dan demonstrasi pelaporan yang efektif pada data besar menggunakan yes, yes, pyspark.
Apache Spark, paradigma fungsionalnya, aljabar relasional, dan kemampuannya sangat mengesankan para pengembang yang terbiasa dengan MySQL sehingga kebutuhan untuk memperkuat peringkat pertempuran dengan analis berpengalaman menjadi semakin jelas.
Upaya lebih lanjut oleh Apache Spark / Hadoop untuk lepas landas dan apa yang salah
Namun, segera menjadi jelas bahwa dengan Spark, tampaknya, ada sesuatu yang secara sistemik tidak beres, atau Anda hanya perlu mencuci tangan dengan lebih baik. Jika stack Hadoop / MapReduce / Lucene dibuat oleh programmer yang cukup berpengalaman, yang jelas terlihat jika Anda melihat source code di Java atau ide-ide Doug Cutting di Lucene dengan penuh semangat, maka Spark, tiba-tiba, ditulis dengan sangat kontroversial dari sudut pandang kepraktisan dan sekarang tidak mengembangkan Scala yang eksotis. Dan penurunan reguler dalam perhitungan pada cluster Spark karena pekerjaan yang tidak logis dan tidak terlalu transparan dengan mengalokasikan memori untuk operasi pengurangan (banyak kunci tiba sekaligus) - menciptakan lingkaran cahaya di sekitarnya yang memiliki ruang untuk berkembang. Selain itu, situasinya diperburuk oleh sejumlah besar port terbuka yang aneh, file sementara,tumbuh di tempat-tempat yang paling tidak bisa dipahami dan neraka ketergantungan toples - yang menyebabkan administrator sistem memiliki perasaan yang satu dan terkenal sejak masa kanak-kanak: kebencian yang hebat (atau mungkin perlu mencuci tangan dengan sabun dan air).
Hasilnya, kami "bertahan" dari beberapa proyek analitik internal yang secara aktif menggunakan Apache Spark (termasuk Spark Streaming, Spark SQL) dan ekosistem Hadoop (dan lainnya dan lainnya). Terlepas dari kenyataan bahwa seiring waktu kami belajar memasak dan memantau "itu" dengan baik dan "itu" secara praktis berhenti tiba-tiba jatuh karena perubahan dalam sifat data dan ketidakseimbangan hashing RDD seragam, keinginan untuk mengambil sesuatu yang sudah jadi, diperbarui dan dikelola di suatu tempat di awan itu tumbuh semakin kuat. Pada saat inilah kami mencoba menggunakan rakitan Amazon Web Services berbasis cloud yang sudah jadi - EMR dan, kemudian, mencoba menyelesaikan masalah di dalamnya. EMR adalah Apache Spark yang disiapkan oleh Amazon dengan perangkat lunak tambahan dari ekosistem, mirip dengan build Cloudera / Hortonworks.
Penyimpanan file karet untuk analitik - kebutuhan mendesak
Pengalaman "memasak" Hadoop / Spark dengan luka bakar di berbagai bagian tubuh ternyata tidak sia-sia. Kebutuhan untuk membuat penyimpanan file tunggal, murah dan andal yang akan tahan terhadap kegagalan perangkat keras dan yang memungkinkan untuk menyimpan file dalam format yang berbeda dari sistem yang berbeda dan di mana dimungkinkan untuk membuat pilihan yang efisien dan tepat waktu untuk laporan berdasarkan data ini mulai menjadi semakin jelas.
Saya juga ingin pembaruan perangkat lunak platform ini tidak berubah menjadi mimpi buruk Tahun Baru dengan membaca 20-halaman jejak Java dan menganalisis log cluster terperinci sepanjang kilometer menggunakan Spark History Server dan kaca pembesar dengan lampu latar. Saya ingin memiliki alat sederhana dan transparan yang tidak memerlukan penyelaman biasa, jika pengembang berhenti menjalankan permintaan MapReduce standar ketika pekerja data yang dikurangi keluar dari memori dengan algoritma partisi yang dipilih dengan buruk untuk data awal.
Amazon S3 seorang Kandidat DataLake?
Pengalaman dengan Hadoop / MapReduce mengajarkan bahwa Anda memerlukan sistem file yang dapat diskalakan, andal, dan pekerja yang dapat diskalakan di atasnya, "datang" lebih dekat ke data, agar tidak mengarahkan data melalui jaringan. Pekerja harus dapat membaca data dalam format yang berbeda, tetapi, sebaiknya, tidak membaca informasi yang tidak perlu dan agar data dapat disimpan sebelumnya dalam format yang sesuai bagi pekerja.
Sekali lagi, ide utamanya.Tidak ada keinginan untuk "mengunggah" data besar ke dalam satu mesin analitik kluster, yang cepat atau lambat akan tenggelam dan harus menjadi pecahan yang jelek. Saya ingin menyimpan file, hanya file, dalam format yang dapat dimengerti dan melakukan kueri analitis yang efektif dengan alat yang berbeda namun dapat dimengerti. Dan akan ada lebih banyak file dalam format yang berbeda. Dan lebih baik membuang bukan mesinnya, tapi data awal. Kami membutuhkan DataLake yang dapat diperluas dan serbaguna, kami memutuskan ...
Bagaimana jika kami menyimpan file di penyimpanan cloud Amazon S3 yang sudah dikenal dan terskala tanpa harus membuat potongan sendiri dari Hadoop?
Jelas bahwa datanya "bawah", tetapi data lain jika Anda mengeluarkannya dan "mengendarainya secara efektif"?
Ekosistem analitik cluster-bigdata dari Amazon Web Services - dengan kata yang sangat sederhana
Dilihat dari pengalaman kami dengan AWS, ini telah secara aktif digunakan di sana untuk waktu yang lama dengan berbagai saus Apache Hadoop / MapReduce, misalnya, dalam layanan DataPipeline (Saya iri dengan rekan-rekan saya, mereka belajar cara memasaknya dengan benar). Di sini kami telah mengonfigurasi cadangan dari berbagai layanan dari tabel DynamoDB:
Dan cadangan tersebut telah dilakukan secara teratur pada cluster Hadoop / MapReduce bawaan seperti jarum jam selama beberapa tahun. Siapkan dan lupakan:
Anda juga dapat terlibat secara efektif dalam penyiksaan data dengan meningkatkan laptop Jupiter untuk analis di cloud dan menggunakan AWS SageMaker untuk melatih dan menerapkan model AI ke dalam pertempuran. Begini tampilannya bagi kami:
Dan ya, Anda dapat mengambil laptop di cloud untuk diri sendiri atau analytics dan memasangnya ke cluster Hadoop / Spark, menghitung dan kemudian "menyelesaikan" semuanya:
Sangat nyaman untuk proyek analitik individu dan untuk beberapa kami telah berhasil menggunakan layanan EMR untuk kalkulasi dan analitik skala besar. Bagaimana dengan solusi sistem untuk DataLake, apakah akan berhasil? Pada saat itu kami berada di ambang harapan dan keputusasaan dan melanjutkan pencarian kami.
AWS Glue - Apache Spark yang dikemas rapi "dengan steroid"
Ternyata AWS memiliki versi tumpukan Hive / Pig / Spark sendiri. Peran sarang, mis. katalog file dan tipenya di DataLake menjalankan layanan "Katalog data", yang tidak menyembunyikan kompatibilitasnya dengan format Apache Hive. Dalam layanan ini Anda perlu menambahkan informasi tentang di mana file Anda berada dan dalam format apa. Data tidak hanya bisa di s3, tetapi juga di database, tapi ini bukan tentang itu di posting ini. Berikut bagaimana direktori data DataLake diatur di sini:
File sudah terdaftar, bagus. Jika file telah diperbarui, kami meluncurkannya dengan tangan atau berdasarkan jadwal oleh perayap, yang akan memperbarui informasi tentang mereka dari danau dan menyimpannya. Kemudian data dari danau tersebut dapat diolah dan hasilnya dapat diturunkan di suatu tempat. Dalam kasus yang paling sederhana, kami mengunggahnya ke s3 juga. Pemrosesan data dapat dilakukan di mana saja, tetapi disarankan untuk menyiapkan pemrosesan pada klaster Apache Spark menggunakan kapabilitas tingkat lanjut melalui AWS Glue API. Faktanya, Anda dapat mengambil kode python lama dan familiar menggunakan pyspark library dan mengkonfigurasinya untuk berjalan di N node dari cluster dengan beberapa kapasitas dengan pemantauan, tanpa menggali ke dalam jeroan ayam itik Hadoop dan menyeret kontainer docker-mocker dan menghilangkan konflik ketergantungan.
Sekali lagi, ide yang sederhana.Anda tidak perlu mengkonfigurasi Apache Spark, Anda hanya perlu menulis kode python untuk pyspark, mengujinya secara lokal di desktop dan kemudian menjalankannya di cluster besar di cloud, yang menunjukkan di mana sumber data dan di mana harus meletakkan hasilnya. Kadang-kadang perlu dan berguna, dan begitulah cara mengonfigurasinya dengan kami:
Jadi, jika Anda perlu menghitung sesuatu di cluster Spark pada data di s3 - tulis kode di python / pyspark, uji dan lakukan perjalanan yang baik ke cloud.
Bagaimana dengan orkestrasinya? Dan apakah tugas itu jatuh dan hilang? Ya, kami mengusulkan untuk membuat pipeline yang indah dengan gaya Apache Pig dan kami bahkan mencobanya, tetapi memutuskan untuk menggunakan orkestrasi kami yang sangat disesuaikan di PHP dan JavaScript untuk saat ini (saya mengerti, ada disonansi kognitif, tetapi berfungsi selama bertahun-tahun dan tanpa kesalahan).
Format file Lake adalah kunci kinerja
Sangat, sangat penting untuk memahami dua poin kunci lagi. Agar permintaan data dari file di danau dieksekusi secepat mungkin dan kinerja tidak menurun saat informasi baru ditambahkan, Anda memerlukan:
- Simpan kolom file secara terpisah (sehingga Anda tidak perlu membaca semua baris untuk memahami apa yang ada di kolom). Untuk ini kami mengambil format parket dengan kompresi
- Sangat penting untuk memecah file menurut ayah dalam semangat: bahasa, tahun, bulan, hari, minggu. Mesin yang memahami jenis sharding ini hanya akan melihat ayah yang tepat, tanpa memasukkan semua data ke dalamnya.
Nyatanya, dengan cara ini, Anda menyusun data awal yang paling efisien untuk mesin analitik yang digantung di atas, yang secara selektif dapat memasukkan shard daddies dan hanya membaca kolom yang diperlukan dari file. Tidak perlu pergi ke mana pun, ini akan berubah menjadi "mengisi" data (penyimpanan akan meledak dengan mudah) - cukup masukkan ke dalam sistem file dengan format yang benar segera. Tentu saja, harus jelas di sini bahwa menyimpan file csv yang besar di DataLake, yang pertama-tama harus dibaca oleh cluster baris demi baris, untuk mengekstrak kolom, sangat tidak disarankan. Pikirkan lagi dua poin di atas jika belum jelas mengapa semua ini terjadi.
AWS Athena - "neraka" dari kotak tembakau
Dan kemudian, menciptakan sebuah danau, kami, entah bagaimana secara sepintas, menemukan Amazon Athena. Tiba-tiba ternyata dengan melipat file log kami yang besar secara rapi dengan shards-daddies dalam format kolom (parket) yang benar, Anda dapat dengan cepat membuat pilihan yang sangat informatif padanya dan membuat laporan TANPA, tanpa cluster Apache Spark / Glue.
Mesin data s3 Athena didasarkan pada Presto yang legendaris , anggota dari pendekatan pemrosesan data MPP (pemrosesan paralel masif), mengambil data di tempatnya, dari s3 dan Hadoop hingga Cassandra dan file teks biasa. Anda hanya perlu meminta Athena untuk menjalankan kueri SQL, lalu semuanya "bekerja dengan cepat dan dengan sendirinya". Penting untuk diperhatikan bahwa Athena itu "pintar", hanya membuka sharded daddies yang diperlukan dan hanya membaca kolom yang diperlukan dalam permintaan.
Permintaan ke Athena juga ditagih dengan menarik. Kami membayar untuk jumlah data yang dipindai . Itu. bukan untuk jumlah mesin dalam cluster per menit, tetapi ... untuk data yang benar-benar dipindai pada 100-500 mesin, hanya data yang diperlukan untuk memenuhi permintaan.
Dan dengan hanya meminta kolom yang diperlukan dari ayah dengan pecahan yang benar, ternyata layanan Athena menghabiskan biaya puluhan dolar sebulan. Hebat, hampir gratis, dibandingkan dengan analitik pada cluster!
Ngomong-ngomong, begini cara kami membagi data kami di s3:
Hasilnya, dalam waktu singkat, divisi yang sama sekali berbeda di perusahaan, dari keamanan informasi hingga analitik, mulai secara aktif mengajukan permintaan ke Athena dan dengan cepat, dalam hitungan detik, menerima jawaban yang berguna dari "besar" data untuk periode yang agak lama: bulan, setengah tahun, dll.
Tapi kami melangkah lebih jauh dan mulai pergi ke cloud untuk mendapatkan jawaban melalui driver ODBC : seorang analis menulis kueri SQL di konsol yang sudah dikenal, yang, pada 100-500 mesin, data wol "untuk satu sen" di s3 dan mengembalikan jawaban biasanya dalam beberapa detik. Nyaman. Dan cepat. Aku masih tidak percaya.
Hasilnya, setelah membuat keputusan untuk menyimpan data di s3, dalam format kolom yang efisien dan dengan pembagian data yang wajar oleh para ayah ... kami mendapatkan DataLake dan mesin analitik yang cepat dan murah - gratis. Dan dia menjadi sangat populer di perusahaan itu karena memahami SQL dan menjalankan urutan besarnya lebih cepat daripada memulai / menghentikan / mengonfigurasi cluster. "Dan kalau hasilnya sama, buat apa bayar lebih?"
Permintaan ke Athena terlihat seperti ini. Jika diinginkan, tentu saja Anda dapat membentuk cukupkueri SQL kompleks dan multi-halaman , tetapi kami akan membatasi diri pada pengelompokan sederhana. Mari kita lihat kode respons apa yang dimiliki klien beberapa minggu yang lalu di log server web dan pastikan tidak ada kesalahan:
kesimpulan
Setelah pergi, bukan untuk mengatakan bahwa jalan yang panjang, tetapi menyakitkan, terus-menerus menilai risiko dan tingkat kerumitan serta biaya dukungan secara memadai, kami telah menemukan solusi untuk DataLake dan analitik yang tidak pernah berhenti menyenangkan kami baik dengan kecepatan dan biaya kepemilikan.
Ternyata bahkan pengembang berpengalaman yang tidak pernah bekerja sebagai arsitek dan tidak dapat menggambar kotak pada kotak dengan panah dan yang mengetahui 50 istilah dari ekosistem Hadoop dapat membangun DataLake yang efisien, cepat, dan murah untuk kebutuhan divisi perusahaan yang sama sekali berbeda.
Di awal perjalanan, kepalaku terpecah dari kumpulan kebun binatang terliar perangkat lunak terbuka dan tertutup dan pemahaman tentang beban tanggung jawab kepada keturunan. Mulailah membangun DataLake Anda dari alat sederhana: nagios / munin -> elastic / kibana -> Hadoop / Spark / s3 ..., kumpulkan umpan balik dan pemahaman mendalam tentang fisika dari proses yang terjadi. Semuanya rumit dan berlumpur - berikan kepada musuh dan pesaing Anda.
Jika Anda tidak ingin menggunakan cloud dan suka memelihara, memperbarui, dan menambal proyek open source, Anda dapat membangun skema yang mirip dengan kami secara lokal, pada mesin kantor murah dengan Hadoop dan Presto di atasnya. Hal utama bukanlah berhenti dan maju, menghitung, mencari solusi sederhana dan jelas dan semuanya pasti akan berhasil! Semoga sukses untuk semuanya dan sampai jumpa!