数据化运营之敏捷BI最佳实践

——畅享IT讲堂演讲实录

大家下午好，我是谢玲，今天的演讲主题是数据化运营之敏捷BI最佳实践，永洪这边是做数据运营的，有各种各样的数据要进行分析，就需要用到可视化的工具，数据化运营，打造智慧企业的唯一选择，可以去监控各个环节进行调优，没有做数据化运营的企业会是一个什么样的现状呢?

首先不知道它的业务现状，无法获知业务状况、发展规律、用户画像等，在一片漆黑中凭感觉前行。利润下滑、增长停滞、用户流失，不能探究真实原因，面对问题无法有效解决，且未来再发生依然如此。销量、收入、用户行为，没有准确的预测，依靠经验来进行备货、促销、人员扩张。粗放经营，损耗太大。我们引用Lord Kelvin的一句话就是"If you can not measure it, you can not improve it."如果我们不去测量它的话就很难改善它。所以数据化运营是未来一个大的方向，那到底是我们要建设一个什么样的数据化运营平台呢?来去支撑业务部门和领导的决策呢?平常搭建的模式是建设数据分析平台(Business Intelligence)，国际市场正经历着怎样的转变?以前说到数据分析，大家一定会提到那些曾经的IT巨头：Oracle BIEE，IBMCognos，SAPBO…，项目实施的成本比较高，周期比较长。现在永洪BI、Spotfire、Tableau、Qlikview等新锐厂商在行业内越来越知名。这里面我们引用下Gartner2015 BI魔力象限报告：敏捷BI、探索式BI已成大势所趋。BI市场正进行着基础性的变革“过去，大多由IT部门主导BI项目的投资，这些项目高度可控、中心化、IT-led。IT部门负责编制出Production Reports，再推送给消费者和分析人员。现在，大量的商业用户迫切要求进行探索式分析或者深度分析，以获取数据洞察力，而他们只有非常有限的IT或数据科学技能。”“在2014年，IT-centric BI平台正越来越多地被Business-user-driven和交互式分析项目替换。”在国内，越来越多的企业希望借力业务主导型、高性能、并同时具备大数据分析能力的敏捷BI平台。

我们来分析一下传统的工具为什么会带来这么多弊端?数据可能来源于多个系统，CRM、HR、OA等业务系统，通过数据转换提炼到数据仓库做一些汇总，面向一些集市之上会建一些OLTP的一些工具或保镖盘的工具，最后再给到BI使用者，我们看到这一层层的搭建首先会使用不同的工具来实现，或者说每层搭建都需要一个良好的设计之后才能给到前端的业务部门去使用，这样会带来一个弊端就是当我的需求发生变化的时候，可能要一层层的回去进行修改，有的甚至会去最底层进行修改，这样就会出现IT部门做出来的一些报告并不能满足业务部门，业务部门想自己使用数据的时候没有办法直接处理，会从仓库里面去导出，再用excel去进行分析。

来自知名咨询机构Forrester的数据：迄今为止，打造了传统的企业数据仓库的机构，有83%的用户没有用数据仓库做数据分析，而是继续使用Excel等其他工具做数据分析。

到今天，敏捷BI平台已经是主流选择，来自知名咨询机构TDWI的数据：利用探索式BI工具，超过50%的用户能从大数据中找到他们想要的答案;如果不是探索式BI工具，那么只有20%的用户才能做到这一点。

敏捷BI最佳实践：系统架构，1.数据源：各种数据源，包括数据库、Hadoop、日志、机器数据等。2.逻辑数据集市：面向主题的逻辑数据集市。由于定义的是逻辑数据集市而不是物理数据集市，并无数据迁移发生。3.MPP数据集市：面向主题的物理数据集市。通过增量加载或全量加载数据，数据已经存储在MPP数据集市里，用于高性能计算和海量数据处理，达到秒级响应。4.自服务分析前端：探索式自服务分析前端。通过极高的数据分析自由度和灵活性，充分释放数据的价值。

敏捷BI最佳实践：敏捷BI与传统BI系统架构的区别，传统BI的维度需要提前设计好再用cube工具计算好，可能的函数需要提前计算好放到cube里面，如果发现某一个维度没有或者说某一个指标求和不够用需要求平方差那这个表里面不存在就需要重新去设计这个二次表，前端的分析会受到很大的局限。

那我们比较了这两种在实现的时候不一样，从结果的角度看，传统BI会大大埋没数据价值而敏捷BI会释放数据价值，为什么我们会去这么解释?提前计算好的会导致我管理层看固定报表、少数人了解数据、只有IT人员才会操作的BI系统、数据量大时需要提前计算汇总好结果。而敏捷BI会使一线人员灵活分析数据、数据指导每个人的业务运营、人人会用的可视化分析工具、海量数据实时计算。固定的不只是报表，还有思维;中断的不只是工作，还有思考;提升的不只是性能，还有视野。

新的数据分析方法，对平台有什么要求?1.敏捷，数据分析需求经常变化，分析报表需要及时调整，以保持业务分析的思维连续性;2.高性能，百万到百亿数据，分析请求需要达到秒级响应，以支持灵活的业务组合分析和任意的时间窗口分析;3.自服务，从上到下的业务人员，有需求时不会一味提请IT部门代劳，而是直接动手进行数据分析。

那我们接下来看下每个环节可能遇到的一些问题展开进行梳理，在系统架构方面每个环节都有不同的考量，分为三个步骤，1.需求梳理2.轻量数据治理3.数据分析。我们首先会去收集各个部门的需求并分析需求和数据现状，再进行研究分析需求和数据现状，形成可行性结论和实施方案，避免无谓反复或者被现实击穿。接下来就是做一个数据准备的工作，在现有的维度和指标下可能会衍生出一些新的需求，这里面就包含两种，1.衍生行间无关的维度或指标。例如：利润=收入-成本2. 衍生行间相关的维度或指标。例如：大客户=年度总消费>5万。那我们衍生行间无关的维度或指标它是以什么形式表达呢?例如：利润=收入-成本1. SQL优先：SQL表达式 vs Script表达式2.减少计算量原则：高性能计算之前定义vs高性能计算之后定义，举个例子，如果两个表要进行关联，关联的工作在数据库里面计算完之后，再把关联好的结果入到集市里面，对于集市的数据进行分析的时候，这个关联的动作就不需要再做了，性能这块的工作把它做了提前，还有类似减少数据资源的方式去进行调优。衍生行间相关的维度或指标，例如：大客户=年度总消费>5万1.可生成中间表2.也可直接用子查询，开启高性能计算1.基于数据库性能满足，不用开启高性能计算2.反之建议装载细节数据以开启高性能计算;增量装载还是全量装载?1.全量装载细节数据：有可能耗时过长2.增量装载细节数据：有可能没有条件。第三步就是数据分析，满足需求，超出预期1.必须满足分析需求：不解决问题的数据分析没有用2.建议适当超出预期：不超出预期的数据分析是土鳖。例如有领导长期看惯了这个表格，这时候提供给一些更丰富的图标给他看，也许就在之前没有的前提下，慢慢就习惯用新的工具能带来更好的可视化的效果。满足当前需求、满足未来需求：构建有生命力的面向主题的数据集市。超出预期的话要考虑1.UIUE：丑的UI让人难受，浓郁的90年代气息迎面而来2.性能：最重要的功能，可以带来更宽的视野、更好的用户体验。

这个界面就是传统的方式用非自然色的色块去搭建。

这是通过新一带的工具实现，可以看到更好的色彩搭配，更好的视觉上冲击效果。

总结一下敏捷BI：三步上篮，最佳实践，第一分析需求，研究现状形成可行性的报告结论和可实施的方案;第二就是对于数据的准备、数据治理过程最一些轻量的建模、准备工作，可以对一些延伸的指标，是采用SQL表达式vs Script表达式，减少计算量原则：物化之前可以减少计算量对于行间相关的维度和指标，我们可以采取生成中间表或者子查询的效果来实现，另外要考虑是否开启高性能计算资源，基于数据库性能满足，不用物化，反之，建议预先装载细节数据以开启高性能计算，全量装载：有可能耗时过长，增量装载：有可能没有条件;第三步就是进行数据分析，对于当前必须满足的需求要整理好，满足未来需求：构建完备的面向主题的数据集市，适度做一些超出的预算，UIUE方面收集更好更精美的新一代更好感觉的界面，再从性能上面达到更高的预期。

最后有一个场景跟大家解释一下，全渠道全周期的营销ROI监控，定义用户唯一标识，辨别不同用户的渠道来源。补充完善用户的属性、行为、购买信息。持续跟踪和迭代分析用户的产品/服务使用行为。根据用户画像调整不断优化投放渠道。我们可以看到用户流量在每个渠道是什么样的比例，转换成购买的用户他的比例是什么?本身的购买能力是达到什么样的选评，再包括他在这个平台上面的活跃度，是通过这四个指标来去打分，贡献值能算出下一次投放时每个渠道的投放比重要更好。

运营KPI监控，这是对于人力资源的投放情况进行KPI监控，渠道投放是说钱投放到哪里?对于人员的利用是说人员的水平、级别，从这两方面进行运营化的监控，再去调整他今后的方向及下一步的工作，这是一个比较典型的场景的事例。

那今天的分享部分就到这里啦，谢谢大家!