XNUMX-р сарын эхээр би маш том алдаа гаргаж, хөгжүүлэгчийн хувьд амьдралдаа эргэлт хийж, компани доторх Data Engineering (DE) багт шилжсэн. Энэ нийтлэлд би DE-ийн багт хоёр сар ажиллахдаа хийсэн зарим ажиглалтаа хуваалцах болно.
Яагаад Data Engineering?
Миний DE-д хийх аялал 2019 оны зун эхэлсэн руу явцгаая , тэгээд би гэгээрэлд хүрсэн. Би энэ сэдвийг сонирхож, алгоритмуудыг судалж эхэлсэн , дараа нь хэрэглээний хамрах хүрээний талаар бодож, манай компанид практик хэрэглээ нь мэдээллийн санг тарааж байгааг хурдан олж мэдэв.
Манай баг яг юу хийдэг вэ? Бид бүх загварлаг охид, хөвгүүдийн нэгэн адил Data Driven Company болохыг хүсдэг. Үүнийг хэрэгжүүлэхийн тулд бид ядаж компанид шаардлагатай аливаа тайланг гаргахад ашиглаж болох найдвартай хадгалах байгууламж барих хэрэгтэй. Гэхдээ хамгийн чухал зүйл бол энэ хадгалалтын өгөгдөлд итгэлтэй байх ёстой. Түүнээс гадна эдгээр өгөгдлийг ашиглан та системийн төлөвийг t үед сэргээх боломжтой байх ёстой. Энэ бүхэн нь бид бичил үйлчилгээний эрэлхэг шинэ ертөнцөд амьдарч байгаа нь төвөгтэй бөгөөд энэ үзэл суртал нь үйлчилгээ бүр өөрийн гэсэн жижиг функцийг хэрэгжүүлдэг, мэдээллийн сан нь өөрийн гэсэн бизнес бөгөөд үүнийг ядаж өдөр бүр устгаж болно гэсэн үг юм. Үүний зэрэгцээ бид үйлчилгээний төлөвийг хүлээн авч, боловсруулах чадвартай байх ёстой.
Хэрэв та өгөгдөлд тулгуурлахыг хүсвэл эхлээд Үйл явдалд тулгуурлана
Тийм ч энгийн биш. Үйл явдлууд өөр өөр байдаг бөгөөд хөгжүүлэгчид болон мэдээллийн инженерүүд өөр өөрөөр хардаг. Үйл явдлын тухай ярих нь тусдаа нийтлэлийн сэдэв тул би энд орохгүй. Үүнээс гадна, ийм нийтлэл аль хэдийн байна Мартин Фаулер, би түүний амжилтыг хасахгүй, тэр ч бас алдартай болоосой.
Ер нь бодох юм их байгаа болохоор л энэ газар сонирхол татдаг. Манай компанид өгөгдлийн инженер гэдэг нь зөвхөн ETL/ELT дамжуулагчийг бичдэг хүнээс илүү өргөн хүрээний хариуцлагын хүрээ юм (хэрэв та эдгээр товчилсон үг нь юу гэсэн үг болохыг мэдэхгүй байгаа бол . Контекст сурталчилгааны хувьд).
Бид хадгалах архитектур, өгөгдлийн загварчлал, өгөгдлийн аюулгүй байдалтай холбоотой асуудлууд, дамжуулах хоолойнуудыг өөрсдөө шийддэг. Бид бас нэг талаас бүтээгдэхүүн хөгжүүлэгчдэд нэг их дарамт учруулахгүй, системд шинэ функцуудыг оруулахдаа тэд бидний шаардлагад аль болох бага анхаарал сарниулах ёстой гэдгийг анхаарах хэрэгтэй. Шинжээчид болон BI багт хадгалах өгөгдлийг хадгалахад тохиромжтой байдлаар хангах шаардлагатай. Бид ингэж л амьдарч байна.
Хөгжилөөс шилжихэд тулгардаг бэрхшээлүүд
Ажлын эхний өдөр би хэд хэдэн бэрхшээлтэй тулгарсан тул та бүхэнтэй хуваалцахыг хүсч байна.
1. Миний олж харсан хамгийн эхний зүйл бол тюлинг байхгүй, зарим дасгалууд байсан. Жишээлбэл, тестийн кодын хамрах хүрээг авч үзье. Бидэнд олон зуун туршилтын хүрээ бий. Өгөгдөлтэй ажиллахад бүх зүйл илүү төвөгтэй байдаг. Тийм ээ, бид туршилтын өгөгдөл дээр ETL дамжуулах хоолойг туршиж үзэх боломжтой, гэхдээ бид бүгдийг гараар хийж, тодорхой тохиолдол бүрийн шийдлийг хайх хэрэгтэй. Үүний үр дүнд тестийн хамрах хүрээ хамаагүй муу байна. Аз болоход, хяналт, бүртгэл хэлбэрээр санал хүсэлтийн өөр давхарга байдаг боловч энэ нь биднээс идэвхтэй байхаас илүүтэй хариу үйлдэл үзүүлэхийг аль хэдийн шаарддаг бөгөөд энэ нь уур бухимдлыг төрүүлж, бухимдуулж байна.
2. DE-ийн өнцгөөс харахад ертөнц жирийн бүтээгдэхүүн хөгжүүлэгчийн хувьд огт харагддаггүй (мэдээж уншигч тийм биш, тэр бүх зүйлийг аль хэдийн мэддэг, гэхдээ би мэдэхгүй байсан, одоо би эргэлзэж байна. дээшээ). Хөгжүүлэгчийн хувьд би өөрийн бичил үйлчилгээг бүтээж, өгөгдлийг [таны сонгосон мэдээллийн санд] оруулаад, тэнд миний төлөвийг хадгалаад, ID-аар нь ямар нэг зүйл авчихвал зүгээр. Үйлчилгээ удаан, захиалга нь будлиантай, тэгээд л болоо. Тэд надаас өөрийн мужийг өөр үйлчилгээнээс хайхыг хүссэн тул би RabbitMQ-д үйл явдал оруулах болно, тэгээд л болоо. Энд бид дээр дурдсан үйл явдлын асуудал руу дахин орлоо.
Үйл ажиллагааны ажилд ямар үйлчилгээ шаардлагатай байгаа нь түүхэн өгөгдөлд тохирохгүй байгаа тул үйлчилгээний гэрээг дахин боловсруулж, хөгжүүлэлтийн багуудтай нягт хамтран ажиллах асуудал эхэлдэг. Биднийг хүлээн зөвшөөрөхөд хэдэн цаг зарцуулсныг та төсөөлж ч чадахгүй: Тэр манай компанид ямар төрлийн үйл явдалд хөтлөгддөг вэ.
3. Толгойгоо бодох хэрэгтэй. Үгүй ээ, би хөгжүүлэгчид боддоггүй (хэдийгээр би хүн болгоны төлөө ярих ёстой юм бэ) гэсэн үг биш л дээ, энэ нь зөвхөн бүтээгдэхүүн боловсруулах явцад та аль хэдийн ямар нэгэн архитектуртай байдаг бөгөөд та хоцрогдсон байдлаасаа өөр өөр холилдсон зүйлсийг хасдаг гэсэн үг юм. Мэдээжийн хэрэг, энэ нь төлөвлөлт, бодохыг шаарддаг, гэхдээ энэ бол урсгал ажил бөгөөд гол асуудал бол үүнийг сайн, үр дүнтэй хийх явдал юм.
Бидний хувьд энэ нь тийм ч хялбар биш, учир нь янз бүрийн системийн бүрэлдэхүүн хэсгүүдийг дулаахан, тухтай цул хэсгээс зэрлэг бичил үйлчилгээний ширэнгэн ойд шилжүүлэх нь тийм ч хялбар биш юм. Үйлчилгээ нь үйл явдлуудыг цацаж эхлэх үед өгөгдөл нь одоо өөр харагдаж байгаа тул хадгалах санг дүүргэх логикийг дахин авч үзэх хэрэгтэй. Энд та хөгжүүлэгчийн хувьд биш, харин мэдээллийн инженерийн хувьд маш их, сайтар бодох хэрэгтэй. Тэмдэглэлийн дэвтэр, үзэг эсвэл самбар дээр тэмдэглэгээтэй өдрүүдийг өнгөрөөх нь ердийн түүх юм. Энэ нь маш хэцүү, би бодох дургүй, би бас продакшндаа дуртай.
4. Магадгүй хамгийн чухал зүйл бол мэдээлэл байх. Бид мэдлэг дутмаг үедээ юу хийдэг вэ? Stackoverflow гэж хэн хэлсэн бэ? Энэ хүнийг өрөөнөөс гарга. Бид энэ сэдвээр бичиг баримт, ном уншдаг, форум, уулзалт, хурал зохион байгуулдаг нийгэмлэг байдаг. Баримтжуулалт нь маш сайн, гэхдээ харамсалтай нь энэ нь бүрэн бус байж болно. Бид Cosmos DB-г хэд хэдэн төсөлд ашигладаг. Энэ бүтээгдэхүүний баримт бичгийг уншихад амжилт хүсье. Ном бол цорын ганц аврал, аз болоход тэдгээр нь байдаг бөгөөд олддог, тэдгээр нь маш их суурь мэдлэгийг агуулдаг бөгөөд та маш их, байнга уншиж байх ёстой. Гэхдээ асуудал нь нийгэмд байна.
Одоо манай нутагт дор хаяж нэг хангалттай хурал, уулзалт олоход хэцүү байна. Үгүй ээ, мэдээжийн хэрэг, Data гэдэг үгтэй олон уулзалт байдаг, гэхдээ энэ үгийн хажууд ихэвчлэн ML эсвэл AI гэх мэт хачирхалтай товчлолууд байдаг. Тиймээс, энэ нь бидэнд зориулагдаагүй, бид агуулахыг хэрхэн яаж барих тухай ярьж байгаа болохоос өөрсдийгөө нейроноор хэрхэн түрхэх тухай биш юм. Эдгээр хипстерүүд бүх зүйлийг булаан авсан. Үүний үр дүнд бид нийгэмгүй болж байна. Дашрамд хэлэхэд, хэрэв та дата инженер бөгөөд сайн нийгэмлэгүүдийг мэддэг бол сэтгэгдэл дээр бичээрэй.
Уулзалтын талаарх дүгнэлт, зарлал
Бид юугаар төгсөх вэ? Миний анхны туршлага надад дата инженерийн оронд байх нь хөгжүүлэгч бүрт ашигтай байх болно гэдгийг хэлж байна. Энэ нь зүгээр л бидэнд юмсыг өөрөөр харах боломжийг олгодог бөгөөд хөгжүүлэгчид өөрсдийн өгөгдөлд хэрхэн ханддагийг хараад бидний нүд цус харвах үед гайхах хэрэггүй. Тиймээс, хэрэв танай компанид DE байдаг бол эдгээр залуустай ярилц, та маш олон шинэ зүйлийг (өөрийнхөө тухай) сурах болно.
Тэгээд эцэст нь мэдэгдэл. Өдрийн турш бидний сэдвээр уулзалт олоход хэцүү байдаг тул бид өөрсдөө хийхээр шийдсэн. Бид яагаад улам дорддог вэ? Азаар бидэнд гайхалтай зүйл бий болон манай найзууд Бидэнтэй адил мэдээллийн инженерүүдийн анхаарлыг шударга бусаар алдсан гэж үздэг.
Энэ завшааныг ашиглан 27.02.2020 оны XNUMX-р сарын XNUMX-ны өдөр Додо Пиццаны оффис дээр болох "DE or DIE" нэртэй олон нийтийн анхны уулзалтанд оролцохыг би сонирхсон бүх хүмүүсийг урьж байна. Дэлгэрэнгүйг хаягаар авна уу .
Хэрэв ямар нэг зүйл тохиолдвол би тэнд байх болно, та хөгжүүлэгчидтэй холбоотой буруу зүйлээ миний нүүрэн дээр хэлж болно.
Эх сурвалж: www.habr.com