BI分析系统的数据收集
数据源分为内部数据和外部数据两部分。对于To B业务，内部数据是零售业的供应链仓库和GMV的细分数据等业务数据，金融业的事务流和控制模型(风控模型也包含用户行为数据)等，对于业务或产品，除了基本流量数据、业务数据外，还有用户行为数据等。这种内部数据收集是更基础的，可以通过常规的CS/BS接口数据交互来执行数据收集。对于c端产品，收集用户行为数据更为重要。在这里，我们要做好数据掩埋工作，深入到每个事件的节点。
对于这些日志收集，在要求范围内，收集地越详细越好，因此可以准确地确定问题。BI分析系统是技术支持、运营战略或产品设计问题。我还见过一些web应用程序记录每次拖动或单击的动作，然后返回给服务器。这种高频传输方式可以保证数据完整性，但高并发性会给服务器带来一定的压力。产品王在需求审查会上提出了这些要求和担忧，提前向D团队通报这些业务方案，并提出相应的对策，下面简要说明了数据处理中一些技术的方案。
BI分析系统内部数据都是属于自己的，只要权限允许，就可以进行进一步的删除调查，但是外部数据大部分是不公开的，需要购买的，有些是没有地方购买的，外部数据的结构不同，所以在数据分类时会出现问题。对于可以买到的数据，经常需要清理数据。
理想的数据BI分析系统是什么样子的？
BI分析系统在后台处理数据时，可以选择执行GUI和SQL操作。以下所有功能仅说明GUI状态的使用情况，而不说明SQL状态的使用情况。保留SQL功能的原因如下：因为Bash比GUI界面的意外概率要低得多。纯SQL操作比GUI操作更稳定，数据开发更喜欢使用SQL。这种保险设计在产品迭代过程中不经常使用，从而实现了缺失的功能。
下面按照操作过程说明了BI分析系统每个模块的功能。
在生产环境BI分析系统中，将生成业务数据、流量数据或其他数据的元数据，并将其存储在数据库中。这个分数被称为“数据源”。此功能的页面称为“数据源管理”。在整个后台，数据源的唯 一权限是“选择”(select)。否则，故障可能会造成损失。这个锅真不好。用户(操作、数据分析师、数据工程师都称为用户)可以读取数据源库表中的元数据并将其存储在数据库中。这部分提取的数据称为“数据集”。许多数据每天定期或根据不同的周期处理。例如，数据的误峰处理，比如关于避免服务器并发的时间段的数据统计，大部分时间都放在凌晨或其他服务空闲的时间段，为了节省用户精力，防止遗漏，这些周期性的点控制操作是有意义的，但单个操作无法满足对复杂数据的处理需求。使用MySQL的“事件调度程序”(Scheduler)和“触发器”(Trigger)的设计理念，连接这些任务，使其根据指定的条件依次执行，BI分析系统从而实现按顺序处理数据结构和数据内容的任务循环。数据集操作生成的库表的其他删除权限控制在初始化时默认情况下仅对用户自己开放，如果需要，以后可以在权限管理中配置。
