Vào đầu tháng XNUMX, tôi đã mắc một sai lầm chết người và tạo ra một bước ngoặt trong cuộc đời làm nhà phát triển khi chuyển sang nhóm Kỹ thuật dữ liệu (DE) trong công ty. Trong bài viết này, tôi sẽ chia sẻ một số quan sát mà tôi đã thực hiện trong hai tháng làm việc trong nhóm DE.
Tại sao lại là Kỹ thuật dữ liệu?
Hành trình đến DE của tôi bắt đầu vào mùa hè năm 2019, khi chúng tôi chúng ta hãy đi đến , và ở đó tôi đã đạt được giác ngộ. Tôi bắt đầu quan tâm đến chủ đề này, nghiên cứu các thuật toán và thậm chí cả về chúng , sau đó nghĩ về phạm vi ứng dụng và nhanh chóng phát hiện ra rằng ứng dụng thực tế trong công ty chúng tôi là cơ sở dữ liệu phân tán.
Chính xác thì nhóm của chúng tôi làm gì? Chúng tôi, giống như tất cả các chàng trai và cô gái thời trang, muốn trở thành Công ty dựa trên dữ liệu. Và để điều này trở thành hiện thực, ít nhất chúng ta cần xây dựng một cơ sở lưu trữ đáng tin cậy, có thể được sử dụng để xây dựng bất kỳ báo cáo nào mà công ty cần. Nhưng điều quan trọng nhất là dữ liệu trong kho lưu trữ này phải đáng tin cậy. Hơn nữa, sử dụng những dữ liệu này, bạn cần có khả năng khôi phục trạng thái của hệ thống tại thời điểm t. Tất cả điều này trở nên phức tạp bởi thực tế là chúng ta đang sống trong một thế giới vi dịch vụ mới đầy dũng cảm và hệ tư tưởng này ngụ ý rằng mỗi dịch vụ thực hiện chức năng nhỏ của riêng mình, cơ sở dữ liệu của nó là hoạt động kinh doanh riêng và nó có thể xóa nó ít nhất mỗi ngày, nhưng tại đồng thời chúng tôi phải có khả năng nhận và xử lý trạng thái của dịch vụ.
Nếu bạn muốn Theo hướng dữ liệu, trước tiên hãy trở thành Theo hướng sự kiện
Không đơn giản lắm. Các sự kiện là khác nhau và nhà phát triển cũng như kỹ sư dữ liệu sẽ xem xét chúng theo cách khác nhau. Nói về sự kiện là một chủ đề dành cho một bài viết riêng nên tôi sẽ không đi sâu vào đây. Ngoài ra, một bài viết như vậy đã một Martin Fowler nào đó, tôi sẽ không tước đi vòng nguyệt quế của anh ấy, hãy để anh ấy trở nên nổi tiếng.
Nói chung có rất nhiều điều để suy nghĩ và đó là lý do tại sao khu vực này lại hấp dẫn. Tình cờ là trong công ty của chúng tôi, Kỹ sư dữ liệu có phạm vi trách nhiệm rộng hơn nhiều so với việc chỉ là người viết đường dẫn ETL/ELT (nếu bạn không biết những từ viết tắt này nghĩa là gì, hãy đến với . Là quảng cáo theo ngữ cảnh).
Tất nhiên, chúng tôi xử lý kiến trúc lưu trữ, mô hình hóa dữ liệu, các vấn đề liên quan đến bảo mật dữ liệu và bản thân các đường dẫn. Chúng tôi cũng cần đảm bảo rằng, một mặt, sự hiện diện của chúng tôi không gây gánh nặng cho các nhà phát triển sản phẩm và họ phải ít bị phân tâm nhất có thể bởi các yêu cầu của chúng tôi khi đưa các tính năng mới vào hệ thống, mặt khác, chúng tôi cần cung cấp chúng được bố trí thuận tiện trong dữ liệu lưu trữ cho các nhà phân tích và nhóm BI. Đó là cách chúng ta sống.
Khó khăn khi chuyển từ phát triển
Ngày đầu tiên đi làm, tôi gặp phải một số khó khăn muốn chia sẻ với các bạn.
1. Điều đầu tiên tôi thấy là sự thiếu vắng tuling và một số phương pháp thực hành. Lấy ví dụ về phạm vi mã với các bài kiểm tra. Chúng tôi có hàng trăm khung thử nghiệm đang được phát triển. Khi làm việc với dữ liệu, mọi thứ phức tạp hơn. Có, chúng tôi có thể kiểm tra đường dẫn ETL trên dữ liệu thử nghiệm, nhưng chúng tôi phải thực hiện tất cả theo cách thủ công và tìm kiếm giải pháp cho từng trường hợp cụ thể. Kết quả là phạm vi kiểm tra kém hơn nhiều. May mắn thay, có một lớp phản hồi khác dưới dạng giám sát và ghi nhật ký, nhưng điều này đã đòi hỏi chúng ta phải phản ứng một cách phản ứng thay vì chủ động, điều này khiến chúng ta tức giận và lo lắng.
2. Thế giới từ góc độ DE hoàn toàn không giống như những gì một nhà phát triển sản phẩm bình thường nghĩ (à, tất nhiên là người đọc không như vậy, và anh ta đã biết mọi thứ, nhưng tôi không biết và bây giờ tôi đang làm hỏng việc nó lên). Với tư cách là một nhà phát triển, tôi tạo microservice của riêng mình, đưa dữ liệu vào [cơ sở dữ liệu bạn chọn], lưu trạng thái của mình ở đó, lấy thứ gì đó bằng ID và mọi thứ đều ổn. Dịch vụ chậm, đơn hàng khó hiểu, chỉ vậy thôi. Họ yêu cầu tôi tìm trạng thái của mình trong một dịch vụ khác, vì vậy tôi sẽ đưa một sự kiện vào một số RabbitMQ và thế là xong. Và ở đây chúng ta lại quay trở lại vấn đề các sự kiện được mô tả ở trên.
Những gì dịch vụ cần cho công việc vận hành không phù hợp với dữ liệu lịch sử của chúng tôi, vì vậy câu hỏi về việc làm lại hợp đồng dịch vụ và hợp tác chặt chẽ với các nhóm phát triển bắt đầu. Bạn thậm chí không thể tưởng tượng được chúng tôi đã mất bao nhiêu giờ để đồng ý: anh ấy thuộc loại Người thúc đẩy sự kiện nào trong công ty của chúng tôi.
3. Bạn cần suy nghĩ bằng cái đầu của mình. Không, ý tôi không phải là các nhà phát triển không nghĩ (mặc dù tôi là ai để nói thay cho mọi người), chỉ là trong quá trình phát triển sản phẩm, bạn thường đã có sẵn một số loại kiến trúc và bạn loại bỏ các xáo trộn khác nhau khỏi hồ sơ tồn đọng. Tất nhiên, điều này đòi hỏi phải lập kế hoạch và suy nghĩ, nhưng đây là công việc truyền phát, trong đó vấn đề chính chỉ đơn giản là thực hiện nó tốt và hiệu quả.
Đối với chúng tôi, điều đó không đơn giản như vậy vì việc chuyển các thành phần hệ thống khác nhau từ một khối nguyên khối ấm áp sang thế giới của khu rừng vi dịch vụ hoang dã không đơn giản như vậy. Khi dịch vụ bắt đầu gửi các sự kiện, bạn cần xem xét lại logic để lấp đầy bộ nhớ vì dữ liệu bây giờ trông khác. Đây là lúc bạn cần phải suy nghĩ rất nhiều và kỹ lưỡng, không còn với tư cách là một nhà phát triển mà với tư cách là một kỹ sư dữ liệu. Đó là một câu chuyện bình thường khi bạn dành nhiều ngày với cuốn sổ và cây bút hoặc với bút đánh dấu trên bảng. Khó lắm, tôi không thích nghĩ ngợi, tôi cũng thích sản xuất.
4. Có lẽ điều quan trọng nhất là thông tin. Chúng ta làm gì khi thiếu kiến thức? Ai đã nói stackoverflow? Đưa người này ra khỏi phòng. Chúng tôi đi đọc tài liệu, sách về chủ đề này và cũng có một cộng đồng tổ chức các diễn đàn, buổi gặp mặt và hội nghị. Tài liệu rất tuyệt, nhưng thật không may, nó có thể không đầy đủ. Chúng tôi sử dụng Cosmos DB trong một số dự án. Chúc may mắn đọc tài liệu cho sản phẩm này. Sách là sự cứu rỗi duy nhất, may mắn thay, chúng tồn tại và có thể tìm thấy, chúng chứa đựng rất nhiều kiến thức cơ bản và bạn phải đọc rất nhiều và liên tục. Nhưng vấn đề là ở cộng đồng.
Bây giờ thật khó để tìm thấy ít nhất một hội nghị hoặc buổi gặp mặt thích hợp trong khu vực của chúng tôi. Không, tất nhiên là có rất nhiều trường hợp gặp từ Data, nhưng bên cạnh từ này thường có những từ viết tắt lạ như ML hay AI. Vì vậy, điều này không dành cho chúng tôi, chúng tôi đang nói về cách xây dựng cơ sở lưu trữ chứ không phải cách tự bôi bẩn tế bào thần kinh. Những người hipster này đã tiếp quản mọi thứ. Kết quả là chúng ta không có cộng đồng. Nhân tiện, nếu bạn là Kỹ sư dữ liệu và biết các cộng đồng tốt, vui lòng viết bình luận.
Kết luận và thông báo cuộc họp
Cuối cùng chúng ta sẽ làm gì? Trải nghiệm đầu tiên của tôi cho tôi biết rằng cảm giác ở vị trí của một kỹ sư dữ liệu sẽ hữu ích cho mọi nhà phát triển. Nó chỉ cho phép chúng ta nhìn mọi thứ một cách khác và không ngạc nhiên khi mắt chúng ta đỏ ngầu khi thấy cách các nhà phát triển xử lý dữ liệu của họ. Vì vậy, nếu có DE trong công ty của bạn, chỉ cần nói chuyện với những người này, bạn sẽ học được rất nhiều điều mới (về bản thân).
Và cuối cùng là thông báo. Vì rất khó tìm được cuộc gặp gỡ về chủ đề của chúng tôi trong ngày nên chúng tôi đã quyết định tổ chức cuộc gặp gỡ của riêng mình. Tại sao chúng ta tệ hơn? May mắn thay chúng ta có một điều tuyệt vời và bạn bè của chúng tôi từ , những người cũng như chúng tôi, cảm thấy rằng các kỹ sư dữ liệu bị thiếu chú ý một cách bất công.
Nhân cơ hội này, tôi mời tất cả những ai quan tâm đến tham dự buổi gặp mặt cộng đồng đầu tiên của chúng tôi với chủ đề đầy hứa hẹn “DE or DIE”, sẽ diễn ra vào ngày 27.02.2020 tháng XNUMX năm XNUMX tại văn phòng Dodo Pizza. Chi tiết tại .
Nếu có chuyện gì xảy ra, tôi sẽ ở đó, bạn có thể nói thẳng với tôi rằng tôi đã sai lầm như thế nào về các nhà phát triển.
Nguồn: www.habr.com