黑道学生4txt下载BI，Business Intelligence的简称，顾名思义，也叫做商业智能。其主要价值，在于通过一系列的数据技术，从数据中挖掘隐藏的客观规律，总结这些规律背后的原因，并用于指导公司业务的发展。

　　大多数情况下，BI分析师的工作，就是通过SQL、Python等语言，将已经统计好的数据，结合数据模型或者是分析框架，来对业务进行各种分析，并做成有价值的报表或者报告的形式，供业务方进行分析。

　　很多人并不清楚数据报表与数据分析的区别。数据报表的重点，是使用相对简单的数学方法，来对历史数据进行展示和呈现；数据分析的重点，是采用更复杂的计算逻辑，并能够预测一些特定的问题、识别因果关系、确定最优解决方案的方法。可以说，数据报表“更广”，数据分析“更深”。

　　从数仓的视角看，数据工程师的第一目标，便是通过事先预处理好的数据，支持业务及分析师的数据探查需求，因为数据系统能够极大的降低数据使用的门槛，简化分析师或者是业务对于数据的理解成本。

　　但仅仅完成第一目标并不够，我们需要体现自身的价值，就需要向第二目标迈进，即价值增量。

　　如何体现BI的价值增量，并不像AI或者智能那样，是一个比较泛化的概念，而是有实际的思路。例如，我们要出一份报告，针对某个特定的问题，而如何描述这个问题，以及针对问题的原因，要做怎样的动作，通常有如下的分析思路：

　　而这几类思路的实现，对数仓的要求，都是相似的：即提供一种完整的数据探查与反馈链路。而这种需求，对数仓的要求，就不仅仅局限在维度建模理论上，而是要求将BI系统、模型系统与反馈系统集合起来应用。

　　因此，我们做需求的思路，就需要围绕“BI分析周期”展开，而不仅仅是follow产品或运营的需求，这就需要我们自己有做产品的意识，为自己做的产品负责。这种情况下，我们与产品或运营，其实是一种合作关系。那么对于BI产品的建设，数仓来负责，应该有怎样的套路？

　　识别异常。通过已有的报表，能够快速定位“出了什么问题”或“问题在哪里”。可以通过BI系统的着色工具，用于标记有问题的数据部分，快速指导分析人员关注重要的业务时机或者有问题的数据。

　　确定异常原因。通过额外的数据处理，做对比验证，包括将数据进行关联、排序，或者是外部的数据（天气等）。

　　提供决策方案。在已有因果关系的基础上，设计模型以评价决策供选方案，而数据仓库丰富的历史信息，辅助以数据分析模型、数据挖掘算法，正是评价决策效果的宝库。

　　采取行动并跟踪结果。BI系统所发现的问题，能够通过其他应用程序，反馈给运营，并及时采取行动。

　　大多数情况下，如何对问题数据进行分析和处理，都存在了分析人员的大脑里。但是，综合性的BI系统，应当是能够超过标准报表的应用范围，通过对业务形式的判断，来主动的“指导”用户，最终帮助他们做出富有见地和深思熟虑的决策。

　　同步工具：提供基本的数据同步功能，支持多数据源的导入，允许用户自定义结果集。

　　看板展示：是预定义的、预先编排好格式的报表，一般提供某个层次的用户交互，比如输入参数，向下钻取到较低层次的细节数据，以及链接到相关报表等。

　　仪表盘：一般是由报表和图表组合而成的，能够突出数据的相关特征，并提供向下钻取的功能、或者异常高亮等功能，能够对多个业务过程的数据进行交叉分析。

　　分析性程序：根据对业务过程的决策分析进行管理，比如发起会话、生成文案等。

　　权限系统：支持定义查看数据角色，通常要支持到卡片粒度，高级一些的能够支持到行权限。

　　当然，很多时候，分析师对于BI系统的需求是非常个性化的，例如报表的样式希望能够自定义、或者是读取数据量超级大的明细，并且提供一定的内存计算、再或者是希望将树形、图形数据的结构展示出来，而不过多的加工数据，等等。这就对于系统的功能和性能提出了非常高的诉求。其实很多BI系统，可以提供一些自定义的功能，比如支持动态SQL、支持CSS自定义编辑、支持组件拖拽方式的SQL开发，等等，但这些功能通常都有比较高的理解和使用成本，更适合进阶一些的分析师。很对BI系统在兼顾易用性与功能性的时候，容易做出一些妥协，从而影响了产品的简洁，满足了一批分析师的需求，又赶跑了一批新用户。

　　因此，既然我们选择了BI系统，那么就需要考虑放弃一些过多的修饰，而把精力放在数据本身上。对于数仓同学来说，对于BI系统，并不是可以放任不管的状态，因为如果数据出现了问题，例如算错了，或者延迟了，最终还是需要数据来兜底。

　　数据集的建设：合作的分析师或者运营，如果不理解维度建模，那么我们的工作职责还需要覆盖到BI系统数据集的建设上来，协助将数据的同步、组合与注释，相对应的标记好。

　　数据同步的建设：如果离线小时加工好的数据，需要3个小时才能同步到数据库里，或者是明细数据太大，撑爆了系统或者浏览器，都算是数据故障的一种，而如果避免这些问题，同样需要数据同学的参与。如果明细确实太大，那就考虑用户是否需要这么多的明细；如果数据库性能不足，那就需要与数据库同学一同进行调优。

　　数据分析思路的提议：通常情况下，数据开发是最懂数据的那部分人，而我们BI系统分析问题的思路是什么，是应该最有发言权的。尽管我们不直接对业务结果负责，但数据系统还是应该遵循一些基本的分析思路，如果自己都看不懂，那么我们的成果也得不到承认，“行百里者半九十”，最后的十步，就是在BI系统的建设思路上了。