十年磨一剑，Smartbi伴随中国金融行业走过了15年，更潜心专注在BI产品研发上，那么我们如何为用户提供自助式BI的必要功能呢，我们模拟角色背景来进行介绍。
业务人员小A是某股份制银行XX分行的数据分析师，技术人员小B是总行信息中心的数据工程师。以前小A想要一份报表，要通过内部OA提请申请流程，通过层层审批后由小B负责开发这张报表提供给小A，如果小A遗漏需求或者变更需求，甚至再着急拿到报表，都要忍受一遍遍的审批流程。
2014年，该银行部署了Smartbi，实现了自助数据分析平台，现在小A需要分析数据时，只需要登陆指定的安全桌面，在其中完成指标定位、拖拽制作、保存报表即可，如果需要得到真实数据到本地，也只需要在系统自动提交审批即可完成。
在这样的需求背景下，Smartbi以开放的技术架构、丰富的操作特性和贴心的运维管理破解了业务需求与IT服务围绕“数据”的矛盾，释放了银行数据生产力，加速了中大型银行在互联网时代的转型速度，提高了面对市场的决策效率！
Smartbi以开放的架构融入各个银行的技术平台，查询计算被分解为2个阶段，提取数据的计算交给大型的MPP数据仓库（或Hadoop）完成，类OLAP分析的前端计算由内存计算（或其它缓存方式）完成。如果用户只是提取数据，那么内存计算能力就不会被消耗。而且计算能力的分布方式可以根据客户的情况进行随时调整，Smartbi也不需要落地的存储资源，极大的体现了自助式BI的部署便捷性。
Smartbi为小A这样的数百名业务人员提供了丰富的操作功能，满足其取数、制表、分析、报告、发布等五类查询需求。我们从小A使用过程的3个环节进行详细说明：
通过顶部搜索框，小A输入“贷款余额”进行模糊搜索，不仅可以找到所有授权访问的报表，还可以迅速定位，马上进行浏览。当然如果她有编辑权限，也能进行修改。
如果小A只知道自己的指标包含“利息金额”，也能通过定制搜索的功能找到系统中真正的指标名称，或者直接了解这个指标都应用到哪些报表中。
这些功能就像我们日常使用的GPS，让小A这样的业务人员能够在数据平台中快速找到目标，为后续的使用提供有效的指导。
当然，小A所需要的数据大多数存在于系统当中，此外还有一些本地的Excel数据，它们都是小A日常辛辛苦苦收集起来的。由于Smartbi提供的透视分析功能非常方便，比Excel透视表更增加了“钻取”功能，小A想用自助分析平台研究一下本地的Excel数据，顺便也能做几张漂亮的图形。
小A在定制管理界面下选择“加载数据包”，指定自己的Excel文件后，按照向导命名了字段名称和格式，就完成了导入，并可以直接进入透视分析界面。
通过小B的指导，小A知道自己所需要的明细数据都在“对公贷款明细”这个业务主题中，于是她打开组合分析功能通过对字段的点选，以及勾选任意字段形成过滤条件，就实现了自己的取数需求。
小A突然想在下载这份数据之前，先进行一下分析，了解一下数据的质量，于是她通过菜单上的快捷按钮，直接将此份数据带入了透视分析功能界面中。在这个功能中，小A还是使用鼠标就可以完成，比如拖拽定义表格、右键进行交互&钻取。甚至还能新增计算字段，比如这次小A就用“组织机构编码”的计数作为客户数据的统计。
注：这个界面是否熟悉，它和Excel透视表很像吧！
小A觉得最让她方便的就是“下钻”功能，只要“待选列”里有的数据字段，都可以作为下钻目标，如果想聚焦在某个取值上，也只需要设置“焦点项”，系统还会给出标记提醒自己哪里设置过了焦点，以免出现对数据的误解。
系统提供的图形包括柱图、堆积柱、瀑布图、横条图、折线图、面积图、堆积面积图、饼图、环形图、油量图…，小A不希望太过渲染图形，一般只用柱图、饼图和趋势图。
小A做好报表后，首先保存在系统上，如果她不愿意公开的话就存在个人空间下，或者保存在小B建议的目录下面，便于别人能够搜索到。处于安全的原因，Smartbi在这个银行的导出功能被改造进入“安全文档管理“，在报表界面上点击导出时，会跳转到相应的界面，而不是默认的功能了。
小A觉得有些报表自己留着用就好，但有些报表可以组合成“动态故事”，以便自己和领导更全面的了解业务情况。她通过“新建页面”的功能，把几张报表合并到了一起，形成了仪表盘功能。
仪表盘页面可动可静，有些特殊的跳转、钻取在小B的帮助下可以实现出来。但小A觉得在系统中找到这个页面打开也不够直接，而且这些数据分析经常需要以PPT、Word格式提供给领导。她感觉很为难，找到了小B来帮忙，小B在安全桌面中的Office安装了一个Smartbi for Office插件，这样小A就可以将若干报表合并为分析报告使用了。
现在是移动互联网的时代，如果能把报表、仪表盘或者（Word/PPT）分析报告直接发布给领导的APP上，小A觉得会非常方便，也不用等领导坐到电脑前面才能得到反馈。
平台的完美运行离不开小B的贡献，他完成了从报表开发人员到数据平台管理员的转变，为各个分行的小A们提供了重要的系统保障。我们也从小B日常工作的三个环节进行说明：
小B根据信息中心的规划，将某个超大数据表迁移至Hadoop，并部署了Kylin，现在他将这个新的分布式OLAP引擎，通过jdbc的配置增加到系统中，为业务人员提供秒级的交互式组合和钻取分析。
小B作为总行的管理员，各个分行的人员变动信息都要由他处理，光这一点，都让他觉得应接不暇。他使用Smartbi的分级管理功能，在分行设立了管理员角色，日常的人员入离职同步和资源、数据授权都在他的管辖下得到了合理的安排。当熟悉这套规则后，即便公司架构发生了调整，他也能把权限分布下去，而自己只需要对所有管理员的工作进行检查和审计。
小B转型做运维管理以来，备感责任重大，尤其对系统的安全运行非常重视。还好Smartbi的架构比较开放，所有的系统元数据都保存在关系数据库里，而且系统自身有自动备份的计划任务。但他还是不放心，因此每几天就会手工操作备份知识库。
一旦系统出现故障，他也可以把知识库马上恢复到之前正常的状态，然后把问题知识库发给Smartbi进行分析和诊断。
小B的日常工作还包括定期的上线支持，每次这个时候，他和同事们都有很大的压力，万一出了问题，后面的几天都很难有好心情了！还好Smartbi提供的资源导出导入功能比较人性化：
■ 从开发环境导出资源时，可以只选择报表、仪表盘或者分析报告，然后通过“添加报表依赖”由系统自动关联所使用的参数、数据集等资源。避免手工选择可能造成的遗漏！
■ 导出的文件格式为XML，可以通过各种方式发送到生产环境相同的网络环境上。然后通过导入资源就可以完成发布。当然如果出现同名冲突，Smartbi也会预警出来，提示必要的操作；大多数情况数据源设置生产与开发环境是不相同的，系统也可以提供数据源更改的功能。
除了每月一次的上线任务，小B日常学会了Smartbi提供的一些运维工具，大大加快了诊断问题的速度。
■ 首先是系统诊断的工具集，Smartbi把十几年来在运维支持中自己使用的工具方法都集成到了系统中，这可真是运维管理的百宝箱！
■ 其次是计划任务功能，很多时候业务人员的需求不是从前台页面能快速解决的，或者业务人员需要定期获得报表（到电子邮箱），以及为一些仪表盘应用预填充T-1的数据。
当然小B也不用担心这么多的job会乱掉，系统有监控管理的功能
■ 最后小B也很关注平台的使用率到底如何，小A们的使用习惯也是他的研究范围。毕竟知己知彼才能心中有数嘛。这个需求Smartbi还是利用知识库（元数据）能力来解决的，甚至都已经内置了很多系统监控报表（用其自身的报表能力完成）。
小B在2年的使用中，越来越理解元数据的设计思想，也发现了几个好东西。
首先对大部分业务人员来说，他们自己不会写SQL，只能通过语义层概念来解决。但Smartbi在语义层的做法上有灵活性的选择，比较合适的做法是这样：由数据模型专家在数据源上建立“统一语义层”，然后由小B为不同业务类型的业务人员再做多个“业务主题”。因为业务主题会自动继承统一语义层上的设置（中文命名和表间关系），也能够手工修改（不继承），所以小B的工作其实就简化为“整理字段“和”检查表关系“。这样不仅兼顾了规范性和灵活性，而且可以用元数据进行影响性、血统分析，便于定位和解决共同的数据模型问题。
其次Smartbi可以为平台定义好筛选参数、数据展现、告警规则、数据转换、页面配色、表格配色、图形配色的格式，这些公共的设置随着小B支持工作积累越来越多，小B后期的工作也变得更加简单，有时他只要告诉对方使用哪个公共设置就可以了！
通过小A和小B的场景化描述，可以看到作为自助式BI的参与者，Smartbi自助分析以其开放的技术架构和独特的功能特点，获得了银行、电信等客户的长期认可。
Smartbi认为通过部署“自助分析平台”，客户获得的真正价值包括：
■ 数据产生于业务部门，现在也可以回归于业务部门进行分析利用，从而实现信息化的真正闭环，推动数据质量、数据完整性的建设；
■ IT部门更加专注于技术的创新与应用，比如引进Kylin等大数据分析平台，也可以更加投入在元数据的维护与管理上，提升分析平台的服务效率；
■ 对于个人来说，业务部门的分析人员学习到了更多的工具，而技术人员也因为掌握数据知识而转型为业务分析师的机会。这样的人员内部流动对企业来说更是释放了潜在的内部生产力；
■ 对企业来说，数据不再是搁置在硬盘上的1-0，而是能够驱动全面决策的数据资产，从这样的结果来说，IT部门因此能够得到更充足的资金预算；
■ 对实施来说，漫长的交付周期能够缩短50%，主要精力放在数据模型、安全体系、元数据服务等基础工作上就可以了。
首先，自助分析平台并不是一个软件、或者IT系统，而是一套完整的管理体系，绝不是像某些厂商宣传的“买了产品后就是自助分析平台”，Smartbi在阿拉丁中只是完成自助报表和分析的功能支撑，而完整的阿拉丁包括了管理流程、安全机制、配套制度等关键环节。
其次，自助分析平台并不是简单的基于大数据系统或者“传统数据仓库”，而是充分整合其各自的优势，根据应用的场景进行技术架构，目的都是解决业务用户的使用友好性。同时从阿拉丁的实践中，我们也看到数据质量和数据模型对于自助分析平台有着决定性的影响。任何宣称不需要数据仓库、数据建模的说法目前都还是不切实际的！
