最近负责BI项目研发与上线，自认为驾轻就熟，但在沟通方面遇到各种困难，在一些问题上摆平各方的质疑或者争执真的需要水平，作为架构师，我的模型设计和整体系统设想必须过硬才行，否则难以服众。梳理如下几个方面：
1. 工具选型
通过调研，当然主要是以我2年的tableau经验为主，我推荐单位采用它作为BI开发的工具，但是产品经理没有使用它的经历，设计的BI产品原型与tableau的设计理念相距千万里，以数据分析为主要应用的经验让我面对这样的开发失去了方向，主要是原型讨论的时候我没有很用心，那是对业务也没有深入了解和掌握，看看图表和数据确定不会有什么问题。直到要进行实际开发才发现遇到很多问题，第一、菜单项和Tab页，tableau server上并不支持顶部和左侧菜单项设置。第二、同环比计算，我在做数据模型的时候，认为凡是所谓比率的计算均放在tableau中以计算变量的形式提供，基础数据表均为基本指标值。
2. 计算的权衡
承接上述第二个问题，所谓比率，包括两种：
第一、同环比。考虑业务需求灵活性和及时性的平衡问题，在数据源实现各种指标的计算，将失去同环比计算的灵活性，且按照天、周、月、季这些时间维度层级进行计算则底层的数据计算将变得非常浩大；但同环比必须读取若干天的数据，在tableau前端实现各种参数设置、计算字段创建，计算效率有些损失。
第二、转化率等，比如APP portal的内容维度分为页面、频道和内容三个层次，计算频道与页面的占比，需要在一行计算中存在频道和页面的相应指标数据，问题在于根据维度层级不在一行中，比率指标计算不出来；若在一行中，需要如上进行计算字段的创建，计算效率上就降低了。此种情形下，只好修改数据模型。
3. 数据模型
根据BI原型和对业务的理解，首先划分主题，再根据主题确定维度和指标，最后由此归纳出数据模型，确定各个字段。在讨论模型的时候，开发觉得难度很大，我把内容各个维度级别的指标放在一行中，实现起来难度比较大，他们说应该存在互斥的指标，就是一行中存在这个指标，另一行中存在另一个指标，整张表存在大量空值。我们采取的计算平台是SQLDW，我内心深处非常排斥的微软云AZURE的那款工具，不过上有leader推动，只好用它了，我告诉他们这是列式的MPP数据仓库平台，没有问题。后来他们一再坚持只好归纳为一个维度层次，再就是各种其他action，比如登录、验证等也划入页面，本来我认为根据其他维度作为一个指标的，最后归入页面的UV、PV，后来证明这样也是可行的，但是后来又要在一行中实现内容各种层级指标的计算，再次折腾回去。
UV这样需要去重汇总的指标，需要通过with cube计算，偏偏SQLDW暂时还不支持with cube这样的窗口计算，工程浩大，我向leader诉说原委时，leader告诉我用那么长时间进行选型，现在才发现这个问题。作为架构师发言不当事的时候，这个选型本来就不是我主张的，只能这样。
4. 数据源迁移
开始开发的时候是一套旧的日志系统，当开发接近尾声的时候新版日志系统已经将要全面铺开了，此时我心中的洪荒之火无从燃烧，只好去改了。作为主导者面对这种场景一定要稳重，不能急躁失去分寸，特别是不要让领导对你失去信心或者觉得你不可靠，如果这样，而且项目延期，那就乱套了。
