Дані для продукту: як і чому важливо покращувати їхню якість

Мене звати Олексій, я працюю в SoftServe на позиції Data Science експерта і відповідаю за домени рітейл, медіа, рекомендаційні рішення і прогнозування. Вже 15 років я у своїй діяльності так чи інакше зіштовхуюсь з продуктами, що побудовані на даних у різних доменах: фінанси, рітейл і маркетинг. В цій статті я розглядаю питання кількості та якості даних, що може бути цікаво як досвідченим спеціалістам, так і початківцям, якщо вони стикаються із різними даними щодня.

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

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

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

Що таке якісні дані

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

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

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

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

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

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

Довіра до даних і як її побудувати

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

Як можна забезпечити довіру до даних? Загалом, існує два підходи до створення довіри — побудова прозорого процесу опрацювання даних (data governance) і перевірка або легалізація даних, яка може бути як внутрішньою, так і зовнішньою (data profiling and data audit). В загальному, треба концентруватись на обох цих сторонах, але відповідальність лежить на різних особах всередині компанії. Власне, ви можете збільшувати довіру до даних через їх внутрішню легалізацію (data profiling) і перевикористовувати супроводжувальні документи чи дописи, які були створені в рамках опису процесу опрацювання даних (data governance).

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

Одного разу я мав ситуацію, коли у даних, що надходили для аналітики, сьогоднішня ціна на конкретний продукт в магазині розраховувалась як середня ціна за минулий день. Як можете здогадатись, документація була відсутня, і весь прогностичний аналіз, що був побудований на тих даних, довелось виправляти. Вийшла така ситуація: при акційній ціні 100 умовних одиниць ви можете продати 100 одиниць товару, а при акційній ціні 70 — ви теж можете продати 100 одиниць товару, бо перша ціна була ще не акційною і просто записана на майбутню дату. Навіть при відсутності документації ця ситуація могла би бути ліпшою, якщо б ми мали метадані, з котрих побачили б, що ціна на сьогодні була оновлена з самого ранку (але це залежить від деталізації метаданих). І, до речі, в тому самому випадку, ми витратили більше місяця, щоб знайти відповідальних осіб, котрі змогли пояснити, як визначається ціна.

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

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

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

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

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

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

Надаю приклад коду для автоматичного контролю якості даних використовуючи AirFlow (приклад з цього ресурсу):

from airflow import DAG
from airflow.models.baseoperator import chain
from airflow.operators.dummy_operator import DummyOperator
from airflow.utils.dates import datetime
from airflow.operators.sql import (
	SQLCheckOperator,
	SQLValueCheckOperator,
	SQLIntervalCheckOperator,
	SQLThresholdCheckOperator
)
from airflow.utils.task_group import TaskGroup
 
# This table variable is a placeholder, in a live environment, it is better
# to pull the table info from a Variable in a template
TABLE = "yellow_tripdata"
DATES = ["2019-01", "2019-02"]
 
# By putting conn_id as a default_arg, the arg is passed to every task,
# reducing boilerplate
with DAG("sql_data_quality",
     	start_date=datetime(2021, 7, 7),
     	description="A sample Airflow DAG to perform data quality checks using SQL Operators.",
     	schedule_interval=None,
     	default_args={"conn_id": "postgres_default"},
     	template_searchpath="/usr/local/airflow/include/sql/sql_examples/",
     	catchup=False) as dag:
    """
	### SQL Check Operators Data Quality Example
	Before running the DAG, ensure you have an active and reachable SQL database
	running, with a connection to that database in an Airflow Connection, and
	the data loaded. This DAG **will not** run successfully as-is. For an
	out-of-the-box working demo, see the sql_data_quality_redshift_etl DAG.
	Note: The data files for this example do **not** include an `upload_date`
	column. This column is needed for the interval check, and is added as a
	Task in sql_check_redshift_etl.py.
	"""
 
	begin = DummyOperator(task_id="begin")
	end = DummyOperator(task_id="end")
 
	"""
	#### Run Table-Level Quality Check
	Ensure that the correct number of rows are present in the table.
	"""
	value_check = SQLValueCheckOperator(
    	task_id="check_row_count",
    	sql=f"SELECT COUNT(*) FROM {TABLE};",
    	pass_value=20000
	)
 
	"""
	#### Run Interval Check
	Check that the average trip distance today is within a desirable threshold
	compared to the average trip distance yesterday.
	"""
	interval_check = SQLIntervalCheckOperator(
    	task_id="check_interval_data",
        table=TABLE,
    	days_back=-1,
    	date_filter_column="upload_date",
    	metrics_thresholds={"AVG(trip_distance)": 1.5}
	)
 
	"""
	#### Threshold Check
	Similar to the threshold cases in the Row-Level Check above, ensures that
	certain row(s) values meet the desired threshold(s).
	"""
	threshold_check = SQLThresholdCheckOperator(
    	task_id="check_threshold",
    	sql=f"SELECT MAX(passenger_count) FROM {TABLE};",
    	min_threshold=1,
    	max_threshold=8
	)
 
	"""
	#### Run Row-Level Quality Checks
	For each date of data, run checks on 10 rows to ensure basic data quality
	cases (found in the .sql file) pass.
	"""
	with TaskGroup(group_id="row_quality_checks") as quality_check_group:
        # Create 10 tasks, to spot-check 10 random rows
    	for i in range(0, 10):
        	"""
        	#### Run Row-Level Quality Checks
        	Runs a series of checks on different columns of data for a single,
        	randomly chosen row. This acts as a spot-check on data.
        	"""
        	SQLCheckOperator(
            	task_id=f"yellow_tripdata_row_quality_check_{i}",
            	sql="row_quality_yellow_tripdata_check.sql"
        	)
 
    	chain(
        	begin,
        	[quality_check_group, value_check, interval_check, threshold_check],
        	end
    	)

Наступним кроком покращення довіри до даних є їхня внутрішня легалізація.Тут варто виділити три обов’язкових етапи перевірки даних:

  1. Типи даних чи колонки (колонки або «комірки» в таблицях, або ж «змінні», якщо дані мають вигляд не таблиці) мають очікуваний тип даних (наприклад, телефон скоріше очікується текстовим значенням ніж числовим, бо так легше буде перевіряти значення у момент введення клієнтом).
  2. Значення даних — який відсоток відсутніх значень в колонці, чи колонка знаходиться в очікуваних межах (наприклад, ціна і кількість позитивна), кількість унікальних значень у колонці (зазвичай неочікувано бачити більше ніж два унікальних значення у колонці fraud: «correct/not correct»), послідовність у даних (наприклад, якщо в даних ми побачимо відсутність шахрайства у квітні).
  3. Зв’язки між даними — чи є повністю однакові записи, чи повторюються значення ключів-колонок (наприклад, тільки один запис на магазин, товар, дату), які кореляції між колонками, чи пусті значення мають ті самі значення в іншій колонці, як колонки з різних таблиць можуть бути поєднані.

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

import pandas as pd
from pandas_profiling import profilereport
from pandas_profiling.utils.cache import cache_file
 
if __name__ == "__main__":
	file_name = cache_file(
    	"titanic.csv",
    	"https://raw.githubusercontent.com/datasciencedojo/datasets/master/titanic.csv",
	)
    df = pd.read_csv(file_name)
	profile = profilereport(df, title="titanic dataset", explorative=true)
    profile.to_file("titanic_report.html")

Доступність даних — наше все

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

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

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

Клієнт: Чому ви не використовуєте такі-то і такі-то дані — ми витрачаємо купу грошей на їх збір і розраховували покращити нашу аналітику.

Я: До цих даних у вашій компанії доступ можуть мати тільки менеджери вищої ланки і тільки зсередини вашої компанії — тобто на цих даних жодної імплементації навіть всередині вашої компанії зробити не можливо.

Клієнт: А менеджери як їх дивляться?

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

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

Тому моя рекомендація така: коли ми думаємо про дані, важливо не забувати про доступність даних в тому сенсі, що ви маєте можливість відповісти на наступні запитання:

  1. Наявність. Чи має клієнт дані в наявності в будь-якій системі?
  2. Безпечність. Чи ми можемо отримати доступ до тих даних?
  3. Доступність. Чи клієнт може пояснити (чи надати документацію) для того, щоб стало зрозумілим, як опрацювати ці дані?
  4. Відкритість. Які є вимоги до результатів, що ми підготуємо, у плані безперешкодного доступу до даних іншими користувачами на стороні клієнта?

Я хочу навести два приклади в рамках цієї секції для того, аби ви могли зробити ваші результати більш доступними для клієнта. Перший приклад стосується автоматичного пайплайну для зберігання даних в AWS-клауді на AirFlow (взято тут):

from airflow import DAG, settings
 
from airflow.operators.python import PythonOperator
from airflow.utils.dates import days_ago
from airflow.models import DAG, DagRun, TaskFail, TaskInstance
from airflow.providers.amazon.aws.hooks.s3 import S3Hook
 
import csv, re
from io import StringIO
 
MAX_AGE_IN_DAYS = 30
S3_BUCKET = 'my-export-bucket'
S3_KEY = 'files/export/{0}.csv'
 
OBJECTS_TO_EXPORT = [
	[DagRun,DagRun.execution_date],
	[TaskFail,TaskFail.execution_date],
	[TaskInstance, TaskInstance.execution_date],
]
 
def export_db_fn(**kwargs):
	session = settings.Session()
	print("session: ",str(session))
 
	oldest_date = days_ago(MAX_AGE_IN_DAYS)
	print("oldest_date: ",oldest_date)
	s3_hook = S3Hook()
	s3_client = s3_hook.get_conn()
	for x in OBJECTS_TO_EXPORT:
    	query = session.query(x[0]).filter(x[1] >= days_ago(MAX_AGE_IN_DAYS))
    	print("type",type(query))
    	allrows=query.all()
  	  name=re.sub("[<>']", "", str(x[0]))
    	print(name,": ",str(allrows))
    	if len(allrows) > 0:
        	outfileStr=""
        	f = StringIO(outfileStr)
        	w = csv.DictWriter(f, vars(allrows[0]).keys())
        	w.writeheader()
        	for y in allrows:
            	w.writerow(vars(y))
        	outkey = S3_KEY.format(name[6:])
        	s3_client.put_object(Bucket=S3_BUCKET, Key=outkey, Body=f.getvalue())
 
	return "OK"
 
with DAG(dag_id="db_export_dag", schedule_interval=None, catchup=False, start_date=days_ago(1)) as dag:
	export_db = PythonOperator(
    	task_id="export_db",
    	python_callable=export_db_fn,
    	provide_context=True    
	)

А другий приклад — як зробити доступ до результатів задач машинного навчання більш інтерактивним використовуючи фреймворк StreamLit на Python (код взятий звідси).

import yaml
import utils
import streamlit as st
import lightgbm
from sklearn import *
 
mod_class_dict = {"Decision Tree Regressor": tree.DecisionTreeRegressor,
              	"Light Gradient Boosting Machine": lightgbm.LGBMRegressor,
              	"Linear Regression": linear_model.LinearRegression}
 
with open("config.yml", "r") as ymlfile:
	config = yaml.load(ymlfile)
 
# step1: checking the absence of CSV file
st.header("Demand Prediction")
st.write("This application allows to forecast the unit sales of Walmart retail goods ")
uploaded_file = st.sidebar.file_uploader("Upload your CSV file")
if not uploaded_file:
	st.write("Plase, load CSV file to start")
	st.stop()
 
# step2: converting csv file into pandas DataFrame.
df = utils.to_df(uploaded_file)
st.subheader("Data Preview")
st.dataframe(df.head())
 
# step3: environment setup
reg = utils.create_setup(df)
 
# step4: setting parameters
st.sidebar.header("Modeling Preferences")
action = st.sidebar.selectbox("Choose an action", ["Custom Modeling", "Auto ML"])
 
# step 5: modeling
# automl path
if action == "Auto ML":
	st.subheader("Train")
	final = utils.autoML(df)
	predictions = utils.predict_model(final)
	st.subheader("Generate predictions")
	utils.plot(predictions)
 
# custom modeling path
elif action == "Custom Modeling":
	models_chosen = st.sidebar.multiselect("Choose Models to build", ["Decision Tree Regressor",
                                                                  	"Light Gradient Boosting Machine",
                                                                  	"Linear Regression"],
                                       	default=["Decision Tree Regressor"])
	tune_button = st.sidebar.checkbox("Enable auto-tuning hyperparameters")
	final = utils.train(models_chosen, tune_button)
	if len(models_chosen) > 1:
    	model_selected = st.sidebar.selectbox("Choose Models to make predictions", models_chosen)
    	for i in final:
        	if isinstance(i, (mod_class_dict[model_selected])):
            	final=i
	predictions = utils.predict_model(final)
	st.subheader("Generate predictions")
	utils.plot(predictions)

Збільшення значущості та вартості даних

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

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

Наприклад, з початком пандемії COVID-19 з’явились нові збірки даних, котрі треба було порівнювати, і звичайні розрізи по місяцях і кварталах перестали працювати. Гнучкість, самодостатність і легкість — це те, що ми всі хочемо мати при роботі з даними, щоб забезпечити швидкість роботи бізнесу. Але зазвичай це більше працює як «неможливий трикутник» (виберіть 2 з 3-х і тільки так ви зможете працювати, бо 3 з 3-х одночасно неможливі).

На цьому фоні продукти, побудовані на даних, виглядають вже не як щось інженерне для інженерів, а більше як нова парадигма бачення світу, на основі чого будуються нові канали створення вартості, специфічна аналітика і управління даними. Ці продукти відрізняються від дата-активів тим, що тут дані сприймаються не як окрема одиниця, а як код в імплементації програмного забезпечення чи зміст повідомлення в дизайні. Іншими словами, над даними будується окрема екосистема, яка складається з посередників, інфраструктури, споживачів і творців. Дата-продукти іноді ще мають додаткові абстракції поруч: наприклад, дата заводи (data factory), що дозволяють трансформувати дані дуже швидко. Тут різниця полягає в тому, з якої сторони ми дивимось на дані — з бізнесової точки зору чи з боку технічної імплементації (це як заводи і магазини в будь-якому бізнесі, тому використовуються схожі терміни).

Мінімальний життєвий цикл продукту, побудованого на даних, має включати 5 кроків:

  1. Перевірка вартості ідеї — розуміння наявних дата-активів, створення вимог до даних; визначення трансформацій, які можуть зацікавити кінцевого користувача (згадайте першу секцію цієї статі, де говорилось про довіру до даних).
  2. Створення дата-активів — визначення структури вхідних даних; розуміння, як посередники можуть створювати додаткові дата-активи; визначення технічних можливостей до зберігання дата-активів (перша частина цієї статті також згадувала необхідність прозорості процесу опрацювання даних).
  3. Постачання даних — визначення, яким чином користувач буде отримувати доступ до даних; підтвердження бізнес-моделі постачання даних; створення технічних можливостей постачання даних згідно з вимогами (загадайте другу частину цієї статті про доступність даних).
  4. Продукціоналізація даних — організація всієї інфраструктури дата-продукту; створення автоматичних процесів навколо трансформації даних; визначення потенційних точок дотику із користувачами (touchpoints) таких як налаштування, запит, отримання.
  5. Підтримка вартості даних — визначення амортизації дата-активу; побудова моніторингу дата-активу; визначення критеріїв знищення дата-активу чи вимоги на реорганізацію дата-активу.

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

Зберігайте дані тільки один раз. Вхідні дані не мають мати різні місця доступу. Тобто користувач має мати тільки один шлях доступу до будь-яких даних. Зазвичай це має бути океан даних (data lake), де ти будеш шукати будь-які дані. Доступ до даних треба обмежувати, але не за рахунок різних систем зберігання — краще розмежувати ролями в одній системі зберігання даних.

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

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

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

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

Дані мають надходити вчасно. Вчасно — це дуже суб’єктивно, але кінцевий користувач має знати, коли йому очікувати дані. Краще це очікування не порушувати, бо інакше почнуть з’являтись копії даних, що будуть не під вашим контролем. Якщо є вимога опрацювання запиту за хвилину, то треба це зробити. Якщо дані мають бути готові до 7-ої ранку, то не 10 хвилин по сьомій чи щось в такому дусі. Але завжди залишайте простір для помилки, щоб був час на її виправлення. Тобто сконцентруйтесь не на питаннях чи дані ріал-тайм чи ні, а зрозумійте, що таке вчасно для користувача і забезпечте це.

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

Зверніть увагу, що деякі з цих кроків збігаються з процесом управління даних (data governance), який згадувався раніше. Тобто data governance — це перший крок до збільшення вартості ваших даних і його не можна упускати в жодному випадку.

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

from airflow import DAG
from airflow.operators import DummyOperator
from datetime import datetime
 
# DAG definition
my_dag = DAG(dag_id='My_DAG', schedule_interval='* * * * *', start_date=datetime(2020, 1, 2), catchup=False,)
 
# DAG steps
connect_data_source = DummyOperator(dag=my_dag, task_id='connect_data_source')
read_data = DummyOperator(dag=my_dag, task_id='read_data')
data_preprocessing = DummyOperator(dag=my_dag, task_id='data_preprocessing')
 
categorical_feat_transform = DummyOperator(dag=my_dag, task_id='categorical_feat_transform')
numeric_feat_transform = DummyOperator(dag=my_dag, task_id='numeric_feat_transform')
 
finalize_dataset = DummyOperator(dag=my_dag, task_id='finalize_dataset')
 
get_customer_statistics = DummyOperator(dag=my_dag, task_id='get_customer_statistics')
get_store_statistics = DummyOperator(dag=my_dag, task_id='get_store_statistics')
get_mall_statistics = DummyOperator(dag=my_dag, task_id='get_mall_statistics')
 
data_analysis = DummyOperator(dag=my_dag, task_id='data_analysis')
 
save_data_to_s3 = DummyOperator(dag=my_dag, task_id='save_data_to_s3')
save_data_to_db = DummyOperator(dag=my_dag, task_id='save_data_to_db')
save_data_to_storage = DummyOperator(dag=my_dag, task_id='save_data_to_storage')
 
# Define DAG rules
connect_data_source \
	>> read_data \
	>> data_preprocessing \
	>> [categorical_feat_transform, numeric_feat_transform] \
	>> finalize_dataset \
	>> [get_customer_statistics, get_store_statistics, get_mall_statistics] \
	>> data_analysis \
	>> [save_data_to_s3, save_data_to_db, save_data_to_storage]

Підсумовуємо

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

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

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

  1. Маніпулятивні дані, які мають вигляд якісних, але у них присутні дефекти (випадкові чи навмисні), що порушують цілісність будь-якого процесу навколо цих даних. Наприклад, якщо ви включите забагато фейкових новин у свою базу і не зробите їх правильне маркування і фільтрацію, то ваш продукт буде ставити під ризик всіх посередників і всю бізнес-інфраструктуру, що ви розбудували навколо вашого продукту.
  2. Низька якість тестування при побудові дата-продуктів. Таке може відбуватись, бо ми зазвичай не очікуємо, що мінімальна технічна зміна може вплинути на результати у даних, та іноді забуваємо перевіряти послідовність вихідних даних на кожному кроці.
  3. Втрата даних при пересиланні через мережу призводить до змін у вихідних даних, які дуже важко проконтролювати, не будуючи додаткові контрольні порівняння всередині ваших процесів. Наприклад, через технічний збій, замість 100 тисяч записів ви отримали із бази тільки 15 тисяч, опрацювали їх і результати відправили до клієнта.

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

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

👍НравитсяПонравилось10
В избранноеВ избранном5
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Чому СофтСёрв лізе в ДіяСіті — здогадайтеся з нульової спроби.

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

PPS. Зробіть дані зрозумілими. Так легше красти та зливати в мережу. Софтсьорв вірний своїм традиціям!

Свою експертизу ви вже показали. Успіхів у житті.

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

Те що я хотів сказати, то написано у статті.

Олексію, а десь є офіційна позиція СофтСЕрву вже? Поділіться)))

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

Задам питання, на яке ви прямо ніколи не відповісте: Чи виділив вже СС фінанси для виконання дій по вступу до ДіяСіті? Не питайте, звідки знаю, СС не та контора, яка вміє зберігати таємниці.

Олексій напишіть про то статтю і там спілкуйтесь — це стаття про інше. Ваші коментарі, то не повага.

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

Я ж саме так і сказав.

Ви праві, коментувати теорії змови і подібні маніпуляції немає жодного сенсу

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

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

я сказав саме так

Пізнавальна стаття, дякую. Зберіг у закладки

Гарна стаття. Із прикладами.
Особливо тішить, шо стаття написана державною (українською) мовою.
Пишіть ще!

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