04
2022-12
每月只需70元，小微企业也能拥有的BI服务
我们不得不否认，这几年真的是赚钱越来越不容易了。既然赚钱不容易，那就势必要开源节流，一分钱掰成两块花。
LEARN MORE
图片来自网络，如侵删
BI虽好，可不要贪杯哦~
差不多已经是共识了，上一个BI能够极大地提高企业数字化决策能力和效率。之前有讲过小微企业选择BI的一个原则就是能外采用SaaS的千万不要自己折腾自研。但是，对于一些急需BI赋能的小微企业而言，一年10-30万的软件费用确实是个需要咬咬牙才能决定的决策。赚钱不易，能省一分是一分，在人员成本类似的情况下，软件费用当然是越低越好，相比于一年10-30万，一个月仅需70元就能实现全套BI岂不是很香。
这个每月70元就能实现的贫民窟标配BI软件就是微软家的Power BI。
首先声明，本文不是广告，仅是分享设计这一套方案的历程和踩坑的地方：
先对上述方案做一个简单的小结，有兴趣的同学可以选择继续深入了解：
①方案模式介于数仓和数据湖之间
②此方案的核心是Power BI的服务，此外还用了一些简单的Python脚本、飞书开放能力、微软的其他软件(（如office 365、windows批处理、windows定时任务等）
③数据设计思路基本参照传统数仓，但是数据呈现的原理和数仓有极大的差别
④该方案适用于较小的业务体量 短期内不会有较大规模膨胀的业务
⑤性能瓶颈可以通过Azure服务和升级license版本进行优化，性价比最高的方案是将每个月70元的Power BI Pro升级为Power BI prieum per user，每月成本为145元
⑥此方案适用于业务变动非常快的场景，调整的灵活度较高，调整效率较高
⑦方案的局限性在于逻辑复杂度较高，需要开发者对业务数据底层有非常深入的了解
为全球用户提供合规的数据服务
和一般公司选择BI方案不同的是，我所面临的业务，虽然体量不大，但是麻雀虽小五脏俱全，需要考虑的地方不逊于一个世界五百强企业。
第一个问题就是跨境的问题，我司业务的特质是服务提供者主要在国内，客户全部在境外；BI服务的使用者在境外，但是BI开发团队在国内。因此，BI设计的时候遇到的第一大问题就是跨境数据传输的问题，于是就面临了三个难题：
①业务服务数据和BI服务的数据传输不能有较大的延迟
②BI用户和BI服务之间的数据访问不能有较大的延迟
③需要符合各国数据合规相关规定
因此BI服务的选择就有了三个选择：美国（和业务数据的存储服务在一起）、新西兰（和公司法人主体 BI服务使用者在一起）、中国（和BI开发团队在一起）。
在经过对国内外数据隐私方案的研读和实测数据访问速度后，第一个排除了部署在中国这个方案，首先是数据传输问题，但就写SQL提数就会遇到网络问题，更别说BI服务了。其次是合规问题，这涉及到了大规模数据传输入境的问题，美国的法案和欧盟的法案看着就让人头疼，真的是没有个专业的顾问，分分钟在违法的边缘试探了。
在对各种法案进行深入研究之后，发现将数据服务部署在新西兰是合规性问题最小的，于是最早一版方案选择了将服务部署在新西兰。然而很快就被事实打脸了，服务部署在了新西兰依然解决不了网速的问题。但凡是做过数据的同学应该能感受到那种痛苦，随便写一个SQL执行都得100秒起步，BI服务基本处于就没刷新成功过的状态。眼看这样不是办法，马上就着手开始了解决。
经过和微软侧的沟通确认，造成数据更新问题的原因，网速只是微不足道的一点，根源在于我将BI服务放在了新西兰，数据网关放在了国内，原始数据又在美国。我们的数据在三国之间传输，稍微有一点网络问题就会导致看板刷新异常。
还好这个时间点，BI看板的开发都还处于很初级的阶段，于是我果断选择了服务迁移，将BI服务整体迁移到了美国。并配置了一台windows的虚拟机，用来搭建网关。至于为什么要用windows虚拟机做网关而不是直接用azure的虚拟网关，主要原因在于我们实操中少不了一些原始数据需要用python处理的情况，虚拟机上可以同时注册个人网关用来跑这类看板，和后续会介绍的其他定时任务。
数仓和BI整合来源于外部客观情况
早期1.0版本的时候，和很多BI设计的理念类似，数仓是数仓，BI是BI，是完全脱离的。
由于公司业务体量偏小，单建数仓团队，不是这个体量的业务能够负担得了的。于是就开始琢磨起了和研发进行资源共用的方案。由于的架构采用了微服务的架构，所以我们如法炮制，可以直接借用微服务架构的特性，直接做一个报表微服务出来，实现数仓的功能。
起初，这个方案是非常有效地，解决了各种口径不一致的问题并且很有效地完成了看板的支撑。但很快就冒出来了新的问题：人的问题。
由于这个方案依赖了传统java开发人员，而对开发而言，这种类似数仓的开发多少有点泯灭人性。加上微服务的架构导致研发人员可能还没有数据人员了解底层的数据，这种模式对于灵活度的高要求是有挑战的，有些逻辑的改动，对于研发人员来说需要较大的沟通成本。
于是开始被迫进行2.0版本的研究：既然BI工具都会带有基础的ETL功能，为何不加以利用呢？于是就有了基于power bi数据流的设计方案，直接利用power bi数据流搭建一个类似数仓宽表的东西出来。
设计拆分的思路就和传统数仓类似了，但是更加简单一些，只需要拆分两个层级：原始数据表和专门拿来统计用的datamapping。原始数据表其实没有必要从业务数据库去同步原始的数据，用SQL直接加工好的宽表就可以了，个别复杂的业务，可以先做一个视图，在视图的基础上再去加工宽表。至于拆分映射表，这种东西对于绝大多数分析师而言都是手到擒来，唯一需要注意的一点就是预判那些东西是可能修改的。
有了原始数据和映射表之后，下一步就是做统计指标的加工。业务体量小就是为所欲为，直接用dax做加工，维护在数据集中。各种个性化的数据呈现看板需求就用加工好的数据集，做看板呈现。
懂得都懂，业务早期，统计指标改算法是很正常的事情。写在dax里面，可以少写很多东西，按照数仓的做法，改一些关键指标的计算公式，那可真的是需要改很多地方，改到怀疑人生的。用dax来写，可以有效减少需要改动的地方。
BI工具之外
其实这一套架构除了Power BI自身的强大能力之外，还用了其他的一些其他的辅助。
比如一些指标，数据量较大，比如APP的DAU，一般也不会下钻明细查看。就可以用python脚本实现每天计算一次，存储在中间表中。
除此之外，还有windos批处理和定时任务，配合飞书的开放能力，实现定时报表推送邮件或者推送飞书群的工作。
这些外部工具中，应用最多的还是Excel，一些不容易通过dax实现的内容，则可以通过用Excel直接调取数据流的方式进行数据获取再加工。
配合上这些外部工具，一个完整的数据服务体系就完成了。虽然没有用什么高端大气上档次的技术，但是对于一家创业公司来说，者已经足够了。
至于成本，70是最小成本啦，实际操作的时候会比70大一些，取决于采购几个账号嘛，一个账号是最低的。至于采购账号怎么采购的问题，这不太道德，我就不说了。
P.S.
偶尔遇到需要装逼的场合，还可以把Power BI 集成在Power Point中，玩一波无形装逼
THANKS
做数据的二号姬
