×Закрыть

Куди переходити з Java. Розвиток кар’єри Java-розробника

Стаття написана у співавторстві з Ярославом Клочником та Андрієм Забавським.

Привіт, я Юлія Матушкевич, Talent Success Lead (TSL) у львівському розробницькому центрі SoftServe, працюю з Java-компетенцією. Моя роль — це балансування між потребою бізнесу й талантами. Тобто, окрім того, що я добре орієнтуюся в активностях, які відбуваються в компанії за напрямом Java та на ринку, я постійно перебуваю в контакті з інженерами та їхніми менеджерами. Розуміючи особисті інтереси працівників та знаючи контекст компанії (які проєкти заходять та з якими технологіями, які нові напрями з’являються тощо), я допомагаю інженерам знаходити можливості для професійного зростання у межах компанії. Зокрема, координую процес переходу між проєктами та зміну компетенції, працюю з фахівцями, які в резерві.

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

Згідно з останнім дослідженням DOU, Java є однією з найпоширеніших мов програмування в Україні. В SoftServe простежується така сама тенденція. Java відкриває широкі можливості для професійного розвитку, оскільки дає змогу отримати цінний досвід: робота з різноманітними фреймворками, типами баз даних, унікальною архітектурою, високонавантаженими системами, кооперація із замовниками та співпраця з особливими доменами бізнесу клієнтів.

Проте якщо сфера ваших зацікавлень уже ширша за безпосередньо Java і пов’язана з архітектурними рішеннями, типом взаємодії з клієнтом, використанням Big Data, AI/ML чи платформами, і для цього є бажання опанувати нову технологію чи перейти в інший напрям, то чому ні?

Далі ми розкажемо про найбільш популярні, за нашим спостереженням, напрями розвитку з Java зараз.

Платформи

Може здатися, що робота з платформами — це просто, оскільки треба лише взяти готові елементи, які вони пропонують, і адаптувати під потреби конкретного проєкту. Насправді це складна інженерна робота, яка складається з:

  • роботи з платформою — її конфігураціями, побудовою інтеграцій тощо;
  • розробки додаткових елементів — частину з них потрібно писати з нуля під конкретний проєкт;
  • тісної співпраці з бізнесом.

Загалом платформи стрімко розвиваються, надають усе ширший функціонал, для компаній це цікаво. Ми бачимо значний попит від клієнтів, водночас ринок талантів не заповнений (відповідно конкуренція менша).

Розглянемо дві категорії платформ.

iPaaS (інтеграційні платформи — Mulesoft, Apigee, Dell Boomi)

Як зазначає Вікіпедія, System Integration (або Data Integration) — це маршрутизація даних з розрізнених джерел (баз даних, систем, мобільних/вебзастосунків через API тощо) в єдину систему/платформу в межах організації або організацій. Мій колега Ярослав Клочник написав докладну статтю про інтеграційні платформи, тож переказувати його не буду.

Якщо коротко, то інтеграційні платформи допомагають, коли:

  • Клієнт застосовує підхід вертикального масштабування (vertical scaling) і приходить до нас із запитом інтегрувати систему, яку він уже використовує з новою (наприклад, Workday з SAP SuccessFactors).
  • Клієнт застосовує підхід горизонтального масштабування (horizontal scaling) і розвиває власну систему та додає до неї нові модулі. І потрібно швидко об’єднати ці модулі для роботи з даними, трансформацій, синхронізації даних тощо.

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

Тобто, простими словами, кожна інтеграційна платформа — це набір блоків, з яких ви будуєте те, що вам потрібно. Водночас вона надає ще критично важливі додаткові сервіси (частково покриває USP, безпеку, формує data layer).

Як перейти в цей напрям

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

З основного, що потрібно вивчити:

  • об’єктноорієнтовану мову програмування;
  • специфіку самої інтеграційної платформи (у нас інженери починають зі знання однієї платформи, але на етапі промо до техліда і вище потрібно вміти працювати мінімально із двома платформами);
  • вебсервіси REST/SOAP;
  • інтеграційні патерни;
  • формат обміну даними.

На наступних етапах потрібно буде розуміти також:

  • скриптову мову (JavaScript або Groovy);
  • принципи безпеки;
  • дизайн баз даних;
  • роботу з хмарами.

Які сертифікації здавати:

  • Dell Boomi Associate Developer Certification
  • Professional Developer Certification
  • MuleSoft Certified Developer

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

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

Наприклад, за словами мого колеги Миколи Мацяха, Middle System Integration Engineer, він починав з мобільної розробки під Android на Java у продуктовій компанії. Вперше почув про інтеграційні платформи на співбесіді у SoftServe. Його зацікавило те, що тут поєднується написання коду з адаптацією готових компонентів системи. На початку роботи в команді він кілька тижнів навчався та готувався до сертифікацій. Тоді здавав Dell Boomi Associate Developer і Dell Boomi Professional Developer, пізніше — ще Dell Boomi Professional Architect. Після цього його одразу взяли на клієнтський проєкт на позицію Junior, за два роки він отримав підвищення до Middle.

Salesforce

Хмарна CRM-система для управління бізнес-процесами в галузі продажів, обслуговування клієнтів, цифрового маркетингу. Вона складається з кількох окремих продуктів, зокрема Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud, Financial Services Cloud, Health Cloud.

У 2007 році Salesforce запустила Force.com — першу PaaS-платформу для розробки та розгортання застосунків в інфраструктурі Salesforce. 2018 року її перейменували у Lightning Platform.

Якщо говорити про роботу на цій платформі, то тут є дві ролі:

  • консультанти — вивчають потреби клієнта і продумують, як Salesforce може їх задовольнити;
  • технічні експерти (інженери, архітектори).

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

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

І загалом темп роботи дуже динамічний. Можу виділити ще одну особливість — Salesforce написана на Apex (Java-подібна мова, на якій реалізовується складна бізнес-логіка), всю рутинну роботу бере на себе платформа. Тому потрібні thinkers, а не doers, які готові вчитися, шукати шляхи подолання викликів та швидко адаптуватися.

Для реалізації роботи інтерфейсу використовують сучасний JS Framework — Lightning Web Components, який відповідає стандартам es6.

Як перейти в цей напрям

Є курс, розроблений Salesforce — Trailhead. Там багато інформації. Наприклад, оверв’ю самої платформи — у цьому розділі. Загалом курс довгий. Відверто кажучи, в ньому є багато води, але й корисного теж. Особливу увагу раджу приділити частині про безпеку.

Якщо знати основи Java і пройти урок за уроком, можна претендувати на позицію Junior. А якщо маєте вже 2–3 роки практичного досвіду розробником — вийти навіть на Middle.

Які сертифікації здавати? Platform Developer 1 для початкового рівня, для наступних рівнів — відповідні номери цієї ж сертифікації.

Кейси переходу в Salesforce трапляються як серед досвідчених розробників (для таких у нас є retrain course, де за два місяці людина достатньо ознайомлюється з платформою, щоб отримати першу сертифікацію та претендувати на посаду Middle Salesforce Developer), так і новеньких. Наприклад, одна з розробниць прийшла в команду Salesforce одразу після закінчення SoftServe IT Academy за напрямом Java. Коли практичний досвід мінімальний, на навчання йде більше часу. Тому перші пів року роботи вона присвятила суто вивченню платформи та проходженню курсу Trailhead. Далі отримала Platform Developer 1, після чого її почали залучати на клієнтські проєкти. Тепер, рік після того, вона готується до наступної сертифікації, щоб перейти на рівень Middle.

Big Data

Інженерія великих даних стала актуальною ще 10 років тому. Що відбувається в цій сфері сьогодні? Якщо коротко, вона набирає все більших обертів. Постійно з’являються нові джерела даних, ринок стрімко зростає. За прогнозами Fortunebusinessinsights, до 2027 року його обсяг зросте до 116 млрд доларів. Багато організацій прагне бути data-driven, тобто ухвалювати зважені рішення на основі реальних даних та аналітики.

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

Тож збільшується і потреба в експертах. За даними QuantHub, інженер з роботи із великими даними — це профайл, який зростає найшвидше серед усіх IT-спеціальностей. На локальному ринку простежується така ж тенденція.

Напрями Data Engineering

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

Вибір рушія баз даних (Database engine). Якщо раніше реляційна модель була де-факто стандартом і вибір коливався довкола різних реляційних СКБД, то нині є тисячі варіантів.

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

Моделювання даних. Проєкція реальних сутностей і процесів на вибраний рушій баз даних — це часто нетривіальне завдання. Тут можна розділити світ на дві частини — реляційний та нереляційний.

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

Своєю чергою, високонормалізовані структури мають різні варіації та ступені нормалізації, а також і цілі методологічні напрями, як-от склепіння даних (Data Vault), якірна модель (Anchor Modelling) та інші.

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

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

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

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

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

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

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

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

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

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

З чого почати

Один з варіантів, як заглибитися у світ великих даних — вивчати сервіси та підходи одного з хмарних провайдерів. Якщо є окреслений потенційний проєкт на конкретному хмарному провайдері (GCP, Azure, AWS), то варто почати зі спеціалізованих онлайн-курсів, які пропонує кожен з них. Курси підготовки до хмарних сертифікацій зазвичай подають матеріал чітко і структуровано, що допоможе добре освоїти теорію та трохи попрактикуватися на лабораторних роботах.

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

Доволі репрезентативними тренінгами в цій сфері можуть бути зі Spark (приклад системи, що підтримує паралельні обчислення) та Cassandra (приклад NoSQL розподіленої бази даних).

Деякі хороші ресурси:

Досвід переходу мав наш колега Аделін Ганаєм з розробницького центру SoftServe в Болгарії. Він починав свій шлях в ІТ з позиції Java бекенд-розробника. Попрацювавши на кількох проєктах, він дійшов висновку, що для нього тут забагато рутини та однотипних завдань. Але якось йому трапився проєкт для телекомунікаційної компанії, де були якраз задачі, пов’язані з даними. У клієнта була велика кількість користувачів, які генерували мільйони call data records (CDRs), що зберігалися в одному великому SQL-сервері. Через це процес генерації рахунків займав занадто багато часу. Вертикальне масштабування в такій ситуації невигідне, та і загалом його зробити майже неможливо. Стало зрозуміло, що тут виходом буде використати Hadoop і MapReduce.

Так Аделін отримав перший досвід роботи з цими технологіями. Це було близько 10 років тому, саме коли Hadoop був новинкою і загалом Big Data ставала трендом. Уже тоді було зрозуміло, що за цими технологіями майбутнє.

Сам перехід з Java у Big Data колега почав 6 років тому, маючи за плечима два проєкти, пов’язані з великими даними. Він почав з поглибленого вивчення Hadoop і MapReduce. Повністю заглибився у напрям Big Data, коли перейшов у SoftServe в Big Data Center of Excellence.

Висновок

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

👍НравитсяПонравилось11
В избранноеВ избранном2
Подписаться на автора
LinkedIn

Похожие статьи



22 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

А є тут люди, які працюють з SalesForce? Наскільки це цікаво?

У SalesForce досить непогані вакансії... таки Силіконова Долина! :)

Такое ощущение что писал человек очень далекий от темы и по статьям седых нулевых (по крайней мере про Data Engineering).
Вместо тысячи слов, для Data Engineer:
Учить Python + Pandas (для фана можно и Scala, но там вакансии берлинская печаль обычно), потыкать палкой Snowflake (в реальном мире сейчас делают например вот так www.snowflake.com/...​oms-powered-by-snowflake, чтобы данные напрямую не шарить, кстати с этого можно спокойно и стартап-аутстафф делать, если есть выход на компании уровня CVS, Walgreens или Walmart), получить пару OOM в pyspark, подтянуть знания по AWS и/или Google Cloud/Azure, глянуть на Airflow.

А потом в бой -> гонять csv в паркет :-).

Гонять csv в паркет дело не хитрое, а если потоковая обработка данных и in memory процессинг? Со знанием Java/Scala есть например Kafka Streams и Akka. А что есть у python для этого?

Часто Stream Processing заканчивается на фразе «а нафига?» и что мы будем считать на окнах и для кого, там ниша еще меньше чем для Scala.

А так в общем случае какой-то Kinesis зарядил на фильтеринг говна в пару кликов и готов «stream processing» :-)

по статьям седых нулевых (по крайней мере про Data Engineering)

та невже?

Python для дата-інжинера актуальний у вакансії на дата-інженера дише там, де першу скрипку грають дата-саєнси, котрі окрім Python нічого і не знають... І якщо подобаться «підтирати штанці» комусь — добре є. Але нормальних грошей там не платитимуть...

Більшість проектів, де треба in_memory_processing (на найближчі років двадцять!) — це таки Spark.
І, зауважте, що один з самих популярних рушиїв для AI Adoption — TensorFlow — відпочатку називався TensorFlowForSpark...

Оптимальною мовою для Spark є Scala, хоча теоретично може бути і Java, і Python.
Чому так — можете легко переконатися по notebook чи Open Talent Studio...

TensorFlow відпочатку писався на Python, але, свого часу, ми в коммюніті підняли революцію і таки зробили версію на Scala...

Окрім того — перевод корпорацій на рейки MDD — а цим зараз займаються більшість великих банків та фінансових установ — це «розв’язка» їх існуючих OracleDB на exedata-машинах через Kafka + Kafka Stream/Spark Stream (можливо ще Hadoop\Empala, Solace, Spring Cloud) — а тут точно потрібні і Java, і Scala, і, можливо, R — мова програмування, котра відпочатку робилася для data-mining...
І по цьому тільки в нас сотні вакансій — як і в інших топ компаній України...

Так, і Python (хоча скорше Jython) — теж треба вивчати...
Хоча знання Python для розробника — це ризик, що компанія почне економити на девопсах та QA, бо як раз його буде треба для написання скріптов для Jenkins чи розробки автотестів...
...якщо це подобається — ву а ля! :)

та невже?

Да, и ваш комментарий это прекрасно иллюстрирует.

Python для дата-інжинера актуальний у вакансії на дата-інженера дише там, де першу скрипку грають дата-саєнси, котрі окрім Python нічого і не знають... І якщо подобаться «підтирати штанці» комусь — добре є. Але нормальних грошей там не платитимуть...

— тут даже сложно прокомментировать, а где-то сейчас DS/ML не играет первую роль? Вы до сих пор унылые чарты ROI на GWT для DB рисуете? Или из оракла данные в «озеро» на HDFS складываете? Реальные сложные задачи как раз и есть там где, например, нужно натренировать какой-то кастомизированный BERT (www.tensorflow.org/...​t/classify_text_with_bert) на массиве social media в пару десятков Тб (который до этого нужно собрать и обработать), но чтобы это не заняло пару месяцев на лучшей GPU, а максимум пару часов. Получилось? Прекрасно, теперь production -> active learning, sla/cost optimization, data/model drift, etc.
И это помимо обычных задач по quality/governance/lineage с PCI/PII/PHI/CCPA различными ограничениями по лицензиям, времени доступа и тд.
Хотя аутсорсу Enteprise клиентам нужно продавать БигДату, мне ребята из Клаудеры рассказывали про объем данных в пару десятков гигабайт и кластерах по 500+ нод для этого.

Більшість проектів, де треба in_memory_processing (на найближчі років двадцять!) — це таки Spark.

— что значит «нужен in_memory_processing»? Обычно в рамках проекта нужно обеспечить некий processing SLA. Чистый «in memory» без disk spill будет только на совсем небольших данных либо операциях в стиле «умножить на 10».

І, зауважте, що один з самих популярних рушиїв для AI Adoption — TensorFlow — відпочатку називався TensorFlowForSpark...

— OMFG, он написан на C++ и часть Питона это просто биндинги. И до сих пор со спарком он работает достаточно печально, был конечно Hydrogen (который появился и умер), но нормального E2E multi-gpu так и не появилось, остается развлекаться с Horovod.

Оптимальною мовою для Spark є Scala, хоча теоретично може бути і Java, і Python.
Чому так — можете легко переконатися по notebook чи Open Talent Studio...

— Если говорить про UDF в стиле str replace, конечно, а так SQL. Хотя, если мы говорим про Spark 3, то я думаю Arrow c Vaex в реальных задачах для UDF будут как минимум не хуже.

TensorFlow відпочатку писався на Python, але, свого часу, ми в коммюніті підняли революцію і таки зробили версію на Scala...

— Переписали с C++ на Scala :-)? И CUDA заодно?

Окрім того — перевод корпорацій на рейки MDD — а цим зараз займаються більшість великих банків та фінансових установ — це «розв’язка» їх існуючих OracleDB на exedata-машинах через Kafka + Kafka Stream/Spark Stream (можливо ще Hadoop\Empala, Solace, Spring Cloud) — а тут точно потрібні і Java, і Scala, і, можливо, R — мова програмування, котра відпочатку робилася для data-mining...
І по цьому тільки в нас сотні вакансій — як і в інших топ компаній України...

— 
все в одну кучу, ну ок, в дополнение к тому что вы перечислили (exadata и Impala) существует еще 100500 инструментов, начиная от Storm и далее до какого-то Аэрона (github.com/real-logic/aeron) зависит от задачи, вон даже Apache Camel оказывается живой. Насчет вакансий, просто в аутсорсинг идут проекты, которые не хотят делать/поддерживать локально, я не удивлюсь что и на JSP может быть спрос.

Так, і Python (хоча скорше Jython) — теж треба вивчати...

— Python это язык, Jython его имплементация на JVM. Это как предлагать учить Zulu Java, а не HotSpot.

Хоча знання Python для розробника — це ризик, що компанія почне економити на девопсах та QA, бо як раз його буде треба для написання скріптов для Jenkins чи розробки автотестів...

— seriously? www.tiobe.com/tiobe-index.

а где-то сейчас DS/ML не играет первую роль?

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

Но. Для корпораций из AI Adoption пока интересен лиш кейс NLP и Image recognition. и то лиш в контексте автоматического разбора договоров.
С другой стороны, топ корпорации имеют свои группы AI (для организации которых нужно минимум 20 PhD!) и AI Adoption их тоже не интересует...

в дополнение к тому что вы перечислили (exadata и Impala)

exadata, teradata — это большие сервера на RISK архитектуре, не которых «бегает» Oracle DB.
И когда у банка или финансового сервиса вся дата на них — никто в дравом уме не согласится єту дату кудато мигрировать. Вот тут и возникает востребованая работа настоящих Data Engineers, потому что тут нужно правильно и быстро эти данные добыть, трансформировать и организовать data mining...

Конечно, у сервиса «подглядывания в окна» задачи иные... :)

— что значит «нужен in_memory_processing»? Обычно в рамках проекта нужно обеспечить некий processing SLA. Чистый «in memory» без disk spill будет только на совсем небольших данных либо операциях в стиле «умножить на 10».

По видимому ваше «обычно в проектах» ограничевается стартапами или лоукост проектами.
Я участвовал во многих больших проектах, где это как раз было крайне актуально.
Более того. Использование Spark оптимально именно когда есть возможность и необходимость «in memory processing». Без этого оптимальнее использовать Kafka, Solace или AKKA...

TensorFlow відпочатку писався на Python, але, свого часу, ми в коммюніті підняли революцію і таки зробили версію на Scala...
— Переписали с C++ на Scala :-)? И CUDA заодно?

Изначально TensorFlow писался на Python. Но когда нас достало писать имплицид классы для связки со Scala, мы подняли «революцию» и получилась версия на Scala. А уже после этого появились версии на c++ и .net. И это уже история.

все в одну кучу

??? Мы говорим о том, чем занимается Data Engineer.
И говорим про это исключительно в контексте движения Java Engineer в том направлении...
Топик про это. :)

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

Не хочу конечно переходить на личности, но честно говоря Ваш опыт в этом направлении как-то не впечатляет :-), год уже исполнился как первый раз Spark запустили?
Я еще Kafka 0.8 с Twitter Storm вместе 7 лет назад для stream процессинга бинарных данных asn.1 и подобных для телеком телеметрии разворачивал и процессинг фреймворк для всего этого писал, с нагрузкой в сотни тысяч сообщений в секунду на один узел и загрузкой в Vertica/Netezza (это еще даже до появления первого релиза спарка). А начал с Apache Chukwa почти уже 10 лет назад.

Но. Для корпораций из AI Adoption пока интересен лиш кейс NLP и Image recognition. и то лиш в контексте автоматического разбора договоров.
С другой стороны, топ корпорации имеют свои группы AI (для организации которых нужно минимум 20 PhD!) и AI Adoption их тоже не интересует...

Вы новости из индустрии узнает по подшивкам «Техники молодежи» за 1988 год? Открою секрет, сейчас наверное нет индустрии где AI не применяется в том или ином виде.

exadata, teradata — это большие сервера на RISK архитектуре, не которых «бегает» Oracle DB.
И когда у банка или финансового сервиса вся дата на них — никто в дравом уме не согласится єту дату кудато мигрировать. Вот тут и возникает востребованая работа настоящих Data Engineers, потому что тут нужно правильно и быстро эти данные добыть, трансформировать и организовать data mining...
Конечно, у сервиса «подглядывания в окна» задачи иные... :)

В моем сообщении я просто пофиксил ваши «exedata» и «Emala» :-). То что вы называете «востребованной работой настоящих Data Engineers» обычно аутсорсят в Индию, Азию или Восточную Европу. Мы в Молдову например :-).

По видимому ваше «обычно в проектах» ограничевается стартапами или лоукост проектами.
Я участвовал во многих больших проектах, где это как раз было крайне актуально.
Более того. Использование Spark оптимально именно когда есть возможность и необходимость «in memory processing». Без этого оптимальнее использовать Kafka, Solace или AKKA...

То есть SLA для processing pipelines вашим серьезным проектам неведомо? Кстати, вы вообще понимаете как Спарк устроен? В чем, например, разница между BHJ, SHJ и SMJ?

Изначально TensorFlow писался на Python. Но когда нас достало писать имплицид классы для связки со Scala, мы подняли «революцию» и получилась версия на Scala. А уже после этого появились версии на c++ и .net. И это уже история.

Я вам даже репо TensorFlow залинкал посмотреть, там справа написан процент разных языков. Мне кажется вы плохо представляете себе что такое TensorFlow в принципе, иначе идея «Изначально TensorFlow писался на Python» в принципе не могла бы родиться.

??? Мы говорим о том, чем занимается Data Engineer.
И говорим про это исключительно в контексте движения Java Engineer в том направлении...
Топик про это. :)

Вот-вот, я и перечислил что нужно знать, чтобы заниматься интересной работой (а не pojo писать) и зарабатывать намного больше, чем 5К брутто.

..непогана спроба... але... Чого не вистачає?

Перше правило формальної логіки: перш ніж про шось говорити — треба дати означення термінів.

напрями розвитку з Java зараз

— а що таке Java зараз?

Так, коли в 1997-му році я починав займатися Java, це була «гарна дорога цяцька», котру наш директор привіз зі штатів... (Тоді воно все було платне!)...

А тепер коли ми говоримо про Java експертайз — ми говоримо про екосистему Java...
І маючи на рівні 15-ти років освіду в Java, я не буду сверджувати, що мною опановано всю екосистему.. :) Та це і не можливо!

Сама екосистема розвивається досить динамічно і постійно відкриваються нові виміри...
JavaSE -> J2EE -> Java SE + POJO + Spring -> Spring beans -> EJB -> Scala -> AKKA + PLAY -> Spring Cloud ... ...Clojure... ... ...
Уявляете які то були якісні стрибки???

От Java. Одне з правил «по замовченню» — «код має бути максимально читабильним»...
І от Scala... чи діє це правило? Так діє. Але «по іншому». Гарний код буде теж максимально читабельним... але для того, хто володіє розумінням специфічними «замовчуваннями» Scala на кшталт імплесітів, монад та т.п. ...
І от Clojure... і тут все читабельно! ...але для де-кого з Java фахівців — то «винос мізку»...

Але ж є проекти де треба все це разом. І один клас написано на Java, а інший на Scala ...і ще рекурсія на Clojure... А збираться все gradle з Groovy чи Kotlin....

Тож,

напрями розвитку з Java зараз

— це не потрібно — бо є де гарно розвиватися в Java...

І тут чітко є чотири різних якісно напрямка, які є розвитком для тих, хто розвивається...

1. Галузевий напрямок.
Фахівець з банківсько-фінансового сектору не те саме, що фахівець з ігрової ідустрії чи соціальних мереж... Тут треба притримуватися одного напрямку і досягати в ньому експертизи...

2. Архітектурний напрямок.
Все це базуєтсья на архітектурі. Вона буває краще чи гірше.
І все це вже на рівні мистецтва... Покращення тут просто безмежне....

3. Інженерний напрямок.
Мало хто з початківців замислюється що ми першим чином не програмісти, а інженери.
І от тут напрямок engineer excellence так само є безмежним.
І чим далі, тим більше тих хто «робить шось на коліні» — а відповідно і вимог клієнтів по engineer excellence — щоб цього не було. І engineer advocacy — вже не новина для тих, хто працює на гарних проектах. І — знову таки — розвиток тут безмежний...

4. Soft skills напрямок.
Гарні проекти — це завжди командна робота. І «вміння робити в команді» — дуже важлива річ. І це таки теж має свої можливості розвитку...
От наша компанія виокремлює шість напрямків розвитку soft skills, а кожний, хто проходить онбоардінг, мусить пройти певні тренінги з тестами на розуміння шости основних принципів роботи компанії. І потім раз в квартал тре звітувати про свій власний розвиток — в цих напрямках також...

..розвитку в цих чотирьох напрямках на найближче життя вистачить кожному... :)

В статті відображено куди можна рухатись далі після Spring’a і інших бек технологій, і не вважати себе ’БОГОМ’, якщо ти щось вже знаєш — це на маю думку головна суть. Технологій сьогодні настільки багато, що не потрібно тільки на них зациклюватись.

Щодо iPaaS, Salesforce не можу нічого сказати, але це досить вузькі напрямки.
Щодо Big Data то тут не все однозначно, Java’и тут бугато, але наприклад для скриптів використовується Python, для ETL — Scala or Java, зважаючи на технологію, але все рівно все залежить від даних і технологій.

Тобто щоб бути хорошим інженером однієї мови мало (і це стосується не тільки Big Data).
У Big Data я б виділив 3 основні мови: (Java, Scala, Python). Також важливим аспектом є робота зі сховищами даних SQL & NoSQL + cloud integration (like AWS, GCP., Azure) + stream-processing frameworks.

Может в Гоу и клоуд инджиниринг?

скриптову мову (JavaScript або Groovy);

seriously, Groovy?

“or” Groovy, again it’s an option

iPaaS (інтеграційні платформи — Mulesoft, Apigee, Dell Boomi)

Идея завязывать карьеру на проприетарных интеграционных платформах, которые используются на 3,5 проектах, мне кажется весьма сомнительной.
Вот дата инжиниринг и облака — другое дело.

тільки от тенденції в data enginiring+cloud більше в сторону python + SQL, ніяк не Java

Я не зовсім погоджуюся. Якшо говорити про інтеграційні платформи, і особливо стрімінгові то Java переважає. Наприклад згадати Flink, GCP DataFlow та багато інших. Часто ці фрейморки стараються підтримувати різні мови програмування, але часто одна з перших — Java, тому там він більш мачурний і т. д. Наприклад то й же GCP DataFlow на Python (принаймні до недавнього часу) взагалі не радили вживати на продакшні, тільки Java версію. Я вже не кажу, що багато самих біг дата стораджів написані на джаві, так що можна подивитися сорс код, і краще розуміти як вони працюють, наприклад Apache НBase, Accumulo

ми говоримо про список технологій чи проектів в реальному житті?)
Моє особисте враження, що зараз тенденції ідуть до проектів не з java стеком, навіть більше, не JVM стеком(не забуваємо про scala). Наприклад, в моїй локації, в більшості вакансій описуються вимоги python+SQL+cloud. І мені здається, що два роки тому була геть зовсім інша ситуація... але вже точно не пам’ятаю.

Я бы даже сказал что стек cloud уже неслабо сместился в GCP/Azure, а Python/SQL в стиле — «не знаешь? Научим!».

там насправді великий ринок і нормальні бабки, але да, таке не для всіх

Подписаться на комментарии