در ابتدای دسامبر، من یک اشتباه مهلک مرتکب شدم و نقطه عطفی در زندگی خود به عنوان یک توسعه دهنده ایجاد کردم و به تیم مهندسی داده (DE) در شرکت نقل مکان کردم. در این مقاله من برخی از مشاهدات خود را در طول دو ماه کار در تیم DE به اشتراک خواهم گذاشت.
چرا مهندسی داده؟
سفر من به DE در تابستان 2019 آغاز شد، زمانی که ما برویم به و در آنجا به روشنگری دست یافتم. من شروع به علاقه مند شدن به موضوع، مطالعه الگوریتم ها و حتی در مورد آنها کردم ، و سپس در مورد دامنه کاربرد فکر کرد و به سرعت متوجه شد که کاربرد عملی در شرکت ما پایگاه های داده توزیع شده است.
تیم ما دقیقا چه کار می کند؟ ما، مانند همه پسران و دختران شیک پوش، می خواهیم به یک شرکت داده محور تبدیل شویم. و برای اینکه این امکان پذیر شود، حداقل باید یک مرکز ذخیره سازی قابل اعتماد بسازیم که بتوان از آن برای ساخت هر گزارشی که شرکت نیاز دارد استفاده کرد. اما مهمترین چیز این است که باید به داده های این ذخیره سازی اعتماد کرد. علاوه بر این، با استفاده از این داده ها، باید بتوانید وضعیت سیستم را در زمان t بازیابی کنید. همه اینها با این واقعیت پیچیده است که ما در دنیای جدید و شجاعی از میکروسرویس ها زندگی می کنیم، و این ایدئولوژی نشان می دهد که هر سرویس عملکرد کوچک خود را پیاده سازی می کند، پایگاه داده آن کسب و کار خودش است و می تواند حداقل هر روز آن را حذف کند، اما در در عین حال باید بتوانیم وضعیت سرویس را دریافت و پردازش کنیم.
اگر می خواهید داده محور باشید، ابتدا رویداد محور شوید
نه چندان ساده رویدادها متفاوت هستند و توسعه دهنده و مهندس داده متفاوت به آنها نگاه می کنند. صحبت در مورد رویدادها موضوعی برای یک مقاله جداگانه است، بنابراین من در اینجا به آن نمی پردازم. علاوه بر این، چنین مقاله ای قبلا یک مارتین فاولر خاص، من افتخاراتش را از بین نمی برم، بگذار او نیز مشهور شود.
به طور کلی جای فکر کردن زیاد است و به همین دلیل این منطقه جذاب است. اتفاقاً در شرکت ما، یک مهندس داده مسئولیت بسیار گسترده‌تری نسبت به شخصی دارد که خطوط لوله ETL/ELT را می‌نویسد (اگر نمی‌دانید این اختصارات به چه معنا هستند، بیایید به . به عنوان تبلیغات متنی).
ما با معماری ذخیره‌سازی، مدل‌سازی داده‌ها، مسائل مربوط به امنیت داده‌ها و خود خطوط لوله سروکار داریم. ما همچنین باید مطمئن شویم که از یک سو، حضور ما برای توسعه دهندگان محصول بسیار سنگین نیست و هنگام برش ویژگی های جدید در سیستم، باید تا حد امکان کمتر حواس آنها را به دلیل نیازهای ما پرت کنیم، و از طرف دیگر، ما نیاز به ارائه آنها به راحتی در داده های ذخیره سازی برای تحلیلگران و تیم BI است. اینطوری زندگی می کنیم.
مشکلات در هنگام گذار از توسعه
در اولین روز کارم با مشکلات زیادی روبرو شدم که می خواهم با شما در میان بگذارم.
1. اولین چیزی که دیدم نبودن تولینگ و چند تمرین بود. برای مثال پوشش کد با تست ها را در نظر بگیرید. ما صدها چارچوب آزمایشی در حال توسعه داریم. هنگام کار با داده ها، همه چیز پیچیده تر است. بله، ما می توانیم خطوط لوله ETL را روی داده های آزمایشی آزمایش کنیم، اما باید همه این کارها را به صورت دستی انجام دهیم و برای هر مورد خاص به دنبال راه حل باشیم. در نتیجه، پوشش تست بسیار بدتر است. خوشبختانه، لایه دیگری از بازخورد در قالب نظارت و گزارش وجود دارد، اما این از قبل ما را ملزم به واکنش واکنشی به جای فعالانه می‌کند، که خشمگین و آزاردهنده است.
2. دنیا از منظر DE اصلاً آن چیزی نیست که برای یک توسعه دهنده محصول معمولی به نظر می رسد (خب، البته خواننده اینطور نیست و او قبلاً همه چیز را می داند ، اما من نمی دانستم و اکنون دارم خراب می کنم. آن بالا). به عنوان یک توسعه‌دهنده، من میکروسرویس خود را ایجاد می‌کنم، داده‌ها را در [پایگاه داده انتخابی شما] قرار می‌دهم، وضعیت خود را در آنجا ذخیره می‌کنم، چیزی با شناسه دریافت می‌کنم و مشکلی نیست. خدمات کند است، سفارشات گیج کننده هستند، این همه است. آنها از من می خواهند که وضعیت خود را در سرویس دیگری جستجو کنم، بنابراین من یک رویداد را در RabbitMQ قرار می دهم و تمام. و در اینجا دوباره به موضوع وقایع شرح داده شده در بالا بازگشتیم.
آنچه سرویس برای کار عملیاتی نیاز دارد برای داده های تاریخی مناسب ما نیست، بنابراین مسئله بازنگری قراردادهای خدمات و کار نزدیک با تیم های توسعه آغاز می شود. حتی نمی توانید تصور کنید که چند ساعت طول کشید تا توافق کنیم: او در شرکت ما از چه نوع رویداد Driven است.
3. باید با سر خود فکر کنید. نه، منظور من این نیست که توسعه‌دهندگان فکر نمی‌کنند (اگرچه من کیستم که به جای همه صحبت کنم)، فقط این است که در توسعه محصول اغلب نوعی معماری دارید، و ترکیب‌های متفاوتی را از کارهای عقب افتاده حذف می‌کنید. البته این نیاز به برنامه ریزی و تفکر دارد، اما این کار جریانی است که مشکل اصلی صرفاً انجام خوب و کارآمد آن است.
برای ما، این کار چندان ساده نیست، زیرا انتقال اجزای مختلف سیستم از یک یکپارچه گرم و دنج به دنیای جنگل میکروسرویس وحشی، چندان ساده نیست. هنگامی که سرویس شروع به پخش رویدادها می کند، باید در منطق پر کردن فضای ذخیره سازی تجدید نظر کنید، زیرا داده ها اکنون متفاوت به نظر می رسند. اینجاست که شما باید خیلی و به طور کامل فکر کنید، نه دیگر به عنوان یک توسعه دهنده، بلکه به عنوان یک مهندس داده. وقتی روزها را با یک دفترچه و خودکار یا با یک نشانگر کنار تخته می گذرانید، یک داستان عادی است. خیلی سخت است، من دوست ندارم فکر کنم، من هم عاشق تولید هستم.
4. شاید مهمترین چیز اطلاعات باشد. وقتی دانش نداریم چه کنیم؟ کی گفته stackoverflow؟ این شخص را از اتاق بیرون ببرید. ما می‌رویم اسناد، کتاب‌هایی در این زمینه می‌خوانیم، و همچنین انجمنی وجود دارد که انجمن‌ها، جلسات و کنفرانس‌ها را سازماندهی می‌کند. مستندات عالی هستند، اما متاسفانه ممکن است ناقص باشند. ما از Cosmos DB در تعدادی از پروژه ها استفاده می کنیم. در خواندن مستندات این محصول موفق باشید. کتاب ها تنها راه نجات هستند؛ خوشبختانه وجود دارند و می توان آن ها را پیدا کرد، حاوی اطلاعات اساسی زیادی است و باید زیاد و مدام مطالعه کرد. اما مشکل در جامعه است.
اکنون یافتن حداقل یک کنفرانس یا نشست مناسب در منطقه ما دشوار است. نه، البته ملاقات های زیادی با کلمه Data وجود دارد، اما در کنار این کلمه معمولا اختصارات عجیبی مانند ML یا AI وجود دارد. بنابراین، این برای ما نیست، ما در مورد چگونگی ایجاد امکانات ذخیره سازی صحبت می کنیم، نه اینکه چگونه خود را با نورون ها آغشته کنیم. این هیپسترها همه چیز را تصاحب کرده اند. در نتیجه ما بدون جامعه هستیم. ضمناً، اگر مهندس داده هستید و جوامع خوبی را می شناسید، لطفاً در نظرات بنویسید.
نتیجه گیری و اطلاعیه جلسه
در نهایت به چه میرسیم؟ اولین تجربه من به من می گوید که احساس در کفش یک مهندس داده برای هر توسعه دهنده ای مفید خواهد بود. این فقط به ما این امکان را می دهد که به طور متفاوت به مسائل نگاه کنیم و وقتی می بینیم توسعه دهندگان چگونه با داده های خود رفتار می کنند، چشمانمان خونی می شود، تعجب نکنیم. بنابراین، اگر یک DE در شرکت شما وجود دارد، فقط با این افراد صحبت کنید، چیزهای جدید زیادی (در مورد خودتان) یاد خواهید گرفت.
و در نهایت اعلامیه. از آنجایی که یافتن جلساتی در مورد موضوع خود در طول روز دشوار است، تصمیم گرفتیم خودمان را بسازیم. چرا بدتر هستیم؟ خوشبختانه ما یک شگفت انگیز داریم و دوستان ما از ، که مانند ما احساس می کنند که مهندسان داده به طور ناعادلانه ای از توجه محروم هستند.
با استفاده از این فرصت، از همه کسانی که دوست دارند با عنوان امیدوارکننده "DE or DIE" که در 27.02.2020 فوریه XNUMX در دفتر پیتزا دودو برگزار می شود، به اولین جلسه انجمن ما بیایند. جزئیات در .
اگر اتفاقی بیفتد، من آنجا خواهم بود، می توانید شخصاً به من بگویید که چقدر در مورد توسعه دهندگان اشتباه می کنم.
منبع: www.habr.com