Ерік Гфессер, головний архітектор практики обробки даних SPR – Серія інтерв’ю

Ерік приєднався до практики даних SPR's Emerging Technology Group як головний архітектор у 2018 році.

Ерік спеціалізується на даних, розробці з відкритим кодом за допомогою Java та практичній корпоративній архітектурі, включаючи створення PoC, прототипів і MVP.

Що спочатку привабило вас у машинному навчанні?

Це дозволяє програмам безперервно навчатися. Я розпочав свою кар’єру розробника як старший аналітик даних із використанням SPSS у компанії, яка стала глобальною дослідницькою компанією, а пізніше включив використання механізму бізнес-правил під назвою Drools у програми, які я створював для клієнтів, але результати всієї цієї роботи були по суті статичний.

Пізніше я пройшов тренінги з удосконалення процесів, під час яких інструктори детально продемонстрували, як вони змогли покращити, за допомогою статистики та інших методів, бізнес-процеси, що використовуються їхніми клієнтами, але тут знову результат був зосереджений на точках у часі. Мій досвід роботи над удосконаленням продукту охорони здоров’я, створеного моїми колегами та мною протягом того самого періоду часу, показав мені, чому для таких зусиль необхідно постійне навчання, але доступних ресурсів тоді не існувало.

Цікаво, що моє захоплення машинним навчанням завершилося, оскільки мій дипломований консультант застеріг мене від спеціальності в тому, що тоді називалося штучним інтелектом, через зиму ШІ. Натомість я вирішив використовувати такі терміни, як ML, тому що вони містять менше конотацій, і тому що навіть AWS визнає, що рівень її послуг штучного інтелекту насправді є просто абстракцією вищого рівня, побудованою на рівні її послуг ML. Хоча деякий ажіотаж щодо ML є нереалістичним, він надає потужні можливості з точки зору розробників, доки ті самі практики визнають той факт, що цінність, яку надає ML, настільки ж хороша, як і дані, які ним обробляються.

Ви великий прихильник відкритого коду, не могли б ви обговорити, чому відкритий код такий важливий?

Один аспект відкритого коду, який мені потрібно було пояснити керівникам протягом багатьох років, полягає в тому, що головна перевага відкритого коду полягає не в тому, що використання такого програмного забезпечення стає доступним без грошових витрат, а в тому, що вихідний код надається у вільний доступ.

Крім того, розробники, які використовують цей вихідний код, можуть змінювати його для власного використання, і якщо запропоновані зміни будуть схвалені, зробити ці зміни доступними для інших розробників, які його використовують. Насправді рух за програмним забезпеченням з відкритим вихідним кодом почався через те, що розробники довго чекали, поки комерційні фірми внесуть зміни в продукти, які вони ліцензували, тому розробники взяли на себе зобов’язання писати програмне забезпечення з тією ж функціональністю, відкриваючи його для вдосконалення іншими. розробників.

Комерціалізоване відкрите програмне забезпечення користується цими перевагами, але реальність така, що багато сучасних продуктів використовують відкрите програмне забезпечення під обкладинками, навіть якщо комерційні варіанти такого програмного забезпечення зазвичай містять додаткові компоненти, недоступні як частина даного випуску з відкритим кодом, забезпечуючи такі відмінності, як а також підтримку, якщо це необхідно.

Мій перший досвід роботи з відкритим кодом відбувся під час розробки продукту охорони здоров’я, про який я згадував раніше, використовуючи такі інструменти, як Apache Ant, який використовується для створення програмного забезпечення, і ранній продукт DevOps того часу під назвою Hudson (база коду якого пізніше стала Jenkins ). Основною причиною наших рішень використовувати ці продукти з відкритим кодом було те, що вони або надавали кращі рішення порівняно з комерційними альтернативами, або були інноваційними рішеннями, навіть не пропонованими комерційними організаціями, не кажучи вже про те, що комерційне ліцензування деяких продуктів, які ми використовували був надто обмежуючим, що призвело до надмірної бюрократії, коли прийшов час потребувати додаткових ліцензій, через витрати.

З часом я бачу, як пропозиції з відкритим кодом продовжують розвиватися, забезпечуючи такі необхідні інновації. Наприклад, багато проблем, з якими ми з колегами боролися, створюючи цей продукт для охорони здоров’я, пізніше були вирішені за допомогою інноваційного Java-продукту з відкритим вихідним кодом, який ми почали використовувати під назвою Spring Framework, який все ще продовжує працювати після більш ніж десятиліття, екосистема якого тепер простягається далеко за межі деяких нововведень, які він надавав спочатку, а зараз вважаються звичайними, наприклад впровадження залежностей.

Ви використовували відкритий код для створення PoC, прототипів і MVP. Не могли б ви поділитися своєю подорожжю до деяких із цих продуктів?

Як пояснювалося в одному з керівних принципів, які я представив нещодавньому клієнту, розробка платформи даних, яку ми створили для них, має продовжувати виконуватися ітеративно за потреби з часом. Не слід очікувати, що компоненти, створені для цієї платформи, залишаться статичними, оскільки потреби змінюються, і з часом будуть доступні нові компоненти та функції компонентів.

Розробляючи функціональність платформи, завжди починайте з того, що є мінімально життєздатним, перш ніж додавати непотрібні навороти, що в деяких випадках навіть включає конфігурацію. Почніть із того, що є функціональним, переконайтеся, що ви це розумієте, а потім розвивайте це. Не витрачайте час і гроші на створення того, що малоймовірно буде використано, але докладіть зусиль, щоб випередити майбутні потреби.

MVP, який ми створили для цього продукту, явно потребував створення так, щоб додаткові сценарії використання могли продовжувати створюватися поверх нього, навіть незважаючи на те, що він постачався з реалізацією єдиного сценарію використання для виявлення аномалії витрат. На відміну від цього клієнта, попередній продукт, який я створив, мав певну історію до мого прибуття. У цьому випадку зацікавлені сторони три роки (!) обговорювали, як їм підійти до продукту, який вони хотіли створити. Керівник клієнта пояснив, що однією з причин, чому він запросив мене, було допомогти фірмі подолати деякі з цих внутрішніх дебатів, особливо тому, що продукт, який він збирався створити, мав задовольнити ієрархію залучених організацій.

Я зрозумів, що ці війни були в основному пов’язані з даними, якими володіли клієнт, його дочірні компанії та зовнішні клієнти, тому в цьому випадку весь беклог продукту обертався навколо того, як ці дані будуть прийматися, зберігатися, захищатися та споживатися. для єдиного використання, що генерує мережі постачальників медичних послуг на льоту для аналізу витрат.

На початку своєї кар’єри я зрозумів, що архітектурна якість під назвою «юзабіліті» не обмежується лише кінцевими користувачами, а й самими розробниками програмного забезпечення. Причина цього полягає в тому, що написаний код має бути придатним для використання так само, як інтерфейс користувача має бути придатним для використання кінцевими користувачами. Для того, щоб продукт став придатним для використання, необхідно створити докази концепції, щоб продемонструвати, що розробники зможуть зробити те, що вони задумали, особливо в зв’язку з вибором конкретної технології, яку вони роблять. Але докази концепції – це лише початок, оскільки продукти є найкращими, коли розвиваються з часом. Однак, на мій погляд, основа для MVP в ідеалі повинна бути побудована на прототипах, що демонструють певну стабільність, щоб розробники могли продовжувати його розвивати.

У той час як огляд книги "Машинне навчання в масштабі підприємства" Ви заявили, що «використання продуктів з відкритим кодом, фреймворків і мов разом із гнучкою архітектурою, що складається з поєднання відкритих кодів і комерційних компонентів, забезпечує гнучкість, яка потрібна багатьом компаніям, але не відразу усвідомлюється на початку». Не могли б ви детальніше розповісти, чому ви вважаєте, що фірми, які використовують відкритий код, більш спритні?

Багато комерційних продуктів обробки даних використовують під обкладинками ключові компоненти з відкритим кодом і дозволяють розробникам використовувати такі популярні мови програмування, як Python. Компанії, які розробляють ці продукти, знають, що компоненти з відкритим кодом, які вони вирішили включити, дають їм швидкий старт, коли вони вже широко використовуються спільнотою.

Компоненти з відкритим кодом із сильними спільнотами легше продавати завдяки знайомству, яке вони приносять до столу. Комерційно доступні продукти, які складаються в основному з закритим кодом або навіть з відкритим кодом, який здебільшого використовується лише в конкретних комерційних продуктах, часто потребують або навчання від цих постачальників, або ліцензій, щоб використовувати програмне забезпечення.

Крім того, документація для таких компонентів здебільшого не є загальнодоступною, що змушує розробників постійно залежати від цих фірм. Коли широко прийняті компоненти з відкритим вихідним кодом, такі як Apache Spark, є центральною увагою, як-от у випадку з такими продуктами, як Databricks Unified Analytics Platform, багато з цих елементів уже доступні для спільноти, мінімізуючи частини, від яких команди розробників повинні залежати від комерційних організацій. виконувати свою роботу.

Крім того, оскільки такі компоненти, як Apache Spark, широко прийняті як де-факто галузевий стандартний інструментарій, код також можна легше переносити між комерційними реалізаціями таких продуктів. Компанії завжди будуть схильні включати те, що вони вважають конкурентоспроможними відмінностями, але багато розробників не хочуть використовувати абсолютно нові продукти, оскільки це виявляється складним переміщенням між фірмами, і це призводить до розриву їхніх зв’язків із сильними спільнотами, до яких вони прийшли. очікувати.

З особистого досвіду я працював із такими продуктами в минулому, і мені може бути складно отримати компетентну підтримку. І це парадоксально, враховуючи, що такі фірми продають свою продукцію з очікуванням клієнтів, що підтримка буде надана вчасно. У мене був досвід надсилання запиту на вилучення до проекту з відкритим вихідним кодом, і виправлення було включено в збірку того ж дня, але я не можу сказати того ж про будь-який комерційний проект, з яким я працював.

Ще щось, у що ви вірите щодо відкритого коду, це те, що воно веде до «доступу до сильних спільнот розробників». Наскільки великими є деякі з цих спільнот і що робить їх такими ефективними?

Спільноти розробників навколо продукту з відкритим кодом можуть досягати сотень тисяч. Показники усиновлення не обов’язково вказують на силу спільноти, але є гарним показником того, що це так, оскільки вони мають тенденцію створювати позитивні цикли. Я вважаю спільноти сильними, коли вони створюють здорове обговорення та ефективну документацію, і де відбувається активний розвиток.

Коли архітектор або старший розробник працює над процесом вибору таких продуктів для включення в те, що вони будують, багато факторів, як правило, вступає в дію, не лише щодо самого продукту та того, як виглядає спільнота, але й щодо команд розробників, які будуть приймати їх, чи добре вони підходять для екосистеми, що розробляється, як виглядає дорожня карта, а в деяких випадках чи можна знайти комерційну підтримку, якщо це може знадобитися. Однак багато з цих аспектів відходять на другий план через відсутність сильних спільнот розробників.

Ви переглянули сотні книг на своєму веб-сайті, чи є три, які ви можете порекомендувати нашим читачам?

Сьогодні я читаю дуже мало книг з програмування, і хоча є винятки, насправді вони зазвичай застарівають дуже швидко, і спільнота розробників зазвичай пропонує кращі альтернативи через дискусійні форуми та документацію. Багато книг, які я зараз читаю, надаються мені у вільний доступ через розсилки новин про технології, на які я підписався, через авторів і публіцистів, які звертаються до мене, або через ті, що надсилає мені Amazon. Наприклад, у 2011 році Amazon надіслав мені для огляду невиправлене підтвердження «The Lean Startup» перед публікацією, ознайомивши мене з концепцією MVP, а нещодавно надіслав мені копію «Julia for Beginners».

(1) Одна книга від O'Reilly, яку я рекомендував «У пошуках нірвани бази даних». Автор детально описує виклики для механізму запитів даних для підтримки робочих навантажень, що охоплюють спектр OLTP з одного боку, до аналітики з іншого, з робочими навантаженнями операційної та бізнес-аналітики посередині. Цю книгу можна використовувати як посібник для оцінки механізму бази даних або комбінації механізмів запитів і зберігання, спрямованих на задоволення вимог до робочого навантаження, будь то транзакційні, аналітичні або поєднання цих двох. Крім того, особливо добре висвітлено автором останні роки «розгойдування маятника бази даних».

(2) Хоча багато чого змінилося в просторі даних за останні кілька років, оскільки нові продукти аналізу даних продовжують впроваджуватися, «Проривна аналітика» представляє доступну коротку історію останніх 50 років інновацій в аналітиці, яких я ніде не бачив, і обговорює два типи руйнувань: руйнівні інновації в аналітичному ланцюжку створення вартості та руйнування галузі через інновації в аналітиці. З точки зору стартапів і практиків аналітики, успіх досягається шляхом руйнування їхніх галузей, оскільки використання аналітики для диференціації продукту є способом створити руйнівну бізнес-модель або створити нові ринки. З точки зору інвестування в аналітичні технології для їхніх організацій, застосування вичікувального підходу може мати сенс, оскільки технології, яким загрожує збій, є ризикованими інвестиціями через скорочений термін служби.

(3) Один із найкращих текстів про технологічний бізнес, який я читав, це «Межі стратегії“, співзасновником Research Board (придбаної Gartner), міжнародного аналітичного центру, який досліджує події у світі комп’ютерів і те, як корпораціям слід адаптуватися. Автор подає дуже докладні нотатки з багатьох своїх розмов із бізнес-лідерами, надаючи глибокий аналіз свого досвіду створення (разом із дружиною) групи клієнтів, великих фірм, яким потрібно було узгодити свої стратегії зі світом комп’ютерів, що вибухає. Як я прокоментував у своєму огляді, те, що відрізняє цю книгу від інших пов’язаних з нею зусиль, це дві, здавалося б, протилежні характеристики: галузева широта та інтимність, яка доступна лише через особисту взаємодію.

Ви є головним архітектором практики даних SPR. Чи можете ви описати, що робить SPR?

SPR – це консалтингова компанія з цифрових технологій, розташована в районі Чикаго, яка надає технологічні проекти для низки клієнтів, від компаній зі списку Fortune 1000 до місцевих стартапів. Ми створюємо наскрізний цифровий досвід, використовуючи низку технологічних можливостей, починаючи від спеціальної розробки програмного забезпечення, взаємодії з користувачами, даних і хмарної інфраструктури до навчання DevOps, тестування програмного забезпечення та управління проектами.

Які ваші обов’язки в SPR?

Як головний архітектор, мій головний обов’язок полягає в тому, щоб надавати клієнтам рішення, керувати архітектурою та розробкою проектів, і це часто означає носити інші головні убори, наприклад власника продукту, тому що здатність зрозуміти, як створюються продукти з практичної точки зору, важить значною мірою щодо того, як слід розставляти пріоритети в роботі, особливо при створенні з нуля. Мене також залучають до обговорень з потенційними клієнтами, коли потрібен мій досвід, і компанія нещодавно попросила мене розпочати постійну серію зустрічей з колегами-архітекторами з практики обробки даних, щоб обговорити проекти клієнтів, додаткові проекти та те, що таке мої колеги. роблячи, щоб бути в курсі технологій, подібно до того, що я раніше проводив для консультації, хоча, так би мовити, внутрішні зустрічі для цієї іншої фірми включали всю їхню технологічну практику, а не роботу з даними.

Більшу частину своєї кар’єри я спеціалізувався на розробці з відкритим кодом за допомогою Java, виконуючи на цьому шляху все більший обсяг роботи з даними. Окрім цих двох спеціалізацій, я також роблю те, що ми з колегами називаємо «практичною» або «прагматичною» архітектурою підприємства, що означає виконання архітектурних завдань у контексті того, що має бути побудовано, і фактичне його будівництво, ніж просто говорити про це чи малювати діаграми, усвідомлюючи, звичайно, що ці інші завдання також важливі.

На мій погляд, ці три спеціалізації перетинаються і не виключають одна одну. Протягом останніх кількох років я пояснював керівникам, що межа, яку традиційно проводила індустрія технологій між розробкою програмного забезпечення та роботою з даними, більше не є чітко визначеною, частково тому, що інструменти між цими двома просторами зблизилися, а частково тому, що в результаті цієї конвергенції сама робота з даними значною мірою перетворилася на роботу з розробки програмного забезпечення. Однак, оскільки традиційні практики обробки даних зазвичай не мають досвіду розробки програмного забезпечення, і навпаки, я допомагаю усунути цю прогалину.

Над яким цікавим проектом ви зараз працюєте з SPR?

Нещодавно я опублікував перша публікація в серії прикладів із багатьох частин про раніше згадану платформу даних, яку ми з командою впровадили в AWS з нуля минулого року для ІТ-директора глобальної консалтингової компанії в Чикаго. Ця платформа складається з конвеєрів даних, озера даних, канонічних моделей даних, візуалізацій і моделей машинного навчання, які будуть використовуватися корпоративними відділами, практиками та кінцевими клієнтами клієнта. Хоча основну платформу мала створити корпоративна ІТ-організація під керівництвом ІТ-директора, мета полягала в тому, щоб цю платформу використовували інші організації поза корпоративними ІТ, а також для централізації активів даних і аналізу даних у всій компанії за допомогою спільної архітектури, на основі цього, щоб задовольнити потреби кожної організації в конкретних варіантах використання.

Як і в багатьох відомих фірмах, використання Microsoft Excel було звичним явищем, коли електронні таблиці зазвичай розповсюджувалися всередині та між організаціями, а також між фірмою та зовнішніми клієнтами. Крім того, бізнес-підрозділи та консультаційні практики стали ізольованими, кожен з яких використовує різні процеси та інструменти. Таким чином, окрім централізації активів даних і аналізу даних, ще однією метою було реалізувати концепцію власності на дані та забезпечити обмін даними між організаціями безпечним і узгодженим способом.

Чи є ще щось, чим ви хотіли б поділитися про відкритий код, SPR чи інший проект, над яким ви працюєте?  

Ще один проект (читайте про нього тут та  тут), яку я нещодавно очолював, включав успішне впровадження Databricks Unified Analytics Platform і перенесення на неї виконання моделей машинного навчання з Azure HDInsight, дистрибутиву Hadoop, для директора з розробки даних великої страхової компанії.

Усі ці перенесені моделі мали на меті передбачити очікуваний рівень сприйняття споживачами різних страхових продуктів, деякі з них були перенесені з SAS за кілька років до того, коли компанія перейшла до використання HDInsight. Найбільшою проблемою була низька якість даних, але інші проблеми включали відсутність повного керування версіями, племінні знання та неповну документацію, а також незрілу документацію та підтримку Databricks щодо використання R на той час (реалізація Databricks Azure щойно стала загальнодоступною кілька місяців до цього проекту).

Щоб вирішити ці ключові проблеми, як продовження нашої роботи над впровадженням я дав рекомендації щодо автоматизації, конфігурації та керування версіями, розділення питань, пов’язаних із даними, документації та необхідного узгодження між їхніми групами даних, платформи та моделювання. Наша робота переконала спочатку дуже скептично налаштованого головного спеціаліста з обробки даних у тому, що Databricks — це правильний шлях, і після нашого відходу вони заявили про мету якнайшвидшого перенесення їхніх моделей, що залишилися, на Databricks.

Це було захоплююче інтерв’ю, яке торкалося багатьох тем, я відчуваю, що я багато чого дізнався про відкритий код. Читачі, які бажають дізнатися більше, можуть відвідати SPR корпоративний сайт або Веб-сайт Еріка Гфессера.