对于BI系统的建设，看看某UGC视频网站数据中心负责人怎么说？

笔者背景

2010年至2016年分别供职于国内某著名邮箱服务提供商以及某UGC视频网站，负责数据中心的建设与维护，以及商业智能系统开发。

引言

在这个言必称大数据、数据驱动、用数据说话的时代，人们越来越意识到整个社会的产业正在向数字化方向发展，企业越来越意识到数据对业务发展的重要性。大数据技术在过去的数年间飞速发展，开源技术以及企业级服务及应用的流行使得过去制约海量数据分析的诸多性能问题不复存在。无论大型企业还是中小型、初创企业，都希望享受到大数据技术发展的红利，利用数据辅助企业决策，指导企业产品开发以及运营工作。但是很多企业只听说数据驱动的好处，真正到落实的时候，会因为缺乏经验而遇到诸多问题。商业智能作为大数据业务发展的第一阶段，对企业发展有着举足轻重的作用，也是问题最多最集中的一个业务板块。因此本文将与读者们探讨分享笔者过去几年，在商业智能业务建设过程中所遇到的典型问题以及问题的解决思路。

1企业关键业务人员对商业智能的认知以及知识储备

之所以首先探讨这个问题，是因为笔者发现普遍企业存在一个问题，就是企业的关键业务部门中数据接触、使用数据的人员对数据缺乏足够的认知和知识储备。

这里所说的关键业务部门包括了产品部、运营部、市场部等日常工作中需要数据支持的部门， 这些部门中与数据打交道的人员都应该对商业智能有一定的认知，以及掌握与数据相关的基本职业技能。包括术语概念(度量、维度等)，数据分析的基本方法论(对比分析、交叉分析、回归分析等)，数据可视化的几种主要形式。

也许有人会有疑问，这样对产品经理和运营人员的要求是否合适。举个例子，这些岗位的人员是数据的最终使用者，就好比上阵打仗的士兵。数据开发人员就好比开发制造兵器的兵工，士兵要拿着兵工制造的武器上阵打仗，那么就必须要对所持有的武器有足够的认知，并且知道如何利用武器打胜仗，不会用枪的士兵是不可能打胜仗的。所以如果数据的使用者没有掌握数据相关的基本技能，就会衍生出以下问题：

1.随意提需求。在还没有想清楚该用什么数据，用数据解决什么问题的情况下，先随意提一些需求给商业智能开发人员，开发人员做出数据来以后，需求提出者又发现不是自己想要的，造成资源的浪费。长此以往，技术人员会觉得业务人员不懂数据，自己的工作没有发挥价值。业务人员会觉得技术人员的支持力度不够。

2.不懂得结合业务状况对数据进行再分析。数据是死的，人是活的。商业智能要解决的问题是如何呈现数据的问题，它的输出是报表以及图表等数据可视化成果，但报表和图表所反映的问题需要人来结合具体业务去挖掘和分析，但实际情况是很多产品和运营人员面对一堆报表和图表不知道从何入手，只看到了数据涨了还是跌了，却不知道如何再深入分析，数据自然也就没有发挥出它应用的作用。

3.不懂得如何提需求以及一个需求的执行过程。笔者在工作中曾经不止一次遇到过这样的场景：一个新入行的产品经理向我提了一个这样的需求：麻烦你帮我算一下过去一段时间活跃用户的情况。我说这个需求我执行不了，因为需求存在那么几个问题：

a.过去一段时间是什么时候到什么时候，不清晰。

b.如何定义活跃用户，不清晰。

c.什么叫活跃用户的情况，是活跃用户登录还是消费还是别的什么行为，不清晰。

d.数据应该以什么形式输出，报表还是图表，如果是报表，结构是怎样的，如果是图表，是柱状图还是线形图还是饼图，不清晰。

这个故事还有后续，当我耐心地与该产品经理沟通清楚上述问题以后，该产品经理说：你先算出来看看，时间区间是一年，我十五分钟后要。我说这样不妥，因为又衍生出几个问题：对于一个拥有5亿注册用户的产品业务来说，数据规模巨大可想而知，就算做了中间结果计算存储，要计算一年期的数据也要耗费不少资源，而且按当时的情况，需求也难以在十五分钟内完成。而且产品经理当时的语气让我感觉到，其实他并没有想清楚算出来的数据要怎么用，没有带着问题和明确的目标来提需求。

上述场景在我的工作过程中经常出现。所以，对于想做好数据业务，特别是商业智能的企业，我的建议是：首要的任务是在招聘和培训的工作中，重视数据终端用户的数据相关职业技能以及明确数据沟通开发流程，让数据需求提出者带着具体的问题来提需求，并且清晰知道如何使用产出的数据应用到实际工作中。当然，一个业务的健康发展是多个相关部门通力合作的结果，业务人员要对相关技术有一定的了解，技术人员也要懂业务，懂得站在业务人员的角度去看待问题，懂得换位思考来进行开发工作。

2商业智能系统的选型及建设

笔者几年前刚参加工作的时候，大数据还没有像今天那样广泛地被人们所熟知。我的第一份工作就是要处理一个拥有5亿注册用户的产品所产生的数据。我的工作是要完成日志分析与统计(现在很多人把这个过程称为ETL)，把原始日志统计成基础数据并加载到数据库，然后进行数据可视化工作，把数据库的数据制作成web报表和图表，供业务部门的同事查看。当时我还没接触商业智能的概念，我们管这套系统叫报表系统。我们当时的那套系统，是使用J2EE开发的，开发之初，我们认为一切都很简单，无非就是按照产品部和运营部的需求制作他们所想要的图或者表，但随着业务的发展，事情变得越来越艰难：

1.需求总是不断在变化，按照需求辛辛苦苦刚做完一个线形图，产品经理说需求要改，改成饼图，然后刚做完又说要改成柱状图，我们总是在需求更改中疲于奔命。

2.报表系统的架构设计之初没有考虑之后的扩展性，使得需求开发和需求更改周期越来越长，技术同事为需求日夜加班的同时产品和运营同事总是抱怨技术同事不能及时响应需求。

3.需求不断增加不断修改，使得数据的正确性难以保证，报表量越来越大，报表背后SQL也越来越多，SQL难以管理，经常写错难以发现，数据库物理表之间的关系错综复杂，报表与报表之间背后的web逻辑耦合严重，其他部门对数据部门的数据总是质疑，作为成本中心而不是利润中心，数据组不产出直接和终端用户接触的产品，投入始终跟不上业务的发展需要，人手总是不够，系统的迭代永远追不上需求的生产速度。

终于有一天，我们开始反思，开始耐心地坐下来共同探讨为什么总是这么累，总是有处理不完的问题。我们开始寻找解决问题根源的方法，于是我们开始向业界寻找解决方案，开始接触商业智能，我们发现我们之前忙忙碌碌的原因是因为我们总是要大部分的精力在重复的web端数据可视化业务上，而这些事情商业智能工具都能为我们解决，我们所需要做的只是选定一款合适的商业智能工具，把精力从web报表开发转化为使用商业智能工具自助式地制作报表，商业智能工具使得整个组的效率大大地提升，以往我们除了要做统计入库的代码工作以外，还得写web逻辑从数据提取数据展示，而现在只需要把数据按照BI工具的建模规范建好表并统计入库数据，即可在web端通过拖动交互式地制作数据可视化方案，而且更从容地面对需求更改，只要入库数据是正确的就无需担心SQL管理的问题。

时至今日，我们已经深深认识到我们所做的报表系统和真正的商业智能工具是有本质区别的，我们所做的报表系统只能是做一些常规的数据监测和业务指标汇报，但若要使得数据真正发挥作用，就必须通过交互式的方式从不同的维度和切面来分析数据，才能找到数据背后隐藏的知识。

过去几年，随着大数据行业的整体发展，商业智能技术也跟随着潮流的发展而被更多人所熟知。企业级BI工具领域也涌现出多家优秀的国内厂商，一举打破国外厂商垄断市场的局面，而且国内厂商的服务和产品价格更亲民，使得大部分的中小企业都用得起。与此同时，BI工具的发展也越来越往敏捷型方向发展，简单的安装配置即可使用工具自助式地进行数据可视化，数据分析挖掘工作。

但出于各种原因，目前很多企业依然不会选择商用的商业智能工具。笔者目前所在的公司就是采取自建报表系统的方式来应对业务，因为吸取了之前的经验和教训，所以现在再开发报表系统就会更加注意不要再犯之前的错误，对于也想自己开发适合企业自身需要的BI系统的读者，我有几点经验和大家分享:

a.在开发语言和前端框架选型上要多做调研和考虑，目前我选用的开发语言是python，选用的前端框架是百度开源的echarts，在实际开发的过程中感觉效率还是要比J2EE架构的要轻巧灵活。

b.在设计中多考虑SQL的管理问题，最好能够做到SQL语句可配置并集中管理，并随着业务的变更及时检查和修改SQL语句。

c.与业务部门多沟通，如果是临时性需求或者是之后可能会频繁变更的需求，可以考虑选用ELK(elasticsearch+logstash+kibana)来辅助完成需求，ELK的特点是安装配置使用都方便，但使用方式对非技术人员不太友好，但可以用来做原型开发和应付临时紧急需求。又或者可以用excel来做最终系统的原型开发模拟，和业务人员确认最终的web报表样式后再进行系统开发，减少需求变更反复带来的消耗。