Повече от думи: Хвърляне на светлина върху бъркотията с терминологията на данните

Имаме нужда от XYZ. Определено. Има го във всички доклади на анализатори, тенденцията е извън класациите и нашите конкуренти също го имат. Така че нека намерим продавач, който го има, и да инвестираме. Това трябва да го направи.

Звучи ли ви познато? Надяваме се, че решенията за технологични инвестиции във вашата компания не се вземат по този начин. Но тъй като технологията се развива по-бързо от всякога, е трудно да се следи цялата терминология. За съжаление, някои хора гледат на терминологията като на замъгляващ слой, който има за цел да прослави онези, които я измислят, да рекламира продуктите и да накара хората, които хвърлят термини, да изглеждат умни.

Може да има известна истина в това, но това не означава, че терминологията е безполезна. Напротив, терминологията е там, за да отговори на реална нужда, която е да опише възникващи концепции в бързо развиваща се област. В идеалния случай споделеният речник трябва да улесни разбирането на различни концепции, пазарни сегменти и продукти.

Пример: управление на данни и метаданни. Чували ли сте преди термините управление на данни, възможност за наблюдение на данни, структура на данни, мрежа от данни, DataOps, MLOps и AIOps? Но знаете ли какво точно означава всеки от тях и как са свързани всички? Ето вашия шанс да разберете.

Слоеве данни

Въпреки че сме активни като анализатори в по-широкия пейзаж на данните, ще признаем, че не всичко от гореизброеното също ни беше напълно ясно. Така че, когато се срещнахме с Maarten Masschelein и Tom Baeyens, решихме, че ще поискаме тяхното представяне. Masschelein и Baeyens са съоснователи на Soda, стартираща компания, която току-що спечели отличието „Готин доставчик в управлението на данни“ от Gartner.

Освен че са официално обявени за готини, има още една причина, поради която може да знаят нещо или две: били са наоколо. Masschelein беше служител номер пет в Колибра, който, по думите му, беше първият, който продаваше софтуер на Chief Data Officers - преди това дори беше нещо. Baeyens беше основател и ръководител на проекта jBPM, легендарен проект с отворен код за управление на бизнес процеси (BPM).

Да започнем с тъкан за данни. Masschelein вижда това като рамка за организиране на данни за мащаб - мета-слой за достъп до всички данни, свързани с организацията, където и да се намират, по унифициран начин.

Платформата за данни се фокусира върху технологичния аспект на този унифициран достъп до данни.

Мрежа за данни е подобна концепция, но различна в смисъл, че се фокусира върху организационните аспекти. Masschelein открива, че мрежата от данни е подобна на модернизирана версия на принципите за управление на данни, приложими за по-широки екипи за данни. Целта е да се структурира и организира, като се премахнат някои от миналите тесни места, като например разчитането на екип за съхранение на данни. Masschelein каза:

„С мрежата от данни основно става дума за изграждане на продукти за данни и услуги за данни. Така че това е мислене за продукти с данни. При управлението на данни говорим за управление на данните като актив. Когато говорим за управление на данни като продукт, това е по-специфично в крайна сметка. Идеята е, че трябва да имаме основни платформени услуги. Но на всичкото отгоре трябва да имаме структура около домейни с данни, области, бизнес, опит и знания, позволявайки им да се обслужват сами. Мисля, че това е ключът".

Управление на данни, Масшелайн добави, е термин, който съществува вече много десетилетия. Той е подробно описан от асоциация за управление на данни, който свърши много работа около това как трябва да се управляват данните. В крайна сметка, част от това беше управлението на метаданни, което създаде софтуер за каталогизиране на данни и възможности за родословие на данни.

Masschelein вижда мониторинг на данни, наблюдаемост на данните, и тестване на данни като специализирани поддомейни на управление на качеството в рамките на по-широката рамка за управление на данни. Baeyens добави контекст относно наблюдаемостта на данните:

„Имате инженери, които изграждат тръбопроводи за данни. Те подготвят данни, които да се използват в продукти за данни, като модели за машинно обучение. Има куп инженери, които редовно разработват нови продукти. След като тези продукти влязат в производство, това е мястото, където започва наблюдението. Това е мястото, където данните всъщност могат да се объркат. Ако моделите, използващи данните, не забелязват, че данните са лоши, това води до всякакви много скъпи и опасни последици".

Мониторинг на данни, тестване, годност и сътрудничество

Що се отнася до DataOps, става въпрос за използване на възможности, свързани с данни, организирани в процеси на най-добри практики за доставяне на продукти с данни с нарастваща скорост, всичко това с повишена надеждност. Много малки процеси трябва да бъдат въведени и стандартизирани, за да се даде възможност за по-добра работа с данни, подобно на това, с което направихме DevOps в софтуерното инженерство, каза Masschelein.

MLOps, който изглежда се използва взаимозаменяемо с AIOps, разчита на добра основа DataOps, но е по-специализиран. В DataOps няма да наблюдаваме точността на прогнозите, например. Това е специфично за продукта с данни и също така специфично за жизнения цикъл на продукта с данни. Masschelein мисли за това от гледна точка на жизнения цикъл:

„Това са две отделни неща, защото жизненият цикъл на набор от данни не е тясно свързан с жизнения цикъл на машинното обучение или продукт с данни, в крайна сметка. Има и различни хора, които го правят. Когато става въпрос за управление на данни и DataOps, ние имаме производители на данни, които могат да бъдат външни за организацията, а вие имате вътрешно генерирани данни.

Друг начин за разглеждане е пейзажът на инструментите. И ако погледнете стека от софтуер за мониторинг и наблюдение, ние имаме инфраструктура на дъното. Така че първо пишем приложения, а след това днес използваме данни и машинно обучение като два вида нови слоеве".

Ние едва започваме със софтуер и платформи, за да помогнем за наблюдението на тези сравнително нови слоеве, докато другите съществуват от много по-дълго, отбелязва дуото. И тук влиза в действие собствената платформа на Soda. Името идва, защото основателите харесват идеята за мълчаливи проблеми с данните, които се появяват като газирана сода. Така че содата обхваща мониторинг, тестване, годност на данните и сътрудничество.

Мониторингът е за автоматично наблюдение на набори от данни за проблеми. Това означава да се опитате да разберете дали има нещо необичайно в наборите от данни, които попадат във вашата среда. Например, приблизително колко записа обработихте този път? Това ненормално ли е в сравнение с това, което имаше в същия ден миналата седмица? Soda може да използва машинно обучение, за да забележи аномалии, например.

Но мониторингът обхваща само малък процент от видовете проблеми с данните, които можете да имате. Ето защо тестването и валидирането на данни е следващата стъпка. Това е мястото, където давате възможност както на инженерите по данни, така и на експертите по темата. Това е мястото, където могат да бъдат посочени правила като „Можем да имаме само X процента липсващи данни в тази колона“, „Нуждаем се от референтна цялост“ или „Допустим набор от стойности“.

Всичко това е добре, но ако имате система за откриване на проблеми с данните, тя ще създаде много предупреждения, така че въпросът е: Как се справяте с предупрежденията? Какъв е бизнес процесът, през който преминавате? Това е мястото, където идват таблата за управление на данните. Това позволява проследяване на SLA, като дава на собствениците на данни поглед върху всички очаквания относно данните в цялата организация и работен процес около разрешаването на проблеми.

Не на последно място, сътрудничеството е междусекторна загриженост. Наличието на функции за сътрудничество позволява на хора с различни познания за проблема, които често имат мълчаливо, недокументирано знание, да работят заедно и да разрешават проблеми. Baeyens спомена, че това засяга и функции, които традиционно не се смятат за сътрудничество, като например даването на възможност на анализаторите сами да управляват знанията за домейна без участието на данни инженери.

Пяна и сода

Експертният опит в BPM, който Baeyens внася в Soda, е използван при изграждането на платформата, по-специално в това как различните модули се вписват заедно в прогресията на работния процес. Soda работи с SQL източници и интеграцията на Spark е почти там. Целта е да можем да покрием възможно най-голяма част от пейзажа на данните.

Содата може да не покрива всички ключови стълбове на цялостна структура от данни според определението на Gartner, но от друга страна, трудно е да се измислят много решения, които го правят. Той обаче увеличава каталозите с данни, като се фокусира върху DataOps. Освен това содата е насочена към различни потребителски сегменти и това се отразява и в нейното предлагане.

Има слой с отворен код, насочен към инженерите на данни. Baeyens вярва, че потребителският сегмент не е непременно заинтересован от предлагане на SaaS. Soda SQL с отворен код има за цел да бъде прост и да работи с технология, която целевата му аудитория обича да използва -- SQL и YAML, според Baeyens.

Soda SQL бележи добър растеж и приемане и това е начин хората да се запознаят със Soda. Въпреки това, ако харесват това, което виждат и нуждите им нарастват, за да включват хора като анализатори и CDO, тогава е време да преминат към платената, SaaS версия на Soda.

Компанията наскоро получи 11,5 милиона евро от Серия А финансиране, което, комбинирано с предишното им начално финансиране, дава общо около 14 милиона евро. Това би трябвало да осигури на Soda добра писта за развитие на предлагането си, с цел да разшири както инженерния, така и екипа за излизане на пазара.

Основателите на Soda изглежда добре разбират пейзажа, в който работят, ако не друго.