Halo, Habr! Kami di Dodo Pizza Engineering sangat menyukai datanya (dan siapa yang tidak menyukainya sekarang?). Sekarang akan ada cerita tentang bagaimana cara mengakumulasi semua data dunia Dodo Pizza dan memberikan akses yang mudah bagi karyawan perusahaan ke array data ini. Tantangan di bawah tanda bintang: selamatkan saraf tim Rekayasa Data.
Seperti Plyushkins asli, kami menyimpan semua jenis informasi tentang karya pizza kami:
- ingat semua pesanan pengguna;
- kami tahu berapa banyak waktu yang diperlukan untuk membuat pizza pertama di Syktyvkar;
- Kami melihat berapa banyak waktu pizza mendingin di rak panas di Voronezh sekarang;
- menyimpan data pada penghapusan produk;
- dan masih banyak lagi.
Beberapa tim saat ini bertanggung jawab untuk bekerja dengan data di Dodo Pizza, salah satunya adalah tim Teknik Data. Sekarang mereka (yaitu, kami) memiliki tugas: untuk memberi karyawan mana pun akses mudah ke array data ini.
Ketika kami mulai berpikir tentang bagaimana melakukan ini dan mulai membahas masalah, kami menemukan pendekatan yang sangat menarik untuk manajemen data - Data Mesh (Anda akan menemukan artikel yang sangat bagus di sini). Ide-idenya jatuh pada ide kami tentang bagaimana kami ingin membangun sistem kami. Sisa artikel ini akan menjadi pemikiran ulang kami tentang pendekatan dan bagaimana kita melihatnya diimplementasikan dalam Dodo Pizza Engineering.
Apa yang kami maksud dengan "data"
Untuk memulai, mari putuskan apa yang kami maksud dengan data di Dodo Pizza Engineering:
- Acara yang mengirim layanan (kami memiliki bus umum yang dibangun menggunakan RabbitMQ);
- Catatan di dalam basis data (bagi kami, ini adalah MySQL dan CosmosDB);
- Clickstream dari aplikasi seluler dan situs web.
Agar bisnis Dodo Pizza menggunakan dan mengandalkan data ini, penting agar kondisi berikut dipenuhi:
- Mereka harus holistik. Kita harus yakin bahwa kita tidak mengubah data dalam proses pemrosesan, penyimpanan, dan tampilan mereka. Jika bisnis tidak dapat mempercayai data kami, maka itu tidak akan ada gunanya.
- Mereka harus cap waktu dan tidak ditimpa. Ini berarti bahwa setiap saat dalam waktu kita ingin dapat memutar kembali dan melihat data periode waktu itu. Misalnya, cari tahu berapa banyak pizza yang terjual pada 8 Juli 2018.
- Mereka harus dapat diandalkan. Dalam proses mengumpulkan dan menyimpan data, kita tidak hanya harus kehilangan integritas, tetapi juga keandalan. Kami tidak dapat kehilangan data, potongan waktu, karena bersama dengan mereka, kami kehilangan kepercayaan pelanggan kami (baik eksternal maupun internal).
- Mereka harus dengan skema stabil - kami menulis permintaan untuk data ini. Kami benar-benar tidak ingin mereka berubah banyak dengan mengubah kode aplikasi, dengan refactoring, sehingga permintaan kami berhenti berfungsi. Orang yang menulis permintaan tidak akan pernah tahu bahwa Anda melakukan refactoring sampai semuanya rusak. Saya tidak ingin tahu tentang hal ini dari pelanggan.
Mengingat semua persyaratan ini, kami sampai pada kesimpulan bahwa data dalam Dodo adalah produk. Sama seperti API layanan publik. Dengan demikian, tim yang sama yang memiliki layanan harus memiliki data. Juga, perubahan skema data harus selalu kompatibel ke belakang.
Pendekatan Tradisional - Danau Data
Untuk memecahkan masalah penyimpanan yang andal dan pemrosesan data besar, ada pendekatan tradisional yang diadopsi oleh banyak perusahaan yang bekerja dengan kumpulan informasi seperti itu - Data Lake. Dalam kerangka pendekatan ini, para insinyur data mengumpulkan informasi dari semua komponen sistem dan menempatkannya dalam satu penyimpanan besar (ini bisa, misalnya, Hadoop, Azure Kusto, Apache Cassandra atau bahkan replika MySQL, jika datanya dimasukkan ke dalamnya).
Lebih lanjut, para insinyur yang sama ini menulis permintaan ke penyimpanan tersebut. Menerapkan pendekatan ini di Dodo Pizza Engineering menyiratkan bahwa tim Teknik Data akan memiliki skema data dalam repositori analitik.
Dengan skenario ini, tim menjadi kucing yang sangat sedih dan itulah sebabnya:
- Dia harus memantau perubahan dalam SEMUA layanan di dalam perusahaan. Dan ada banyak dari mereka dan ada banyak perubahan (rata-rata kami menggabungkan ~ 100 permintaan tarik per minggu, sementara banyak layanan tidak melakukan permintaan tarik sama sekali).
- Saat mengubah skema data, manajer produk dan tim yang mengubah skema data harus menunggu sampai Rekayasa Data menyelesaikan kode yang diperlukan agar perubahan dapat didukung. Selain itu, kami telah lama ditampilkan dan situasi di mana satu tim sedang menunggu yang lain sangat jarang. Dan kami tidak ingin ini menjadi bagian "normal" dari proses pengembangan.
- Dia harus tenggelam dalam seluruh bisnis perusahaan. Sebuah rantai pizza terlihat seperti bisnis sederhana, tetapi sepertinya begitu. Sangat sulit untuk mengumpulkan kompetensi yang cukup dalam satu tim untuk membangun model data yang memadai untuk seluruh perusahaan.
- Ini adalah satu titik kegagalan. Setiap kali Anda perlu mengubah data yang dikembalikan layanan atau menulis kueri, semua tugas ini jatuh ke tim Rekayasa Data. Akibatnya, tim memiliki kelebihan simpanan.
Ternyata tim berada di persimpangan sejumlah besar kebutuhan dan tidak mungkin dapat memuaskan mereka. Pada saat yang sama, tekanan dan stres akan konstan. Kami benar-benar tidak menginginkan ini. Oleh karena itu, Anda harus memikirkan cara menyelesaikan masalah ini dan pada saat yang sama mendapatkan kesempatan untuk menganalisis data.
Mengalir dari Danau Data ke Data Mesh
Untungnya, tidak hanya kami bertanya pada diri sendiri pertanyaan ini. Bahkan, masalah serupa telah dipecahkan di industri (haleluya!). Hanya di area lain: penerapan aplikasi. Ya, saya sedang berbicara tentang pendekatan DevOps, di mana tim menentukan cara menggunakan produk yang mereka buat.
Pendekatan serupa untuk pemecahan masalah Data Lake disarankan oleh Zhamak Dehghani, konsultan ThoughtWorks. Menonton Netflix dan Spotify memecahkan masalah seperti itu, dia menulis artikel yang luar biasa tentang Cara Bergerak Melampaui Danau Data Monolitik ke Jala Data Terdistribusi (tautannya ada di awal artikel). Gagasan utama yang kami ambil untuk diri kami sendiri:
- Bagilah Danau Data yang besar menjadi domain data yang sangat mirip dengan domain desain yang digerakkan oleh domain. Setiap domain adalah konteks terbatas kecil.
- Tim Fitur, yang bertanggung jawab untuk domain DDD, juga bertanggung jawab untuk domain data yang sesuai. Mereka menyimpan sirkuit, mengubahnya, memuat data ke dalamnya. Pada saat yang sama, mereka sendiri tahu segalanya: bagaimana mengubah pemuatan data dan tidak merusak apa pun ketika aplikasi berubah. Pengetahuan tidak pergi ke mana pun. Untuk membuka data, mereka tidak perlu pergi ke mana pun. Tim itu sendiri melakukan siklus pengembangan penuh dari mengubah data operasional hingga menyediakan data analitis kepada pihak ketiga. Satu tim memiliki semua yang terkait dengan domain (domain bisnis dan domain data).
- Insinyur Data - Peran dalam Tim Fitur. Ini tidak harus seorang individu, tetapi sangat penting bahwa tim memiliki kompetensi ini.
Sementara itu, tim Rekayasa Data ...
Jika Anda membayangkan bahwa semua ini diwujudkan dengan satu klik jari, maka tetap menjawab dua pertanyaan:
Apa yang akan dilakukan tim Teknik Data sekarang? Dodo Pizza Engineering sudah memiliki tim platform / SRE. Tugasnya adalah memberikan alat pengembang untuk penyebaran layanan yang mudah. Tim Rekayasa Data akan melakukan peran yang sama hanya untuk data.
Mengubah data operasional menjadi data analitik adalah proses yang kompleks. Membuat analisis tersedia untuk seluruh perusahaan bahkan lebih sulit. Ini adalah solusi untuk masalah-masalah ini yang akan ditangani oleh tim Rekayasa Data.
Kami akan memberikan kepada Tim Fitur satu set alat dan praktik yang mudah digunakan untuk mempublikasikan data dari layanan mereka ke seluruh perusahaan. Kami juga akan bertanggung jawab untuk bagian infrastruktur umum dari pipa data (antrian, penyimpanan yang andal, cluster untuk melakukan transformasi pada data).
Bagaimana keterampilan Insinyur Data muncul di dalam Tim Fitur? Tim Fitur semakin sulit. Tentu saja, kami dapat mencoba mempekerjakan satu Insinyur Data di masing-masing tim kami. Tetapi ini sangat sulit. Menemukan seseorang dengan latar belakang yang baik dalam pengolahan data dan meyakinkan dia untuk bekerja di dalam tim grosir sulit.
Keuntungan besar dari Dodo adalah bahwa kita menyukai pembelajaran internal. Jadi sekarang rencana kami adalah ini: tim Rekayasa Data mulai mempublikasikan data beberapa layanan, tangisan, menusuk, tetapi terus memakan kaktus. Segera setelah kami memahami bahwa kami memiliki proses publikasi siap pakai, kami mulai membicarakannya di Tim Fitur.
Kami memiliki beberapa cara untuk melakukan ini:
- DevForum , di mana kami akan memberi tahu Anda seperti apa proses yang kami buat, alat apa yang ada di sana dan bagaimana cara menggunakannya secara efektif.
- Berbicara di DevForum akan membantu kami mengumpulkan umpan balik dari pengembang produk. Setelah itu, kami akan dapat bergabung dengan tim produk dan membantu mereka memecahkan masalah dengan publikasi data, mengatur pelatihan untuk tim.
Konsumsi data
Sekarang saya berbicara banyak tentang menerbitkan data. Tetapi ada juga konsumsi. Bagaimana dengan masalah ini?
Kami memiliki tim BI yang luar biasa yang menulis laporan yang sangat kompleks untuk perusahaan manajemen. Di dalam Dodo IS, ada banyak laporan untuk mitra kami yang membantu mereka mengelola pizza. Dalam model baru kami, kami menganggap mereka sebagai konsumen data yang memiliki domain data sendiri. Dan konsumenlah yang akan bertanggung jawab atas domain mereka sendiri. Terkadang domain konsumen dapat dijelaskan dengan satu permintaan ke repositori analitik - dan ini bagus. Tetapi kami memahami bahwa ini tidak akan selalu berhasil. Itu sebabnya kami ingin platform yang akan kami buat untuk tim produk yang akan digunakan oleh konsumen data juga (karena dalam kasus laporan di dalam Dodo IS, ini hanya akan menjadi tim).
Ini adalah bagaimana kami melihat bekerja dengan data di Dodo Pizza Engineering. Kami senang membaca pendapat Anda tentang ini di komentar.