1. Предыстория

В эпоху больших данных стандартизированное управление информационными активами стало необходимым условием для содействия глубокой интеграции Интернета, больших данных, искусственного интеллекта и реальной экономики. Спецификации НИОКР, которые близки к атрибутам бизнеса и учитывают ключевые моменты каждого этапа НИОКР, могут эффективно повысить эффективность НИОКР и обеспечить упорядоченное выполнение работ по НИОКР в области данных. Несовершенный процесс НИОКР снизит эффективность НИОКР и увеличит затраты и риски.

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

2. Процесс разработки данных

С учетом подведения итогов и проведения ежедневных исследований и разработок хранилищ данных процесс исследований и разработок хранилищ данных разделен на следующие моменты:

1. стадия спроса：данные Как менеджеры по продуктам должны реагировать на меняющийся бизнеснуждаться。
2. этап проектирования：данныеменеджер по продукту、Как данныеразвивать комплексную производительность、расходы、эффективность、Качество и другие факторы,лучше организован схранилищеданные。
3. стадия разработки：данные Как быть эффективным разработчиком、Выполняйте работу по кодированию стандартизированным образом.
4. этап тестирования：Как тестировщикам следует точно выявлять проблемы с кодом и риски проекта,Улучшите качество вывода.
5. стадия релиза：Как плавно выпустить в Интернет программы, соответствующие условиям выпуска, со стабильным выводом。
6. Этап эксплуатации и обслуживания：Каким образом персонал по эксплуатации и техническому обслуживанию должен обеспечитьданные Своевременность и стабильность результатов。

Конкретный процесс разработки

1. нуждаться：Обсудить с оперативными продуктаминуждаться。Деловая сторонануждаться Отправить вJIRA,И общался с продуктом.
2. Обзор PRD：обзор продуктаPRDдокумент。
3. Обсуждение технического решения：Лучше всего, чтобы ответственное лицо сначала представило предварительный план.,Затем обсудите это со всеми (это может быть более эффективно, чем прямой мозговой штурм).,Обсудите, исходя из опыта ответственного лица); затем обсудите со всеми.
4. Обзор технического проекта：Обзор дизайна требует тестирования。
5. Принципы проверки дизайна:Совещание по рассмотрению должно основываться на предпосылке, что все в основном согласны с планом проектирования.,документ, который строит планы.
6. Дизайн интерфейса：Сосредоточьтесь на точном описании входов и выходов.。
7. поля дизайна：в соответствии снуждаться Определить поля,и определить полевые показатели и источники сбора данных,Создайте словарь данных.
8. развивать：ветвь,Напишите код. Хорошо создавайте тест-кейсы,Тогда проверьте себя.
9. проверка кода：позвонить на тест и еще одноразвиватьодноклассник,Приведите результаты проверки. Цель состоит в том, чтобы позволить другим учащимся помочь разобраться в логике.
10. тест：данныйтест Отчет,Включает список контрольных точек.
11. Выйти в Интернет：Заранее уведомите об эксплуатации и техническом обслуживании,Подайте заявку на машинные ресурсы заранее,в соответствии с Хороший бизнес-прогнозCPU、хранилище、пропускная способность и другие ресурсы.
12. документ：развивать После завершения,документ записывает процесс и предоставляет описания полей таблицы данных.,Легко провести рефакторинг.

процесс требований к данным

Обязанности каждой роли

Этот процесс направлен на разработку проекта. В начале проекта необходимо уточнить обязанности каждой роли, и они должны взаимодействовать с несколькими ролями. Как разработчику данных вам необходимо координировать действия и взаимодействовать с различными ролями:

• Потребность и оценка продукта разумности этой нуждаться,Может ли существующий технологический стек поддержать эту потребность?,Например: компания хочет создать рынок данных в реальном времени.,Если нет архитектуры хранилища данных реального времени,Нет возможности завершить этот кусок нуждаться. После того, как определились с разработкой,Необходимо координировать ресурсы,Содержит ресурсы развития, ресурсы оборудования и т. д.
• Необходимо оценить целесообразность использования данных с представителями бизнеса и продукта.,Источник данныхразвивать не появился на пустом месте,Необходимо уточнить у бизнес-стороны, могут ли существующие данные поддерживать нуждатьсяразвивать.,Если данные отсутствуют,План извлечения недостающих данных необходимо спланировать отдельно.
• Необходимо самостоятельно оценить техническую осуществимость,Развивание данных может включать передачу данных, синхронизацию данных, ETL, разработку в реальном времени, работу в автономном режиме и т. д.,Оценить возможность представления набора процессов из источников данных в данные.,Например: источник данных, если они выводятся для нескольких мест.,Возможно, придется начать сbinlongполучать、Кафка читал、Синхронизация бизнес-библиотеки、HDFSЧитать и т. д.,вывод данных также может идти в разные места,Например：mysql、hive、ES、Kafka、redisПодождите большехранилище,Прежде чем начинать разработку, необходимо определить весь процесс обработки данных.
• Необходимо определить, соблюдаются ли требования безопасности и соответствия требованиям.,Как обращаться с некоторыми конфиденциальными данными,это очень важный компонент,какданныеразвиватьперсонал,Может быть подвергнуто большему количеству данных,Но какие данные можно отображать, какие данные можно отображать после десенсибилизации, какие данные нельзя реализовать и т. д.,И в процессе обращения данных,Также хочусосредоточиться Безопасность наданного, можно ли его реализовать, можно ли передать и т.д.
• Необходимо синхронизировать логику обработки данных с тестовыми одноклассниками,и добавьте немного логикиSQLруководитьдокументизменять,Студентам-тестировщикам удобно проводить модульное тестирование.,перед отправкой на тестирование,Необходимо самостоятельно протестировать код,Чтобы гарантировать, что код, поступающий в канал выполнения теста, соответствует определенным стандартам качества. В то же время лучше всего разрешить переключение кода в разных средах посредством конфигурации.,Студентам-испытателям удобно проводить тестирование в тестовой среде и предрелизной среде.,После прохождения теста тот же набор кода можно будет использовать напрямую.

1. Прежде чем выйти в Интернет

01. Обзор требований

Обсуждение требований, встреча по рассмотрению требований. Во встрече приняли участие аналитики данных, менеджеры по продуктам и менеджеры по продуктам данных. Определите, нужно ли клиенту или серверу скрывать баллы, и определите, нужно ли студентам скрывать баллы для участия. Если это API данных, такой как интерфейс службы, онлайн-пакет и т. д., студенты-серверы также должны участвовать в собрании. Встреча в основном была сосредоточена на трех аспектах: бизнес-история и преимущества, модель данных и ее согласование, планирование и возможные скрытые опасности и точки риска.

02.Исследование данных

Исследование данных, исследование данных. Источники данных в основном должны быть знакомы с полной связью со скрытыми точками клиента, обнаружением и отслеживанием скрытых точек на стороне сервера, а также с генерацией, анализом и интеграцией binlog данных базы данных. Прежде чем получить проект требования или модели предметной области, проведение исследования данных (исследования данных, сопоставления данных) можно начать со следующих пунктов:

• 1. Величина. Если это данные заглубленной точки,Это позволяет напрямую предсказать, произойдет ли повторная отчетность или занижение отчетности.,Если это дбданные,Это может эффективно оценить интеграцию данных и увеличить объем стратегии извлечения (рекомендуется, чтобы данные базы данных использовали binlog унифицированным образом).
• 2.схема. Значение поля, описание бизнеса,Объяснение значения перечисления,Доля вакантных площадей, единиц и т. д. Обратите особое внимание на,json、Структуры сложных типов данных, такие как struct、ключ и т. д.
• 3. Первичный ключ. Как правило, с первичным ключом базы данных проблем не возникает, но особое внимание следует уделять данным, сообщаемым сервером.
• 4. Последовательность. Например, сторона предложения соответствует стороне потребителя, а сторона B соответствует стороне C.

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

03.Общественная модель

Публичный дизайн и разработка моделей. dwd dws dim общая модель данных, можно ли повторно использовать существующие модели и следует ли закрывать модель. Ориентация на спрос обогащает существующие модели, особенно для некоторых крупных компаний. Если это новый бизнес, вам также может потребоваться разобраться в диаграмме бизнес-процессов, CDM и модели предметной области. Разберитесь с матрицей индексов размерностей и зависимостью модели. Рассмотрите возможность одновременного проектирования нескольких моделей, в том числе конкретных размеров, изменения степени детализации, высокой связности и низкой связанности, а также возможности повторного использования.

В частности, публичная модель запрещает объединение онлайн-бизнес-логики.

04. Модель приложения

Разработка данных прикладного уровня. Относительно просто, но не будьте небрежны. Необходимо учитывать форму воздействия, величину, зернистость, идемпотентность, нужны ли кубики и т. д.

05.Обзор модели

Обзор модели. В дополнение к этому, перед разработкой необходимо провести анализ модели. Он может не только оперативно обнаружить и избежать проблем, которые вы не заметили при проектировании модели, но и позволить другим коллегам быстро разобраться в связанных моделях и бизнесе. Чем больше компания, тем больше ее необходимо пересматривать, даже если это позиция AB.

Кроме того, на работе мы часто сталкиваемся с различиями в концепциях и мыслях моделирования с коллегами и руководителями, или это может быть связано с разными бизнес-перспективами и отправными точками. Это очень распространено и нормально на работе. Если вы столкнулись с этим на работе, не нужно ощущать никакой психологической нагрузки. Можно обратиться к нескольким способам борьбы с этим:

• Душевное спокойствие. Осознайте это эмоциями, двигайтесь разумом.
• Свернуть. Добродетель не соответствует своему месту и занимает свое место.
• Пустой. В уме много всего, а вы просто делаете что-то небрежно.
• раковина. Никогда не привыкайте к этому и бросайте работу.

Конечно, круг очень узок, и однажды мы, возможно, снова станем коллегами, поэтому лучше относиться к этому спокойно и стремиться к лучшему.

06. Стандартизированная проверка

Стандартная проверка. Еще раз проверьте, соответствуют ли конструкция модели, наименование полей, наименование таблиц, производительность, жизненный цикл и т. д. спецификациям.

3. Ежедневная поддержка данных

Помимо разработки на основе проекта, разработчики данных в большинстве случаев сталкиваются с некоторыми временными требованиями к данным, предъявляемыми продуктом, например, с данными о ситуации с продажами, статусе доступа пользователей и т. д. за последние шесть месяцев. поддержка не требуется. Внутреннее сотрудничество может не требовать тестирования. Вместо этого отчет с данными будет предоставляться регулярно или нерегулярно на основе четких показателей данных. Эта часть модели разработки данных относительно проста и быстра, но она также должна быть понятной:

• Очистить шаблон данныхнуждаться, обычную форму заявления нуждаться и т. д.,Цель предоставления поддержки – избежать длительного общения.,Особенно существующий индикатор данных,Просто попросите товар предоставить подробные данныенуждаться,Просто предоставьте данные по шаблону нуждаться. Шаблон выглядит следующим образом:

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

• Уточнить значение показателя нуждаться,Вадокоронуждатьсясведения о поле、статистический период、период изменения и т. д.

4. Внимание

• нуждаться После завершения обзора,Если будут нуждаться изменения или итерации,одинНеобходимо предоставить форму заявки на итерацию/изменение,Или предоставьте JIRA,Избегайте нуждаться, не прослеживаясь.

• Определение некоторых важных показателей,Даже если это написано в документе,Также проверьте товар,Например, для продукта нужны все продажи за последние шесть месяцев.,Затем необходимо уточнить, включает ли этот объем продаж возвраты, рассчитывается ли он исходя из времени транзакции или времени оплаты и т. д. Избегайте несоответствия индикаторов данных,Результатом является вторичная разработка.
• процесс разработки,документ должен быть регламентирован,Дизайн прежде всего в развитии,И при построении системы,Иметь глобальную перспективу,Не ограничен определенным моментом,Дело не в том, что релиз завершен,Даже если все закончилось,Завершение разработки кода — это только первый шаг,Последующая разработка документации, проверка кода, мониторинг данных, оповещения о данных, стабильность и т. д.,Все нужно спланировать в самом начале.
• своевременная обратная связь,В процессе разработки,Неважно, на каком этапе,В ходе проекта прогресс необходимо синхронизировать с фронтендом и бэкендом каждый день.,Избегайте риска задержек.
• Поиск неисправностей,После программы вверх и вниз,Могут быть некоторые ошибки по объективным причинам или по причинам кода.,Планы поиска неисправностей разные.,Но обратите внимание на записи обзоров и неисправностей.,Избегайте появления той же ОШИБКИ в следующий раз.

Определение уровня отказа:

P0 ： 1. Глобальные проблемы затрагивают всех пользователей. Например, система выйдет из строя, и основные функции будут недоступны, что серьезно повлияет на нормальные транзакции пользователей. 2. Проблемы, связанные с потерей средств пользователей. Срок решения: в течение 2 часов. Время обратной связи: 0,5 часа. Метод обратной связи: комментарии по электронной почте + обмен мгновенными сообщениями: например, QQ\WeChat\DingTalk\telephone

P1： 1. Глобальные проблемы, затрагивающие всех пользователей, такие как недоступность мелких функций системы, периодические сбои системы и частота сбоев, превышающая 50%. 2. Локальные проблемы затрагивают более 20% пользователей. Например, основные функции системы недоступны и система неизбежно выйдет из строя. Время решения: подлежит уточнению, не более ночи. Время обратной связи: 1 час. Метод обратной связи: комментарии по электронной почте + обмен мгновенными сообщениями: например, QQ\WeChat\DingTalk\telephone

P2： 1. Локальные проблемы затрагивают 10%-20% пользователей. Например, недоступны второстепенные функции системы или недоступна определенная логика системы, а процент сбоев системы составляет 20-50%. Время решения: TBD 48 часов. Метод обратной связи: автоматическое электронное письмо с комментариями.

P3： 1. Локальные проблемы, затрагивающие менее 10 % пользователей. Например, незначительные функции системы недоступны, часть системной логики ненормальна, а проблемы возникают только у одной модели или пользователя. Время разрешения: будет определено в следующей версии. Метод обратной связи: отражен в следующей версии плана спроса.

P4： 1. Системные текстовые ошибки, ошибки стиля системы, удобство взаимодействия с системой и другие функции, которые не влияют на нормальное использование пользователем. (Включает глобальные свойства) Время разрешения: когда следующая версия появится в сети. Метод обратной связи: отражен в следующей версии плана спроса.