敏捷最终不仅体现在业务的效率上,更是体现在工作的本质上。只有这样,才真正让业务人员在“分析”数据。拖拽一个仪表盘不是分析,这是搭建可视化的看板,分析是细致的研究、迭代和决定什么数据的口径能够准确反映业务的关键状况,并以此作为 KPI 进行追踪。没有敏捷,是无法真正进行分析的。敏捷还体现在分析的起点尽量靠近原始数据、明细数据、业务数据,更大的原始粒度决定了分析的视角是足够宽泛的,能够容纳足够的变化度和探索空间。缺失的后果不够敏捷首先是局限为 IT 或者数据团队需要去准备数据,这里的沟通成本在于 IT 岗位和业务场景还是有不小的鸿沟;同时还特指数据的成本,包括了对业务预设场景的计算成本、中间生成的结果表的存储成本、以及对这一系列过程的工作流管理管理成本、还有在发生变化时的定位、修改成本、最后还有在这一系列复杂过程中频繁出错的修复成本和数据经过层层计算最终反馈出变化的时间成本。在一个业务快速变化、数据源也快速变化的动态场景下,以上所有成本都会同步大幅成长,在数据放量面前,所有的提前预设和准备都是失效的。 开放性|Embedded Friendly 开放性的定义 首先要明确,集成解决的是研发效率问题。嵌入集成友好是一个架构设计要求,不是一个功能层面要求,因此面向嵌入集成友好的设计在软件研发的早期就要确定,在软件自身功能的每一个抽象分层上,都有考虑到和外部系统的交互问题主要包括下面的几点:
1、Open API:需要严格的前后端分离设计,在功能层面能够表现为一组完整 API 集合;
2、身份:有完备的用户登陆认证适配机制,和与此配合的动态权限控制机制;
3、前端:有非常灵活的 iFrame 定制化能力、CSS 自定义能力、主题设计能力;
4、模块化:主要功能都有良好封装,松耦合设计,具备独立的能力,能够边界清晰的被识别和调用;
5、对外能力服务化:能够通过 API、iFrame 等各种方式明确对外形成服务机制,有完善的功能 API 创建、注册和流控等管理机制;
6、弹性可扩展:在通过 API 支撑的方式成为一些应用的基础设施后,能够根据服务压力进行弹性扩展,轻松无修改的通过增加部署节点或者容器实例来应对增加的服务压力;
缺失的后果按照传统单机桌面软件的设计路径,单一的价值落地方式,不能灵活的通过修改配置自定义,无法对外暴露出各种 API 能力,模块之间紧耦合相互调用,对外呈现不清晰、不透明的单一应用层功能,无法在性能受阻的情况下进行水平扩展。 建模语义层|Modeling and Metrics 建模语义层的定义能够在数据层面之上构建一个以指标计算逻辑为核心的管理层,用专有语法定义指标被数据的字段计算的公式,指标可以成为一个可被管理的逻辑概念被创建、修改和发布,基于这样的中心化管理,实现从数据到分析的解耦分层,让分析人员面对字段、维度和指标集合开展工作。这个架构上的变化源动力来自于业务人员希望更快的从更大量和更加分散的数据集中获得结果,而最大的阻碍则来自于如何从数据中构建模型关联关系这个过程。构建一个建模语义层支撑的指标管理功能会让这个构建过程可见可管理,面向业务,敏捷应对变化。
缺失的后果缺乏全流程的支持和管控。需要大量整合各种开源或者商用工具,拼装完整的工作流程,带来大量的实施和对接成本。 无法应对或者只能以高成本来应对更严重的数据孤岛环境。需要搭建重型的数据仓库和大数据平台方案,反复搬运数据,无法根据分析需求灵活的改变数据集成路径。 缺乏协同的划分,引起混乱。在工作流程中没有工具层面的边界划分,需要依靠管理机制进行工作安排,带来大量沟通和管理成本。 平台适配性|Adaptive for Big Data 平台适配性的定义能够对接各大数据存储/计算平台的查询接口,进行高速的即时查询,对接主流的数十种大数据分析引擎。 能够将建模语义层的指标计算的公式语法按对接类型翻译执行,下推到不同类型的数据平台完成运算,并收集聚合统计初步结果,在平台上完成最终聚合。