DataLakes & DataWarehouses: Bagaimana mereka digunakan dalam SEO
Diterbitkan: 2021-02-16Meskipun konsep DataWarehouses dan DataLakes menjadi bagian dari bahasa sehari-hari Analis Data dan Ilmuwan Data sejak lama, kami baru mendengarnya di industri lain selama beberapa tahun terakhir.
Misalnya, Analis Web dan Pakar SEO mulai memperhatikan konsep ini dengan serius, karena sifat pekerjaan mereka dan hubungan kuat yang ada antara apa yang mereka lakukan dan manipulasi data. Banyak artikel baru-baru ini berbicara tentang minat menerapkan SEO DataLake atau SEO DataWarehouse, memperlakukan kedua istilah tersebut sebagai dapat dipertukarkan dan tanpa membuat perbedaan di antara keduanya.
Pada artikel ini, kami akan memandu Anda dalam menentukan perbedaan antara DataLakes dan DataWarehouses untuk memahami tujuan dan kasus penggunaannya dalam SEO dan analisis web.
DataWarehouse: gudang terstruktur untuk data
Penggunaan pertama dari istilah "DataWarehouse" tanggal kembali ke 1988 dalam sebuah makalah oleh Paul Murphy dan Barry Delvin, Sebuah arsitektur untuk bisnis dan sistem informasi . Artikel ini memberi kita definisi pertama dari konsep sebagai lingkungan database relasional yang mudah diakses, menyatukan semua data bisnis yang berguna untuk pengambilan keputusan strategis.
Apa isi DataWarehouse?
DataWarehouse digunakan untuk mengumpulkan data bisnis yang berguna untuk pengambilan keputusan strategis bagi perusahaan di satu tempat. Kita berbicara tentang data bisnis yang dapat mencakup apa saja mulai dari data pelanggan, hingga informasi inventaris, hingga konversi di situs web komersial atau kunjungan organik (dari mesin telusur seperti Google misalnya).
Secara umum diterima bahwa data yang dikirim ke DataWarehouse terstruktur, data pra-proses yang digunakan untuk membongkar basis data operasional, yang pada akhirnya memungkinkan basis data operasional ini diminta sesedikit mungkin untuk tujuan kueri.
Tujuan utama dari DataWarehouse dan mereka yang mengelolanya adalah untuk mengkompilasi data dari berbagai sumber yang heterogen (baik internal maupun eksternal) untuk menstandarkannya sehingga berbagai sumber dapat berkomunikasi satu sama lain. Tujuan akhirnya adalah menggunakan data ini untuk melakukan analisis, pelaporan, dukungan pengambilan keputusan, dll.
Siapa pengguna harian DataWarehouse?
Karena sifat DataWarehouse dan format serta tipe data yang dikandungnya, ini adalah taman bermain yang ideal untuk Analis Data dan Web.
Analis Data bekerja bersama administrator DataWarehouse (atau tim administrasi). Mereka mendefinisikan kebutuhan bisnis dan kasus penggunaan. Mereka mengidentifikasi sumber data dan tindakan yang diperlukan untuk memproses data di hulu. Data ini kemudian akan digunakan oleh Analis Data di akhir rantai.
Bagaimana pengguna berkomunikasi dengan DataWarehouse?
Setelah sumber data diidentifikasi, dan data diproses, diserap, dan ditautkan di DataWarehouse, Analis Data dapat menggunakan data ini dalam analisis dan untuk membuat kombinasi data baru. Proses ini dapat digunakan untuk memelihara dasbor pelaporan, dasbor peringatan, dll.
Bahasa pemrograman yang paling umum digunakan untuk kueri di DataWarehouse adalah SQL (atau bahasa mirip SQL). SQL memungkinkan Analis Data untuk memanipulasi dan memproses data untuk memenuhi kebutuhan bisnis: pemantauan, pengambilan keputusan strategis, dll.
Kasus penggunaan dan jenis proyek apa yang dilayani DataWarehouses?
Tidak mungkin untuk menyusun daftar lengkap kasus penggunaan yang melibatkan penggunaan DataWarehouse. Namun, berikut adalah beberapa contoh proyek tempat Analis Data kemungkinan akan bekerja:
Peningkatan DataWarehouse:
Jenis proyek ini sering ditemui saat menyiapkan DataWarehouse, tetapi juga saat kebutuhan baru atau kasus penggunaan bisnis diidentifikasi.
Ini adalah pertanyaan di sini untuk menambahkan data baru ke DWH (sekali lagi, ini bisa berupa data internal atau eksternal).
Dalam hal ini kita sering berbicara tentang proses ETL (Extraction-Transformation-Loading):
- Ekstraksi:
Langkah pertama yang terdiri dari mengidentifikasi dan mengumpulkan data dari berbagai sumber yang diperlukan untuk operasi lebih lanjut. - Transformasi:
Langkah kedua ini sangat penting, karena tanpa penyesuaian, tanpa standarisasi, umumnya tidak mungkin menggunakan data baru dan membuat mereka berkomunikasi dengan yang sudah ada di DWH.
Oleh karena itu fase standardisasi yang diperlukan yang kadang-kadang dapat menjadi rumit oleh kekakuan yang dikenakan oleh DWH dalam hal format dan skema tabel. - Memuat:
Fase penyerapan data yang diproses (dan dengan demikian terstruktur) di DWH.
Realisasi analisis statistik:
Ini adalah penggunaan DWH yang sangat sering. Tujuannya mungkin untuk membuktikan X atau Y melalui data, untuk menghasilkan statistik berdasarkan data historis yang tersedia, atau untuk membangun hubungan sebab akibat untuk menjelaskan suatu temuan, dll.
Pelaporan & peringatan:
Ini, sekali lagi, kasus penggunaan yang sangat sering. Faktanya, karena data dalam DWH sangat terstruktur dan diformat (berbagi skema tetap dan standar), semuanya cocok untuk mendorong data ke dasbor pelaporan atau peringatan.
Ini adalah permintaan berulang dari manajemen puncak, yang harus dapat memantau tim operasional dan kesehatan hasil, penjualan, dll. dengan cara yang paling sederhana dan secepat mungkin.
Jika kami merangkum semua ini, kami memiliki kurang lebih 2 jenis proyek: proyek akuisisi dan integrasi data (yang juga dapat dibandingkan dengan bentuk penyimpanan dan historisasi data) dan proyek analisis dan evaluasi data (melalui pemantauan/dasbor dan peringatan ).
Konsep DWH telah hadir dalam bahasa sehari-hari mereka yang bekerja dengan data untuk waktu yang lama. Cara kerjanya dan banyak kasus penggunaannya telah lama dikonfirmasi, dan DWH dapat ditemukan di banyak perusahaan dengan berbagai kematangan di mana pertanyaan tentang manajemen data terkait.
Ini kurang berlaku untuk konsep DataLakes, yang jauh lebih muda dan kurang tersebar luas.
Data Perayapan³
DataLake: danau megadata (BigData)
Asal usul konsep ini dikaitkan dengan James Dixon, CTO Penthao, yang mendefinisikannya sebagai solusi untuk menyimpan dan mengeksploitasi data dalam jumlah besar, tanpa pra-pemrosesan dan tanpa harus menggunakan kasus penggunaan khusus… Tidak seperti DWH, yang sangat berorientasi menuju aktivasi segera.
DL mencoba mengisi celah, yang semakin penting dengan munculnya BigData, tentang apa yang harus dilakukan dengan semua kumpulan data yang dapat kami kumpulkan hari ini dan bagaimana memanfaatkannya.
Apa isi DataLake?
Saya akan mulai dengan mengutip James Dixon yang menggunakan perbandingan yang sangat menggugah, yang berfungsi baik sebagai penjelasan untuk nama "danau" dari konsepnya dan sebagai pembeda dengan DWH:
“Jika Anda menganggap datamart sebagai penyimpanan air kemasan – dibersihkan dan dikemas dan disusun untuk konsumsi yang mudah – data lake adalah kumpulan air yang besar dalam keadaan yang lebih alami. Isi aliran data danau dari sumber untuk mengisi danau, dan berbagai pengguna danau bisa datang untuk memeriksa, menyelam, atau mengambil sampel.”
Kutipan ini dengan sempurna menggambarkan perbedaan antara jenis data yang terkandung dalam DWH, yang terstruktur dan terorganisir dalam tabel dengan pola yang tepat dan tetap, dan jenis data yang terkandung dalam DataLake, yang mentah, tanpa pemrosesan sebelumnya, tersedia untuk diambil sampel dari sesuai kebutuhan, baik eksploratif atau tidak.
Di mana DWH dibatasi untuk mengakomodasi data terstruktur, DataLake dibuat untuk menyimpan semua jenis data mentah (terstruktur atau tidak). Perdebatan antara Tamara Dull (Amazon Web Service) dan Anne Buff (Microsoft SAS) memberi kita visi yang sedikit lebih konkret tentang konten DataLake:
“Data lake adalah repositori penyimpanan yang menyimpan sejumlah besar data mentah dalam format aslinya, termasuk data terstruktur, semi-terstruktur, dan tidak terstruktur. Struktur dan persyaratan data tidak ditentukan sampai data dibutuhkan.”
Siapa pengguna harian DataLakes?
Di mana Analis Data sangat cocok untuk bekerja dengan data terstruktur yang terkandung dalam DHW, data mentah justru merupakan spesialisasi Ilmuwan Data, yang seringkali lebih siap untuk memanipulasi jenis data ini.
Perubahan profil data dan pengguna utama ini juga menghasilkan bahasa pemrograman dan kasus penggunaan yang berbeda.
Kasus penggunaan dan jenis proyek apa yang dilayani DataLakes?
Karena sifatnya yang tidak terstruktur dan volume data yang cukup besar yang dapat ditampung oleh DataLake, kasus penggunaan bisa sangat berbeda dari yang sebelumnya ditemukan dalam kerangka kerja DWH, misalnya:
- Implementasi algoritme pembelajaran mesin untuk menciptakan nilai tambah bagi BigData:
Kami sering berbicara di sini tentang analisis prediktif, berdasarkan algoritme pembelajaran mesin yang mengeksploitasi semua jenis data.
Untuk mengambil contoh yang lebih konkrit, mari kita bayangkan sebuah perusahaan di sektor keuangan (perbankan & asuransi) ingin menentukan probabilitas bahwa transaksi keuangan X adalah penipuan. Ini mungkin membutuhkan Ilmuwan Data, yang mampu membuat algoritme pembelajaran mesin yang akan melatih jumlah astronomis data yang terkandung dalam DataLake (jumlah, tanggal, frekuensi, profil transaksi yang biasa dilakukan oleh pemilik akun, dll.). Tujuannya adalah untuk melakukan studi prediktif yang akan digunakan untuk mengidentifikasi transaksi yang berpotensi penipuan dan dengan demikian memungkinkan perusahaan untuk mengurangi waktu reaksinya dalam mendeteksi mereka dan pada akhirnya menghindari kerugian besar bagi mereka dan pelanggan mereka.
Ini adalah contoh sederhana yang sering digunakan untuk menggambarkan minat dan nilai tambah pembelajaran mesin, tetapi ada banyak contoh lainnya, seperti yang Anda bayangkan. - DataLakes sebagai sumber data untuk DataWarehouse:
Sangat sederhana, DataLake dapat bertindak sebagai zona transit antara berbagai sumber data internal dan eksternal Anda dan DWH Anda. Prinsip DataLake adalah memusatkan semua jenis data, terstruktur atau tidak terstruktur, untuk melakukan studi prediktif melalui ML, atau untuk ekstraksi sebagai sampel untuk analisis. Oleh karena itu, DWH tampaknya sangat cocok untuk kategori proyek kedua ini dan memanfaatkan DataLake sebagai sumber potensial (asalkan data DataLake diimpor secara terstruktur melalui pra-pemrosesan, jika perlu). - Dari DataLake hingga perangkat lunak BI (Business Intelligence):
Kita dapat melihat ini sebagai penggunaan yang mirip dengan yang kita lihat dengan DataWarehouses, berpikir ada kekhususan tertentu untuk menggunakan DataLake untuk tujuan ini. DataLake akan memungkinkan Anda membuat visualisasi yang sedikit lebih eksotis (karena keragaman data yang dikandungnya), melalui alat seperti Tableau, Qlikview, Google Data Studio, Microstrategy, dll.
Bagaimana cara pengguna berkomunikasi dengan DataLake?
Mengingat kasus penggunaan dan pengguna (Data Ilmuwan), kita akan sangat sering menemukan bahasa pemrograman seperti Python, Java, R, Scala, dll…
Sebagian besar, bahasa-bahasa ini telah hadir di bidang ilmu data untuk waktu yang lama.
Oleh karena itu, DataLake adalah alat untuk mengelola BigData. Ini bergantung pada penyimpanan data mentah yang besar untuk tujuan analisis dan visualisasi tingkat lanjut, sehingga memungkinkan peningkatan data yang sebelumnya tidak banyak digunakan.

Untuk meringkas, berikut adalah tabel elemen pembeda yang dibuat sejak awal artikel ini:
Gudang data | Danau Data | |
---|---|---|
Jenis data | Data terstruktur dan telah diproses sebelumnya, diatur dalam tabel dengan skema yang ditentukan | Data mentah, disimpan secara terstruktur atau tidak terstruktur |
Pengguna | Analis Data, Analis Web | Ilmuwan Data (terkadang Analis Data) |
volume data | Kecil besar (Tergantung pada kebutuhan dan kasus penggunaan) | Berpotensi sangat besar (Data besar) |
Bahasa pemrograman yang digunakan | SQL atau seperti SQL | Python, R, Java, Scala, antara lain |
Jenis proyek | Proyek analitik & statistik, Pelaporan, Peringatan, proyek tipe ELT (ekspor, transformasi, muat), beberapa analisis prediktif dan berbasis data | Analisis prediktif, pembelajaran mesin, zona transit antara sumber data dan DWH, visualisasi lanjutan – BI, analisis berbasis data |
Analisis prediktif, pembelajaran mesin, zona transit antara sumber data dan DWH, visualisasi lanjutan – BI, analisis berbasis data
Perbedaan inilah yang menjadikan kedua konsep tersebut sebagai alat yang saling melengkapi. Dalam banyak kasus, tergantung pada kematangan tata kelola perusahaan dan manajemen data, mereka mungkin mengandalkan kombinasi dari kedua alat ini.
DWH terutama digunakan untuk pelaporan dan analisis tradisional, sedangkan DataLake berfungsi sebagai sumber data sebelum mencapai potensi penuhnya saat perusahaan mendekati kedewasaan pada subjek data.
Menurut pendapat saya, DataLakes lebih merupakan respons terhadap masalah data baru abad ke-21, terutama dengan munculnya BigData dan meningkatnya kapasitas perusahaan untuk mengumpulkan data, daripada pengganti DWH, seperti yang mungkin dipikirkan beberapa orang.
Keduanya memiliki kelebihan, kekurangan, kelebihan dan kekurangan masing-masing. Cara terbaik untuk memanfaatkan keduanya adalah tetap menggunakan keduanya secara bersama-sama untuk dapat menghadapi segala kemungkinan dan untuk mengatasi berbagai kebutuhan yang lebih luas.
Sekarang kami telah mendefinisikan konsep dengan jelas, kami akhirnya akan fokus pada penggunaan DataWarehouses dan DataLakes untuk pemasaran dan lebih khusus untuk SEO (bahkan jika dalam banyak kasus, apa yang benar untuk yang pertama akan berlaku untuk yang terakhir, dan sebaliknya. sebaliknya).
DataWarehouse dan DataLake SEO
Kami akan berbicara di sini tentang DataWarehouse atau DataLake (atau keduanya) di mana setidaknya sebagian dari data yang ada dapat digunakan untuk kasus penggunaan SEO.
Mengapa mengaitkan DataLakes dan DataWarehouses dengan Pemasaran dan SEO?
SEO (dan, lebih umum, pemasaran) telah mengambil giliran yang sangat mencolok terhadap data dalam beberapa tahun terakhir. Semakin banyak tugas memerlukan penggunaan berbagai sumber data:
- Data analitik (Google Analytics, AT internet, dll.)
- Data kinerja (Google Search Console, Analytics)
- Data log, “sumber” data yang sangat besar untuk beberapa situs, yang memerlukan frekuensi pembaruan tinggi dan kapasitas penyimpanan yang besar.
- Data penautan jaringan (Majestic, Ahrefs, Babbar)
- Data pemosisian (SEMRush, Monitorank, dll.)
- Data perayapan (OnCrawl, dll.)
- Terkadang data bisnis/industri juga
Ke daftar ini kita juga harus menambahkan penggunaan API alat seperti Search Console, Majestic, Google Analytics misalnya, yang secara alami mendorong kita ke jenis solusi yang dijelaskan sebelumnya di artikel ini.
Hubungan kuat antara SEO dan Data inilah yang mendorong semakin banyak Analis Web dan Pakar SEO untuk belajar tentang cara-cara baru untuk mengatur saluran data mereka.
Namun, pendorong transisi ini bukan hanya tentang potensi dan keterkaitan SEO dan Data. Banyak kasus penggunaan sehari-hari beresonansi dengan jenis proyek yang tercantum di atas untuk DWH dan DL.
Kasus penggunaan DataWarehouse SEO atau DataLake SEO.
Pertama-tama saya akan memulai dari pain point yang biasa ditemui oleh para SEO Experts sebelum menjelaskan bagaimana penggunaan DataLake atau DataWarehouse menjadi jawaban yang harus diperhatikan saat menyikapinya.
Di antara poin nyeri utama, berikut ini menonjol:
- Perkalian file Excel (kertas lepas dari dekade kami) dan salin-tempel terkait:
Bagi banyak SEO, ini masih merupakan norma, tetapi jujur saja, ini memakan waktu, membatasi, dan sangat kondusif bagi kesalahan manusia. Untuk ini, DataWarehouse adalah solusi sempurna. DataWarehouses tidak hanya memungkinkan semua KPI yang diperlukan untuk melakukan audit/analisis ini atau itu dikumpulkan dari berbagai sumber data yang tersedia, tetapi juga memungkinkan pemrosesan yang diperlukan untuk mencapai hasil yang diharapkan menjadi otomatis.
Saat DataWarehouse dibangun, semakin banyak kasus penggunaan yang diidentifikasi dan semakin banyak masalah yang diselesaikan, yang mengarah pada penghematan waktu yang semakin signifikan dari waktu ke waktu. - Batasan kapasitas (sebagai pengingat, Excel hanya dapat membuka seluruh file jika tidak melebihi 1.048.576 baris. Sepertinya banyak, tetapi sebenarnya tidak sebanyak itu dalam volume hari ini): Tidak ada kasus penggunaan khusus di sini, karena di umum, baik DataLakes dan DataWarehouses tidak mengalami batasan seperti ini. Keduanya menawarkan sarana untuk meminta data dalam jumlah besar untuk semua jenis kebutuhan. Untuk kasus khusus ini, penting untuk diingat bahwa, tergantung pada kebutuhan, satu atau yang lain akan memungkinkan Anda membebaskan diri dari batas kapasitas dan, pada akhirnya, mengatasi situasi ini dengan lebih mudah.
- Menanggapi kebutuhan akan histori data
Spoiler: salah satu kasus penggunaan dapat, misalnya, untuk menyimpan riwayat data dari Google Search Console di DataWarehouse SEO, daripada menyalin dan membuat halaman datanya di Google Spreadsheet setiap minggu untuk memelihara dasbor Data Studio.Dalam pendapat saya, kami memiliki salah satu kasus penggunaan paling umum di antara Pakar SEO, baik di agensi atau internal: historisasi data. Memang, banyak Analis SEO melihat data historis dan menarik kesimpulan darinya.
Contoh yang mungkin langsung terlintas di benak Anda adalah kasus Google Search Console. Itu hanya menyediakan akses ke 16 bulan sejarah hari ini (bahkan melalui API). Dan jika jaminan simpanan manual tetap memungkinkan melalui ekspor untuk ditempelkan ke Google Spreadsheet setiap minggu (atau metode tidak jelas lainnya), itu adalah pemborosan waktu yang cukup besar selain menyakitkan dan membosankan.
Itu hal yang baik karena ini adalah masalah yang relatif sederhana untuk diatasi dengan DataWarehouse. Yang harus Anda lakukan adalah menyiapkan koneksi otomatis ke Google Search Console API, menentukan berbagai kemungkinan pra-pemrosesan dan kombinasi data yang diperlukan untuk mendapatkan data dengan nilai tambah nyata, dan terakhir, mengotomatiskan panggilan API. - Keinginan untuk melakukan analisis lebih lanjut, untuk menggabungkan atau "menganalisis silang" data perayapan, data audiens, log, dll. dengan cara industri.
Karena keunggulan kompetitif kecil tidak ada salahnya. Deskripsi yang kami berikan tentang DataWarehouse dan DataLake berbicara sendiri di sini. Salah satu tujuan utama dari kedua alat tersebut adalah untuk membuka kemungkinan baru untuk analisis, melalui pengumpulan data dan analisis silang dan/atau pembelajaran mesin.
Untuk mengutip hanya satu contoh yang sangat representatif; penggunaan algoritma pembelajaran mesin seperti Random Forest atau XG-Boost untuk membuat prediksi peringkat di Google.
Sangat sederhana, idenya adalah untuk melatih algoritme pada sejumlah besar Google SERP (halaman hasil) dan semua metrik SEO yang dapat dipanen untuk SERP ini untuk menentukan, berdasarkan metrik yang sama, potensi peringkat dari URL yang diberikan (dan oleh karena itu, lebih khusus lagi, untuk menentukan metrik yang paling penting untuk diberi peringkat di sektor/tema tertentu).
→ Anda akan menemukan metodologi lengkap dalam artikel oleh Vincent Terrasi, Direktur Produk di Oncrawl, “Berhasil memprediksi peringkat Google di ujung tombak ilmu data” , 2018. - Keinginan untuk mengotomatiskan pelaporan sebanyak mungkin, untuk fokus pada tugas bernilai tambah tinggi. Sekali lagi, ini benar-benar termasuk dalam kasus penggunaan klasik DataWarehouse. Ini menawarkan kemungkinan untuk mengotomatisasi seluruh pemulihan dan pemrosesan berbagai sumber data, dan dengan sempurna mengatasi masalah ini. Setelah diatur, tabel akan secara otomatis dimasukkan ke dalam DWH dan dapat digunakan sebagai koneksi ke perangkat lunak BI untuk dasbor, baik untuk pemantauan, peringatan, dll. Tentu saja, otomatisasi tidak berhenti pada proyek pelaporan saja. Baik DWH dan DL dapat digunakan untuk banyak pengoptimalan SEO otomatis. Misalnya, pembaruan dinamis untuk blok tautan internal pada peringkat, anggaran perayapan, audiens SEO, dll. (semua data terdapat dalam DWH).
- Keinginan untuk mengakhiri sekali dan untuk semua masalah keamanan (kami tahu siapa yang melakukan apa dan di mana menemukannya) dan menghindari menghabiskan waktu untuk pemeliharaan. Kami mengakhiri di sini pada aspek yang lebih berorientasi pada proses daripada kasus penggunaan, secara tegas.
Baik DataLakes dan DataWarehouses menyiratkan penerapan proses tertentu yang dapat disajikan dengan cara yang disederhanakan berikut:- Titik awalnya adalah pengamatan yang dipecah menjadi pernyataan kebutuhan (tim bisnis / SEO – Analis Data).
- Kemudian, ini diubah menjadi spesifikasi yang lebih teknis yang memungkinkan tim yang mengelola alat untuk memahami apa yang perlu dilakukan dan bagaimana hal itu perlu dilakukan.
- Tim administrasi yang sama ini melaksanakan permintaan tersebut.
- Tim bisnis dan Analis Data menghasilkan kasus penggunaan prosedural untuk pekerjaan yang dilakukan.
- Ada proses yang sedang berlangsung di mana kedua ujung rantai (tim bisnis dan tim administrasi DataWarehouse atau DataLake) memastikan bahwa tidak ada perubahan dalam hal input dan output.
Ini terutama berlaku untuk DWH, yang akan menolak data apa pun yang bukan bagian dari struktur (skema yang telah ditentukan sebelumnya).
Sekali lagi, ini adalah daftar poin nyeri yang tidak lengkap dan kemungkinan kasus penggunaan untuk DataWarehouse – DataLake SEO. Batasan lebih banyak ditemui melalui kurangnya imajinasi mereka yang menggunakannya daripada alat itu sendiri.
Memilih DataWarehouse atau DataLake untuk penggunaan SEO Anda
Sebagai kesimpulan, bertentangan dengan apa yang mungkin sering Anda dengar atau baca, DataWarehouses dan DataLakes adalah struktur terpisah untuk penyimpanan dan pengumpulan data, dan tidak kompatibel. Tidak perlu memilih salah satu dari yang lain, justru sebaliknya. Keduanya memiliki kasus penggunaan yang berbeda dan bahkan ada beberapa adhesi.
Kasus SEO adalah contoh jitu, dan memperkuat kebutuhan akan DataWarehouses dan DataLakes secara umum. Data ada di mana-mana dalam SEO: kita harus memanipulasi sejumlah besar data dari berbagai sumber. Jadi tidak mengherankan jika kita berbicara tentang DataWarehouses dan DataLakes dalam konteks ini. Kita dapat membayangkan banyak kasus penggunaan DataWarehouses atau DataLakes dalam SEO, apakah itu untuk tujuan otomatisasi, untuk melakukan analisis "ditambah" melalui data, atau hanya untuk memecahkan masalah yang berulang (titik nyeri).