数据类产品设计和实现思路

声明

个人原创, 转载需注明来源 https://www.cnblogs.com/milton/p/16216347.html

数据类产品

对数据类产品(或服务)的需求是信息化发展到一定阶段的必然产物, 在信息化时代, 现实世界的大部分活动都已经(或即将)被投射成数据, 在这个大背景下, 数据产品的作用也越来越大.

• 对于所有个体, 大至一国政府, 小至个人, 对内的数据收集, 数据治理, 对外情报收集和分析, 知己知彼才能形成竞争优势
• 对于政府, 各个职能部门天然存在对实时数据的需求, 对环境, 卫生, 经济, 金融, 教育, 制造等各行业的统计分析, 问题预警和政策制定都离不开数据. 使用数据系统可以避免中间人修饰, 提高决策准确性和速度. 对于政府的执行单位, 使用数据产品降低监管成本, 避免人为的不确定性, 将监管常态化, 与上下游机构和行业企业的报告交叉验证, 出现问题能快速预警, 及时修复.
• 对于企业, 一部分企业的业务本身就是构建在数据之上, 像金融新闻广告游戏娱乐, 数据和速度是天生的需求, 另一部分企业的业务与数据没有直接关联, 但是在企业的生产过程中, 通过数据产品可以提升效率, 提高企业的竞争优势; 对于关系国计民生的行业, 企业为了符合监管政策, 也会产生对数据产品的需求.

2B的数据产品的用户为企业, 政府, 或科研机构，提供数据治理, 数据仓库, 数据挖掘, 智能决策等服务. 受限于当前的技术, 以及不同行业不同角色之间的差异, 没有通用于所有业务场景的数据产品服务商, 数据产品需要根据不同业务场景的需求制定解决方案. 像SAS这样的市场前排产品, 也是通过不同的行业套件保持竞争优势.

业务场景拆分

从场景上, 可以分为

• 应对监管需求, 对自身业务的数据进行抽取和处理, 部署监管要求的规则, 生成符合监管要求的报告
• 科研类场景, 对线上线下采集的数据进行收集, 分析和验证
• 广告推荐类产品, 根据数据进行决策
• 金融风控, 反洗钱, 打分, 决策, 预警等
• 工业自动化, 配合ERP, MES, IOT等系统进行数据的进一步分析和报告

不同的数据状态, 可以分为

• 静态数据分析, 一般针对日志, 交易流水等存量信息进行事件分析, 用于周期跑批, 问题复盘, 案件调查等业务场景
• 动态数据分析, 数据对象为实时的日志, 交易流水, 传感器记录等, 常用于业务监控和自动化, 例如网络安全的预警, 拦截, 交易的拦截, 风险预警等业务场景.

功能模块拆分

从功能上可以分为以下几个模块:

• 输入适配
• 建模转换
• 分析处理
• 输出适配
• 行业套件

所有的数据产品, 都会由这些功能组成, 只是侧重点不同. 例如 SAS/ACCESS 侧重于输入适配; SAS/Warehouse Administrator 是典型的ETL工具, 侧重于建模转换; SAS OLAP Server(前身是SAS MDDB Server)属于BI工具, 侧重于分析处理, 而 SAS/STAT, SAS/GHAPH, SAS/QC, SAS/IML 这些都是贯穿于整个产品使用过程的功能组件, 在这些模块的基础上, 通过 SAS/QC, SAS/ETS, SAS/OR, SAS/ITSV, SAS/GIS, SAS/CFO Vision 这些行业套件为客户提供服务.

下面对各模块分别说明

1. 输入适配

数据输入相当于ETL中的E部分, 是整个系统的数据入口. 数据输入模块通过内建的或用户自定义的规则, 将原始数据接入处理系统. 数据输入是对产品性能和用户体验影响很大的一个模块.

数据输入主要分为以下几部分内容

接口适配

• 数据源适配, 常见的传统关系型数据库 Oracle, DB2, SQL Server, MySQL, PostgreSQL, 以及 MongoDB, Redis, Hive, Clickhouse, TIDB 等新型数据库, 以及 Spark, Kafka 等消息数据库
• 文件系统的适配, 文件解压缩, 解密处理
• 各种文件格式的解析, 例如CSV, Excel, Access, log等
• 被动接收接口, 提供数据接口, 接收第三方系统推送的数据并正确解析
• 数据采集, 通过内建工具或用户自定义工具主动采集数据

格式适配

• 行数据, 传统的关系型数据主要使用行数据
• 列数据, HBASE等列数据库
• 地理数据, 二维, 三维坐标数据
• 文本数据, HTML, XML, JSON 这类非结构数据
• 允许用户自定义格式

数据存储

• 对于读取频次较低, 或逻辑较为简单的数据规则, 可以直接从数据源读取数据进行处理
• 对于读取速度较慢的数据, 需要频繁读取的数据, 可以将数据缓存在本地, 方便后续环节处理

预处理

在数据层面对读取的数据进行清洗, 筛除或替换无效的值, 以及做一些基础转换. 这一步与模型转换的区别, 在于是否与业务逻辑有关. 原则是去除无效信息, 但是尽可能保留源数据的信息.

第三方数据导入

从第三方接口获取数据, 如征信接口, 高风险IP和地区名单等

技术面分析

数据输入部分, 涉及的技术实现主要包含以下几部分

接口适配

• 不同数据源(传统数据库, NoSQL, 图数据库)的数据抽取接口
• 文件类型数据的读取, 压缩文件的解压
• 安全和隐私相关的验签, 解密, 脱敏
• 屏蔽数据源中的故障和脏数据
• 便于扩展新的数据源, 数据格式
• 使数据系统适用于更多的业务场景, 避免过早遇到功能或性能瓶颈

数据存储机制

• 面向不同场景的需求, 用于存储结构化, 半结构化和非结构化的数据, 需要满足分析模块对数据容量, 访问速度的要求
• 提供MB级到PB级的数据存储方案, 实现对不同体量的数据的存储, 并保证数据存取速度, 保证数据的完整性和安全性
• 对高速率数据的接收能力, 类似双十一这种峰值每秒百万交的数据接收, 如何保证高效且不丢失数据

数值类型和数据格式处理

• 定义基础数值类型, 并在基础数值类型上扩展(或组合)出有实际意义的数值类型, 对输入的数据需要有一定的自动识别能力.
• 对常见格式的自动识别和处理, 例如CSV, Excel, Access
• 对非行结构数据的识别, 例如HTML, XML, JSON等
• 对非结构化数据的识别, 例如新闻内容, 聊天记录等
• 对二进制数据, 常见媒体格式的处理, 图片格式, 视频格式, 流媒体解析(和存储)

预处理和错误处理

• 简单的过滤逻辑, 例如数值校验, 脏数据清理, 重复数据的判断和清理
• 基本的路由规则, 将数据分发到不同的流水线
• 数据源日志记录
• 监控数据源错误率, 适当发出预警

这部分的开发量比较大, 完整覆盖是不可能做到的, 只能针对性的覆盖业务相关的数据接口和类型范围. 根据项目及业务的领域不同, 定义不同的覆盖面, 确定性能指标.

2. 建模转换

数据建模和转换是原始数据和分析处理之间的桥梁, 属于ETL的T和L部分. 建模转换的职能主要有

模型定义

模型定义是分析和处理的需求, 不同的分析处理, 需要的数据输入格式, 质量和数量都会不同, 这些会体现在模型定义上. 例如对于证券分析, 对于股票有不同时间单位的价格, 3秒, 5秒, 1天, 5天, 对每个时间单位有高值, 低值, 开盘, 收盘等不同价格, 只有满足这些数据字段和格式, 才能进行后续的数据分析处理. 只有数据真实有效, 才能得出有意义的结果.

这部分功能和行业套件是相关的, 除了通用的基础模型外, 都是行业套件中的模型定义. 当数据导入后, 需要对数据数值和格式进行判断, 推荐最接近的模型.

数据管理

数据管理的功能在于给用户提供一个数据的管理手段, 让用户可以用命令行或图形界面操作数据集, 为后续的建模和分析做好准备工作

1. 数据分组, 分类
2. 数据单元的命名, 删除, 复制, 移动,
3. 数据单元的抽取, 切割, 合并
4. 数据的标签管理
5. 查看数据, 这里会涉及数据可视化的一些功能
6. 数据的单个编辑和批量编辑

模型识别和映射

根据输入的数据, 计算与系统中各模型的匹配度, 推荐最接近的模型, 匹配度计算分两个因素

1. 带元数据的数据(例如表格字段定义, excel表头等), 可以根据字段标识文本进行计算
2. 不带元数据的数据(例如不带表头的csv, 未知来源的日志等), 需要对数据的实际数值进行分析, 计算其最接近的数据类型, 与各模型中的相似字段进行比对

实现机制

1. 文本匹配, 使用关键词或正则, 需要行业经验和人工设置规则, 配置简单, 效果明显. 缺点是需要行业知识, 配置不好效果会比较差.
2. 算法聚类, 贝叶斯, SVM或神经网络, 综合已知的数据结构提取特征量, 使用机器建模对不同数据格式进行学习分类, 方法是通用的, 需要结合客户的实际场景, 配合人工结果进行持续训练, 使其达到更好的匹配效果.
3. 用户手工指定. 对于匹配失败的数据, 需要用户手工匹配

数据转换

数据转换用于将原始数据适配至模型输入

1. 基础转换规则的管理
   • 基础计算, 例如从英制距离转为公里, 从日期文本转换为时间戳, 或者人民币按当时的浮动汇率转为美元
   • 字符串操作, 替换, 子串, 提取等
   • 聚合操作, 按指定的属性进行聚合, 并提取指定字段的聚合计算的结果
   • 字典转换, 根据预设字典表进行查表转换
   • 与其他数据集的联合转换
2. 接口形式的数据转换和扩充, 例如使用第三方接口从文本中提取关键词, 提取热词, 从IP扩充出地理信息等
3. 规则管道的管理, 使用多个规则, 按条件组合, 用于复杂的数据转换

技术实现

数据的建模转换涉及的技术实现主要有

1. 模型管理和同步, 需要管理内建的和行业组件中产生的模型, 提供用户创建和编辑接口
2. 模型的可视化
3. 数据的管理和同步, 根据前面的描述, 涉及到
   • 分组分类的管理,
   • 单元的命名, 删除, 复制, 移动
   • 数据单元的抽取, 切割, 合并
   • 数据的标签管理
   • 查看数据, 这里会涉及数据可视化的一些功能
   • 数据的单个编辑和批量编辑
4. 数据模型识别匹配
   • 材料收集, 规则收集
   • 关键词收集, 正则编写, 性能测试
   • 机器识别算法的测试和选型, 数据准备, 训练, 调优
5. 转换规则管理
   • 新增, 编辑, 删除, 移动, 条件设置
   • 规则的可视化
   • 中间过程的可视化
   • 第三方转换接口的接入
6. 规则管道的配置, 可视化

3. 分析处理

数据分析和处理是数据类产品的核心模块, 主要负责模型和决策引擎的运行, 这一步集中了密集的计算和数据处理, 因此要设计合理的机制方便硬件扩容

服务注册和任务分发

采用合适的任务分发机制, 确保资源分配均衡合理, 使用必要的缓冲机制削平业务毛刺.

资源管理

• 对不同任务使用的计算资源进行调配, 实时增加/减少计算资源.
• 根据任务的负载自动创建和分配资源, 以保证分析处理的服务质量
• 当任务空闲时回收资源

性能监控

对计算资源的负载和错误率进行监控, 实时预警

技术实现

调研现有的分布式服务治理框架, 根据业务场景进行选型. 技术上, 对于分片较小的任务场景, 可以使用集中服务注册和分发机制, 对于分片较大的任务, 可以采用消息队列机制, 技术上的目标主要有

1. 简单稳健, 易于维护, 能实时进行资源伸缩
2. 时间任务管理
3. 有完善的完成确认机制, 确保任务不丢失
4. 设计合理的调度机制保证集群的工作效率

4. 输出适配

输出功能包括数据可视化, 数据导出, 数据输出接口, 自动化操作(预警, 拦截等). 数据输出功能实际上分布于系统中的每个环节.

从产品功能上分, 主要有以下几方面

数据可视化

数据可视化包括以下几方面

• 结构化数据可视化
  • 行数据库可视化
  • 列数据库可视化
• 半结构化数据可视化
  • MongoDB等文档型数据库
  • Memcache, Redis等NoSQL数据库
  • HTML, XML, JSON等格式化文本
• 非结构化数据可视化
  • 新闻内容聊天记录等
  • 二进制内容可视化
    • 图片
    • 音频
    • 视频
    • 行业数据格式

数据导出格式化

导出格式化包括

• 系统其他模型的输入
• 输出CSV, Excel
• 输出图片(各种chart), gif(动态chart), svg等
• 输出PDF
• 输出音频, 视频
• 其他行业格式

数据装载(Load)

将数据通过接口, 导出至其他持久化存储

• 关系型数据库
• 非关系型数据库

输出至接口

根据业务场景的需要, 通过接口与第三方系统集成, 实现业务联动, 对实时数据处理产生的预警, 拦截和报告, 使用多种途径进行传输.

技术实现

在技术上有一部分是和数据输入重叠的, 需要适配各种第三方系统的接口, 但是实现成本主要体现在可视化上, 图形, 图像, 报表和行业特定格式的输出

1. 数据可视化, 对各种数值类型和已知数据格式的查看, 对不同场景可能有不同的展示变体
2. 对数据生成各种类型的chart, table, 以及动态chart, 对不同场景可能有不同的显示和格式要求, 包括遮盖脱敏等
3. 生成不同格式的文件
4. 文件系统的附加操作: 签名, 加密, 压缩
5. 处理异构数据之间的映射转换
6. 第三方数据接收接口的适配

这部分开发首先是基础的可视化和输出, 比如常见的文档图片文件, 又可以进一步分成后端代码生成和数据接口输出然后由第三方程序(前端JS, 安卓, IOS控件等)生成.
其次是项目或行业相关的可视化输出, 例如证券行业里需要的走势图, 统计图表, GIS项目需要的地图绘制和统计图表.
前者大部分场合都会用到, 所以是必须开发的, 后者根据项目需求设置好覆盖范围和性能指标规划开发任务.

5. 行业套件

行业套件是搭建在前面基础功能之上的上层建筑, 通过行业经验以及监管需求创建好标准数据模型和输入输出机制, 预置业内常用系统的适配, 提供可行的集成方案.

行业套件的目的是降低行业用户使用门槛, 实现快速部署, 快速展示效果, 提升使用方的使用和购买意愿. 主要的产品功能包括

业务逻辑集成

• 内建行业数据模型, 只需要用户数据满足模型入参条件, 就可以使用内建的模型进行处理
• 内建行业业务逻辑, 例如财务相关的会计和审计算法和模板, 人力相关的报表和审批流程
• 便于扩展, 用户可以通过界面进行自定义

接口和数据集成

• 对行业常见的上下游系统接口进行集成, 例如金蝶, 用友等标准财务系统, salesforce等CRM系统, 用户只需要配置账户环境, 就可以进行数据接入
• 监管接口的集成, 降低用户接入监管系统的难度和迁移难度, 这部分根据政府监管机构的政策变化, 需要有人定期维护, 保证可用性
• 行业数据接口, 例如汇率, 股价, 地理数据, 行政区划, 高风险地区名单等便于用户用于制定规则决策和生成报表的素材.

报表和规则管理

• 内建常用报表, 用户可以直接使用或只需要少量修改就可以接入用户业务系统, 快速生成符合监管要求的报表
• 内建满足监管要求的业务处理规则, 实现实时的信息上报, 预警跟踪, 处置报告生成等功能
• 根据客户场景和预算, 提供不同实时性的处理机制

界面集成, 定制用户交互

对于不同类型的场景, 需要为客户提供定制的, 便捷的操作界面和输出, 甚至集成到客户的业务系统, 例如

• 对于企业客户, 集成用户登录, 定制综合看板, 业务统计, 通知邮件, 定制报表导出等.
• 对于政府机构客户, 定制室内大屏和监控显示, 政务系统集成, 适配信创系统.
• 对于银行客户, 定制管理界面, 对接当地监管.

用户培训

提供相关的业务培训, 一方面是作为增值服务增加服务粘性. 另一方面在培训中收集行业信息, 发掘更多的客户业务需求.

技术实现

技术上更多的是调研和总结客户的行业需求

1. 政府监管实施细则, 字面之下实际的执行标准, 当前客户的实际流程
2. 总结出对应业务和监管场景的数据模型, 处理流程和报表格式
3. 依托基础模块之上实现上述的业务逻辑, 并进行必要的二次开发
4. 适配行业上下游系统接口
5. 跟随监管及市场需求, 定期维护

行业套件的开发成本(和风险)来源于三方面

• 已知的标准业务逻辑, 在一个确定的流程里定义好数据的模型, 再针对各环节的覆盖面评估开发量, 分批或分期实现.
• 未知或者潜在的业务逻辑. 这些不确定性带来的成本, 需要与与客户深入合作或灰度测试后才能明确, 如果有资深从业人员参与需求评审, 可以降低这部分的不确定性.
• 实施成本. 与客户现有系统, 与第三方系统集成产生的开发成本. 这部分的成本与客户和第三方现有系统的技术架构, 技术团队的能力, 以及客户和第三方的配合意愿都有关系.