定义现代化的数据分析最佳实践（一）
数据蕴含的无限价值已经被大家所认可，数据和分析也是数字业务成功的关键。在Garnter的相关报告中也多次提到：未来企业应该向数据驱动型公司迈进，创建数据素养计划目前是一个高度优先事项。但如何通过建设数据“基建”充分发挥价值企业却还在不断摸索中。数据和分析日益成为业务战略的主要驱动力，完全融入企业的日常工作之中，数据驱动的业务战略和信息产品也具备了前所未有的发展潜力。不少企业已经引入数据分析做为实现数据价值的关键，但我们发现许多企业在搭建数据分析应用时缺乏顶层视野，缺乏“数据思维”，主要问题有几点：
- 没有整体规划，数据、系统的堆叠，上量后系统容易崩溃
- 数据分析跟不上业务变化、不同场景不同角色的个性化需求
- 如何让数据分析与其他产品、工具协同工作
在《HENGSHI SENSE 4.0 发布，前所未有的敏捷分析管道》一文中，我们也曾提到过许多数据分析和数据平台发展的关键趋势。趋势和问题并存，处理这些数据分析难题往往需要更系统的思路，才能搭建起商业分析成功路径，享受由数据带来的持久的价值。
本文内容部分源于《定义现代化的数据分析最佳实践》白皮书，希望能对大家有所帮助。文末附上该白皮书完整版本获取方式。
Analytics Blueprint
商业分析成功实践蓝图
准确定义现代化的分析能力体系
敏捷性｜Agile is the key
敏捷的定义
业务方或者分析人员能够灵活的定义分析指标，并在分析探索过程中可以随需应变的临时新增、修改、删除指标模型，修改的结果会直接影响到最后的仪表盘或者数据 API，而整个过程对数据层面完全“无感”。这里的完全无感的意思是，没有任何中间实体表的生成，也没有任何中间计算需要发生。
敏捷最终不仅体现在业务的效率上，更是体现在工作的本质上。只有这样，才真正让业务人员在“分析”数据。拖拽一个仪表盘不是分析，这是搭建可视化的看板，分析是细致的研究、迭代和决定什么数据的口径能够准确反映业务的关键状况，并以此作为 KPI 进行追踪。没有敏捷，是无法真正进行分析的。
敏捷还体现在分析的起点尽量靠近原始数据、明细数据、业务数据，更大的原始粒度决定了分析的视角是足够宽泛的，能够容纳足够的变化度和探索空间。
缺失的后果
不够敏捷首先是局限为 IT 或者数据团队需要去准备数据，这里的沟通成本在于 IT 岗位和业务场景还是有不小的鸿沟；同时还特指数据的成本，包括了对业务预设场景的计算成本、中间生成的结果表的存储成本、以及对这一系列过程的工作流管理管理成本、还有在发生变化时的定位、修改成本、最后还有在这一系列复杂过程中频繁出错的修复成本和数据经过层层计算最终反馈出变化的时间成本。
在一个业务快速变化、数据源也快速变化的动态场景下，以上所有成本都会同步大幅成长，在数据放量面前，所有的提前预设和准备都是失效的。
开放性｜Embedded Friendly
开放性的定义
首先要明确，集成解决的是研发效率问题。嵌入集成友好是一个架构设计要求，不是一个功能层面要求，因此面向嵌入集成友好的设计在软件研发的早期就要确定，在软件自身功能的每一个抽象分层上，都有考虑到和外部系统的交互问题主要包括下面的几点：
- Open API：需要严格的前后端分离设计，在功能层面能够表现为一组完整 API 集合；
- 身份：有完备的用户登陆认证适配机制，和与此配合的动态权限控制机制；
- 前端：有非常灵活的 iFrame 定制化能力、CSS 自定义能力、主题设计能力；
- 模块化：主要功能都有良好封装，松耦合设计，具备独立的能力，能够边界清晰的被识别和调用；
- 对外能力服务化：能够通过 API、iFrame 等各种方式明确对外形成服务机制，有完善的功能 API 创建、注册和流控等管理机制；
- 弹性可扩展：在通过 API 支撑的方式成为一些应用的基础设施后，能够根据服务压力进行弹性扩展，轻松无修改的通过增加部署节点或者容器实例来应对增加的服务压力；
缺失的后果
按照传统单机桌面软件的设计路径，单一的价值落地方式，不能灵活的通过修改配置自定义，无法对外暴露出各种 API 能力，模块之间紧耦合相互调用，对外呈现不清晰、不透明的单一应用层功能，无法在性能受阻的情况下进行水平扩展。
建模语义层｜Modeling and Metrics
建模语义层的定义
能够在数据层面之上构建一个以指标计算逻辑为核心的管理层，用专有语法定义指标被数据的字段计算的公式，指标可以成为一个可被管理的逻辑概念被创建、修改和发布，基于这样的中心化管理，实现从数据到分析的解耦分层，让分析人员面对字段、维度和指标集合开展工作。
这个架构上的变化源动力来自于业务人员希望更快的从更大量和更加分散的数据集中获得结果，而最大的阻碍则来自于如何从数据中构建模型关联关系这个过程。构建一个建模语义层支撑的指标管理功能会让这个构建过程可见可管理，面向业务，敏捷应对变化。
通过建模语义层的抽象，真正随需而变的部分，就可以被灵活的配置和修改，封装为一个个分析模板，让接下来的应用场景能够轻松的嵌入整合，实现了计算的后置，也真正降低了分析的门槛，让业务人员能够自助式完成对数据的探索。
缺失的后果
数据仓库的实际运算和商业智能的分析逻辑混在一起，数据人员和业务人员强行绑定配合，指标分析逻辑固化且需要提前完成数据准备，没有足够强大的规则去表达和定义计算的逻辑，需要依靠 SQL 机制生成大量的中间数据表和存储加工任务，业务人员无法真正介入分析过程。
中台属性｜Middle Office
分析场景中的数据中台定义
需要具备端到端的数据全生命周期管控机制。由于语义层的能力，分析得以从明细数据展开，因此分析的过程也需要从数据聚合阶段开始，整个数据聚合、管理、建模、看板构建和发布复用的全流程都需要能够一站式发生，并在每个阶段进行清楚的落位管控。
需要具备一个逻辑数据湖仓的全局管理视图。能够在数据可达但是不搬动的情况下，实现对数据的全局浏览，屏蔽掉多源异构的底层环境。实现数据逻辑整合后的目录整理和浏览，在缓存技术的帮助下，能够进一步实现数据物理上的聚合整合（到数据湖）。
定义数据工作需要的各种专业角色，然后根据角色分工协同落地最佳实践。设计好不同团队在平台中的工作流和配合边界，能够在产品中带入实践方法论，帮助用户养成数据文化。
缺失的后果
缺乏全流程的支持和管控。需要大量整合各种开源或者商用工具，拼装完整的工作流程，带来大量的实施和对接成本。
无法应对或者只能以高成本来应对更严重的数据孤岛环境。需要搭建重型的数据仓库和大数据平台方案，反复搬运数据，无法根据分析需求灵活的改变数据集成路径。
缺乏协同的划分，引起混乱。在工作流程中没有工具层面的边界划分，需要依靠管理机制进行工作安排，带来大量沟通和管理成本。
平台适配性｜Adaptive for Big Data
平台适配性的定义
能够对接各大数据存储/计算平台的查询接口，进行高速的即时查询，对接主流的数十种大数据分析引擎。
能够将建模语义层的指标计算的公式语法按对接类型翻译执行，下推到不同类型的数据平台完成运算，并收集聚合统计初步结果，在平台上完成最终聚合。
能够根据各数据平台的优势，创建适配的语言函数发挥差异化优势，比如 Elastic / Mongo 的原生语法深度支持。
缺失的后果
数据分析运算不能下推执行，数据需要加载到分析平台完成所有运算，极大影响性能。
不能真正享受到大数据平台蓬勃发展的技术红利，不能利用每一种平台针对某种场景的高性能计算和存储优势。
数据分析无法形成全流程的联通管道，带来分析的延时性，无法触达实时分析领域。
构建现代化分析能力的最佳实践路径
大而全的数据平台建设，常常因为希望一步到位的建设周期过长，又缺乏调焦校正的机制，在过程中失去对需求把握的准确度。
分析的需求还是来自业务端的经营管理需求爆发，构建的路径从底层开始往往经过漫长的建设周期，难以预测业务变化。反之，先从业务端的一些典型场景需求开始构建，能够以最快的速度得到分析效果的闭环验证，呈现小步快跑的落地效果。
赋能业务 —— 敏捷的分析上线
先收集业务部门对刚需的分析场景，提炼出几个最常用也最关键的应用，就能够拆解出一批试点用户、一套关键仪表盘和一组基础指标需求，作为最初的落地场景。
在 IT 数据部门的管控配合下，对接原始数据表的数据库位置，通过敏捷分析平台即时搭建出敏捷加工的数据分析管道，能在快速呈现报表分析结果，并完成视觉优化和发布工作，由此开始培养大家看数据做决策的习惯动作。
组织业务部门进行数据研讨，将数据的语言在组织内部做更多的发布传播，形成大家对数据口径的共识，通常也伴随几轮对指标更准确的优化或重新定义，最终形成一个效果不断提升的数据分析亮点场景。
赋能 IT —— 让数据准备和指标建模清晰可见
在一个业务部门的试点初步跑通后，管理效率或者管理 KPI 的可见性会得到凸显，这势必会让更多的业务部门也提出自身需求，希望复制成功的数据化经验，这时候才是 IT 部门大显身手的时刻。
广泛收集分析需求后，就能够在两个层面形成管理动作，一个原始的数据层，构建一个虚拟的数据集市，让多源异构的问题暂时不用理会，先专心收集所有有价值的数据输入源头；同时构建一个指标层，把需求提炼为业务指标库，进行统一的中心化管理，确保数据口径定义、数据溯源都是能够验证和灵活修改的。
通过分析的指标需要，结合明细数据的物理分布当前现状，构建数据关联模型，创建虚拟的宽表视图，形成关联分析的基础表，进行必要的数据加工，创建虚拟的新增定义字段。
最后在数据模型的基础上，构建出需要的所有指标的计算逻辑公式，以及参数化的变量，完成分析前的准备工作。让业务人员面对一个干净、清晰、整洁的数据资产层，这时候就能够安全可控的大规模推向多个业务部门，自助式的随需而变的构建分析场景看板。
赋能产研 —— 让数据类的应用开发简单搭建
如果基于数据分析的基础设施，已经完成了业务端的自助分析落地和数据层的清晰管控和指标中心化沉淀复用，最终则能够将价值落地的范围从业务人员扩展到所有系统。
形成数据资产的 API 管理集合，暴露给所有业务系统，在数据部门的管控下，进行注册管理和直接调用，设置流控机制。
同时，将数据分析看板和各种应用成果，嵌入集成到业务系统中，在营销、人力、运营等核心场景复用分析能力和成果，让分析服务化，无处不在的整合进企业经营流程方方面面中。
最后，鼓励产品研发团队，基于已经形成的数据能力，更灵活高效的开发数据应用场景，或者包装出更加有针对性的行业解决方案。
至此，数据分析真正成为驱动组织进化的生产力平台，以一个增长引擎的定位，赋能组织内的每一个人、每一个应用。
小预告：在《定义现代化数据分析最佳实践》系列（二）中，我们将拆解衡石在最佳实践案例中的应用价值，想要提前了解相关内容的小伙伴，欢迎关注衡石科技公众号，留言获取白皮书完整版。
关于衡石科技
衡石科技专注于企业服务的数据领域，赋能行业客户持续数据资产化，实现业务创新为目标，秉承“Analytics as a Service”的理念，构建数据时代的一站式分析云。
我们相信，在数据时代，所有业务都会成为数据业务。
衡石科技旗下核心产品“ HENGSHI SENSE ”，已为 70+ 国内外行业伙伴提供标准化、易整合、可扩展的数据分析云，通过数据能力延伸双方的增长路径。
- Powered by HENGSHI
