公告
【公告】周五BI飞起来，天善商业智能BI社区每周五下午举办问答社区在线答疑活动，每周五晚上举办行业、厂商工具、技术相关的微信在线直播活动。
【预告】下周微信直播的话题有：
1、数据挖掘在会员分析方面的应用，包括并不限于会员分级、精准营销、交叉销售、流失分析等。
2、数据挖掘过程的关键点及难点探讨。
3.、百货零售行业的应用、数据质量、数据治理、分析模型等等。
2015年11月13日 Friday BI Fly 微信直播主题 - 报表平台运营模式、系统架构
主持人：加入本群的朋友们，感谢大家参加由天善智能举办的 Friday BIFly 活动，每周五微信直播，每周一个话题敬请关注。
【群规】本群为BI 行业、技术、工具交流和学习群。不准发广告，只能发红包，发广告者一律移除微信群。
本次微信直播讨论内容：
1. 报表平台运营模式
2. 报表平台系统架构
嘉宾介绍：
BAO胖子
春宇老师 15年BI经验，涉足医药，电力，快消品，信息服务等行业的BI老兵。
个人专栏：http://www.flybi.net/people/shaocy
博客专栏：http://www.flybi.net/blog/rayshawn
老头子
Oracle11g OCP、BI产品经理，有非常丰富的开发和技术实战经验，擅长企业级数据仓库模型设计和技术架构的设计、项目管理以及大数据量的Oracle SQL性能调优及模型调优。服务客户有华为运营商、华为IT、联想等企业，曾作为产品经理带领30 人以上的实施团队实施BI项目、主要负责需求管理、模型设计和oracle技术支持以及培训。
个人专栏：http://www.flybi.net/people/azzo
博客专栏：http://www.flybi.net/blog/azzo
贾岩
逆光老师，做了十年的信息化项目，从事BI行业近八年时间，主要从事系统集成，集团信息平台数据的整合与建设工作。对于集团数据平台建设有深刻理解，从事过ETL开发，报表开发，以及数据库管理等工作。目前主要做系统运维工作。
个人专栏：http://www.flybi.net/people/jiayan
博客专栏：http://www.flybi.net/blog/jiayan
话题一：报表平台运营模式
主持人：我们首先来进行第一个话题的讨论，1. 报表平台运营模式 请几位嘉宾先发表下各自的看法。
贾岩：
各位朋友大家好，很高兴能参与今天的直播，今天主要给大家介绍报表平台结构，企业级数据仓库设计，数据挖掘应用，用户画像等内容，我们根据个人的项目经历以及个人经验，总结一些这方面的内容，跟大家进行知识的分享与讨论，在直播期间大家有什么好的建议或者想法，也可以与我们互相沟通与交流，那么现在开始我们今天的直播内容：
其实所谓运营模式，这个话题理解起来可能有点大，我就把我做过的项目的整体建设情况以及过程，整理了一下，虽然用的软件不同，虽然每个项目也会有不同，但是很多结构都是很类似的，我们可以加以变化，但是大同小异，变化都不会很大，这种集团性的数据平台体架构，基本是比较大比较完整的结构了。每个项目开始前，尤其是大型项目，基本都会成立一个这样的人员体系结构，如下图所示：
项目中有着明确的分工，尤其是大型国有企业，当然有些小的企业不会分的这么细致，这里不再做细致介绍，另外就是项目的整个过程 ：
我们在制定一个项目计划的时候，会比这个更细致一些，这个是一个项目大概的过程。下面详细介绍每个阶段要做的工作：
需求分析阶段：
用户访谈、发放调研表、收集样本数据、编制需求报告
设计阶段：
架构设计、数据模型设计、功能设计、接口设计。并且完成相应设计文档。
例如：《系统设计报告》、《公共数据模型建模报告》、《BI应用功能设计》、《ETL设计报告》、《物理数据库设计报告》等。
环境搭建阶段：
确定硬件需求、编写技术规范书，招标采购，并编制《实施方案》、《应用软件配置方案》、《ETL部署配置方案》、《中间件配置方案》、《数据仓库部署配置方案》等。
系统开发阶段：
开始根据需求进行程序的开发与部署。
系统测试阶段：
根据项目的不同，测试的内容也不同，需要明确了测试工作内容，通常包含开发测试和现场测试2个层面；测试内容包括单元测试、出厂测试、上线功能测试、性能测试等等测试内容。并且需要编制完成《测试用例》、《测试报告》等文档。
系统试运行阶段：
进行整体运行的测试工作，包括接口、数据、系统集成等。
每个阶段都会都会产生相关的项目文档，这些文档是作为项目下一步执行的依据。
当项目结束之后，也会有一个相应的团队来进行维护。这个结构可以根据项目的大小，以及结构的复杂度而定，如果是长期项目，那么一期结束之后这个团队就会成立，在项目的二期建设中，同时也要保证一期项目的稳定运行，这里面我只是列举了一些大概的运维情况，以及运维的内容，只作为大家的参考。
l 服务支持队伍
服务支持队伍可以包括这样一些工作：服务台，事件/问题，变更，版本和配置管理，以及场地和一些非IT设施的管理。
l 技术支持队伍
技术支持队伍包括这样一些工作：
Ø 存储服务支持
存储管理员负责数据平台尤其是数据仓库存储（备份、归档）的计划，配制，管理及故障排除等工作，并协调数据平台所有其他业务应用系统中有关信息存储的任务， 包括数据备份和恢复，数据归档及恢复。具体体现在存储区域网络，本地数据复制应用，远程数据复制，容灾，业务连续性，存储容量的分配，性能监控等任务。
Ø 数据仓库服务支持
监控ODS、数据仓库、数据集市的运行状态、日志文件及空间使用情况，并对系统资源的使用情况进行检查，发现并解决问题。监控数据库对象的空间扩展情况，并就数据库做健康检查，寻找数据库性能调整的机会，进行数据库性能调整，并以此提出下一步空间管理计划。
Ø 网络应用支持
实现对整个网络的设备配置、监控、动态运行分析、安全、问题诊断、流量控制以及虚拟网划分和管理等工作。使网络的运行更能符合企业实际应用的需要，达到网络高速有效的传输和安全可靠的使用。
以上，是我对于企业级数据平台的整个建设，以及后期收尾后进行维护的一个大概过程的理解。因为时间关系，暂时介绍到这里。下面请另外两位嘉宾发表一下自己看法：
BAO胖子
BI发展历史：最常见的传统模式之一自下而上
首先我们今天的话题是：集团公司级别报表平台运营，关键词有俩：一个是集团，也就是说是企业级的，俯瞰整个企业的视角；二是 平台，是一个能够容纳各种BI应用，并且能行之有效的运行起来的一种机制。我们有一个大的假设前提，集团报表平台是服务于大型公司，比如有很多分公司，子公司，多部门等，并且有BI需求的访问人群超过1000以上的公司。这里稍微讲点历史，先看最常见的传统模式：
最典型的各个分公司或者部门，有一定的IT经费，然后各自为战，会雇佣一定的IT的管理员，当有规模的需求时，组织项目进行系统设计开发。通常都会立项 ->招标->采购（硬件+软件+服务）->需求调研->设计->开发->部署上线->运维管理。然后一个项目结束，再接另外的项目，刚才 @逆光 说的很好，就是二期的时候就把开发，运维，支持什么的都分开了，通常如果能够健康的发展，就会一直不断的运行下去。
本世纪初开始，下级部门建IT应用这种情况最为明显，很多省级公司的报表都是需要市级、县级、区级逐层上报汇总，数据中参杂各种水分。这个阶段，都是多如牛毛般的小项目，然后相关数据设计千差百别，集成很多时候是根本无法高质量完成的。这个阶段地市一级的BI需求很多都是夹杂在MIS系统里面一起实现的，通常都是固定报表，一般很少有为BI单独立项的项目，在2003年以前，会做一些独立 于MIS以外的决策支持系统，规模通常都很小。而经理一层的在这方面的需求实际上是很强烈的，很多小系统使用率非常高，偶尔会采购BI工具，很多时候就是 自行开发实现，用户规模也小，通常只有十几个人。
BI有关的稍微大一点规模项目往往是由集团管理层发起的，因为看不到及时的数据，无法做有效的决策，这个阶段出现各种二级数据集市的模式，地市一级用一套系统，出数据，然后上传到省公司, 集团公司等再做数据汇总。
总结一下这个阶段的特点是：
1. 部门或者分公司发起
2. 小规模DSS系统，需求自下而上
3. 项目by项目，做一个是一个
4. 基本上找个管理员维护了事，很少升级
5. 自行定制开发很多
6. 集团拿不到原始数据，都是汇总加工过的。或者拿到原始数据除了查查基本信息，也做不了分析。
这种模式有哪些缺点呢：
1. 管理分散化，这样势必造成各个分公司、部门之间的不一致，建立企业级统一化的数据平台战略更是无从谈起。
2. BI都是循序渐进的，是长期的过程，这个基本是一锤子买卖，做完了等升级换代就不知道何年何月了。
3. 统统交给乙方，甲方完全没有核心团队，造成后面难以为继。
4. 下次有类似一定规模的需求，如果换了乙方，基本上就是重做。
5. 集团级别拿的数据水分十足，并且很难及时，各个分公司口径不一致，没有统一视图。
一个事情总有两面性，既然存在就有存在的理由，所以它还是有优点的：
1. 一线的需求都是真需求，接地气。
2. 低成本，灵活，规模小，启动快，容易见成效。
3. 麻雀虽小五脏俱全，充分锻炼和培养了人的综合能力，不过绝大部分都是乙方的人。是的，我们很多人就是这么成长起来的。
为什么讲这些老掉牙的东西呢？因为即使到了今天也有很多信息化建设水平低下的企业（行业）还存在同样的问题。
群里面的如果有企业还是这种模式的，也不妨举下手。
【话外音】小伙伴儿们纷纷举起了手，手呢手呢，我咋没看到呢，哦哦，咱们是微信直播，小伙伴们儿天南海北，你若没有千里眼是万万看不到的，看这里吧
【话外音】不捣蛋了，我们继续听老师讲课，做个乖学生。
BI发展历史：最常见的传统模式之一自上而下
再后来，一些信息化建设基础比较好的企业，就开始做省级（或者全国级，当然也有全球级别）的集中，这个时候通常的大前提是，业务系统已经在集团公司集中了，比如ERP，CRM，SCM这类系统的集团化使用。这种情况下势必带来BI系统的升级换代，这个时候的需求是自上而下的。
这部分我强调一下，我极力反对ETL是整个企业BI系统建设的核心，最重要的还是直指value的BI应用，我提及的这种场景下的项目，眼下其实很多，经常是大国企
这里存在多种有趣的现象和问题，列出一些但不限于此：
需求问题：
1. 虽然规模大，但有趣是有很多时候仍然不是企业级别的项目，而是最有钱或者最有实力（有话语权)的Business Unit (比如销售）出资，这样就只做自己的部分，其他的我可没钱去关心。然后公司就出现一种奇怪的现象，其他小部门呢？无人关心。他们也有需求啊！ -->小部门需求没人满足
这个我有必要说明一下，是这样的，我曾经遇到过一些项目，项目的规模很大，但其实出资人不是企业的cio办公室，而是某个具体的部门，比如移动的话，可能是就相当于移动的业务部门，他的财务、hr不会参与其中的，从建的规模来看好像是企业级的，但其实很多business units很多都没有纳入进来。
而在这种情况下建设的bi平台实际上只是解决了他企业当前这一个部门的业务问题，没有想到去解决其他部门的业务问题，为什么我要提平台的概念，就是应该是从CIO的角度来讲，我去建一个更大规模的平台，能够纳入其他各个部门的需求。
2. 集中化，需求自上而下，集团公司爽了，下面忽然看不到想要的数据了。而下面的需求其实和上面有很大区别，即使是同样的Business Unit。 -> 信息专制，而又没有渠道让下级公司满足需求。
这个问题也非常常见，集团公司定需求，往往忽略下级的需求，而下级有需求，但没有渠道做做，自己希望立项去做相关项目，又没有数据资源，因为都在集团手里，所以需求就湮没了。
3. 对于企业没有专门BI团队配置的，还是按项目走，项目一旦结束，增加点中等规模或者小规模的需求很是吃力。 -> 更新，升级，增加小需求困难。
这部分我有必要强调一下，就是说有这种情况，企业没有专门的bi团队配置，按项目走以后，项目一旦结束，中间去增加一些中等规模小规模的需求就很吃力，一定要等到下个项目来了以后才能解决这种问题，而bi这种应用实际上来讲是长期的应用，是随需而变的，当我市场来一个需求，我要很快看到这个信息，但时间一旦错过，要等一个项目启动，这个周期很长，她就把这个需求错过了，可能就会错过市场的商机。
那这种模式又会造成什么问题呢？
资源浪费问题：
1. A部门有钱，B部门也有钱，OK，各自为战，你买Cognos做平台，我买BO，各玩各的。
A部门有高级分析需求，用Tableau，殊不知B部门也有类似需求，但买了Qlikiew。 -> 软件License浪费。
2. 硬件买多了浪费，买少了不够用；我就是月末用，平时都闲着；全球性企业，白天用晚上闲着，全世界多套系统均如此。 ->硬件资源需要优化。
3. 信息安全（登录、授权）之类的通用型需求，重复建设。 ->基础建设管理成本增加。
架构问题：
1.随着时间推移，用的人越来越多，并发太多，根本无法使用。 ->架构不可扩展。
2.选择过于小众的产品，虽然满足了一小部分需求，但community不成熟，产品功能不完备，造成后续新功能无法添加，人员难以配备，出现技术问题没有成熟方案和社区获得支持。 ->产品选型问题。
3. 若应用规模较大，可以更有效的获得产品厂家的技术支持，甚至为了当下迫切的需求，临时打补丁。从企业战略层面，和厂家深度合作也能获得更有利的折扣和其他优惠。 -> 产品Support方面。
管理问题：
1. 没有BI建制的公司，乙方核心顾问闪了，自己的人没培养起来，回头还是做不出高质量的BI应用 -> 核心竞争力培养问题。
2. 有BI建制的公司，BI人员苦逼了，都是企业内部需求，谁都可以让你做事，你都不知道听谁的，然后做了也白做，你自己都说不清楚你做了多少。优先级就是谁的声音大听谁的。 -->管理混乱。
3. 用户看报表发现错误，不知道向谁反映 -> 维护支持管理问题。
林林总总，可能还有很多，各位看看是不是自己公司也有类似的问题。这里需要上一张BI的成熟度阶段图，可以看看处于什么位置。
BI发展到现在，我们该如何做？
因此，要解决以上的问题，就要从企业级的视角去管理BI，并且需要组织/技术/流程等等综合在一起的复杂的过程。
并且，我们今天的关键词是 集团报表“平台”，需要去搭建这样一个平台，去充分发挥BI的价值。并且，只有做成平台模式，才能实现下面的需求。如何做成平台模式呢？
1） Organization：BI核心团队，逐步建立起对整个公司的业务的理解，对BI平台技能掌握精深，逐渐对业务需求熟知，对系统、数据非常了解，并能制定各项规范的核心人员团队。
2） Technology：集团统一化BI平台
a. 基础功能统一化管理，比如数据安全访问控制，访问审计，授权等等。
b. 选择可扩展，可信赖，成熟BI产品工具。对于不同需求，可以采购不同的BI产品，但部署于同一平台。
c. 最优化利用硬件，软件资源。
d. 统一化管理
3） Process&policy：流程、方法论、最佳实践、知识管理
ａ．部署模式
对于长期运行的BI应用，按运行的报表数量，使用用户的个数计算收费，提供不同级别的Support，比如将用户分为钻石，金，银等不同级别，提供不同的support。一般会用ticket的模式去管理，结合call center, email等接受信息的模式。制定Service LevelAgreement，分请求的优先级等等。
b. 咨询/开发模式
对于客户有开发新报表的需求，可以提供顾问给出专业的建议和解决方案，并且提供开发/测试等环境，同时提出如果使用平台的规约，比如对于查询performance的要求，等等。对于特殊需求的用户，也可以单独分配硬件/软件资源，等等。
c. 培训
d. 流程
Engagement, 了解基本需求，评估，然后设计开发之类。
现在BI还流行一种概念，全民BI，未来数据应用的潮流。BI的最基本需求：所有决策均依赖于信息，决策有大小，小决策也同样需要信息的支持。因此，其实BI绝对不仅仅是高层和中层的需求，而是全员的需求。而当前很多BI系统没有得到充分的利用，很大一部分原因就是在于数据访问仅仅限于部分管理人员，尤其是集团管治下的模式，通常集团公司有充分的权限，需求设计也是根据他们的需求而来，而不是从底层一线人员之处获取，一线人员只能获取少的可怜的信息。而provide rightinformation to right people at right time by right way是Bi的使命。因此，未来的模式就是全民BI，每个人都他具有权限看的信息都应该有访问权，当下对于大型企业而言，如果能下达到一线经理，主管其实就已经很难能可贵了。
而众所周知，一旦BI访问权下放一级，就会带来大量并发访问压力，因此集团报表的架构一定是可扩展能力很强的架构。并且，全民BI意味着更加复杂的权限管理机制。这些，就是我们今天讨论这个主题的主要原因，因为这些问题都是需要平台去解决的问题。
此外，除了企业内部人员，还可以开放部分权限给合作伙伴访问，这个也是非常常见的平台级别应用。
内容总结：
上面讲了那么多，大家一时也不一定消化得了，我这边再总结一下，强调一下我讲的内容：
全民bi，如果大家经常访问天善的网站，就会发现我们经常会提到全民BI这个概念，全民bi，实际上指的是信息的民主化，就是说每个人其实他都有权利去访问他可以访问的数据。我们平时做的bi系统，他就会有这个问题，你会发现只有个别人能访问bi系统，平时很多人他想看都看不了数据。这个不是他没有需求，而是说通过集团式控制的手段，当他需求没办法释放出来，但如果需求一旦释放出来，就要求你的系统架构足够稳定，支持多并发，以及去能够应付复杂的授权，以及数据安全管理这种需求，你才能把这种数据下发下去。所以说这部分分为三块来看，一个平台怎么把它运营起来，首先就是有人，有核心的人，包括consultant顾问，包括前面贾岩说的，团队要有做support，做开发的，团队配置要全。
此外，要建立一套平台，后面老头子和贾岩有更详细的描述这个平台怎么搭建，就是有一个技术性搭建的环境，能够支撑你这个应用，包括安全性，多扩展，种种能力，提供服务给相关的使用人员。
最后还有一块是流程以及相关的知识管理相关的一些东西，这个话题非常大，可能要讨论很久的时间，如果有人感兴趣，我们后续可以再开课题详细讲，就是说我有人有物了，我可以把平台理解为物，我也有客户了，我怎么通过一种手段，让这个大规模的机器有效的运转起来，这就需要流程来规范，我要跟客户去谈你的需求是什么，我来帮你解决，你需要我提供什么样的服务，有可能我有需求做报表，但我没有足够的人，你可以提供senior的人去做需求做开发做设计，有可能我有报表我有人，但我没有平台来发布，我可能要你的平台来发布。另外一个问题，我还有support，我support怎么来做，就是说我发布上去之后，我怎么能保证每天正常运行，当出问题的时候我该找什么样的人来解决，这个需要一套行之有效的流程以及人员责任管理制度完善起来。这个话题很大，今天的介绍就到这里，如果还有另外的需求，咱们可以稍后再谈。
老头子：
两位大师说的都很全面了，我就简单说下我的理解：
一般来说业务提出需求后，IT侧BA与业务人员会议交接，IT侧提出业务解决方案，并与业务人员串讲需求，确认无误后，输出需求文档，由业务人员评审和签字。
IT业务BA传递实施需求，IT侧进行模型设计、架构审核等，输出需求设计文档，将业务需求转换成IT需求（这一步一般来说是各个企业信息部门的痛点，很大部分需求就是在这里变形的）。
然后IT技术人员进行：开发、测试巴拉巴拉巴拉，开发完成后，业务测参与UAT测试验收，验收通过后进行签字确认并上线部署。
这也是我们经常说的一个大体的开发流程。
版本上线后开始试运行、系统监控等维护工作。系统、数据稳定后根据业务需求规划进行新一轮的调研、研发。
以上是一个理想的良性循环流程，期间的进度把控、风险预警、版本质量、需求控制等需要管理人员进行把控、接口。一个好的管理者可以平衡业务与IT期望、保持良好的合作关系。其他的再讲是重复了，我就说这么多吧。
主持人：好的，三位嘉宾已经就第一个话题进行了详细的分享，图文并茂，文字与语音并存，交流形式多种多样，内容深入浅出，信息量很大，大家都理解了吗？有任何问题都可以提出来跟老师互动哟，老师也很期待听到大家的声音呢。
话题一自由讨论：
网友提问一： @贾岩 BI应用功能设计 这个文档都包含哪些内容？指标？维度？表样？还是可以提供的功能：钻取、灵活分析等（by Suky）
贾岩：@suky 我可以给你截图
熊猫晶晶：数据需求和功能需求，针对这两大类。
Suky：数据需求和功能需求更应该体现在需求说明书里吧
贾岩：@suky 那个是需求说明书，因为我们是BI项目，所以没有应用功能
贾岩：@suky 所以功能多数指的是开发文档，和模型设计文档
Suky：对啊，所以你提到的BI应用功能设计 这个文档我比较好奇，应该包含哪些内容呢？
贾岩：@suky，这个是ETL设计文档：
这个是BI页面设计文档：
suky：那么就是说BI应用功能设计包含了模型设计、ETL设计....
贾岩：是的。
网友提问二：ETL的重要性及工作比例到底应该多大？（by 铁皮罐头）
北京~BIEE~罐头：我认为ETL的重要性是毋庸置疑的。其实说ETL重要 是因为里面涉及到太多的业务逻辑和计算逻辑，数据的准确性 是及其重要的。数据仓库作为核心，是因为数据仓库会包含整个企业的信息，并且随着时间的变化不断更新，如果需要对某个部门或者业务进行针对性的需求开发，就可以直接从数据仓库中取数据在数据集市中建立一个新的模型满足需要即可 所以数据仓库的建设应该是整个BI项目的核心。 就像是盖房子，地基打好了，才会有向上的基础，而整个后台的过程全都是基于ETL的。
北京~BIEE~罐头：再有前台展现的问题，由于这个是面向用户的，所以很多领导对这个的要求也不低，所以不仅仅要求前台人员能够开发，还需要前台人员有一定的设计观念和对需求的理解。
BAO胖子：@北京~BIEE~罐头 我的point，相对于Reporting，ETL是更偏向于一次性的工作，也就是如果DW 模型稳定，应该ETL只在开发阶段有大量工作，而后期工作将逐渐减少，也就是说，你的基础已经打完了，应该是收获的时节，此时开始report的工作量将逐渐增大，这样才是BI存在的带来value的意义，后续的工作的比例应该是report的工作量占主导，而目前的问题是，一次性的做ETL和Report，然后既停滞，所以ETL的比例很大，而report的比例很小，这种模式，不是BI的初衷。
BAO胖子：Report开发是细水长流的事情，sooner orlater，它的比例是应该超过ETL的。
北京~BIEE~罐头：@BAO胖子 你说的对 整个流程也都是重要的，缺一不可，但是重中之重还是打好基础。
BAO胖子：@北京~BIEE~罐头 不可偏废，这个就是我的意思，目前是太偏了。
北京~BIEE~罐头：现在很多项目都是还没怎么样呢，就急匆匆的开始开发前台了, 然后就不断的返工重整。
BAO胖子：Qlikview的套路就是啊。还是那句话，不可偏废。
Seng：etl好是必要条件但不充分。
网友提问三：@贾岩 ETL服务支持和数据仓库服务支持分别指的是什么？数据仓库只是建立模型和OLAP地方分析吗？（by我的哆啦不能没有A梦）
贾岩：@我的哆啦不能没有A梦
ETL服务支持，这个服务也包含ETL产品公司提供的后期升级之类的服务，但是不多，主要是我们维护人员的工作，因为业务系统有改动，源表有变化，ETL就要修改。
Ø 数据仓库服务支持
监控ODS、数据仓库、数据集市的运行状态、日志文件及空间使用情况，并对系统资源的使用情况进行检查，发现并解决问题。监控数据库对象的空间扩展情况，并就数据库做健康检查，寻找数据库性能调整的机会，进行数据库性能调整，并以此提出下一步空间管理计划。数据仓库你要保证正常运行，我们以前要经常检查日志，以及检查数据库健康状态的。
贾岩：还有叫什么命中率。。。好多东西，尤其大型企业，每周都要提交平台健康状态检查表@我的哆啦不能没有A梦。
网友提问四：其实这些文档工作需要耗费大量的时间，怎么去衡量呢？（by AricZhou@上海辰智.BI）
贾岩：@AricZhou@上海辰智.BI 这些是你必须要交给客户的，必须要有，这是验收文档之一。
AricZhou@上海辰智.BI：大客户是这样的 甚至客户自己提供了需要交付的文档，小客户好像不懂也不关心这个。
有我在呢别怕：小型乙方公司还是会关注的。
贾岩：@AricZhou@上海辰智.BI 嗯嗯，小客户有时是这样，根据项目情况而定。
King：@贾岩 了解，已经很全面了，各种文档，小公司很多时候是没有写文档这个人的，我来了这个公司才每一个需求让他们弄一个文档
贾岩：@AricZhou@上海辰智.BI 我们讲的，多数是按照一个常规的标准讲，就像胖子说的，多数都是大型国企，因为他们要归档的。
主持人：好了，第一个话题我们已经严重超时了，虽说大家搞IT的都是夜猫子，也考虑下群里还有好多妹子的哦，大家有没讨论完的话题或者还希望嘉宾分享哪方面的内容都可以联系我，我给大家记到小本本上，后续还会开展更多的直播分享啊，我们赶紧开始第二个话题的讨论：2. 报表平台系统架构 。
话题二：报表平台系统架构
贾岩：
兄弟们。。。第一个话题涉及管理方面多一点，因为当你做了很多年项目，回过头看，就全理解的。新人对我们讲解的，可能还不是很理解，这个需要项目一点点积累的。大家注意，打起精神，第一个话题不理解没关系，做项目慢慢学，第二个话题我认为大家都应该学， 都应该知道的。因为我们在做项目，做开发，做分析时，我们最好去了解我们的结构是怎么样的，有人愿意一辈子低头做自己的开发吗？我相信没多少吧，所以，做好眼前事，还要抬起头，纵观全局。做好人生规划，少不了要学习，所以我们要知道你做的事情，做的开发，是处于项目哪个，部分，哪个阶段，将来做管理，还是咨询，你都要从大局出发，所以系统结构，所有人必须要知道。现在开始架构方面的讲解，先来看张图：
这是张硬件结构图，一般集团，还是非集团性，物理结构都是双机，单机风险比较大。根据结构复杂度而分，这个图是ORACLE单独放在了一个服务器了，也有和ETL放在一起的。因项目而议，除了应用服务器，还会有一个单独的磁盘阵列，通过这些都是服务器的管理员来负责。
这个就是一个典型数据平台结构，每个层次使用的软件可能不同，但是结构基本都是一致的。数据平台，借助统一的运行环境对来自不同业务应用的数据依靠统一的开发路线进行抽取、转换和加载，加工形成企业数据仓库和并根据具体的业务需求形成相应的数据集市，在数据集市的基础上进行更高级的业务分析应用，同时将各种来源的数据转化成实用的业务信息，为企业提供完整的数据支撑，实现企业数据的构建、保存、更新、集成、分发与共享。
企业数据平台为企业信息门户提供展现的内容，两级数据平台通过数据交换平台实现级联，可以通过应用集成平台实现各业务系统间的集成。
大家看前面的展示层，有些可能用COGNOS 或者BIEE展示，有些是开发门户，将COGNOS 或者BIEE开发的报表嵌套进去的。所以大家重要的是理解结构。
这个是一个逻辑架构图，他包含了一个集团省级，总部之间的关系。也许地市级别有时是一个单独的，独立的小系统，但是省级，本部，结构基本一致，重点是数据的交换功能。
1. 数据获取与交换的实现
各种数据源进入数据平台的数据缓冲区有两种方式，即利用ETL工具提供的功能获取数据，和利用数据交换平台提供的数据交换服务进行交换，下面将具体说明。
l ETL处理的实现
省级公司集中的业务系统的数据、地市分布的业务系统数据、和外部数据，可以经过抽取（Extract）进入数据缓冲区，再经过转换(Transition)和清洗(Cleansing)，然后加载(Loading)到数据仓库。
进行转换的目的在于解决源数据可能存在的数据不一致现象，对抽取的源数据根据数据模型的要求，进行数据的转换、清洗、拆分、汇总等处理，保证来自不同系统、不同格式的数据的一致性和完整性。因为当源数据进行抽取后，如果不进行一致性转换，会造成数据无法加载或加载后无法使用。
进行清洗的目的在于检测并删除或改正将装入数据仓库的“脏数据”，使源数据元素化、标准化、并消除重复记录。
l 数据交换服务处理的实现
数据交换服务存在以下应用场景：
a) 省级公司数据平台与总部公司总部纵向数据交换、省级公司数据平台与其他机构的外部系统的数据交00换，通过数据交换平台提供的数据交换服务进行实时和非实时交换。
b) 有些准备进入到ODS缓冲区中的数据，包括省级集中业务系统的数据、地市分布的业务系统数据、和外部数据，当无法使用ETL工具获取时，也可以通过数据交换平台提供的数据交换服务进行数据交换的方式，完成采集后，加载并存储到数据仓库中。
2. ODS区内的数据处理
在图中，ODS区包括数据缓冲区和统一数据视图区。
a) 统一数据视图区主要保存各个业务应用系统中的关键数据，并为以后搭建的业务应用系统提供全局的数据逻辑视图和数据存储平台。并且也可以实现实时监控功能。
b) 数据缓冲区暂存由ETL获取的数据，这些数据经过转换和清洗后加载到数据仓库中。数据缓冲区是为了保证数据移动的顺利进行而开设的阶段性数据存储空间，需要进入数据仓库的各个业务系统的数据首先直接快速传输到数据缓冲区，再从数据缓冲区经过清洗、转换、映射等复杂的数据移动处理转移到目标数据仓库中。
从省级公司数据平台数据处理的角度，数据缓冲区是存放各业务系统的原始数据和各个异构系统转入的原始数据，对数据缓冲区的数据进行清洗和过虑，然后面向主题、按数据模型存放数据仓库。
3. 数据仓库区和数据集市区的数据处理
经过清洗、整合后的数据进入数据仓库。数据集市对数据仓库中的基础数据进行逐次聚合，形成目标数据供前端数据应用或展现。数据集市根据省级公司的具体应用需要和数据量建立。
各部门业务应用的数据首先被存储在数据仓库，从数据仓库经过数据集市，细节数据逐步演变为轻度综合和高度综合的数据，其实质是对OLTP系统产生的历史数据进行整合、存储、处理、统计、分析，从而获取关于历史的、目前的、和未来的知识，从而获取信息、支持决策与管理的应用模式。
4. BI应用的实现
数据仓库、数据集市的数据可以应用于报表、即席查询和OLAP展现；也可以应用于数据挖掘。这些数据应用的数据处理和前端展现主要是通过相应的BI工具完成的。这些BI工具软件的SERVER端部署在APPLICATIONSERVER上。
用户使用BI工具客户端经过门户登陆统后，访问BI工具SERVER端，完成访问请求。BI应用与PORTAL集成时，需要重点考虑单点登陆和访问权限集成的实现。系统级访问权限由门户系统控制；数据级范围权限由BI工具与数据库系统共同实现。
这是整个结构每个环节的一个说明。其实对于一个庞大的集团性的企业来说，这么大的结构，需要主要谈的就是信息安全，信息安全其实说起来话题也不小，包含技术协议，网络安全，数据库安全等方面，但是对于我们做系统的来说，其实主要涉及的层面，就是权限控制及门户集成的操作。
信息安全目标与原则：
q “进不来”
使用访问控制机制，阻止非授权用户进入网络，“进不来”
q “拿不走”
使用授权机制，实现对用户的权限控制，即不该拿走的，“拿不走”；
q “看不懂”
使用加密机制，确保信息不暴漏给未授权的实体或进程，即“看不懂”；
q “改不了”
使用数据完整性鉴别机制，保证只有得到允许的人才能修改数据，而其它人“改不了”；
q “走不脱”
使用审计、监控、防抵赖等安全机制，使得攻击者、破坏者、抵赖者"走不脱"。
集团数据平台建立完成后，信息的安全控制尤为重要，其实可以通过门户来进行权限的控制，以及数据的访问控制，另外也可以通过报表应用的权限，对数据信息的权限进行控制与授权。
企业门户是一种能够为从事各种类型工作的用户提供全面的服务支持，一个为消除信息孤岛、构建知识管理体系、提高决策支持能力的全新信息化平台。依靠此平台，可以轻松的将分散的信息资源和内容整合到一起。
企业门户系统提供统一的信息访问渠道（单点登录）；提供基于角色和权限的个性化的信息、知识、服务和应用，不仅可以集成信息资源，也可以集成企业应用；也可以采用不同的模式来进行访问，模式很多，我只是列举一下而已，大家仅作参考。
1、省公司建设实体门户，地市公司全部建设虚拟门户。在地市公司部署独立的访问控制。用户与身份维护工作均集中在省公司，如下图所示
2、省公司和地市公司均建立实体门户和独立的目录系统。用户与身份维护均在地市进行。
3、其中门户也可以对于应用，分析等功能进行集成，进行权限进行控制。这里涉及到单点登录，用户同步等技术功能。
每种安全机制的建立，都是根据项目实际情况设计的。因为都各有弊端，有些成本可能会高一些。我大概就讲这些，主要是架构方面，需要大家仔细体会。
主持人：老师还没讲完，同学们已经开始迫不及待的要感谢老师了，关键的是今天晚上除了此起彼伏的感谢声，眼前竟然还有一片片的红色，从今天晚上开始流行红包感谢啦，小伙伴儿们真是有福了。
还有一位小伙伴儿一直没敢去卫生间的，简直太拼了！！！
废话不多说，欢迎回来，板凳坐好，老师开讲了。
老头子：
感谢@贾岩的分享 ， 我这边很简单，一共3张图：
1. 数据架构
2. 技术架构
3. 应用架构
【内心独白】（每次都很简单，是不是太不走心了）
第一张图是数据架构图，自己画比较粗糙，大家见谅！图里的EDW没有详细画出具体的分层，可以参考之前岩哥的图。
第二个图：技术架构
画了下需要搭建BI平台常用的一些技术能力，可以自下而上的看。这几年BI开始受到移动互联网的影响 ，都开始玩手机了，所以企业也会有移动BI这方面的需求。大致分了传统关系型数据库、非关系型数据、数据仓库、数据挖掘、以及传统BI所需的技术实现。
最后一张应用架构，一把来说应用架构是根据业务来画的，我这里只是举个栗子，大家根据实际业务来理解。
应用是直接面对业务的，也是BI价值体现的直接方式，和春宇说的现在企业过于看重数据仓库的建设一样，其实企业精力放到ETL上，从我的经验来看是由于数据仓库建设实在不易，所以不断的完善、加强、修复，导致了少部分企业忽略了前台应用
传统行业BI的企业架构大同小异，抓住精髓即可。
我就到这儿吧，我还是喜欢和大家互动环节，我一个人讲话我自己会睡着的，嘿嘿。
BAO胖子
1. 访问层
最常见的：Portal(在线访问)
其他如: Email（离线访问，比如发alert, 发export 文件，日报之类）
目前最火的：ipad， mobile, 当然也可以-微信
其他系统的接口：提供web service，对接其他系统，提供相应信息，这种应用相对不多。
这部分，Portal是最常见的，一般都是用java之类，定制开发的，这里需要说明的是，很多企业级架构，是包含多种报表工具的。因为报表工具各有所长Cognos、
Bo、BIEE算同类报表工具，Tableau, Qlikview又是另外一种，实际上是满足不同人群的需求。Portal可以作为一个壳，把所有的不同的工具纳入其中。
2. 应用层
按报表类型的分类：Dashboard, Ad-hoc, 固定报表，Alert, OLAP,KPI，高级分析（Data Mining）之类。
按业务分类: Finance, HR, SCM， CRM等等。
3. 产品层（技术层）
常用的报表工具，为了Developer设计的，固定报表为主的报表： Cognos, BO, BIEE等等。
为了分析而生的，高级分析为主的报表： Qlikview, Tableau等。
具体区别，请参见：http://www.flybi.net/blog/rayshawn/542
4. 数据安全层
与各类LDAP，ActiveDirectory之类的接口，包括企业内部和企业外部。
行级数据限制接口，一般在报表逻辑中实现。
还有很多安全相关的内容，此处暂不做赘述。
5. 数据访问层
多种数据库，Oracle, Teradata, DB2，各类Data Mart， DW， Cube之类。
统一化的平台大致分这么五层，这是我的理解。
主持人：自由讨论时间到了，刚才那谁说的不跟大家互动就会睡着的，大家快放马过来吧。
话题二自由讨论
网友提问一：百万级的大维表如何做缓慢变化维？
广州~BI~冬：@老头子，对于ORACLE数据库来说，如果有一个上百万的大维表，每天抽取全量数据，用SCD类型2的策略来保存，一般需要旧表和新表一条一条数据做对比，效率极低，有什么办法去增加效率呢？
老头子：首先百万级的维表要看有多少字段，其次要看需要缓慢变化的有哪些字段，然后只针对这几个字段进行处理即可。具体你说的缓慢，是处理方式问题，基本使用ETL进行缓慢变化处理，不把压力放在数据库中，比如在Datastage里进行合并然后MD5check。
广州~BI~冬：老师的意思是使用专业的ETL工具会比在oracle中效率高？还是效率相当，只是纯粹把压力转向ETL服务器呢？？
老头子：意思是把压力转向ETL服务器，自己如果能写出更棒的算法，那是更好，如果没有，就不要把所有压力给数据库，不过这要看系统的性能瓶颈在哪儿，如果瓶颈在ETL，那我们就应该在数据库中处理，这个要分情况来看。
网友提问一：监控系统前台界面是否属于BI？（by 深圳-供应链-王静）
深圳-供应链-王静：我个人觉得这种监控系统前台界面不属于BI，因为没有DW，可能是开发的应用系统直接连接生产数据库，也就是您所说的触发器触发记录数据的地方。不像是遵循了老头子的架构和您画的企业架构，个人见解，理解错了的话，请海涵。
贾岩：其实吧，举例就像手机多个相机功能一样，但是照相比不了专业单反，像电力、交通，需要的是实时监控。
深圳-供应链-王静：对，那是实时监控，或者叫实时报表，我之所以纠结BI实时，是因为新项目需求，我们不接要求实时的案子，因为一直觉得BI做不了实时，所以对这块如果遵循BI架构做成功的方法难以理解。模型一旦建立，用户可以根据自己的需要组建不同的视图，而实时报表或者监控系统是没有原型的。
贾岩：是的，BI只能做部分关键指标实时，不能所有都实时。
主持人：讨论还在继续，BI、大数据、数据挖掘都是我们可聊的话题，小伙伴儿们收获多多啊
主持人：预告一下，我们下周微信直播的话题有：
1、数据挖掘在会员分析方面的应用，包括并不限于会员分级、精准营销、交叉销售、流失分析等。
2、数据挖掘过程的关键点及难点探讨。
3.、百货零售行业的应用、数据质量、数据治理、分析模型等等。
感兴趣的朋友快来报名吧。
参与方式
每周 Friday BI Fly 微信直播参加方式，加个人微信：liangyong1107 并发送微信：行业+姓名，参加天善智能微信直播。
天善公众号
