这是彭文华的第95篇原创
爱奇艺的版权意识太强了，昨天发完文章后，小助手联系我删稿
。这不，只能发一个阉割版的了。
我又去DataFun的活动了，这次是深入爱奇艺的大本营，前去学习爱奇艺、美团和字节跳动的数据中台建设经验。
现在就给大家分享其中入门级的《爱奇艺数据仓库平台与服务建设实践》。说是入门级，是因为数据仓库是本次分享的内容中最基础的部分，后面分享的内容都得基于数仓开展工作
先把张迪大佬放出来镇楼。
【大佬照片】爱奇艺数仓进化之路
【数据仓库1.0架构图】
这是爱奇艺的数仓1.0的架构，中规中矩的4层，ODS、明细层、聚合层和应用层。现场有朋友对数仓的建设不太了解，抓着张迪大佬使劲问。直播平台还有人吐槽提问者太不专业了。我之前有一篇文章写的比较全面，没玩过数仓的同学可以参考一下：点击阅读：如何搭建一个数据仓库。
张迪大佬现场披露，当时建设就是按照自下而上的Kimball建设，最后建成了一个个的烟囱。各个烟囱的数据相互引用，重复造轮子，口径不统一，天天打架，实在是太痛苦了。虽然有各种数仓规范，但是如果你建设过数仓就知道，烟囱式的建设有范围小、建设快、见效快的好处，也有相互割裂、口径难以统一、各说各话等“烟囱式建设”天然且难以根治的问题。
为了降本、增效、少扯皮，爱奇艺开始了数仓2.0的建设，用张迪大佬的话来说，几乎是推到重来。
【数据仓库2.0架构图】
请注意看这张图的中间的三个框框：下面是统一数仓，上面是主题数仓和业务集市。另外不要忽略了右边的统一指标体系和一致性维度。
这个就是爱奇艺数仓2.0和1.0的根本区别。在ppt上看上去就几个框框，但是我能感受到，这后面的时间付出起码是以“年”为单位计算的，其中夹杂着无数扯皮、妥协、争论、加班和熬夜。
其实这个框架就是融合了Inmon自上而下和KimBall自下而上建设方式的CIF架构。可以扩展阅读我之前的文章：点击阅读传统数仓和大数据数仓的区别是什么？里面有详细介绍。
【数据仓库2.0示意图】
这么弄的好处就是，公司所有底层数据都是一个出口（统一数仓），解决重复造轮子的问题。上面按主题和业务分别归类建设，满足个性化的需求。统一指标体系和一致性维度解决数据打架的问题。这样就天下太平了。
爱奇艺数仓建设经验
【数据平台架构图】
拍照技术实在是太渣了，您多担待，凑合着看。
这个架构总揽了爱奇艺的数仓建设经验，咱先别管，往下继续看，下面会细说。下面的内容看完了再回来看这张图就清晰了。
【统一维度梳理示意图】
【指标体系梳理示意图】
这两张图是梳理维度和指标的方法论，我有一篇文章专门讲这些，就是上面提到过的，这里再给您放出来，点击阅读：如何搭建一个数据仓库。
另外，我之前也都分享了数仓建设中的所有理论书籍和过程模板，点击下载：【资料包】数据仓库建设完整资料包。在这里就不赘述了。
【统一数仓建模流程图】
【集市、主题数仓建模流程图】
张迪大佬写的是真详细，可以作为数仓建模的标准参考了。建模的流程就是这样，业务建模-数据建模-物理建模。之所以会有两张片子，是因为统一数仓建模是从最底层开始的，而主题数仓和业务集市，是基于统一数仓之上，进行建模的，所以可以免掉业务建模那一层（其实也是要梳理业务的，但是不需要做基础的主题域划分、实体和事实确认等工作）。现场有人问建模方法，我这里也给一个之前分享的内容作为参考，基本上数仓建模方法都讲到了：点击查阅一口气讲完数据仓建模方法--数据仓库架构师碎碎念。
【数据模型页面展示】
这是建好的模型，内容已经重码。从这张图可以看出，他们还建了一个平台，在平台上来管理数仓所有内容。这个平台也就是接下来要讲到的“数据图谱”。
爱奇艺数据治理
【数据图谱介绍】
特意把数据图谱的介绍放出来。因为业界一般都叫数据地图、数据治理、数据管理、数据资产管理之类的，基本都是一个意思，大家明白就行。
【元数据管理示意图】
第一个功能没的跑，元数据管理。其他的内容都还好，什么元数据采集、统一服务、技术元数据、业务元数据等，所有元数据管理都会涉及到。但是这个架构有两个点吸引了我的注意力：JanusGraph和血缘采集。
这就意味着他们会用HiveHook等自动采集各层之间的血统/血缘信息，并存到JanusGraph中，这个很有意思，说明他们在用atlas。因为atlas就是把血缘关系存到JanusGraph的。另外他们用ES存储技术元数据和业务元数据，应该是提供各种快速、高效的元数据查询和搜索服务。
【数据图谱功能介绍图】
这是爱奇艺数据图谱的内容，各位可以过来抄作业了哈~~~
【数据血缘展示图】
这张图就是他们的数据血缘流向示意。大佬现场还透露，他们每张报表都有一个自己的等级标签，一方面区分优先级别，另一方面可以向上追溯，一致找到源头。一旦出了问题，就可以迅速定位，那是相当的好用啊！
【数据图谱页面展示图】
这是业务视角下的数据图谱，业务同学在这个界面就能很自由的找到想要的数据。
注意看上图的内容：表、维度、指标，这就可以自由的查询元数据了。
然后看下图，有点不清楚，我连猜带蒙的，应该是这样的：
下图左上角的标签应该是切换数仓：统一数仓、业务集市、主题数仓；下面的12345步骤分别是：
选择关联业务，比如商城；
选择业务过程，比如播放（应该是对应业务领域）；
选择数据模型，就是主题模型，看上去全是测试的；
选择物理表，打了重码了，看不清；
最后是查看维度和指标，这应该就是能看到这个限定范围内所有可以展示数据的维度和指标了，甚至还能拉出一个大表给你。
总结
简单总结一下：
1、建设过程是先Kimball，快速满足业务需求。当问题越积越多，开始用CIF架构重建。提示：这是从0开始的最佳路径。万不可一上来就用CIF或者inmon，你会死的很惨的。
2、建设方法论中规中矩，梳理维度、整理指标，然后开始建模（业务建模、数据建模、物理建模）。本文已经更详细的方法论，请自行参考。
3、数据图谱用的是atlas，元数据存在es里。元数据和血缘关系自动采集，用api提供查询和搜索服务，方便业务进行元数据的快速定位。
时间有限，张迪大佬也没有透露更多建设细节，比较遗憾。不过幸运的是爱奇艺OLAP大佬林豪在Apache Kylin这边分享过OLAP的经验，ppt已经公开了，不用考虑侵权问题了。
后台回复“爱奇艺”即可获取《Apache-Kylin在爱奇艺的实践》。有空再写爱奇艺OLAP的解析。
如果有我没说清楚的内容，可以在后台留言，咱接着唠。
配合以下文章享受更佳
干货 |一口气讲完数据仓库建模方法
干货 |什么才叫做懂业务？分析的5个层次
干货 | 如何搭建一个数据仓库
【资料包】数据仓库建设完整资料包