Un ejemplo de especificación de desarrollo de una plataforma de big data

uno, antes

El contenido incluye, entre otros, los requisitos internos y externos de la plataforma, desarrollo de código, pruebas y especificaciones de procesos en línea.

Desde la perspectiva de la arquitectura de la plataforma de tecnología de big data, clasifique los ejemplos normativos de cómo cooperar con los estudiantes de análisis de datos y almacenamiento de datos, solo como referencia.

2. Información medioambiental

En primer lugar, es necesario clasificar información como el método de implementación, el host y la versión de cada componente, para que otras plataformas, almacenes de datos o estudiantes de análisis de datos puedan comprender la implementación de la base de la plataforma.

3. Proceso de demanda

3.1 Proceso principal

El proceso principal de la demanda general es el siguiente.

3.2 Inicio de la demanda

3.2.1 Iniciador de demanda

Incluyendo pero no limitado al siguiente personal.

• Desarrollo de almacén de datos
• análisis de los datos
• producto de datos
• Insiders (excavación activa)

3.2.2 Tipo de requisito

• Requisitos comerciales: requisitos comerciales que deben ser respaldados por componentes, como el desarrollo de scripts de aplicaciones.
• Requisitos funcionales de los componentes: extensiones funcionales de los componentes, como la expansión del conector o la construcción de ruedas.
• Requisitos de errores de componentes: los errores causados ​​por defectos de diseño de componentes o defectos de versión deben resolverse en combinación con la comunidad y el código fuente.

3.2.3 Canal de demanda

• Tapd/DevOps/Zen Tao (plataforma de gestión de colaboración)
  • Principalmente para requisitos de errores de componentes, como la dirección de envío: Plataforma de datos_Resumen de errores en línea
• Feishu/DingTalk/Enterprise WeChat (plataforma de oficina empresarial)
  • Principalmente para preguntas/necesidades urgentes e importantes, la retroalimentación se puede hacer a través de DA (grupo de ingreso de demanda de datos), grupo de preguntas o chat privado (se permite el chat privado/trabajo privado, pero se requiere comunicación interna para evitar información deficiente ). se registrará en Unified Anchor: nuevo registro de emisión de clúster
• comunicación fuera de línea
  • Los requisitos complicados se pueden comunicar fuera de línea y es necesario desmontarlos y confirmarlos, por ejemplo: registros de requisitos del almacén de datos.

3.2.4 Persona de atraque a demanda

Si el equipo aún se encuentra en una etapa inmadura de desarrollo, no se recomienda adoptar el método de [ persona de acoplamiento unificada ], y se puede adoptar la estrategia de [ un maestro y varios esclavos ], es decir, excepto el líder del equipo. Otros miembros pueden ser la "persona de acoplamiento de requisitos", pero no importa quién sea la "persona de acoplamiento de requisitos", es necesario registrar la demanda en el [grupo de requisitos] para evitar información deficiente.

• jefe del equipo
• Propietario del componente
  • La dirección (soporte técnico/Preguntas y respuestas) de cada componente debe designar al primer responsable y al segundo responsable.
• grupo de demanda
  • El registro de requisitos evita la pérdida de requisitos y ayuda a establecer un rastreo claro de los requisitos.La lista de registros del grupo de requisitos: Big Data Platform Requests Pool

3.3 Procesamiento de la demanda

3.3.1 Evaluación Interna

• Para requisitos pequeños que se pueden responder y procesar rápidamente, se pueden omitir este paso y el proceso posterior. Por ejemplo, Doris tiene el problema de fallas de lectura y escritura debido a una gran cantidad de memoria SQL.
• Para las necesidades que no se pueden responder y procesar rápidamente, la persona en el muelle debe organizar reuniones intermedias para realizar evaluaciones internas, como actualizaciones de Doris.
• Elementos a confirmar en evaluación interna
  • Si la demanda es razonable y si se requiere un procesamiento de seguimiento
  • Priorizar las necesidades
  • Especifique quién debe ser atendido

3.3.2 Planificación y programación

• Programación por parte de los manejadores de la demanda de acuerdo con la prioridad de la demanda y retroalimentación al personal interno y externo relevante.

3.3.3 Revisión del esquema

• El procesador de demanda genera el plan, y la forma del plan puede ser en forma de lista, declaración 123, diagrama de flujo o documento.
• Para requisitos/proyectos complejos, el resumen y las soluciones detalladas se pueden generar sucesivamente, como la necesidad de un middleware de desarrollo propio o una base de sistema de aplicación, etc.
• Organizado por gestores de la demanda, el método de revisión se puede llevar a cabo en forma de asientos o reuniones.
• Deben ser dos o más participantes, dependiendo de las necesidades, si es necesario traer al iniciador

3.3.4 Entrega del desarrollo

• El desarrollo, pruebas y entrega se realizan según el tiempo previsto, si es necesario priorizar otros asuntos urgentes se pueden posponer mediante coordinación.
• El proceso específico se refiere al siguiente [ proceso de desarrollo ]

4. Proceso de desarrollo

Incluyendo el proceso de desarrollo, prueba y lanzamiento.

4.1 Desarrollo

• Si existe un esquema o diseño de esquema detallado (diagrama de flujo), se debe seguir estrictamente
• Desarrollar de acuerdo con el cronograma y brindar comentarios sobre el progreso cada semana o cada dos días para evitar lagunas de información.
• Para herramientas públicas y API, se puede establecer un almacén maven privado para una gestión unificada
• Si el programa desarrollado no pasa la prueba, es necesario reelaborarlo inmediatamente para reiniciar el proceso de seguimiento.

4.2 Revisión del código

• A medida que pasa el tiempo, aumentará la cantidad de código de desarrollo, como transformación de componentes, scripts o API, y se debe prestar atención a la revisión del código.
  • Facilitar un clima técnico dentro del equipo.
  • Mejore la calidad del código y unifique las especificaciones
  • Evite el fenómeno de la "obsesión por la autoridad" y la "fabricación repetida de ruedas"
• El enlace cr requiere una cierta cantidad de tiempo, por lo que el tiempo cr debe incluirse en la programación.

4.3 Pruebas

• Es necesario generar los casos de prueba correspondientes, que incluyen, entre otros, autoprueba, depuración conjunta, verificación de escenarios y prueba de presión de lectura y escritura, etc.
• La forma de los casos de uso no está limitada y se puede generar en forma de listas, 123 declaraciones, diagramas de flujo o mapas mentales.

4.4 Lanzamiento

• El proceso en línea debe seguir las [ Especificaciones de Operación y Mantenimiento ]
• Los cambios relacionados con el contenido de los componentes (corrección de errores, ajustes de parámetros, actualizaciones y reinicios de componentes, etc.) deben anunciarse con antelación.

4.4.1 Ejemplo de aviso de actualización

[喇叭][喇叭]【Doris Be2.0升级通知】
@人员 
变更时间：2023-08-08 12:12 至 2023-08-08 13:13
变更类型：BE滚动升级
变更版本：1.2.6-release升级至2.0-roc3
变更内容：仅升级BE
变更原因：
1. 引入workgroup和倒排索引等2.0新特性
2. 使用新优化器提升整体查询效率
3. ......
测验结果：升级前测试报告
回滚策略：无
预计影响范围：doris上游任务可能会存在闪断

4.4.2 Ejemplo de anuncio de sintonización

[喇叭][喇叭]【Dolphinscheduler调优通知】
@人员 
变更时间：2023-08-08 13:13 至 2023-08-08 14:14
变更类型：调优重启
变更内容：
1. datasource调整为druid
2. 默认连接大小由50调整为100
3. 新增ldap模块，ds登录改为sso账号密码登录
预计影响范围：所有ds调度任务（重启后自动重试）

4.4.3 Ejemplo de anuncio de reinicio

[喇叭][喇叭]【Doris Be紧急重启通知】
@人员 
变更时间：2023-08-08 00:00 至 2023-08-08 01:01
变更类型：重启
变更内容：无
变更原因：进程假死
预计影响范围：doris上游任务可能会存在闪断

4.4.4 Ejemplo de anuncio de finalización

【XXX完成通知】
完成时间：2023-08-08 08:08
完成结果：升级完成/调优完成/重启完成
完成说明：顺风顺水顺财神

5. Especificaciones de desarrollo

5.1 Base de datos

• rechazar seleccionar *
• Todas las tablas deben ser comentadas.
• El nombre de la biblioteca/tabla temporal debe tener el prefijo tmp_employment número
• Seleccionar diseño paradigmático o antiparadigma según requerimientos
• Los campos reservados están prohibidos para nombres de bibliotecas, nombres de tablas y nombres de campos.
• Los nombres de bibliotecas, nombres de tablas y nombres de campos deben usar letras minúsculas y estar separados por guiones bajos.

5.2 JAVA

Para obtener más información, consulte la especificación de codificación Ali Java.

5.2.1 Denominación

• Los nombres de clases utilizan el estilo UpperCamelCase, excepto en los siguientes casos: DO / BO / DTO / VO / AO / PO, etc.
• Los nombres de las constantes están todos en mayúscula y las palabras están separadas por guiones bajos, para que la expresión semántica sea completa y clara, y no crea que el nombre es demasiado largo.
• Los nombres de métodos, nombres de parámetros, variables miembro y variables locales usan el estilo lowerCamelCase y deben seguir el caso camel.

5.2.2 Constantes

• No permita que ningún valor mágico (es decir, constantes indefinidas) aparezca directamente en el código.
• Cuando se asigna inicialmente long o Long, use L mayúscula en lugar de L minúscula. Las minúsculas se confunden fácilmente con el número 1, lo que provoca malentendidos.

5.2.3 Notas

• Comente el código con moderación; elabore lo anterior, no simplemente comente; elimínelo si no es útil
• Los comentarios sobre clases, atributos de clase y métodos de clase deben utilizar especificaciones Javadoc; no se permiten los métodos /* contenido /formato y // xxx

5.3 estrategia de Git

• Dirección de Gitlab: https://git.xxx.com/
• Contraseña de la cuenta de Gitlab: doris/doris

5.4 Revisión del código

• La CR debe realizarse antes de la prueba o debe realizarse de forma sincrónica
• Realice cr para cada solicitud de fusión, es decir, mr es cr, para evitar la acumulación de mr
• Durante cr, el diagrama de flujo principal del código se puede generar primero, lo que obtendrá el doble de resultado con la mitad de esfuerzo.
• Revisión privada para pequeñas necesidades.
  • 2 ~ 3 personas pueden ir a la computadora para revisar
  • Hable sobre los requisitos primero y luego revise
• Revisión de la reunión del proceso central
  • El proceso de revisión principal, para que los participantes estén familiarizados con el proceso.
  • En segundo lugar, revise el código central y el contenido relacionado con la configuración.

Este es el final del intercambio de ejemplos de especificaciones de desarrollo de plataformas de big data. Si encuentra algún problema durante el proceso de revisión, deje un mensaje para intercambiar.