背景
在YZ公司不知不觉也已经3年了，期间一直在做指标相关的平台开发工作，有一些感悟、经验（成功和不那么成功的都有），也有一些困惑与思考，想记录分享一下。
这篇文章主要是偏向业务和方法论相关的，不会涉及到太多技术细节。
1. BI平台
1.1 功能与实现简单介绍
BI平台是我在YZ做的第一个和指标相关的平台，自认为做的还是比较成功的。
自己作为负责人，基本是从0开始搭建，从1.0的用户自行写SQL，BI只作为展示工具，到2.0用户拖拽字段，各种复杂的行列总计、行列权限、计算字段、联动下钻等功能的实现，把BI平台打造成数据中台核心的平台之一。
YZ BI平台的大致功能和实现原理可以查看我发表在公司技术博客上的一篇文章：
https://tech.youzan.com/principle-on-bi-platform/
技术架构图（功能）：
如果是从0开始搭建BI平台，可能会遇到系统功能建设方面会不知道怎么实现，特别是后台的实现。前端因为大家都看得到，分析方法也都类似，常用的基本就是X轴，Y轴，筛选过滤，排序等等。
而后台的实现网上文章到是也不多，毕竟是赚钱的东西。我自己和一些观远的同学也交流过，面试也问过一些其他做BI的同学，感觉好像没有什么非常统一的实现， 拼SQL可能是一种方案，但是怎么拼，好像也都各有各的方法。
1.2 方法
1.2.1 系统功能方面建设
BI（商业智能）的概念真的已经提出了非常非常久了，业界不乏很多优秀产品（核心功能大同小异），如果是从0开始做的话直接试用一下别人成熟的产品，然后照搬基本就能做起来。
一些我参考过的认为非常不错的产品：
网易有数 https://youdata.163.com/
有数是我个人觉得国内做的最棒的BI产品了，基本没啥上手难度（也可能是我本身就比较了解BI系统）
观远 https://www.guandata.com/
YZ的BI系统（前端与交互）主要是参考观远做的，相比有数，需要有一点点数据分析的基础，但是也是挺好用的。
之前和观远的大佬们也交流过几次，他们现在主推AI+BI，因为国内各大BI平台基本已经很成熟了，该有的功能都有了，核心功能可能大家处于伯仲之间，需要有一些其他的发力点。而现在不是流行数智化吗，所以希望借AI赋能BI，提供更智能的数据分析吧。
之前观远的一些分享会也去参加了，但是感觉其实AI和BI还是2个产品分开卖的，AI最终展示用到了BI而已。当然，真正能融合的产品，基本没怎么见到过。
bdp https://me.bdp.cn/home.html
一个免费的小巧但是精美的BI软件，除了观远，我们也参考了部分BDP的设计。部分功能真的挺好用的，自由下钻等功能比观远的好很多。
1.2.2 和BI分析师同学紧密合作
讲真，BI平台我觉得是个比较容易做起来的平台，因为绝对不用担心做了没人用。
他们对用户使用场景很熟悉，我们对成熟产品很熟悉，这是强强联合
产品，运营的取数需求基本是提给BI分析师同学的，他们对使用方很了解，但是他们对产品的形态，功能交互这些不懂。所以我们需要做的就是参考业界比较成熟的产品，当他们提系统功能需求的时候可以非常快速的找到到底对应成熟产品上面的哪个功能模块，然后基本照搬一下，就能搞定。
千万不要忽略BI分析师的述求，直接完完全全直接CV别人成熟产品的所有功能，至少分个优先级，就从我们自己的BI系统来看，80%以上的用户，真的就用用行列维度，全局筛选过滤下数据就行了，甚至下钻联动这些功能都很少用。
他们可以帮助我们推广BI系统，带来UV，PV
这点真的很感激他们，与他们协作，上了新功能以后他们会帮助我们推广给新的业务方，为平台带来新的用户。
更妙的是，大数据平台做为一个二线支撑团队，很多平台的用户仅仅只是业务开发、数仓等（比如离线调度平台），那UV能有多少？而BI平台的潜在用户是全公司，谁会不关注指标报表？KPI不需要量化一下？量化的指标是你自己说了算还是以BI出的口径为准？更进一步BI分析师是需要为公司决策服务的，会有各种面向老板的看板，只要BI平台功能足够精美，就能给老板留下不错的印象，这是其他数据平台不具备的优势。
2. 自助分析
自助分析确切来说不是一个单独的产品，是在BI平台上的扩展，业界也看到了一些类似的产品，比如网易有数的自助取数（名字大同小异吧）
我们的自助分析：
这个产品我自认为做的挺成功的，下面我想介绍一下它出现的背景，意义等。
2.1 自助分析出现的背景与意义
上面这张图是网易有数的报告制作界面，可以看到它和前面的自助取数几乎一模一样，除了自助取数好像简单那么一点点，在对数据分析的方法上几乎一样（选指标，选维度，加一些过滤条件，blablabla）
既然有了BI系统，为什么还要搞一个自助分析（取数）呢？或者说自助分析的意义是什么？
2.1.1 传统报表开发流程中的问题
从功能上来说我觉得自助分析相对于BI不是什么创新，最多加强了一点点（其实我觉得反而砍掉了部分不常用的功能，是一个简化版的BI）。
但是它在职责划分，开发流程改善方面有非常大的意义。
传统BI项目报表的开发流程大致是：
1. 需求方（产品、运营、客满、服务等）提出报表看板需求给BI分析师
2. BI分析师基于数仓的某些表制作BI系统的数据集
3. 基于这个数据集开发报表（复用性高一点的话可能一个数据集会对应开发N个报表，低一点就对应一个报表）
这套开发流程最大最大的问题在于数据集是针对业务场景来开发的 ，需求方给BI提的看板、报表需求基本对应他们的一个取数场景。
而场景会经常发生变化，比如客满、服务今天用24小时接了多少电话做考核标准，明天就可能会改成24小时解决多少jira问题做考核标准。
BI分析师的数据集有多少复用性？如果他经验老到，非常熟悉业务方的需求，那他的数据集复用性就高一些，但是不可避免的，很多需求是要新制作数据集，新制作看板，报表去满足业务方的需求的。
上图是我们需求方提给BI同学的需求数量的变化趋势，2018H1-2020H1 公司人数大约*2~*3左右，但是需求数量大约*20
所以BI分析师不可能依靠堆人力的方式来解决这个问题，同时如果BI分析师认为自己的本职工作是做做报表就完事了，那他对自己的定位要求也太低了。
BI分析师的最要精力应该投入到帮助高层决策上，比如调研报告，行业分析，量化研究等。而不仅仅只是制作看板，报表，被动满足取数需求。
需求数量的爆炸增长与BI分析师资源的限制不可避免会产生矛盾，取数需求排期不断延长，面向高层决策的分析报告缺少人力投入......
那如何解决这个问题？
2.1.2 自助分析实现了报表制作与模型制作的解耦
我们再来看一下开发流程
1. 需求方（产品、运营、客满、服务等）提出报表看板需求给BI分析师
这一步暗含的操作是：
BI分析师需要明确需求以后确定指标的口径，这一步只能BI同学来做
2. BI分析师基于数仓的某些表制作BI系统的数据集
数仓的表是按照维度建模来制作的（可能不是大宽表），有明细层表也有略微聚合过的表。
BI系统因为性能问题，可能会需要大宽表，或者聚合粒度相对来说高（BI groupby的字段比较多，削减了很多维度）一些的表，同时BI指标因为不是非常通用，所以BI的表基本是属于DM层（ADS应用层），这一层数仓同学一般不会去建。
所以这一步，制作数据集也是需要BI同学来做的。
3. 基于这个数据集开发报表
基于已经有的数据集开发报表需要做什么操作？
现代BI系统已经足够简单，用户无需编写SQL，拖拽字段(维度、指标）就能快速进行分析。这一步无论是BI同学来做还是业务方来制作其实都是可行的，甚至业务方同学来做更加方便合理，因为他自己知道要什么过滤条件，要怎么使用这个数据。
因此，我们可以这样划分大家的分工来做优化：
BI分析师：
1. 确定需求方指标的口径，这一步和以前一样。
2. 基于数仓中间层表简单包装一下，制作满足业务方使用的通用数据模型（数据集）
业务方：
3. 使用通用数据模型，自行拖拽字段，分析数据，制作报表
这种合作方式实现了报表制作与模型制作的解耦，砍掉了BI分析师制作看板的时间，从实际经验来看，节约了大量时间（主要是报表，看板配色，样式等等花了很长时间）。
同时业务方也是满意的，因为比如本来提一个需求可能需要排期5天，等不及。他自己上手来做可能半天就能搞定，也是加快了需求被响应的速度。毕竟求人不如求己。
那么什么是通用的数据模型？
很遗憾，目前YZ并没有非常清晰的文档，就我观察，还是需要一定的经验判断，好在这边每条业务线都有对应的BI同学，自己维护自己的数据模型并不算困难。
举个例子，用户提的第一个需求是我们要24H的接通电话量。最佳实践是制作一个数据模型，里面是明细数据包含了每一次电话接通的时间，用户可以自己在自助分析模块内，通过时间粒度将时间按天聚合，count次数得到接通数量。
当然，因为性能考虑，BI同学直接制作一个数据集包含了24H的接通量（BI在库表层面聚合了一次，落成hive表，而非在BI系统内聚合成逻辑SQL），我觉得也是合理的。但是当用户下一次需求提出需要7天的接通量的时候，这个指标不应该在重新制作一个数据模型，而是应该在原本的数据模型上增加一列。如果是使用明细数据，就没有这个问题，指标都是用户自己制作的。不管哪种方式都是合理的，只要不新增数据模型即可。从实际管理经验上来看，大家做的还不错。
2.1.3 小结
总结一下自助分析吧，相对于BI他并没有提供什么特殊的功能。可以把他看做是BI系统的扩展，通过解耦报表制作与流程制作流程，提升了人效，满足了日益增长的报表取数需求。
3. 指标库
YZ数据中台下的数据相关的平台还是挺多的，离线调度平台、BI平台、元数据相关的平台......我们也有一个前端发起的项目，把众多独立的平台通过统一的URL入口打包成一个一站式的，解决方案似的大平台。
目前中台整合各个平台的做法我还是挺认可的，但是我觉得我们离真正的数据中台还是有一些需要完善的地方的。
我认为各个独立平台仅仅是通过简单的打包在一起是不能称之为数据中台的。中台和平台组合区别是什么？我的理解是复用性。
复用性带来的好处或者说目的就不再多说废话，什么提升人效了，快速赋能业务啦，blablabla。
那么怎么体现出复用性的，为什么各个平台单独使用就没复用性（或者说比较小）？
我认为主要体现在下面2个地方上：
1. 数据的复用性
2. 经验方面的复用，方法论的沉淀
3.1 数据的复用
数据的复用性与数仓团队紧密相关。
数据中台的数据来自哪里？可能入口有千千万万，但是都会汇总到数仓这边做统一的ETL加工。
为什么需要有统一的数仓，大家按组织架构的划分，每个小团队各自加工数据不好吗？
还真的不太好，主要是2个原因，口径与重复开发的问题
3.1.1 口径
数仓同学制作表的时候需要按照维度建模的思想，构建一致性的维度，同时按照业务过程组织事实表。
这样做的目的就是为了在不同组织架构的报表（或者其他数据接口）中保证定义的指标的口径是一致的。
支付金额要不要排除邮费？店铺是怎么分级的？这些在数仓这边必须有统一的定义（维度和指标的确定），不然我按我的理解出数，你按你的理解出数，每天出报表的时候就是不同部门天天撕逼。这样的数据是没有复用性的，甚至连用都不能用。
3.1.2 重复开发
一个公共指标如果数仓已经开发好了，那不允许再次开发。原因很简单，多一个入口，多一份维护工作量，口径要修改，2边都要修改，改不全，客户天天问为什么2个地方同一个指标数值不同。
同时，重复开发会造成浪费资源。
因此，公共层的指标需要由数仓统一提供，收口。
3.1.3 数据复用小结
工具平台是同一个工具平台。有一个专业的数仓团队，通过规范的建模，打造口径统一的中间层，相比于各个小团队毫无规范的使用工具，在数据的复用性上会带来截然不同的结果。
3.2 经验方面的复用，方法论的沉淀
假设我们出去给其他商家推销我们的BI产品，我说我们BI产品有 12345，XXXXX功能，好用、NB得很。
我想大概率商家会觉得是我一个SB，然后心想：你的系统NB跟我没关系啊：
1. 我的需求没有解决啊，我想要的（问题的解决）和你能给的（系统）之前没有建立桥梁，我完全不知道怎么用你们的系统来解决我的现实问题。
2. 就算你们的系统能解决我实际的问题，买来以后对我们这边的人员素质有什么要求？是买了你们系统，我们随便一个应届培训2，3周就能上手，还是需要再招几个资深的BI分析师？
所以一般卖中台产品的时候不会只是仅仅卖一个系统平台，也不会仅仅是卖用户数据。卖的是数据+工具（系统）+如何使用这些数据解决用户实际需求的方法
还是以刚才的BI举例，一般会这样卖：
1. 我们的系统NB，功能该有的都有。（这个还是要吹的）
2. XXX公司买了我们的BI系统，给一些使用案例，分享几个给他们制作的看板，图标，效果很好。（带上同行案例，证明你们的需求我们是可以解决的，是这样解决的）
3. 我们对于你们这个行业，有一些通用的分析案例，内置了一些核心指标看板，指标，简单好用，谁都看得懂，通过这些内置的强大功能，谁都能快速上手成为分析专家。（我们很专业，我们能给的比你们现在想要的还多，你们买了我们的平台不需要有非常多的专业知识，这些分析相关知识与方法我们都沉淀下来，做进系统里了，就算没有现成的，在我们基础上修改修改就能快速满足新的需求）
第一点、第二点体现的是我们系统是完善的强大，又贴合业务，主要是工具层面的。
第三点体现的是我们不光有工具，还因为我们接了大量行业客户，我们沉淀出了一套解决这个行业问题的通用方法，通用解决方案。我们将这套解决方案（这套解决问题的方法论）做进了系统里面，即使是小白用户，没有专业的分析能力，通过我们的系统引导可以快速制作出专业级别的分析看板。同时我们内置的这么多行业常用的分析看板、指标，是我们的经验沉淀结果（方法论操作多次以后在数据资产方面的沉淀），这些指标、看板对于行业内的任意商家都是适用的，可以复用的。
3.3 数据中台与数据平台小结
通过把各种各样解决问题经验与方法沉淀到系统中（比如数仓中间层建表规范：本来调度平台只是一个工具，可以随意建表，现在对库表字段名称，层级等都有明确规范要求，平台做限制），将各个平台连通在一起（元数据与调度平台，调度平台与BI平台等等），让不懂大数据的小白用户（也可能是普通的业务开发）通过平台的引导，能够像专业大数据人员一样高效的加工处理数据（从业务数据库到数仓hive清洗数据到最终的产出，比如BI看板报表等），同时将数据加工的结果在系统中沉淀，形成数据资产（指标等），保证数据的复用性，这是数据中台区别于各个平台简单堆砌的地方。
3.4 指标库
扯了那么多自己对中台的理解，这和指标库有什么关系？有关系，而且有很大的关系。在真正介绍指标库之前，我想梳理一下YZ数据中台开发的流程，一些问题，与我的思考与我想要做的改变。其中有部分问题可能是有YZ独有的，但是也有一些可能是其他公司在业务快速发展过程中也会遇到的。
3.4.1 YZ数据中台开发流程
大致开发流程如上图，无外乎几个步骤：
1. 业务方Mysql数据、日志数据、Hbase等数据导入数仓ODS层hive库表内
2. 数仓对数据加工分层，构建事实表，维度表等，得到dws（我们叫dws层，是个明细层，对应业界的dwd层，其他层叫法也有不同，但是类似）、dwa层。
3. 数据开发自行加工dm层，数据导入业务方mysql库，或者大数据自己这边的存储介质中
4. 业务方自己提供接口，或者走大数据这边的接口，可能是oneservice，也可能是各种Java项目工程
5. 如果是对内指标，则在第3步中由BI分析师开发bi层的表，在BI系统中建立数据集、报表、看板
这样的开发流程，过程中会有几个问题，我红色标注了。下面具体分析一下。
问题1：DM 应用层开发
首先说一下我们认知的指标这个概念一般是出现在dwa聚合层的，一般是由dws（明细层）的某一个字段（比如订单支付金额），通过某种算子（比如sum）和一些过滤条件加工得来的。
而dm层一般是给各个业务线基于数仓中间层的表构造自己特有指标（一般不共享的指标）的一层。
也就是说跨组织部门，跨业务线通用的指标一般数仓会建立，放在dwa层，而各个业务线独有的指标一般会放在dm层。
现在的问题是YZ的dm层构建缺乏规范，它的上游既可以是dwa，也可以是dws，甚至可以是ods。
前面也分析过了，指标是由某个字段（事实）经过一系列加工（算子、过滤条件、统计周期等）得来。这就会导致同样的指标可能出现在dwa，也可能会出现在dm层。
数据开发越过数仓dwa层直接开发dm会使得指标口径的问题难以管理，自行开发的口径是没有得到数仓认可的，也就是没有全公司统一的。
当各个业务线数据开发都如此操作以后会带来的实际后果就是：
1. YZ不同产品上同名指标口径很可能是不一致的（比如零售与微商城，因为2个dm层指标都没有来自数仓，都是自行开发的，商家店铺升级以后发现指标统计口径变化了，造成了困扰。举例：支付宝某用户从大众会员升级到黄金会员，同一个月份的花呗支出金额统计发生了变化，支付宝的解释：我们是2个产品，所以统计方法有区别，一个自然月，一个会计月。用户：我去你大爷......）
2. 同一个产品，在不同模块下，如果聚合到同一个粒度，值很有可能也是对不上的（比如店铺概览下支付金额与按流量划分支付金额的总额），带来很多不必要的客诉与质疑
为什么dm没有使用dwa，允许从明细层甚至ods直接聚合呢？因为有些历史原因，YZ数仓在建模方面基础比较弱，数仓起到了作用类似于数据开发，一直是面向业务线的垂直开发，所以没有建模理论支撑，本来复用性就较低。当公司快速发展，大量业务涌入的时候，数据开发不可能因为数仓排期就延误业务上线，只能越过数仓中间层，自行开发指标。当自行开发新指标后，新业务进来也会使用旧的模式。而对于数仓来说，业务都忙不过来，谁管规范和复用，先解决当下需求再说。这就是一个不断恶性循环，几个迭代以后烟囱式的开发就会越来越多，越来越难维护。
问题2：不必要的BI中间层
因为部分历史原因，YZ数仓对外的商家指标口径和BI分析师出的对内的指标统计口径是不一样的。
BI分析师绝大部分情况下只使用数仓ODS或者DWS明细层的表，导入bi自己的hive库后再自行分层（类似于数仓，但是没那么专业）出指标。
这带来的问题就是：
1. 同样指标，2倍的人力投入，BI不知道数仓有哪些指标，知道也不敢用，因为口径都没确定过，长期往复，对内对外指标差距越来越大，谁也没有完整梳理过，谁也说不清楚到底商家端指标与对内指标有多大区别，反正新需求来了，直接开发。
2. 日常沟通指标很困难，会给决策造成不必要的麻烦。大家在讨论一个指标的时候得先确认这个指标是BI出的还是给商家用的，讨论指标之前还得费老大劲再确认下口径。
问题3：没有统一的提供的接口层
虽然数据的入口是数仓，但是数据的出口没有规范，可以是大数据这边加工完成了导入业务方自己的mysql库，也可以是大数据这边不同的Java项目中的各种各样的接口，也可以是现在新起的oneservice项目。
这带来的问题就是：
1. 指标出口太多，我们很难收敛，权限，限流基本做不了
2. 很难追踪指标被哪些页面用到了，因为出口太多，各种各样，每个地方都要定制
放在实际问题上就是一张表因为调度要延期了，到底哪些页面会受到影响?
如果我们的oneservice统一了所有接口服务，那么我们可以及时告知测试、客服等同学，他们面对商家的咨询时不会一问三不知，再提jira给开发一步一步查问题。至少风险是可控的。
3.4.2 我认为理想情况下的开发流程
改动的地方我用红色标注出来了。
BI层只是DM应用层的一个case
其实BI这层是不应该独立于数仓存在的。BI的指标应该是基于数仓中间层（大量DWA，非常少量DWS）表来开发的。BI不要从ODS取数据以后自己重复做数仓的工作，划分DWS/DWA等ETL操作。
1. BI如果有自己的库表，应该归类与DM 应用层（ADS），通用指标走数仓，个性化指标放在自己这层
2. 更进一步，如果我们的DM是按业务线划分的（零售、微商城、分销......）那dm_bi其实也是可以不需要的，对外和对内指标口径也应该是一致的，不应该将BI单独列为一个dm。（不应该对外划分dm_fx，dm_retail，然后在BI内部再按业务线划分一次）
DM层从数仓DWA中取数据
非常类似于BI这一层。
DM层的开发应该从数仓汇总层的表中加工得来，不要自己从明细数据（ODS/DWS）中自行加工，因为加工过程中就是确定指标口径的过程，这一步由数仓统一收口，在DM层基于数仓的表做简单聚合即可。
如果是非常个性化的指标，也应当由数仓首先开发通用指标落表，基于这个通用指标再次开发个性化指标。
oneservice
数据相关出口，通过接口统一提供，不要把我们的一些存储介质暴露出去，比如离线计算完结果存在mysql，hbase，kylin等等。因为
1. 首先业务方不怎么会用这些组件，有学习成本，oneservice可以屏蔽底层这些不同的物理存储介质
2. 多个出口会很难管理，比如鉴权，限流，审计等操作
3. 接口被哪些业务方调用很容易追踪，数据问题相对来说比较容易排查，影响面也可控
3.5 我对指标的定位与一些想法
基于YZ的特殊情况，我觉得指标库大概要做这么一些事情
3.5.1 数仓内部
可以看①的部分。
指标库最最最基本的用户就是数仓同学，这也是个基础，这一步如果做得不太好，上层应用会很难做。
模型录入指标库
首先因为YZ数仓建模基础比较弱，所以需要逐步沉淀建模相关知识，根据维度建模的相关知识，把数仓业务域、业务过程、原子指标、维度、统计周期等等相关模型录入指标库，逐渐形成数仓的规范。
建模的规程类似于设计的过程，应该先有建模设计，技术评审通过后再去开发对应的表结构，数据。模型确定了以后不管是交给资深数仓同学来做开发，还是交给新加入的资历较浅的同学来开发，表的实现应该是一致的。
沉淀通用的指标资产
指标库很重要的一个功能就是要沉淀指标资产，对于数据中台赋能的业务方来说他们会很自然的问我们这么几个问题：1.我们有多少指标 2.指标的定义口径是什么 3.哪里可以取数，怎么取数
很遗憾，这个问题YZ现在不能很好的回答。原因是建模不完善，导致指标口径无法确定，就更不要说沉淀多少指标了。
可以说模型录入指标库是个过程，沉淀通用指标是录入的一个很重要的结果。
形成数仓建模方法论指导表设计
在数仓不断录入模型的过程中，数仓内部会不断讨论，逐步形成方法论，比如常规维度怎么从ODS里提取，缓慢变化维怎么制作，退化维度又如何处理。
这套规则可以打通离线调度平台，做到系统里，当新人来开发数仓需求时，可以用平台的这套规则，约束他的开发，指导他的开发，既能提升效率，又能保证质量。
YZ现状
目前YZ处于1，2两个阶段，存量的部分量比较大，录完需要花费较长时间，增量的指标需要100%控制录入。
尽管如此，模型相关的建设也是需要大量时间才能沉淀出来的（比如我们的业务限定或者说修饰词是什么，怎么区分）。
好在目标虽然遥远，但是还是在前进吧。
（指标录入的冰山一角）
3.5.2 上层应用
对应②的部分。指标库的本职是服务数仓同学，但是对上层应用也有一定的赋能。
打通调度平台指导个性化指标建表
参考形成数仓建模方法论指导表设计那一节，无论是通用性的指标还是个性化的指标，只是分层的不同，建模设计是类似的。
打通离线调度平台以后可以帮助开发同学快速构建DM层的指标，提升开发人效，又保证规范质量。
oneservice
YZ外部指标未来统一的出口应该是oneservice，指标可以与oneservice做集成，把页面、接口与指标等做关联。打通页面路径、指标、底层数仓表、血缘等对于查看指标影响面，报警，分析对比指标等功能会有很大帮助。
（某个商家后台的指标，是哪个产品负责的，名称是啥，产品给的业务口径是啥，统计周期是啥，在数仓这边的维度是啥，派生指标是啥，blablabla）
BI平台
BI平台是指标库赋能的一个非常非常重要的上层应用。
之前的章节已经分享过YZ的BI平台和自助分析了，BI这一块本身相对是比较成熟的，这里我想再分享一下为什么如此成熟的BI平台（包含自助分析）还会需要指标库。
自助分析功能将表（模型，数据集）的制作与报表的开发分离，明确指出了数据的生产，规范由BI分析师同学负责，数据的使用与展示由业务方自行负责，大量提升了人效。
但是这里还有一个核心问题没有解决，就是数据集（模型）的实现在物理层次是一段逻辑SQL或者一张物理表，如果业务方要想对他感兴趣的指标取数，就必须要对底层表的存储结构有了解。
换句话说业务方必须知道这个指标在表的哪个字段上，他必须要关心指标这个业务的概念与表这个底层物理实现的联系。
BI分析师当然可以口头告诉他或者有文档描述，但是还是很麻烦，特别是指标多了的时候，另外这不是一个完美解决的方案，还会有一些其他问题，比如BI同学做的模型基本是面向业务线（面向使用场景）的，如果我要跨业务线或者跨业务域看指标数据，因为指标在物理实现上是在不同表上，尽管这些指标已经存在了，BI分析师同学还是得把不同的表做一次join，形成新的模型，然后再告诉业务方，你可以使用这个新的模型。在这样的情况下用户是不可能随心所欲探索自己想要的指标的（因为得BI排期做模型）。
怎么解决这个问题？
这个问题的核心就是指标的定义（业务逻辑上的概念）与指标的实现（物理数据库表上的存储）在BI平台上有耦合。
最理想的情况是展示指标与维度，用户无需关心底层库表实现，只需要知道我们提供了多少多少指标，多少多少维度，你关心哪个，就选哪个。指标库来做join与聚合，把分散在不同物理表上的指标汇聚到一起做展示。
（用户选择维度、指标以后点击分析按钮就可以直接去BI平台做分析，指标库生成SQL）
在这种模式下，用户看到的是他们更加理解的指标，更加友好，同时BI分析师同学也无需为每个需求都定制模型，提升人效。
YZ现状
打通调度平台指导个性化指标建表的前置条件是数仓规范建模，形成方法论落地，所以现阶段正在起步。
oneservice因为自身排期的关系现在和指标库集成度暂时比较低，目前指标库自己做了一些指标与页面路径等信息的关联（其实这部分我觉得应该是由oneservice来做的，因为它是统一的数据出口，它更应该知道解口被谁用了，用在哪里）
BI平台的打通正在做，目前已经实现了通过指标的方式给用户展示数据。核心功能算是实现了吧（但是多事实表的各种连接等有很多case需要完善）。
3.5.3 BI中间层
对应③，这个应该算是YZ的历史原因了吧，其他公司可能并不多见。对内指标与对外指标口径应该是要统一的，所以我的想法是逐步合并。
之前刚好因为指标库对BI是有赋能的，所以借此机会，我定了个流程：BI后续每个新指标都与数仓共建，如果是中间层的指标，就由数仓录入指标库，做表。如果是个性化指标，数仓做中间层通用指标，BI基于中间层制作BI层个性化指标，2层指标都录入指标库。指标库负责新需求指标的展现。
由此方法逐步统一，最终消灭掉原本BI自己的中间层，合并到数仓内部，实现对内对外指标统一。
3.6 小结
小结一下指标库对数据中台的意义吧：
1. 规范数仓建模，统一指标口径，防止重复开发指标（规范性的）
2. 沉淀建模方法论，打通调度平台，指导建表设计，提升数据开发效率（经验的复用，方法论的沉淀）
3. 形成数据指标资产赋能应用，例如BI应用，oneservice应用（数据资产的沉淀，连通数仓的数据和各个其他平台）
所以我认识指标库对于从数据平台整合成数据中台有非凡的意义。
总结
以上便是我对BI、自助分析、指标库相关平台的一些学习感悟吧。
我觉得自己还是挺幸运的，一直在做指标相关的事情，不断遇到各种挑战，不断尝试泛化问题，解决问题。从BI解决BI分析师问题，到自助分析解决业务方取数问题，到指标库解决中台指标相关问题，积累了BI数据分析、数据产品/数据开发、数仓建模等各种知识。希望自己有朝一日成为领域专家！