Kita hidup di masa yang menakjubkan ketika Anda dapat dengan cepat dan mudah menghubungkan beberapa alat sumber terbuka yang sudah jadi, mengaturnya dengan "kesadaran dimatikan" sesuai dengan saran dari stackoverflow, tanpa mempelajari "beberapa huruf", dan meluncurkan mereka ke dalam operasi komersial. Dan ketika Anda perlu memperbarui/memperluas atau seseorang secara tidak sengaja me-reboot beberapa mesin - Anda menyadari bahwa semacam mimpi buruk obsesif telah dimulai, segalanya menjadi sangat rumit hingga tak dapat dikenali lagi, tidak ada jalan untuk kembali, masa depan tidak jelas dan lebih aman, alih-alih memprogram, beternak lebah dan buat keju.
Bukan tanpa alasan bahwa rekan-rekan yang lebih berpengalaman, dengan kepala mereka dipenuhi bug dan karena itu sudah beruban, memikirkan penerapan paket "wadah" dalam "kubus" yang sangat cepat di lusinan server dalam "bahasa modis" dengan dukungan bawaan untuk I/O non-pemblokiran asinkron, tersenyumlah dengan sopan. Dan mereka diam-diam terus membaca ulang “man ps”, mempelajari kode sumber “nginx” sampai mata mereka berdarah, dan menulis, menulis, menulis unit test. Rekan-rekan kerja tahu bahwa hal yang paling menarik akan datang ketika “semua ini” suatu hari dipertaruhkan di malam hari pada Malam Tahun Baru. Dan mereka hanya akan terbantu dengan pemahaman mendalam tentang sifat unix, tabel status TCP/IP yang dihafal, dan algoritma pencarian pengurutan dasar. Untuk menghidupkan kembali sistem saat lonceng berbunyi.
Oh ya, saya sedikit teralihkan, tapi saya harap saya berhasil menyampaikan keadaan antisipasi tersebut.
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 sangat berbeda.
Beberapa waktu yang lalu, kami memahami bahwa perusahaan semakin membutuhkan hasil dari analisis produk dan teknis (belum lagi hal yang paling penting dalam bentuk pembelajaran mesin) dan untuk memahami tren dan risiko - kami perlu mengumpulkan dan menganalisis semakin 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 sederhana dan andal yang akan membantu melihat masalah infrastruktur dengan cepat dan merencanakan langkah selanjutnya. Tentu saja, disarankan untuk mengambil alat yang sudah jadi yang sesederhana dan sedapat mungkin dimengerti. Hasilnya, nagios dipilih untuk pemantauan dan munin untuk analisis dan visualisasi. Sekarang kami memiliki ribuan cek di nagios, ratusan grafik di munin, dan kolega kami berhasil menggunakannya setiap hari. Metriknya jelas, grafiknya jelas, sistem telah bekerja dengan andal selama beberapa tahun dan pengujian serta grafik baru ditambahkan secara berkala ke dalamnya: saat kami mengoperasikan layanan baru, kami menambahkan beberapa pengujian dan grafik. Semoga beruntung.
Finger on the Pulse - Analisis Teknis Tingkat Lanjut
Keinginan untuk menerima informasi tentang masalah “secepat mungkin” membawa kami pada eksperimen aktif dengan alat yang sederhana dan mudah dipahami - pinba dan xhprof.
Pinba mengirimi kami statistik dalam paket UDP tentang kecepatan pengoperasian bagian halaman web dalam PHP, dan kami dapat melihat secara online di penyimpanan MySQL (Pinba dilengkapi dengan mesin MySQL sendiri untuk analisis peristiwa cepat) daftar singkat masalah dan tanggapannya mereka. Dan xhprof secara otomatis memungkinkan kami mengumpulkan grafik eksekusi halaman PHP paling lambat dari klien dan menganalisis apa yang menyebabkan hal ini - dengan tenang, menuangkan teh atau sesuatu yang lebih kuat.
Beberapa waktu yang lalu, toolkit ini diisi ulang dengan mesin lain yang cukup sederhana dan mudah dipahami berdasarkan algoritma pengindeksan terbalik, yang diterapkan dengan sempurna di perpustakaan Lucene yang legendaris - Elastic/Kibana. Ide sederhana untuk merekam dokumen multi-utas ke dalam indeks Lucene terbalik berdasarkan peristiwa di log dan mencarinya dengan cepat menggunakan pembagian faset ternyata sangat berguna.
Meskipun tampilan visualisasi di Kibana agak teknis dengan konsep tingkat rendah seperti “ember” “mengalir ke atas” dan bahasa aljabar relasional yang belum sepenuhnya terlupakan, alat ini mulai membantu kita dengan baik dalam tugas-tugas berikut:
- Berapa banyak kesalahan PHP yang dialami klien Bitrix24 di portal p1 dalam satu jam terakhir dan yang mana? Pahami, maafkan, dan cepat perbaiki.
- Berapa banyak panggilan video yang dilakukan di portal di Jerman dalam 24 jam sebelumnya, dengan kualitas apa dan apakah ada kesulitan dengan saluran/jaringan?
- Seberapa baik fungsionalitas sistem (ekstensi C kami untuk PHP), yang dikompilasi dari sumber dalam pembaruan layanan terbaru dan diluncurkan ke klien, berfungsi? Apakah ada segfault?
- Apakah data pelanggan masuk ke dalam memori PHP? Apakah ada kesalahan tentang kelebihan memori yang dialokasikan untuk proses: "kehabisan memori"? Temukan dan netralkan.
Berikut ini contoh konkritnya. Meskipun pengujian menyeluruh dan multi-level, klien, dengan kasus yang sangat tidak standar dan data input yang rusak, menerima kesalahan yang mengganggu dan tidak terduga, sirene berbunyi dan proses perbaikan cepat dimulai:
Selain itu, kibana memungkinkan Anda mengatur pemberitahuan untuk acara tertentu, dan dalam waktu singkat alat di perusahaan tersebut mulai digunakan oleh lusinan karyawan dari berbagai departemen - mulai dari dukungan teknis dan pengembangan hingga QA.
Aktivitas departemen mana pun dalam perusahaan menjadi mudah untuk dilacak dan diukur - alih-alih menganalisis log secara manual di server, Anda hanya perlu menyiapkan penguraian log satu kali dan mengirimkannya ke kluster elastis untuk dinikmati, misalnya, direnungkan di kibana dasbor jumlah penjualan anak kucing berkepala dua yang dicetak pada printer 3-D selama sebulan terakhir.
Analisis Bisnis Dasar
Semua orang tahu bahwa analisis bisnis di perusahaan sering kali dimulai dengan penggunaan Excel yang sangat aktif. Namun yang terpenting adalah hal itu tidak berakhir di situ. Google Analytics berbasis cloud juga menambahkan bahan bakar ke dalam api - Anda dengan cepat mulai terbiasa dengan hal-hal yang baik.
Di perusahaan kami yang berkembang secara harmonis, di sana-sini “nabi” yang bekerja lebih intensif dengan data yang lebih besar mulai bermunculan. Kebutuhan akan laporan yang lebih mendalam dan beragam mulai muncul secara teratur, dan melalui upaya orang-orang dari berbagai departemen, beberapa waktu lalu sebuah solusi sederhana dan praktis diselenggarakan - kombinasi ClickHouse dan PowerBI.
Untuk waktu yang cukup lama, solusi fleksibel ini banyak membantu, namun lambat laun mulai muncul pemahaman bahwa ClickHouse bukanlah karet dan tidak bisa diejek 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 analisis yang cukup nyaman (jumlah, agregasi, minimum-maksimum berdasarkan kolom dan beberapa kemungkinan gabungan ), Karena diatur untuk penyimpanan kolom tabel relasional yang efisien, tidak seperti MySQL dan database (berorientasi baris) lainnya yang kita kenal.
Intinya, ClickHouse hanyalah "database" yang lebih luas, dengan penyisipan poin demi poin yang tidak terlalu nyaman (begitulah tujuannya, semuanya baik-baik saja), tetapi analitik yang menyenangkan dan serangkaian fungsi menarik yang kuat untuk bekerja dengan data. Ya, Anda bahkan dapat membuat cluster - tetapi Anda memahami bahwa memalu paku dengan mikroskop tidak sepenuhnya benar dan kami mulai mencari solusi lain.
Permintaan python dan analis
Perusahaan kami memiliki banyak pengembang yang menulis kode hampir setiap hari selama 10-20 tahun dalam PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Ada juga banyak administrator sistem berpengalaman yang telah mengalami lebih dari satu bencana luar biasa yang tidak sesuai dengan hukum statistik (misalnya, ketika sebagian besar disk dalam serangan-10 dihancurkan oleh sambaran petir yang kuat). Dalam keadaan seperti itu, untuk waktu yang lama tidak jelas apa itu “analis python”. Python itu seperti PHP, hanya saja namanya sedikit lebih panjang dan jejak zat yang mengubah pikiran dalam kode sumber penerjemahnya sedikit lebih sedikit. Namun, seiring dengan semakin banyaknya laporan analitis yang dibuat, pengembang berpengalaman mulai semakin memahami 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, ya, ya, pyspark.
Apache Spark, paradigma fungsionalnya yang cocok dengan aljabar relasional, dan kemampuannya memberikan kesan yang besar pada pengembang yang terbiasa dengan MySQL sehingga kebutuhan untuk memperkuat peringkat dengan analis berpengalaman menjadi semakin jelas.
Upaya lebih lanjut dari Apache Spark/Hadoop untuk lepas landas dan apa yang tidak berjalan sesuai dengan skrip
Namun, segera menjadi jelas bahwa ada sesuatu yang tidak beres secara sistemis dengan Spark, atau Anda hanya perlu mencuci tangan dengan lebih baik. Jika tumpukan Hadoop/MapReduce/Lucene dibuat oleh programmer yang cukup berpengalaman, terlihat jelas jika Anda melihat lebih dekat kode sumber di Java atau ide Doug Cutting di Lucene, maka Spark tiba-tiba ditulis dalam bahasa eksotik Scala, yaitu sangat kontroversial dari segi kepraktisan dan saat ini tidak berkembang. Dan penurunan reguler dalam penghitungan pada kluster Spark karena pekerjaan yang tidak logis dan tidak terlalu transparan dengan alokasi memori untuk operasi pengurangan (banyak kunci tiba sekaligus) telah menciptakan lingkaran cahaya di sekitarnya dari sesuatu yang memiliki ruang untuk berkembang. Selain itu, situasi ini diperburuk oleh sejumlah besar port terbuka yang aneh, file-file sementara yang tumbuh di tempat yang paling tidak dapat dipahami, dan ketergantungan jar yang luar biasa - yang menyebabkan administrator sistem memiliki satu perasaan yang sudah diketahui sejak masa kanak-kanak: kebencian yang hebat (atau mungkin) mereka perlu mencuci tangan dengan sabun).
Hasilnya, kami telah “selamat” dari beberapa proyek analitis internal yang secara aktif menggunakan Apache Spark (termasuk Spark Streaming, Spark SQL) dan ekosistem Hadoop (dan seterusnya). Terlepas dari kenyataan bahwa seiring waktu kami belajar untuk mempersiapkan dan memantau "itu" dengan cukup baik, dan "itu" praktis berhenti tiba-tiba mogok karena perubahan sifat data dan ketidakseimbangan hashing RDD yang seragam, keinginan untuk mengambil sesuatu yang sudah siap , diperbarui dan dikelola di suatu tempat di cloud menjadi semakin kuat. Pada saat inilah kami mencoba menggunakan rakitan cloud Amazon Web Services yang sudah jadi - dan, selanjutnya, mencoba memecahkan masalah dengan menggunakannya. EMR adalah Apache Spark yang disiapkan oleh Amazon dengan perangkat lunak tambahan dari ekosistem, seperti yang dibuat oleh Cloudera/Hortonworks.
Penyimpanan file karet untuk analitik merupakan 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 tahan terhadap kegagalan perangkat keras dan memungkinkan untuk menyimpan file dalam format berbeda dari sistem berbeda serta membuat sampel yang efisien dan efisien waktu untuk laporan dari data ini menjadi semakin penting. jernih.
Saya juga ingin memperbarui perangkat lunak platform ini tidak berubah menjadi mimpi buruk Tahun Baru dengan membaca jejak Java sepanjang 20 halaman dan menganalisis log rinci cluster sepanjang satu kilometer menggunakan Spark History Server dan kaca pembesar dengan lampu latar. Saya ingin memiliki alat yang sederhana dan transparan yang tidak memerlukan penyelaman rutin jika permintaan MapReduce standar pengembang berhenti dijalankan ketika pekerja pengurangan data kehabisan memori karena algoritma partisi data sumber yang tidak dipilih dengan baik.
Apakah Amazon S3 merupakan kandidat untuk DataLake?
Pengalaman dengan Hadoop/MapReduce mengajarkan kita bahwa kita memerlukan sistem file yang dapat diskalakan dan andal serta pekerja yang dapat diskalakan di atasnya, “mendekat” ke data agar tidak mengarahkan data melalui jaringan. Pekerja harus dapat membaca data dalam format yang berbeda, namun sebaiknya tidak membaca informasi yang tidak perlu dan dapat menyimpan data terlebih dahulu dalam format yang nyaman bagi pekerja.
Sekali lagi, ide dasarnya. Tidak ada keinginan untuk "menuangkan" data besar ke dalam satu mesin analitik cluster, yang cepat atau lambat akan tersedak dan Anda harus membuangnya dengan buruk. Saya ingin menyimpan file, hanya file, dalam format yang dapat dimengerti dan melakukan kueri analitis yang efektif terhadap file tersebut menggunakan alat yang berbeda namun dapat dimengerti. Dan akan ada lebih banyak lagi file dalam format berbeda. Dan lebih baik untuk memecahkan bukan mesinnya, tetapi data sumbernya. Kami membutuhkan DataLake yang dapat diperluas dan universal, kami memutuskan...
Bagaimana jika Anda menyimpan file di penyimpanan cloud scalable Amazon S3 yang familiar dan terkenal, tanpa harus menyiapkan potongan Anda sendiri dari Hadoop?
Jelas bahwa data pribadi “sedikit”, tetapi bagaimana dengan data lain jika kita mengeluarkannya dan “menjalankannya secara efektif”?
Ekosistem cluster-bigdata-analytics dari Amazon Web Services - dengan kata yang sangat sederhana
Dilihat dari pengalaman kami dengan AWS, Apache Hadoop/MapReduce telah lama digunakan secara aktif di sana dengan berbagai saus, misalnya dalam layanan DataPipeline (saya iri pada rekan-rekan saya, mereka belajar cara menyiapkannya dengan benar). Di sini kami menyiapkan cadangan dari berbagai layanan dari tabel DynamoDB:
Dan mereka telah berjalan secara teratur pada cluster Hadoop/MapReduce yang tertanam seperti jam selama beberapa tahun sekarang. “Atur dan lupakan”:
Anda juga dapat secara efektif terlibat dalam satanisme data dengan menyiapkan laptop Jupiter di cloud untuk para analis dan menggunakan layanan AWS SageMaker untuk melatih dan menerapkan model AI ke dalam pertempuran. Berikut tampilannya bagi kami:
Dan ya, Anda dapat mengambil laptop untuk Anda sendiri atau analis di cloud dan melampirkannya ke cluster Hadoop/Spark, melakukan penghitungan, lalu menyelesaikan semuanya:
Sangat nyaman untuk proyek analitik individual dan untuk beberapa proyek kami telah berhasil menggunakan layanan EMR untuk perhitungan dan analitik skala besar. Bagaimana dengan solusi sistem untuk DataLake, apakah akan berhasil? Saat ini kami berada di ambang harapan dan keputusasaan dan melanjutkan pencarian.
AWS Glue - Apache Spark yang dikemas dengan rapi pada steroid
Ternyata AWS memiliki versi tumpukan “Hive/Pig/Spark” sendiri. Peran Hive, yaitu. Katalog file dan tipenya di DataLake dilakukan oleh layanan "Katalog Data", yang tidak menyembunyikan kompatibilitasnya dengan format Apache Hive. Anda perlu menambahkan informasi ke layanan ini tentang lokasi file Anda dan formatnya. Datanya bisa tidak hanya di s3, tapi juga di database, tapi itu bukan pokok bahasan postingan ini. Berikut cara pengelolaan direktori data DataLake kami:
Filenya sudah terdaftar, bagus. Jika file telah diperbarui, kami meluncurkan crawler baik secara manual atau terjadwal, yang akan memperbarui informasi tentang file tersebut dari danau dan menyimpannya. Kemudian data dari danau tersebut dapat diolah dan hasilnya diunggah ke suatu tempat. Dalam kasus paling sederhana, kami juga mengunggah ke s3. Pemrosesan data dapat dilakukan di mana saja, namun disarankan agar Anda mengonfigurasi pemrosesan pada klaster Apache Spark menggunakan kemampuan tingkat lanjut melalui API AWS Glue. Faktanya, Anda dapat mengambil kode python lama dan familiar menggunakan perpustakaan pyspark dan mengonfigurasi eksekusinya pada N node dari cluster dengan kapasitas tertentu dengan pemantauan, tanpa menggali inti Hadoop dan menyeret kontainer docker-moker dan menghilangkan konflik ketergantungan .
Sekali lagi, ide sederhana. Tidak perlu mengonfigurasi Apache Spark, Anda hanya perlu menulis kode python untuk pyspark, mengujinya secara lokal di desktop Anda, lalu menjalankannya di cluster besar di cloud, menentukan di mana sumber datanya dan di mana meletakkan hasilnya. Terkadang hal ini perlu dan berguna, dan inilah cara kami menyiapkannya:
Jadi, jika Anda perlu menghitung sesuatu di cluster Spark menggunakan data di s3, kami menulis kode dengan python/pyspark, mengujinya, dan semoga sukses di cloud.
Bagaimana dengan orkestrasinya? Bagaimana jika tugas itu gagal dan hilang? Ya, diusulkan untuk membuat pipeline yang indah dengan gaya Apache Pig dan kami bahkan mencobanya, tetapi untuk saat ini kami memutuskan untuk menggunakan orkestrasi kami yang sangat disesuaikan dalam PHP dan JavaScript (Saya mengerti, ada disonansi kognitif, tetapi berhasil, untuk tahun dan tanpa kesalahan).
Format file yang disimpan di danau adalah kunci kinerja
Sangat, sangat penting untuk memahami dua poin penting lainnya. Agar kueri tentang data file di danau dapat dieksekusi secepat mungkin dan kinerja tidak menurun saat informasi baru ditambahkan, Anda perlu:
- Simpan kolom file secara terpisah (sehingga Anda tidak perlu membaca semua baris untuk memahami isi kolom). Untuk ini kami mengambil format parket dengan kompresi
- Sangat penting untuk membagi file ke dalam folder seperti: bahasa, tahun, bulan, hari, minggu. Mesin yang memahami jenis sharding ini hanya akan melihat folder yang diperlukan, tanpa memilah semua data secara berurutan.
Intinya, dengan cara ini, Anda menata data sumber dalam bentuk yang paling efisien untuk mesin analitik yang digantung di atas, yang bahkan dalam folder yang di-sharding dapat secara selektif memasukkan dan hanya membaca kolom yang diperlukan dari file. Anda tidak perlu "mengisi" data di mana pun (penyimpanan akan langsung meledak) - cukup segera masukkan ke dalam sistem file dengan format yang benar. Tentu saja, harus jelas di sini bahwa menyimpan file csv berukuran besar di DataLake, yang harus dibaca baris demi baris terlebih dahulu oleh cluster untuk mengekstrak kolom, sangat tidak disarankan. Pikirkan kembali dua poin di atas jika belum jelas mengapa semua ini terjadi.
AWS Athena - jack-in-the-box
Dan kemudian, saat membuat danau, kami secara tidak sengaja menemukan Amazon Athena. Tiba-tiba ternyata dengan hati-hati mengatur file log besar kami ke dalam pecahan folder dalam format kolom (parket) yang benar, Anda dapat dengan cepat membuat pilihan yang sangat informatif dan membuat laporan TANPA, tanpa cluster Apache Spark/Glue.
Mesin Athena yang ditenagai oleh data di s3 didasarkan pada yang legendaris - perwakilan dari keluarga pendekatan MPP (pemrosesan paralel besar-besaran) untuk pemrosesan data, 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 otomatis”. Penting untuk dicatat bahwa Athena adalah “pintar”, ia hanya masuk ke folder sharded yang diperlukan dan hanya membaca kolom yang diperlukan dalam permintaan.
Harga permintaan ke Athena juga menarik. Kami membayar untuk . Itu. bukan untuk jumlah mesin dalam cluster per menit, tapi... untuk data yang benar-benar dipindai pada 100-500 mesin, hanya data yang diperlukan untuk menyelesaikan permintaan.
Dan dengan hanya meminta kolom yang diperlukan dari folder yang dipecah dengan benar, ternyata layanan Athena menghabiskan biaya puluhan dolar sebulan. Hebat, hampir gratis, dibandingkan dengan analitik pada cluster!
Omong-omong, inilah cara kami membagi data kami di s3:
Hasilnya, dalam waktu singkat, berbagai departemen di perusahaan, mulai dari keamanan informasi hingga analitik, mulai secara aktif mengajukan permintaan ke Athena dan dengan cepat, dalam hitungan detik, menerima jawaban berguna dari data “besar” dalam jangka waktu yang cukup lama: berbulan-bulan, setengah tahun, dll. P.
Namun kami melangkah lebih jauh dan mulai menggunakan cloud untuk mendapatkan jawaban : seorang analis menulis kueri SQL di konsol yang sudah dikenal, yang pada 100-500 mesin “untuk uang” mengirimkan data ke s3 dan biasanya mengembalikan jawaban dalam beberapa detik. Nyaman. Dan cepat. Saya masih tidak percaya.
Hasilnya, setelah memutuskan untuk menyimpan data dalam s3, dalam format kolom yang efisien dan dengan pembagian data yang wajar ke dalam folder... kami menerima DataLake dan mesin analitik yang cepat dan murah - gratis. Dan dia menjadi sangat populer di perusahaan, karena... memahami SQL dan bekerja jauh lebih cepat dibandingkan dengan memulai/menghentikan/menyiapkan cluster. “Dan jika hasilnya sama, mengapa harus membayar lebih?”
Permintaan kepada Athena terlihat seperti ini. Jika diinginkan, tentu saja bisa dibentuk secukupnya , tapi kami akan membatasi diri pada pengelompokan sederhana. Mari kita lihat kode respons apa yang dimiliki klien beberapa minggu lalu di log server web dan pastikan tidak ada kesalahan:
Temuan
Setelah melalui, bukan jalan yang panjang, namun menyakitkan, terus-menerus menilai risiko dan tingkat kompleksitas serta biaya dukungan secara memadai, kami menemukan solusi untuk DataLake dan analitik yang tidak pernah berhenti memuaskan kami dengan kecepatan dan biaya kepemilikan.
Ternyata membangun DataLake yang efektif, cepat dan murah untuk kebutuhan berbagai departemen perusahaan sepenuhnya berada dalam kemampuan pengembang berpengalaman yang belum pernah bekerja sebagai arsitek dan tidak tahu cara menggambar kotak di kotak dengan panah dan mengetahui 50 istilah dari ekosistem Hadoop.
Di awal perjalanan, kepala saya terpecah dari banyaknya kebun binatang liar yang memiliki perangkat lunak terbuka dan tertutup serta pemahaman tentang beban tanggung jawab kepada keturunan. Mulailah membangun DataLake Anda dari alat sederhana: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., kumpulkan masukan dan pahami secara mendalam proses fisika yang sedang berlangsung. Segala sesuatu yang rumit dan suram - berikan kepada musuh dan pesaing.
Jika Anda tidak ingin menggunakan cloud dan ingin mendukung, memperbarui, dan menambal proyek sumber terbuka, Anda dapat membuat skema serupa dengan skema kami secara lokal, pada mesin kantor murah dengan Hadoop dan Presto di atasnya. Hal utama adalah jangan berhenti dan bergerak maju, menghitung, mencari solusi yang sederhana dan jelas, dan semuanya pasti akan berhasil! Semoga sukses untuk semuanya dan sampai jumpa lagi!
Sumber: www.habr.com