背景目标当前使用情况架构
架构图架构说明
数据层服务层
ImpalaElasticSearchClickHouse 权限管理层
权限管理服务 应用层
web uicode service 展望
产品层面应用层面技术层面 其他相关内容引荐
背景作为数据赋能的一部分，大数据整合的数据集、标签、特征如何在生产中完全铺开使用；如何满足不同部门人员使用；能够从数据源、数据联合、数据集结果、元数据、数据链路进行完整的赋能是一个比较大的难题；尤其是业务人员很多，业务形态多变，查询请求量大，查询复杂都是其中的挑战； 目标
满足公司所有分析需要，产品化服务；满足公司所有的BI服务；稳定、快速、易用； 当前使用情况
因为是内部平台，平台用户量200+，人员类型分别是数据分析师、建模分析师、算法工程师、产品等；
很多情况是根据外部数据热度模块来说明的，此模块的建设后续和大家单独分享；
时间段访问量
查询总量
分析元数据部分
数据层主要是以数据仓库展开，因为此项目是以数据分析平台展开，那么具体数据仓库的建设流转以及实时数仓的流转这里不多做阐述；基本上所有的查询都从数据仓库提供，包括线上业务数据、数仓的所有层级（因为公司性质，分析团队庞大，数分能力强大）、用户行为日志埋点、公司重要的系统审核日志等； 服务层 Impala
- 服务层目前百分之90以上是使用Impala作为查询引擎，其中包括数仓、数据湖落库的数据、日志埋点等数据仓库部门处理清洗过的数据，但是业务需求有轻重缓急、那么不可避免的也有一些数据是和原始数据源的数据完全一致的数据；作为用户查询的主战力，那么集群资源配置、节点数量、配置优化，外部数据刷新节奏，Impala计算算法优化提前计算compute等必不可少；后续有空会把各个部分生产的使用贴出来；
- 数据分析平台中ES的主战力场是一些日志数据，实时日志等数据入ES，供业务部门以及分析部门进行线上业务流转情况查询，比如说风控的审核规则、策略、反欺诈等情况；
- 与Impala类似、目前实时数仓的一些数据会在CH作为服务端提供服务；
说明
一个面向应用层请求与请求服务层的中间层服务，此服务可以是Java微服务、python服务等；
功能
- 按照组、个人进行权限控制；单体的权限控制DML、DDL等所有；包含哪个部门哪个人可以进行删除、创建等；此部分的实现也是直接接收应用层的查询，然后进行解析判断；单体的查询可以进行行级别的控制，例如where条件的判断；例如生产中各部门的查询操作按照渠道、客群等进行控制；
环境
因为一个底线，就是数据不出公司；所有分析人员、产品人员的使用环境都是阿里云桌面，并非公司机器或者自己的机器；
应用层应用层的应用形式目前是两种，第一种是web界面进行数据报表的查询、查询、以及用户自定义的查询；第二种用户进行API连接查询，此处更灵活，可以进行数据处理codeing； web ui
当前公司由于针对此块的平台人员投入的原因，是针对开源产品superset进行的二次开发；
面向用户
面向公司产品、数据分析师、建模工程师、算法、策略等；
应用场景
针对报表查看，数据检测，数据分析，数据快速查询等；
服务过程
开发人员针对superset二次开发，将各类连接的请求打到权限管理服务进行审核然后进行数据服务；二次开发包括日志，ui界面等；
code service
面向用户
codeing能力强的数据分析师，模型开发的算法工程师等；
应用场景
自主分析，提取数据仓库标签层特征进行模型建设，自主特征衍生等；
服务过程
开发人员针对python连接的package进行二次开发然后一键部署到所有用户的云桌面环境内，将请求打到权限管理服务进行审核然后进行数据服务；
展望 产品层面- 将中台中的服务进行嵌套嫁接，保证单平台多功能，给用户最好的体验；将数据热度、元数据查询【包含基础数据集元数据、标签层口径、名称索引等】、血缘关系拓扑等进行集成，保证快速使用和理解；
- 因为技术服务搭建是随着需求而变化的；例如服务层做自动化特征衍生，自动化数据处理等是需要权衡的；
- 服务的稳定性，服务查询的高效保证都是不停要做的事情；通过与业务层深入结合，做出好的数仓数据模型；针对集群服务层服务查询的优化等都需要逐步突破；
此部分会逐步更新很多企业中应用的落地以及结合；逐步产品化、中台化；
