Unpopular Opinion: Data Scientists Should be More End-to-End

eugeneyan

eugeneyan

Начни здесь Тексты Выступления Прототипирование Обо мне

Unpopular Opinion: Data Scientists Should be More End-to-End

Непопулярное мнение: Data Scientist'ы должны быть более end-to-end

[ datascience machinelearning leadership 🔥 ] · 17 min read

[ datascience machinelearning leadership 🔥 ] · 17 мин чтения

Recently, I came across a Reddit thread on the different roles in data science and machine learning: data scientist, decision scientist, product data scientist, data engineer, machine learning engineer, machine learning tooling engineer, AI architect, etc.

Недавно мне попался тред на Reddit о различных ролях в data science и machine learning: data scientist, decision scientist, product data scientist, data engineer, machine learning engineer, machine learning tooling engineer, AI architect и так далее.

I found this worrying. It’s difficult to be effective when the data science process (problem framing, data engineering, ML, deployment/maintenance) is split across different people. It leads to coordination overhead, diffusion of responsibility, and lack of a big picture view.

Я нахожу это тревожным. Сложно быть эффективным, когда процесс data science (постановка задачи, дата-инжиниринг, ML, развёртывание/поддержка) разнесён между разными людьми. Это ведёт к накладным расходам на координацию, размыванию ответственности и отсутствию общей картины.

IMHO, I believe data scientists can be more effective by being end-to-end. Here, I’ll discuss the benefits and counter-arguments, how to become end-to-end, and the experiences of Stitch Fix and Netflix.

IMHO, я считаю, что data scientist'ы могут быть эффективнее, работая end-to-end. Здесь я обсужу преимущества и контраргументы, как стать end-to-end, а также опыт Stitch Fix и Netflix.

From start (identify the problem) to finish (solve it)

От начала (поставить задачу) до конца (решить её)

You may have come across similar labels and definitions, such as:

Вам могли встречаться похожие ярлыки и определения, например:

Generalist: ориентация на роли (PM, BA, DE, DS, MLE); порой с негативной коннотацией. Full-stack: ориентация на технологии (Spark, Torch, Docker); термин популяризован full-stack разработчиками. Unicorn: ориентация на мифологию; считается, что таких не существует.

I find these definitions to be more prescriptive than I prefer. Instead, I have a simple (and pragmatic) definition: An end-to-end data scientist can identify and solve problems with data, to deliver value. To achieve the goal, they’ll wear as many (or as little) hats as required. They’ll also learn and apply whatever tech, methodology, and process that works. Throughout the process, they ask questions such as:

Мне кажется, эти определения слишком предписывающие. Я предпочитаю более простое (и прагматичное) определение: end-to-end data scientist умеет выявлять и решать задачи с помощью данных, принося ценность. Чтобы достичь цели, он наденет столько шляп, сколько потребуется. Он также освоит и применит любую технологию, методологию и процесс, которые работают. По ходу он задаёт вопросы вроде:

В чём задача? Почему она важна? Можем ли мы её решить? Как именно её решать? Какова ожидаемая ценность? Какова фактическая ценность?

Another way of defining end-to-end data science is via processes. These processes are usually complex and I’ve left them out of the main discussion. Nonetheless, here are a few in case you’re curious:

Ещё один способ определить end-to-end data science — через процессы. Они обычно сложные, и я вынес их за рамки основного обсуждения. Тем не менее, вот несколько, если вам любопытно:

CRISP-DM: Cross-Industry Standard Process for Data Mining (1997). KDD: Knowledge Discovery in Databases. TDSP: Team Data Science Process, предложенный Microsoft в 2018 году. DSLP: Data Science Lifecycle Process.

Don’t worry if these processes seem heavy and overwhelming. You don’t have to adopt them wholesale—start bit by bit, keep what works and adapt the rest.

Не переживайте, если эти процессы кажутся громоздкими и подавляющими. Не обязательно внедрять их целиком — начинайте по чуть-чуть, сохраняйте то, что работает, и адаптируйте остальное.

More context, faster iteration, greater satisfaction

Больше контекста, быстрее итерации, выше удовлетворённость

For most data science roles, being more end-to-end improves your ability to make meaningful impact. (Nonetheless, there are roles that focus on machine learning.)

Для большинства ролей в data science работа end-to-end повышает вашу способность приносить значимый impact. (Тем не менее, есть роли, сфокусированные на machine learning.)

Working end-to-end provides increased context. While specialized roles can increase efficiency, it reduces context (for the data scientist) and leads to suboptimal solutions.

Работа end-to-end даёт больше контекста. Специализированные роли могут повышать эффективность, но снижают контекст (для data scientist'а) и ведут к субоптимальным решениям.

The trick to forgetting the big picture is to look at everything close-up. – Chuck Palahniuk

Чтобы забыть общую картину, нужно рассматривать всё крупным планом. – Chuck Palahniuk

It’s hard to design a holistic solution without full context of the upstream problem. Let’s say conversion has decreased and a PM raises a request to improve our search algorithm. However, what’s causing the decrease in the first place? There could be various causes:

Трудно спроектировать целостное решение без полного понимания вышестоящей проблемы. Допустим, конверсия упала, и PM просит улучшить алгоритм поиска. Но что вообще вызвало это падение? Причины могут быть разные:

Товар: не снижает ли доверие покупателей мошеннический/некачественный товар? Дата-пайплайны: не пострадало ли качество данных, нет ли задержек/сбоев? Обновление модели: обновляется ли модель регулярно/корректно?

More often than not, the problem—and solution—lies outside of machine learning. A solution to improve the algorithm would miss the root cause.

Чаще всего и проблема, и решение лежат вне machine learning. Подход «улучшить алгоритм» прошёл бы мимо корневой причины.

Similarly, it’s risky to develop a solution without awareness of downstream engineering and product constraints. There’s no point:

Аналогично, рискованно разрабатывать решение, не учитывая нижестоящие инженерные и продуктовые ограничения. Нет смысла:

Строить near-real time рекомендатель, если инфраструктура и инженеры не могут его поддержать. Строить рекомендатель с бесконечной прокруткой, если он не вписывается в наш продукт и приложение.

By working end-to-end, data scientists will have the full context to identify the right problems and develop usable solutions. It can also lead to innovative ideas that specialists, with their narrow context, might miss. Overall, it increases the ability to deliver value.

Работая end-to-end, data scientist'ы получают полный контекст, чтобы выявлять правильные задачи и разрабатывать применимые решения. Это также может приводить к инновационным идеям, которые специалисты с их узким контекстом упустили бы. В целом это повышает способность приносить ценность.

Communication and coordination overhead is reduced. With multiple roles comes additional overhead. Let’s look at an example of a data engineer (DE) cleaning the data and creating features, a data scientist (DS) analysing the data and training the model, and a machine learning engineer (MLE) deploying and maintaining it.

Снижаются накладные расходы на коммуникацию и координацию. Чем больше ролей, тем больше overhead. Рассмотрим пример: data engineer (DE) очищает данные и создаёт фичи, data scientist (DS) анализирует данные и обучает модель, а machine learning engineer (MLE) её разворачивает и поддерживает.

What one programmer can do in one month, two programmers can do in two months. – Frederick P. Brooks

То, что один программист делает за месяц, двое сделают за два. – Frederick P. Brooks

The DE and DS need to communicate on what data is (and is not) available, how it should be cleaned (e.g., outliers, normalisation), and which features should be created. Similarly, the DS and MLE have to discuss how to deploy, monitor, and maintain the model, as well as how often it should be refreshed. When issues occur, we’ll need three people in the room (likely with a PM) to triage the root cause and next steps to fix it.

DE и DS должны договариваться о том, какие данные доступны (и недоступны), как их очищать (выбросы, нормализация) и какие фичи создавать. Аналогично DS и MLE обсуждают, как развёртывать, мониторить и поддерживать модель, как часто её переобучать. Когда возникают инциденты, в комнате (вероятно, с PM) понадобится трое, чтобы найти корневую причину и шаги по устранению.

It also leads to additional coordination, where schedules need to be aligned as work is executed and passed along in a sequential approach. If the DS wants to experiment with additional data and features, we’ll need to wait for the DE to ingest the data and create the features. If a new model is ready for A/B testing, we’ll need to wait for the MLE to (convert it to production code) and deploy it.

Это также порождает дополнительную координацию — расписания приходится синхронизировать, а работа передаётся по цепочке. Если DS хочет поэкспериментировать с новыми данными и фичами, придётся ждать, пока DE их загрузит и создаст. Если новая модель готова к A/B тесту, придётся ждать, пока MLE её (переписав в production-код) развернёт.

While the actual development work may take days, the communication back-and-forth and coordination can take weeks, if not longer. With end-to-end data scientists, we can minimize this overhead as well as prevent technical details from being lost in translation.

Сама разработка может занимать дни, но коммуникация туда-обратно и координация — недели, если не больше. С end-to-end data scientist'ами мы можем минимизировать этот overhead, а также избежать потери технических деталей в переводе.

(But, can an end-to-end DS really do all that? I think so. While the DS might not be as proficient in some tasks as a DE or MLE, they will be able to perform most tasks effectively. If they need help with scaling or hardening, they can always get help from specialist DEs and MLEs.)

(Но действительно ли один end-to-end DS способен на всё это? Думаю, да. Хотя DS может уступать DE или MLE в каких-то задачах, большинство он сможет выполнить эффективно. Если нужно масштабирование или закаливание решения, всегда можно подключить специализированных DE и MLE.)

Richard Hackman, a Harvard psychologist, showed that the number of relationships in a team is N(N-1) / 2, where N is the number of people. This leads to exponential growth in links, where:

Гарвардский психолог Ричард Хэкман показал, что число связей в команде равно N(N-1) / 2, где N — число людей. Это даёт экспоненциальный рост связей:

У стартап-команды из 7 человек — 21 связь. У группы из 21 человека (то есть трёх стартап-команд) — 210 связей. У группы из 63 человек — почти 2000 связей.

In our simple example, we only had three roles (i.e., six links). But as a PM, BA, and additional members are included, this leads to greater than linear growth in communication and coordination costs. Thus, while each additional member increases total team productivity, the increased overhead means productivity grows at a decreasing rate. (Amazon’s two-pizza teams are a possible solution to this.)

В нашем простом примере было всего три роли (то есть шесть связей). Но как только добавляются PM, BA и другие участники, коммуникационные и координационные издержки растут быстрее, чем линейно. Поэтому, хотя каждый новый участник увеличивает общую продуктивность команды, рост происходит с уменьшающимся темпом из-за накладных расходов. (Амазоновские two-pizza teams — возможное решение.)

Iteration and learning rate is increased. With greater context and lesser overhead, we can now iterate, fail (read: learn), and deliver value faster.

Растёт скорость итераций и обучения. Имея больше контекста и меньше overhead, мы можем быстрее итерировать, ошибаться (читай: учиться) и приносить ценность.

This is especially important for developing data and algorithmic products. Unlike software engineering (a far more mature craft), we can’t do all the learning and design before we start building—our blueprints, architectures, and design patterns are not as developed. Thus, rapid iteration is essential for the design-build-learn cycle.

Это особенно важно для разработки продуктов на данных и алгоритмах. В отличие от software engineering (куда более зрелого ремесла), мы не можем закончить всё обучение и проектирование до того, как начнём строить — наши чертежи, архитектуры и паттерны проектирования не настолько проработаны. Поэтому быстрая итерация критична для цикла design-build-learn.

There’s greater ownership and accountability. Having the data science process split across multiple people can lead to diffusion of responsibility, and worse, social loafing.

Больше ownership и ответственности. Когда процесс data science поделён между многими, возникает размывание ответственности и, что хуже, социальное безделье.

A common anti-pattern observed is “throw over the wall”. For example, the DE creates features and throws a database table to the DS, the DS trains a model and throws R code over to the MLE, and the MLE translates it to Java to production.

Распространённый анти-паттерн — «перебросить через стену». Например, DE создаёт фичи и перебрасывает таблицу базы данных DS'у, DS обучает модель и перебрасывает R-код MLE, а MLE переводит его в Java для продакшна.

If things get lost-in-translation or if results are unexpected, who is responsible? With a strong culture of ownership, everyone steps up to contribute in their respective roles. But without it, work can degenerate into ass-covering and finger-pointing while the issue persists and customers and the business suffers.

Если что-то теряется в переводе или результат не оправдывает ожиданий, кто отвечает? При сильной культуре ownership каждый берёт на себя свою часть. Без неё работа вырождается в прикрывание задниц и перекидывание стрелок, пока проблема остаётся, а страдают клиенты и бизнес.

Having the end-to-end data scientist take ownership and responsibility for the entire process can mitigate this. They should be empowered to take action from start to finish, from the customer problem and input (i.e., raw data) to the output (i.e., deployed model) and measurable outcomes.

Если end-to-end data scientist берёт на себя ownership и ответственность за весь процесс, это смягчает проблему. У него должны быть полномочия действовать от начала до конца: от клиентской задачи и входных данных (то есть сырых данных) до выхода (то есть развёрнутой модели) и измеримых результатов.

Diffusion of responsibility: We are less likely to take responsibility and act when there are others present. Individuals feel less responsibility and urgency to help if we know that there are others also watching the situation.

Размывание ответственности: мы реже берём на себя ответственность и действуем, когда рядом есть другие. Люди ощущают меньше ответственности и срочности помочь, если знают, что ещё кто-то наблюдает за ситуацией.

One form of this is the Bystander effect, where Kitty Genovese was stabbed outside the apartment building across the street from where she lived. While there were 38 witnesses who saw or heard the attack, none called the police or helped her.

Одна из его форм — эффект свидетеля: Kitty Genovese была убита возле дома напротив того, где она жила. Несмотря на 38 свидетелей, видевших или слышавших нападение, никто не вызвал полицию и не помог ей.

Social loafing: We exert less effort when we work in a group vs. working alone. In the 1890s, Ringelmann made people pull on ropes both separately and in groups. He measured how hard they pulled and found that members of a group tended to exert less effort in pulling a rope than did individuals alone.

Социальное безделье: мы прилагаем меньше усилий, работая в группе, чем в одиночку. В 1890-х Ringelmann заставлял людей тянуть верёвки поодиночке и в группах. Он измерял силу тяги и обнаружил, что в группе люди прилагали меньше усилий, чем поодиночке.

For (some) data scientists, it can lead to increased motivation and job satisfaction, which is closely tied to autonomy, mastery, and purpose.

У (некоторых) data scientist'ов это повышает мотивацию и удовлетворённость работой, которые тесно связаны с автономией, мастерством и смыслом.

Автономия: возможность решать задачи самостоятельно. Вместо того чтобы ждать и зависеть от других, end-to-end data scientist может сам выявить и сформулировать задачу, построить дата-пайплайны, развернуть и валидировать решение. Мастерство: в задаче, решении и результате — от начала до конца. Он также осваивает домен и технологии по мере необходимости. Смысл: глубоко вовлекаясь во весь процесс, он сильнее связан с работой и её результатами, что усиливает ощущение смысла.

But, we need specialist experts too

Но нам также нужны узкие специалисты

Being end-to-end is not for everyone (and every team) though, for reasons such as:

Быть end-to-end подходит не всем (и не каждой команде), по разным причинам:

Wanting to specialize in machine learning, or perhaps a specific niche in machine learning such as neural text generation (read: GPT-3 primer). While being end-to-end is valuable, we also need such world-class experts in research and industry who push the envelope. Much of what we have in ML came from academia and pure research efforts.

Желание специализироваться в machine learning или в какой-то конкретной нише, например, в нейронной генерации текста (см.: GPT-3 primer). Работа end-to-end ценна, но нам нужны и эксперты мирового класса в исследованиях и индустрии, которые двигают границы. Многое из того, что есть в ML, пришло из академии и чистых исследований.

No one achieves greatness by becoming a generalist. You don’t hone a skill by diluting your attention to its development. The only way to get to the next level is focus. – John C. Maxwell

Никто не достигает величия, становясь дженералистом. Невозможно отточить навык, размывая своё внимание на его развитие. Единственный способ перейти на новый уровень — фокус. – John C. Maxwell

Lack of interest. Not everyone is keen to engage with customers and business to define the problem, gather requirements, and write design documents. Likewise, not everyone is interested in software engineering, production code, unit tests, and CI/CD pipelines.

Отсутствие интереса. Не каждому хочется общаться с клиентами и бизнесом, чтобы формулировать задачу, собирать требования и писать дизайн-документы. Так же не каждый интересуется software engineering, продакшен-кодом, юнит-тестами и CI/CD пайплайнами.

Working on large, high leverage systems where 0.01% improvement has giant impact. For example, algorithmic trading and advertising. In such situations, hyper-specialization is required to eke out those improvements.

Работа над крупными high-leverage системами, где улучшение в 0,01% даёт гигантский эффект. Например, алготрейдинг и реклама. В таких ситуациях нужна гиперспециализация, чтобы выжать эти улучшения.

Others have also made arguments for why data scientists should specialize (and not be end-to-end). Here are a few articles to provide balance and counter-arguments:

Другие также приводили аргументы за специализацию data scientist'ов (вместо end-to-end). Вот несколько статей для баланса и контраргументов:

Why You Shouldn't Be A Data Science Generalist Why Every Data Scientist Needs to Specialize Want a Job in Data Science? Here's Why You Should Specialize

The best way to pick it up is via learning by doing

Лучший способ это освоить — учиться на практике

If you’re still keen on becoming more end-to-end, we’ll now discuss how to do so. Before that, without going into specific technology, here are the buckets of skills that end-to-end data scientists commonly use:

Если вам всё же хочется стать более end-to-end, обсудим, как этого добиться. Прежде чем углубляться в конкретные технологии, вот наборы навыков, которые обычно используют end-to-end data scientist'ы:

Продукт: понимать проблемы клиентов, формулировать и приоритизировать требования. Коммуникация: координировать команды, добиваться согласия, писать документы, делиться результатами. Дата-инжиниринг: перемещать и преобразовывать данные из точки A в B. Анализ данных: понимать и визуализировать данные, A/B тестирование и инференс. Machine learning: обычные задачи плюс эксперименты, реализация и метрики. Software engineering: практики продакшен-кода, включая юнит-тесты, документацию, логирование. Dev Ops: базовое владение контейнеризацией и облаком, сборочные и автоматизационные инструменты.

(This list is neither mandatory nor exhaustive. Most projects don’t require all of them.)

(Этот список ни обязателен, ни исчерпывающий. Большинству проектов не нужно всё.)

Here are four ways you can move closer to being an end-to-end data scientist:

Вот четыре способа приблизиться к роли end-to-end data scientist:

Study the right books and courses. (Okay, this is not learning by doing but we all need to start somewhere). I would focus on courses that cover tacit knowledge rather than specific tools. While I’ve not come across such materials, I’ve heard good reviews about Full Stack Deep Learning.

Изучайте правильные книги и курсы. (Окей, это не «обучение на практике», но всем нужно с чего-то начинать). Я бы сосредоточился на курсах, передающих неявные знания, а не конкретные инструменты. Сам я подобных материалов не встречал, но слышал хорошие отзывы о Full Stack Deep Learning.

Do your own projects end-to-end to get first-hand experience of the entire process. At the risk of oversimplifying it, here are some steps I would take with their associated skills.

Делайте собственные проекты end-to-end, чтобы получить опыт всего процесса из первых рук. Рискну упростить — вот шаги, которые я бы предпринял, и связанные с ними навыки.

I hear and I forget. I see and I remember. I do and I understand. – Confucius

Слышу — забываю. Вижу — запоминаю. Делаю — понимаю. – Конфуций

Start with identifying a problem to solve and determining the success metric (product). Then, find some raw data (i.e., not Kaggle competition data); this lets you clean and prepare the data and create features (data engineering). Next, try various ML models, examining learning curves, error distributions, and evaluation metrics (data science).

Начните с выявления задачи и определения метрики успеха (product). Затем найдите сырые данные (то есть не данные с Kaggle-соревнования); это позволит вам очистить и подготовить данные и создать фичи (data engineering). Дальше попробуйте разные ML-модели, изучая кривые обучения, распределение ошибок и метрики оценки (data science).

Assess each model’s performance (e.g., query latency, memory footprint) before picking one and writing a basic inference class around it for production (software engineering). (You might also want to build a simple user interface). Then, containerise and deploy it online for others to use via your preferred cloud provider (dev ops).

Оцените производительность каждой модели (например, латентность запросов, объём памяти), выберите одну и напишите вокруг неё базовый inference-класс для продакшна (software engineering). (Возможно, вы захотите построить простой пользовательский интерфейс.) Затем упакуйте в контейнер и разверните онлайн через выбранного облачного провайдера, чтобы другие могли пользоваться (dev ops).

Once that’s done, go the extra mile to share about your work. You could write an article for your site or speak about it at a meetup (communication). Show what you found in the data via meaningful visuals and tables (data analysis). Share your work on GitHub. Learning and working in public is a great way to get feedback and find potential collaborators.

После этого пройдите лишнюю милю и расскажите о своей работе. Можно написать статью на своём сайте или выступить на митапе (communication). Покажите, что вы нашли в данных, через осмысленные визуализации и таблицы (data analysis). Поделитесь работой на GitHub. Учиться и работать публично — отличный способ получить обратную связь и найти потенциальных соавторов.

Volunteer through groups like DataKind. DataKind works with social organizations (e.g., NGOs) and data professionals to address humanitarian issues. By collaborating with these NGOs, you get the opportunity to work as part of a team to tackle real problems with real(ly messy) data.

Волонтёрьте через сообщества вроде DataKind. DataKind работает с социальными организациями (например, НКО) и специалистами по данным над гуманитарными проблемами. Сотрудничая с такими НКО, вы получаете возможность работать в команде над реальными задачами с реально грязными данными.

While volunteers may be assigned specific roles (e.g., PM, DS), you’re always welcome to tag along and observe. You’ll see (and learn) how PMs engage with NGOs to frame the problem, define solutions, and organize the team around it. You’ll learn from fellow volunteers how to work with data to develop working solutions. Volunteering in hackathon-like DataDives and longer-term DataCorps is a great way to contribute to the data science process end-to-end.

Хотя волонтёрам могут назначать конкретные роли (например, PM, DS), вы всегда можете присоединиться и просто наблюдать. Вы увидите (и поймёте), как PM работают с НКО, чтобы сформулировать проблему, определить решения и организовать команду. У других волонтёров вы научитесь работать с данными и создавать рабочие решения. Волонтёрство в хакатоно-подобных DataDives и более долгих DataCorps — отличный способ внести вклад в процесс data science end-to-end.

Join a startup-like team. Note: A startup-like team is not synonymous with a startup. There are big organizations that run teams in a startup-like manner (e.g., two-pizza teams) and startups made up of specialists. Find a lean team where you’re encouraged, and have the opportunity, to work end-to-end.

Присоединяйтесь к стартап-подобной команде. Заметьте: стартап-подобная команда — не синоним стартапа. Бывают крупные организации с командами в стартап-стиле (например, two-pizza teams) и стартапы из узких специалистов. Найдите небольшую команду, где вас поощряют и где у вас есть возможность работать end-to-end.

End-to-end in Stitch Fix and Netflix

End-to-end в Stitch Fix и Netflix

Eric Colson of Stitch Fix was initially “lured to a function-based division of labour by the attraction of process efficiencies” (i.e., the data science pin factory). But over trial and error, he found end-to-end data scientists to be more effective. Now, instead of organizing data teams for specialization and productivity, Stitch Fix organizes them for learning and developing new data and algorithmic products.

Эрик Колсон из Stitch Fix изначально «поддался привлекательности функционального разделения труда из-за эффективности процессов» (то есть фабрики дата-сайентистов). Но методом проб и ошибок он обнаружил, что end-to-end data scientist'ы эффективнее. Теперь, вместо организации дата-команд ради специализации и продуктивности, Stitch Fix организует их ради обучения и разработки новых продуктов на данных и алгоритмах.

The goal of data science is not to execute. Rather, the goal is to learn and develop new business capabilities. … There are no blueprints; these are new capabilities with inherent uncertainty. … All the elements you’ll need must be learned through experimentation, trial and error, and iteration. – Eric Colson

Цель data science не в выполнении. Скорее, цель — учиться и развивать новые бизнес-возможности. … Чертежей нет; это новые возможности с присущей им неопределённостью. … Все необходимые элементы должны быть получены через эксперименты, пробы и ошибки, итерации. – Eric Colson

He suggests that data science roles should be made more general, with broad responsibilities agnostic to technical function and optimized for learning. Thus, his team hires and grows generalists who can conceptualize, model, implement, and measure. Of course, this is dependent on a solid data platform that abstracts away the complexities of infra setup, distributed processing, monitoring, automated failover, etc.

Он предлагает делать роли data science более общими, с широкими обязанностями вне технической функции и оптимизированными под обучение. Поэтому его команда нанимает и растит дженералистов, способных концептуализировать, моделировать, реализовывать и измерять. Конечно, это зависит от мощной дата-платформы, абстрагирующей сложности настройки инфраструктуры, распределённой обработки, мониторинга, автоматических переключений и так далее.

Having end-to-end data scientists improved Stitch Fix’s learning and innovation capabilities, enabling them to discover and build more business capabilities (relative to a specialist team).

Наличие end-to-end data scientist'ов улучшило способности Stitch Fix к обучению и инновациям, позволив открывать и создавать больше бизнес-возможностей (по сравнению с командой специалистов).

Netflix Edge Engineering initially had specialized roles. However, this created inefficiencies across the product life cycle. Code releases took more time (weeks instead of days), deployment problems took longer to detect and resolve, and production issues required multiple back-and-forth communications.

Netflix Edge Engineering поначалу имела специализированные роли. Однако это создавало неэффективности по всему жизненному циклу продукта. Релизы кода занимали больше времени (недели вместо дней), проблемы развёртывания дольше выявлялись и устранялись, а продакшен-инциденты требовали многочисленных переписок.

At the extreme, each function area/product is owned by 7 people (source)

В крайнем случае за каждой функциональной областью/продуктом стоят 7 человек (источник)

To address this, they experimented with Full Cycle Developers who were empowered to work across the entire software life cycle. This required a mindset shift—instead of just considering design and development, devs also had to consider deployment and reliability.

Чтобы решить это, они поэкспериментировали с Full Cycle Developers, которым дали полномочия работать на всём жизненном цикле ПО. Это потребовало смены мышления — помимо проектирования и разработки, разработчики должны были думать о развёртывании и надёжности.

Instead of multiple roles and people, we now have the full cycle dev (source)

Вместо нескольких ролей и людей теперь есть full cycle dev (источник)

To support full cycle devs, centralized teams built tooling to automate and simplify common development process (e.g., build and deploy pipelines, monitoring, managed rollbacks). Such tooling is reusable across multiple teams, acts as a force multiplier, and helped devs be effective across the entire cycle.

Чтобы поддержать full cycle разработчиков, централизованные команды строили инструменты для автоматизации и упрощения общих процессов разработки (например, билд- и деплой-пайплайны, мониторинг, управляемые откаты). Такие инструменты переиспользуются между командами, действуют как множитель силы и помогают разработчикам быть эффективными на всём цикле.

With the full cycle developer approach, Edge Engineering was able to iterate quicker (instead of coordinating across teams), with faster and more routine deployments.

С подходом full cycle developer Edge Engineering смогла итерировать быстрее (вместо координации между командами), с более быстрыми и рутинными развёртываниями.

Did it work for me? Here are a few examples

Сработало ли это у меня? Вот несколько примеров

At IBM, I was on a team that created job recommendations for staff. Running the entire pipeline took a very long time. I thought we could halve the time by moving the data prep and feature engineering pipelines into the database. But, the database guy didn’t have time to test this. Being impatient, I ran some benchmarks and reduced overall run time by 90%. This allowed us to experiment 10x faster and save on compute cost in production.

В IBM я был в команде, создававшей рекомендации вакансий для сотрудников. Запуск всего пайплайна занимал очень много времени. Я думал, что можно сократить его вдвое, перенеся подготовку данных и feature engineering в базу. Но у специалиста по базам не было времени это протестировать. Не имея терпения, я прогнал бенчмарки и сократил общее время работы на 90%. Это позволило экспериментировать в 10 раз быстрее и сэкономить на compute в продакшне.

While building Lazada’s ranking system, I found Spark necessary for data pipelines (due to the large data volume). However, our cluster only supported the Scala API which I was unfamiliar with. Not wanting to wait (for data engineering support), I chose the faster—but painful—route of figuring out Scala Spark and writing the pipelines myself. This likely halved dev time and gave me a better understanding of the data to build a better model.

Создавая систему ранжирования Lazada, я понял, что для дата-пайплайнов нужен Spark (из-за большого объёма данных). Однако наш кластер поддерживал только Scala API, с которым я не был знаком. Не желая ждать (поддержки от data engineering), я выбрал более быстрый — но болезненный — путь: разобраться со Scala Spark и написать пайплайны самому. Это, вероятно, сократило время разработки вдвое и дало мне лучшее понимание данных для построения лучшей модели.

After a successful A/B test, we found that business stakeholders didn’t trust the model. As a result, they were manually picking top products to display, decreasing online metrics (e.g., CTR, conversion). To understand more, I made trips to our marketplaces (e.g., Indonesia, Vietnam). Through mutual education, we were able to address their concerns and reduce the amount of manual overwriting and reap the gains.

После успешного A/B теста мы обнаружили, что бизнес-стейкхолдеры не доверяют модели. В результате они вручную выбирали топ-товары для показа, ухудшая онлайн-метрики (например, CTR, конверсию). Чтобы лучше понять ситуацию, я ездил на наши маркетплейсы (например, в Индонезию, Вьетнам). Через взаимное обучение мы смогли снять их опасения, сократить ручные правки и получить выгоду.

In the examples above, going out of the regular DS & ML job scope helped with delivering more value, faster. In the last example, it was necessary to unblock our data science efforts.

В приведённых примерах выход за рамки обычной работы DS и ML помог принести больше ценности и быстрее. В последнем примере это было необходимо, чтобы разблокировать наши усилия в data science.

Try it out

Попробуйте

You may not be end-to-end now. That’s okay—few people are. Nonetheless, consider its benefits and stretching closer towards it.

Возможно, сейчас вы не end-to-end. Это нормально — мало кто такой. Тем не менее, обдумайте преимущества и попробуйте подтянуться ближе.

Which aspects would disproportionately improve your ability to deliver as a data scientist? Increased engagement with customers and stakeholders to design more holistic, innovative solutions? Building and orchestrating your own data pipelines? Greater awareness of engineering and product constraints for faster integration and deployments?

Какие аспекты непропорционально улучшили бы вашу способность приносить ценность как data scientist? Более тесное взаимодействие с клиентами и стейкхолдерами для создания более целостных, инновационных решений? Построение и оркестрация собственных дата-пайплайнов? Большая осведомлённость об инженерных и продуктовых ограничениях ради быстрой интеграции и развёртываний?

Pick one and try it. After you get better at it, try something else. Let me know how it goes in the tweet or comments below!

Выберите одно и попробуйте. Когда станете лучше — попробуйте что-то ещё. Расскажите, как идут дела, в твите или комментариях ниже!

Unpopular view: Data scientists should be more end-to-end.

While this is frowned upon (too generalist!), I've seen it lead to more context, faster iteration, greater innovation—more value, faster.

More details and Stitch Fix & Netflix's experience 👇 https://t.co/aOBjuBSsSz

Непопулярное мнение: data scientist'ы должны быть более end-to-end. Хотя это порицают (слишком дженералист!), я видел, как такой подход даёт больше контекста, более быстрые итерации, больше инноваций — больше ценности и быстрее. Детали и опыт Stitch Fix и Netflix 👇 https://t.co/aOBjuBSsSz— Eugene Yan (@eugeneyan) August 12, 2020

Addendum: Clarifying the intent of this post

Дополнение: уточняю замысел этого поста

A couple months after publishing this, I realize some readers interpret this post from the skills and technical knowledge perspective. They see this post as pushing for data scientists / ML engineers to be full-stack and have in-depth knowledge of how to set up K8s, do PhD-level research, design front-end, etc. That’s not my intention.

Через пару месяцев после публикации я понял, что некоторые читатели воспринимают этот пост с точки зрения навыков и технических знаний. Они видят его как призыв к data scientist'ам / ML-инженерам стать full-stack и обладать глубокими знаниями о том, как настраивать K8s, делать PhD-исследования, проектировать фронтенд и т. д. Это не моё намерение.

Instead, I’m trying to convince that end-to-end visibility, cohesion (i.e., reverse Conway’s Law), and ownership leads to better outcomes. Although visibility should be paired with ability to make an impact, for a start, its sufficient to be able to use the tools without being able to set it up yourself. The effective data scientists I know are power users of their tools even without being able to set it up from scratch (though I’m sure they can pick it up fast).

Я пытаюсь убедить, что end-to-end видимость, целостность (то есть обратный закон Конвея) и ownership ведут к лучшим результатам. Хотя видимость должна сопровождаться способностью влиять, для начала достаточно уметь использовать инструменты не умея их настраивать. Эффективные data scientist'ы, которых я знаю, — мощные пользователи своих инструментов, даже если не умеют поднять всё с нуля (хотя уверен, что освоят быстро).

You don’t have to be able to build a plane, runway, or airport to be a pilot.

Чтобы быть пилотом, не обязательно уметь построить самолёт, взлётно-посадочную полосу или аэропорт.

Thanks to Yang Xinyi for reading drafts of this, and to Basil Han and @gSajko for suggesting bug fixes.

Спасибо Yang Xinyi за чтение черновиков и Basil Han и @gSajko за указание на баги.

If you found this useful, please cite this write-up as:

Если это оказалось полезным, цитируйте, пожалуйста, этот текст так:

Yan, Ziyou. (Aug 2020). Unpopular Opinion: Data Scientists Should be More End-to-End. eugeneyan.com. https://eugeneyan.com/writing/end-to-end-data-science/.

Yan, Ziyou. (Aug 2020). Unpopular Opinion: Data Scientists Should be More End-to-End. eugeneyan.com. https://eugeneyan.com/writing/end-to-end-data-science/.

or

или

@article{yan2020end, title = {Unpopular Opinion: Data Scientists Should be More End-to-End}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Aug}, url = {https://eugeneyan.com/writing/end-to-end-data-science/} }

@article{yan2020end, title = {Unpopular Opinion: Data Scientists Should be More End-to-End}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Aug}, url = {https://eugeneyan.com/writing/end-to-end-data-science/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

Присоединяйтесь к 11 800+ читателям, которые получают обновления о machine learning, RecSys, LLM и инженерии.