До всесвітньої мережі даних

Дані, дані, скрізь …

… заповнений величезною потенційною цінністю для відкриттів у науці, бізнесі та суспільстві.

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

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

Зібрані дані страждають від неповноти вмісту – і я кажу не лише про відсутні значення. Що представляють дані? Чому були зібрані дані? Яким був дизайн / мета? Для кого були зібрані дані та для кого? Які упередження чи особливі умови існують? Зазвичай відсутня інформація про джерело даних зберігається у мозку експертів доменів – тобто конкретних людей. І ці люди рідко перебувають там, де є джерела даних, якими вони володіють або колись належали

Ev’ry джерело даних

чиста, хитромудра сніжинка,

швидко тане.

Старе програмне забезпечення не працює з новими типами даних

Все програмне забезпечення старіє в день надходження.

Програмне забезпечення та алгоритми, створені для виявлення / вилучення значень, призначені для роботи на вихідних даних, структурованих у явному форматі або схемі.

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

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

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

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

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

Це не масштабовано.

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

Це марна проблема даних. Потрібно щось змінити.

Шаблон оформлення у всесвітній павутині

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

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

(Інтернет-програмне забезпечення) поглинає світ.

Що це означає для проблеми марних даних, як описано вище? Зупинимось на п’яти ключових компонентах шаблону дизайну всесвітньої павутини, що сприяли революції в Інтернеті:

Веб-сервери (наприклад, Apache)

Веб-клієнти / браузери (наприклад, Netscape)

HTTP

HTML / JavaScript / CSS

URL-адреси (наприклад, IP-адреси та DNS)

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

Ви можете в одну мить масштабувати свою програму для мільйонів користувачів.

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

Ви можете одразу відвідати та використовувати будь-який з мільйонів веб-сайтів.

Веб-клієнти спілкуються з веб-серверами за допомогою загальної мови: HTTP. HTTP має ряд методів, що дозволяють клієнту робити запити на будь-який сервер. Загальний формат запиту HTTP є універсальним – GET, POST, заголовки, аутентифікація, SSL тощо.

То як веб-клієнт може отримати інформацію з веб-сервера, не знаючи нічого про домен? З шаблоном зворотного виклику, реалізованим у HTML та / або JavaScript.

Після початкового, загального HTTP-запиту від веб-клієнта на веб-сервер, відповідь сервера не лише надає HTML / JavaScript / CSS, який визначає, як виглядає та працює сторінка, визначаються конкретні зворотні виклики серверу – або іншим веб-серверам також вбудований у відповідь.

напр. <a href=·https://tag.biob>>, або вираз AJAX.

Вміст, який доставляється з веб-сервера, повинен належним чином передавати дійсний код HTML і JavaScript, щоб клієнт відображав сторінку та робив зворотні дзвінки – інакше у вас з’являться непрацюючі сторінки та непрацюючі посилання у вашому браузері.

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

Нарешті, шаблон Всесвітньої павутини вимагає універсальної адресної системи, так що коли ви вводите URL-адресу у своєму веб-клієнті (наприклад, https://tag.bio), клієнт буде знати шлях Інтернету для зв’язку з правильним веб-сервером. Цьому сприяє глобальний реєстр адрес в Інтернеті, система IP та глобальний реєстр зіставлення доменних імен з адресами в Інтернеті, DNS.

Чи можемо ми використати шаблон дизайну WWW для вирішення проблеми марних даних?

Архітектура data mesh

У 2019 році Жамак Деггані з ThoughtWorks опублікував натхненну статтю, в якій Data Mesh представлений як запропоноване рішення непотрібної проблеми з даними. З реферату статті:

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

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

Загальна ідея Data Mesh полягає в тому, що джерела даних можна – і потрібно – залишати на місці. Джерела даних повинні розроблятися та застосовуватися як модульні, незалежні продукти даних особами, які найкраще знають домен. Ці особи найефективніше і результативніше зможуть розробляти корисний вміст та функціональність навколо свого джерела даних.

Що це звучить? Сервери всесвітньої павутини. Гаряче блін.

До всесвітньої мережі зібраних даних

Давайте поєднаємо шаблон дизайну WWW з архітектурою Data Mesh і побачимо, як далеко заходить кроляча нора.

Ось що нам потрібно (збігаючись безпосередньо з 5 перерахованими вище компонентами WWW):

Серверна програма – вузол даних – який може обертати будь-яке дане джерело даних / схему, не змінюючи його. Вузол даних буде обладнаний API, який може універсально взаємодіяти з будь-яким клієнтом, а також увімкнути запити та відповіді для конкретного домену – і зворотні виклики додатковим серверним функціям – без викриття схеми вихідних даних. Забезпечення незалежності клієнта від схеми вихідних даних є критичним для масштабованості цього шаблону, тому що, якщо повинна змінюватися схема вихідних даних – що відбувається постійно – потрібно було б налаштувати лише вузол даних, а не кожну клієнтську програму gall-dang .

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

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

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

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

Чому це важливо

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

Деякі ключові переваги:

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

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

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

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

Модульний дизайн, керований доменом – масштабований та корисний!

Що порталу даних потрібно запитати вузол даних

Які у вас дані? Коли воно востаннє оновилось?

Які методи ви пропонуєте?

Які аргументи для даного методу?

Для аргументу методу, який дійсний набір / діапазон значень?

Що є для даного методу схемою / кодуванням відповіді?

Будь ласка, запустіть цей метод із цими аргументами.

RESTful та асинхронне опитування на основі токенів (для тривалих методів).

Припущення та міркування

Портал даних не знає явної схеми даних за кожним вузлом даних. Він знає вузол даних лише за переліченими вище питаннями. Це дозволяє вузлу даних пристосовуватися до змін схеми даних, не порушуючи кожного клієнта API.

Як опубліковано в статті Data Mesh – вузли даних повинні бути незмінними. Отже, стан / сеанси клієнта повинні підтримуватися додатковим компонентом. Якщо портал даних або алгоритм викликає перетворення даних у вузлі даних, він повинен створити / розгорнути новий вузол даних.

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

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

Чи повинні вузли даних дозволяти виконання віддаленого коду, поданого з порталу даних або через API? Це потужний варіант, але він представляє величезний ризик для безпеки, який страждав від світової світової війни в минулому, – обережно ступайте.

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

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

Глобальний реєстр вузлів даних – і самі вузли даних – повинні дотримуватися принципів FAIR.

Який вплив це може мати? які припущення потрібно перевірити? залиште коментар нижче.

Для нашої власної реалізації цієї моделі відвідайте Tag.bio.

І якщо ви читали це далеко, але ще не перевірили статтю Data Mesh від ThoughtWorks, зробіть це зараз.

Мільярди і мільярди,

іскристі зірки з їхніми секретами;

Карл мріяв: “Я повинен знати!”

Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/towards-world-wide-web-data-jesse-paquette/.

Jesse Paquette люб’язно дозволив нам перекласти і опублікувати цю статтю.