Artikel ini adalah terjemahan artikel saya di medium - , yang ternyata agak popular, mungkin kerana kesederhanaannya. Oleh itu, saya memutuskan untuk menulisnya dalam bahasa Rusia dan menambah sedikit untuk menjelaskan kepada orang biasa yang bukan pakar data apa itu gudang data (DW), dan apa itu tasik data (Tasik Data), dan bagaimana mereka bergaul bersama.
Mengapa saya mahu menulis tentang tasik data? Saya telah bekerja dengan data dan analitik selama lebih 10 tahun, dan kini saya pasti bekerja dengan data besar di Amazon Alexa AI di Cambridge, yang berada di Boston, walaupun saya tinggal di Victoria di Pulau Vancouver dan sering melawat Boston, Seattle , dan Di Vancouver, dan kadang-kadang di Moscow, saya bercakap di persidangan. Saya juga menulis dari semasa ke semasa, tetapi saya menulis terutamanya dalam bahasa Inggeris, dan saya telah pun menulis , saya juga mempunyai keperluan untuk berkongsi aliran analitik dari Amerika Utara, dan kadangkala saya menulis .
Saya sentiasa bekerja dengan gudang data, dan sejak 2015 saya mula bekerja rapat dengan Perkhidmatan Web Amazon, dan secara amnya beralih kepada analitik awan (AWS, Azure, GCP). Saya telah memerhatikan evolusi penyelesaian analitik sejak 2007 dan juga bekerja untuk vendor gudang data Teradata dan melaksanakannya di Sberbank, dan ketika itulah Big Data dengan Hadoop muncul. Semua orang mula mengatakan bahawa era penyimpanan telah berlalu dan kini semuanya berada di Hadoop, dan kemudian mereka mula bercakap tentang Data Lake, sekali lagi, bahawa kini penghujung gudang data pasti akan datang. Tetapi mujurlah (mungkin malangnya bagi sesetengah orang yang membuat banyak wang untuk menubuhkan Hadoop), gudang data tidak hilang.
Dalam artikel ini kita akan melihat apa itu tasik data. Artikel ini ditujukan untuk orang yang mempunyai sedikit atau tiada pengalaman dengan gudang data.
Dalam gambar adalah Tasik Bled, ini adalah salah satu tasik kegemaran saya, walaupun saya berada di sana hanya sekali, saya mengingatinya sepanjang hayat saya. Tetapi kita akan bercakap tentang satu lagi jenis tasik - tasik data. Mungkin ramai di antara anda telah mendengar tentang istilah ini lebih daripada sekali, tetapi satu lagi definisi tidak akan membahayakan sesiapa pun.
Pertama sekali, berikut ialah takrifan Data Lake yang paling popular:
"simpanan fail semua jenis data mentah yang tersedia untuk analisis oleh sesiapa sahaja dalam organisasi" - Martin Fowler.
“Jika anda berpendapat bahawa data mart ialah sebotol air - disucikan, dibungkus dan dibungkus untuk kegunaan mudah, maka tasik data ialah takungan air yang besar dalam bentuk semula jadinya. Pengguna, saya boleh mengumpul air untuk diri sendiri, menyelam dalam-dalam, meneroka” - James Dixon.
Kini kami tahu pasti bahawa tasik data adalah mengenai analitik, ia membolehkan kami menyimpan sejumlah besar data dalam bentuk asalnya dan kami mempunyai akses yang diperlukan dan mudah kepada data tersebut.
Saya sering suka memudahkan perkara, jika saya boleh menerangkan istilah yang kompleks dengan perkataan yang mudah, maka saya faham sendiri bagaimana ia berfungsi dan untuk apa ia diperlukan. Pada suatu hari, saya melihat-lihat galeri foto iPhone, dan saya sedar, ini adalah tasik data sebenar, saya juga membuat slaid untuk persidangan:
Semuanya sangat mudah. Kami mengambil gambar pada telefon, foto itu disimpan pada telefon dan boleh disimpan ke iCloud (storan fail awan). Telefon juga mengumpul metadata foto: apa yang ditunjukkan, tag geo, masa. Hasilnya, kami boleh menggunakan antara muka mesra pengguna iPhone untuk mencari foto kami dan kami juga melihat penunjuk, contohnya, apabila saya mencari foto dengan perkataan api, saya dapati 3 foto dengan imej api. Bagi saya, ini sama seperti alat Perisikan Perniagaan yang berfungsi dengan cepat dan tepat.
Dan sudah tentu, kita tidak boleh lupa tentang keselamatan (kebenaran dan pengesahan), jika tidak, data kita boleh dengan mudah berakhir dalam domain awam. Terdapat banyak berita tentang syarikat besar dan syarikat pemula yang datanya tersedia secara terbuka kerana kecuaian pembangun dan kegagalan mematuhi peraturan mudah.
Malah gambar mudah sedemikian membantu kita membayangkan apa itu tasik data, perbezaannya daripada gudang data tradisional dan elemen utamanya:
- Memuatkan Data (Pengingesan) ialah komponen utama tasik data. Data boleh memasuki gudang data dalam dua cara - kelompok (memuatkan pada selang waktu) dan penstriman (aliran data).
- Penyimpanan fail (Storan) ialah komponen utama Tasik Data. Kami memerlukan storan supaya mudah berskala, sangat boleh dipercayai dan kos rendah. Sebagai contoh, dalam AWS ia adalah S3.
- Katalog dan Carian (Katalog dan Carian) - untuk mengelakkan Paya Data (ini adalah apabila kita membuang semua data dalam satu longgokan, dan kemudian adalah mustahil untuk bekerja dengannya), kita perlu mencipta lapisan metadata untuk mengklasifikasikan data supaya pengguna boleh mencari data dengan mudah, yang mereka perlukan untuk analisis. Selain itu, anda boleh menggunakan penyelesaian carian tambahan seperti ElasticSearch. Carian membantu pengguna mencari data yang diperlukan melalui antara muka yang mesra pengguna.
- Pemprosesan (Proses) - langkah ini bertanggungjawab untuk memproses dan mengubah data. Kami boleh mengubah data, menukar strukturnya, membersihkannya dan banyak lagi.
- keselamatan (Keselamatan) - Adalah penting untuk meluangkan masa pada reka bentuk keselamatan penyelesaian. Contohnya, penyulitan data semasa penyimpanan, pemprosesan dan pemuatan. Adalah penting untuk menggunakan kaedah pengesahan dan kebenaran. Akhirnya, alat audit diperlukan.
Dari sudut pandangan praktikal, kita boleh mencirikan tasik data dengan tiga atribut:
- Kumpul dan simpan apa sahaja — tasik data mengandungi semua data, kedua-dua data mentah yang belum diproses untuk sebarang tempoh masa dan data yang diproses/dibersihkan.
- Imbasan Dalam — tasik data membolehkan pengguna meneroka dan menganalisis data.
- Akses fleksibel — Tasik data menyediakan akses fleksibel untuk data yang berbeza dan senario yang berbeza.
Sekarang kita boleh bercakap tentang perbezaan antara gudang data dan tasik data. Biasanya orang bertanya:
- Bagaimana dengan gudang data?
- Adakah kita menggantikan gudang data dengan tasik data atau adakah kita mengembangkannya?
- Adakah masih boleh dilakukan tanpa tasik data?
Pendek kata, tiada jawapan yang jelas. Semuanya bergantung pada situasi tertentu, kemahiran pasukan dan bajet. Contohnya, memindahkan gudang data ke Oracle ke AWS dan mencipta tasik data oleh anak syarikat Amazon - Woot - .
Sebaliknya, vendor Snowflake mengatakan bahawa anda tidak perlu lagi memikirkan tentang tasik data, kerana platform data mereka (sehingga 2020 ia adalah gudang data) membolehkan anda menggabungkan kedua-dua tasik data dan gudang data. Saya tidak banyak bekerja dengan Snowflake, dan ia benar-benar produk unik yang boleh melakukan ini. Harga isu adalah perkara lain.
Kesimpulannya, pendapat peribadi saya ialah kami masih memerlukan gudang data sebagai sumber data utama untuk pelaporan kami, dan apa sahaja yang tidak sesuai kami simpan dalam tasik data. Peranan keseluruhan analitik adalah untuk menyediakan akses mudah untuk perniagaan membuat keputusan. Walau apa pun, pengguna perniagaan bekerja dengan lebih cekap dengan gudang data berbanding tasik data, contohnya di Amazon - terdapat Redshift (gudang data analisis) dan terdapat Redshift Spectrum/Athena (antara muka SQL untuk tasik data dalam S3 berdasarkan Hive/Presto). Perkara yang sama berlaku untuk gudang data analisis moden yang lain.
Mari kita lihat seni bina gudang data biasa:
Ini adalah penyelesaian klasik. Kami mempunyai sistem sumber, menggunakan ETL/ELT kami menyalin data ke dalam gudang data analitikal dan menyambungkannya kepada penyelesaian Perisikan Perniagaan (kegemaran saya ialah Tableau, bagaimana pula dengan anda?).
Penyelesaian ini mempunyai kelemahan berikut:
- Operasi ETL/ELT memerlukan masa dan sumber.
- Sebagai peraturan, memori untuk menyimpan data dalam gudang data analisis tidak murah (contohnya, Redshift, BigQuery, Teradata), kerana kita perlu membeli keseluruhan kluster.
- Pengguna perniagaan mempunyai akses kepada data yang dibersihkan dan sering diagregatkan serta tidak mempunyai akses kepada data mentah.
Sudah tentu, semuanya bergantung pada kes anda. Jika anda tidak mempunyai masalah dengan gudang data anda, maka anda tidak memerlukan tasik data sama sekali. Tetapi apabila masalah timbul dengan kekurangan ruang, kuasa atau harga memainkan peranan penting, maka anda boleh mempertimbangkan pilihan tasik data. Inilah sebabnya mengapa tasik data sangat popular. Berikut ialah contoh seni bina tasik data:
Menggunakan pendekatan tasik data, kami memuatkan data mentah ke dalam tasik data kami (kelompok atau penstriman), kemudian kami memproses data seperti yang diperlukan. Tasik data membolehkan pengguna perniagaan membuat transformasi data mereka sendiri (ETL/ELT) atau menganalisis data dalam penyelesaian Perisikan Perniagaan (jika pemacu yang diperlukan tersedia).
Matlamat sebarang penyelesaian analitik adalah untuk memberi perkhidmatan kepada pengguna perniagaan. Oleh itu, kita mesti sentiasa bekerja mengikut keperluan perniagaan. (Di Amazon ini adalah salah satu prinsip - bekerja ke belakang).
Bekerja dengan kedua-dua gudang data dan tasik data, kami boleh membandingkan kedua-dua penyelesaian:
Kesimpulan utama yang boleh dibuat ialah gudang data tidak bersaing dengan tasik data, sebaliknya melengkapinya. Tetapi terpulang kepada anda untuk memutuskan perkara yang sesuai untuk kes anda. Ia sentiasa menarik untuk mencuba sendiri dan membuat kesimpulan yang betul.
Saya juga ingin memberitahu anda salah satu kes apabila saya mula menggunakan pendekatan data lake. Segala-galanya agak remeh, saya cuba menggunakan alat ELT (kami mempunyai Matillion ETL) dan Amazon Redshift, penyelesaian saya berjaya, tetapi tidak memenuhi keperluan.
Saya perlu mengambil log web, mengubahnya dan mengagregatkannya untuk menyediakan data untuk 2 kes:
- Pasukan pemasaran ingin menganalisis aktiviti bot untuk SEO
- IT mahu melihat metrik prestasi tapak web
Log yang sangat mudah, sangat mudah. Berikut ialah contoh:
https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"Satu fail mempunyai berat 1-4 megabait.
Tetapi ada satu kesukaran. Kami mempunyai 7 domain di seluruh dunia, dan 7000 ribu fail telah dibuat dalam satu hari. Ini bukan lebih banyak volum, hanya 50 gigabait. Tetapi saiz kelompok Redshift kami juga kecil (4 nod). Memuatkan satu fail dengan cara tradisional mengambil masa kira-kira seminit. Iaitu, masalah itu tidak diselesaikan secara langsung. Dan ini berlaku apabila saya memutuskan untuk menggunakan pendekatan tasik data. Penyelesaiannya kelihatan seperti ini:
Ia agak mudah (saya ingin ambil perhatian bahawa kelebihan bekerja di awan adalah kesederhanaan). Sudah biasa:
- AWS Elastic Map Reduce (Hadoop) untuk Kuasa Pengiraan
- AWS S3 sebagai storan fail dengan keupayaan untuk menyulitkan data dan mengehadkan akses
- Spark sebagai kuasa pengkomputeran InMemory dan PySpark untuk logik dan transformasi data
- Parket akibat Spark
- AWS Glue Crawler sebagai pengumpul metadata tentang data dan sekatan baharu
- Redshift Spectrum sebagai antara muka SQL kepada tasik data untuk pengguna Redshift sedia ada
Kelompok EMR+Spark terkecil memproses keseluruhan timbunan fail dalam masa 30 minit. Terdapat kes lain untuk AWS, terutamanya banyak yang berkaitan dengan Alexa, di mana terdapat banyak data.
Baru-baru ini saya mengetahui salah satu kelemahan tasik data ialah GDPR. Masalahnya ialah apabila pelanggan meminta untuk memadamnya dan data berada dalam salah satu fail, kami tidak boleh menggunakan Bahasa Manipulasi Data dan operasi DELETE seperti dalam pangkalan data.
Saya harap artikel ini telah menjelaskan perbezaan antara gudang data dan tasik data. Jika anda berminat, saya boleh menterjemah lebih banyak artikel atau artikel profesional yang saya baca. Dan juga beritahu tentang penyelesaian yang saya bekerjasama dan seni binanya.
Sumber: www.habr.com