Kami hidup dalam masa yang menakjubkan apabila anda boleh menyambung dengan cepat dan mudah beberapa alat sumber terbuka yang sudah siap, menyediakannya dengan "kesedaran dimatikan" anda mengikut nasihat stackoverflow, tanpa menyelidiki "berbilang huruf", dan melancarkan mereka ke dalam operasi komersial. Dan apabila anda perlu mengemas kini/mengembangkan atau seseorang secara tidak sengaja mengebut semula beberapa mesin - anda menyedari bahawa beberapa jenis mimpi buruk yang obsesif telah bermula dalam realiti, segala-galanya tiba-tiba menjadi lebih rumit tanpa dapat dikenali, tidak dapat berpatah balik, masa depan samar-samar dan lebih selamat, bukannya pengaturcaraan, ternak lebah dan buat keju.
Bukan sia-sia rakan sekerja yang lebih berpengalaman, dengan kepala mereka dipenuhi pepijat dan oleh itu sudah kelabu, merenungkan penggunaan pek "bekas" yang sangat pantas dalam "kiub" pada berpuluh-puluh pelayan dalam "bahasa bergaya" dengan sokongan terbina dalam untuk I/O tidak menyekat tak segerak, senyumlah dengan sederhana . Dan mereka secara senyap terus membaca semula "man ps", menyelidiki kod sumber "nginx" sehingga mata mereka berdarah, dan menulis, menulis, menulis ujian unit. Rakan sekerja tahu bahawa perkara yang paling menarik akan datang apabila "semua ini" suatu hari menjadi dipertaruhkan pada waktu malam pada Malam Tahun Baru. Dan mereka hanya akan dibantu dengan pemahaman yang mendalam tentang sifat unix, jadual keadaan TCP/IP yang dihafal dan algoritma carian pengisihan asas. Untuk menghidupkan semula sistem apabila bunyi lonceng berlaku.
Oh ya, saya sedikit terganggu, tetapi saya harap saya berjaya menyampaikan keadaan jangkaan.
Hari ini saya ingin berkongsi pengalaman kami dalam menggunakan timbunan yang mudah dan murah untuk DataLake, yang menyelesaikan sebahagian besar tugasan analisis dalam syarikat untuk bahagian struktur yang berbeza sama sekali.
Beberapa ketika dahulu, kami mendapat pemahaman bahawa syarikat semakin memerlukan hasil analisis produk dan teknikal (apatah lagi icing pada kek dalam bentuk pembelajaran mesin) dan untuk memahami trend dan risiko - kami perlu mengumpul dan menganalisis semakin banyak metrik.
Analitik teknikal asas dalam Bitrix24
Beberapa tahun yang lalu, serentak dengan pelancaran perkhidmatan Bitrix24, kami secara aktif melaburkan masa dan sumber dalam mencipta platform analisis yang mudah dan boleh dipercayai yang akan membantu melihat masalah dalam infrastruktur dengan cepat dan merancang langkah seterusnya. Sudah tentu, adalah dinasihatkan untuk mengambil alat siap sedia yang semudah dan boleh difahami. Hasilnya, nagios telah dipilih untuk pemantauan dan munin untuk analisis dan visualisasi. Kini kami mempunyai beribu-ribu cek dalam nagios, beratus-ratus carta dalam munin, dan rakan sekerja kami menggunakannya dengan jayanya setiap hari. Metriknya jelas, grafnya jelas, sistem telah berfungsi dengan pasti selama beberapa tahun dan ujian serta graf baharu kerap ditambahkan padanya: apabila kami menggunakan perkhidmatan baharu, kami menambah beberapa ujian dan graf. Semoga berjaya.
Finger on the Pulse - Analitis Teknikal Lanjutan
Keinginan untuk menerima maklumat tentang masalah "secepat mungkin" membawa kami ke percubaan aktif dengan alat yang mudah dan mudah difahami - pinba dan xhprof.
Pinba menghantar kepada kami statistik dalam paket UDP tentang kelajuan operasi bahagian halaman web dalam PHP, dan kami boleh melihat dalam talian dalam storan MySQL (Pinba dilengkapi dengan enjin MySQLnya sendiri untuk analitik acara pantas) senarai pendek masalah dan bertindak balas kepada mereka. Dan xhprof secara automatik membenarkan kami mengumpul graf pelaksanaan halaman PHP paling perlahan daripada pelanggan dan menganalisis perkara yang boleh membawa kepada ini - dengan tenang, menuangkan teh atau sesuatu yang lebih kuat.
Beberapa ketika dahulu, kit alat telah diisi semula dengan enjin lain yang agak mudah dan mudah difahami berdasarkan algoritma pengindeksan terbalik, dilaksanakan dengan sempurna dalam pustaka Lucene legenda - Elastic/Kibana. Idea mudah rakaman dokumen berbilang benang ke dalam indeks Lucene songsang berdasarkan peristiwa dalam log dan carian pantas melaluinya menggunakan bahagian facet ternyata sangat berguna.
Walaupun penampilan visualisasi yang agak teknikal di Kibana dengan konsep peringkat rendah seperti "baldi" "mengalir ke atas" dan bahasa ciptaan semula algebra hubungan yang belum dilupakan sepenuhnya, alat itu mula membantu kami dengan baik dalam tugasan berikut:
- Berapa banyak ralat PHP yang dialami oleh klien Bitrix24 pada portal p1 dalam sejam terakhir dan yang mana? Fahami, maafkan dan cepat betulkan.
- Berapakah bilangan panggilan video yang dibuat pada portal di Jerman dalam tempoh 24 jam sebelumnya, dengan kualiti apa dan adakah terdapat sebarang kesulitan dengan saluran/rangkaian?
- Sejauh manakah fungsi sistem (sambungan C kami untuk PHP), yang disusun daripada sumber dalam kemas kini perkhidmatan terkini dan dilancarkan kepada pelanggan, berfungsi? Adakah terdapat segfault?
- Adakah data pelanggan sesuai dengan memori PHP? Adakah terdapat sebarang ralat tentang melebihi memori yang diperuntukkan kepada proses: "kehabisan ingatan"? Cari dan neutralkan.
Berikut adalah contoh konkrit. Walaupun ujian menyeluruh dan pelbagai peringkat, pelanggan, dengan kes yang sangat tidak standard dan data input yang rosak, menerima ralat yang menjengkelkan dan tidak dijangka, siren berbunyi dan proses membetulkannya dengan cepat bermula:
Selain itu, kibana membolehkan anda mengatur pemberitahuan untuk acara tertentu, dan dalam masa yang singkat alat dalam syarikat itu mula digunakan oleh berpuluh-puluh pekerja dari jabatan yang berbeza - daripada sokongan teknikal dan pembangunan kepada QA.
Aktiviti mana-mana jabatan dalam syarikat menjadi mudah untuk dijejak dan diukur - bukannya menganalisis log secara manual pada pelayan, anda hanya perlu menyediakan log penghuraian sekali dan menghantarnya ke gugusan elastik untuk dinikmati, contohnya, merenung dalam kibana papan pemuka bilangan anak kucing berkepala dua yang dijual yang dicetak pada pencetak 3-D untuk bulan lunar yang lalu.
Analitis Perniagaan Asas
Semua orang tahu bahawa analisis perniagaan dalam syarikat selalunya bermula dengan penggunaan yang sangat aktif, ya, Excel. Tetapi perkara utama ialah ia tidak berakhir di sana. Google Analytics berasaskan awan juga menambah bahan api - anda dengan cepat mula membiasakan diri dengan perkara yang baik.
Dalam syarikat kami yang membangun secara harmoni, di sana sini "nabi" kerja yang lebih intensif dengan data yang lebih besar mula muncul. Keperluan untuk laporan yang lebih mendalam dan pelbagai rupa mula muncul dengan kerap, dan melalui usaha lelaki dari jabatan yang berbeza, suatu ketika dahulu penyelesaian yang mudah dan praktikal telah dianjurkan - gabungan ClickHouse dan PowerBI.
Untuk masa yang agak lama, penyelesaian fleksibel ini banyak membantu, tetapi secara beransur-ansur pemahaman mula datang bahawa ClickHouse bukan getah dan tidak boleh dipermainkan seperti itu.
Di sini adalah penting untuk memahami dengan baik bahawa ClickHouse, seperti Druid, seperti Vertica, seperti Amazon RedShift (yang berdasarkan postgres), adalah enjin analisis yang dioptimumkan untuk analisis yang agak mudah (jumlah, pengagregatan, minimum-maksimum mengikut lajur dan beberapa kemungkinan gabungan ), kerana dianjurkan untuk penyimpanan lajur jadual hubungan yang cekap, tidak seperti MySQL dan pangkalan data lain (berorientasikan baris) yang kami ketahui.
Pada dasarnya, ClickHouse hanyalah "pangkalan data" yang lebih luas, dengan sisipan titik demi titik yang tidak begitu mudah (begitulah tujuannya, semuanya ok), tetapi analitik yang menyenangkan dan satu set fungsi berkuasa yang menarik untuk bekerja dengan data. Ya, anda juga boleh membuat gugusan - tetapi anda faham bahawa memalu paku dengan mikroskop adalah tidak betul sepenuhnya dan kami mula mencari penyelesaian lain.
Permintaan untuk python dan penganalisis
Syarikat kami mempunyai ramai pembangun yang menulis kod hampir setiap hari selama 10-20 tahun dalam PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Terdapat juga banyak pentadbir sistem berpengalaman yang telah mengalami lebih daripada satu bencana yang luar biasa yang tidak sesuai dengan undang-undang statistik (contohnya, apabila majoriti cakera dalam serbuan-10 dimusnahkan oleh kilat yang kuat). Dalam keadaan sedemikian, untuk masa yang lama tidak jelas apa itu "penganalisis python". Python adalah seperti PHP, cuma namanya lebih panjang sedikit dan terdapat sedikit kesan bahan pengubah minda dalam kod sumber penterjemah. Walau bagaimanapun, apabila semakin banyak laporan analisis dibuat, pembangun berpengalaman mula semakin memahami kepentingan pengkhususan sempit dalam alatan seperti numpy, panda, matplotlib, seaborn.
Peranan yang menentukan, kemungkinan besar, dimainkan oleh pengsan pekerja secara tiba-tiba daripada gabungan perkataan "regresi logistik" dan demonstrasi pelaporan berkesan pada data besar menggunakan, ya, ya, pyspark.
Apache Spark, paradigma fungsinya di mana algebra perhubungan sesuai dengan sempurna, dan keupayaannya memberi kesan kepada pembangun yang terbiasa dengan MySQL bahawa keperluan untuk mengukuhkan kedudukan dengan penganalisis berpengalaman menjadi jelas dari hari ke hari.
Percubaan lanjut Apache Spark/Hadoop untuk berlepas dan apa yang tidak berjalan mengikut skrip
Walau bagaimanapun, ia tidak lama kemudian menjadi jelas bahawa ada sesuatu yang tidak betul secara sistemik dengan Spark, atau hanya perlu mencuci tangan anda dengan lebih baik. Jika timbunan Hadoop/MapReduce/Lucene dibuat oleh pengaturcara yang cukup berpengalaman, yang jelas jika anda melihat dengan teliti kod sumber dalam Java atau idea Doug Cutting di Lucene, maka Spark, tiba-tiba, ditulis dalam bahasa eksotik Scala, iaitu sangat kontroversial dari sudut praktikal dan pada masa ini tidak berkembang. Dan kejatuhan biasa dalam pengiraan pada gugusan Spark kerana kerja yang tidak logik dan tidak terlalu telus dengan peruntukan memori untuk mengurangkan operasi (banyak kunci tiba sekali gus) telah mencipta lingkaran di sekelilingnya tentang sesuatu yang mempunyai ruang untuk berkembang. Selain itu, keadaan diburukkan lagi oleh sejumlah besar port terbuka yang pelik, fail sementara yang tumbuh di tempat yang paling sukar difahami dan ketergantungan yang besar - yang menyebabkan pentadbir sistem mempunyai satu perasaan yang terkenal sejak zaman kanak-kanak: kebencian yang sengit (atau mungkin mereka perlu membasuh tangan dengan sabun).
Akibatnya, kami telah "bertahan" beberapa projek analisis dalaman yang secara aktif menggunakan Apache Spark (termasuk Spark Streaming, Spark SQL) dan ekosistem Hadoop (dan seterusnya dan seterusnya). Walaupun fakta bahawa dari masa ke masa kami belajar untuk menyediakan dan memantau "ia" dengan baik, dan "ia" hampir berhenti tiba-tiba ranap disebabkan oleh perubahan dalam sifat data dan ketidakseimbangan pencincangan RDD seragam, keinginan untuk mengambil sesuatu yang sudah sedia. , dikemas kini dan ditadbir di suatu tempat dalam awan menjadi lebih kuat dan lebih kukuh. Pada masa inilah kami cuba menggunakan pemasangan awan siap sedia bagi Perkhidmatan Web Amazon - dan, seterusnya, cuba menyelesaikan masalah menggunakannya. EMR ialah Apache Spark yang disediakan oleh Amazon dengan perisian tambahan daripada ekosistem, sama seperti binaan Cloudera/Hortonworks.
Penyimpanan fail getah untuk analitik adalah keperluan mendesak
Pengalaman βmemasakβ Hadoop/Spark dengan melecur ke pelbagai bahagian badan tidak sia-sia. Keperluan untuk mencipta storan fail tunggal, murah dan boleh dipercayai yang tahan terhadap kegagalan perkakasan dan di mana ia mungkin untuk menyimpan fail dalam format yang berbeza daripada sistem yang berbeza dan membuat sampel yang cekap dan cekap masa untuk laporan daripada data ini menjadi semakin meningkat. jelas.
Saya juga mahu pengemaskinian perisian platform ini tidak berubah menjadi mimpi ngeri Tahun Baru dengan membaca jejak Java 20 halaman dan menganalisis log terperinci sepanjang kilometer bagi kluster menggunakan Pelayan Sejarah Spark dan kaca pembesar bercahaya belakang. Saya mahu mempunyai alat yang ringkas dan telus yang tidak memerlukan penyelaman biasa di bawah hud jika permintaan MapReduce standard pembangun berhenti melaksanakan apabila pekerja data pengurangan hilang daripada ingatan disebabkan oleh algoritma pembahagian data sumber yang tidak begitu baik.
Adakah Amazon S3 calon untuk DataLake?
Pengalaman dengan Hadoop/MapReduce mengajar kami bahawa kami memerlukan sistem fail berskala, boleh dipercayai dan pekerja berskala di atasnya, "mendekati" lebih dekat kepada data supaya tidak memacu data melalui rangkaian. Pekerja seharusnya boleh membaca data dalam format yang berbeza, tetapi sebaiknya jangan membaca maklumat yang tidak diperlukan dan boleh menyimpan data terlebih dahulu dalam format yang sesuai untuk pekerja.
Sekali lagi, idea asas. Tidak ada keinginan untuk "menuangkan" data besar ke dalam enjin analisis kluster tunggal, yang lambat laun akan tercekik dan anda perlu membelahnya dengan buruk. Saya ingin menyimpan fail, hanya fail, dalam format yang boleh difahami dan melakukan pertanyaan analitikal yang berkesan pada mereka menggunakan alat yang berbeza tetapi boleh difahami. Dan akan ada lebih banyak fail dalam format yang berbeza. Dan lebih baik untuk memecah enjin, tetapi data sumber. Kami memerlukan DataLake yang boleh diperluas dan universal, kami memutuskan...
Bagaimana jika anda menyimpan fail dalam storan awan berskala Amazon S3 yang biasa dan terkenal, tanpa perlu menyediakan potongan anda sendiri daripada Hadoop?
Jelas sekali bahawa data peribadi adalah "rendah", tetapi bagaimana pula dengan data lain jika kami mengeluarkannya dan "mendorongnya dengan berkesan"?
Ekosistem kluster-bigdata-analytics Perkhidmatan Web Amazon - dalam perkataan yang sangat mudah
Berdasarkan pengalaman kami dengan AWS, Apache Hadoop/MapReduce telah digunakan secara aktif di sana untuk masa yang lama di bawah pelbagai sos, contohnya dalam perkhidmatan DataPipeline (Saya iri dengan rakan sekerja saya, mereka belajar cara menyediakannya dengan betul). Di sini kami menyediakan sandaran daripada perkhidmatan yang berbeza daripada jadual DynamoDB:
Dan mereka telah berjalan dengan kerap pada kelompok Hadoop/MapReduce yang dibenamkan seperti kerja jam selama beberapa tahun sekarang. "Tetapkan dan lupakannya":
Anda juga boleh melibatkan diri dalam satanisme data dengan berkesan dengan menyediakan komputer riba Jupiter di awan untuk penganalisis dan menggunakan perkhidmatan AWS SageMaker untuk melatih dan menggunakan model AI ke dalam pertempuran. Inilah rupanya bagi kami:
Dan ya, anda boleh mengambil komputer riba untuk diri sendiri atau penganalisis dalam awan dan melampirkannya pada kelompok Hadoop/Spark, lakukan pengiraan dan kemudian catat semuanya:
Sangat mudah untuk projek analisis individu dan bagi sesetengah pihak kami telah berjaya menggunakan perkhidmatan EMR untuk pengiraan dan analisis berskala besar. Bagaimana pula dengan penyelesaian sistem untuk DataLake, adakah ia akan berfungsi? Pada ketika ini kami berada di ambang harapan dan putus asa dan meneruskan pencarian.
AWS Glue - Apache Spark yang dibungkus kemas pada steroid
Ternyata AWS mempunyai versi timbunan "Hive/Pig/Spark" sendiri. Peranan Hive, i.e. Katalog fail dan jenisnya dalam DataLake dilakukan oleh perkhidmatan "Katalog data", yang tidak menyembunyikan keserasiannya dengan format Apache Hive. Anda perlu menambah maklumat pada perkhidmatan ini tentang lokasi fail anda dan dalam format apa ia berada. Data boleh bukan sahaja dalam s3, tetapi juga dalam pangkalan data, tetapi itu bukan subjek siaran ini. Begini cara direktori data DataLake kami disusun:
Fail didaftarkan, bagus. Jika fail telah dikemas kini, kami melancarkan perangkak sama ada secara manual atau mengikut jadual, yang akan mengemas kini maklumat tentangnya dari tasik dan menyimpannya. Kemudian data dari tasik boleh diproses dan hasilnya dimuat naik ke suatu tempat. Dalam kes paling mudah, kami juga memuat naik ke s3. Pemprosesan data boleh dilakukan di mana-mana sahaja, tetapi dicadangkan anda mengkonfigurasi pemprosesan pada kluster Apache Spark menggunakan keupayaan lanjutan melalui AWS Glue API. Malah, anda boleh mengambil kod python lama dan biasa yang baik menggunakan perpustakaan pyspark dan mengkonfigurasi pelaksanaannya pada N nod sekumpulan beberapa kapasiti dengan pemantauan, tanpa menggali ke dalam hati Hadoop dan menyeret bekas docker-moker dan menghapuskan konflik pergantungan .
Sekali lagi, idea yang mudah. Tidak perlu mengkonfigurasi Apache Spark, anda hanya perlu menulis kod python untuk pyspark, mengujinya secara setempat pada desktop anda dan kemudian menjalankannya pada gugusan besar dalam awan, menyatakan di mana data sumber berada dan di mana untuk meletakkan hasilnya. Kadangkala ini perlu dan berguna, dan berikut ialah cara kami menyediakannya:
Oleh itu, jika anda perlu mengira sesuatu pada gugusan Spark menggunakan data dalam s3, kami menulis kod dalam python/pyspark, mengujinya dan semoga berjaya ke awan.
Bagaimana dengan orkestrasi? Bagaimana jika tugas itu jatuh dan hilang? Ya, adalah dicadangkan untuk membuat saluran paip yang cantik dalam gaya Apache Pig dan kami juga mencubanya, tetapi buat masa ini kami memutuskan untuk menggunakan orkestrasi kami yang sangat disesuaikan dalam PHP dan JavaScript (saya faham, terdapat disonans kognitif, tetapi ia berfungsi, untuk tahun dan tanpa kesilapan).
Format fail yang disimpan di tasik adalah kunci kepada prestasi
Sangat, sangat penting untuk memahami dua lagi perkara utama. Agar pertanyaan pada data fail di tasik dapat dilaksanakan secepat mungkin dan prestasi tidak menurun apabila maklumat baharu ditambah, anda perlu:
- Simpan lajur fail secara berasingan (supaya anda tidak perlu membaca semua baris untuk memahami perkara dalam lajur). Untuk ini kami mengambil format parket dengan mampatan
- Adalah sangat penting untuk memecah fail ke dalam folder seperti: bahasa, tahun, bulan, hari, minggu. Enjin yang memahami jenis sharding ini hanya akan melihat pada folder yang diperlukan, tanpa menapis semua data berturut-turut.
Pada asasnya, dengan cara ini, anda membentangkan data sumber dalam bentuk yang paling cekap untuk enjin analitik yang digantung di atas, yang walaupun dalam folder beling boleh secara selektif memasukkan dan membaca hanya lajur yang diperlukan daripada fail. Anda tidak perlu "mengisi" data di mana-mana sahaja (storan hanya akan pecah) - hanya dengan serta-merta dengan bijak meletakkannya dalam sistem fail dalam format yang betul. Sudah tentu, harus jelas di sini bahawa menyimpan fail csv yang besar dalam DataLake, yang mesti dibaca baris demi baris oleh kluster terlebih dahulu untuk mengekstrak lajur, adalah tidak digalakkan. Fikirkan kembali dua perkara di atas jika masih belum jelas mengapa semua ini berlaku.
AWS Athena - jack-in-the-box
Dan kemudian, semasa mencipta tasik, kami entah bagaimana secara tidak sengaja terjumpa Amazon Athena. Tiba-tiba ternyata bahawa dengan menyusun fail log besar kami dengan teliti ke dalam serpihan folder dalam format lajur (parket) yang betul, anda boleh dengan cepat membuat pilihan yang sangat bermaklumat daripadanya dan membina laporan TANPA, tanpa kluster Apache Spark/Glue.
Enjin Athena yang dikuasakan oleh data dalam s3 adalah berdasarkan legenda - wakil keluarga MPP (pemprosesan selari besar-besaran) pendekatan kepada pemprosesan data, mengambil data di mana ia terletak, daripada s3 dan Hadoop ke Cassandra dan fail teks biasa. Anda hanya perlu meminta Athena untuk melaksanakan pertanyaan SQL, dan kemudian semuanya "berfungsi dengan cepat dan automatik." Adalah penting untuk ambil perhatian bahawa Athena adalah "pintar", ia hanya pergi ke folder sharded yang diperlukan dan hanya membaca lajur yang diperlukan dalam permintaan.
Harga untuk permintaan kepada Athena juga menarik. Kita bayar . Itu. bukan untuk bilangan mesin dalam kluster seminit, tetapi... untuk data yang sebenarnya diimbas pada 100-500 mesin, hanya data yang diperlukan untuk melengkapkan permintaan.
Dan dengan meminta hanya lajur yang diperlukan dari folder yang dipecahkan dengan betul, ternyata perkhidmatan Athena menelan belanja kami berpuluh-puluh dolar sebulan. Baik, hebat, hampir percuma, berbanding analitis pada kelompok!
Ngomong-ngomong, inilah cara kami memecah data kami dalam s3:
Akibatnya, dalam masa yang singkat, jabatan yang sama sekali berbeza dalam syarikat, daripada keselamatan maklumat kepada analitik, mula aktif membuat permintaan kepada Athena dan dengan cepat, dalam beberapa saat, menerima jawapan yang berguna daripada data "besar" dalam tempoh yang agak lama: bulan, setengah tahun, dsb. P.
Tetapi kami pergi lebih jauh dan mula pergi ke awan untuk mendapatkan jawapan : seorang penganalisis menulis pertanyaan SQL dalam konsol biasa, yang pada 100-500 mesin "untuk sen" menghantar data ke s3 dan mengembalikan jawapan biasanya dalam beberapa saat. Selesa. Dan cepat. Saya masih tidak percaya.
Akibatnya, setelah memutuskan untuk menyimpan data dalam s3, dalam format kolumnar yang cekap dan dengan pembahagian data yang munasabah ke dalam folder... kami menerima DataLake dan enjin analisis yang pantas dan murah - secara percuma. Dan dia menjadi sangat popular di syarikat itu, kerana... memahami SQL dan menjalankan susunan magnitud lebih cepat daripada melalui permulaan/berhenti/menyediakan kelompok. "Dan jika keputusannya sama, mengapa membayar lebih?"
Permintaan kepada Athena kelihatan seperti ini. Sekiranya dikehendaki, sudah tentu, anda boleh membentuk cukup , tetapi kami akan mengehadkan diri kami kepada kumpulan mudah. Mari lihat kod tindak balas yang pelanggan miliki beberapa minggu lalu dalam log pelayan web dan pastikan tiada ralat:
Penemuan
Setelah melalui, bukan untuk mengatakan laluan yang panjang, tetapi menyakitkan, sentiasa menilai risiko dan tahap kerumitan dan kos sokongan dengan secukupnya, kami menemui penyelesaian untuk DataLake dan analitik yang tidak pernah berhenti menggembirakan kami dengan kedua-dua kelajuan dan kos pemilikan.
Ternyata membina DataLake yang berkesan, cepat dan murah untuk mengendalikan untuk keperluan jabatan yang sama sekali berbeza syarikat adalah benar-benar dalam keupayaan pemaju berpengalaman yang tidak pernah bekerja sebagai arkitek dan tidak tahu cara melukis petak pada petak dengan anak panah dan mengetahui 50 istilah daripada ekosistem Hadoop.
Pada awal perjalanan, kepala saya berpecah dari banyak zoo liar perisian terbuka dan tertutup dan pemahaman tentang beban tanggungjawab kepada keturunan. Hanya mula membina DataLake anda daripada alatan mudah: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., mengumpul maklum balas dan memahami secara mendalam fizik proses yang berlaku. Segala-galanya kompleks dan keruh - berikan kepada musuh dan pesaing.
Jika anda tidak mahu pergi ke awan dan suka menyokong, mengemas kini dan menampal projek sumber terbuka, anda boleh membina skim yang serupa dengan kami secara tempatan, pada mesin pejabat yang murah dengan Hadoop dan Presto di atas. Perkara utama bukanlah untuk berhenti dan bergerak ke hadapan, mengira, mencari penyelesaian yang mudah dan jelas, dan semuanya pasti akan berjaya! Semoga berjaya kepada semua orang dan jumpa lagi!
Sumber: www.habr.com