数据仓库

 数新网络官网已全新上线，欢送点击拜访www.datacyber.com 数新网络_让每个人享受数据的价值 1 什么是拉链表拉链表是针对数据仓库设计中表存储数据的形式而定义的，顾名思义，所谓拉链，就是记录历史。记录一个事物从开始，始终到以后状态的所有变动的信息。比方上面的表： 编辑 下面就是一个简略的拉链表，记录了每个用户随着工夫的变动其等级的变动状况。 2 拉链表的应用场景在数据仓库的数据模型设计过程中，常常会遇到上面这种表的设计： 有一些表的数据量很大，比方一张用户表，大概10亿条记录，50个字段，这种表，即便应用ORC压缩，单张表的存储也会超过100G，在HDFS应用双备份或者三备份的话就更大一些。表中的局部字段会被update更新操作，如用户联系方式，产品的形容信息，订单的状态等等。须要查看某一个工夫点或者时间段的历史快照信息，比方，查看某一个订单在历史某一个工夫点的状态。表中的记录变动的比例和频率不是很大，比方，总共有10亿的用户，每天新增和发生变化的有200万左右，变动的比例占的很小。3 拉链表的实现创立2020-5-1的数据  CREATE TABLE IF NOT EXISTS link_first( user_id BIGINT ,name STRING ,level STRING ,time STRING )COMMENT "link_first";insert into link_first values (1,'甲','A','2020-05-01'),(2,'乙','B','2020-05-01');SELECT * from link_first 数据如下： 编辑 创立2020-5-2的数据  CREATE TABLE IF NOT EXISTS link_second( user_id BIGINT ,name STRING ,level STRING ,time STRING )COMMENT "link_second";insert into link_second values (1,'甲','A','2020-05-02'),(2,'乙','A','2020-05-02'),(3,'丙','B','2020-05-02');SELECT * from link_second 数据如下： 编辑 创立历史表存储5月1日数据，并对格局进行整顿  CREATE TABLE IF NOT EXISTS level_his( user_id BIGINT ,name STRING ,level STRING ,start_time STRING ,end_time STRING )COMMENT "level_his";INSERT OVERWRITE TABLE level_hisSELECT FROM ( SELECT DISTINCT(user_id),name,level,'2020-05-01' as start_time,'9999-12-31' as end_time FROM link_first --WHERE id !='')t SELECT  from level_his; ...

一、快手实时数仓的倒退作为短视频畛域的领头羊，快手 APP 始终致力于视频、直播技术的迭代，其背地对数据实时性、准确性的要求十分高，这对于数仓体系的构建也提出了新的挑战。上面是快手实时数仓倒退到当初经验的几个阶段： 在第一个阶段，快手的实时数仓起始于春节、国庆、快手之夜等大型流动场景。在这些流动场景下，实时数据次要用于满足流动大屏、经营看板、流动成果监控等实时需要。在这个阶段咱们基于屡次流动场景的实时化建设，积淀了流动流量、用户激励等流动通用的数据。残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1189954 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

导读： 随着业务量快速增长，云积互动对数据的实时性及灵活性提出更高要求，晚期基于 CDH 的大数据平台已无奈满足以后难度以及复杂度较高的的业务需要，因而云积互动于 2021 引进 Apache Doris 在局部业务中应用，并在应用过程中逐步发掘出 Apache Doris 更多弱小之处以及劣势，最终决定在 2022 年全面利用 Apache Doris ，基于 Apache Doris 来构建云积互动企业级实时离线对立数仓。 作者｜云积互动大数据团队 王杰&蒙磊 业务背景云积互动，全称深圳市云积分科技有限公司，成立于 2014 年，是国内当先的 AI 驱动的消费者经营服务提供商，致力于倒退消费者经营相干实践、技术、算法、模型及软件工具，为寰球消费性企业提供基于 AI 的消费者经营零碎及经营策略服务，打造消费者经营畛域最佳服务和实际规范，帮忙企业构建消费者经营外围能力，以应答以后及将来的场景化经营挑战。目前已成为天猫、京东、抖音、腾讯等支流电商和社交平台深度合作伙伴，服务客户 2300+，其中世界 500 强客户超过 18 家，包含寰球第一的美妆、日化、医药集团，均深度服务超过 7 年。 业务需要云积互动的次要业务是以消费者经营为外围，蕴含了会员通，CRM，策略营销，数据资产等一系列业务，如下图所示。 晚期云积互动的大数据需要较少，起步也比拟晚，2019 年才开始搭建基于 CDH 的大数据平台，因而大数据平台的次要目标是为了满足晚期较为繁多的 BI 数据看板及报表性能。近年来，随着业务量快速增长，数据量的增长，业务对数据的实时性及灵活性提出更高的要求，大数据平台也从晚期的只须要满足繁多的 BI 服务需要，扩大到须要反对各业务线，蕴含圈人服务，人群剖析，AI智能数据等多种业务需要。晚期基于 CDH 的大数据平台已无奈满足以后难度以及复杂度较高的的业务需要。 大数据平台的迭代晚期数仓架构晚期公司业务量较少，基于 Hive+Spark 构建的离线数仓即可满足晚期大数据的需要。晚期架构次要用于反对 BI 相干性能，数据大屏，自助报表等利用，大部分的指标仅要求 T+1 的指标。 下图为云积互动晚期数仓架构，晚期的数据源次要为业务数据库 MySQL 以及日志，数据通过 Streamsets 实时采集数据并经 ETL 后传入ODS层，存储到 Kudu 中，通过 Impala 对 ODS 层的数据进行解决，实现实时查问业务的需要。通过 Hive 构建了离线数仓的 DWD、DWS 以及 DIM 层，应用 Spark 进行离线工作的计算与调度，最终解决并计算实现的数据输入到 MySQL 和 Kylin 中，利用于下层业务利用及剖析。 ...

这一篇整顿下订单域的数仓设计。目前市场上的企业都有很多销售渠道，线下门店以及各个电商平台，那么要想及时理解销售状况，获取、整合数据以及进行剖析就显得尤为重要，订单模型就是一套依照迷信零碎的办法设计的整合所有渠道订单数据的、省去人力反复加工数据过程的分析模型，所以订单模型对于大部分企业来讲还是很有价值的。我做过三个我的项目的订单模型设计，接下来就依照这个分类说说订单模型设计的那些事儿： 订单模型设计指标订单模型组成数据获取和传输业务梳理数据源探查订单模型设计订单模型利用一、订单模型设计指标1. 统一口径，增强数据可解释性如果一家销售美妆的企业，有多家线下门店，电商平台有淘宝、京东、微商城，那么如果想查看最近一个月的销售额，则须要手机各方数据再进行汇总，期间可能会因为工夫统计周期不同或者销售额口径不统一（例如线下门店是营收额，电商平台是减了退款的不含税的销售额）导致最初的后果失去准确性和可解释性，进而失去剖析的意义。订单模型在设计之初就会对立销售渠道的数据口径，确保数据对齐。 2. 缩短数据获取周期和老本以上统一口径中提到的例子中，数据获取可能还绝对容易些，因为各门店和电商平台都有本人的销售额看板，然而想剖析明细数据的话，就须要自行导出各个平台的明细订单数据，期间可能会因为各个平台的商品编码、订单状态不对立，须要对商品编码、订单状态进行 mapping 转换，在进行真正的剖析之前就减少了很多前置预处理工作。那么订单模型就承当了这个工作，对立各渠道数据，独特应用一套数据字典，并且应用数据工具定时拉取个平台的数据进行整合计算，极大地升高了剖析数据的老本。 3. 便于数据分析当订单模型上线之后，数据分析人员就能够持续订单模型进行不同维度的剖析探查，缩小了数据获取和剖析的老本，更具时效性；若指标探查后具备剖析意义，可落地成标签或者报表指标，由平台主动计算。 二、订单模型组成订单模型个别由“订单父表” 和 “订单子表” 组成，搭配“维度模型”一起应用。 1. 订单父子表订单父表是基于订单维度的一张表，个别蕴含订单的编号、工夫、状态、渠道，消费者信息，收货人信息，数量金额信息以及门店信息等；而订单子表是订单明细表，除了记录订单的根本信息外，还会记录商品明细的一些信息，例如商品编码、商品价格等。 2. 退单父子表退单父子表和订单父子表是一一对应的，退单次要记录退货商品的数量、金额以及正向单据的一些信息，用于正负单关联，得出减退款退件口径的指标。 3. 维度模型订单模型个别搭配维度模型应用，维度模型常见有“商品维度模型”，存储商品的详细信息如编码、生产日期、容量、分量等，个别商品信息繁多，全副存储在订单模型会显得十分冗余，而且剖析场景不是特地频繁的状况下，能够只在“订单模型”保留商品编码，须要剖析商品其它维度信息的时候，能够用“订单模型”关联“商品维度模型”进行其它粒度的剖析。 三、数据获取和传输个别数据仓库是一个独立于各平台的企业级的数据库，各个销售渠道个别有独自的数据库，那通常获取源数据的形式有三种： API 获取：须要开发 API 接口，有开发成本，而且 API 提供方可能因为各种因素会限度数据的返回数量；然而对于数据提供方来说，这种形式更平安更灵便；应用ETL工具：从源数据库通过脚本和工作加载到指标数据库，对应用方来说比拟不便；然而对于数据提供方来说有安全隐患，数据权限和调用频率也不好管制，个别也是抽取源的备份数据库；文件传输：也能够应用excel、csv 或者 txt ，上传 SFTP 服务器。个别数据传输周期是 T+1，当然也有实时传输的场景，可用kafka等音讯队列进行传输。 四、业务梳理1. 明确数据的业务含意这一步尤其重要，要先明确各渠道订单数据字段的含意和口径，能力确保数据的真实性和可解释性，例如“销售额”须要明确：是否含税、是否减退款、是否减折扣、是商品总金额还是付款金额，“订单工夫”须要明确：是下单工夫还是付款工夫还是发货工夫等。另外对于用户信息也须要分外留神，明确手机号、openid之类的数据是明文还是密文，因为后续触达的话须要保障身份信息可用。 2. 明确业务规定数据更新场景 因为波及到指标数据库的数据更新，所以要理解哪些状况下订单数据会更新。常见的有订单状态、订单 工夫的更新，以及退款之后金额字段的更新，那么一笔订单从创立到关单的周期是多长也须要理解。业务规定 常见的业务规定比方淘宝店铺积分是如何产生的、积分有效期如何计算、店铺会员是什么折扣、套装折扣产品的成本价如何计算等等，这些须要依据具体业务场景细细理解，才便于发展后续的建模以及剖析工作。 五、数据源探查1. 主键确认这一步对于订单数据更新也很重要，个别订单表的主键是“订单编号”或者“数据库自增id”，订单明细表的主键是“订单编号”+“商品编码”或者“数据库自增id”，然而通常状况下可能不会这么简略，因为很多订单零碎设计的不太正当，这时候能够做一些解决，以下是我碰到的几种状况： 订单明细表一笔订单存在多行雷同商品编码的订单明细，产生多行的起因是一些商品加入了套装流动，价格产生了折扣即不同于单品的价格，当用户独自购买了该单品和含该单品的套装时，该商品因为价格不同就会被拆成2行，那么在订单明细表没有其它主键标识的状况下，如何标识主键进行后续的数据更新呢？--最间接的方法还是从源头解决，革新源订单零碎，减少主键标识；然而在源订单零碎没方法革新的状况下，也能够用一个笨办法，即指标订单表用“订单编号”+自生成的“订单明细序列号”作为主键，当源表订单中任一明细产生扭转的状况下，抽取该订单的全副订单明细更新该订单的所有明细。订单父表主键为“订单编号”+“门店编码”，且主键存在反复，那第一步须要查看反复订单的信息是否雷同，若全副雷同的话，则可间接疏忽；若主键雷同订单的订单信息不同，则须要查看起因，是否订单源零碎的问题，是否修复，若是极少产生的事件，则能够手动更改历史订单的主键信息；若是常常产生的状况，则须要源订单零碎做数据上的修改。 2. 身份id探查在业务梳理的时候理解到的身份 id 例如手机号、openid 等，须要探查数据的可用性和填充率：例如手机号是否非法、是否为虚构号，openid 是否非法、字符串是否含空格等；如有空格之类的可解决的须要荡涤掉，不非法的身份id须要从源头思考怎么能获取实在可用的数据，或者有没有其它的 id mapping 关系能够关联获取，进步身份 id 的填充率； 3. 数据字典搞清楚字段的含意之后，就须要对立各渠道的数据字典，便于后续剖析。 例如淘宝的订单状态为：已下单已付款已发货已收货京东的订单状态为：未付款已付款期待发货已发货确认收货那么从业务流程来讲，京东的”未付款”、“已付款”、“已发货”、“确认收货”和淘宝的“已下单”、“已付款”、“已发货”、“已收货”是一个含意，须要对立名称；京东的“期待发货”较淘宝是多进去的一个中间状态，能够保留，相当于看不到淘宝订单已付款未发货的订单，只能看到京东这个状态的订单；再例如商品编码对立，我之前碰到企业各渠道的商品编码不对立，例如 一款洗发水，A零碎存的是 “S001 450ml”，B零碎存的是“S001_450ml”，这个时候就须要进行对立荡涤解决；另外还有其它字段：领取形式、退款状态等都需一一对照对立，可依据理论业务而定。 4. 异样值解决订单中可能还会呈现一些异样值，例如超过字典范畴的枚举值，需确认是否新的枚举或是异样，异样是否能够置空或者转换成其它枚举值；例如日期字段存储成了数值，是否能够将该日期间接置空，或者用其它日期字段赋值。 5. 确认数据类型除了以上步骤，最重要的就是确认数据字段类型了，这会影响到后续指标的计算，例如日期是什么格局、数值类型的是int还是decimal，数值类型是否有空值（计算过程中需将null转0），字符串长度是否超过存储要求等等，非凡状况能够根据理论状况来调整。 六、订单模型设计1. 字段对齐通过之前的业务梳理以及数据源探查之后，数据能够说是荡涤洁净了，那么就到了订单模型设计阶段，其实比较简单，只需将各个源业务零碎的字段分类，而后对应起来即可，如果对应不起来的，独自存在即可，另外也可依据字段信息重要成都酌情删减；常见的订单父表分类如下：订单子表除了订单根底信息模块和订单主表不同，还多了商品信息模块： 2. 数据荡涤加工设计好之后就能够进行数据ETL的解决，个别将源零碎的订单数据分表存储在 ods 层，在 dwd 整合成“订单主表”和“订单子表”，在 dm 层进行个性化指标的计算；当然这个分层也不是相对的，也要依据具体实施我的项目的产品和条件来定。 ...

当下，企业的实时计算需要越来越高频，很多企业和组织抉择建设实时数据仓库，以麻利撑持实时报表剖析、智能算法举荐、零碎危险预警等多元业务场景需要。 相比离线数仓，实时数仓有哪些个性？如何进行实时数仓的技术选型？ [**个推TechDay“治数训练营”系列直播课第二期来了！ 8月24日（下周三）早晨19:30-20:30，个推资深数据研发工程师为您解读实时数仓架构演进，分享实时数仓技术选型要点，并联合实战案例具体分析实时数仓的搭建秘诀。**](https://mp.weixin.qq.com/s/u_...) 更有超多惊喜福利等你拿！

数据仓库系列文章数仓架构发展史数仓建模方法论数仓建模分层实践数仓建模—宽表的设计数仓建模—指标体系一文搞懂ETL和ELT的区别数据湖知识点技术选型 | OLAP大数据技术哪家强？数仓相干面试题从 0 到 1 学习 Presto，这一篇就够了！元数据管理在数据仓库的实际利用做中台2年多了，中台到底是什么呢？万字长文来聊一聊中台数据仓库之拉链表sqoop用法之mysql与hive数据导入导出关注公众号：大数据技术派，回复材料，支付1024G材料。指标体系提起指标这个词，每个人仿佛都能够说出几个指标，像常常在工作中会听到的日活、月活、注册率、转化率、交易量等 事实上指标就是用来量化事物的一个工具，帮忙咱们去将一些形象的事件得出一个轮廓上的形容。例如咱们能够从指标上判断一个产品的好坏，用户粘性等等，例如咱们通过日活能去判断出咱们整个产品的用户量，从而能反馈出咱们这个产品的一个衰弱水平，也就是否处于增长过程中。 一个好的数据指标体系能够助力业务疾速的解构业务、了解业务、发现业务问题，疾速定位起因，并且找到最合适的解决方案。因而学习搭建一个好的数据指标体系是数据助力业务决策的灵魂。 指标，实际上就是一种度量。大到用于监控和评估商业过程的状态，小到掂量某个功能模块的状况，或者是本人的流动成果。指标体系的构建，是为了让业务指标可度量、可形容、可拆解，所以咱们的指标是基于业务指标抽取和评估的数据维度，这些数据为度能够用来帮忙达到业务指标。 从而进行业务状况的监控、找到以后业务问题、评估业务可改良的中央，找出下一步工作的方向。 其实小到集体，大到国家都有各种各样的指标，就连数字中国最要害的也是各种指标指数的定义和修改机制的建设！ 指标建设过程中遇到的问题指标没有重点、没有思路，构建实现后也只是一组数据，各有用途，合起来却起不到作用； 指标空洞，粗看有模型又有分类，细看流程中却没有几个具体的指标，无奈落地 指标不足数据，导致业务上线了又开始增加指标、减少维度，最初报表变得臃肿，数据参差不齐，影响工作推动 指标建设方法论上面是常见的指标体系建设办法，咱们比拟罕用的是OSM+UJM 模型，当然这也不是相对的，次要还是得看咱们的业务场景和业务指标 北极星指标人货场指标体系目前阶段互联网业务比拟风行的一种通用形象场景“人、货、场”，理论就是咱们日常所说的用户、产品、场景，在艰深点讲就是谁在什么场景下应用了什么产品，不同的商业模式会有不同的组合模式。 以滴滴理论场景为例：哪些场景（此处场景定义为终端，如Native，微信，支付宝）的什么人（乘客）在平台上应用了哪些货（平台业务线，如慢车/专车等），进而为评估用户增长的价值和成果。 “人”的视角 从“人”的视角，咱们比较关心的是什么乘客在什么工夫打的车，排了多长时间，等了多长时间上车，周期内第几次打车，打车花了多少钱，是否有投诉和勾销行为，具体到数据指标次要看发单用户数、完单用户数、客单价、周期内完单订单数、勾销订单数、评估订单数等 “货"的视角 从“货”的视角，咱们比较关心的就是成交了多少，交易额多少，花了多少，到具体数据指标次要会看GMV、成交率、勾销率指标，在进一步会细分到城市、区域，一级品类、二级品类。数据的成果通过指标比照，横向比照、历史比拟等形式进行剖析确定。 “场”的视角 从“场”的视角，咱们比较关心的就是哪个渠道用户点击量大曝光率大，带来了多少新用户，实现多少交易订单，客单价是多少；或者是哪个流动拉新或促活成果怎么样转化率多少，联合场景数据理论状况制订对应策略。 以上别离从“人”、“货”、“场”三个角度进行了数据指标和剖析维度的提炼，上面咱们把三类指标联合指标分级办法进行合成关联。 OSM+UJM 模型OSM+ AARRR海盗模型指标分级办法指标分级次要是指标内容纵向的思考，依据企业战略目标、组织及业务过程进行自上而下的指标分级，对指标进行层层分析，次要分为三级T1、T2、T3。 T1指标：公司策略层面指标 用于掂量公司整体指标达成状况的指标，次要是决策类指标，T1指标应用通常服务于公司策略决策层 T2指标：业务策略层面指标 为达成T1指标的指标，公司会对指标拆解到业务线或事业群，并有针对性做出一系列经营策略，T2指标通常反映的是策略后果属于支持性指标同时也是业务线或事业群的外围指标。T2指标是T1指标的纵向的门路拆解，便于T1指标的问题定位，T2指标应用通常服务业务线或事业群 T3指标：业务执行层面指标 T3指标是对T2指标的拆解，用于定位T2指标的问题。T3指标通常也是业务过程中最多的指标。依据各职能部门指标的不同，其关注的指标也各有差别。T3指标的应用通常能够领导一线经营或剖析人员发展工作，内容偏过程性指标，能够疾速疏导一线人员做出相应的动作。 指标的形成指标 = 业务维度形容 + 技术维度形容 指标，是反映某种事物或景象，形容在肯定工夫和条件下的规模、水平、比例、构造等概念，通常由指标名称和指标数值组成。指标分类简略计数型指标简略计数型指标是指可通过反复加1这一数学行为而取得数值的指标，如UV（Unique Visit , 独立访客数）、PV（Page View，页面浏览量）复合型指标通过若干个根底指标计算得来的指标，在业务角度无奈再拆解的指标复合型指标是由简略计数型指标经四则运算后失去的，如跳出率、购买转化率。在计算指标时，咱们还会波及绝对数、相对数；百分比、百分点；频率、频数；比例、比率等计算形式。根底指标不能再进一步拆解的指标，能够间接计算出来的指标，如“订单数”、“交易额”衍生指标在根底指标的根底上，通过某个非凡维度计算出的指标，如“微信订单数”、“支付宝订单数”指标分级在进行整个指标分级的时候，咱们须要先思考：一级二级指标，是否反馈产品以后的经营状况；三级四级指标是否帮忙一线人员定位问题，领导经营工作。 数据自身是分层的，咱们在思考指标的时候，也应该有一个层级的概念，而不是现阶段关怀什么，咱们就放什么；指标分级能够帮忙咱们更高效的去定位问题，去验证你的方法论，无需每次都要思考要去看哪些指标 公司策略层面指标用于掂量公司整体指标达成状况，通常设定在5-8个指标。这类指标是与业务紧密结合，依照行业标准进行制订，有可参考的行业标准指标，且这类指标针对全公司所有员工均具备外围的指导意义。比方某游戏公司的一级指标：新增账号、留存率、DAU/MAU、付费人数（率）、支出金额等。业务策略层面指标为了实现一级指标，企业会做出一些策略，二级指标通常与这些策略有所关联。能够简略了解为一级指标的实现门路，用于更快定位一级指标的问题。某游戏公司一级指标是游戏支出，那么二级指标能够设定为不同游戏物品的支出。一级指标是DAU，那么二级指标设定为分服务器的DAU等。这样当一级指标呈现问题的时候，咱们能够疾速查问到问题的所在点。业务执行层面指标三级指标是对二级指标的门路拆解，用于定位二级指标的问题。三级指标的应用通常是能够领导一线人员发展工作的指标内容。三级指标的要求是：一线人员看到指标后，能够疾速做出相应的动作。游戏公司的二级指标是XX区服的DAU，那么三级指标则能够设定为游戏时长、游戏频次、游戏等级散布、游戏关卡散失状况等。通过观察这些数据，能够去针对性地做调整，如某个关卡散失的用户特地高，那么尝试升高难度。如何设立指标体系为什么要建设数据指标体系当咱们的业务呈现数据异样时，因为数据很多，往往会一遍遍地从这些数据中去寻找能够定位起因的相干指标，这不仅会节约很多工夫，还会使人心疲力竭。「指标」是一种度量，它用于追踪和评估商业过程的状态，确保我的项目务在正确的轨道上经营，同时验证方法论，一直地学习。指标监控体系最大的价值就是帮忙大家高效利用工夫，把工夫花在解决问题上，而不是寻找问题上，从而进步团队整体的人效 指标也是指标，没有指标就不晓得做什么，搭建指标体系是为了更好地发现用户的问题，并且去解决。所以咱们须要站在用户的场景去思考整体的内容。 首先咱们来看下为什么咱们须要一个好的数据指标体系。这边给大家看一个故事，预计大家都会比拟有体感：大家有没有在中午收到过老板的信息，问为什么业务上的外围指标GMV降落了？而后这里边咱们产品同学小六就会连忙把电脑关上，然而他所有能获取的信息就只有一个Dashboard，里边只有一个GMV外围指标，环比同比同时降落，这个时候他怎么答复老板的问题？ 后果根本靠猜，是不是竞对做了一些流动？是不是某个主播停播了？另外一种可能性的状况是小六同学手里边有一百多张报表，这一百多张报表里边，有四百多个指标，而后每一个指标都在降落，那在这种状况下，也没有方法答复老板的问题，为什么这个外围指标降落，到底是DAU降落了，还是用户满意度降落了，还是转化效率降落了等等？ 另外一种状况是老板同样提了这样一个问题，而后另外一个产品同学小快不紧不慢的拿出了一张这样的一个报表体系，他说：“老板，我认为GMV降落会跟整个业务流程都有相关性，咱们从业务角度进行了这样的一个拆解，发现在流量入口，和最初的人均生产来看的话，其实并没有降落，次要降落起源其实来源于列表页转化效率的降落。再往下拆解，发现高价的商品的曝光占比和高价的曝光占比并不太均衡。高价商品的一个曝光占比比拟高，然而它的转化效率却是低的，所以从这个角度来讲，我认为可能在列表页来外面的不同价格的商品的散发策略或者曝光策略须要进行优化，而后通过A/B test去看一下咱们这个策略调整的成果是什么样子的”。 咱们看到数据指标体系能够帮忙咱们 整体了解业务、全面理解问题、疾速定位起因、迅速落地计划，咱们说的指标体系不止是指标，还有指标治理和指标监控 如何建设指标体系 OSM 模型OSM模型（Obejective，Strategy，Measurement）别离代表业务指标、业务策略、业务度量 O：用户应用产品的指标是什么？产品满足了用户的什么需要？咱们的经营指标是什么 如果你是公司的负责人，想一想公司的外围指标是什么，可能是公司往年的利润额。如果你是产品部门负责人，那你须要思考将来几年的产品布局 S：为了达成上述指标我采取的策略是什么？这些策略往往是一些列的 M：这些策略随之带来的数据指标变动有哪些？它用于掂量咱们的策略是否无效，反映指标的达成状况。「业务度量」波及到以下两个概念：一个是 KPI ，用来直 接掂量策略的有效性；一个是 Target，是事后给出的值，用来判断是否达到预期。 ...

关注公众号：大数据技术派，回复“材料”，支付1024G材料。 数据仓库系列文章数仓架构发展史数仓建模方法论数仓建模分层实践数仓建模—宽表的设计数仓建模—指标体系一文搞懂ETL和ELT的区别数据湖知识点技术选型 | OLAP大数据技术哪家强？数仓相干面试题从 0 到 1 学习 Presto，这一篇就够了！元数据管理在数据仓库的实际利用做中台2年多了，中台到底是什么呢？万字长文来聊一聊中台数据仓库之拉链表sqoop用法之mysql与hive数据导入导出宽表的设计其实宽表是数仓外面十分重要的一块，后面咱们介绍过了维度表事实表，明天咱们介绍一下宽表，后面咱们说过了数仓是分层的，这是技术提高和时代变动相结合的产物，数仓的分层式为了更好地治理数仓以及更加高效地进行数据开发。 宽表次要呈现在dwd 层和报表层，当然有的人说dws 层也有，宽表，从字面意义上讲就是字段比拟多的数据库表，通常状况下是将很多相干的数据包含维度表、实时、已有的指标或者是dws/dwd 表关联在一起造成的一张数据表。 因为把不同的内容都放在同一张表存储，宽表曾经不合乎范式设计的模型设计规范而且数仓外面也不强调范式设计，随之带来的就是数据的大量冗余，与之绝对应的益处就是查问性能的进步与便捷。 分层 请参考 数仓建模—分层建设实践 设计 请参考 数仓建模—建模方法论 为什么要建设宽表就像咱们后面说过分层的目标是为了治理不便、开发高效、问题定位、节约资源等等，那么咱们建设宽表呢？后面学习建模方法论的时候，提到过维度模型的非强范式的，能够更好的利用大数据处理框架的解决能力，防止范式操作的过多关联操作，能够实现高度的并行化。数据仓库大多数时候是比拟适宜应用星型模型构建底层数据Hive表，通过大量的冗余来晋升查问效率，星型模型对OLAP的剖析引擎反对比拟敌对，这一点在Kylin中比拟能体现。 能够更好的施展大数据框架的能力维度模型能够更好地利用大数据框架，体现在哪里的，体现在数据数据冗余，能够防止很多的关联，怎么体现的呢，宽表。然而这只是站在大数据框架层面上的了解，还有其余层面上的了解。 能够进步开发效率个别状况下，咱们的宽表蕴含了很多相干的数据，如果咱们在宽表的根底上做一些开发，那就很不便，咱们间接从宽表外面取数据，防止了咱们从头计算，你构想一下你要是没次都从ods开发一张报表，那是多苦楚的体验啊。 能够进步数据品质宽表的准确性，个别都是经验了工夫的测验的，逻辑谬误的可能性很小，能够间接应用，要是让你从头开发，那这个过程中可能因为对业务了解不透彻或者是书写的逻辑不正确，导致有数据品质问题 能够对立指标口径其实这一点和下面一点有点反复，然而这两点的强调的方面是不一样的，因为如果咱们的报表要是都能从咱们的底层宽表出，那么咱们报表上的指标必定是一样的，其实这一点我置信很多人都深有体会，同一个指标的口径不统一，导致咱们提供的数据在不同的进口不一样，是业务部门常常提出的一个问题。其实这也就是咱们始终强调的外围逻辑下沉的起因。 宽表的益处和有余宽表的益处就是咱们后面提到过的咱们为什么要建设宽表的起因，接下来咱们看一下宽表的有余 性能不高因为咱们的宽表的计算逻辑往往很简单，再加上宽表的数据输出是有大量依赖的，也就是说须要解决的数据量很大，在负载逻辑+大数据量的起因下，导致咱们的宽表往往运行很慢，资源占用很多，尤其是重跑的时候。 稳定性不高 上面的最初一张表就是一张宽表，咱们晓得一个零碎的稳定性是取决于最差的一个环节的，这就是短板实践也叫木桶实践，咱们的宽表的稳定性也是很差的，这个次要是因为咱们的宽表依赖太多，每一个表的不稳定性都会传到到宽表。 假如 一张表依赖A B C 三张表，并且这三张表的稳定性是 1/m 1/n 1/x,那么咱们的宽表的稳定性就是 1/m*n*x ,至于表的稳定性你可用它胜利运行的次数/运行的总次数 如果性能不高和稳定性不高同时作用在一件事上的时候咱们晓得这其实是很致命的，例如你发现报表数据有问题，然而重跑须要几个小时，哈哈！ 开发难度大/保护老本高咱们说了基于宽表做报表开发才是正确的姿态，然而宽表自身也是咱们开发人员开发的，因为自身的逻辑很简单设计的业务逻辑繁多，所以给咱们的开发就带来了挑战，而且因为业务逻辑的变更咱们也须要去保护着简单的逻辑，例如每次都让你在几千行的SQL 外面加逻辑。 如何设计宽表宽表的益处和有余咱们都讲了，也就是说宽表虽好，然而带来的问题也很多，上面咱们就看一下如何从设计的角度来防止宽表的不足之处 宽表到底多宽开始之前，咱们思考一个问题，那就是宽表到底有多宽，就想咱们后面讲分层的时候说其实咱们不分层也玩得转，早起的数仓就只有一层，当初咱们思考一个问题那就是宽表到底多宽才适合，其实你要把所有的数据装进去也能够。 所以咱们要思考到底多宽才适合的，后面咱们介绍过数据域的概念，咱们与其答复多宽这个问题，不如答复宽表都应该笼罩哪些数据，然而这个问题也不好答复，然而咱们能够反着思考，宽表不应该蕴含什么数据，这个问题很好答复，宽表不应该蕴含不属于它所在域的数据，例如会员域的宽表只应该蕴含会员相干的信息，同理咱们的宽表是针对某一个域而言的，也就是说它是有边界的。 这下咱们再来答复宽表到底多宽，只有不跨域，并且方便使用都是正当的。然而这仿佛并不能解决咱们下面提到的宽表的有余，只是指明了宽表的一个大抵的方向。有了方向之后咱们通过咱们的设计策略就能够让宽表瘦下来。 主次分类主次拆散，其实咱们常常听到的一句话就是做事件要搞清楚主次，咱们看一下表设计的主次是什么，假如咱们做的是一个会员域的宽表，然而会员域是还是一个比拟大的概念，所以咱们还要发掘出咱们这个表的主题，例如咱们做的是一张会员域下的会员根本信息宽表，那么咱们专一的必定就是根本信息，例如会员信息买通。当让因为事宽表你可能还会冗余的其余信息进来，然而当这样的信息越来越多的时候，咱们这张表的主题就越来越弱，所以咱们就须要做拆分。 拆分能够让咱们更加聚焦表的主题，对于数仓开发人员而言能够更好的保护、对于应用方而言能够更加分明的了解这张表的主题。 冷热拆散除了后面的主次拆散咱们还能够做冷热拆散，其实冷热拆散这个词我置信你不是第一次听到，然而怎么看这个事件呢，你想一下你在数据存储的时候是怎么做冷热拆散的，这里也是同样的理念。 假如我有一张宽表，外面有200个字段，有30张报表在应用它，然而我发现后面150个常常字段常常被应用，前面 50个字段只有一两张报表应用到了，那么咱们就能够做一个冷热拆散，将宽表拆分。 稳固与不稳固拆散其实后面的主次拆散、冷热拆散都能够进步稳定性，然而后面咱们不是为了稳定性拆散的。 咱们常常有这样的宽表，它依赖埋点数据，然而咱们的埋点数据的特点就是量大，导致计算常常提早，那么咱们的宽表就会受影响，从而咱们的报表就受影响，然而很多时候你发现报表基本没有用过埋点计算出来的指标，或者是只用了一两个。那咱们能够将其拆分，如果报表没有应用到那就最好了，如果应用到了，那就后推，在报表层面上做关联，这样咱们的埋点数据即便出不来，咱们的报表数据还是能够看的。 总结次要解说了一下几个方面 为什么要建设宽表宽表的有余如何设计宽表 宽表到底多宽主次拆散冷热分类稳固与不稳固分类设计宽表的实践其实说白了就是一句话高内聚低耦合，当然这几个字你在其余畛域可能很相熟了，然而这里你就好好思考一下能力想通，我始终新崇奉的是一力降十会 一拙破万巧 也就是说你要学会基本的货色，能力触类旁通破万难。 猜你喜爱Spark SQL知识点与实战Hive计算最大间断登陆天数Hadoop 数据迁徙用法详解Hbase修复工具Hbck数仓建模分层实践Flink 是如何对立批流引擎的

关注公众号：大数据技术派，回复“材料”，支付1024G材料。数据仓库系列文章(继续更新) 数仓架构发展史数仓建模方法论数仓建模分层实践数仓建模—宽表的设计数仓建模—指标体系数据仓库之拉链表数仓—数据集成数仓—数据集市数仓—商业智能零碎数仓—埋点设计与治理数仓—ID Mapping数仓—OneID数仓—AARRR海盗模型数仓—总线矩阵数仓—数据安全数仓—数据品质数仓—数仓建模和业务建模数据集市(DM)这里咱们先回顾一下数据仓库的定义， 数据仓库(Data Warehouse) 是一个面向主题的(Subject Oriented) 、集成的( Integrate ) 、绝对稳固的(Non -Volatile ) 、反映历史变动( Time Variant) 的数据汇合用于反对管理决策。更多对于数据仓库的能够参考数仓架构发展史,而且后面咱们也介绍了大量对于数仓建模这一块的内容，具体能够参考咱们的专栏数仓建模方法论。 明天咱们介绍一个在数仓中十分常见的概念——数据集市，数仓定义中的五个个性都值得一一认真品尝，随着你对数仓的了解加深，你对这个五个个性的了解也会更加全面。 首先数据仓库用于反对决策,面向剖析型数据处理,它不同于企业现有的操作型数据库;其次,数据仓库是对多个异构的数据源无效集成，集成后依照主题进行了重组,并蕴含历史数据并且寄存在数据仓库中的数据个别不再批改。 什么是数据集市(DM)这里有一个词是主题，那就是咱们集成后的数据，又依照了主题进行了划分，而面向主题划分进去的局部就是数据集市，也就是说数据集市是数据仓库的一个子集或者说是集成后的子集。 数据集市通常是面向部门的或者是部门级业务，或者是面向部门的主题的，举个例子例如在金融畛域可能会有结算部门的数据集市、风控部部门数据集市、市场部门的数据集市、经营部门的数据集市，这里的特点就是面向部门的，然而对于有的部门它的组织构造可能比拟大，所以它所负责的业务线也有多个，这个时候就会呈现，数据集市是面向部门的子业务，总之一句话，数据集市是面向主题的，个别公司的主题就是部门或者业务线。 这里还有一点要强调数据集市是作为咱们数仓的一层，对外提供数据服务，当然提供服务的形式是有很多种的，然而最终咱们是将数据集市层的数据提供进来的，也就是说这一层是面向用户的。 为什么要有数据集市下面理解了什么是数据集市，接下来咱们就看看一下为什么要有数据集市，开始之前咱们线回顾一下后面的数仓建模分层实践,咱们晓得了数仓最简略的就是ODS+DM，但为什么咱们还要分层，在文章中咱们解释了分层的意义是什么，如果你遗记了能够看一下后面的文章。 这里咱们晓得了数据集市是数据仓库的子集，咱们能够把分层看作是横向切分，那么数据集市就是竖向切分， 所以咱们能够得出一个论断那就是数据集市的划分也是为了更好的治理数仓和进步生产效率，然而这个还是有点形象，上面咱们再讨论一下为什么要做数据集市层。 灵活性这里咱们把数据集成也引入进来，从宏观上看一下从数据源到数据服务，整个数仓的存在模式是怎么的，当然这里咱们是一个简化的图，咱们次要反映出问题就行了。 下面就是咱们以后的数仓状态，这下咱们解释一下咱们为什么要做数据集市层，数据集市层尽管是一个层，然而这层里有多个集市，每个集市面向不同的业务线或者是业务部门，那咱们为什么要这么做呢，说白了就是为解耦，解耦的目标是为了减少灵活性。 如果没有数据集市层，那么咱们的数仓就要面向泛滥的业务部门，然而因为每个业务部门的数据需要或者所关怀的数据是不一样的，这就会导致咱们的数仓建设失去外围，就会呈现咱们为了满足某一个部门而违反了咱们数仓的建设准则的景象呈现，所以咱们减少了数据集市层，也就是每个部门的个性化需要在这里体现。 其实如果你学习过设计模式或者是Java 的话，其实很容易立刻，这有点相似抽象类Service 和 实现类 ServiceImpl. 数据集市有什么特点如果你认真学习了后面的内容的话，你必定能够了解上面的几个特点这里我就不一一解释，而且这些特点也是我总结进去的，你也可有对其进行扩大。 规模小数据仓库是面向企业的，数据集市是面向部门或者特定业务的 面向主题数据集市是面向部门或者特定业务的 间接面向用户数据集市是面向部门或者特定业务的 个性化高数据集市是面向部门或者特定业务的，所以就会呈现灵便多变的特点，而且也会呈现流程上更简略疾速，标准上要求不严格，应用上要尽量简略。其实这会反映到咱们的表上 就是咱们集市层的表个别都是关联好之后的表，应用的时候根本不须要关联，次要是为了使用方便性能高，其实能够看到咱们集市层的表机会都是数仓建模—宽表的设计还有就是咱们集市层的表个别都是冗余了一些相干的字段，次要是为了应答也不妨多变的申请，举个例子业务方想看每个人往年的总生产，我可能会把最大值和平均值都会计算出来。满足需要为第一优先级尤其在一起初创企业，数仓建设跟不上的时候，为了尽快实现需要咱们就会间接从ods层建设DM，从而能够对外提供数据。 如何建设数据集市数据仓库（集市）的设计能够采纳迭代式的办法，也就是说咱们能够依据咱们的实用方一直的去迭代咱们的数据集市，而且也没有任何数据集市是能够一次性建成的。 实践上讲，应该有一个总的数据仓库的概念，而后才有数据集市，然而咱们理论的做法是先确定了数据集市以及咱们的服务对象之后，而后才开始开始建设数据仓库最初才是数据集市，也就是咱们首先设计的是数据集市，然而咱们建设的时候却是首先建设的是数据仓库。 总结数据集市就是数据仓库面向某个主题的子集,它作为数仓面向用户的一层存在，提供数据服务。 据集市往往作为数据仓库之上的一个面向剖析利用或者是数仓里面向用户的一层，也就是说没有这一层的话，咱们的仓库就要面向用户了，咱们能够将其视作代理，因为这一层要面向用户，所以它就有多变和不标准的个性，然而为了保障数仓整体建设的合理性和规范性，所以咱们在数仓上加了这一层。 尽管集市层是面向用户的，然而因为面向的用户群体不同，所以又依据用户群体的特点，将集市层进行了纵向切分，切分成了一个个不同的集市。 数据仓库是面向企业的，数据集市是面向部门或者特定业务的，你能够将其看作一个小型的数据仓库，其实这里牵扯出了晚期数据仓库的一种存在形体，那就是每个部门有本人的数据仓库，而不是对立建设的数据仓库。

更多技术交换、求职机会、试用福利，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群 IDC 2021年报告数据显示，2021年寰球大数据软件市场规模达预计可达5414.2亿人民币。“十三五”期间，我国大数据产业疾速起步，产业倒退获得显著功效，《“十四五”大数据产业倒退布局》更是提到：到2025年，我国大数据产业规模预计将冲破3万亿元。 越来越多企业正在摸索本身数字化转型，政务、金融等各行业也在一直进行数字化产业降级，对数据仓库的易用性、性能等提出了更高的要求。本篇从业务需要和技术趋势两个层面，别离介绍新时代下数据仓库发展趋势。 业务需要：实时性、低成本、疾速上云在企业级数据仓库场景中，须要交融来自多个业务零碎数据库的业务数据，比方交易记录，包含银行存取记录、用户订单记录等，大多数为千万至亿条规模；比方用户行为日志，往往是数据量最大的数据源，包含用户拜访日志、用户操作记录等，数据量通常是业务数据的数百倍。随着大数据利用的深刻倒退，最外围的业务需要如下： 1）进步剖析的实时性最近10年，以hadoop技术体系为代表的大数据平台大规模部署，大大小小的企业和政府部门都搭建了大数据平台和剖析利用，以隔天和小时级数据提早的利用失去了遍及；以Flink为代表的实时计算引擎解决了数据统计场景的时效性问题。 随着业务的倒退和技术的提高，业务部门不再满足于T+1的剖析需要和固化的实时统计，更冀望业务产生后秒级/分钟级提早即可看到统计后果；同时，性能上冀望实现交互性探查剖析数据，毫秒/秒级返回后果保持良好的用户体验。 在新的企业级数据架构中，有些曾经构建了大数据平台的企业，会应用云原生数据仓库构建实时数仓来满足有高时效性要求的业务，以此作为Hadoop平台的补充；有些数据量低于1PB，且没有构建Hadoop等大数据平台的企业，则间接以云原生数据仓库构建轻量级数据仓库。 2）老本可控大数据利用逐渐从互联网企业和政府部门，并深刻到工业企业。各行业都先后进行了业务数据的大集中、用户行为数据和IOT数据的宽泛采集存储，企业和政府单位的数据量更是以每年出现30%以上的增长速度。 在过来集中式架构的数据仓库计划中，建设老本与数据总量正相干，导致老本居高不下；采纳基于分布式架构的大数据计划中，因为存储计算耦合，为了满足存储空间收缩，须要洽购越来越多的服务器。实时的数据采集和存储更是导致数据量继续高速增长。 在新的云原生数据仓库计划中，既要解决数据和利用增长带来的扩展性问题，同时要解决老本问题，将数据存储和计算成本处于可控范畴。 3）反对业务上云依据智库报告的钻研，目前业务上云曾经造成趋势，除游戏视频电商等泛互联网企业之外，在政务、金融、制造业等畛域，正在以公有云和混合云的形式继续上云，从而实现数据上云。 政务云和金融云是两大次要的行业云，平台建设程度较高，同时制造业、医疗卫生、交通等畛域的行业云也在减速改革和放慢建设行业云平台大规模建设和降级，实现数字化治理和经营。 制造业设施上云和云化革新可能实现制造业企业的数据互通和业务互联，撑持造成以数据驱动的智能化制作、实现供应链和上下游业务的网络化协同，以及实现对业务和设施的数字化治理等制造业倒退新模式，引领制造业数字化转型。 业务上云从而数据上云，也在推动数据处理平台的云原生降级。 技术趋势：数据仓库进入云原生时代近年来，以Snowflake为代表的云原生数据仓库失去了客户的认同，市场上获得了微小的胜利。其外围性能和技术点是云原生的架构设计，利用IAAS的高可用和资源池化个性，通过存储计算拆散、多租户隔离、容器化技术，提供数据仓库的扩展性、稳定性、可维护性和易用性，整体上进步资源利用率。国内上，除了Snowflake之外，谷歌的BigQuery、AWS的RedShift、Azure的Synapse都实现了云原生的架构降级，实现了存储计算拆散和多租户治理。Databricks、Fireblot等新生的厂商及产品如雨后春笋一样涌现进去。在国内，阿里云、华为云、腾讯云都推出了本人的云原生数据仓库产品；PingCap的TiDB、鼎石科技的StarRocks等独立产品也抉择了云原生路线。OLAP产品有如下几个技术趋势： 1）云原生的整体架构基于公共云、公有云或混合云的架构设计，利用容器化和微服务等云原生技术，以此实现麻利开发、麻利运维，人造解决扩展性问题。 2）存储服务化对数据存储层进行对立形象，灵便采纳HDFS块存储或S3等对象存储作为数据存储载体，最终实现存储服务化，便于解决存储扩展性、读写吞吐瓶颈问题、数据一致性问题，同时能大幅升高存储老本。此外，实现存储服务化后，对于产品的跨云兼容和多云部署带来不便。 3）计算资源池化因为OLAP利用负载的稳定特点，特地在反对多租户的场景下，通过计算资源池化，依据实时负载进行计算资源对立调度治理，实现资源隔离的同时，又能反对资源共享和实时弹性扩缩。从而进步集群整体利用率。 4）反对混合负载在企业级利用中，OLAP场景能够细分为交互查问和批量计算，前者要求毫秒/秒级响应并反对高并发查问，后者能够承受分钟/小时级提早，但要求计算性能的稳定性和较好的failover机制。自适应反对多场景的混合负载是OLAP产品的外围能力。 5）其余OLAP平台中的计算资源、内存、网络带宽是最贵重的资源，系统资源利用率通常围绕这三个资源进行优化。很多产品开始在计算Serverless化、分布式缓存等方向进行摸索。 点击理解火山引擎ByteHouse更多产品信息

导读有赞数据报表核心为商家提供了丰盛的数据指标，包含30+页面，100+数据报表以及400+不同类型的数据指标，它们帮忙商家更正当、迷信地经营店铺，同时也间接提供剖析决策办法供商家应用。并且，每天在跑的底层工作和波及的数据表曾经达到千级别。 面对如此宏大的数据体系，作为测试如何制订品质保障策略呢？这篇文章将从：1.有赞数据链路 、2.数据层测试、 3.应用层测试、 4.后续布局这四个方面开展。 数仓建设保姆级教程PDF文档一、有赞数据链路1、数据链路介绍首先介绍有赞的数据总体架构图： 自顶向下能够大抵划分为应用服务层、数据网关层、利用存储层、数据仓库，并且作业开发、元数据管理等平台为数据计算、任务调度以及数据查问提供了根底能力。 以上对整体架构做了初步的介绍，对于品质把控来说，最外围的两个局部是：数据仓库以及数据利用局部。因为这两局部属于数据链路中的外围环节，绝对于其余层级而言，日常改变也更为频繁，呈现问题的危险也比拟大。 二、数据层测试1、整体概览首先，针对数据层的品质保障，能够分成三个方面：数据及时性、完整性、准确性。 2、 数据及时性数据及时性，顾名思义就是测试数据须要按时产出。及时性重点关注的三个因素是：定时调度工夫、优先级以及数据deadline。其中工作的优先级决定了它获取数据计算资源的多少，影响了工作执行时长。数据deadline则是数据最晚产出工夫的统一标准，须要严格遵守。 这三要素中，属于“普世规定”且在品质保障阶段须要重点关注的是：数据deadline。那么咱们基于数据deadline，针对及时性的保障策略就可分为两种： 监控离线数据工作是否执行完结。这种形式依赖于有赞作业开发平台的监控告警，若数据工作在deadline工夫点未执行实现，则会有邮件、企微、电话等告警模式，告诉到相应人员。 查看全表条数或者查看分区条数。这种形式依赖接口自动化平台，通过调用dubbo接口，判断接口返回的数据指标是否为0，监控数据是否产出。 其次咱们能够关注失败、重试次数，当工作执行过程中呈现屡次失败、重试的异常情况，能够抛出告警让相干人员感知。这部分的告警是对deadline告警的补充，目前在有赞作业开发平台上也有性能集成。 3、数据完整性数据完整性，顾名思义看数据是不是全，重点评估两点：数据不多、数据不少。 数据不多：个别是查看全表数据、重要枚举值，看数据有没有多余、反复或者数据主键是否惟一。数据不少：个别是查看全表数据、重要字段（比方主键字段、枚举值、日期等），看字段的数值是否为空、为null等。可见数据完整性和业务自身关联度没有那么亲密，更多的是数仓表的通用内容校验。所以从一些根底维度，咱们能够将测试重点拆成表级别、字段级别两个方向。 表级别完整性： 全表维度，通过查看全表的总行数/表大小，若呈现表总行数/总大小不变或降落，阐明表数据可能呈现了问题。分区维度，通过查看当日分区表的数据行数/大小，若和之前分区相比差别太大（偏大或偏小），阐明表数据可能呈现了问题。目前有赞元数据管理平台已集成相干数据视图： 字段级别完整性： 唯一性判断：保障主键或某些字段的唯一性，避免数据反复导致和其余表join之后数据翻倍，导致最终统计数据偏大。比方判断ods层订单表中的订单号是否惟一，编写sql： select count(order_no),count(distinct order_no) from ods.xx_order若两者相等，则阐明order\_no值是表内惟一的；否则阐明order\_no表内不惟一，表数据存在问题。 非空判断：保障重要字段非空，避免空数据造成和表join之后数据失落，导致最终统计数据偏少。比方判断ods层订单表中的订单号是否呈现null，编写sql： select count(*) from ods.xx_order where order_no is null若后果等于0，则阐明order\_no不存在null；若后果大于0，则阐明order\_no存在null值，表数据存在问题。 枚举类型判断：保障枚举字段值都在预期范畴之内，避免业务脏数据，导致最终统计后果呈现脱漏/多余的数据类型。比方判断ods层订单表中的shop\_type字段中所有枚举值是否合乎预期，编写sql： select shop_type from ods.xx_order group by shop_type剖析查问后果是否满足预期，确保不会呈现脱漏/多余的枚举类型。 数据有效性判断：判断数据格式是否满足预期，避免字段的数据格式不正确导致数据统计的谬误以及缺失。常见的有日期格局yyyymmdd。一旦呈现数据完整性问题，对数据品质的影响很大。所以完整性策略更实用于ods层，因为咱们更冀望从源头发现并解决数据不合理问题，及时止损，防止脏数据进入上游之后，数据净化扩充。 另外，咱们看到完整性校验内容逻辑简略，且比拟固定，略微进行简略的形象就能将其模板化。那么作为测试，咱们更偏向于将数据完整性校验做成工具。目前有赞“数据状态工具”曾经落地，上面给出我的一些思路： 针对所有表来说，普世性的规定，比方表主键的唯一性。针对不同类型比方数值、String、枚举、日期格局类型，列举出常见的数据判断规定。给每项规定进行等级划分，比方表的主键不惟一，记为critical。String类型字段的空值比例大于70\%，记为warning。依据表数据是否满足上述这些规定，最终落地一份可视化报告，测试人员可依据报告内容评估数据品质。 4、数据准确性数据准确性，顾名思义数据要“精确”。“精确”这个概念比拟形象，因为咱们很难通过一个强逻辑性的判断，来阐明数据有多准，大部分都存在于理性的认知中。所以准确性测试也是在数据品质保障过程中思维绝对发散的一个方向。 通过总结，咱们能够从字段本身查看、数据横向比照、纵向比照、code review等方面，去把控数据的准确性，这些测试点和业务的关联也比拟亲密。 4.1 本身查看数据本身查看，是指在不和其余数据比拟的前提下，用本身数据来查看精确的状况，属于最根本的一种查看。常见的本身查看包含：查看数值类指标大于0、比值类指标介于0-1范畴。这类根底规定，同数据完整性，也能够联合“数据状态工具”辅助测试。 举个例子，比方针对订单表，领取金额必然是大于等于0，不会呈现正数的状况，编写sql： select count(pay_price) from dw.dws_xx_order where par = 20211025 and pay_price<0若后果为0，阐明领取金额都是大于0，满足预期；否则若count后果大于0，阐明数据存在问题。 4.2 表内横向数据比照表内横向比照能够了解为同一张表内，业务上相关联的两个或多个字段，他们存在肯定的逻辑性关系，那么就能够用来做数据比照。 比方针对订单表，依据理论业务剖析易得：针对任何一家店铺的任意一款商品，都满足订单数 >=下单人数，编写sql： select kdt_id,goods_id,count(order_no),count(distinct buyer_id) from dw.dws_xx_orderwhere par = '20211025'group by kdt_id,goods_idhaving count(order_no)<count(distinct buyer_id)若查问后果不存在记录，则阐明不存在 订单数\<下单人数，反向阐明订单数>=下单人数，则合乎预期；否则若查问后果的记录大于0，则不合乎预期。 ...

 基于维度建模的KimBall架构，将数据仓库划分为4个不同的局部。别离是操作型源零碎、ETL零碎、数据展示和商业智能利用，如下图。 操作型源零碎，指的就是面向用户的各类零碎，如app、网站、ERP、CRM等零碎。这一块就是咱们数据仓库的数据起源，并且这类数据往往有各自的格局和内容，咱们同步过去之后，须要对数据进行荡涤和规范化。 ETL零碎，指的就是获取、转换、加载的(Extract Transformation and Load)过程以及在etl过程中应用到的数据和数据结构这样的一个过程的汇合。也就是蕴含etl脚本，以及etl中的数据，以及对应的构造。 ETL过程中的获取，指的是数据的同步，转换指的是对数据进行转换操作，因为数据同步过去之后，数据的格局可能不是咱们想要的，数据可能有一些缺漏，数据格式可能不统一等，所以这一步，咱们须要对数据进行打消拼写错误、解决畛域抵触、处理错误的数据、解析为规范的格局等。加载，指的就是通过转换的数据，咱们加载到咱们的指标门路或者指标表之中。个别有维度建模和范式建模的表中，kimball架构应用的是维度建模。 数据展示，指的就是用户组织、存储数据，反对开发者对数据进行查问，制作报表等。数据展示中的数据，必须是维度化的、原子的，以业务过程为核心的。保持应用总线结构的企业数据仓库，数据不应该依照个别部门须要的数据来构建。 商业智能利用，指的是开发这基于数据展示，开发出报表或者自主查问，为商业用户提供数据反对，数据分析等。商业智能利用与数据展示的区别，就是一个是针对开发者的，往往是数据库级别的展示，而商业智能利用往往是界面化的是针对普通用户的。

文章原文：直播预报｜离线数仓建设，企业大数据的业务驱动与技术实现 报名链接： https://app.jingsocial.com/mi... 一、课程介绍 随着企业的高速倒退，业务范围一直扩大，企业数据量暴增，面对着海量多源异构数据的存储与解决、数据的疾速剖析及深度开掘等需要，传统数仓所面临的问题越来越显著。 尤其在增量市场越发饱和的事实背景下，如何进步数据处理效率，胜利通过数据赋能业务，成为许多企业须要思考的问题。要想胜利晋升数据生产效率，为下层业务提供牢靠的数据服务及数据产品撑持，离线数仓及计算是要害一环。 所以到底如何围绕离线开发平台这一外围驱动力，保障根底的数据能力，反对经营决策，实现数据商业变现呢？就在本节直播课程一一为您解答 二、课程主题 离线数仓建设，企业大数据的业务驱动与技术实现 三、课程工夫 & 地点 工夫：2022 年 5 月 25 日晚 19:00--20:00（周三） 地点：数栈数据中台交换群，课前 15 分钟群内发送直播链接 四、课程介绍 离线数仓建设背景怎么建设离线数仓（方法论）离线开发施行流程离线数仓经典建设案例五、讲师介绍 潮汐（陶漫佳），袋鼠云数栈资深产品专家 多年以上大数据产品设计教训，负责了离线开发、数据服务等多个产品的规划设计，主导了金融、互联网、保险等多个畛域的数据中台我的项目施行交付，先后参加过中原银行、连连领取、连通领取、酷家乐、中山大学、吉利汽车、光大证券、常熟农商行、尚诚消金等国内大型企业和机构的大数据建设。

数据仓库系列文章(继续更新) 数仓架构发展史数仓建模方法论数仓建模分层实践数仓建模—宽表的设计数仓建模—指标体系数据仓库之拉链表数仓—数据集成数仓—数据集市数仓—商业智能零碎数仓—埋点设计与治理数仓—ID Mapping数仓—OneID数仓—AARRR海盗模型数仓—总线矩阵数仓—数据安全数仓—数据品质数仓—数仓建模和业务建模关注公众号：大数据技术派，回复: 材料，支付1024G材料。凡事无规矩不立，所以你会常常看到各种各样的标准，面对标准须要恪守，然而不能自觉，例如咱们开发人员最常看到的就是《Mysql 开发标准》、《Java 编程手册》、《Java 开发标准》 之类的货色，这些货色的出发点有三方面： 进步性能防止谬误方便管理其实很多标准都是这三方都相干的，然而咱们明天介绍的数仓标准次要是为了防止谬误和方便管理，其实方便管理这个话题咱们后面说了好屡次了，这里你能够参考后面的文章数仓建模—分层建设实践、数仓建模—数据集市 这些在肯定水平上来说都是为了方便管理。 数据档次的划分具体仓库的分层状况须要联合业务场景、数据场景、零碎场景进行综合思考，上面咱们看一下常见的分层 ODS：Operational Data Store，操作数据层，在结构上其与源零碎的增量或者全量数据根本保持一致。它相当于一个数据筹备区，同时又承当着根底数据的记录以及历史变动。其次要作用是把根底数据引入到数仓。CDM：Common Data Model，公共维度模型层，又细分为DWD和DWS。它的次要作用是实现数据加工与整合、建设一致性的维度、构建可复用的面向剖析和统计的明细事实表以及汇总公共粒度的指标。 DWD：Data Warehouse Detail，明细数据层。DWS：Data Warehouse Summary，汇总数据层。ADS：Application Data Service，利用数据层。数据分类架构 该数据分类架构在ODS层分为三局部：数据筹备区、离线数据和准实时数据区。在进入到CDM层后，由以下几局部组成： 公共维度层：基于维度建模理念思维，建设整个企业的一致性维度。明细粒度事实层：以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。您能够联合企业的数据应用特点，将明细事实表的某些重要维度属性字段做适当的冗余，即宽表化解决。公共汇总粒度事实层：以剖析的主题对象为建模驱动，基于下层的利用和产品的指标需要，构建公共粒度的汇总指标事实表，以宽表化伎俩来物理化模型。数据划分及命名约定请依据业务划分数据并约定命名，倡议针对业务名称联合数据档次约定相干命名的英文缩写，这样能够给后续数据开发过程中，对我的项目空间、表、字段等命名做为重要参照。 #### 数据划分 按业务划分：命名时按次要的业务划分，以领导物理模型的划分准则、命名准则及应用的ODS project。按数据域划分：命名时依照CDM层的数据进行数据域划分，以便无效地对数据进行治理，以及领导数据表的命名。按业务过程划分：当一个数据域由多个业务过程组成时，命名时能够按业务流程划分。业务过程是从数据分析角度看客观存在的或者形象的业务行为动作。命名约定如果公司业务线比拟多，咱们能够依照我的项目的模式进行划分，如果不是间接依照档次划分，project\_ods、project\_dwd ODS层命名标准表命名标准 表命名规定：{档次}{源零碎表名}{工夫单位与增全量},i示意增量，f示意全量 ,d 示意天, h示意小时 增量数据：{project_name}.s{源零碎表名}_di。全量数据：{project_name}.s{源零碎表名}_df。ODS ETL过程的长期表：{project_name}.tmp{长期表所在过程的输出表}{从0开始的序号}。按小时同步的增量表：{project_name}.s{源零碎表名}_hi。按小时同步的全量表：{project_name}.s{源零碎表名}_hf。当不同源零碎同步到同一个Project下的表命名抵触时，您须要给同步较晚的表名加上源零碎的dbname以解决抵触。字段命名标准 字段默认应用源零碎的字段名。字段名与关键字抵触时，在源字段名后加上\_col，即源字段名\_col。同步工作命名标准 工作名：倡议和表名保持一致。dim 层命名标准命名规定：{project_name}.dim{业务/pub}{维度定义}[_{自定义命名标签}]，其中的pub与具体业务无关，各个业务部都能够共用，例如工夫维度。 公共区域维表dim_pub_area公司社群板块的群成员全量表dim_group_memberdwd 层命名标准通常须要遵循的命名标准为：dwd_{业务板块/pub}_{数据域缩写}_{业务过程缩写}[_{自定义表命名标签缩写}] _{单分区增量全量标识}，pub示意数据包含多个业务板块的数据。 单分区增量全量标识通常为：i示意增量，f示意全量。例如： dwd_group_create_inf_df（公司社群创立事实表，日刷新全量）及dwd_group_chat_di（公司社群发消息事实表，日刷新增量）。 dws 层命名标准公共汇总事实表命名标准：dws_{业务板块缩写/pub}_{数据域缩写}_{数据粒度缩写}[_{自定义表命名标签缩写}]_{统计工夫周期范畴缩写}。 对于统计理论周期范畴缩写，缺省状况下，离线计算应该包含最近一天（_1d），最近N天（_nd）和历史截至当天（_td）三个表。对于小时表（无论是天刷新还是小时刷新），都用_hh 来示意。对于分钟表（无论是天刷新还是小时刷新），都用_mm来示意。举例如下： dws_group_patient_join_1d（公司社群患者加群一日汇总事实表）dws_group_patient_exit_td（公司社群患者退群截至当日汇总表）档次调用约定应用层应优先调用公共层数据，必须存在中间层数据，不容许应用层跨过中间层从ODS层反复加工数据。一方面，中间层人员应该踊跃理解应用层数据的建设需要，将专用的数据积淀到公共层，为其余人员提供数据服务；另一方面，应用层人员也应踊跃配合中间层人员进行继续的数据公共建设的革新。必须避免出现适度的援用ODS层、不合理的数据复制以及子集合冗余。 ODS层数据不能被应用层工作援用，中间层不能有积淀的ODS层数据，必须通过CDM层的视图拜访。CDM层视图必须应用调度程序进行封装，放弃视图的可维护性与可管理性。CDM层工作的深度不宜过大（倡议不超过10层）。原则上一个计算刷新工作只容许一个输出表。如果多个工作刷新输入一个表（不同工作插入不同的分区），DataWorks上须要建设一个依赖多个刷新工作的虚构工作，通常上游应该依赖此虚构工作。CDM汇总层应优先调用CDM明细层。在调用可累加类指标计算时，CDM汇总层尽量优先调用曾经产出的粗粒度汇总层，以防止大量汇总间接从海量的明细数据层计算。CDM明细层累计快照事实表优先调用CDM事务型事实表，以保持数据的一致性产出。防止应用层适度援用和依赖CDM层明细数据，须要针对性地建设好CDM公共汇总层。数据类型标准ODS层的数据类型应基于源零碎数据类型转换。例如，源数据为MySQL时的转换规则如下。 MySQL数据类型Hive数据类型 MySQL数据类型Hive 数据类型TINYINTTINYINTSMALLINT/MEDIUMINTSMALLINTINTEGERINTBIGINTBIGINTFLOATFLOATDOUBLEDOUBLEDECIMALDECIMALCHAR/VARCHARVARCHARLONGTEXT/TEXTSTRINGDATE/TIMESTAMP/TIME/YEARSTRINGDATETIMEDATETIMECDM数据公共层如果是援用ODS层数据，则默认应用ODS层字段的数据类型。其衍生加工数据字段按以下规范执行： 金额类及其它小数点数据应用DOUBLE类型。字符类数据应用STRING类型。ID类和整形数值应用BIGINT类型。工夫类型数据应用STRING类型（如果有非凡的格局要求，能够选择性应用DATETIME类型）。状态应用STRING类型。公共字段定义标准数据统计日期的分区字段按以下规范： 按天分区：ds(YYYYMMDD)。按小时分区：hh(00-23)。按分钟：mi (00-59)。is_{业务}：示意布尔型数据字段。以Y和N示意，不容许呈现空值域。原则上不须要冗余分区字段。数据冗余一个表做宽表冗余维度属性时，应该遵循以下倡议准则： 冗余字段与表中其它字段高频率（大于3个上游利用SQL）同时拜访。冗余字段的引入不应造成其自身的刷新实现工夫产生过多后延。公共层数据不容许字段反复率大于60%的雷同粒度数据表冗余，能够抉择在原表根底上拓宽或者在上游利用中通过JOIN形式实现。数据拆分数据的程度和垂直拆分是依照拜访热度散布和数据表非空数据值、零数据值在行列二维空间上散布状况进行划分的。 在物理上划分外围模型和扩大模型，将其字段进行垂直划分。将拜访相关度较高的列在一个表存储，将拜访相关度较低的字段离开存储。将常常用到的Where条件按记录行进行程度切分或者冗余。程度切分能够思考二级分区伎俩，以防止多余的数据复制与冗余。将呈现大量空值和零值的统计汇总表，根据其空值和零值散布情况能够做适当的程度和垂直切分，以缩小存储和上游的扫描数据量。空值解决准则汇总类指标的空值：空值解决，填充为零维度属性值为空：在汇总到对应维度上时，对于无奈对应的统计事实，记录行会填充为-99（未知），对应维表会呈现一条-99（未知）的记录。设计准则一致性维度标准 公共层的维度表中雷同维度属性在不同物理表中的字段名称、数据类型、数据内容必须保持一致。除了以下状况： 在不同的理论物理表中，如果因为维度角色的差别，须要应用其余的名称，其余名称也必须是标准的维度属性的别名。例如，定义一个规范的会员ID时，如果在一个表中，别离要示意买家ID，卖家ID，那么设计规范阶段就事后对会员ID别离定义买家ID和卖家ID。如果因为历史起因，在临时不统一的状况下，必须在标准的维度定义一个规范维度属性，不同的物理名也必须是来自规范维度属性的别名。维度的组合与拆分 组合准则 将维度所形容业务相关性强的字段在一个物理维表实现。相关性强是指常常须要一起查问或进行报表展示、两个维度属性间是否存在人造的关系等。例如，商品根本属性和所属品牌。无相关性的维度能够适当思考杂项维度（例如交易），能够构建一个交易杂项维度收集交易的非凡标记属性、业务分类等信息。也能够将杂项维度进化在事实表中解决，不过容易造成事实表绝对宏大，加工解决较为简单。所谓的行为维度是通过汇总计算的指标，在上游的利用应用时将其当维度解决。如果有须要，度量指标能够作为行为维度冗余到维度表中。拆分与冗余 对于维度属性过多，波及源较多的维度表（例如会员表），能够做适当拆分： 拆分为外围表和扩大表。外围表绝对字段较少，刷新产出工夫较早，优先应用。扩大表字段较多，且能够冗余外围表局部字段，刷新产出工夫较晚，适宜数据分析人员应用。依据维度属性的业务不相关性，将相关度不大的维度属性拆分为多个物理表存储。数据记录数较大的维度表（例如商品表），能够适当冗余一些子集合，以缩小上游扫描数据量： 能够依据当天是否有行为，产出一个有沉闷行为的相干维表，以缩小利用的数据扫描量。可依据所属业务扫描数据范畴大小的不同，进行适当子集合冗余。数据存储及生命周期治理标准CDM公共维度层的表的类型为维度表，存储形式为按天分区。 模型设计者依据本身业务需要设置表的生命周期治理。您可根据3个月内的最大须要拜访的跨度设置保留策略，具体计算形式如下： 当3个月内的最大拜访跨度小于或等于4地利，倡议将保留天数设为7天。当3个月内的最大拜访跨度小于或等于12地利，倡议将保留天数设为15天。当3个月内的最大拜访跨度小于或等于30地利， 倡议将保留天数设为33天。当3个月内的最大拜访跨度小于或等于90地利，倡议将保留天数设为93天。当3个月内的最大拜访跨度小于或等于180地利， 倡议将保留天数设为183天。当3个月内的最大拜访跨度小于或等于365地利，倡议将保留天数设为368天总结其实标准这个货色很重要，然而有时候它的设计不那么可续，例如咱们公司的天分区字段是ds而不是pt,然而这个货色只有大家认可就行，然而不能因为不认可就不恪守。 ...

 数据仓库（数仓）与大数据区别，数据仓库（数仓）与数据库的区别，大数据与传统数据库的区别等等，这篇文章带你理解。 咱们这里先来说说明天要比照的三个主体，数据仓库、大数据、数据库，在具体阐明之前，咱们先来说说这三个百度百科下面的定义。 数据仓库：为企业所有级别的决策制定过程，提供所有类型数据反对的策略(数据)汇合。 大数据：所波及的材料量规模微小到无奈透过支流软件工具，在正当工夫内达到撷取、治理、解决、并整顿成为帮忙企业经营决策更踊跃目标的资讯。 传统数据库：一个长期存储在计算机内的、有组织的、可共享的、对立治理的大量数据的汇合。 其实从三个定义，咱们如同区别不大。 数据库指的是数据的汇合，数据仓库也是一个数据汇合，大数据也是一个解决和存储数据的中央。 然而不同的是，在于利用场景，和构建的技术原理不一样。 传统数据库是存储依据范式建模的关系型数据，次要用于OLTP（on-line transaction processing）翻译为联机事务处理的软件。大数据是依据map redurce范式构建的出局解决，存储的软件，次要用于OLAP是做剖析解决。大数据和传统数据库，还有一个更大的区别在于，解决的数据量以及计算量的大小，当传统数据库，无奈在人能够承受的短时间内计算出后果，那这个数据就叫大数据，须要应用到大数据技术解决。而数据仓库实质上是一种数据的解决形式，而不是一种根底软件，它能够依赖于传统数据库，也能够依赖大数据技术去构建。 这个扩大一下数据仓库与传统数据库利用的区别，有上面几点： 用处:传统数据库次要用于OLTP（on-line transaction processing）翻译为联机事务处理，即即时的零碎交互，数据仓库次要用于OLAP（On-Line Analytical Processing）翻译为联机剖析解决，从字面上来看OLTP是做事务处理，OLAP是做剖析解决。从对数据库操作来看，OLTP次要是对数据的增删改，OLAP是对数据的查问。建模:传统数据库次要应用范式建模，数据仓库能够依据须要采纳范式建模或者当初互联网广泛应用的星形模型等。应用技术:个别应用mysql等关系型数据库，数据仓库目前互联网行业更多的是应用hadoop等大数据技术，也有应用mysql等，能够依据理论状况搭建。存储的数据：传统数据库只存储以后状态的数据，数据仓库须要存储历史状态的数据，用户对历史数据的回溯剖析。参考文章：数据仓库(2)数仓、大数据与传统数据库的区别

在生活中，规范与咱们非亲非故，吃的食品须要满足国家标准能力食用，汽车排放达标才可能上路行驶，电脑接口得满足对立的规范才可能与外设对接等等。而在数据的世界，数据规范也等同重要。咱们冀望将数据规范真正利用到实际中去，帮忙客户解决资产化有余、数据品质难以晋升、数据开发效率低等问题，于是网易开始了数据规范的建设。 本文将基于咱们对数据规范的了解，论述规范的建设并根据规范的建设内容和流程来设计的规范治理产品的介绍以及规范在数据治理过程中的具体实际，心愿与大家碰撞出新的意识。 1.数据规范是什么？在理论的工作生产中，咱们个别会参照国家标准、中央规范、行业标准等来进行具体的流动，来确保咱们生成过程合乎监管要求、便于上下游协同等，于是咱们会见到如下的规范领导文件： 同样，数据规范也会以文件的模式存在，在除了国标、行标定义的规范外，企业外部为了便于各部门采取同样的数据建设标准，通常会应用文件来定义数据规范，以供各部门达成对立的共识。 尽管文件是规范的一种体现模式，但文件是非结构化的，在理论利用中，咱们只有了解、提取文件里的内容，将规范利用于产品设计及流程流动当中去，规范能力起到真正的标准束缚作用。 依据信通院公布的《数据规范治理实际白皮书》定义：数据规范（Data Standards）是指保障数据的内外部应用和替换的一致性和准确性的规范性束缚。 毫无疑问，这是正确的。但咱们还须要将规范践行，以建设数据中台为例，咱们晓得数据中台强调的是资源整合，在数据层面就是整合多源异构零碎中扩散在各个孤岛的数据，造成对立的数据服务能力，这是一项艰巨的工作， 很难通过相互约定以及默认信赖相干方来保障数据的价值挖掘，造成真正的数据资产。 于是，基于此点将数据规范进行裁减，一是对治理范畴的裁减，从广义的数据规范（指对根底数据自身的规范性束缚，如数据格式、类型、值域等）裁减到整个数据中台层面的规范（蕴含治理各阶段的规范性束缚）；二是对管理手段的裁减，数据规范不再是指一系列的数据标准化文档，而是一套由标准要求、流程制度、技术工具独特组成的体系，通过这套体系实现规范的布局、制订、公布、执行、查看、保护等行为，来实现数据的标准化以及规范的积淀。 2.数据规范的价值在说价值之前，咱们先聊聊让咱们头疼的问题。人人都在议论数据规范，但数据规范真的被利用起来了么，咱们拿着一堆标准文件，冀望企业外部宣贯大家要依照这个规范来，但执行的后果如何？ 数据集成多源异构数据时，数仓开发人员真的能疾速了解这些数据的理论业务含意么？如果了解老本很高，开发人员可能就会呈现意识偏差。 终于数据集成进来了，能够开始进行数仓建设了，如何保障每一层的数据都是合乎品质要求的，靠开发的集体素质么？比方咱们个别在dwd层做数据标准化，那么不同主题域的由不同的负责人进行开发，怎么保障标准化的后果仿佛满足标准的？dws的数据可信度还能保障么？还能被叫做公共模型层么？ 再后，数仓开发实现后须要对外开放，咱们其实开发的不光是其数据，还须要开发它的元数据信息，帮忙数据应用方疾速的找到须要的数据，如果只是把数据堆在一起，只有研发人员本人晓得这个数据是什么、在哪、怎么应用，那是不可能被称为数据资产的。 还有很多问题，这里只列举了些典型。当然这些问题，是能够解决的，解决的形式就是数据规范。解决的的过程可能须要的工夫比拟长，因为规范从治理到落地执行推动并不是一件容易的事，须要从思维上进行转变，但咱们总要正确的做事。 上面列举了一些价值，但在理论的利用过程可能发现更多的可能性。 价值一：建设对立的数据视图 建设通用的元模型标准，反对用户自定义扩大，对多源异构数据表进行信息形象提取，造成对立的元数据层。所有的数据开发实现后公布到数据规范保护的对立的数据目录，通过不同维度的数据目录进行多维筛选，满足各类用户的检索须要，达到资产的可管、可用、可查的指标。 价值二：建设对立的数据认知 首先利用规范实现对多源异构数据的标准化形容，尽管数据在不同零碎中的称说千奇百怪，但只有进入咱们的平台都将赋予对立的名姓，使得管理方、开发方、应用方建设对立认知。对于仓表面将数据规范与表字段进行关联，旨在对立含意以及告知将来数据处理的方向；对于仓内表，模型设计之初就须要援用规范，咱们晓得将数据项进行组合即可失去模型，数据元即为规范数据项池，模型设计时仅需从池子里选取须要的字段进行组合即可组装成想要的模型。 价值三：建设品质稽核体系 现有的品质稽核个别是由用户依据业务需要手动设置，不同人员的认知偏差将导致数据品质难以管制。数据规范通过数据元的示意类属性，依据其格局、类型等要求主动生成品质稽核规定，当某张表的字段绑定了数据元时，即可依据数据元的品质信息要求主动生成稽核工作，且保障了源头定义的一致性。 价值四：面向未来的数据治理咱们晓得，工具的终极目标都是为了降本提效。效率晋升是要靠流程标准的，流程足够标准，在某种程度上可实现流程主动流转。因而，将来的数据治理趋势该当侧重于流程自动化以及阶段智能化，而这两点都须要数据规范的撑持。 阶段智能化冀望在流程各阶段提供智能辨认能力，比方字段的实在含意（挂载数据规范）、资源所属分类、字段枚举值等，缩小人工参加。从短期来看，用户从解决者变为审核者，从长期来看，用户干涉的行为反哺辨认模型，减少辨认准确性，可升高人力老本； 流程自动化依赖阶段智能化以及人工干预的后果，将各阶段进行串联，上下游尽可能完满对接，当上游阶段达到上游准入条件时，可主动触发流程运作，当然该过程也须要对立上下游语言（即数据规范），在理论实际中，可通过试运行进行验证。 规范的价值还有很多，限于篇幅不过多赘述，大家能够一直发现规范的利用场景。说完规范的价值了，那么咱们该如何建设数据规范呢？ 3.如何建设数据规范？在晚期的业务倒退过程中，企业为了解决当下的业务问题，各业务条线已建设本人个性化的业务零碎，在建设的过程中为了保障外部通信，或多或少都已存在部分的数据规范。因而，建设对立的数据规范很大水平上是对部分规范进行收口，一般来说，可收集现行的国家标准或行业标准，将现有规范与国标或行标进行对标，此过程一是能够满足监管须要，二是可大大节俭规范制订的人力；另一方面则是思考所在行业的特点并联合企业的理论须要，逐渐构建规范进行推广。 具体可参考数据规范的建设的6个步骤，别离是：数据规范布局、数据规范制订、数据规范公布、数据规范执行、数据规范查看、数据规范保护。 3.1 数据规范布局规范的布局首先需对企业业务和数据进行调研和剖析，结合实际的数据规范需要，明确数据规范的范畴。再依据理论状况的不同，逐步推进。 3.1.1 收集现行标准 可从业务流程登程，圈定参加业务流程的业务实体，通用的业务实体如人，可收集对应现行的国家标准，如对于公民身份证号码该当遵循强制性规范GB 11643 ,对于性别的代码该当参考推荐性规范GB/T 2261.1的规定，行政区划该当参考GB/T 2260的规定等。具备行业属性的业务实体如商业银行担保物，可参考JR/T 0170.1以及JR/T 0170.2的规定等。 3.1.2 从部分规范到全局规范 对于企业各业务条线（部门）已建设的部分规范且不适用于援用现行标准或不存在于现行标准的须要进行收集，对同一业务含意但不同规范形容的项进行评审，在企业外部达成统一，失去最终对立的数据规范。 此过程可蕴含根底类数据规范对立、参照类规范对立、指标类数据规范对立。 3.1.3 发现更多数据规范 发现更多规范次要利用于以下状况，一是部分规范不明确也无现行标准实用时，二是企业各业务条线垂直零碎较多，数据体量较大，不足足够的人力及技术手段，但从总体策略的角度冀望制订规范时。应答这种状况可依赖数据规范治理平台（第3节将具体介绍）进行规范的辨认及拾取。 规范的辨认及拾取个别存在两种形式： 第一种有明确制订某项规范的需要，则通过定义数据元概念（第2.2节具体介绍 ），确定该项数据规范形容的对象类及个性，再通过关键词扫描及智能辨认技术，扫描存量数据，辨认与该数据元概念统一的数据项汇合，对该汇合进行探查获取字段类型散布、长度范畴、值域散布等，从而构建数据元的示意形容，造成残缺的数据规范。 第二种是暂无明确制订某项规范的需要，去摸索是否须要对某些数据项制订规范。系统对存量数据进行扫描，遍历所抉择的数据源类型中的所有字段名，提取达到反复阈值的字段名，对其制订数据规范。 3.2 数据规范制订3.2.1 元数据规范 元数据规范次要标准了平台对于各类元数据及资产的示意形式和组织形式。 3.2.1.1 元模型的制订 数据中台是企业数字化转型的根底和中枢系统，将企业全域海量、多源、异构的数据整合资产化，但多源异构数据差异化显著，如何保证数据管理者、使用者、开发者对数据具备对立的认知是亟待解决的问题。良好元模型设计，宗旨在于屏蔽底层多源异构零碎的复杂度，用对立的语言来形容来自不同利用零碎、存储在不同品种数据库的各类数据。 咱们晓得元数据是形容数据的数据，而元模型则是对于模型的数据形容，依据OMG（对象治理组织）提出的四层元模型构造，能够清晰的表白出四层的关系： 能够看出，元数据是个绝对的概念，元模型即为元数据的元数据，为了更不便大家了解，这里提供一个实例解释： 元模型不仅限于表元模型、字段元模型，还蕴含指标元模型、标签元模型等，尽管所形容的元数据品种不同，但治理办法上都是统一的，在实际的过程中，可全副纳入数据规范进行治理，也可在对应的子系统中各自保护。 3.2.1.2 命名及编码规定制订 命名规定次要用于标准表名、字段名、工作名称、指标名称、标签名称等，指定某个名称该当应用哪些命名因素组成以及以何种排列程序组成。编码规定次要用户资产编码、数据元外部标识符、标签编码、指标编码等，指定某个编码该当应用何种编码方式。 因而须要指定命名及编码因素范畴，一是选取平台已存在的枚举值，如数据分层、主题域或其余已存在的分类枚举；二是用户可自定义常量、自定义枚举值；三是平台提供的可变位序列。通过上述的命名因素，进行排序组合，造成命名及编码规定。 以数据元为例子： 第一种编码方式能够为“指定标识（常量）+7位自增序列”，能够编码为DE0000001; 第二种编码方式能够依照所在分类进行对立编码，相似于“一级分类编码+二级分类编码+三位自增序列”，比方公民身份号码数据元归属分了为”人员类（01）/信息标识类（001）“，那么能够编码为01001001，其余以此类推。 ...

简介：分层架构很容易在各种书籍和文档中去了解，然而把建模办法和分层架构放在一起就会呈现很多困惑了。接下来，我会从数据研发与建模的角度，演进一下分层架构的设计起因与档次的意义。 分层架构很容易在各种书籍和文档中去了解，然而把建模办法和分层架构放在一起就会呈现很多困惑了。 一、分层的演进之所以会有分层架构，最次要的起因还是要把简单简短的数据吹流程分拆成一些有明确目的意义的档次，这样简单就被拆解为一些绝对简略小的模块。那么分层架构中各层都是怎么产生的呢，咱们能够简化看一下。 第一个数据加工工作 我要进行第一个数据加工工作，所有平台档次都没有，我只有一个MaxCompute。我该怎么做呢？ 第一步，我须要本人做一下数据集成，把源零碎的数据集成到MaxCompute。 第二步，我须要把增量合并全量生成ODS层，这样我就失去了与业务零碎一样的表构造和全量的数据。 第三步，因为我对业务零碎的数据表关联关系有理解，所以，我能够依据业务需要应用ODS的全量表做表关联，加工出我想要的数据后果。 第一个数据利用 如果我不只是做一个业务需要，我是有很多业务需要，这样我就造成了我的第一个数据利用。所以，我会集成更多的数据，做更多的数据合并全量的工作，并且我的全量ODS的表能够在多个业务场景复用。 然而试想一下，如果不是一个人在开发，那么团队外部是不是要协调一下，对工作进行一下分工。做集成的和做合并的是不是能够分给一部分人，而后把前面业务需要开发再分给另外一部分人。这样就防止了反复工作，和便于工作的专业性。 于是就能够拆分进去上图中的第一个方块“集成”（STG）和第二个方块 “全量”（ODS），这部分是纯技术性的工作，还没有波及到业务需要。对于理论业务需要计算局部，就是咱们的应用层集市层（ADM）。 第二个数据利用 随着第二个数据利用的呈现，各自做集成合并曾经是十分不适宜的做法了，于是就有个独立的STG和ODS层。 很多时候，做完ODS就能够做业务数据加工了。并且这种状况从数据处理技术倒退之初，数据仓库概念提出之前就存在了，当初仍然很广泛。集市各自依赖ODS会遇到的多源加工指标不统一的问题逐步遭人诟病，而造成指标不统一的次要起因反复加工。不同的人对同一业务的了解都很难保障一致性，更何况不同的部门的利用。对于这个问题，能够在各个大型企业晚期的数据场景都会遇到，所以，在阿里对外宣传大数据平台的时候也会提到这个晚期各个业务部门数据口径不统一的问题。这个问题在ODS的层面无奈解决，必须要独立出一个团队来做公共的这部分数据，让各个利用集市去做各自独立的局部，这也是公共层（CDM）的由来。 二、分层与建模通过下面的内容，咱们终于晓得了数据加工过程为什么要分层。那么数据建模应该如何来做呢？因为在数据仓库畛域，在数据建模始终有两种争锋绝对的观点，就是范式建模还是维度建模。咱们在目前大数据这个场景，个别就只提一种办法了，就是维度建模。 维度建模的经典办法与教程中没有中间层的概念，也没有主题域划分的概念。维度建模个别用在数据集市场景，也就是ODS+ADM场景，各个业务通过一致性维度实现企业级的数据一致性。在传统的被IOE统治的时代，Teradata、IBM、Oracle都有基于关系型数据库（包含MPP数据库），在某些重要的行业，例如金融这些企业都会构建大型的企业级的维度模型来给集市提供公共数据服务，这就是公共层。因为范式模型导致实体都比拟窄，跟理论的剖析型业务需要（维度模型）差别太大，所以须要做一层中间层（绝对范式模型更宽的表，这也是宽表说法的由来）来做为利用集市层共性加工工作的档次，这就是当初咱们在架构中提到的ODS+CDM+ADM的架构。 那么问题就在这里进去了，咱们全副应用维度模型建模，如何应用范式模型的架构与概念。这也是咱们在分层架构设计中目前最难以讲清楚的问题，也是咱们理论在我的项目外面做的很顺当的起因：不足实践与实际撑持。 维度模型的构建是以理论业务需要为导向，模型是一直的需要累积进去的，适应疾速的业务变动。而且维度模型不是一个倡议一开始就进行企业级的思考设计的模型设计办法，是由部分业务逐步扩张构建的。所以，我认为维度模型的架构不太合适一开始做太重的太业务化公共层。反而应该强调在公共层构建共性加工的汇合，去协调同步多个利用集市的计算，从而实现全局性的一致性维度和一致性事实。因为维度建模的建设也不是简略欲速不达的，也是须要屡次和多种数据处理当前能力最终变成合乎业务需要的后果。多个不同的利用集市有大量的共性的加工需要，这些需要就是咱们公共层的收集的建模需要。把这些共性需要在公共层应用维度建模的办法实现才是建设公共层的正当办法，而不是越俎代庖的去建设面向具体某个业务场景的指标标签（就是尽管理论是做了指标和标签的计算，然而我只是一个两头加工过程）。 接下来，咱们持续利用下面解说分层的办法来解说公共层与集市层的关系。 第一个利用 随着第一个利用呈现，就能够基于局部的需要构建第一个公共层了。共性加工需要在一个中型的利用集市就很显著了。一、数据荡涤。一个表的数据荡涤后，会有多个数据加工工作都会应用这个荡涤后的表，这就是最简略的共性加工的了解。二、多表关联。多张表的关联也是多个数据加工工作中能够提炼进去的，一次把须要关联应用的字段都关联合并到一张新表，后续的工作就能够间接用这个新表。三、共性汇总。对于数据从明细到汇总的group by，对立依据多个罕用条件进行汇总，生成一张新表，后续的工作就能够间接用这个新表。一致性维度是维度建模中最要害的局部，间接影响到各个利用集市的数据规范与一致性问题，是公共层最重要的工作。 第二个利用 随着利用的减少，需要也在一直的裁减，长期层和镜像层集成的表更多了。在公共层的明细和汇总也呈现了多个利用集市都在共用的数据需要，会扩大补充到公共层。并且随着工夫的变动，公共层的逻辑的正确性和公共性也须要在多个利用进入后整体思考。 公共层与利用关系 通过下面两步演进，咱们曾经看到了公共层与应用层的关系了，是一体的。并不是各做各的，而是一件事件从专业化分工上做了切分。公共层与应用层只有一个独特指标，就是为满足业务需要而做数据加工。不同偏重的是应用层只须要关注本人部门的最终业务指标，公共层则须要从企业级的全局一致性、资源经济性上全盘考虑。 公共层与应用层的关系就是后勤部队与后方作战部队的关系，一个负责根底的资料筹备工作，一个负责利用这些输入投入到实在战场。公共层是高效的数据复用和综合更低的资源代价，应用层则就是理论的业务需要。所以，最终的业务模型在应用层才有残缺的针对性业务场景，在公共层是模型是多种场景业务需要的一个复合，代表了平台最根底和最通用的模型。 从档次上来说，公共层向下是一块整体，负责跟上游多个交易型业务零碎对接，对利用集市屏蔽了上游变动带来的影响，使得应用层能只关注于利用公共层的模型解决本人的业务需要。 原文链接本文为阿里云原创内容，未经容许不得转载。

写在后面数据仓库的个性之一是集成，即首先把未通过加工解决的、不同起源的、不同模式的数据同步到ODS层，个别状况下，这些ODS层数据包含日志数据和业务DB数据。对于业务DB数据而言(比方存储在MySQL中)，将数据采集并导入到数仓中(通常是Hive或者MaxCompute)是十分重要的一个环节。 那么，该如何将业务DB数据高效精确地同步到数仓中呢？个别企业会应用两种计划：直连同步与实时增量同步(数据库日志解析)。其中直连同步的基本思路是直连数据库进行SELECT，而后将查问的数据存储到本地文件作为两头存储，最初把文件Load到数仓中。这种形式十分的简略不便，然而随着业务的倒退，会遇到一些瓶颈，具体见下文剖析。 为了解决这些问题，个别会应用实时增量的形式进行数据同步，比方DataWorks提供的一键TT接入性能，其基本原理是CDC (Change Data Capture) + Merge，即实时Binlog采集 + 离线解决Binlog还原业务数据这样一套解决方案。本文次要包含以下内容，心愿对你有所帮忙 数据同步的形式一键TT接入的流程与步骤基于Canal+Flink模仿实现TT数据接入 数据同步的形式直连同步直连同步是指通过定义好的标准接口API和基于动态链接库的形式间接连贯业务库，比方ODBC/JDBC等规定了对立的标准接口，不同的数据库基于这套规范提供标准的驱动，从而反对完全相同的函数调用和SQL实现。比方常常应用的Sqoop就是采取这种形式进行批量数据同步的。 直连同步的形式配置非常简略，很容易上手操作，比拟适宜操作型业务零碎的数据同步，然而会存在以下问题： 数据同步工夫：随着业务规模的增长，数据同步破费的工夫会越来越长，无奈满足上游数仓生产的工夫要求。性能瓶颈：直连数据库查问数据，对数据库影响十分大，容易造成慢查问，如果业务库没有采取主备策略，则会影响业务线上的失常服务，如果采取了主备策略，尽管能够防止对业务零碎的性能影响，但当数据量较大时，性能仍然会很差。 日志解析所谓日志解析，即解析数据库的变更日志，比方MySQL的Binlog日志，Oracle的归档日志文件。通过读取这些日志信息，收集变动的数据并将其解析到指标存储中即可实现数据的实时同步。这种读操作是在操作系统层面实现的，不须要通过数据库，因而不会给源数据库带来性能上的瓶颈。 数据库日志解析的同步形式能够实现实时与准实时的同步，提早能够管制在毫秒级别的，其最大的劣势就是性能好、效率高，不会对源数据库造成影响，目前，从业务零碎到数据仓库中的实时增量同步，宽泛采取这种形式，比方一键TT接入。当然，这种形式也会存在一些问题，比方批量补数时造成大量数据更新，日志解析会解决较慢，造成数据提早。除此之外，这种形式比较复杂，投入也较大，因为须要一个实时的抽取零碎去抽取并解析日志，下文会对此进行具体解释。 一键TT接入的根本步骤根本流程根本流程如下，首先是将数据的变更日志推送到DataHub/TimeTunnel(TT,一种基于生产者、消费者和Topic音讯标识的消息中间件，将音讯数据长久化到HBase,其底层基于DataHub，类比Kakfa)，而后将表全量同步，且仅全量同步一次，接着将TT的数据订阅生产到ODPS的TTSource表，并将TTSource表合并到增量表中，最初将增量表与全量表进行Merge失去最新的全量表。当前的同步流程仅执行增量表的数据装载以及增量表与全量表的Merge合并，合并的形式是应用全外连贯(full outer join)+数据笼罩(insert overwrite)的形式，比方日调度，即是将当天的增量数据和前一天的全量数据做全外连贯，从新装载获取最新的一份全量数据。 步骤解释以WDK_MEMBER_PRO_APP.member_round_detail为例 Step1. BPMS审批Step2.创立TT表这一步会在TT(类比Kafka)中生成名为wdk_member_pro_app_member_round_detail的Topic，用于存储Binlog变更日志（比方INSERT、UPDATE数据），该Topic的个别命名格局是：${TDDL APP NAME}_${源表名}。值得注意的是，因为一行数据记录的变更日志是有严格程序的，而DataHub/TimeTunnel是分区有序的，所以要保障同一个key的数据进入到Topic的同一个分区，这样能力保障有序，这也是为什么要指定惟一主键的起因。而后创立TT Source表，该表名为：s_tt_wdk_member_pro_app_member_round_detail_tt4，表名的个别格局是：s_tt_${TDDL APP NAME}_${源表名}_tt4，该表次要用于订阅DataHub/TimeTunnel中的Topic，将DataHub的数据抽取到ODPS中存储(行将曾经采集到TT的数据存储到ODPS上)。该表的content字段存储了变更日志数据，包含一部分的元数据信息和理论的日志数据，对于元数据信息，具体如下： dbsync_ts: 同步机器的工夫戳（ms）+自增序列dbsync_db_name: 物理分库dbsync_table_name: 物理分表dbsync_modify_time: Binlog变更日志工夫，即数据长久化到DB的工夫dbsync_operation: 数据的操作类型，比方insert、updatedbsync_region_id: 标识本条数据的地区信息，实用于团体单元化场景。 Step3.创立增量表在ODPS中创立一张名为s_tt_member_round_detail_delta的表，该表的个别命名格局是：${指标表名}_delta。该表用于存储增量的数据，比方按天增量抽取，那么表中的数据就是当天的增量数据。次要解决逻辑是读取TT Source表的当天分区数据，将其写入到该增量表中。详见TTMerge节点工作。 Step4.创立TTMerge节点该节点的工作名称为tt_${指标表名}_delta，次要作用是向Step3中创立的增量表中装载数据，值得注意的是：因为TT写入的数据是有时序的，例如一条记录在一天被更新N次，则在当日的表中，就有N条记录。对于按天增量的数据来说，只须要最新的数据即可，所以须要依照主键分区排序，分组取最新的数据，这里再次阐明一下主键的重要性，如果主键指定不正确，很容易造成脏数据的产生。装载数据的逻辑是： INSERT OVERWRITE TABLE s_tt_member_round_detail_delta PARTITION(ds='20210304')SELECT id ,gmt_create ,gmt_modified ,user_id ,start_date ,end_date ,STATUS ,TYPE ,attributes ,round ,merchant_code ,consume_discount ,card_id ,plan_id ,biz_idFROM ( -- 因为TT写入的数据是有时序的，例如一条记录在一天被更新N次，则在当日的表中，就有N条记录。 -- 对于按天增量的数据来说，只须要最新的数据即可 -- 依照主键分区排序，分组取最新的数据 SELECT row_number() OVER(PARTITION BY id,user_id,biz_id ORDER BY id,user_id,biz_id,dbsync_ts DESC) AS row_number ,dbsync_operation ,id ,gmt_create ,gmt_modified ,user_id ,start_date ,end_date ,STATUS ,TYPE ,attributes ,round ,merchant_code ,consume_discount ,card_id ,plan_id ,biz_id FROM ( SELECT dbsync_ts ,dbsync_operation ,id ,gmt_create ,gmt_modified ,user_id ,start_date ,end_date ,status ,TYPE ,attributes ,round ,merchant_code ,consume_discount ,card_id ,plan_id ,biz_id FROM ( -- 获取并解析当天的变更日志数据 SELECT tt_split(content, 21) AS (dbsync_ts,dbsync_db_name,dbsync_table_name,dbsync_modify_time,dbsync_operation,dbsync_change_fields,id,gmt_create,gmt_modified,user_id,start_date,end_date,status,TYPE,attributes,round,merchant_code,consume_discount,card_id,plan_id,biz_id) FROM hm_ods.s_tt_wdk_member_pro_app_member_round_detail_tt4 WHERE ( ds > '20210304' OR (ds = '20210304' AND (hh > '00' OR (hh = '00' AND mm >= '00'))) ) AND ( ds < '20210305' OR (ds = '20210305' AND (hh < '00' OR (hh = '00' AND mm < '00'))) ) ) t WHERE t.dbsync_ts != '' ) b ) uWHERE row_number = 1;Step5.TTMerge节点公布公布TTMerge的工作 ...

数据仓库系列文章(继续更新) 数仓架构发展史数仓建模方法论数仓建模分层实践数仓建模—宽表的设计数仓建模—指标体系数据仓库之拉链表数仓—数据集成数仓—数据集市数仓—商业智能零碎数仓—埋点设计与治理数仓—ID Mapping数仓—OneID数仓—AARRR海盗模型数仓—总线矩阵数仓—数据安全数仓—数据品质数仓—数仓建模和业务建模工欲善其事，必先利其器，所以开始数仓建模之前咱们还是要抉择一个适合的建模工具，江湖上混怎么能没有一个嘹亮的名号和趁手的武器呢，PDMan就是咱们要介绍的工具。前面咱们还会介绍其余建模工具，你抉择一个适合的就行。 PDMan是一款开源收费的数据库模型建模工具，反对Windows,Mac,Linux等操作系统，是PowerDesigner之外，更好的收费的代替计划。他具备颜值高，应用简略的特点。蕴含数据库建模，灵便主动的主动生成代码模板，主动生成文档等多种开发人员实用的性能。 PDMan已全面降级至CHINER开始之前咱们开始先介绍一下这个工具自身，前面再看怎么应用它以及它的个性,其实CHINER就是PDMan的降级版本，咱们能够先看一下界面 这是PDMan 的项目管理界面，咱们看到也是分项目管理的，能够抉择关上已有的我的项目 我的项目关上后的界面，其实性能还是比较简单的，次要就是模型的设计，蕴含两块 表设计关系设计 名称由来第一个（公开发行名称）：PDMan: Physical Data Model Manager(物理模型治理)第二个（外部应用名称）：SINOPER: SINO Popular Entity Relation(中国最风行的实体关系图工具)，目前该软件发行版，底层很多代码为该词前缀。第三个（公开发行名称）：CHINER: CHINESE Entity Relation(国产实体关系图工具)，为不便国内遍及，中文名称为：元数建模，也作:"CHINER[元数建模]"公开应用。CHINER 的特点体系结构从新设计，构造颠覆，然而对原PDMan做到高度兼容。精密的界面布局及操作优化，更好看，更简略，更好用。减少实用新性能(如导入PowerDesigner等），性能更弱小，生态兼容性更好。性能介绍因为CHINER 是PDMan 的降级版本，所以咱们这里间接介绍CHINER 自带入门参考案例首页自带两个典型参考案例，不便用户疾速理解软件反对的性能以及个性。 治理对象数据表及字段提供简洁直观的数据表以及字段治理及操作，左侧列表反对拖动排序，数据表更多设置反对减少表备注，扩大属性列表，例如提供对Hive的反对，如下图： 多表关联的视图视图由多个表联合而成，反对多表以及字段的抉择，如下图： 视图及起源数据表，如下图： 可定制的数据类型及数据域可扩大的数据类型，并且反对多种数据库方言的适配，如下图： 这个次要是解决拓展性的，也就是咱们能够依据扩大不同的数据库进来 数据域，用于设置同一类具备特定业务含意的数据类型，其实这个是很重要的，咱们在做数仓建模的过程中是须要对立字段命名和字段类型，如下图： 数据规范（字段库）规范字段库用于解决常用字段记录，不便用户建设数据表时，可能从常用字段库里间接拖入数据表中。 规范字段库能够用户自行添加，也能够从现有数据表中移到规范字段库中，其实这个是很重要的，咱们在做数仓建模的过程中是须要对立字段命名和字段类型 如下图所示： 规范字段库反对导出JSON文件，也反对从JSON文件中导入，以解决共享交换问题。 数据字典（代码映射表）减少了数据字典反对，用于解决对字段元数据更清晰的解析论述，如下图： 数据表字段能够间接关联数据字典，如下图所示： 我的项目组织模式(多模块模式以及不分模块模式)简略我的项目，不须要分模块，间接分为数据表，视图，关系图，数据字典即可，简单我的项目须要折分为一个一个独立的模块，系统对这两种模式均给予反对。 简略模式，如下图： 分模块模式，如下图： ### 关系图 其实以后版本的关系图的可视化相比PDMan 就难看很多了，而且还反对了折线 ER关联关系图数据实体关联关系图，该关联关系图须要人工手动保护，如下图所示： 简略的概念模型图反对简略的概念模型图，概念模型图实体只保留在关系图上，不放弃实体对象，如下图所示： 概念模型图，次要用于疾速勾画零碎的要害业务对象关系图，用于疾速整体了解数据模型。 同一模块多张关系图同一个模块，能够反对多张多种形式的关系图： 画布设计界面分组框及以备注框分组框，用于对数据表或者实体进行分类，可能更清晰的理解数据表的层次结构，如下图： 文字以及背景色彩设置备注框，为一般矩形框，用于对数据表或者业务场景进行解释阐明，如下图： 代码模板不同数据库方言的DDL通过代码模板引擎，实现可扩大的数据库方言反对，如下图： MySQL ...

本文纲要： 因内容较多，本文将间接从第五章开始，完整版文档请点击下方链接： 本文数仓建设保姆级教程残缺PDF版 前四章内容在上方链接获取五、实时数仓建设外围1. 实时计算初期尽管实时计算在最近几年才火起来，然而在晚期也有局部公司有实时计算的需要，然而数据量比拟少，所以在实时方面造成不了残缺的体系，根本所有的开发都是具体问题具体分析，来一个需要做一个，根本不思考它们之间的关系，开发模式如下： 如上图所示，拿到数据源后，会通过数据荡涤，扩维，通过Flink进行业务逻辑解决，最初间接进行业务输入。把这个环节拆开来看，数据源端会反复援用雷同的数据源，前面进行荡涤、过滤、扩维等操作，都要反复做一遍，惟一不同的是业务的代码逻辑是不一样的。 随着产品和业务人员对实时数据需要的一直增多，这种开发模式呈现的问题越来越多： 数据指标越来越多，“烟囱式”的开发导致代码耦合问题重大。需要越来越多，有的须要明细数据，有的须要 OLAP 剖析。繁多的开发模式难以应酬多种需要。每个需要都要申请资源，导致资源老本急速收缩，资源不能粗放无效利用。短少欠缺的监控零碎，无奈在对业务产生影响之前发现并修复问题。大家看实时数仓的倒退和呈现的问题，和离线数仓十分相似，前期数据量大了之后产生了各种问题，离线数仓过后是怎么解决的？离线数仓通过分层架构使数据解耦，多个业务能够共用数据，实时数仓是否也能够用分层架构呢？当然是能够的，然而细节上和离线的分层还是有一些不同，稍后会讲到。 2. 实时数仓建设从方法论来讲，实时和离线是十分类似的，离线数仓晚期的时候也是具体问题具体分析，当数据规模涨到一定量的时候才会思考如何治理。分层是一种十分无效的数据治理形式，所以在实时数仓如何进行治理的问题上，首先思考的也是分层的解决逻辑。 实时数仓的架构如下图： 从上图中咱们具体分析下每层的作用： 数据源：在数据源的层面，离线和实时在数据源是统一的，次要分为日志类和业务类，日志类又包含用户日志，埋点日志以及服务器日志等。实时明细层：在明细层，为了解决反复建设的问题，要进行对立构建，利用离线数仓的模式，建设对立的根底明细数据层，依照主题进行治理，明细层的目标是给上游提供间接可用的数据，因而要对根底层进行对立的加工，比方荡涤、过滤、扩维等。汇总层：汇总层通过Flink的简洁算子间接能够算出后果，并且造成汇总指标池，所有的指标都对立在汇总层加工，所有人依照对立的标准治理建设，造成可复用的汇总后果。咱们能够看出，实时数仓和离线数仓的分层十分相似，比方 数据源层，明细层，汇总层，乃至应用层，他们命名的模式可能都是一样的。但认真比拟不难发现，两者有很多区别： 与离线数仓相比，实时数仓的档次更少一些： 从目前建设离线数仓的教训来看，数仓的数据明细层内容会十分丰盛，解决明细数据外个别还会蕴含轻度汇总层的概念，另外离线数仓中应用层数据在数仓外部，但实时数仓中，app 应用层数据曾经落入利用零碎的存储介质中，能够把该层与数仓的表拆散。应用层少建设的益处：实时处理数据的时候，每建一个档次，数据必然会产生肯定的提早。汇总层少建的益处：在汇总统计的时候，往往为了容忍一部分数据的提早，可能会人为的制作一些提早来保证数据的精确。举例，在统计跨天相干的订单事件中的数据时，可能会等到 00:00:05 或者 00:00:10 再统计，确保 00:00 前的数据曾经全副承受到位了，再进行统计。所以，汇总层的档次太多的话，就会更大的减轻人为造成的数据提早。与离线数仓相比，实时数仓的数据源存储不同： 在建设离线数仓的时候，根本整个离线数仓都是建设在 Hive 表之上。然而，在建设实时数仓的时候，同一份表，会应用不同的形式进行存储。比方常见的状况下，明细数据或者汇总数据都会存在 Kafka 外面，然而像城市、渠道等维度信息须要借助 Hbase，MySQL 或者其余 KV 存储等数据库来进行存储。3. Lambda架构的实时数仓Lambda和Kappa架构的概念已在前文中解释，不理解的小伙伴可点击链接：一文读懂大数据实时计算 下图是基于 Flink 和 Kafka 的 Lambda 架构的具体实际，下层是实时计算，上层是离线计算，横向是按计算引擎来分，纵向是按实时数仓来辨别： Lambda架构是比拟经典的架构，以前实时的场景不是很多，以离线为主，当附加了实时场景后，因为离线和实时的时效性不同，导致技术生态是不一样的。Lambda架构相当于附加了一条实时生产链路，在利用层面进行一个整合，双路生产，各自独立。这在业务利用中也是牵强附会采纳的一种形式。 双路生产会存在一些问题，比方加工逻辑double，开发运维也会double，资源同样会变成两个资源链路。因为存在以上问题，所以又演进了一个Kappa架构。 4. Kappa架构的实时数仓Kappa架构相当于去掉了离线计算局部的Lambda架构，具体如下图所示： Kappa架构从架构设计来讲比较简单，生产对立，一套逻辑同时生产离线和实时。然而在理论利用场景有比拟大的局限性，因为实时数据的同一份表，会应用不同的形式进行存储，这就导致关联时须要跨数据源，操作数据有很大局限性，所以在业内间接用Kappa架构生产落地的案例不多见，且场景比拟繁多。 对于 Kappa 架构，相熟实时数仓生产的同学，可能会有一个疑难。因为咱们常常会面临业务变更，所以很多业务逻辑是须要去迭代的。之前产出的一些数据，如果口径变更了，就须要重算，甚至重刷历史数据。对于实时数仓来说，怎么去解决数据重算问题？ Kappa 架构在这一块的思路是：首先要筹备好一个可能存储历史数据的音讯队列，比方 Kafka，并且这个音讯队列是能够反对你从某个历史的节点从新开始生产的。接着须要新起一个工作，从原来比拟早的一个工夫节点去生产 Kafka 上的数据，而后当这个新的工作运行的进度曾经可能和当初的正在跑的工作齐平的时候，你就能够把当初工作的上游切换到新的工作下面，旧的工作就能够停掉，并且原来产出的后果表也能够被删掉。 5. 流批联合的实时数仓随着实时 OLAP 技术的倒退，目前开源的OLAP引擎在性能，易用等方面有了很大的晋升，如Doris、Presto等，加上数据湖技术的迅速倒退，使得流批联合的形式变得简略。 如下图是流批联合的实时数仓： 数据从日志对立采集到音讯队列，再到实时数仓，作为根底数据流的建设是对立的。之后对于日志类实时特色，实时大屏类利用走实时流计算。对于Binlog类业务剖析走实时OLAP批处理。 咱们看到流批联合的形式与下面几种架构的存储形式产生了变动，由Kafka换成了Iceberg，Iceberg是介于下层计算引擎和底层存储格局之间的一个中间层，咱们能够把它定义成一种“数据组织格局”，底层存储还是HDFS，那么为什么加了中间层，就对流批联合解决的比拟好了呢？Iceberg的ACID能力能够简化整个流水线的设计，升高整个流水线的提早，并且所具备的批改、删除能力可能无效地升高开销，晋升效率。Iceberg能够无效反对批处理的高吞吐数据扫描和流计算按分区粒度并发实时处理。 六、基于Flink SQL从0到1构建一个实时数仓注：本大节内容来自公众号大数据技术与数仓！实时数仓次要解决传统数仓数据时效性低的问题，实时数仓通常会用在实时的OLAP剖析，实时大屏展现，实时监控报警各个场景。尽管对于实时数仓架构及技术选型与传统的离线数仓会存在差别，然而对于数仓建设的根本方法论是统一的。接下来次要介绍Flink SQL从0到1搭建一个实时数仓的demo，波及到数据采集、存储、计算、可视化整个流程。 ...

晚上起床的时候，发现自己尿分叉，我没有多想，简略洗洗就匆忙出门。路过早餐店，我看到徒弟纯熟的拉扯一小块面团，拉至修长条，而后放入油锅中，不一会功夫，一根屎黄色的油条便出锅了，卖相不错。我在想，小到炸屎黄色的油条，大到学习，其实都是一个游刃有余的过程。 数据仓库系列文章(继续更新) 数仓架构发展史数仓建模方法论数仓建模分层实践数仓建模—宽表的设计数仓建模—指标体系数据仓库之拉链表数仓—数据集成数仓—数据集市数仓—商业智能零碎数仓—埋点设计与治理数仓—ID Mapping数仓—OneID数仓—AARRR海盗模型数仓—总线矩阵数仓—数据安全数仓—数据品质数仓—数仓建模和业务建模关注大数据技术派，回复: 材料，支付1024G材料。顾名思义咱们晓得ID Mapping 的操作对象是ID，指标或者是动作是Mapping，也就是说咱们要做的事件其实就是想把不同平台不同设施上的ID 买通，从而更好的去刻画用户，也就是说咱们心愿能买通用户各个维度的数据，从而更好的去服务业务服务用户 通常公司有产品矩阵，而每个产品都有本人的注册账号产生的用户ID。从公司全局，整合用户表，用户行为数据来看，确定不同产品的用户ID是雷同一个人十分重要, 选取适合的用户标识对于进步用户行为剖析的准确性有十分大的影响，尤其是对用户画像、举荐、漏斗、留存、Session 等用户相干的剖析性能。 其实对于任何剖析都是一样的，如果咱们不能精确标识一个用户，那么咱们的计算结果就没有准确性可言，其实对于数据服务方而言，数据的准确性是咱们的第一要务，咱们宁愿不出数据，也不要出谬误的数据。 ID Mapping 的背景网络身份证 如果没有网络身份证，那么每个商家（App）只能基于本人的账号体系标识用户，并记录用户的行为。而有了对立的网络身份证之后，各个商家之间的数据就能够买通了，天猫不仅晓得用户A在淘宝系的购物数据，也能理解到该用户在社交网络的行为，以及游览的爱好，等等。 在事实的数据中，因为，用户可能应用各种各样的设施，有着各种各样的前端入口，甚至同一个用户领有多个设施以及应用多种前端入口，就会导致，日志数据中对同一个人，不同时间段所收集到的日志数据中，可能取到的标识个数、品种各不相同； 比方用户可能应用各种各样的设施，其次是不同设施有不同的操作系统，设置是软件自身的版本也会影响咱们对用户的标识， 手机、平板电脑、PC安卓手机、ios手机、winphone手机安卓零碎有各种版本 （ 5.0 6.0 7.0 8.0 9.0 ）ios零碎也有各种版本（3.x 4.x 5.x 6.x 7.x … 12.x ）存在的问题 用户设施的标识，没方法轻易定制一个规定来取某个作为惟一标识：mac地址：手机网卡物理地址， 若干晚期版本的ios，winphone，android可取到imei(入网许可证序号)：安卓零碎可取到，若干晚期版本的ios，winphone可取到，运营商可取到imsi(手机SIM卡序号)：安卓零碎可取到，若干晚期版本的ios，winphone可取到，运营商可取到androidid ：安卓零碎idopenuuid(app本人生成的序号) ：卸载重装app就会变更IDFA(广告跟踪码)扩大 IDFA IDFA，英文全称 Identifier for Advertising ，能够了解为广告id，苹果公司提供的用于追踪用户的广告标识符，能够用来买通不同app之间的广告。每个设施只有一个IDFA，不同APP在同一设施上获取IDFA的后果是一样的 苹果为了爱护用户隐衷，早在2012年就不再容许其生态中的玩家获取用户的惟一标识符，然而商家在挪动端打广告的时候又心愿能监控到每一次广告投放的成果，因而，苹果想出了折中的方法，就是提供另外一套和硬件无关的标识符，用于给商家监测广告成果，同时用户能够在设置里扭转这串字符，导致商家没有方法长期跟踪用户行为。这个就叫做广告标识符（IDFA），设置门路是“设置->隐衷->广告->还原广告标识符”，如下图所示（iOS9） 常见的标识设施 ID须要留神的是，设施 ID 并不一定是设施的惟一标识。例如 Web 端的 Cookies 有可能被清空（例如各种安全卫士），而 iOS 端的 IDFV( Identifier For Vendor)在不同厂商的 App 间是不同的,而且重新安装IDFV会被重置。 设施规定Android1.10.5 之前版本，默认应用 UUID（例如：550e8400-e29b-41d4-a716-446655440000），App 卸载重装 UUID 会变，为了保障设施 ID 不变，能够通过配置应用 AndroidId（例如：774d56d682e549c3）；1.10.5 及之后的版本 SDK 默认应用 AndroidId 作为设施 ID，如果 AndroidId 获取不到则获取随机的 UUID。iOS1.10.18 及之后版本，如果 App 引入了 AdSupport 库，SDK 默认应用 IDFA 作为匿名 ID。1.10.18 之前版本，能够优先应用 IDFV（例如：1E2DFA10-236A-47UD-6641-AB1FC4E6483F），如果 IDFV 获取失败，则应用随机的 UUID（例如：550e8400-e29b-41d4-a716-446655440000），个别状况下都可能获取到 IDFV。如果应用 IDFV 或 UUID ，当用户卸载重装 App 时设施 ID 会变。也能够通过配置应用 IDFA（例如：1E2DFA89-496A-47FD-9941-DF1FC4E6484A），如果开启 IDFA ，能够优先获取 IDFA，如果获取失败再尝试获取 IDFV。应用 IDFA 能防止用户在重装 App 后设施 ID 发生变化的状况，须要留神的是IDFA 也是能够被重置的登录 ID登录 ID 通常是业务数据库里的主键或其它惟一标识。所以 登录 ID，相对来说更准确更长久。然而，用户在应用时不肯定注册或者登录，而这个时候是没有登录 ID 的。 ...

数据仓库系列文章(继续更新) 数仓架构发展史数仓建模方法论数仓建模分层实践数仓建模—宽表的设计数仓建模—指标体系数据仓库之拉链表数仓—数据集成数仓—数据集市数仓—商业智能零碎数仓—埋点设计与治理数仓—ID Mapping数仓—OneID数仓—AARRR海盗模型数仓—总线矩阵数仓—数据安全数仓—数据品质数仓—数仓建模和业务建模关注公众号：大数据技术派，回复: 材料，支付1024G材料。其实数据集成是数仓的一个根本特点，这里咱们再回顾一下数仓的个性，或者说是咱们再回顾一下数仓的定义，面向主题的（Subject Oriented）、集成的（Integrate）、绝对稳固的（Non-Volatile）、反映历史变动（Time Variant）的数据汇合，用于反对管理决策的数据系统。 明天咱们学习的数据集成指的是“集成的” 个性，说到数据集成咱们就不得不说咱们为什么要建设数仓了，对于数仓是是什么或者是服务于什么的咱们曾经说过了，那就是数仓次要是用来做决策的，也就是从数据的角度登程去做决策，而不是纯正的拍脑袋去决策。 所以这个时候数据准确性就很重要，这里的数据准确性不仅仅指的是咱们的数据计算精确，而是指的是咱们的数据自身要可能反馈事实，也就是说咱们要拿适合的数据来干正确的事件。 咱们将以前扩散的数据收集到一起不仅仅是为了突破数据壁垒，咱们更心愿能进行对立解决，从而进步数据的可信性、进步数据的生产效率问题，所以说数据集成并不是单单指的是数据收集，可能一说到数据集成大家想到的可能就是 sqoop、dataX、maxwell 这样的数据同步工具，这个想法自身没错，然而这些仅仅是工具，是开始而已。 数据集成的背景集成的目标是为了买通数据从而更加精确的形容业务，从而更好的为业务赋能，这里举一个例子介绍我当初有三个决策零碎，都须要一份业务数据，那这个时候三个零碎都会从业务数据库拉去数据，这个时候就会引发很多问题 对业务库的压力太大每个零碎都有本人的逻辑、产出不精确、数据无奈核查每个零碎都有资源耗费在企业中，因为开发工夫或开发部门的不同，往往有多个异构的、运行在不同的软硬件平台上的信息系统同时运行，这些零碎的数据源彼此独立、互相关闭，使得数据难以在零碎之间交换、共享和交融，从而造成了"信息孤岛"。随着信息化利用的不断深入，企业外部、企业与内部信息交互的需要日益强烈，急切需要对已有的信息进行整合，买通信息孤岛，共享信息。 数据集成是把不同起源、格局、特点性质的数据在逻辑上或物理上有机地集中，从而为企业提供全面的数据共享。在企业数据集成畛域，曾经有了很多成熟的框架能够利用。目前通常采纳联邦式、基于中间件模型和数据仓库等办法来结构集成的零碎，这些技术在不同的着重点和利用上解决数据共享和为企业提供决策反对。 数据集成通过利用间的数据交换从而达到集成，次要解决数据的散布性和异构性的问题，其前提是被集成利用必须公开数据结构，即必须公开表构造，表间关系，编码的含意等 数据集成的分类在企业数据集成畛域，曾经有了很多成熟的框架能够利用。通常采纳联邦式、基于中间件模型和数据仓库等办法来结构集成的零碎，这些技术在不同的着重点和利用上解决数据共享和为企业提供决策反对。在这里将对这几种数据集成模型做一个根本的剖析。 联邦数据库系统联邦数据库系统( FDBS)由半自治数据库系统形成，相互之间分享数据，联盟各数据源之间互相提供拜访接口，同时联盟数据库系统能够是集中数据库系统或分布式数据库系统及其他联邦式零碎。 在这种模式下又分为紧耦合和松耦合两种状况，紧耦合提供对立的拜访模式，个别是动态的，在减少数据源上比拟艰难；而松耦合]则不提供对立的接口，但能够通过对立的语言拜访数据源，其中外围的是必须解决所有数据源语义上的问题。 中间件模式中间件模式通过对立的全局数据模型来拜访异构的数据库、遗留零碎、Web 资源等。 中间件位于异构数据源零碎[数据层) 和应用程序(应用层) 之间，向上协调各数据源零碎，向下为拜访集成数据的利用提供对立数据模式和数据拜访的通用接口。各数据源的利用依然实现它们的工作，中间件零碎则次要集中为异构数据源提供一个高层次的数据收集和散发服务。 中间件模式是比拟风行的数据集成办法，它通过在中间层提供一个对立的数据逻辑视图来暗藏底层的数据细节，使得用户能够把集成数据源看为一个对立的整体。这种模型下的关键问题是如何结构这个逻辑视图并使得不同数据源之间能映射到这个中间层。 比拟支流的中间件模式是应用一些高性能的音讯队列，例如kafak、pulsar 等，也就是说咱们的多个数据源将本人的数据发送到kafka ，上游的集成系统再从kafka 进行生产数据，从而实现数据集成。 数据仓库模式数据仓库在另外一个层面上表白数据之间的共享，它次要是为了针对企业某个应用领域提出的一种数据集成办法，也就是咱们在下面所提到的面向主题并为企业提供数据挖掘和决策反对的零碎。 所以说数据仓库的数据集成其实是依照域对数据集成进行划分治理的，其实这就和咱们的宽表建设进行了响应，能够参考数仓建模—宽表的设计,所以说数据集成它不等于数据堆集，也不等于数据同步，不是说我把数据同步到一个中央，而后应用的时候就能够在这个中央找失去这就是数据集成。 数据集成的目标是为了买通数据孤岛，数据同步到一起，孤岛还在，这个时候要咱们须要依照业务特点进行加工才能够建设咱们的数仓表，这样才算是实现了数据集成。 所以咱们能够看到后面的联邦数据库系统、中间件模式 只是在肯定水平上的数据集成工具，然而它并没有实现业务意义上的数据集成。 数据集成的含意这里咱们还是要说一下数据集成的含意，否则你可能认为数据集成就是数据同步，或者是数据同步平台(d_BUS)的建设 数据集成须要有数据同步的能力，也就是说须要将散落在各处的数据同步过去，这里会波及到各种异构数据源，所以对咱们的数据平台能力有肯定的要求，例如反对各种数据库的能力、反对实时和离线的数据同步能力依照业务特点对同步过去的数据进行荡涤加工，而后以宽表的模式堆外提供服务，这里的宽表才是咱们业务上集成的含意集成也是有要求的，也就是说咱们是在特定的数据域下进行集成的。总结数据集成是数仓的个性，所以数仓须要具备数据集成的能力数据集成它不等价于数据同步平台，数据同步只是数据集成的第一步数据集成的目标是为了买通数据孤岛，从而更好的反对企业的数据决策，数仓突破数据孤岛的形式是将各个业务零碎数据集中到一个对立的、集中的 数据仓库，而达到这个目标形式就是数据集成

明天是我在上海租房的小区被封的第三天，因为我的粗心，没有屯吃的，外卖明天齐全点不到了，中午的时候我找到了一包快过期的肉松饼，才补充了1000焦耳的能量。然而中午去做核酸的时候，我感觉走路有点不稳，我看到大白的棉签深刻我的嘴里，我居然认为是吃的，差点咬住了，还好我有仅存的一点意识。下午我收到女朋友给我点的外卖——面包（我不晓得她是怎么点到的外卖，我很打动），很粗劣的面包，搁平时我根本不喜爱吃面包，然而曾经到了这个份上，我大口吃起来，居然感觉这是世界上最好吃的食物了。今天晚上5：50的闹钟，去叮咚和美团买菜，看能不能抢几桶泡面吧。愿神保佑，我暗暗下着信心并祷告着，胸前画着十字。。。 数据仓库系列文章(继续更新) 数仓架构发展史数仓建模方法论数仓建模分层实践数仓建模—宽表的设计数仓建模—指标体系数据仓库之拉链表数仓—数据集成数仓—数据集市数仓—商业智能零碎数仓—埋点设计与治理数仓—ID Mapping数仓—OneID数仓—AARRR海盗模型数仓—总线矩阵数仓—数据安全数仓—数据品质数仓—数仓建模和业务建模关注公众号：大数据技术派，回复: 材料，支付1024G材料。OneID后面咱们学习了ID Mapping，包含ID Mapping 的背景介绍和业务场景，以及如何应用Spark 实现ID Mapping，这个过程中波及到了很多货色，当然咱们都通过文章的模式介绍给大家了，所以你再学习明天这一节之前，能够先看一下后面的文章 Spark实战—GraphX编程指南数仓建模—ID Mapping在上一节咱们介绍ID Mapping 的时候咱们就说过ID Mapping 是为了买通用户各个维度的数据，从而打消数据孤岛、防止数据歧义，从而更好的刻画用户，所以说ID Mapping是伎俩不是目标，目标是为了买通数据体系，ID Mapping最终的产出就是咱们明天的配角OneID，也就是说数据收集过去之后通过ID Mapping 买通，从而产生OneID，这一步之后咱们的整个数据体系就将应用OneID作为用户的ID，这样咱们整个数据体系就得以买通 OneData开始之前咱们先看一下阿里的OneData 数据体系，从而更好认识一下OneID，后面咱们说过ID Mapping 只是伎俩不是目标，目标是为了买通数据体系，ID Mapping最终的产出就是OneID 其实OneID在咱们整个数据服务体系中，也只是终点不是起点或者说是伎俩，咱们最终的目标是为了建设对立的数据资产体系。 没有建设对立的数据资产体系之前，咱们的数据体系建设存在上面诸多问题 数据孤岛：各产品、业务的数据互相隔离，难以通过共性ID买通反复建设：反复的开发、计算、存储，带来昂扬的数据老本数据歧义：指标定义口径不统一，造成计算偏差，利用艰难在阿里巴巴 OneData 体系中，OneID 指对立数据萃取，是一套解决数据孤岛问题的思维和办法。数据孤岛是企业倒退到肯定阶段后广泛遇到的问题。各个部门、业务、产品，各自定义和存储其数据，使得这些数据间难以关联，变成孤岛个别的存在。 OneID的做法是通过对立的实体辨认和连贯，突破数据孤岛，实现数据通融。简略来说，用户、设施等业务实体，在对应的业务数据中，会被映射为惟一辨认（UID）上，其各个维度的数据通过这个UID进行关联。 各个部门、业务、产品对业务实体的UID的定义和实现不一样，使得数据间无奈间接关联，成为了数据孤岛。基于手机号、身份证、邮箱、设施ID等信息，联合业务规定、机器学习、图算法等算法，进行 ID-Mapping，将各种 UID 都映射到对立ID上。通过这个对立ID，便可关联起各个数据孤岛的数据，实现数据通融，以确保业务剖析、用户画像等数据利用的精确和全面。 OneModel 对立数据构建和治理将指标定位细化为： 1. 原子指标2. 工夫周期3. 修饰词（统计粒度、业务限定, etc）通过这些定义，设计出各类派生指标 基于数据分层，设计出维度表、明细事实表、汇总事实表，其实咱们看到OneModel 其实没有什么新的内容，其实就是咱们数仓建模的那一套货色 OneService 对立数据服务OneService 基于复用而不是复制数据的思维，指得是咱们的对立的数据服务，因为咱们始终再提倡复用，包含咱们数仓的建设，然而咱们的数据服务这一块却是空白，所以OneService外围是服务的复用，能力包含： 利用主题逻辑表屏蔽简单物理表的主题式数据服务个别查问+ OLAP 剖析+在线服务的对立且多样化数据服务屏蔽多种异构数据源的跨源数据服务OneID 对立数据萃取基于对立的实体辨认、连贯和标签生产，实现数据通融，包含： ID自动化辨认与连贯行为元素和行为规定标签生产OneID基于超强ID辨认技术链接数据，高效生产标签；业务驱动技术价值化，打消数据孤岛，晋升数据品质，晋升数据价值。 而ID的买通，必须有ID-ID之间的两两映射买通关系，通过ID映射关系表，能力将多种ID之间的关联买通，齐全孤立的两种ID是无奈买通的。 买通整个ID体系，看似简略，实则计算简单，计算量十分大。如果某种对象有数亿个个体，每个个体又有数十种不同的ID标识，任意两种ID之间都有可能买通关系，想要实现这类对象的所有个体ID买通须要数亿次计算，个别的机器甚至大数据集群都无奈实现。 大数据畛域中的ID-Mapping技术就是用机器学习算法类来取代横蛮计算，解决对象数据买通的问题。基于输出的ID关系对，利用机器学习算法做稳定性和收敛性计算，输入关系稳固的ID关系对，并生成一个UID作为惟一辨认该对象的标识码。 OneID实现过程中存在的问题后面咱们晓得咱们的ID Mapping 是通过图计算实现，外围就是连通图，其实实现OneID咱们在买通ID 之后，咱们就能够为一个个连通图生成一个ID, 因为一个连通图 就代表一个用户，这样咱们生成的ID就是用户的OneID，这里的用户指的是自然人，而不是某一个平台上的用户。 OneID 的生成问题首先咱们须要一个ID 生成算法，因为咱们须要为大量用户生成ID,咱们的ID 要求是惟一的，所以在算法设计的时候就须要思考到这一点，咱们并不举荐应用UUID,起因是UUID了可能会呈现反复，而且UUID 没有含意，所以咱们不举荐应用UUID,咱们这里应用的是MD5 算法，所以咱们的MD5 算法的参数是咱们的图的标示ID。 ...

数仓建设保姆级教程，离线和实时一网打尽(实践+实战) 本文纲要： 因内容较多，带目录的PDF查看是比拟不便的： 数仓建设保姆级教程PDF文档 一、数仓基本概念1. 数据仓库架构咱们在谈数仓之前，为了让大家有直观的意识，先来谈数仓架构，“架构”是什么？这个问题素来就没有一个精确的答案。这里咱们援用一段话：在软件行业，一种被广泛承受的架构定义是指零碎的一个或多个构造。构造中包含软件的构建（构建是指软件的设计与实现），构建的内部能够看到属性以及它们之间的互相关系。 这里参考此定义，把数据仓库架构了解成形成数据仓库的组件及其之间的关系，画出上面的数仓架构图： 上图中显示的整个数据仓库环境包含操作型零碎和数据仓库零碎两大部分。操作型零碎的数据由各种模式的业务数据组成，这些数据通过抽取、转换和装载（ETL）过程进入数据仓库零碎。 任何事物都是随着工夫的演进变得越来越欠缺，当然也是越来越简单，数仓也不例外。在数据仓库技术演化过程中，产生了几种次要的架构办法，包含数据集市架构、Inmon企业信息工厂架构、Kimball数据仓库架构、混合型数据仓库架构。这几种架构咱们前面再讲，接下来看下数仓的基本概念。 2. 数据仓库概念英文名称为Data Warehouse，可简写为DW或DWH。数据仓库的目标是构建面向剖析的集成化数据环境，为企业提供决策反对（Decision Support）。它出于剖析性报告和决策反对目标而创立。 数据仓库自身并不“生产”任何数据，同时本身也不须要“生产”任何的数据，数据来源于内部，并且凋谢给内部利用，这也是为什么叫“仓库”，而不叫“工厂”的起因。 1) 基本特征数据仓库是面向主题的、集成的、非易失的和时变的数据汇合，用以反对管理决策。 面向主题:传统数据库中，最大的特点是面向利用进行数据的组织，各个业务零碎可能是互相拆散的。而数据仓库则是面向主题的。主题是一个形象的概念，是较高层次上企业信息系统中的数据综合、归类并进行剖析利用的形象。在逻辑意义上，它是对应企业中某一宏观剖析畛域所波及的剖析对象。 集成性:通过对扩散、独立、异构的数据库数据进行抽取、清理、转换和汇总便失去了数据仓库的数据，这样保障了数据仓库内的数据对于整个企业的一致性。 数据仓库中的综合数据不能从原有的数据库系统间接失去。因而在数据进入数据仓库之前，必然要通过对立与综合，这一步是数据仓库建设中最要害、最简单的一步，所要实现的工作有： 要对立源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不对立、字长不统一，等等。进行数据综合和计算。数据仓库中的数据综合工作能够在从原有数据库抽取数据时生成，但许多是在数据仓库外部生成的，即进入数据仓库当前进行综合生成的。下图阐明一个保险公司综合数据的简略处理过程，其中数据仓库中与“保险” 主题无关的数据来自于多个不同的操作型零碎。这些零碎外部数据的命名可能不同，数据格式也可能不同。把不同起源的数据存储到数据仓库之前，须要去除这些不统一。 非易失性（不可更新性）:数据仓库的数据反映的是一段相当长的工夫内历史数据的内容，是不同时点的数据库快照的汇合，以及基于这些快照进行统计、综合和重组的导出数据。 数据非易失性次要是针对利用而言。数据仓库的用户对数据的操作大多是数据查问或比较复杂的开掘，一旦数据进入数据仓库当前，个别状况下被较长时间保留。数据仓库中个别有大量的查问操作，但批改和删除操作很少。因而，数据经加工和集成进入数据仓库后是极少更新的，通常只须要定期的加载和更新。 时变性:数据仓库蕴含各种粒度的历史数据。数据仓库中的数据可能与某个特定日期、星期、月份、季度或者年份无关。数据仓库的目标是通过剖析企业过来一段时间业务的经营情况，开掘其中暗藏的模式。尽管数据仓库的用户不能批改数据，但并不是说数据仓库的数据是永远不变的。剖析的后果只能反映过来的状况，当业务变动后，挖掘出的模式会失去时效性。因而数据仓库的数据须要更新，以适应决策的须要。从这个角度讲，数据仓库建设是一个我的项目，更是一个过程。数据仓库的数据随工夫的变动体现在以下几个方面： （1） 数据仓库的数据时限个别要远远长于操作型数据的数据时限。 （2） 操作型零碎存储的是以后数据，而数据仓库中的数据是历史数据。 （3） 数据仓库中的数据是依照工夫程序追加的，它们都带有工夫属性。 3. 为什么要有数据仓库先来看下数据仓库的数据从哪里来，最终要到哪里去？ 通常数据仓库的数据来自各个业务利用零碎。业务零碎中的数据模式多种多样，可能是 Oracle、MySQL、SQL Server等关系数据库里的结构化数据，可能是文本、CSV等立体文件或Word、Excel文档中的数据，还可能是HTML、XML等自描述的半结构化数据。这些业务数据通过一系列的数据抽取、转换、荡涤，最终以一种对立的格局装载进数据仓库。数据仓库里的数据作为剖析用的数据源，提供给前面的即席查问、 剖析零碎、数据集市、报表零碎、数据挖掘零碎等。 这时咱们就想了，为什么不能把业务零碎的数据间接拿来供即席查问、剖析零碎、报表零碎等应用呢，为什么要通过数据仓库这一步？实际上在数仓呈现之前，的确是这么做的，然而有很多数据分析的先驱者过后曾经发现，简略的“间接拜访”形式很难良好工作，这样做的失败案例不可胜数。上面列举一些间接拜访业务零碎无奈工作的起因： 某些业务数据因为平安或其余因素不能间接拜访。业务零碎的版本变更很频繁，每次变更都须要重写剖析零碎并从新测试。很难建设和保护汇总数据来源于多个业务零碎版本的报表。业务零碎的列名通常是硬编码，有时仅仅是无意义的字符串，这让编写剖析零碎更加艰难。业务零碎的数据格式，如日期、数字的格局不对立。业务零碎的表构造为事务处理性能而优化，有时并不适宜查问与剖析。没有适当的形式将有价值的数据合并进特定利用的数据库。没有适当的地位存储元数据。用户须要看到的显示数据字段，有时在数据库中并不存在。通常事务处理的优先级比剖析零碎高，所以如果剖析零碎和事务处理运行在同一硬件之上，剖析零碎往往性能很差。有误用业务数据的危险。极有可能影响业务零碎的性能。只管须要减少软硬件的投入，但建设独立数据仓库与间接拜访业务数据相比，无论是老本还是带来的益处，这样做都是值得的。随着处理器和存储老本的逐年升高，数据仓库计划的劣势更加显著，在经济上也更具可行性。 4. 数据仓库与数据库的区别数据库与数据仓库的区别理论讲的是 OLTP 与 OLAP 的区别。 操作型解决，叫联机事务处理 OLTP（On-Line Transaction Processing，），也能够称面向交易的解决零碎，它是针对具体业务在数据库联机的日常操作，通常对多数记录进行查问、批改。用户较为关怀操作的响应工夫、数据的安全性、完整性和并发反对的用户数等问题。传统的数据库系统作为数据管理的次要伎俩，次要用于操作型解决，像Mysql，Oracle等关系型数据库个别属于OLTP。 剖析型解决，叫联机剖析解决 OLAP（On-Line Analytical Processing）个别针对某些主题的历史数据进行剖析，反对管理决策。 首先要明确，数据仓库的呈现，并不是要取代数据库。数据库是面向事务的设计，数据仓库是面向主题设计的。数据库个别存储业务数据，数据仓库存储的个别是历史数据。 数据库设计是尽量避免冗余，个别针对某一业务利用进行设计，比方一张简略的User表，记录用户名、明码等简略数据即可，合乎业务利用，然而不合乎剖析。数据仓库在设计是无意引入冗余，按照剖析需要，剖析维度、剖析指标进行设计。 数据库是为捕捉数据而设计，数据仓库是为剖析数据而设计。 以银行业务为例。数据库是事务零碎的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，能够简略地了解为用数据库记账。数据仓库是剖析零碎的数据平台，它从事务零碎获取数据，并做汇总、加工，为决策者提供决策的根据。比方，某银行某分行一个月产生多少交易，该分行以后贷款余额是多少。如果贷款又多，生产交易又多，那么该地区就有必要设立ATM了。 显然，银行的交易量是微小的，通常以百万甚至千万次来计算。事务零碎是实时的，这就要求时效性，客户存一笔钱须要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而剖析零碎是预先的，它要提供关注时间段内所有的无效数据。这些数据是海量的，汇总计算起来也要慢一些，然而，只有可能提供无效的剖析数据就达到目标了。 数据仓库，是在数据库曾经大量存在的状况下，为了进一步开掘数据资源、为了决策须要而产生的，它决不是所谓的“大型数据库”。 5. 数据仓库分层架构依照数据流入流出的过程，数据仓库架构可分为：源数据、数据仓库、数据利用 数据仓库的数据来源于不同的源数据，并提供多样的数据利用，数据自下而上流入数据仓库后向下层凋谢利用，而数据仓库只是两头集成化数据管理的一个平台。 源数据：此层数据无任何更改，间接沿用外围零碎数据结构和数据，不对外开放；为长期存储层，是接口数据的长期存储区域，为后一步的数据处理做筹备。 数据仓库：也称为细节层，DW层的数据应该是统一的、精确的、洁净的数据，即对源零碎数据进行了荡涤（去除了杂质）后的数据。 数据利用：前端利用间接读取的数据源；依据报表、专题剖析需要而计算生成的数据。 数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都能够认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也能够认为是数据仓库的血液，它维系着数据仓库中数据的推陈出新，而数据仓库日常的治理和保护工作的大部分精力就是放弃ETL的失常和稳固。 ...

成立于1996年的北京银行，抢抓时代时机，相继实现引资、上市、跨区域等倒退冲破，在北京、天津、上海、西安、深圳、杭州、长沙、南京、济南、南昌、石家庄、乌鲁木齐等十余个核心城市以及香港特别行政区、荷兰领有670多家分支机构，摸索了中小银行翻新倒退的经典模式。 北京银行资产规模持重增长，持续领跑全国城商行，跻身寰球百强银行和我国零碎重要性银行。在世界品牌实验室品牌价值排行榜中，品牌价值升至654亿元。在英国《银行家》杂志寰球千家大银行排名第62位，间断8年跻身寰球百强银行。此外，被人民银行、银保监会正式纳入我国零碎重要性银行名单，成为我国19家零碎重要性银行之一。 新期间，北京银行严密围绕“服务实体经济、防控金融风险、深入金融改革”三项工作，强化党建引领，依法合规经营，放慢数字化转型降级，增强全方位危险管控，扎实推动全行各项业务高质量倒退。 为此，北京银行信用卡核心从2015年开始建设数据平台零碎。随着新业务的倒退，北京银行信用卡核心要求IT零碎具备更强的数据存储、检索和继续的业务建模剖析能力。 为了满足将来业务倒退对数据的需要，北京银行信用卡核心要求构建新一代大数据平台，更好实现各利用零碎间数据和计算资源的共享，并撑持内外部数据的剖析和开掘利用，为数据中台建设打下基础。 具体而言，北京银行信用卡核心的的新一代大数据中心的利用需要包含： 针对批量业务，要求基于新一代大数据平台实现数据文件查收、数据文件预处理、数据文件传输、数据荡涤、数据加载、原始文件归档等性能；可能接管上游零碎数据并存储到数据仓库中，提供剖析计算接口，供上游业务零碎应用。 而针对实时业务，则需利用大数据平台的流解决引擎，接入行内音讯平台（或构建在平台的内部消息队列后），能具备前期开发实时流解决业务的能力，包含实时仪表盘监控、实时报表等能力。 解决方案图片 根据北京银行信用卡核心的需要和将来对大数据平台的布局，星环科技为其新一代大数据平台设计出架构计划。该架构次要分为上游零碎数据源、文件解决、大数据平台和上游。 批量数据从上游零碎数据平台数据库、贴源零碎中将数据文件接入到星环科技大数据根底平台TDH中的TDFS中，通过星环科技关系型剖析引擎Inceptor进行脱敏、计算，以供上游系统分析开掘。 实时数据从上游发卡零碎将数据接入到星环科技事件存储库Event Store音讯队列中，应用星环科技实时流计算引擎Slipstream剖析，将数据写入到星环科技宽表数据库Hyperbase中，反对决策引擎。 星环科技大数据管理软件TDH Manager是平台的对立治理入口，承当平台运维治理的性能。 星环科技大数据安全管理软件TDH guardian是平台的平安认证治理组件，可对组、角色、用户进行权限管控和对平台各个服务的应用权限管制。 北京银行信用卡核心对于大数据平台的整体数据流转如下： 数据源 北京银行信用卡核心的数据源来源于数据平台数据库和贴源零碎，大数据平台提供数据接口，通过星环科技事件存储库Event Store接入实时数据；通过数据接口全量或定时增量抽取同步关系型数据库，将数据文件的聚汇到TDFS的性能。 具体而言，对于结构化数据：现有业务零碎以及数据仓库中的数据，能够应用Sqoop或以文件的形式采纳T+1的形式接入到大数据平台。 对于实时数据，反对将实时数据接入Event Store音讯队列，并通过Slipstream组件做音讯实时研判解决、加工剖析，并将处理结果实时返回，以对接下层实时仪表盘等相干利用。 数据存储 通过对立的数据存储平台，对结构化、非结构化数据以及实时数据进行落地长久化，同时提供容错、多正本平安冗余等性能，保证数据的可靠性。 其中，结构化数据次要的起源为数据仓库，业务零碎为行内外围、信贷、网银等零碎。在理论应用中，因为实时查问数据类数据与离线剖析类数据有不同的业务需要，应依据具体的业务场景，将相应的数据长久化到不同的存储引擎当中。 数据加工 大数据平台将数据存储后，能够持续应用Inceptor做加工解决剖析，最终供下层应用程序查问检索。 查问局部，次要用于交互式的数据查问，典型业务如行内海量历史数据的查问，能够无效地将以前冷数据局部应用起来。 流式解决局部，流式解决引擎岂但能够用于实现数据的实时入库工作，而且能够用于数据的实时统计与解决，如基于工夫窗口的统计、基于规定的实时告警利用等。 离线剖析局部，离线剖析次要用于对时效性要求不高耗时较长的场景中。典型应用场景如报表的离线计算、数据离线导出、前期数据挖掘剖析的数据预处理等工作。 计划特点图片 星环科技为北京银行信用卡核心建设的新一代大数据平台，满足用户理论和将来的倒退需要，在以下四个方面获得成功经验： 搭建了根底数据平台架构。联合北京银行信用卡核心根底IT设施状况及所洽购的大数据产品，构建北京银行信用卡核心的大数据平台，解决上游零碎的批量或者实时数据，包含批量数据的计算、存储，权限管制、批量数据与上游利用的对接，实时数据的接入、计算和上游利用的对接等。 实现了数据的迁徙和同步模块。我的项目对以后贴源层数据、明细汇总层数据进行初始化全量迁徙及日常增量同步。针对贴源层和明细层批量历史和增量数据，制订不同的接入计划，在后续施行阶段，依据上游提供的不同字符集的文件进行转码、校验以及对表从新梳理，制订数据分层及存储策略，并将上游提供的源文件保留在大数据平台上。 建设了数据脱敏模块。我的项目次要是在大数据平台的关系型剖析引擎Inceptor中，通过udf函数对数据脱敏，依据具体的要求对姓名、身份证、手机号、卡号等字段进行遮蔽性脱敏、格式化脱敏和一致性脱敏。脱敏后，保障原数据格式不变，对于须要关联的字段保障仍旧能够关联等。 实现实时数据模块。搭建实时数据平台，对接发卡零碎，其中包含实时数据采集程序的开发、实时数据同步，实时利用开发。 我的项目满足发卡数据的实时数据的接入和数据处理，满足业务在流式计算方面的数据需要，包含Event Store监听发卡零碎的实时数据并接入、流式引擎计算。实时数据采集平台与卡核心内的决策引擎通过Event Store和Hyperbase实现实时数据的利用对接。 实现数据沙箱环境搭建。实现沙箱环境搭建、数据表权限管制以及资源分配。通过对贴源层和明细层数据的脱敏，将数据加载到星环科技Inceptor中，提供一个基于Inceptor构建的脱敏环境，为下层利用包含但不仅限于模型平台，提供一个沙箱环境。 通过为Inceptor创立角色并赋予不同角色查问、批改权限，进行权限管制，通过调配Inceptor计算配额(cpu个数、百分比)来实现资源的管制。 实现调度模块。基于北京银行内现有的调度工具，做相应的作业流以及作业设计，制订规范化的作业开发标准。次要是通过工具，批量生成对应的xml文件，进行接口导入，实现调度作业的批量开发。 利用价值图片 此前北京银行信用卡核心的数仓历史数据是存储在数据平台数据库中。而基于星环大数据根底平台TDH建设的新一代大数据中心既能反对传统数仓数据的迁徙，又能保障后续信用卡核心业务倒退的数据利用与剖析的需要。 为了更好地反对北京银行信用卡核心数仓业务，须要将数仓历史数据迁徙至北京银行信用卡核心大数据平台中星环科技大数据根底平台TDH。 因为北京银行信用卡核心的数据平台数据库服务器部署在北京，而TDH大数据平台服务器部署在西安，如果采纳在线迁徙的形式，因为迁徙数据量过大且网络带宽有余，迁徙工夫会很长，所以决定采纳离线迁徙的形式，即先将数仓数据从数据平台数据库中导出到存储服务器，落成数据文件，而后将服务器带到西安，间接连贯到TDH大数据集群，将数据文件上传到大数据平台的TDFS上。 同时，北京银行信用卡核心的数据源来源于数据平台数据库和贴源零碎，大数据平台提供数据接口，通过Event Store接入实时数据；通过数据接口全量或定时增量抽取同步关系型数据库将数据文件的聚汇到TDFS的性能。 目前北京银行信用卡核心曾经实现了80%以上零碎的数据入仓工作，提供报表、数据下发、上游利用反对等数据服务，反对北京银行数字化转型。

最近几个新入职的同学说被数据库，数据集市，数据仓库整的有点懵，不太分明它们之间的关系和区别。周末小编在买菜的过程中灵光一闪，决定从买菜这件小事来聊聊数据仓库。 当咱们想做饭时首先须要思考的就是想做的菜须要买什么资料，比方小炒肉，咱们须要青椒和猪肉。晚期的时候，咱们须要别离去蔬菜店买青椒，去肉铺买猪肉。这个过程咱们须要破费很多的工夫和精力，甚至有的时候跑了一大段路却发现店里没有我想买的货色，或者我买到了青椒，却发现肉铺没有肉卖了这种难堪的状况。起初逐步建设了农贸市场，由每个资料供货商供货，品种齐全，并依照肯定的规定摆放参差，咱们想要买什么菜依照指示牌就能够疾速地定位。 咱们能够把数据库比作一个个小店铺或者供货商，他们的强项在于事务处理，比方从农民伯伯手上去收买蔬菜，从屠宰厂零售猪肉等，将这些原材料汇总起来，至于怎么摆放供客户筛选，通过各种市场剖析去增长销量等不是他们善于的。数据库次要就是面向事务设计的，与ERP，CRM，OA等各类业务系统集成并实现业务过程数据的组织治理，他们解决的是根本的业务流程治理，通过数据的录入，删除，批改，查问及用户在业务零碎操作界面中做的增删改查操作，和业务零碎底层的数据库例如MySQL，Oracle，SQL Server实现数据的交互，数据也积淀在这些数据库中。 那聪慧的同学曾经晓得数据仓库其实就像“农贸市场”，把各种供货商手上的货源收集起来，依照肯定的规定摆放参差供客户筛选，同时能够通过整个农贸市场的销售经营状况进行一些粗疏的剖析，对整个市场有更好的理解，从而促销相应的洽购，销售策略等等。数据仓库是构建面向剖析的集成化数据环境，为企业提供决策反对，它出于剖析性报告和决策反对的目标而创立。 那什么是数据集市呢？数据集市能够比喻成各种专区，卖蔬菜农产品的，卖水产海鲜的，卖肉禽的等等。数据集市其实就是一个面向小型的部门或工作组级别的小型数据仓库，只专一于某一个方面的主题剖析。 数据仓库自身并不生产数据，数据来源于内部，并且凋谢给内部利用，这也是为什么叫仓库，不叫工厂的起因。例如农贸市场并不种植蔬菜、养殖各种水产禽类，而是从各供货商获取资料。数据集市能够从本人的数据源获取数据，也能够从数据仓库中获取某一主题的数据。 那从供货商到农贸市场的两头过程，其实就是所谓的“ETL”过程。ETL就是extract，Transform和load，指的是荡涤，转换和加载。咱们都晓得，供货商提供的货不是什么都要的，咱们要筛选出有价值的，滞销的种类，有些坏的，不陈腐的菜在进农贸市场的过程中就须要去除掉。而不同的供货商提供的货可能也存在一些一样的品种，那么在搬运到农贸市场中就须要做一些归类合并，依照更好的一种排列形式摆放参差供客户筛选。这个从供货商搬运，荡涤，转换，加载各种菜的过程就是ETL过程。 在这个过程中，还波及到ETL的形式和频率。比方水产海鲜，很多都是速冻空运过去的，一些需求量比拟小的比方澳龙可能几天才送一次，而一些蔬菜是人们日常须要的，大都是周边蔬菜大棚产的，就会由货车每天运输进农贸市场。 这些菜被运送到农贸市场后，会依据肯定的规定进行摆放让客户筛选。咱们能够依据不同的规定对这些菜进行治理，就像数据仓库的技术框架一样，咱们能够抉择个别的技术框架或者大数据技术框架，不同的抉择最终决定了咱们数据仓库的应用成果和投入老本。 因而，数据仓库的实质还是一个数据库，它将各个异构的数据源，数据库的数据对立治理起来，并且实现了相应数据的剔除，格局转换，最终依照一种正当的建模形式来实现源数据的组织模式的转变，以更好的反对前端的可视化剖析。 那数据仓库有什么价值呢？咱们先来说一个啤酒和尿布的故事。某超市货架上将啤酒与尿布放在一起售卖，这看似不相干的两个货色，为什么会放在一起售卖呢？原来在晚期的时候，该店面经理发现每周啤酒和尿布的销量都会有一次同比增长，但始终搞不清楚起因。起初商家通过对原始交易记录进行长期的详细分析后发现，很多年老的父亲在上班后给孩子买完尿布后，大都会顺便买一点本人爱喝的啤酒。于是该商家将尿布与啤酒摆放在一起售卖，通过它们的潜在关联性，互相促进销售。“啤酒与尿布”的故事一度成为营销界的神话。 从下面能够看出，数据仓库除了将各数据源抽取集成到一起为数据管理和使用提供方便外，还能够依照不同的主题，将不同品种的数据进行归类组织，从多维度、多角度挖掘出一些有价值的货色，为了企业的剖析和决策提供数据根据。而个别数据库次要是面向事务处理，对数据分析性能不佳。此外，通常一个公司的业务零碎会有很多，不同的业务零碎往往治理部门不同，地区不同，各个数据库系统之间是互相隔离的，无奈从这些不同零碎的数据之间挖掘出关联关系。因而基于这些个性，数据仓库可用于人工智能、机器学习、危险管制、无人驾驶，数据化经营、精准经营，广告精准投放等场景。 星环科技是国内当先的大数据根底软件公司，围绕数据的集成、存储、治理、建模、剖析、开掘和流通等数据全生命周期提供根底软件与服务，于2016年被国内出名剖析机构 Gartner 选入数据仓库及数据管理剖析魔力象限，位于远见者象限，在前瞻性维度上优于 Cloudera、Hortonworks 等美国支流大数据平台厂商，是Gartner 公布该魔力象限以来首个进入该魔力象限的中国公司。 Transwarp ArgoDB是星环科技面向数据分析型业务场景的分布式闪存数据库产品，次要用于构建离线数据仓库、实时数据仓库、数据集市等数据分析系统。2019年8月，ArgoDB成为寰球第四个通过TPC-DS基准测试并通过TPC官网审计的数据库产品。 基于星环科技ArgoDB的数据仓库解决方案，通过对数据的荡涤、治理、建模、治理、剖析，造成数据仓库，为业务人员和管理人员提供管理决策服务。联合星环科技事件存储库Event Store和实时流计算引擎构建实时数据仓库，能够高速接入实时音讯数据（吞吐量能够达到数百万记录/秒），或者从交易型数据库实时同步数据到ArgoDB，并对数据进行实时增删改查，以及高速的数据简单加工和统计分析。 基于星环科技ArgoDB的数据仓库解决方案个性：多模型数据库反对关系型、搜寻、文本、对象等数据模型 残缺的SQL反对反对残缺的SQL规范语法，兼容Oracle、IBM DB2、Teradata方言，兼容Oracle和DB2的存储过程，反对业务平滑迁徙 反对超大规模集群人造分布式架构，集群节点规模无下限，数据存储容量随节点规模线性扩容，可反对2000+节点集群 混合负载反对反对实时数据与混合负载，反对海量数据的离线批量解决、在线实时剖析和多维度的简单关联统计等性能 分布式事务保障反对残缺4种事务隔离级别，保障事务在分布式系统下失常运行，高吞吐的，确保数据强统一，高可用的事务保障 典型案例某农商行基于ArgoDB构建了新一代数据仓库，通过反对Oracle方言，极大升高了原先Oracle数据库业务数据和现有剖析型业务的迁徙老本。在剖析型业务方面以更低成本、更高性能残缺代替了传统Oracle数据仓库，确保剖析型业务与交易型业务的隔离。平台满足了行内包含历史明细数据查问、交易流水查问、实时交易大屏、大额交易揭示等十多个要害查问业务场景需要。针对各类剖析型业务的主动性能优化，保障了多用户高并发场景下的性能要求。联合实时流引擎Slipstream，将源数据库Oracle的增量数据以秒级延时疾速同步到ArgoDB数仓，尤其确保了对源零碎数据有删改的经常性调账退款业务数据能即时反映在剖析零碎中。平台基于实时落库的业务数据实现了多流水表多维度数据整合的交互式简单剖析能力，将本来基于Oracle的离线级剖析能力晋升到秒级的准实时级交互式剖析能力，为行内将来多种简单的剖析型业务利用的拓展与更高的实时性要求打下松软的技术根底。 数据仓库： https://www.transwarp.cn/solu...

本文目录： 一、前言 二、概念解析 数据仓库数据湖数据中台三、具体区别 数据仓库 VS 数据湖数据仓库 VS 数据中台总结四、湖仓一体 目前数据存储计划Data Lakehouse（湖仓一体）一、前言数字化转型浪潮卷起各种新老概念满天飞，数据湖、数据仓库、数据中台轮流在朋友圈刷屏，有人说“数据中台算个啥，数据湖才是趋势”，有人说“再见了数据湖、数据仓库，数据中台已成气象”…… 50000字详解数仓建设保姆级教程，涵盖离线和实时 企业还没推开数字化大门，先被各种概念绊了一脚。那么它们 3 者到底有啥区别？别急，先跟大家分享两个乏味的比喻。 1、图书馆VS地摊 如果把数据仓库比喻成“图书馆”，那么数据湖就是“地摊”。去图书馆借书（数据），书籍品质有保障，但你得等，等什么？等管理员先查到这本书属于哪个类目、在哪个架子上，你能力精准拿到本人想要的书；而地摊上没有人会给你把关，什么书都有，你本人翻找、随用随取，流程上比图书馆便捷多了，但大家找书的过程是没有教训可复用的，偶然多拿少拿咱们可能也不晓得。 2、升级版银行 假设数据仓库、数据湖、数据中台都是银行，能够提供现金、黄金等多种服务。过来大家进银行前都得先问门卫，外面每个门牌上的数字对应哪个服务呢？是现金还是黄金呢？而后推开对应的门把货色取出来。而有了“数据中台”这个银行，大家一进来就能看到标着“现金”、“黄金”汉字的窗口，高深莫测，你只须要走到窗口前，就有专人帮你办理。 以上两个例子不肯定全面，但根本能解释三者的优劣势。数据仓库具备规范性，但取数用数流程长；数据湖取数用数更实时、存储量大，但数据品质难以保障；数据中台能精准疾速地响应业务需要，离业务侧最近。 为了更清晰地区别三者，接下来咱们再来看看它们各自的定义以及利用区别。 二、概念解析1. 数据仓库数据仓库诞生于 1990 年，相对算得上是“老前辈”了，它是一个绝对具体的性能概念。目前对数据仓库的支流定义是位于多个数据库上的大容量存储库，它的作用在于存储大量的结构化数据，并能进行频繁和可反复的剖析，帮忙企业构建商业智能（BI）。 具体定义： 数据仓库(Data Warehouse)是一个面向主题的（Subject Oriented）、集成的（Integrated）、绝对稳固的（Non-Volatile）、反映历史变动的（Time Variant）数据汇合，用于反对管理决策和信息的全局共享。其次要性能是将组织透过资讯零碎之联机事务处理(OLTP)经久不息所累积的大量材料，透过数据仓库实践所特有的材料贮存架构，剖析出有价值的资讯。 所谓主题：是指用户应用数据仓库进行决策时所关怀的重点方面，如：支出、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务撑持零碎那样是依照业务性能进行组织的。所谓集成：是指数据仓库中的信息不是从各个业务零碎中简略抽取进去的，而是通过一系列加工、整顿和汇总的过程，因而数据仓库中的信息是对于整个企业的统一的全局信息。所谓随工夫变动：是指数据仓库内的信息并不只是反映企业以后的状态，而是记录了从过来某一时点到以后各个阶段的信息。通过这些信息，能够对企业的倒退历程和将来趋势做出定量分析和预测。数据仓库的作用： 数据仓库零碎的作用能实现跨业务条线、跨零碎的数据整合，为治理剖析和业务决策提供对立的数据反对。数据仓库可能从根本上帮忙你把公司的经营数据转化成为高价值的能够获取的信息（或常识），并且在失当的时候通过失当的形式把失当的信息传递给失当的人。 是面向企业中、高级治理进行业务剖析和绩效考核的数据整合、剖析和展示的工具；是次要用于历史性、综合性和深层次数据分析；数据起源是ERP（例:SAP）零碎或其余业务零碎；可能提供灵便、直观、简洁和易于操作的多维查问剖析;不是日常交易操作系统，不能间接产生交易数据；实时数仓 实时数仓和离线数仓十分的像，诞生的背景次要是近几年企业对于数据服务的实时性需要日益增多。外面的数据模型也会像中台一样分好几层：ODS 、CDM、ADS。但整体对于实时性要求极高，因而个别存储会思考采纳Kafka这种log base的MQ，而计算引擎会采纳Flink这种流计算引擎。 2. 数据湖数据湖是一种一直演进中、可扩大的大数据存储、解决、剖析的基础设施，它就像一个大型仓库存储企业多样化原始数据以数据为导向，实现任意起源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式解决与全生命周期治理。领有弱小的信息处理能力和解决简直有限的并发工作或工作的能力。 数据湖从企业的多个数据源获取原始数据，数据可能是任意类型的信息，从结构化数据到齐全非结构化数据，并通过与各类内部异构数据源的交互集成，反对各类企业级利用。联合先进的数据迷信与机器学习技术，能帮忙企业构建更多优化后的经营模型，也能为企业提供其余能力，如预测剖析、举荐模型等，这些模型能刺激企业能力的后续增长。 进入互联网时代，有两个最重要的变动。 一个是数据规模前所未有，一个胜利的互联网产品日活能够过亿，就像你熟知的头条、抖音、快手、网易云音乐，每天产生几千亿的用户行为。传统数据仓库难于扩大，根本无法承载如此规模的海量数据。 另一个是数据类型变得异构化，互联网时代的数据除了来自业务数据库的结构化数据，还有来自 App、Web 的前端埋点数据，或者业务服务器的后端埋点日志，这些数据个别都是半结构化，甚至无构造的。传统数据仓库对数据模型有严格的要求，在数据导入到数据仓库前，数据模型就必须当时定义好，数据必须依照模型设计存储。 所以，数据规模和数据类型的限度，导致传统数据仓库无奈撑持互联网时代的商业智能。 05年的时候，Hadoop诞生了。 Hadoop 相比传统数据仓库次要有两个劣势： 齐全分布式，易于扩大，能够应用价格低廉的机器堆出一个计算、存储能力很强的集群，满足海量数据的解决要求；弱化数据格式，数据被集成到 Hadoop 之后，能够不保留任何数据格式，数据模型与数据存储拆散，数据（蕴含了原始数据）在被应用的时候，能够依照不同的模型读取，满足异构数据灵便剖析的需要。而数仓更加关注能够作为事实根据的数据。随着Hadoop与对象存储的成熟，数据湖的概念在10年被提出：数据湖（Data Lake）是一个以原始格局存储数据的存储库或零碎（这意味着数据湖的底层不应该与任何存储耦合）。 对应的来说，如果数据湖没有被治理好（不足元数据、定义数据源、制订数据拜访策略和安全策略，并挪动数据、编制数据目录），则会变成数据沼泽。 而从产品状态上来说，数仓往往是独立标准化的产品。而数据湖更像是一种架构领导——须要配合一系列的周边工具，来实现业务须要的数据湖。 3. 数据中台大规模数据的利用，也逐步裸露呈现一些问题。 业务倒退后期，为了疾速实现业务的需要，烟囱式的开发导致企业不同业务线，甚至雷同业务线的不同利用之间，数据都是割裂的。两个数据利用的雷同指标，展现的后果不统一，导致经营对数据的信任度降落。如果你是经营，当你想看一下商品的销售额，发现两个报表上，都叫销售额的指标呈现了两个值，你的感触如何? 你第一反馈必定是数据算错了，你不敢持续应用这个数据了。 数据割裂的另外一个问题，就是大量的反复计算、开发，导致的研发效率的节约，计算、存储资源的节约，大数据的利用老本越来越高。 如果你是经营，当你想要一个数据的时候，开发通知你至多须要一周，你必定想是不是太慢了，能不能再快一点儿？如果你是数据开发，当面对大量的需要的时候，你必定是在埋怨，需要太多，人太少，活干不完。如果你是一个企业的老板，当你看到每个月的账单成指数级增长的时候，你必定感觉这也太贵了，能不能再省一点，要不吃不消了。这些问题的本源在于，数据无奈共享。2016 年，阿里巴巴率先提出了“数据中台”的口号。数据中台的外围，是防止数据的反复计算，通过数据服务化，进步数据的共享能力，赋能数据利用。之前，数据是要啥没啥，两头数据难于共享，无奈积攒。当初建设数据中台之后，要啥有啥，数据利用的研发速度不再受限于数据开发的速度，一夜之间，咱们就能够依据场景，孵化出很多数据利用，这些利用让数据产生价值。 数据中台样板 在建设中台的过程中，个别强调这样几个重点： 效率、品质和老本是决定数据是否撑持好业务的要害，构建数据中台的指标就是要实现高效率、高质量、低成本。数据只加工一次是建设数据中台的外围，实质上是要实现公共计算逻辑的下沉和复用。如果你的企业领有 3 个以上的数据利用场景，数据产品还在一直研发和更新，你必须要认真思考建设数据中台。那么接下来就看一下阿里巴巴对于数据中台的实际。 ...

简介：本文将会从阿里巴巴双11场景登程，剖析实时数仓面临的高可用挑战以及针对性设计。 2021年阿里巴巴双11完满落下为帷幕，对消费者来说是一场购物盛宴，对背地的业务撑持技术人来说，更是一场年度大考。在这场大考中，一站式实时数仓Hologres以每秒11.2亿条的高速写入，和每秒1.1亿次的查问峰值（蕴含点查和OLAP查问），交出了称心的答卷，稳固高效地撑持了阿里巴巴双11外围利用场景。 这是一站式实时数仓Hologres诞生的第5年，也是撑持阿里巴巴双11外围场景的第4年。这也证实实时数仓技术曾经开始从幕后走到台前，撑持起更多的在线生产零碎，并在性能、稳定性、高可用性等方面禁受住了严苛的考验。 本文将会从阿里巴巴双11场景登程，剖析实时数仓面临的高可用挑战以及针对性设计。 可用性、老本、复杂度的综合挑战传统上，实时数仓（数据仓库）是一个非生产零碎，次要面向外部客户，撑持实时大屏、实时报表等场景。用户对它的稳定性、可用性的要求相较于订单、购物车这样的生产零碎要弱很多，只有能持续应用，即便实时数仓短暂不可用或者有显著稳定，影响也不是很大。 而随着实时数仓开始对外提供服务，业务对系统的可用性、稳定性都提出了更高更严苛的要求。特地是如果提供的是to C的服务，那要求就更高了。 举几个Hologres被用在阿里生产零碎中的例子： 阿里的CCO（Customer Chief Officer）通过阿里小蜜来向C端消费者提供查问服务。阿里妈妈为广告主（B端）提供广告圈选服务。达摩院无人车包裹配送服务。...这些零碎的最大特点是他们都是生产零碎，如果零碎不稳固或者不可用，那么影响会十分大。 具体到双11这样的极其场景，在流量洪峰下要做好生产高服务质量、达到高可用对任何零碎都是一件极具挑战的事。传统分布式系统是通过正本和隔离机制来实现可用性和一致性，而要实现生产可用的高可用也须要面临肯定的取舍和挑战： 面向流量洪峰时的可扩大能力零碎因意外或者故障宕机时的疾速恢复能力主备切换时的数据一致性问题保障高性能的同时资源隔离能力多正本隔离带来的资源老本问题.......通过本文，咱们将会介绍，一站式实时数仓Hologers的高可用架构设计和实际，从而达到低成本、可扩大、高可用的生产服务能力。 Hologres高可用架构设计1. 计算存储拆散架构进步零碎扩大灵活性实时数仓技术不论是面向剖析型场景还是服务型场景，所解决的数据量级、场景复杂度都远比传统数据库要高，尤其是互联网、电商等行业，流动促销多，大促和日常所解决的流量齐全不一样，这就十分考验零碎的资源程度扩大能力。 在传统的分布式系统中，罕用的存储计算架构有如下三种： Shared Disk/Storage （共享存储）：有一个分布式的存储集群，每个计算节点像拜访单机数据一样拜访这个共享存储上的数据；这种架构的存储层能够比拟不便的扩大，然而计算节点须要引入分布式协调机制保证数据同步和一致性，因而计算节点的可扩展性有一个下限。Shared Nothing：每个计算节点本人挂载存储，一个节点只能解决一个分片的数据，节点之间能够通信，最终有一个汇总节点把数据进行汇总。这种架构能比拟不便的扩大，然而它的毛病是节点failover须要期待数据加载实现之后能力提供服务；并且存储和计算须要同时扩容，不够灵便。扩容后，有漫长的数据rebalance过程。Storage Disaggregation（存储计算拆散架构）：存储和Shared Storage相似，有一个分布式的共享存储集群，计算层解决数据的模式和Shared Nothing相似，数据是分片的，每个shard只解决本人所在分片的数据，每个计算节点还能够有本地缓存。 这种存储计算拆散的架构益处在于： 一致性解决简略：计算层只须要保障同一时刻只有一个计算节点写入同一分片的数据。扩展性更灵便：计算和存储能够离开扩大，计算不够扩计算节点，存储不够扩存储节点。这样在大促等场景上会非常灵活。计算资源不够了，马上扩容计算就好了，不须要像Shared Nothing那样做耗时耗力的数据rebalance；也不会呈现Shared Nothing那样，呈现单机的存储容量瓶颈。计算节点故障复原快：计算节点产生failover之后，数据能够按需从分布式的共享存储异步拉取。因而，failover的速度十分快。在架构上，Hologres采纳的是第3种存储计算拆散架构，Hologres的存储应用的是阿里自研的Pangu分布式文件系统（相似HDFS）。用户能够依据业务需要进行弹性扩缩容，轻松应答在线零碎不同的流量峰值。 2.多状态Replication解决数据读写拆散Replication（复制）是实现高可用的必备技术，通过不同状态的Replication设计，疾速将数据在节点间、集群间进行复制，实现隔离和SLA保障。 Hologers同时反对了逻辑Replication和物理Replication，上面将会针对Hologres的Replication性能做具体介绍。 1）基于Binlog的逻辑Replication 相似于传统数据库MySQL中的Binlog概念，在Hologres中，Binlog用来记录数据库中表数据的批改记录，比方Insert/Delete/Update的操作，次要利用场景包含： 数据实时复制、同步场景，典型的场景就是把一张Hologres的行存表复制成一张列存表，行存反对点查点写，列存反对多维分析型需要，同步的逻辑通常由Flink撑持。这个是Hologres在V1.1版本之前的一种典型用法。在Hologres 1.1中反对了行列共存表后，能够一张表满足行存和列存两种需要。实现事件的全链路驱动，通过Flink生产Hologres Binlog，实现事件驱动的加工开发，实现ODS向DWD，DWD向DWS等的全实时加工作业。 在Hologres中，逻辑Replication依赖Binlog实现，产生变更的表作为Publication公布变更事件，加工逻辑解决后写入Subscription侧。用户能够订阅一个表的Binlog转成Record，写入到另外一张表里，实现逻辑上的复制性能。这种做法能够人造做到不同Workload的隔离，然而它有两个问题：它是一个最终一致性的模型，很难做到强统一；另一个是它耗费了两份资源，应用两份存储，并且写入链路的资源也得有两份。 因而Hologres也实现了物理Replication。 2）物理Replication 在Hologres中，物理Replication是基于WAL log的复制，咱们能够把存储引擎看成是状态机，WAL log是这个状态机的输出。当咱们要对某个Shard做Replication的时候，咱们会起一个Follower Shard读取以后最新的WAL log进行回放（replay），同时Leader Shard又有新的WAL产生，Follower Shard会从Leader Shard订阅最新的WAL，一直的回放，从而达到和Leader Shard统一的状态。如果须要保障Follower Shard上的可见性，咱们能够在读申请中加一个强统一的选项，问一下Follower Shard和Leader Shard之间WAL log的回放差距，等补齐差距后再返回查问后果。 Follower Shard回放WAL log的过程中，对WAL log中指向的数据文件能够进行复制。也能够只进行援用，其中复制的形式称为非共享存储模式，援用的形式称为共享存储模式。 基于此，Hologres实现了3种状态的物理Replication： 1.单实例多正本：一个实例内采纳Shard级多正本机制，可用来实现跨过程高可用，读写拆散，同时因为正本可动静减少，能轻松反对高并发的读。 2.多实例读写拆散：不同的实例之间共享一份存储，实现计算跨机房高可用，通常用于读写拆散场景，并反对高并发的读场景 3.多实例容灾：多个实例之间不共享存储，实现计算和存储服务的跨机房高可用，反对读写拆散，读的高并发，版本的热降级和存储系统的迁徙等性能 单实例多正本Hologres数据分片单元是Shard，Shard能够有多个正本，然而存储只有一份。平时，查问流量能够被各个正本均摊，从而实现高QPS。当某一个正本failover当前，流量能够疾速被导到其余正本。并且Shard的故障复原十分轻量，只需回放局部WAL，没有数据的复制。基于单实例内多正本机制，能够很不便的实现计算的可扩展性，并疾速解决物理机单机failover问题。 利用场景： 单实例内的查问高可用：当一个Shard所在Worker产生故障时，能够通过前端阶段的重试操作，将申请重定向到正本Shard所在Worker，从而利用异样无感知。通过负载均摊，实现更高吞吐：同一份数据由多个Shard独特对外提供服务，不同的查问路由到不同的Shard所在节点，从而实现负载在多个Shard间的平衡，QPS能够显著晋升，对于每次查问只拜访确定Shard的场景（例如点查场景）晋升显著。 机器故障疾速Failover：从Hologres V1.1版本开始，采纳全新复原机制，Shard复原速度在一分钟以内，可用性进一步加强。 多实例读写拆散和单实例内多正本的Replication相比，跨实例的Replication实现了Meta的物理复制。 Hologres 在V1.1版本，反对了共享存储的多实例部署计划。在该计划中，主实例具备残缺能力，数据可读可写，权限、零碎参数可配置，而子实例处于只读状态，所有的变更都通过主实例实现，实例之间共享一份数据存储，实例间数据异步实时同步。 利用场景： 1.读写拆散：这个计划实现了残缺的读写拆散性能，保障不同业务场景的SLA，在高吞吐的数据写入和简单的架构作业、OLAP、AdHoc查问、线上服务等场景中，负载之间物理上齐全隔离，不会因写入产生查问的抖动。 ...

@TOC 数仓笔记 数据仓库和数据集市详解：ODS、DW、DWD、DWM、DWS、ADS 尚硅谷数仓实战之1我的项目需要及架构设计 尚硅谷数仓实战之2数仓分层+维度建模 尚硅谷数仓实战之3数仓搭建 尚硅谷数据仓库4.0视频教程 B站中转：2021新版电商数仓V4.0丨大数据数据仓库我的项目实战百度网盘：https://pan.baidu.com/s/1FGUb... ，提取码：yyds 阿里云盘：https://www.aliyundrive.com/s... ，提取码：335o第4章 数仓搭建-ODS层1）保持数据原貌不做任何批改，起到备份数据的作用。 2）数据采纳LZO压缩，缩小磁盘存储空间。100G数据能够压缩到10G以内。 3）创立分区表，避免后续的全表扫描，在企业开发中大量应用分区表。 4）创立内部表。在企业开发中，除了本人用的长期表，创立外部表外，绝大多数场景都是创立内部表。 4.2 ODS层（业务数据）ODS层业务表分区规划如下 ODS层业务表数据装载思路如下 4.2.1 流动信息表DROP TABLE IF EXISTS ods_activity_info;CREATE EXTERNAL TABLE ods_activity_info( `id` STRING COMMENT '编号', `activity_name` STRING COMMENT '流动名称', `activity_type` STRING COMMENT '流动类型', `start_time` STRING COMMENT '开始工夫', `end_time` STRING COMMENT '完结工夫', `create_time` STRING COMMENT '创立工夫') COMMENT '流动信息表'PARTITIONED BY (`dt` STRING)ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'STORED AS INPUTFORMAT 'com.hadoop.mapred.DeprecatedLzoTextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'LOCATION '/warehouse/gmall/ods/ods_activity_info/';第5章 数仓搭建-DIM层5.1 商品维度表（全量）1.建表语句 ...

@TOC 数仓笔记 数据仓库和数据集市详解：ODS、DW、DWD、DWM、DWS、ADS 尚硅谷数仓实战之1我的项目需要及架构设计 尚硅谷数仓实战之2数仓分层+维度建模 尚硅谷数仓实战之3数仓搭建 尚硅谷数据仓库4.0视频教程 B站中转：2021新版电商数仓V4.0丨大数据数据仓库我的项目实战百度网盘：https://pan.baidu.com/s/1FGUb... ，提取码：yyds 阿里云盘：https://www.aliyundrive.com/s... ，提取码：335o第1章 数仓分层1.1 为什么要分层 1.2数据集市与数据仓库概念 1.3 数仓命名标准1.3.1 表命名Ø ODS层命名为ods_表名 Ø DIM层命名为dim_表名 Ø DWD层命名为dwd_表名 Ø DWS层命名为dws_表名 Ø DWT层命名为dwt_表名 Ø ADS层命名为ads_表名 Ø 长期表命名为tmp_表名 1.3.2 脚本命名Ø 数据源_to_指标_db/log.sh Ø 用户行为脚本以log为后缀；业务数据脚本以db为后缀。 1.3.3 表字段类型Ø 数量类型为bigint Ø 金额类型为decimal(16, 2)，示意：16位有效数字，其中小数局部2位 Ø 字符串(名字，形容信息等)类型为string Ø 主键外键类型为string Ø 工夫戳类型为bigint 第2章 数仓实践2.1 范式实践2.1.1 范式概念1）定义 数据建模必须遵循肯定的规定，在关系建模中，这种规定就是范式。 2）目标 采纳范式，能够升高数据的冗余性。 为什么要升高数据冗余性？ （1）十几年前，磁盘很贵，为了缩小磁盘存储。 （2）以前没有分布式系统，都是单机，只能减少磁盘，磁盘个数也是无限的 （3）一次批改，须要批改多个表，很难保证数据一致性 3）毛病 范式的毛病是获取数据时，须要通过Join拼接出最初的数据。 4）分类 目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。 2.1.2 函数依赖 2.1.3 三范式辨别 2.2 关系建模与维度建模关系建模和维度建模是两种数据仓库的建模技术。关系建模由Bill Inmon所提倡，维度建模由Ralph Kimball所提倡。 ...

简介： Delta Lake 和 Hudi 是风行的凋谢格局的存储层，为数据湖同时提供流式和批处理的操作，这容许咱们在数据湖上间接运行 BI 等利用，让数据分析师能够即时查问新的实时数据，从而对您的业务产生即时的洞察。MaxCompute 在湖仓一体架构中，通过反对 Delta Lake 和 Hudi 在数据湖中提供数据仓库性能。 本文作者 孟硕 阿里云智能 产品专家 直播视频请点击 直播观看 一、最佳实际背景整个最佳实际是基于MaxCompute的湖仓一体架构，模仿公司应用场景。比方公司 A 应用云上关系型数据库 RDS 作为本人的业务库，同时应用阿里云 EMR 零碎做日志数据采集。将数据会集到云上对象存储 OSS 上，引入了数据湖常会用的存储机制 Delta Lake 和 Hudi 为数据湖提供流解决、批处理能力。通过 MaxCompute 查问到实时数据，即时洞察业务数据变动。 整个场景demo的架构是，云上EMR产生的实时变动的数据，包含在线数据库RDS，通过数据入湖，而后实时的把数据变动体现在归档的OSS 上。同时MaxCompute跟其余引擎一起剖析OSS上的数据。 湖仓一体架构：异构数据平台交融 因为企业外部会有很多业务线，不同的部门，因为自身业务的需要及员工的技术栈几个方面的起因，导致采纳的数据架构不一样，数据平台也不一样。技术架构有Hadoop技术体系，也有云上全托管架构，所以造成不同的部门对技术架构，应用的技术平台不一样，也造成了数据割裂的状况。湖仓一体就是帮忙企业把异构数据平台做一个买通，底层数据能够互相拜访，两头元数据层也能够做到相互透视，数据能够做到自在流动。数据湖局部不只是反对EMR，也反对ESC Hadoop和云下IDC Hadoop。其中MaxCompute数据仓库也能够和数据湖EMR做一个数据买通，在用MaxCompute跟联播数据源做一个联播查问，这样能够把所有的数据在MaxCompute中做一个汇总。比方有三张表，在RDS和Hive中，共事MaxCompute里有大量事实表，如果需要是对这个三个表做一个联结查问，通过这个架构，能够很不便的做到这一点。 更快的业务洞察 DataWorks 自助开明湖仓一体：5分钟买通异构数据平台（Hadoop/ DLF+OSS ）更宽泛的生态对接反对对接阿里云云原生数据湖构建（DLF）反对查问 DeltaLake、Hudi 格局反对对接更多内部联邦数据源 Hologres （RDS、HBaseUpcoming！ ）更高的性能 智能 Cache 实现 OSS/ HDFS 数据拜访减速湖数据查问减速更好的综合数据开发与治理 跨引擎开发和调度对立湖/仓数据开发体验对立湖/仓全局资产治理 湖仓一体的架构 首先看右侧局部，是跟OSS和DLF侧的买通，因为在OSS 上咱们归档大量的半结构化和结构化的数据。有关系型数据库，有nosql数据库，能够通过DLF组件把OSS上的元数据爬取出来。相比于在MaxCompute上创立OSS表面拜访OSS数据，当初通过DLF对立自动识别OSS schema，MaxCompute间接映射这种形式，会更不便一些。一些数据的更新，schema的变更，DLF也能够自动识别到。同时DLF外面有用户权限治理，后续会陆续上线。也就是说对于OSS对接的引擎，对立的数据拜访权限会收敛到DLF里。 左侧是对Hadoop生态系统的买通，Hadoop包含阿里云半托管的EMR，开源的on ECS和IDC Hadoop，也蕴含支流的发行版CDH，也都能够做买通。下方再加上联邦数据源。通过MaxCompute能够连贯到各种各样的云上数据源，通过上传DataWorks做对立的开发和治理，以及数据治理。 这样就有一个全域数据资产视图，开发工作数据也能联通，元数据也能投射到DataWorks之上。这就是整个湖仓一体的架构。 ...

摘要：GaussDB(DWS)反对的MERGE INTO性能，能够同时进行大数据量的更新与插入。对于数据仓库是一项十分重要的技术。本文分享自华为云社区《一招教你如何高效批量导入与更新数据》，原文作者：acydy。 前言如果有一张表，咱们既想对它更新，又想对它插入应该如何操作？ 能够应用UPDATE和INSERT实现你的指标。 如果你的数据量很大，想尽快实现工作执行，可否有其余计划？那肯定不要错过GaussDB(DWS)的MERGE INTO性能。 MERGE INTO 概念MERGE INTO是SQL 2003引入的规范。 If a table T, as well as being updatable, is insertable-into, then rows can be inserted into it (subject to applicable Access Rules and Conformance Rules). The primary effect of an <insert statement> on T is to insert into T each of the zero or more rows contained in a specified table. The primary effect of a <merge statement> on T is to replace zero or more rows in T with specified rows and/or to insert into T zero or more specified rows, depending on the result of a <search condition> and on whether one or both of <merge when matched clause> and <merge when not matched clause> are specified.一张表在一条语句外面既能够被更新，也能够被插入。是否被更新还是插入取决于search condition的后果和指定的merge when matched clause（当condition匹配时做什么操作）和merge when not matched clause（当condition不匹配时做什么操作）语法。 ...

摘要：大规模分布式系统中的故障无奈防止。当DN产生单点故障时，复原伎俩有哪些，又是如何复原的，本节重点介绍操作gs_ctl build是如何修复DN单点故障的。本文分享自华为云社区《华为云数仓备机DN重建，疾速修复DN单点故障!》，原文作者：welblupen。 1. 技术背景GaussDB(DWS)的DN高可用架构为主、备、从备架构。即在分布式环境中，残缺的集群数据采纳分片技术散布在多个DN组上，每组DN承当一个数据分片，包含：一个主DN、一个备DN和一个从备DN。主和备各有一份残缺的数据，从备上个别不存储数据，仅在备机故障时做数据的暂存，当备机故障复原之后，为了放弃集群数据的一致性，须要备机连贯主机进行数据和xlog日志的拷贝。 2. 备机DN须要进行重建的场景2.1. 主机产生单点故障之后，备机进行failover升主，原主降备，集群降级；待原主故障复原后，可能会导致主备机WAL日志CRC校验失败，CM零碎检测到该状态后会主动通过备机重建的形式进行主动备机重建。2.2. 备机产生单点故障之后，备机状态变为unknown，集群降级，待备机故障复原之后，需须要进行备机重建操作同主机同步数据。3. 备机DN重建的操作分类3.1. 增量重建： gs_ctl build -b incremental -Z datanode用处：增量build可修复常见的主机或实例故障导致的备机日志分叉问题，也可修复局部数据文件失落的问题，在重建过程中产生主机异样，能够手动回退有损复原。 过程：获取差别文件：通过解析Xlog日志获取主备DN差别文件备份与复原：对主备差别文件进行严格进行原子化复原和备份，过程中出错可复原，排除谬误后，可再次调用重入传输文件：由备机创立指定（1-16）个线程从主机拉取差别文件实现增量重建期待xlog日志落盘剖析：增量重建是，依据Xlog日志计算主备DN差别文件，将文件发送给备DN,在备机数据没有损坏的状况下疾速进行增量重建，代价较小。 3.2. 全量重建： gs_ctl build -b full -Z datanode用处：备机全量重建可能修复绝大多数数据和日志损坏或失落的场景，但修复工夫比增量build更长 过程：获取差别文件：应用根据硬件调优的CRC-32C系列算法获取主DN上相应文件的CRC校验值，同时本地也进行对应操作，二者比拟取得差别文件列表备份与复原：默认无原子化，但会尝试进行原子化复原，疏忽复原后果成败传输文件：由备机创立指定（1-16）个线程从主机拉取差别文件实现增量重建期待xlog日志落盘剖析：全量重建是一种以主DN文件为基准，备DN文件同其进行校验，如果备DN文件的某个文件块校验不统一，则主机将此文件块发给备DN。与全量清理重建相比拟，拷贝的数据量和WAL日志量都更少，代价中等。 3.3. 全量清理重建： gs_ctl build -b fullcleanup -Z datanode用处：与full模式区别为：同步前须要清理DN主机的数据目录。可能修复绝大多数数据和日志损坏或失落的场景，但修复工夫比其余模式更长 过程：清理备机数据文件：备机清空数据目录，保留配置文件主机向备机传输全量镜像：主机应用单个线程将本人的数据目录除了配置文件外，全副发给备机实现全量重建期待xlog日志落盘剖析：全量清理重建是备机清空数据目录，保留配置文件，向主机发送全量重建申请，主机将本人的数据目录除了配置文件外，全副发给备机，重建后启动备机，代价较大。 4. 总结备机DN重建性能次要目标是单点故障修复，备机重建形式依照实现分为全量重建，全量清理重建和增量重建，均和主DN进行交互。当DN呈现单点故障时，操作人员应该依据理论损坏水平和资源耗费抉择适合的重建办法进行备机的数据重建。 想理解GuassDB(DWS)更多信息，欢送微信搜寻“GaussDB DWS”关注微信公众号，和您分享最新最全的PB级数仓黑科技~ 点击关注，第一工夫理解华为云陈腐技术~

摘要：数据库智能运维（DMS）是GaussDB(DWS) 为客户数据库疾速、稳固运行提供保驾护航的能力，对业务数据库所应用磁盘、网络、OS指标数据，集群运行要害性能指标进行收集、监控、剖析。通过综合收集到的多种类型数据对数据库主机、实例、业务SQL进行诊断，及时裸露数据库中要害故障及性能问题，领导客户进行优化解决。本文分享自华为云社区《【云图说】第210期 数据仓库服务的“千里眼、顺风耳” ——数据库智能运维》，原文作者：阅识风波。 随着云时代的到来，云数据库逐步托管了客户的数据存储服务，云化将所有沉重的IT运维工作都集中在云后盾治理了起来，从而把客户从业余、简单、沉重的数据中心运维流动中解放出来，使客户可能更加专一于其外围业务。数据库智能运维（DMS）通过可视化的伎俩以人类便于了解的图表模式，将重点数据以图形化的伎俩展现给客户，从而显著的升高了数据库运维的门槛，进步了数据库运维的效率。 点击下方“理解更多”，华为云数据仓库服务等着您！ 点击关注，第一工夫理解华为云陈腐技术~

摘要：避免数据泄露能够有两种技术门路。一是权限治理，采纳最小化受权准则对应用数据的用户和应用程序受权。另一种是数据加密，包含应用SQL函数加密和通明加密。本文分享自华为云社区《【平安无小事】你应该晓得的数仓平安——加密函数》，原文作者：zhangkunhn。 前言最近遇到一个客户场景，波及共享schema的权限问题。场景简略能够形容为：一些用户是数据的生产方，须要在schema中创立表并写入数据；另一些用户是数据的生产方，读取schema中的数据做剖析。对于该schema权限治理的一种实现办法是数据生产方在每次创立新表后告知管理员用户应用grant select on all tables in schema语法来授予生产方权限。这种办法有肯定的局限性。如果生产方在schema上面又创立了一些新表，为了受权生产方应用这些新表还须要告知管理员用户再次应用grant select on all tables in schema来受权。有没有简略的应答计划？答案是必定的，能够应用Alter default privilege。Alter default privilege用于未来创立的对象的权限的授予或回收。 语法介绍 ALTER DEFAULT PRIVILEGES [ FOR { ROLE | USER } target_role [, ...] ] [ IN SCHEMA schema_name [, ...] ] abbreviated_grant_or_revoke;其中abbreviated_grant_or_revoke子句用于指定对哪些对象进行受权或回收权限。对表受权语法是： GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES } [, ...] | ALL [ PRIVILEGES ] } ON TABLES TO { [ GROUP ] role_name | PUBLIC } [, ...]参数阐明target_role已有角色的名称。如果省略FOR ROLE/USER，则缺省值为以后角色/用户。 ...

数据仓库是数据挖掘技术的要害和根底。数据挖掘技术是在已有数据的根底上，帮忙用户了解现有的信息，并且在以后信息的根底上，对将来的企业情况作出预测，在数据仓库的根底上进行数据挖掘，能够针对整个企业的倒退情况和将来前景作出较为残缺、正当、精确的剖析和预测。 数据仓库的重要作用在整个数据分析的过程中显而易见。然而往往因为要解决的数据量过大，数据仓库的搭建咱们通常都交给BI工具来实现。当初国内有许多数据仓库软件都做的很不错的，当初小编就以Smartbi为例来具体阐明一下。 1、实用的数据采集 Smartbi提供了弱小的数据采集性能，既缩小了开发人员的工作量，又能够满足业务人员的数据采集需要。 Smartbi提供Excel数据批量导入性能，可能简便的将Excel数据，一键上传、数据入库的一种形式导入数据库；通过回写权限和规定定义，实现用Excel设计采集表单、Web填报数据，配置灵便便捷，反对在报表上间接进行数据填报，反对校验公式进行数据校验，反对多人填报，反对会签及分支的流程审批。 2、丰盛的数据连贯 反对间接上传Excel、CSV、TXT文件、数据分析包导入到高速缓存库或关系数据源，反对导入的指标关系数据源有：MySQL、Oracle、DB2_V9、MSSQL；反对接入Java数据源；Smartbi反对各种大数据库比方有：Presto+Hive、星环、Vertica、Infobright等等。 3、弱小的跨库整合 目前反对做跨库的数据源类型包含：高速缓存库、Hadoop_Hive、星环、Vertica、CH、Greenplum、Infobright、Oracle、DB2 V9、MySQL、MS SQL Server、Spark SQL、Teradata_v12、Informix、IMPALA、PostgreSQL。 数据采集、数据连贯与跨库整合，除此之外，Smartbi还有更多其余弱小的性能，不仅在数据挖掘这方面做的特地好，在数据分析、数据可视化和数据管控等层面，也取得了业界的统一好评。

一、数据仓库是什么？ 数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据反对的策略汇合。它是单个数据存储，出于剖析性报告和决策反对目标而创立。 为须要业务智能的企业，提供领导业务流程改良、监督工夫、老本、品质以及管制。 二、数据仓库有哪些特点？ 1、效率高 数据仓库的剖析数据个别分为日、周、月、季、年等，能够看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。 2、扩展性 之所以有的大型数据仓库零碎架构设计简单，是因为思考到了将来3-5年的扩展性，这样的话，将来不必太快花钱去重建数据仓库零碎，就能很稳固运行。次要体现在数据建模的合理性，数据仓库计划中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。 3、面向主题 操作型数据库的数据组织面向事务处理工作，各个业务零碎之间各自拆散，而数据仓库中的数据是依照肯定的主题域进行组织的。主题是与传统数据库的面向利用绝对应的，是一个抽象概念，是在较高层次上将企业信息系统中的数据综合、归类并进行剖析利用的形象。每一个主题对应一个宏观的剖析畛域。数据仓库排除对于决策无用的数据，提供特定主题的扼要视图。 4、集成性 面向事务处理的操作型数据库通常与某些特定的利用相干，数据库之间互相独立，并且往往是异构的。而数据仓库中的数据是在对原有扩散的数据库数据抽取、清理的根底上通过零碎加工、汇总和整顿失去的，必须打消源数据中的不一致性，以保障数据仓库内的信息是对于整个企业的统一的全局信息。 5、反映变动 操作型数据库次要关怀以后某一个时间段内的数据，而数据仓库中的数据通常蕴含历史信息，零碎记录了企业从过来某一时点（如开始利用数据仓库的时点）到目前的各个阶段的信息，通过这些信息，能够对企业的倒退历程和将来趋势做出定量分析和预测。 三、数据仓库的一些常见意识误区 1、数据仓库的建设是一次性工程。数据仓库实际上须要每年、每月、每周甚至每日都要进行更新，不是说一次性录入了历史的数据就能够实现的工作。 2、数据仓库是一个很大的仓库。其实掂量一个数据仓库的品质如何，并不是用数据量来掂量的，有一些优质的数据仓库我的项目，数据量并不是很大。 3、只有数据仓库建设和应用了，问题就解决了。 4、聚焦于外部的档案型数据，而漠视了内部数据以及图象、音频和视频文件的潜在价值。 5、数据仓库是将所有的业务数据存在一起的。数据仓库的一个指标是将扩散的业务整合在一起的，但它往往是有目的地按剖析需去施行的，并不是将全副的业务数据通通都集成在一起。

摘要：本文通过介绍双集群的架构、log构造、剖析步骤来介绍双集群容灾的问题分析方法。本文分享自华为云社区《从原理到实际，手把手带你轻松get数仓双集群容灾》，原文作者：Puyol 。 双集群原理GaussDB(DWS) 的容灾计划是一个双集群同步的架构，即两套独立集群定期同步数据以达到容这的目标。目前数据同步的形式是通过roach(GaussDB(DWS)备份、复原工具)定期做增量备份和复原同步。双集群框架是一个简单的分布式系统，在呈现问题时，如何疾速精确的定位问题及复原服务是一个十分紧迫的问题，这个问题在云上会更突出。本文通过介绍双集群的架构、log构造、剖析步骤来介绍双集群容灾的问题分析方法。 首先介绍一下双集群的部署计划原理，从部署架构和重要参数两个方面先介绍一下背景常识，便于更好了解问题剖析的办法。 架构简介1. 逻辑架构示例下图是一个同构的双集群部署示意图，主备集群都是3c3d, 主集群的主结点部署双集群框架脚本，定期进行备份操作，备集群的主结点定期复原备份集。根底数据须要进行一全量备份，之后增量备份。 2. 部署架构下图是接上图的部署架构，波及双集群同步脚本(SyncDataToStby.py), 备份程序（GaussRoach.py, gs_roach）三个二进制文件 备份侧调用关系：SyncDataToStby.py -> GaussRoach.py -> gs_roach 复原侧调用关系：SyncDataToStby.py -> GaussRoach.py -> gs_roach 理解调用关系和咱们剖析问题有间接的关系。 SyncDataToStby.py 是整个双集群的调用起始，管制着双集群的失常运行，失常状况下是长驻内存的过程，如果异样退出后，后盾会有crontab的来从新拉起双集群脚本: crontab -> SyncDataToStby.py -> GaussRoach.py -> gs_roach 主要参数简介 问题定位家喻户晓，零碎的各种log是咱们理解运行机制，理解问题现场的无力工具，同样双集群的问题剖析也依赖于log的剖析，首先认识一下双集群对应的日志： log 目录构造由上节的逻辑图及部署图，每个二进制对应的log文件如下图所示，对应二进制的信息查找对应的log。 如上图，双集群的日志也是寄存到$GAUSSLOG这个目录，并且有本人独立的目录 roach, 由这个目录同样是备份/复原的对应的log门路。咱们按调用关系从上到下的角度来介绍 frame目录寄存 SyncDataToStby.py 生成的log，波及到双集群调度，备份集清理，状态显示，配置文件及命令行参数解析的性能。 controller目录寄存 GaussRoach.py 生成的log，波及到备份、复原筹备工作一些操作，备份、复原参数解析，备份集群的解决，错误处理等 agent目录寄存 gs_roach工具 生成的log，波及到gs_roach 连贯gaussdb/gtm/cm发动备份/复原，生成备份集/复原备份集等操作。 gs_roach工具性能：在备份侧实现将cn/dn/gtm/cm的数据文件按程序打包成备份文件的性能，并生成备份集元信息文件; 复原侧依据元信息文件将备份集文件解压到对应cn/dn/gtm/cm的数据目录中。 定位步骤 确定问题在备份侧还是复原侧，查找双集群主结点上Sync日志，确定出错的模块确定出错的档次，因为双集群执行过程是一个上上层调用及时序关系的形式，具体程序参考：crontab -> SyncDataToStby.py -> GaussRoach.py -> gs_roach 在各个模块都有较具体的日志形容过程，具体问题具体分析，大体有如下几个方面1）配置出错，用户、环境变量文件 2）备份集群门路权限问题 3）因为集群状态非Normal导致备份失败 4）结点故障及备份集损坏导致复原失败 后续文章会按模块及谬误类型来详细描述问题定位步骤小结GaussDB(DWS)的双集群容灾性能是一个独立的简单的分布式系统，波及到三层工具的应用，因而在问题定位时会造成一些困惑。定位的办法须要先去了解架构，运行机制，而后依据时序关系去对应结点剖析日志。后续会从各个模块的角度介绍一些典型的问题及修复办法。 想理解GuassDB(DWS)更多信息，欢送微信搜寻“GaussDB DWS”关注微信公众号，和您分享最新最全的PB级数仓黑科技，后盾还可获取泛滥学习材料哦~ 点击关注，第一工夫理解华为云陈腐技术~

简介：数据仓库概念从1990年提出，通过了四个次要阶段。从最后的数据库演进到数据仓库，到MPP架构，到大数据时代的数据仓库，再到明天的云原生的数据仓库。在一直的演进过程中，数据仓库面临着不同的挑战。 作者 张良模 阿里云智能资深产品专家 谈到数据仓库，咱们往往容易疏忽“数据”两个字，阿里云有着很多业务场景和业务体系，在这些数据利用之下咱们如何治理数据的呢？数据仓库是如何帮到咱们以及它本身是如何演进的？ 数据仓库概念从1990年提出，通过了四个次要阶段。从最后的数据库演进到数据仓库，到MPP架构，到大数据时代的数据仓库，再到明天的云原生的数据仓库。在一直的演进过程中，数据仓库面临着不同的挑战。 第一 启动老本高、建设周期长，价值难以疾速验证对于数仓的建设人员，面临的挑战是业务人员心愿数仓建设周期能更短。而传统数据仓库往往要面临从洽购服务器，建设物理仓库到逻辑仓库等一个较长的周期，所以数据仓库面临的第一个挑战就是怎么去升高建设周期。 第二 如何解决多样数据，拥抱新技术，充沛开掘数据价值随着大数据的到来，传统数据仓库治理的大多是结构化数据。如何对半结构化的数据进行对立全面的治理就成为传统数据仓库面临的第二个挑战。 第三 难以共享企业数据资产、数据翻新老本高数据仓库更加强调治理和平安，在强调平安的状况下如何在组织里以及整个生态上下游中更好的共享和替换数据，成为了新的挑战。例如在企业的部门间或业务间仍然存在为数不少的数据孤岛，数据共享老本高，不足企业级别的对立的数据获取进口，由此导致数据生产方获取数据艰难，难于自助剖析，重大依赖IT部门反对来满足企业更宽泛的数据需要。 第四 平台架构简单、经营老本高随着数据处理品种的多样化和数据量的一直变大，不同的技术被叠加在一起从而使得数据仓库架构变得越发简单。同一企业里往往会同时存在各种技术类型的数据仓库。所以如何简化数据仓库的架构也是面临的一个重要挑战。个别须要投入业余团队负责管理简单的数据平台，同时对资源利用率不高的状况进行治理和治理。 第五 满足业务须要的扩展性、弹性、灵活性业务疾速倒退的企业，常常会有大促流动，补数据，解决非常规事件的需要，如何疾速扩大数仓性能，进步业务峰谷的响应时效，也带来很多挑战。 对于传统数据仓库面临的这些挑战，在技术和业务的驱动下新型数据仓库如何应答呢？这里能够看到六个次要的驱动力。 第一 咱们心愿有一个对立的数据平台，能去连贯，去存储和解决多种数据。 第二 实时化，企业基于数据驱动能实时对业务作出撑持和决策的信息，这里有更高时效性的要求。 第三 数据量变得十分宏大，在海量数据中如何找到想要的数据，就须要有一张地图，要对数据进行治理和治理。 第四 传统数据仓库中，数据的存储采纳集中的形式，肯定要把数据集中在同一个存储中。而在新的业务驱动下，须要去连贯数据而不是对立存储在一起。 第五 数据仓库之上如何反对更多智能化的利用，信息化的业务以及业务的信息化等关系。这就是数仓智能化和智能化数仓的需要驱动力。 第六 数据畛域的不同角色对数据平台有着不同需要。例如数据工程师，数据分析人员，数据科学家等，他们对数据平台的响应工夫，处理速度，数据量，开发语言等有着不同的需要。所以更多的做好剖析服务，成为数据管理平台第六个驱动力。 据仓库在一直地演进过程中，从30年前的概念来看曾经注入了更多新的外延。对于新的外延，咱们能够从数据仓库的基础架构，数据架构，数据分析以及服务模型四个角度来显著看到云原生，湖仓一体，离线实时一体化、服务模型的SAAS化的演进趋势。 云原生 — 数仓基础架构的演进方向云原生是数仓基础架构的一个根本的演进方向。传统数据仓库是基于物理服务器或云上托管服务器的模式。而云原生的状况下能够更多去利用云的根底服务，包含存储服务，网络服务以及更多的监控服务。这就意味着在云上用原生服务能够取得云的自服务、弹性等能力，云数仓就能够更好的去集成更多的云上服务，包含如何把日志数据从各种数据源抽取到数据仓库中，也包含如何进行全链路的数据管理和机器学习等。所以云原生往往蕴含了如何构建和如何与云上服务原生的集成。 如图，云原生的状况下在底层充分利用了云的弹性计算，存储以及平安能力。在此之上能够看到咱们把所有云的复杂性都屏蔽掉，作为数据平台的用户，只需开明服务，通过web形式创立我的项目空间，五分钟开明一个数据仓库进行数据仓库前面模型的开发。大大简化了服务交付的周期以及数据仓库整个底层架构，技术架构构建过程。另一方面是云原生数仓的扩展性，不论你提交了一个只须要1CU的作业还是提交一个可能须要10000CU的作业，平台都会按你的须要调度资源来进行数据处理。所以云原生又给咱们带来近乎有限的扩展性。 湖仓一体 — 数仓数据架构的演进方向讲到湖仓一体，先来看湖仓一体背地的起因。不得不说到明天为止数据仓库依然是企业治理数据最优的解决方案。各个企业大都有本人的数据仓库，只不过可能是基于不同的技术状态构建的数据仓库。在解决策略，对语义的反对上，对场景的优化上以及工程教训上，数据仓库是目前积淀下来的一个最优的计划。在此之上，企业数据量越来越大，须要更灵便更麻利的数据摸索能力。同时，对未知数据存在先存储下来再进一步摸索的诉求。由此，企业在架构上须要交融数据分析的最优化和可摸索两个方面的劣势，从解决策略到语义反对，以及应用案例上，数据仓库和数据湖别离带给企业不同的劣势。数据仓库在易治理，数据品质高，而数据湖在可摸索，灵活性强方面为咱们带来劣势。咱们要思考和探讨如何将两种形式联合起来共用，这就是提出“湖仓一体”的背景。 在MaxCompute以数据仓库为主的场景下，将数据仓库对数据管理的最优工程教训，治理教训和数据湖对数据管理的灵活性，数据处理的灵活性更好的联合在一起， 2019年咱们在寰球率先提出了“湖仓一体”的全新数据管理架构。基于MaxCompute数据仓库来提供安全可靠的，结构化的数据管理形式，以及在此之上由DataWorks提供数据血统，数据地图和数据治理等能力。这些能力如何延长到数据湖中？明天咱们可见的数据湖包含基于云上的对象存储OSS，也蕴含企业中基于Hadoop HDFS的数据湖，对于这两类数据湖如何基于已有的灵活性可能取得更容易摸索能力，能晋升它们得数据处理性能，治理能力和安全性？ 咱们所做的就是把数据仓库和数据湖两者买通，通过数据湖构建DLF，发现数据湖的元数据，进行结构化的对立治理，交融湖的灵便和便捷劣势。这就是以仓为核心的湖仓一体新型数据管理的架构，数据仓库在企业数据的治理形式上往前又推动了一步。 离线实时一体 — 数仓数据分析的演进方向在企业的数据仓库中，通过SLS、Kafka等订阅的形式进行数据采集，通常有三种门路。第一种可能是将一部分数据归档在数据仓库中，而后进行全量的剖析。第二种是进行实时的查问剖析，比方风控场景下查一个电话号码过来三年的通话记录，要马上查出来，就须要进行实时的连贯剖析。第三种是进行一些关联的多维度查问，对这些实时数据等进行关联的根底上，前面再来进行批量的解决，实时处理以及点查。实时数据的获取，计算以及利用这三方面，形成了整个数仓由离线向实时倒退的三个外围含意。这里最外围的就是计算。计算的实质无外乎两个，一个是被动计算，另一个是被动计算。离线计算往往是被动计算，须要数仓工程师通过定义工作来调度作业，能力计算出新的后果。在实时离线一体化中，除了被动计算，还要有被动计算能力。当数据流入后，不做人工干预，任何作业的插入和重启都能主动算出新的后果或两头后果。参加实时计算就最大水平的减少了被动计算的过程，而被动的后果带给咱们的益处就是无需从新调度任何作业就能拿到想要的后果数据。 在离线和实时一体的状况下尽管能够解决业务上的一些问题，但架构会非常复杂。所以阿里云提出离线实时一体化的数仓架构。简化是说咱们只须要外围的几个产品，就能够实现离线和实时一体化的架构。数据源包含了交易数据以及各个服务器生成的人的行为数据和物的行为数据，通过日志服务，定期归档到Hologres,之后，实时数仓加上流计算来进行实时计算，而后在上面是全量的数仓，整个实现了被动计算、被动计算和数据的实时获取。后果数据能够不必做任何搬迁，间接通过Hologres来做实时剖析。将实时的数据获取，实时的数据计算和实时的数据分析服务三者买通为一体，架构上做了最大水平的简化，这就是明天所说的离线实时一体化的云数据仓库。 SaaS模式 — 数仓服务模式的演进方向基于数仓基础架构、数据管理架构、数据分析架构的演进，这些产品的服务是如何被交付的呢？那就是通过SaaS化的形式向客户来交付数据仓库，能够最简化的去应用数据仓库的服务。 数据仓库的形成有几种形式，第一种是说基于物理服务器自建数据仓库，这是大家最为相熟的形式。第二种是在云上基于Hadoop，也能够基于各种MPP的数据库去构建和搭建半托管的云上数据仓库。第三种和第四种就属于比拟深的云原生的模式，第三种是典型Snowflake的形式，这种形式下云根底服务其实并不会裸露给数据仓库的管理者，所以咱们把它叫做嵌入式的，将IaaS这一层嵌入到PaaS层中，但最终数据仓库是通过SaaS的齐全web的形式裸露进去的。2021年寰球Forrester评测中有13家厂商参加了评估，其中以SaaS模式交付数据仓库服务的只有三家，别离是谷歌的BigQuery，Snowflake和阿里云MaxCompute。 能够看到通过云计算的数据仓库服务，从自建到云原生，帮咱们最大化的升高了数据仓库的治理复杂度，整个架构少了很多层，无需治理集群和软件，通过服务化的形式达到免运维，将底层的所有这些需治理的内容去掉，后盾降级是由云厂商来提供服务的，只须要治理本人的数据和数据模型，通过web形式来应用数据仓库服务。在数据仓库里存储的数据与云存储一样，按存储量付费。计算也是一样的，不计算不花钱。充分体现了SaaS化的劣势。同时，在匹配业务需要上具备十分强的弹性能力，咱们有很多客户日常只须要一万核的算力，在双十一当天须要三万核的算力。在这种SaaS模式的服务下，用户在齐全无感知的状况下咱们就能够保障充分的弹性能力去满足数据仓库的各种工作需要了。 综上，数据仓库从1990年的数据库演进到数据仓库，到MPP架构，到大数据时代的数据仓库，再到明天的云原生的数据仓库的一路演进，基础架构的云原生，数据架构的湖仓一体，数据分析的离线实时一体化以及数仓服务模式的SaaS化，是最为次要的四个演进的方向和特色。 阿里云正在通过全新数据仓库架构给企业带来具备更优体验的数据管理的形式。 原文链接 本文为阿里云原创内容，未经容许不得转载。

摘要：本文次要介绍GaussDB（DWS）数据库智能监控运维服务体系的设计规划和现状。本文分享自华为云社区《眼观六路耳听八方还不知疲倦？数仓智能运维服务体系是怎么做到的？》，原文作者：鲁巨匠。 背景介绍晚期，数据库系统仅仅提供SQL命令来查问其外部的运行状态，导致数据库运维操作门槛高，易用性差，DBA一度成为高度专业化的要害岗位，享受高薪和大家艳羡的眼光的同时，也为企业的数据安全带来了不确定性危险。并且，命令行运维不直观，重大依赖运维人员教训，不能做到疾速的发现、定位、解决问题，导致数据库运维问题，发现难，定位难，解决难。 为了应答这个困境，数据库运行状态可视化（数据库监控零碎）应运而生，通过可视化的伎俩以人类便于了解的图表模式，将重点数据以图形化的伎俩展现给运维人员，从而显著的升高了数据库运维的门槛，进步了数据库运维的效率。这个阶段有一些代表性的产品比方：OEM(Oracle), ViewPoint(Teradata)，等等。然而，这个期间用户的数据的规模不是很大，数据库也仍然部署在用户本人的数据中心，仍然是几个DBA运维几套数据库的阶段。 随着云时代的到来，云数据库逐步托管了客户的数据存储服务，云化将所有沉重的IT运维工作都集中在云后盾治理了起来，从而把客户从业余，简单，沉重的数据中心运维流动中解放了进去，使客户可能更加专一于其外围业务。同时，云服务提供商作为数据存储服务的提供者，则须要在IT运维与数据库运维上深耕细作，施展其团队稳固，专业化水平高，把握海量数据库运行数据的劣势；充分利用目前机器学习、人工智能畛域的科研成果，应用技术手段逐步提高每名运维人员所能治理的数据库数量，从而实现数据库运维工作的“减员增效”。另一方面，数据库服务上云后，云服务提供商所须要运维的数据库数量与之前相比天差地别，以前的工具可能曾经不适应云时代的需要。如何做好云上海量数据库的运维工作将成为云服务提供商的一个微小挑战。 数据库智能运维体系传统意义上的数据库监控服务仅仅是指（1）采集数据库运行状态；（2）上报/存储数据库运行数据；（3）图形化展现数据库运行状态数据。然而，这仅仅是数据库智能监控运维体系的一部分。 如果把整个数据库智能监控运维体系比作一个人的话，传统意义上的数据库监控服务仅仅代表了，眼睛的角色。该服务只能做到发现问题，辨认定位问题和解决问题都须要DBA的染指。因而DBA才是传统数据库监控运维体系中的外围因素，这也是DBA人才为何如此要害的起因之一。 而云时代的到来和大数据分析、人工智能等技术的成熟，给了数据库监控运维更多的设想空间。我能够在传统数据库监控（眼睛）的根底上，减少预测剖析和根因判断模块，建设景象-根因-解决方案的映射关系（大脑），最初通过数据库治理模块执行解决方案（双手），从而实现从发现问题，定位问题，到解决问题的运维闭环。并且机器不同于人类，只有算力容许，它能够做到眼观六路，耳听八方，不知疲倦，也不会感觉无聊，7x24的盯着成千盈百数据库系统的各种运行数据，不会放过任何一个渺小的潜在问题。因而，数据库运维工作的智能化中，应用规定或算法固化DBA判断和决策教训将是十分重要的一环。 友商的数据库智能运维体系综合来看目前亚马逊在云数据库的智能监控体系上切入的比拟早，也倒退了很多成绩。相对而言，其余传统厂商在数据的智能监控体系上尽管各有千秋，然而并没有像亚马逊一样可能造成运维闭环。亚马逊Redshift在数据库监控运维设计上体现了数据库服务化的思维，他们只提供了非常简单的零碎负载剖析和问题SQL定位工具帮忙云上利用开发者发现业务层面的问题。而把数据库系统的复杂性全副暗藏在了云服务运维层的后盾，我集体猜想（因为咱们看不到AWS的运维界面）亚马逊AWS后盾应该有一整套主动发现问题，定位问题和解决问题的工具。否则，仅仅凭一个公司的人力必定是无奈运维寰球海量的数据库的。 更多的友商智能运维产品剖析和比照相干内容，咱们就不在这里赘述了，后续咱们会有专题展开讨论。 GaussDB(DWS)的数据库智能运维体系参考友商数据库监控运维体系的建设教训，联合GaussBD(DWS)数仓的本身特点，咱们筹备从眼，脑，手三个方面发力建设闭环的数据库智能监控运维体系。 GaussDB(DWS)应用DMS来承载数据库的智能运维体系。DMS将会串起数据库运维过程中的监控，剖析，解决三个步骤，别离对应上文提到的数据库智能运维体系中的眼，脑，手三局部，从概念设计上造成运维体系的闭环。 监控局部：次要负责数据库运行状态数据的采集、存储和可视化展现，这一部分根本等同于传统的数据库的监控业务。这一部分性能和指标的选取，咱们参考了友商以及运维团队的倡议，将监控指标分为底层IT零碎运维指标和数据库系统运维指标两类，正在别离逐渐补齐和欠缺中。监控模块是DMS数据库运智能监控运维体系首先发力，并要在短时间内造成竞争力的模块。 剖析局部：作为整个DMS数据库智能运维体系的大脑，该局部是承当运维数据分析与决策的要害模块。该局部因为其复杂性，目前还处于设计构想阶段。初步布局有三个子模块，工夫序列的趋势剖析子模块，该模块次要用来做趋势预测剖析，用来预判潜在的问题；逻辑推断子模块，用户剖析问题景象与理论根因之间的关系，能够实现从问题景象到触发起因的推断，初步思考应用搜索引擎技术实现；常识图谱子模块，次要用于景象、根因与解决方案之间的映射关系示意，不便从定位的根因中找到最合适的解决方案。 解决局部：次要由DWS提供的数据库治理性能承当，目前能够提供数据库参数配置（可配置参数少，须要进一步丰盛），工作负载队列配置，集群装置/卸载，集群重启，集群扩容，集群数据重散布以及节点温备等运维能力。 GaussDB(DWS)数据库智能运维典型用户与需要为了进一步理清数据库智能运维产品的设计思路，咱们打算从用户的角度剖析其需要，而后从需要导出性能（工具）页面设计，从性能（工具）页面总结出所需监控数据库指标。通过剖析数据库监控零碎的各种应用场景，咱们对数据库监控零碎的用户做了用户角色画像，定义了数据库运维过程中的三种角色，并认为不同角色仅仅关注数据库运维的一个侧面。在理论的数据库运维场景中，可能同一个用户会身兼多种角色，然而这里咱们为了不便剖析仅仅从逻辑上定义这三种角色。 利用开发：次要指客户侧的利用开发角色，他们负责设计具体的业务SQL。他们关怀业务SQL执行的正确性和执行效率。利用开发工程师须要用到web SQL来调试其SQL语句的查问效率；须要用到查问监控页面来查看业务SQL在理论执行场景中的体现和资源耗费；须要用到工作负载队列监控来确认新开发的业务SQL是否在适合的工作负载队列中，以及所配置的熔断规定是否正当，等等。 SRE：指的是华为云侧的数据库运维角色，他们通常一个人须要负责成千盈百个集群的稳固运行，他们须要可能迅速辨认出集群运行状态的异样，集群资源瓶颈以及集群潜在的扩容需要，并且他们还须要积极响应客户的求助，帮忙客户定位，确认和解决问题。SRE须要节点资源监控来辨认集群中的资源歪斜；须要辨认集群资源耗费基线变化趋势，从而辨认到扩容需并揭示用户；须要关注存储变动以推算下一次惯例颐养的工夫点并主动布局；同时还须要响应用户需要，应用DMS提供的问题定位工具，辅助用户定位现网问题。 DBA：指的是GaussDB(DWS)数据库集群专家，他们相熟数据库设计方法论，数据库的调优，数据库问题定位。他们须要剖析定位数据库的故障，从资源和业务角度使用多种工具综合剖析定位系统故障，零碎稳定性和潜在瓶颈；也须要帮忙用户从业务、数据库设计的角度去举荐数据库的索引，散布列配置，依据用户业务水平举荐用户购买适合的集群规模等等；同时还须要辅助利用开发工程师调优引起性能劣化的SQL语句；在找到确切的故障根因后，举荐适合的解决方案修复故障。 在一般来说在私有云场景中，用户角色个别只有利用开发和SRE两种，私有云场景中的SRE角色往往涵盖了DBA的角色。咱们在这里将运维角色细分的目标，其实是要展现一个残缺的运维场景沙盘，将客户的运维诉求分门别类的列举进去，为后续进一步的性能（工具）页面设计和运维场景设计提供根底。 GaussDB(DWS)数据库智能运维指标数据库监控指标数量多，模式和逻辑简单，依据指标类型能够分为逻辑关系与物理关系两种。其中逻辑关系指数库外部逻辑关系，比方，最顶层是数据库，数据库中有多个schema，schema中有多个表，数据库中有多个用户，一个用户能够有多个schema和表。而物理关系是指，gaussDB(DWS)集群的拓扑关系，比方，一个数据库集群是由多个计算节点形成，每个计算节点上会部署多个计算实例。这两种指标关系都会影响到数据库指标的采集维度和聚合展现维度。 因为下面曾经剖析了指标的维度关系，所以咱们上面将只探讨具体的数据库指标类型，而不会对指标的维度进行开展。数据库是一个软件服务，而它必须运行在一个宿主机和操作系统之上，因而监控指标大抵能够分为两类： 系统资源类指标：这一类指标次要形容零碎上的各种资源耗费 数据库相干指标：这一类指标次要形容数据性能相干的业务负载程度 上图总结了DMS采集的数据库次要指标，具体指标项依照指标大类，原子指标和派生指标三个档次排列。不过，目前该指标地图并不固定，将来随着GaussDB(DWS)智能运维零碎的逐渐成熟，该指标地图会逐步完善并固定下来。 因为MPP数据库的非凡构型，数据库实例是作为过程试运行在节点上的。因而，咱们的指标设计其实自身会自带维度属性，比方磁盘使用率指标，最小的维度应该是某个DN实例，上一级是节点级，再上一级就是整个集群。所以，咱们理论提供的监控指标应该是指标维度关系与集群指标地图的一个笛卡尔积。为了形容这种情景，咱们引入原子指标，派生指标和组合指标的概念。以下面的磁盘使用率为例，咱们将DN实例的磁盘使用率作为原子指标，而其余维度的磁盘使用率作为派生指标。 原子指标：形容数据库某个个性的最小维度指标，比方节点的CPU使用率，DN实例的磁盘使用率，等等。派生指标：（1）原子指标在不同维度上的聚合后果，比方集群均匀CPU使用率，集群磁盘使用率，等等；（2）对原子指标做统计运算失去的新指标，比方CPU歪斜率，等等。组合指标：将多个原子指标或者派生指标组合在一起，从而失去的更加便于了解的新指标。比方集群衰弱度，等等。目前DMS的指标建设更多停留在原子指标和派生指标阶段，因为咱们认为应该首先补齐数据库的根底指标造成根本的监控运维能力之后，能力联合用户应用习惯，深度开掘指标在各个维度下的运维含意以及多种指标组合后所代表的运维意义。 总结最初，总结一下，本文次要介绍了GaussDB（DWS）数据库智能监控运维服务体系的设计规划和现状。本文作为DMS系列文章的第一篇，次要起到一个概要介绍的作用，让大家对GaussDB（DWS）数据库智能监控运维服务体系有个概况的意识，更多干货细节欢送期待后续的文章。 想理解GuassDB(DWS)更多信息，欢送微信搜寻“GaussDB DWS”关注微信公众号，和您分享最新最全的PB级数仓黑科技，后盾还可获取泛滥学习材料哦~ 点击关注，第一工夫理解华为云陈腐技术~

摘要：本期将具体介绍 SSDB、LevelDB 和 RocksDB 到 GaussDB(for Redis)的迁徙。本文分享自华为云社区《华为云PB级数据库GaussDB(for Redis)揭秘第十一期：GaussDB(forRedis)迁徙系列（下）》，原文作者：高斯 Redis 官网博客 。 GaussDB(for Redis)是一款基于计算存储拆散架构，兼容 Redis 生态的云原生 NoSQL 数据库，基于共享存储池的多正本强统一机制，反对长久化存储。在保障数据库的高兼容、搞性价比、高牢靠、无损扩容等特点的同时，GaussDB(forRedis)团队针对不同的数据库产品，为用户提供了多种数据迁徙计划，本期将具体介绍 SSDB、LevelDB 和 RocksDB 到 GaussDB(for Redis)的迁徙。 1、SSDB 到 GaussDB(for Redis)的迁徙SSDB 是一款应用 C/C++语言开发的高性能 NoSQL 数据库，和 Redis 具备类似的 API，反对 KV，list，map(hash)，zset(sorted set)，qlist(队列)等数据结构，因而失去了宽泛的利用。SSDB 是一个长久化的 KV 存储系统，底层应用 leveldb 作为存储引擎。其业务间接与 LevelDB 交互，Compaction 等操作会对业务读写造成间接的影响。 GaussDB(forRedis)是一款兼容 Redis 生态的云原生 NoSQL 数据库，基于共享存储池的多正本强统一机制，以保证数据的安全性和可靠性。GaussDB(forRedis)应用 RocksDB 作为存储引擎，其性能与 leveldb 相比有了很大的晋升, 并解决了 leveldb 被动限度写的问题，同时实现了冷热拆散，减小了存储层的操作对性能造成的影响。 1.1 迁徙原理ssdb-port 作为源端 SSDB 数据库的主节点的从节点（replica）运行，通过主从复制的形式进行数据迁徙。将获取到的数据解析、转换为 Redis 反对的格局，并发送到配置文件中指定的 Redis 实例，迁徙过程如下图所示。全量同步实现后，SSDB 中新增的数据也会同步到 Redis 实例中。 1.2 前提条件部署迁徙工具 ssdb-port。保障迁徙工具 ssdb-port、源端 SSDB 和指标端 GaussDB(for Redis)网络互通。 ...

简介： 本文介绍数据仓库产品作为企业中数据存储和治理的基础设施，在通过分层存储技术来升高企业存储老本时的关键问题和核心技术。 作者 | 沄浩、士远起源 | 阿里技术公众号 一 背景据IDC公布的《数据时代2025》报告显示，寰球每年产生的数据将从2018年的33ZB增长到2025年的175ZB，均匀每天约产生491EB数据。随着数据量的一直增长，数据存储老本成为企业IT估算的重要组成部分。例如1PB数据存储一年，全副放在高性能存储介质和全副放在低成本存储介质两者老本差距在一个量级以上。因为要害业务需高性能拜访，因而不能简略的把所有数据寄存在低速设施，企业需依据数据的拜访频度，应用不同品种的存储介质取得最小化老本和最大化效率。因而，把数据存储在不同层级，并可能主动在层级间迁徙数据的分层存储技术成为企业海量数据存储的首选。 本文介绍数据仓库产品作为企业中数据存储和治理的基础设施，在通过分层存储技术来升高企业存储老本时的关键问题和核心技术。 1 什么是分层存储 分层存储顾名思义，就是把数据分为高频拜访的热数据和低频拜访的冷数据，并别离存储在热数据层和冷数据层，达到性能与老本的均衡。 热数据层采纳高性能存储介质，单位成本高，为管制估算个别容量较小，只存储要害业务数据，例如ERP，CRM数据，或者最新的订单数据等。 冷数据层则存储非关键业务数据，例如审计日志，运行日志等，或历史积淀数据，例如一个月前的订单数据。此局部数据体量大，拜访频度低，性能要求不高，因而采纳单位成本低，容量大的存储介质来降低成本。同时，随着工夫流逝，局部热数据拜访频度会升高（个别称为数据降温），此时存储系统可能主动迁徙该局部数据到冷数据层来降低成本。 2 数据仓库分层存储面临的挑战 数据仓库产品在实现分层存储能力时，面临的几个外围挑战如下： 抉择适合的存储介质。存储介质既要满足性能、老本需要，还要满足可靠性、可用性、容量可扩大、运维简略等需要。业务上的冷热数据，如何在分层存储中定义？即如何形容哪局部是热数据，哪局部是冷数据。冷热数据如何迁徙？随着工夫流逝，业务上的热数据降温为冷数据后，数据仓库如何感知温度的变动并执行数据迁徙来升高存储老本。 如何减速冷数据的拜访？冷数据依然会被拜访，比方因法规政策要求，用户需对三个月前数据进行订正，或者须要对过来一年的数据进行统计分析来进行历史回顾和趋势剖析。因为冷数据体量大，查问波及的数据多，存储介质性能低，如果不进行优化，对冷数据的元信息，内容拜访可能呈现瓶颈影响业务应用。 二 数据仓库分层存储关键技术解析 本章将以阿里云数据仓库AnalyticDB MySQL版（下文简称ADB）为原型介绍如何在数据仓库产品中实现分层存储，并解决其外围挑战。ADB的整体架构分为三层： 第一层是接入层：由多个前端节点形成，次要负责接入用户查问，进行SQL解析、优化、调度。 第二层是计算引擎层：由多个计算节点组成，负责执行用户查问。 第三层是存储引擎层：由多个存储节点组成，用户数据按Shard切片存储，每个Shard有多个正本保障高牢靠和高可用。 1 冷热数据存储介质的抉择 对于业务上的热数据，需采纳高性能存储介质满足其疾速查问需要。SSD绝对HDD来说，老本较高，但其具备高IOPS和高带宽的个性，因而ADB把热数据层建设在SSD上，并应用数据多正本机制，呈现存储节点异样时，通过切换服务节点来保障高牢靠和高可用。 业务上的冷数据，个别是历史积淀的业务数据或日志数据，这些数据体量大，拜访频度低，因而容量大、成本低是存储介质的次要抉择因素。对于冷数据层，ADB抉择建设在阿里云OSS上。阿里云对象存储服务OSS作为阿里云提供的海量、低成本、高持久性的云存储服务，其数据设计持久性不低于99.9999999999%，服务可用性不低于99.995%。OSS提供的这些个性满足了冷数据层对老本和可靠性的需要，同时绝对于本人保护HDD磁盘，OSS本身具备容量有限扩大能力，满足海量数据存储需要。并且OSS能够近程拜访，因而存储节点的正本间能够共享数据来进一步降低成本。 2 冷热数据定义问题 业务本身对冷热数据的定义比拟明确。比方企业中一些须要高频拜访的CRM、ERP数据均为热数据。而对于审计日志，或数天前的订单数据，其拜访频度低，则可定义为冷数据。外围问题是，业务上的这些数据，如何在分层存储中形容其冷热属性并保障存储地位的准确性。例如企业促销流动，大量用户正在线上进行业务交互，此时如果分层存储谬误的把客户信息、商品信息等要害数据迁徙到冷区，则会引起相干查问性能受损，最终呈现客户登录碰壁，客户点击失败等业务异样，导致企业受损。ADB解决这个问题的办法是在用户建表时指定存储策略（storage_policy）来准确关联业务上的冷热数据和分层存储中的冷热存储，上面是示例。 全热表 所有数据存储在SSD并且不会降温，实用于全表数据被频繁拜访，且对拜访性能有较高要求的场景，比方CRM、ERP数据。 Create table t1( id int, dt datetime) distribute by hash(id) storage_policy = 'HOT';全冷表 所有数据存储在OSS，实用于体量大，拜访频度低，须要缩小存储老本的场景，比方审计日志数据。 Create table t2( id int, dt datetime) distribute by hash(id) storage_policy = 'COLD';冷热混合表 实用于数据冷热有显著工夫窗口的场景。例如最近7天的游戏日志数据，广告点击数据等需高频拜访，作为热数据存储，而7天前的数据可降温为冷数据，低成本存储。 注：冷热混合表需配合表的分区应用。除storage_policy外，还需指定hot_partition_count属性。hot_partition_count指按分区值倒序，取最大N个分区为热分区，其余为冷分区。下例中，表按天分区，hot_partition_count = 7示意分区值最大的7个分区，也就是最近7天的数据为热数据。Create table t3( id int, dt datetime) distribute by hash(id) partition by value(date_format(dt, '%Y%m%d'))lifecycle 365storage_policy = 'MIXED' hot_partition_count = 7;批改冷热策略 ...

建设数据仓库是一个解决企业问题的过程，业务人员往往不懂如何建设和应用数据仓库，施展其决策反对的作用;IT部门的人员往往又不懂业务，不晓得应该建设哪些决策主题，从数据源中抽取哪些数据。因而，数据仓库的我的项目小组应该由业务人员和IT人员独特组成，单方须要互相沟通，合作开发数据仓库。 开发数据仓库的过程包含以下几个步骤。 一、系统分析，确定主题 建设数据仓库的第一个步骤就是通过与业务部门的充沛交换，理解建设数据仓库所要解决的问题的真正含意，确定各个主题下的查问剖析要求。 业务人员往往会列举出很多想解决的问题，IT人员应该对这些问题进行分类汇总，确定数据仓库所实现的业务性能。一旦确定问题当前，IT人员还须要确定几个因素： 操作呈现的频率，即业务部门每隔多长时间做一次查问剖析? 在零碎中须要保留多久的数据，是一年、两年还是五年、十年? 用户查问数据的次要形式，如在工夫维度上是依照天然年，还是财政年? 用户所能承受的响应工夫是多长、是几秒钟，还是几小时? 因为单方在了解上的差别，确定问题和理解问题可能是一个须要屡次重复的过程，IT人员可能须要做一些原型演示给业务人员看，以最终确定零碎将要实现的性能的确是业务部门所须要的。 二、抉择满足数据仓库零碎要求的软件平台 在数据仓库所要解决的问题确定后，第二个步骤就是抉择适合的软件平台，包含数据库、建模工具、剖析工具等。这里有许多因素要思考，如系统对数据量、响应工夫、剖析性能的要求等，以下是一些公认的抉择规范： 厂商的背景和反对能力，是否提供全方位的技术支持和咨询服务? 数据库对大数据量(TB级)的反对能力? 数据库是否反对并行操作? 是否提供数据仓库的建模工具，是否反对对元数据的治理? 是否提供反对大数据量的数据加载、转换、传输工具(ETL)? 是否提供残缺的决策反对工具集，满足数据仓库中各类用户的须要? 三、建设数据仓库的逻辑模型 具体步骤如下： 确定建设数据仓库逻辑模型的根本办法; 基于主题视图，把主题视图中的数据定义转到逻辑数据模型中; 辨认主题之间的关系; 合成多对多的关系; 用范式实践测验逻辑数据模型; 由用户审核逻辑数据模型; 四、逻辑数据模型转化为数据仓库数据模型 具体步骤如下： Step.1 删除非战略性数据 数据仓库模型中不须要蕴含逻辑数据模型中的全副数据项，某些用于操作解决的数据项要删除; Step.2 减少工夫主键 数据仓库中的数据肯定是工夫的快照，因而必须减少工夫主键; Step.3 减少派生数据 ...

数据仓库概念： 数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据反对的策略汇合。它是单个数据存储，出于剖析性报告和决策反对目标而创立。 为须要业务智能的企业，提供领导业务流程改良、监督工夫、老本、品质以及管制。 那么数据仓库有什么作用呢？ 1、提供增强的商业智能BI利用从各种数据源提供的数据，管理人员和高管们将不再须要凭着无限的数据或他们的直觉做出商业决策。此外,“数据仓库及相干商业智能BI可间接用于包含市场细分、库存治理、财务管理、销售这样的业务流程中。”2、提高效率和节省成本通过数据仓库，能够建设企业的数据模型，这对于企业的生产与销售、老本管制与收支调配有着重要的意义，极大的节约了企业的老本，进步了经济效益，同时，用数据仓库能够剖析企业人力资源与根底数据之间的关系，能够用于返回剖析，保障人力资源的最大化利用，亦能够进行人力资源绩效评估，使得企业治理更加科学合理。 3、进步数据的品质和一致性一个数据仓库的施行包含将数据从泛滥的数据源零碎中转换成独特的格局。因为每个来自各个部门的数据被标准化了，每个部门将会产生与所有其它部门合乎的后果。所以你能够对你数据的准确性更有信念。而精确的数据是弱小的商业决策的根底。4、提供历史的智慧一个数据仓库贮存了大量的历史数据，所以你能够通过剖析不同的期间和趋势来做出对将来的预测。这些数据通常不能被存储在一个交易型的数据库里或用来从一个交易系统中生成报表。5、创立高的投资回报率曾经装置了数据仓库和欠缺了商业智能BI零碎的企业比没有在商业智能BI零碎和数据仓库投资的企业能产生更多的利润和节约更多的资金。而这应该成为高级管理层疾速退出到数据仓库这个潮流中的足够理由。 以上就是思迈特软件明天分享的数据仓库及其作用。 感谢您的浏览，更多常识，请持续关注咱们，下期再见！ 广州思迈特软件有限公司（简称：思迈特软件Smartbi）是国家认定的“高新技术企业”，专一于商业智能（BI）与大数据分析软件产品和服务。咱们在BI畛域具备15年以上产品研发教训，提供残缺的大数据分析软件产品、解决方案、以及配套的征询、施行、培训及保护服务。

对于数据仓库的分层，仿佛大家都有一个独特的意识。但波及到每一层该如何去建模，可能每个人都有本人的了解。数据建模，毫无疑问是数仓建设的重中之重，而后，在理论的开发过程中，会把大量的工夫都投入到了需要开发，往往会疏忽数据建模(尤其是DWS层的建模)，长此以往，数据模型变的越来越芜杂，指标口径无奈对立，造成的后果就是：尽管表很多，然而却很难取数。本文次要介绍DWS层建模的根本方法论，心愿对你有所帮忙。 公众号【大数据技术与数仓】首发，关注支付材料数仓为什么要分层正当的数据仓库分层一方面可能升高耦合性，进步重用性，可读性可维护性，另一方面也能进步运算的效率，影响到数据需要迭代的速度，近而影响到产品决策的及时性。建设数据分层能够提炼公共层，防止烟囱式开发，可见一个适合且正当的数仓分层是极其重要。 通用分层设计思路ODS:操作型数据(Operational Data Store)，指构造与源零碎根本保持一致的增量或者全量数据。作为DW数据的一个数据筹备区，同时又承当根底数据记录历史变动，之所以保留原始数据和线上原始数据保持一致，不便前期数据核查须要。CDM：通用数据模型，又称为数据中间层(Common Data Model)，蕴含DWD、DWS、DIM层。DWD：数据仓库明细层数据(Data Warehouse Detail)。对ODS层数据进行荡涤转化，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。能够联合企业的数据应用特点，基于维度建模思维，将明细事实表的某些重要属性字段做适当冗余，也即宽表化解决，构建明细宽表。DWS：数据仓库汇总层数据(Data Warehouse Summary)，基于指标需要，构建初步汇总事实表，个别是宽表。基于下层的利用和产品的指标需要，构建公共粒度的汇总指标表。以宽表化伎俩物理化模型，构建命名标准、口径统一的统计指标，为下层提供公共指标。DIM：建设统一数据分析维表，能够升高数据计算口径不对立的危险，同时能够不便进行穿插探查。以维度作为建模驱动，基于每个维度的业务含意，通过增加维度属性、关联维度等定义计算逻辑，实现属性定义的过程并建设统一的数据分析维表。ADS：面向利用的数据服务层(Application Data Service)。整合汇总成剖析某一个主题域的服务数据，面向应用逻辑的数据加工。该层次要存放数据产品个性化的统计指标数据，这一层的数据间接对接数据的消费者，是产品、经营等角色能够间接感知了解的一层，大多数这一层的表都能够间接在BI上通过图表的模式间接透出。没有DWS层不行吗当咱们在做数据需要时，会不会有这样的疑难：我间接能从DWD层很不便的取出想要的数据，为什么还要多此一举建设DWS层的汇总表呢？那是不是意味着能够不必建设DWS层的表呢，答案是：能够的。然而这有一个前提，就是业务场景不简单。从短期来看能够疾速满足数据需要的开发，然而长期来看，会存在如下的问题： 对于简单的业务场景而言，会呈现很多跨域、跨事实的穿插探查，如果没有积淀出DWS层的指标进行统一口径的收口，那么雷同的指标会呈现不同的口径和命名，其结果就是取数变得越来越不不便，而且容易造成业务狐疑数据是否正确的难堪场面。公共指标没有对立计算，当每次须要雷同的指标时，则须要从新计算一遍取数逻辑，不仅效率不高(须要关联表，计算指标)，而且会造成计算资源节约。DWS层设计以剖析的主题对象作为建模驱动，基于下层的利用和产品的指标需要，构建公共粒度的汇总指标表。以宽表化伎俩物理化模型，构建命名标准、口径统一的统计指标，为下层提供公共指标，建设汇总宽表。如：造成日，周，月粒度汇总明细，或者基于某一个维度，如商品类目粒度的汇总日表，统计便于下一步报表数据结构的组织。 DWS层的根本特点DWS层是面向剖析维度进行设计的，剖析维度通常是业务常常须要的看数据的角度。DWS层的表服务于数据报表和数据产品的指标需要ADS层的指标数据会存在穿插探查的状况，所以DWS层的指标要放弃命名和口径统一，防止ADS层的指标数据凌乱DWS是公共汇总层，提供不同维度的统计指标，指标的口径要保持一致，并且要提供具体的形容以宽表的模式进行设计，比方雷同粒度的统计指标能够放在一起，防止创立太多的表公共汇总层的一个表通常会对应一个派生指标DWS存储派生指标(统计周期+修饰词+统计粒度+原子指标)，原子指标存储在DWD层的事实表中原子指标与派生指标所谓原子指标，即是业务过程的度量，就是明细事实表中的度量值。比方订单表，那么某个订单对应的订单金额就是一个原子指标，这个指标是随同着订单的业务过程而产生的。 所谓派生指标，即由统计周期+修饰词+统计粒度+原子指标组合加工而成的指标 其中，统计周期：指的是想要统计的工夫周期，比方天、周、月 修饰词：指的是业务的束缚，通常呈现在SQL的where条件中，比方订单的下单渠道等等 统计粒度：指的是维度组合，通常呈现在SQL的group by中，比方统计商品一级类目对应的销售额，那一级类目就是统计粒度 DWS层的设计准则对于汇总层的表建模应遵循以下的准则： 数据专用性比方，汇总的汇集表是否与别人专用？基于某个维度的汇集是否是数据分析或者报表中常常应用的？如果满足这些状况，咱们就有必要把明细数据积淀到汇总表中。不跨数据域数据域是在较高层次上对数据进行分类汇集的形象，如交易对立划到交易域下，商品的新增、批改放到商品域下。辨别统计周期表命名上要能阐明数据的统计周期，如_1d 示意最近1天，_td 截止到当天，_nd 示意最近N天。防止多个层级的数据应该防止将不同层级的数据放在一起，比方，如果存在7天和30天的事实，咱们能够抉择用两列寄存7天和30天的事实，然而须要在列名和字段正文上阐明分明。同时咱们也能够应用两张表别离存储不同统计周期的数据加以辨别。汇集是不逾越事实的汇集是针对原始星型模型进行的汇总，为了获取和查问原始模型统一的后果，汇集的维度和度量必须与原始模型保持一致，因而汇集是不跨事实的。横向钻取(穿插探查)是针对多个事实基于一致性维度进行的剖析，很多时候采纳交融事实表，事后寄存横向钻取的后果，从而进步查问性能。因而交融事实表是一种导出模式而不是汇集。DWS层设计步骤首先，确定汇集维度，即确定统计粒度，比方商品粒度而后，确定统计周期，比方天最初，确定汇集事实，即派生指标CREATE TABLE IF NOT EXISTS dws_asale_trd_itm_ord_1d( item_id                 BIGINT COMMENT '商品ID', item_title               STRING COMMENT '商品名称', cate_id                 BIGINT COMMENT '商品类目ID', cate_name               STRING COMMENT '商品类目名称', mord_prov               STRING COMMENT '收货人省份', confirm_paid_amt_sum_1d DOUBLE COMMENT '最近一天订单曾经确认收货的金额总和')COMMENT '商品粒度交易最近一天汇总事实表'PARTITIONED BY (ds STRING COMMENT '分区字段YYYYMMDD'); ...

拉链表是针对数据仓库设计中表存储数据的形式而定义的，顾名思义，所谓拉链，就是记录历史。记录一个事物从开始，始终到以后状态的所有变动的信息。 上面就是一张拉链表，存储的是用户的最根本信息以及每条记录的生命周期。咱们能够应用这张表拿到最新的当天的最新数据以及之前的历史数据。 注册日期用户编号手机号码t_start_datet_end_date2017-01-010011111112017-01-019999-12-312017-01-010022222222017-01-012017-01-012017-01-010022333332017-01-029999-12-312017-01-010033333332017-01-019999-12-312017-01-010044444442017-01-012017-01-012017-01-010044324322017-01-022017-01-022017-01-010044324322017-01-039999-12-312017-01-020055555552017-01-022017-01-022017-01-020051151152017-01-039999-12-312017-01-030066666662017-01-039999-12-31阐明： t_start_date 示意该条记录的生命周期开始工夫，t_end_date 示意该条记录的生命周期完结工夫；t_end_date = '9999-12-31' 示意该条记录目前处于无效状态；如果查问以后所有无效的记录，则select * from user where t_end_date = '9999-12-31'如果查问2017-01-01的历史快照，则select * from user where t_start_date <= '2017-01-01' and end_date >= '2017-01-01'，这条语句会查问到以下记录：拉链表的应用场景在数据仓库的数据模型设计过程中，常常会遇到上面这种表的设计： 有一些表的数据量很大，比方一张用户表，大概10亿条记录，50个字段，这种表，即便应用ORC压缩，单张表的存储也会超过100G，在HDFS应用双备份或者三备份的话就更大一些。表中的局部字段会被update更新操作，如用户联系方式，产品的形容信息，订单的状态等等。须要查看某一个工夫点或者时间段的历史快照信息，比方，查看某一个订单在历史某一个工夫点的状态。表中的记录变动的比例和频率不是很大，比方，总共有10亿的用户，每天新增和发生变化的有200万左右，变动的比例占的很小。对于这种表的设计？上面有几种计划可选： 计划一：每天只留最新的一份，比方咱们每天用datax抽取最新的一份全量数据到Hive中。计划二：每天保留一份全量的切片数据。计划三：应用拉链表。为什么应用拉链表计划一：每天只留最新的一份 这种计划就不必多说了，实现起来很简略，每天drop掉前一天的数据，从新抽一份最新的。长处很显著，节俭空间，一些一般的应用也很不便，不必在抉择表的时候加一个工夫分区什么的。毛病同样显著，没有历史数据，先翻翻旧账只能通过其它形式，比方从流水表外面抽。 计划二：每天保留一份全量的切片数据 每天一份全量的切片是一种比拟稳当的计划，而且历史数据也在。毛病就是存储空间占用量太大太大了，如果对这边表每天都保留一份全量，那么每次全量中会保留很多不变的信息，对存储是极大的节约。当然咱们也能够做一些取舍，比方只保留近一个月的数据？然而，需要是无耻的，数据的生命周期不是咱们能齐全左右的。 计划三：拉链表 拉链表在应用上根本兼顾了咱们的需要。首先它在空间上做了一个取舍，虽说不像计划一那样占用量那么小，然而它每日的增量可能只有计划二的千分之一甚至是万分之一。其实它能满足计划二所能满足的需要，既能获取最新的数据，也能增加筛选条件也获取历史的数据。所以咱们还是很有必要来应用拉链表的。 拉链表的设计在Mysql关系型数据库里的user表中信息变动 在2017-01-01表中的数据是： 注册日期用户编号手机号码2017-01-010011111112017-01-010022222222017-01-010033333332017-01-01004444444在2017-01-02表中的数据是，用户002和004材料进行了批改，005是新增用户: 注册日期用户编号手机号码备注2017-01-01001111111无2017-01-01002233333（由222222变成233333）2017-01-01003333333无2017-01-01004432432（由444444变成432432）2017-01-02005555555（2017-01-02新增）在2017-01-03表中的数据是，用户004和005材料进行了批改，006是新增用户: 注册日期用户编号手机号码备注2017-01-01001111111 2017-01-01002233333 2017-01-01003333333 2017-01-01004654321（由432432 变成 654321） 2017-01-02005115115（由555555 变成 115115） 2017-01-03006115115（2017-01-03 新增） 如果在数据仓库中设计成历史拉链表保留该表，则会有上面这样一张表，这是最新一天（即2017-01-03）的数据： 注册日期用户编号手机号码t_start_datet_end_date2017-01-010011111112017-01-019999-12-312017-01-010022222222017-01-012017-01-012017-01-010022333332017-01-029999-12-312017-01-010033333332017-01-019999-12-312017-01-010044444442017-01-012017-01-012017-01-010044324322017-01-022017-01-022017-01-010044324322017-01-039999-12-312017-01-020055555552017-01-022017-01-022017-01-020051151152017-01-039999-12-312017-01-030066666662017-01-039999-12-31阐明： t_start_date 示意该条记录的生命周期开始工夫，t_end_date 示意该条记录的生命周期完结工夫；t_end_date = '9999-12-31'示意该条记录目前处于无效状态；如果查问以后所有无效的记录，则select * from user where t_end_date = '9999-12-31'如果查问2017-01-01的历史快照，则select * from user where t_start_date <= ‘2017-01-01′ and end_date >= '2017-01-01'。拉链表的实现与更新Hive中实现拉链表咱们须要一张ODS层的用户全量表。至多须要用它来初始化。每日的用户更新表。而且咱们要确定拉链表的工夫粒度，比如说拉链表每天只取一个状态，也就是说如果一天有3个状态变更，咱们只取最初一个状态，这种天粒度的表其实曾经能解决大部分的问题了。 ...

分层建设实践简略点儿，间接ODS+DM就能够了，将所有数据同步过去，而后间接开发些应用层的报表，这是最简略的了；当DM层的内容多了当前，想要重用，就会再拆分一个公共层进去，变成3层架构,这个过程有点相似代码重构，就是在实践中一直的进行形象、总结。 数仓的建模或者分层，其实都是为了更好的去组织、治理、保护数据,所以当你站在更高的维度去看的话，所有的划分都是为了更好的治理。小到JVM 内存区域的划分，JVM 中堆空间的划分(年老代、老年代、办法区等)，大到国家的省市区的划分，无一例外的都是为了更好的组织治理。 所以数仓分层是数据仓库设计中非常重要的一个环节，优良的分层设计可能让整个数据体系更容易了解和应用。 这一节，咱们次要是从整体上登程进行剖析和介绍，就和上一节数仓建模方法论一样，进度比照剖析，更多细节的货色咱们前面会独自拆分进去，用案例进行演示，例如维度建模，维度表的设计，事实表的设计、以及如何设计标签、如何治理标签等等。 分层的意义清晰数据结构体系每一个数据分层都有它的作用域，这样在应用表的时候能更不便的定位和了解。 数据血统追踪因为最终给业务出现的是一个能间接应用的业务表，然而表的数据起源有很多，如果有一张起源表出问题了，咱们心愿可能疾速精确的定位到问题，并分明它的影响范畴，从而及时给到业务方反馈，从而将损失降到最低。 缩小反复开发和资源节约标准数据分层，开发一些通用的中间层数据，可能缩小极大的反复计算；清晰明了的构造使得开发、保护的老本升高；缩小反复计算和存储的资源节约；简单问题简单化将一个简单的工作分解成多个步骤来实现，每一层只解决繁多的步骤，比较简单和容易了解。而且便于保护数据的准确性，当数据呈现问题之后，能够不必修复所有的数据，只须要从有问题的步骤开始修复。 在理论的建设过程中，因为业务应用数据十分紧急以及对立数仓层建设跟不上业务的须要，所以DIM和ADS层可能间接应用ODS层进行疾速的业务响应，然而这种不标准的操作可能导致数据口径不统一，所以待数仓建设结束，要切换到对立数仓层和DIM层。对立数据口径过数据分层提供对立的数据进口，对立对外输入的数据口径，这往往就是咱们说的数据应用层。 对于分层的一点思考后面咱们说到分层其实是为了更好更快更准的组织治理，然而这个是从宏观上来说的，接下来咱们从宏观上也来看一下分层。 越靠上的档次，对利用越敌对,比方ADS层，根本是齐全为利用设计,从数据聚合水平来讲，越下层的聚合水平越高，当然聚合水平越高可了解水平就越低。 数仓层外部的划分不是为了分层而分层，分层是为了解决 ETL 工作及工作流的组织、数据的流向、读写权限的管制、不同需要的满足等各类问题，当然咱们常说的分层也是面向行业而言的，也是咱们罕用分层办法，然而你须要留神的是分层仅仅是伎俩而已。 数仓的分层ods 操作数据层ODS 全称是 OperationalDataStore，操作数据层存储的是面向业务零碎的数据，也是最靠近数据源中数据的一层，数据源中的数据，通过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。 其实这里说ETL 有点不适合了，其实更精确的是ELT,你能够细细品品本层的数据，总体上大多是依照源头业务零碎的分类形式而分类的，后面咱们说到为什么在数仓次要用维度建模的状况下，咱们仍然要学习范式建模呢，因为咱们的数据源是范式建模的，所以学习范式建模能够帮忙咱们更好的了解业务零碎，了解业务数据，所以你能够认为咱们的ODS 层其实就是用的实范式建模。 然而，这一层面的数据却不等同于原始数据。在源数据装入这一层时，要进行诸如去噪(例如有一条数据中人的年龄是300岁，这种属于异样数据，就须要提前做一些解决)、去重(例如在个人资料表中，同一ID却有两条反复数据，在接入的时候须要做一步去重)、字段命名标准等一系列操作。这里的数据处理，并不波及业务逻辑，仅仅是针对数据完整性以及反复值和空值的解决，其实就是做的是数据规约，数据荡涤，然而为了思考后续可能追溯数据源问题，因而对这一层不倡议做过多的数据荡涤工作，一成不变接入源数据即可，至于数据的去噪，去重，异样值解决等过程能够放在前面的DW层 其实对于这一层，很多人的了解不太一样，那就是是否要进行数据荡涤，其实还是取决于公司的应用习惯，其实有很多公司在这一层之前也会造成一个层，名字千奇百怪，然而它的目标是数据缓冲，而后进行荡涤，荡涤之后的数据存入ODS ,而这个时候缓冲层数据寄存个别为一周左右，简直不会超过一个月；而ODS则永恒寄存。设计准则表名的设计 ODS_业务零碎_表名_标记，这样的设计能够放弃与业务表名统一，又能够有清晰的档次，还能够辨别起源。标记个别指的是其余数仓特有的属性，例如表是天级的还是小时的，是全量的还是增量的。 ods 层不做字段名归一和字段类型对立的操作，如果须要则应用兼容的数据类型对于增量表，须要设计增量表(ODS_业务零碎_表名_delta)和全量表,而后将增量表合并成全量表数据；对于半结构化数据须要设计解析；因为业务数据库（OLTP）根本依照维度模型建模，因而ODS层中的建模形式也是维度模型；ods 的设计能够保障所有的数据依照对立的标准进行存储。 DW 对立数仓层DW是数据仓库的外围，从ODS层中取得的数据依照主题建设各种数据模型。DW又细分数据明细层DWD 和轻度汇总层DWS 这一层和维度建模会有比拟深的分割，业务数据是依照业务流程不便操作的角度来组织数据的，而对立数仓层是依照业务易了解的角度或者是业务剖析的角度进行数据组织的，定义了统一的指标、维度，各业务板块、数据域都是依照对立的标准来建设，从而造成对立标准的规范业务数据体系，它们通常都是基于Kimball的维度建模实践来构建的，并通过一致性维度和数据总线来保障各个子主题的维度一致性。 如果 ods 层的数据就十分规整，根本能满足咱们绝大部分的需要，这当然是好的，这时候dwd层其实就简略了很多，然而事实中接触的状况是 ods 层的数据很难保证质量，毕竟数据的起源多种多样，推送方也会有本人的推送逻辑，在这种状况下，咱们就须要通过额定的一层 dwd 来屏蔽一些底层的差别。有没有很像JVM。设计准则一致性维度标准公共层的维度表中雷同维度属性在不同物理表中的字段名称、数据类型、数据内容必须保持一致，因为这样能够升高咱们在应用过程中犯错误的概率，例如应用了不正确的字段，或者因为数据类型的起因导致了一些奇怪的谬误 维度的组合与拆分将维度所形容业务相关性强的字段在一个物理维表实现。相关性强是指常常须要一起查问或进行报表展示、两个维度属性间是否存在人造的关系等。例如，商品根本属性和所属品牌。 DWD 明细数据层布告明细数据层，能够说是咱们数仓建设的外围了。 DWD层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、标准不统一的、状态定义不统一的、命名不标准的数据都会被解决。而后加工成面向数仓的根底明细表，这个时候能够加工一些面向剖析的大宽表。 DWD层应该是笼罩所有零碎的、残缺的、洁净的、具备一致性的数据层。在DWD层会依据维度模型，设计事实表和维度表，也就是说DWD层是一个十分标准的、高质量的、可信的数据明细层。 DWS 轻度汇总层DWS层为公共汇总层，这一层会进行轻度汇总，粒度比明细数据稍粗，基于DWD层上的根底数据，整合汇总成剖析某一个主题域的服务数据，个别是也是面向剖析宽表或者是面向某个留神的汇总表。DWS层应笼罩80%的利用场景，这样咱们能力疾速响应数据需要，否则的话，如果很多需要都要从ods开始做的话，那阐明咱们的数仓建设是不欠缺的。 例如依照业务划分，例如流量，订单，用户等，生成字段比拟多的宽表，用于后续的业务查问，OLAP剖析，数据分析等。 个别采纳维度模型办法作为实践根底，更多的采纳一些维度进化手法，将维度进化至事实表中，缩小维度表与事实表的关联，进步明细数据表的易用性；同时在汇总数据层要增强指标的维度进化，采纳更多的宽表化伎俩构建公共指标数据层，晋升公共指标的复用性，缩小反复加工。 DIM 维度层维表层，所以其实维度层就是大量维表形成的，为了对立治理这些维度表，所以咱们就建设维度层，维度表自身也有很多类型，例如稳固维度维表，突变维度维表。 维度指的是察看事物的角度，提供某一业务过程事件波及用什么过滤和分类的形容属性，"谁、什么时候、什么地点、为什么、如何"干了什么，维度示意维度建模的根底和灵魂。 比方，"小王早上在小卖部破费5元钱购买了包子"，工夫维度——早上，地点维度——小卖部，商品维度——包子 那么事实表呢？所以能够看出，维度表蕴含了业务过程记录的业务过程度量的上下文和环境。维度表都蕴含繁多的主键列，维度表设计的外围是确定维度字段，维度字段是查问约束条件(where)、分组条件(group)、排序(order)，与报表标签的根本起源。 维度表个别为繁多主键，在ER模型中，实体为客观存在的事务，会带有本人的描述性属性，属性个别为文本色、描述性的，这些形容被称为维度。维度建模的外围是数据能够形象为事实和维度，维度即察看事物的角度，事实某一粒度下的度量词，维度肯定是针对实体而言的。 每个维度表都蕴含繁多的主键列。维度表的主键能够作为与之关联的任何事实表的外键，当然，维度表行的形容环境应与事实表行齐全对应。 维度表通常比拟宽，是扁平型非标准表，蕴含大量的低粒度的文本属性。例如customer（客户表）、goods(商品表)、d_time(时间表)这些都属于维度表，这些表都有一个惟一的主键，而后在表中寄存了具体的数据信息。 设计准则维度表通常比拟宽，蕴含多个属性、是扁平的标准表，理论利用中蕴含几十个或者上百个属性的维度并不少见，所以维度表应该包含一些有意义的形容，不便上游应用。 维度表的维度属性，应该尽可能的丰盛，所以维度表中，经常出现一些反范式的设计，把其余维度属性并到主维度属性中，达到易用少关联的成果。 维度表的设计包含维度抉择，主维表的确定，梳理关联维度，定义维度属性的过程。 维度的抉择个别从报表需要和从业务人员的交谈中发现，次要用于过滤、分组、排序，主维度表个别从业务库间接同步，比方用户表，然而数仓的自身也会有本人的维度，这是因为数仓是面向剖析的，所以会有很多从剖析的角度登程的维度。 关联维度次要是不同业务零碎或者同一业务零碎的表之间存在关联性(范式建模)，依据对业务表的梳理，确定哪些表和主维度表之间存在关联关系，并抉择其中的某些表用于生成维度属性。 TDM 标签数据层随着互联网的遍及，获客老本越来越高，这也使得公司对用户经营提出了更高的要求，不仅须要精细化更须要个性化。解决这一问题的方法之一就是建设绝对齐备的标签零碎，而数仓的标签层对于标签零碎而言就像数据仓库对于数据系统一样，有着无足轻重的位置，这样的标签零碎须要与业务进行紧密结合，从业务中获取营养—用户标签，同时也要服务于业务—给用户提供更加精准和共性的服务。 ...

发展史时代的变迁，生死的轮回，历史长河滔滔，没有什么是永恒的，只有变动才是不变的，技术亦是如此，当你抉择互联网的那一刻，你就相当于乘坐了一个滚滚向前的时代列车，开往未知的方向，不管什么样的技术架构只有放在以后的时代背景下，才是有意义的，人生亦是如此。 工夫就是一把尺子，它能掂量奋斗者后退的过程；工夫就是一架天平，它能掂量奋斗者成绩的分量；工夫就是一架穿梭机，它能带咱们漫游历史长河,明天咱们看一下数仓架构的倒退，来感受一下历史的变迁，回头看一下那些已经的陈迹。筹备好了吗 let's go!，在此之前咱们先看一下，数据仓库在整个数据平台中的位置 开始之前，咱们先上一张大图，先有一个大略的认知，从整体到部分从概括到具体，看一下导致机构变动的起因是什么，探索一下时代背景下的意义，咱们顺便看一下什么是数仓 那么什么是数仓，数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、绝对稳固的（Non-Volatile）、反映历史变动（Time Variant）的数据汇合，用于反对管理决策，数据仓库在数据平台中的建设有两个环节：一个是数据仓库的构建，另外一个就是数据仓库的利用。 数据仓库是随同着企业信息化倒退起来的，在企业信息化的过程中，随着信息化工具的降级和新工具的利用，数据质变的越来越大，数据格式越来越多，决策要求越来越刻薄，数据仓库技术也在不停的倒退 这就是架构降级的起因，其实就是外部环境变了，现有的体系不能满足以后的需要，既然找到了起因，咱们就来观赏一下历史长河中哪些闪亮的星 “咱们正在从IT时代走向DT时代(数据时代)。IT和DT之间，不仅仅是技术的改革，更是思想意识的改革，IT次要是为自我服务，用来更好地自我管制和治理，DT则是激活生产力，让他人活得比你好”——阿里巴巴董事局主席马云。 经典数仓在开始之前，咱们先说一点，其实数据仓库很早之前就有了，也就是说在离线数仓之前(基于大数据架构之前)，有很多传统的数仓技术，例如基于Teradata的数据仓库，只不过是数据仓库技术在大数据背景下产生了很多扭转，也就是咱们开始摈弃了传统构建数仓的技术，转而抉择了更能满足以后时代需要的大数据技术而已，当然大数据技术并没有残缺的、彻底的取代传统的技术实现，咱们仍然能够在很多中央看见它们的身影 经典数仓能够将数仓的数仓的不同分层放在不同的数据库中，也能够将不同的分层放在不同的数据库实例上，甚至是能够把不同的分层放在不同的机房 大数据技术扭转了数仓的存储和计算形式，当然也扭转了数仓建模的理念，例如经典数仓数据存储在mysql等关系型数据库上，大数据数仓存储在hadoop平台的hive中（实际上是HDFS中），当然也有其余的数仓产品比方TD、greenplum等。 离线数仓(离线大数据架构)随着互联网时代降临，数据量暴增，开始应用大数据工具来代替经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有基本的区别，能够把这个架构叫做离线大数据架构。 随着数据量逐步增大，事实表条数达到千万级，kettle等传统ETL工具逐步变得不稳固，数据库等存储技术也面临着存储缓和，每天都陷入和磁盘的争斗中单表做拉链的工作的执行工夫也指数级减少，这个时候存储咱们开始应用HDFS而不是数据库；计算开始应用HIVE(MR)而不是传统数仓技术架构应用的kettle、Informatica 等ETL工具； 公司开始思考从新设计数仓的架构，应用hadoop平台的hive做数据仓库，报表层数据保留在mysql中，应用tableau做报表零碎，这样不必放心存储问题、计算速度也大大放慢了。在此基础上，公司凋谢了hue给各个部门应用，这样简略的提数工作能够由经营本人来操作。应用presto能够做mysql、hive的跨库查问，应用时要留神presto的数据类型十分严格。 Lambda架构起初随着网络技术、通信技术的倒退，使得终端数据的实时上报传输成为可能，从而业务实零碎发生变化，进而导致了咱们对需要的时性要求的一直进步开始之前咱们先看一下，网络技术和通信技术到底对咱们的生存有什么样的影响 为了应答这种变动，开始在离线大数据架构根底上加了一个减速层，应用流解决技术间接实现那些实时性要求较高的指标计算，而后和离线计算进整合从而给用户一个残缺的实时计算结果，这便是Lambda架构。 为了计算一些实时指标，就在原来离线数仓的根底上减少了一个实时计算的链路，并对数据源做流式革新（即把数据发送到音讯队列），实时计算去订阅音讯队列，间接实现指标增量的计算，推送到上游的数据服务中去，由数据服务层实现离线&实时后果的合并。 须要留神的是流解决计算的指标批处理仍然计算，最终以批处理为准，即每次批处理计算后会笼罩流解决的后果（这仅仅是流解决引擎不欠缺做的折中），Lambda架构是由Storm的作者Nathan Marz提出的一个实时大数据处理框架。Marz在Twitter工作期间开发了驰名的实时大数据处理框架Storm，Lambda架构是其依据多年进行分布式大数据系统的经验总结提炼而成。Lambda架构的指标是设计出一个能满足实时大数据系统要害个性的架构，包含有：高容错、低延时和可扩大等。Lambda架构整合离线计算和实时计算，交融不可变性（Immunability），读写拆散和复杂性隔离等一系列架构准则，可集成Hadoop，Kafka，Storm，Spark，Hbase等各类大数据组件。 如果抛开下面的Merge 操作，那么Lambda架构就是两条齐全不同解决流程，就像上面所示 存在的问题同样的需要须要开发两套一样的代码，这是Lambda架构最大的问题，两套代码不仅仅意味着开发艰难（同样的需要，一个在批处理引擎上实现，一个在流解决引擎上实现，还要别离结构数据测试保障两者后果统一），前期保护更加艰难，比方需要变更后须要别离更改两套代码，独立测试后果，且两个作业须要同步上线。 资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分）· 实时链路和离线链路计算结果容易让人误会，昨天看到的数据和明天看到的数据不统一** 上游解决简单，须要整合实时和离线处理结果，这一部分往往是咱们在出现给用户之前就实现了的 Kappa架构再起初，实时的业务越来越多，事件化的数据源也越来越多，实时处理从主要局部变成了次要局部，架构也做了相应调整，呈现了以实时事件处理为外围的Kappa架构。当然这不要实现这一变动，还须要技术自身的变革——Flink，Flink 的呈现使得Exactly-Once 和状态计算成为可能，这个时候实时计算的后果保障最终后果的准确性 Lambda架构尽管满足了实时的需要，但带来了更多的开发与运维工作，其架构背景是流解决引擎还不欠缺，流解决的后果只作为长期的、近似的值提供参考。起初随着Flink等流解决引擎的呈现，流解决技术很成熟了，这时为了解决两套代码的问题，LickedIn 的Jay Kreps提出了Kappa架构 Kappa架构能够认为是Lambda架构的简化版（只有移除lambda架构中的批处理局部即可）。在Kappa架构中，需要批改或历史数据重新处理都通过上游重放实现。 Kappa架构的从新处理过程 抉择一个具备重放性能的、可能保留历史数据并反对多消费者的音讯队列，依据需要设置历史数据保留的时长，比方Kafka，能够保留全副历史数据,当然还有前面呈现的Pulsar，以及专门解决实时输入存储的Pravega 当某个或某些指标有重新处理的需要时，依照新逻辑写一个新作业，而后从上游音讯队列的最开始从新生产，把后果写到一个新的上游表中。 当新作业赶上进度后，利用切换数据源，应用新产生的新后果表。进行老的作业，删除老的后果表。 存在的问题Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个能够通过减少计算资源来补救 Pravega(流式存储)想要对立流批处理的大数据处理架构，其实对存储有混合的要求 对于来自序列旧局部的历史数据，须要提供高吞吐的读性能，即catch-up read对于来自序列新局部的实时数据，须要提供低提早的 append-only 尾写 tailing write 以及尾读 tailing read 存储架构最底层是基于可扩大分布式云存储，中间层示意日志数据存储为 Stream 来作为共享的存储原语，而后基于 Stream 能够向上提供不同性能的操作:如音讯队列，NoSQL，流式数据的全文搜寻以及联合 Flink 来做实时和批剖析。换句话说，Pravega 提供的 Stream 原语能够防止现有大数据架构中原始数据在多个开源存储搜寻产品中挪动而产生的数据冗余景象，其在存储层就实现了对立的数据湖。 ...

ClickHouse简介ClickHouse是一个用于联机剖析(OLAP)的列式数据库管理系统(DBMS)。ClickHouse最后是一款名为Yandex.Metrica的产品，次要用于WEB流量剖析。ClickHouse的全称是Click Stream,Data WareHouse，简称ClickHouse。 ClickHouse十分实用于商业智能畛域，除此之外，它也可能被广泛应用于广告流量、Web、App流量、电信、金融、电子商务、信息安全、网络游戏、物联网等泛滥其余畛域。ClickHouse具备以下特点： 反对齐备的SQL操作列式存储与数据压缩向量化执行引擎关系型模型(与传统数据库相似)丰盛的表引擎并行处理在线查问数据分片ClickHouse作为一款高性能OLAP数据库，存在以下有余。 不反对事务。不善于依据主键按行粒度进行查问（尽管反对），故不应该把ClickHouse当作Key-Value数据库应用。不善于按行删除数据（尽管反对）单机装置下载RPM包本文装置形式抉择的是离线装置，能够在上面的链接中下载对应的rpm包，也能够间接百度云下载 -- rpm包地址https://packagecloud.io/Altinity/clickhouse-- 百度云地址链接：https://pan.baidu.com/s/1pFR66SzLvPYMfcpuPJww5A 提取码：gh5a在咱们装置的软件中蕴含这些包: clickhouse-client 包，蕴含 clickhouse-client 应用程序，它是交互式ClickHouse控制台客户端。clickhouse-common 包，蕴含一个ClickHouse可执行文件。clickhouse-server 包，蕴含要作为服务端运行的ClickHouse配置文件。总共蕴含四个RPM包， clickhouse-client-19.17.4.11-1.el7.x86_64.rpmclickhouse-common-static-19.17.4.11-1.el7.x86_64.rpmclickhouse-server-19.17.4.11-1.el7.x86_64.rpmclickhouse-server-common-19.17.4.11-1.el7.x86_64.rpm尖叫提醒：如果装置过程中，报错：依赖检测失败，示意短少依赖包能够先手动装置libicu-50.2-4.el7_7.x86_64.rpm依赖包 敞开防火墙## 查看防火墙状态。systemctl status firewalld## 长期敞开防火墙命令。重启电脑后，防火墙主动起来。systemctl stop firewalld## 永恒敞开防火墙命令。重启后，防火墙不会主动启动。systemctl disable firewalld零碎要求ClickHouse能够在任何具备x86_64，AArch64或PowerPC64LE CPU架构的Linux，FreeBSD或Mac OS X上运行。尽管预构建的二进制文件通常是为x86 _64编译并利用SSE 4.2指令集，但除非另有阐明，否则应用反对它的CPU将成为额定的零碎要求。这是查看以后CPU是否反对SSE 4.2的命令： grep -q sse4_2 /proc/cpuinfo && echo "SSE 4.2 supported" || echo "SSE 4.2 not supported"SSE 4.2 supported要在不反对SSE 4.2或具备AArch64或PowerPC64LE体系结构的处理器上运行ClickHouse，应该通过源构建ClickHouse进行适当的配置调整。 装置RPM包## 将rpm包上传至/opt/software目录下## 执行如下命令进行装置[root@cdh06 software]# rpm -ivh *.rpm谬误：依赖检测失败： libicudata.so.50()(64bit) 被 clickhouse-common-static-19.17.4.11-1.el7.x86_64 须要 libicui18n.so.50()(64bit) 被 clickhouse-common-static-19.17.4.11-1.el7.x86_64 须要 libicuuc.so.50()(64bit) 被 clickhouse-common-static-19.17.4.11-1.el7.x86_64 须要 libicudata.so.50()(64bit) 被 clickhouse-server-19.17.4.11-1.el7.x86_64 须要 libicui18n.so.50()(64bit) 被 clickhouse-server-19.17.4.11-1.el7.x86_64 须要 libicuuc.so.50()(64bit) 被 clickhouse-server-19.17.4.11-1.el7.x86_64 须要## 下面装置报错，短少相应的依赖包，## 须要下载绝对应的依赖包## 下载libicu-50.2-4.el7_7.x86_64.rpm进行装置即可 ...

摘要：本文次要是探讨OLAP关系型数据库框架的数据仓库平台如何设计双集群零碎，即加强零碎高可用的保障水准。以后社会、企业运行当中，大数据分析、数据仓库平台已逐步成为生产、生存的重要位置，不再是一个从属的可有可无的剖析零碎，内部监控要求、企业外部服务，涌现少量要求7*24小时在线的利用，逐渐呈现不同等级要求的双集群零碎。 数据仓库支流数据库平台均已存在多重高牢靠保障措施设计，如硬盘冗余的raid设计、数据表冗余、节点备用冗余、机柜备用数据穿插等，以及加上服务过程高可用冗余设计，其最大化水平满足数据仓库服务继续在线。 但事实场景，如数据库软件缺陷、定期加固补丁、产品迭代、硬件降级这些产品事实因素，以及来自机房、数据中心、地区、网络的内部劫难故障因素，均在升高数据仓库可用性服务水平。 鉴于数据仓库存在大量数据吞吐，针对不同数据库、不同可用性要求，若须要设计双集群冗余设计，可选技术手段别离有数据同步模式、双ETL模式、双活模式，具体探讨如下： 1. 数据同步模式a) 架构 因为数据库IO能力无限、且两个数据库间带宽无限，除了首次全量同步之后，后续通常思考增量同步技术，即如何精确、高效获取“变动数据”，个别存在日志同步技术、备份增量同步技术、逻辑数据同步； b) 日志同步技术日志同步技术，有业内最驰名Oracle Golden Gate，大部分厂家也有本人的实现形式，像Teradata近年来推出Unity CDM（变动数据播送）技术，而我司GaussDB for DWS可采纳xlog及page进行变动数据同步。 劣势：间接同步变动数据增量，数据量少，要求带宽低，但目前市面技术大都只适宜数据每日变动量较少的数据仓库环境； 劣势：事实的技术门槛高，应答各类异样场景适应能力差，对主数据库侵入性能要求高，一旦主库忙碌，同步时效低；面对全删全插等变动数据量大场景，同步吃力； c) 备份增量同步技术次要利用各数据库平台备份恢复能力，进行数据增、全量备份、复原；通常源库备份数据压缩之后，经网络传输后，解压复原到指标库；对应GaussDB for DWS可采纳roach备份复原工具实现； 劣势：利用同一技术实现增、全量数据同步，逻辑清晰，各场景容错能力强； 劣势：要求数据库反对增备能力，且往往锁期待重大； d) 逻辑数据同步该项次要波及较高的业务侵入性，即充沛获取ETL调度数据流元数据，对应数据库当日数据稳固之后，发动数据表导出-导入操作，针对数据表加工个性，抉择增全量同步规定，进行数据准实时同步。 劣势：较上述同步技术，能够实现多样选择性同步，同步过程由施行我的项目自身管制，做到表级数据同步，不须要全零碎同步，即可实现局部业务双集群； 劣势：客户化同步逻辑，操作前置依赖多，施行投入人力多，较难推广； 2. 双ETL模式a) 架构 即采纳两套独立调度平台进行数据加工，抽取同一个数据源（往往是落地稳固的数据交换平台），采纳同一套ETL代码依赖逻辑调度，各自生成指标数据，往往批量过程中，采取主库对外继续服务，待主备库数据准实时或批后校验统一后，再凋谢备库对外服务。 若双集群数据产生不统一场景，次要以主库数据为准，笼罩备库。该同步过程，须要应用到“数据同步模式”相干同步技术。 b) 参照落地架构 c) 加载源数据思考为保障两套ETL调度加载数据源统一及数据复用，往往要求搭建一个数据交换平台。因为至多存在一个文件被两套调度读取，要求数据交换平台两倍过往吞吐能力；且禁止加载的数据文件被二次笼罩，导致两套零碎加载不统一； d) 调度依赖程序思考因为ETL作业调度关系没有配置齐备，即存在A作业应用B作业的数据，但不配置依赖关系（绝大部分的状况是A作业可容忍B数据的时效，是否最新数据均能够应用，故为时效，业务上不配置依赖关系；当然也存在物理工夫上，通常B远远早于A执行），导致两套零碎A作业生成数据不统一。 该场景下，在一套调度平台无奈发现此问题，但存在两套零碎的校验比对，即发现数据不统一； 该问题倡议用户补全依赖关系，确认执行程序一致性； 当然若心愿灵便应用依赖关系，则需二次开发，管制两套调度当日时序一致性； e) ETL代码服务器思考为了防止两套ETL调度代码保护不统一，需思考对立保护渠道，蕴含不限于同一个代码存储源、版本服务器，以及代码变更机会 f) 存在不确定值的SQL函数返回ETL代码中往往存在sample、random、row_number排序这种同一份数据产生不同后果集的函数，造成两套零碎数据不统一； 该问题倡议用户应用代替函数、明确取值、惟一排序，确保最终数据一致性； 同时，该设计逻辑正确状况下，哪份数据均可被业务采信，若该数据对上游影响少，可每日批后从主库同步备库，拉平数据； g) 报错修数逻辑思考其中一套零碎的数据产生报错、修数行为，会波及到另一套零碎的保护行为； 可选作法是保留操作逻辑，待另一套零碎产生报错时反复执行一次； 其它交给数据品质校验（DQC）、数据校验去复查； h) 干涉重跑修数逻辑思考若批后重跑，两套零碎重跑逻辑统一，波及重复劳动（或撑持平台优化），绝对简略； 但波及批量过程中发现局部数据须要重跑，因为两套调度进度不统一，会导致 i) 数据校验i. 校验机会批后校验，逻辑清晰，对调度依赖少，即依据整体调度进度，做到分层、分库或整体数据校验； 准实时校验，即侵入调度环节，在每个作业实现时，均发动日志解析，提取每个SQL影响记录数，若相应作业SQL存在影响记录数不统一场景，即停止较晚实现的调度平台调度后续作业； ii. 校验伎俩增全量校验，即针对不同加工逻辑的数据表，辨别增、全量数据值，以最小代价笼罩所有业务表 iii. 校验办法通常作法有记录数、汇总值、checksum校验； 汇总值校验，通过是数值型字段间接sum、字符型计算字符长度的sum、工夫类型则转换成数值相加的比对； Checksum校验，针对全表或局部字段，进行md5或hash运算，实现两套零碎一致性比对； 对于关系型数据库，校验开销代价逐渐递增（记录数 < 汇总值 < checksum校验）；往往是联合增量校验、联合重要指标，辨别维度校验，日常增量逻辑校验，定期全量校验，在校验数据一致性和零碎性能之间获得平衡点。 ...

摘要：如何搭建数据仓库，在这个过程中都应该遵循哪些办法和准则，我的项目实际中有哪些技巧。一、数据仓库的“心脏”首先来谈谈数据模型。模型是事实世界特色的模仿和形象，比方地图、建筑设计沙盘，飞机模型等等。 而数据模型DataModel是事实世界数据特色的形象。 在数据仓库我的项目建设中，数据模型的建设具备重要的意义，客户的业务场景，流程规定，行业常识都体现在通过数据模型体现进去，在业务人员和技术人员之间搭建起来了一个沟通的桥梁，所以在国外一些数据仓库的文献中，把数据模型称之为数据仓库的心脏“TheHeartoftheDataWarehouse”。 数据模型设计的好坏间接影响数据的 稳定性易用性拜访效率存储容量保护老本二、数据仓库中数据模型，数据分层和ETL程序2.1概述数据仓库是一种通过(准)实时/批量的形式把各种内部数据源集成起来后，采纳多种形式提供给最终用户进行数据生产的信息系统。 面对繁多的上游业务零碎而言，数据仓库的一个重要工作就是进行数据荡涤和集成，造成一个标准化的规范化的数据结构，为后续的一致性的数据分析提供可信的数据根底。 另一方面数据仓库外面的数据要施展价值就须要通过多种形式体现，有用于理解企业生产情况的固定报表，有用于向管理层汇报的KPI驾驶舱，有用于大屏展现的实时数据推送，有用于部门利用的数据集市，也有用于分析师的数据实验室...对于不同的数据生产路径，数据须要从高度一致性的根底模型转向便于数据展示和数据分析的维度模型。不同阶段的数据因而须要应用不同架构特点的数据模型与之相匹配，这也就是数据在数据仓库外面进行数据分层的起因。 数据在各层数据两头的流转，就是从一种数据模型转向另外一种数据模型，这种转换的过程须要借助的就是ETL算法。打个比方，数据就是数据仓库中的原材料，而数据模型是不同产品状态的模子，不同的数据层就是仓库的各个“车间”，数据在各个“车间”的造成流水线式的传动就是依附调度工具这个流程自动化软件，执行SQL的客户端工具是流水线上的机械臂，而ETL程序就是驱动机械臂进行产品加工的算法外围。 上图是数据仓库工具箱-维度建模权威指南一书中的数据仓库混合辐射架构 2.2金融行业中的分层模型金融行业中的数据仓库是对模型建设要求最高也是最为成熟的一个行业，在多年的金融行业数据仓库我的项目建设过程中，基本上都造成了缓冲层，根底模型层，汇总层（共性加工层），以及集市层。不同的客户会依靠这四层模型做不同的演变，可能通过合并造成三层，也可能通过细分，造成5层或者6层。本文简略介绍最常见的四层模型： 缓冲层：有的我的项目也称为ODS层，简略说这一层数据的模型就是贴源的，对于仓库的用户就是在仓库外面造成一个上游零碎的落地缓冲带，原汁原味的生产数据在这一层得以保留和体现，所以这一层数据保留工夫周期较短，常见的是7~15天，最大的用处是间接提供基于源系统结构的简略原貌拜访，如审计等。 根底层：也称为核心层，根底模型层，PDM层等等。数据依照主题域进行划分整合后，较长周期地保留具体数据。这一层数据高度整合，是整个数据仓库的外围区域，是所有前面数据层的根底。这一层保留的保留的数据起码13个月，常见的是2~5年。 集市层：先跳到最初一层。集市层的数据模型具备强烈的业务意义，便于业务人员了解和应用，是为了满足部门用户，业务用户，要害治理用户的拜访和查问所应用的，而往往对接前段门户的数据查问，报表工具的拜访，以及数据挖掘剖析工具的摸索。 汇总层：汇总层其实并不是一开始就建设起来的。往往是根底层和集市层建设起来后，发现泛滥的集市层数据进行汇总，统计，加工的时候存在对根底层数据的重复查问和扫描，而不同部门的数据集市的统计算法实际上是有共性的，所以主键的在两层之间，把具备共性的汇总后果造成一个独立的数据档次，承前启后，节俭整个零碎计算资源。 2.3数据仓库常见ETL算法尽管数据仓库外面数据模型对于不同行业，不同业务场景有着千差万别，但从实质上从缓冲层到根底层的数据加工就是对于增/全量数据如何可能高效地追加到根底层的数据表中，并造成正当的数据历史变动信息链条；而从根底层到汇总层进而到集市层，则是如何通过关联，汇总，聚合，分组这几种伎俩进行数据处理。所以长期积攒下来，对于数据档次之间的数据转换算法实际上也能造成固定的ETL算法，这也是市面上很多数据仓库代码生成工具可能自动化地智能化地造成无编码方式开发数据仓库ETL脚本的起因所在。这里因为篇幅关系，只简略列举一下缓冲层到根底层常见的几种ETL算法，具体的算法对应的SQL脚本能够找工夫另起篇幅具体地介绍。 1.全表笼罩A1算法阐明：删除指标表全副数据，再插入以后数据起源数据量：全量数据实用场景：无需保留历史轨迹，只应用最新状态数据2.更新插入(Upsert)A2算法阐明：本日数据依照主键比对后更新数据，新增的数据采纳插入的形式减少数据起源数据量：增量或全量数据实用场景：无需保留历史轨迹，只应用最新状态数据3.历史拉链（Historychain）A3算法阐明：数据依照主键与上日数据进行比对，对更新数据进行当日的关链和当日开链操作，对新增数据减少当日开链的记录起源数据：增量或全量数据实用场景：须要保留历史变动轨迹的数据，这部分数据会疏忽删除信息，例如客户表、账户表等4.全量拉链（FullHistorychain）A4算法阐明：本日全量数据与拉链表中上日数据进行全字段比对，比对后果中不存在的数据进行当日关链操作，对更新数据进行当日关链和当日开链操作，对新增数据减少当日开链的记录起源数据量：全量数据实用场景：须要保留历史变动轨迹的数据，这部分数据会由数据比对出删除信息进行关链5.带删除增量拉链(Fx:DeltaHistoryChain)A5算法阐明：本日增量数据依据增量中变更标记对删除数据进行当日关链操作，对更新和新增数据与上日按主键比对后依据须要进行当日关链和当日开链操作，对新增数据减少当日开链的记录起源数据量：增量数据实用场景：须要保留历史变动轨迹的数据，这部分数据会依据CHG_CODE来判断删除信息6.追加算法（Append）A6算法阐明：删除当日/月的增量数据，插入本日/月的增量数据起源数据量：增量数据实用场景：流水类或事件类数据三、GaussDB(DWS)和数据仓库华为的GaussDB(DWS)是一种基于私有云基础架构的分布式MPP数据库。其次要面向海量数据分析场景。MPP数据库是业界实现数据仓库零碎最支流的数据库架构，这种架构的次要特点就是Shared-nothing分布式架构，由泛滥领有独立且互不共享的CPU、内存、存储等系统资源的逻辑节点（也就是DN节点）组成。 在这样的零碎架构中，业务数据被扩散存储在多个节点上，SQL被推送到数据所在位置就近执行，并行地实现大规模的数据处理工作，实现对数据处理的疾速响应。基于Shared-Nothing无共享分布式架构，也可能保障随着集群规模地扩大，业务解决能力失去线性增长。 点击关注，第一工夫理解华为云陈腐技术~

数仓开发常常须要与数据表打交道，那么数仓表开发实现之后就高枕无忧了吗？显然不是，还须要思考一下如何剖析数据以及如何出现数据，因为这是施展数据价值很重要的一个方面。通过数据的剖析与可视化出现能够更加直观的提供数据背地的机密，从而辅助业务决策，实现真正的数据赋能业务。通过本文你能够理解到： 帕累托分析方法与数据可视化RFM剖析与数据可视化波士顿矩阵与数据可视化帕累托剖析与数据可视化基本概念帕累托(Pareto)分析法，又称ABC分析法，即咱们平时所提到的80／20法令。对于帕累托(Pareto)分析法，在不同的行业都有不同的利用。 举个栗子在企业的库存治理中，能够发现多数种类在总需用量(或是总供给额、库存总量、储备金总额)中，占了很大的比重，但在相应的量值中所占的比重很少。因而能够使用帕累托分析法，将企业所需的各种物品，按其需用量的大小、物品的重要水平、资源短缺和洽购的难易水平、单价的高下、占用储备资金的多少等因素分为若干类，施行分类管理。 商品销售额剖析中，某些商品的销售额占了总销售额的很大部分，某些商品的销售额仅占很小的比例，这样就能够将其分为A、B、C几大类，对销售额占比拟多的分类进行投入，以取得更多的销售额。 在品质剖析中，对某种原因导致产品质量不合格的产品数量进行剖析，应用帕累托(Pareto)分析法，能够很直观的看出哪些起因造成了产品质量不合格以及哪些起因比较严重。这样就能够着重解决重要的问题，明确指标，更易于操作。 另一种表述形式依据事物在技术或经济方面的次要特色，进行分类，分清重点与非重点。对每一种分类进行区别对待治理，把被剖析的对象分成 A、B、C 三类，三类物品没有明确的划分数值界线。 分类与重要水平形容A类(十分重要)数量占比少，价值占比大B类(比拟重要)没有A类那么重要，介于 A、C 之间C类(个别重要)数量占比大但价值占比很小分类的核心思想：多数奉献了大部分价值。以商品品类和销售额为例：A 品类数量占总体 10% ，却奉献了 80% 的销售额。 数据分析案例效果图 实现步骤假如有如下数据集格局： 品牌销售额NEW BALANCE(新百伦)8750ZIPPO(之宝)9760OCTMAMI(十月妈咪)5800须要将数据加工成上面的格局： 品牌销售额销售总额累计销售额累计销售额占比 =∑所有品牌销售额=以后品牌销售额 +上一个品牌销售额累计销售额/销售总额具体的SQL实现如下： SELECT brand, -- 品牌 total_money, -- 销售额 sum(total_money) over() AS sum_total_money,-- 销售总额 sum(total_money) over(ORDER BY total_money DESC ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS acc_sum_total_money -- 累计销售额FROM sales_money下面给出了具体的SQL实现，其实BI工具曾经内置了许多的处理函数和拖拽式的数据处理，不须要写SQL也能够将一份明细数据加工成下面的模式。 论断剖析从下面的帕累托图中能够看出：A类的(绿色局部)占了总销售额的80%左右，B类(黄色局部)占总销售额的10%,C类(红色局部)占总销售额的10%。接下来能够进行长尾剖析，制订营销策略等等。 RFM剖析与数据可视化基本概念RFM模型是在客户关系治理(CRM)中罕用到的一个模型,RFM模型是掂量客户价值和客户创利能力的重要工具和伎俩。该模型通过一个客户的近期购买行为、购买的总体频率以及花了多少钱三项指标来形容该客户的价值情况。 RFM模型较为动静地层示了一个客户的全副轮廓，这对个性化的沟通和服务提供了根据，同时，如果与该客户打交道的工夫足够长，也可能较为准确地判断该客户的长期价值(甚至是一生价值)，通过改善三项指标的情况，从而为更多的营销决策提供反对。 在RFM模式中，包含三个要害的因素，别离为： R(Recency)：示意客户最近一次购买的工夫有多远，即最近的一次生产，生产工夫越近的客户价值越大F(Frequency)：示意客户在最近一段时间内购买的次数，即生产频率，常常购买的用户也就是熟客，价值必定比偶然来一次的客户价值大M (Monetary)：示意客户在最近一段时间内购买的金额，即客户的生产能力，通常以客户单次的均匀生产金额作为掂量指标，生产越多的用户价值越大。最近一次生产、生产频率、生产金额是测算消费者价值最重要也是最容易的办法，这充沛的体现了这三个指标对营销流动的指导意义。而其中，最近一次生产是最无力的预测指标。 通过下面剖析能够对客户群体进行分类： 客户类型与等级RFM客户特色重要价值客户(A级/111)高(1)高(1)高(1)最近生产工夫近、生产频次和生产金额都很高重要倒退客户(A级/101)高(1)低(0)高(1)最近生产工夫较近、生产金额高，但频次不高，忠诚度不高，很有后劲的用户，必须重点倒退重要放弃客户(B级/011)低(0)高(1)高(1)最近生产工夫交远，生产金额和频次都很高。重要挽留客户(B级/001)低(0)低(0)高(1)最近生产工夫较远、生产频次不高，但生产金额高的用户，可能是将要散失或者曾经要散失的用户，该当基于挽留措施。个别价值客户(B级/110)高(1)高(1)低(0)最近生产工夫近，频率高，但生产金额低，须要进步其客单价。个别倒退客户(B级/100)高(1)低(0)低(0)最近生产工夫较近、生产金额，频次都不高。个别放弃客户(C级/010)低(0)高(1)低(0)最近生产工夫较远、生产频次高，但金额不高。个别挽留客户(C级/000)低(0)低(0)低(0)都很低数据分析案例效果图 实现步骤假如有如下的样例数据： 客户名称日期生产金额生产数量上海**有限公司2020-05-20768022630须要将数据集加工成如下格局： ...

数仓开发常常须要与数据表打交道，那么数仓表开发实现之后就高枕无忧了吗？显然不是，还须要思考一下如何剖析数据以及如何出现数据，因为这是施展数据价值很重要的一个方面。通过数据的剖析与可视化出现能够更加直观的提供数据背地的机密，从而辅助业务决策，实现真正的数据赋能业务。通过本文你能够理解到： 帕累托分析方法与数据可视化RFM剖析与数据可视化波士顿矩阵与数据可视化帕累托剖析与数据可视化基本概念帕累托(Pareto)分析法，又称ABC分析法，即咱们平时所提到的80／20法令。对于帕累托(Pareto)分析法，在不同的行业都有不同的利用。 举个栗子在企业的库存治理中，能够发现多数种类在总需用量(或是总供给额、库存总量、储备金总额)中，占了很大的比重，但在相应的量值中所占的比重很少。因而能够使用帕累托分析法，将企业所需的各种物品，按其需用量的大小、物品的重要水平、资源短缺和洽购的难易水平、单价的高下、占用储备资金的多少等因素分为若干类，施行分类管理。 商品销售额剖析中，某些商品的销售额占了总销售额的很大部分，某些商品的销售额仅占很小的比例，这样就能够将其分为A、B、C几大类，对销售额占比拟多的分类进行投入，以取得更多的销售额。 在品质剖析中，对某种原因导致产品质量不合格的产品数量进行剖析，应用帕累托(Pareto)分析法，能够很直观的看出哪些起因造成了产品质量不合格以及哪些起因比较严重。这样就能够着重解决重要的问题，明确指标，更易于操作。 另一种表述形式依据事物在技术或经济方面的次要特色，进行分类，分清重点与非重点。对每一种分类进行区别对待治理，把被剖析的对象分成 A、B、C 三类，三类物品没有明确的划分数值界线。 分类与重要水平形容A类(十分重要)数量占比少，价值占比大B类(比拟重要)没有A类那么重要，介于 A、C 之间C类(个别重要)数量占比大但价值占比很小分类的核心思想：多数奉献了大部分价值。以商品品类和销售额为例：A 品类数量占总体 10% ，却奉献了 80% 的销售额。 数据分析案例效果图 实现步骤假如有如下数据集格局： 品牌销售额NEW BALANCE(新百伦)8750ZIPPO(之宝)9760OCTMAMI(十月妈咪)5800须要将数据加工成上面的格局： 品牌销售额销售总额累计销售额累计销售额占比 =∑所有品牌销售额=以后品牌销售额 +上一个品牌销售额累计销售额/销售总额具体的SQL实现如下： SELECT brand, -- 品牌 total_money, -- 销售额 sum(total_money) over() AS sum_total_money,-- 销售总额 sum(total_money) over(ORDER BY total_money DESC ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS acc_sum_total_money -- 累计销售额FROM sales_money下面给出了具体的SQL实现，其实BI工具曾经内置了许多的处理函数和拖拽式的数据处理，不须要写SQL也能够将一份明细数据加工成下面的模式。 论断剖析从下面的帕累托图中能够看出：A类的(绿色局部)占了总销售额的80%左右，B类(黄色局部)占总销售额的10%,C类(红色局部)占总销售额的10%。接下来能够进行长尾剖析，制订营销策略等等。 RFM剖析与数据可视化基本概念RFM模型是在客户关系治理(CRM)中罕用到的一个模型,RFM模型是掂量客户价值和客户创利能力的重要工具和伎俩。该模型通过一个客户的近期购买行为、购买的总体频率以及花了多少钱三项指标来形容该客户的价值情况。 RFM模型较为动静地层示了一个客户的全副轮廓，这对个性化的沟通和服务提供了根据，同时，如果与该客户打交道的工夫足够长，也可能较为准确地判断该客户的长期价值(甚至是一生价值)，通过改善三项指标的情况，从而为更多的营销决策提供反对。 在RFM模式中，包含三个要害的因素，别离为： R(Recency)：示意客户最近一次购买的工夫有多远，即最近的一次生产，生产工夫越近的客户价值越大F(Frequency)：示意客户在最近一段时间内购买的次数，即生产频率，常常购买的用户也就是熟客，价值必定比偶然来一次的客户价值大M (Monetary)：示意客户在最近一段时间内购买的金额，即客户的生产能力，通常以客户单次的均匀生产金额作为掂量指标，生产越多的用户价值越大。最近一次生产、生产频率、生产金额是测算消费者价值最重要也是最容易的办法，这充沛的体现了这三个指标对营销流动的指导意义。而其中，最近一次生产是最无力的预测指标。 通过下面剖析能够对客户群体进行分类： 客户类型与等级RFM客户特色重要价值客户(A级/111)高(1)高(1)高(1)最近生产工夫近、生产频次和生产金额都很高重要倒退客户(A级/101)高(1)低(0)高(1)最近生产工夫较近、生产金额高，但频次不高，忠诚度不高，很有后劲的用户，必须重点倒退重要放弃客户(B级/011)低(0)高(1)高(1)最近生产工夫交远，生产金额和频次都很高。重要挽留客户(B级/001)低(0)低(0)高(1)最近生产工夫较远、生产频次不高，但生产金额高的用户，可能是将要散失或者曾经要散失的用户，该当基于挽留措施。个别价值客户(B级/110)高(1)高(1)低(0)最近生产工夫近，频率高，但生产金额低，须要进步其客单价。个别倒退客户(B级/100)高(1)低(0)低(0)最近生产工夫较近、生产金额，频次都不高。个别放弃客户(C级/010)低(0)高(1)低(0)最近生产工夫较远、生产频次高，但金额不高。个别挽留客户(C级/000)低(0)低(0)低(0)都很低数据分析案例效果图 实现步骤假如有如下的样例数据： 客户名称日期生产金额生产数量上海**有限公司2020-05-20768022630须要将数据集加工成如下格局： ...

无论是数仓开发还是数据分析，写一手好的SQL是一项根本的技能。毋庸置疑，编写性能较好的SQL是十分重要的，然而，SQL的可读性同样是不容小觑的。一个有着凌乱格局的SQL脚本，往往须要破费较长的工夫去弄清楚脚本的具体逻辑。如果你已经被祖传的毫无章法的SQL脚本狂虐过，你肯定心有感触。本文将分享几个SQL格局的标准，当然仁者见仁智者见智，其实没有严格的规范，如果有，那就是保障易于浏览和易于保护。 秦人不暇自哀，而后人哀之；前人哀之而不鉴之，亦使前人而复哀前人也大小写保持一致能够对SQL关键字应用不同的大小写，然而要保持一致。看看这个： SELECT customer_city,count(*) from dim_customer WHERE customerProvince = '上海' Group by customer_city下面的SQL语句是不是很让人抓狂，大小写混用，看起来很不标准。总结起来，要留神上面几点： SQL的关键字能够大写，也能够小写，然而不要大小写混用。下面的SQL查问既有齐全大写，也有首字母大写，更有小写。看似是不拘小节，然而万万使不得。因为大小写是混合的，因而很难辨别小写的关键字实际上是关键字还是列。此外，浏览也很烦人。字段命名要保持一致的格调，下面的SQL与中customer_city是小写加下划线，而customerProvince字段是驼峰命名法，这种不一致性显然是不可取的。进行一些标准之后后，查问应如下所示： SELECT customer_city, count(*)FROM dim_customerWHERE customer_province = '上海'GROUP BY customer_city应用缩进再来看看上面的一条查问语句： SELECT dp.region_name,count(*) FROM user_behavior_log ubl JOIN dim_province dp ON ubl.province = dp.province_name WHERE ubl.province = '上海市' GROUP BY dp.region_name将下面的SQL语句格式化上面的模式： SELECT dp.region_name, count(*)FROM user_behavior_log ublJOIN dim_province dp ON ubl.province = dp.province_nameWHERE ubl.province = '上海市'GROUP BY dp.region_name下面的格式化模式仿佛清晰了很多，然而如果语句中蕴含了子查问、多个JOIN以及窗口函数时，同样会显得对浏览不是很敌对。 再换一种格式化形式，如下： SELECT dp.region_name, count(*)FROM user_behavior_log ubl JOIN dim_province dp ON ubl.province = dp.province_nameWHERE ubl.province = '上海市'GROUP BY dp.region_name-- 或者上面的模式SELECT dp.region_name ,count(*)FROM user_behavior_log ubl JOIN dim_province dp ON ubl.province = dp.province_nameWHERE ubl.province = '上海市'GROUP BY dp.region_name尖叫提醒：对于第二种模式，在SELECT字段中，从第二个字段开始，每个字段后面增加一个逗号，而不是每个字段前面应用逗号结尾。这种形式能够很不便地辨认FROM后面是否存在逗号，从而造成语法错误。当然，这个只是集体习惯问题，并不是硬性的规定。另外下面的SQL语句应用了4个字符缩进，当然也能够抉择2个字符缩进，这个也是集体习惯问题。 ...

无论是数仓开发还是数据分析，写一手好的SQL是一项根本的技能。毋庸置疑，编写性能较好的SQL是十分重要的，然而，SQL的可读性同样是不容小觑的。一个有着凌乱格局的SQL脚本，往往须要破费较长的工夫去弄清楚脚本的具体逻辑。如果你已经被祖传的毫无章法的SQL脚本狂虐过，你肯定心有感触。本文将分享几个SQL格局的标准，当然仁者见仁智者见智，其实没有严格的规范，如果有，那就是保障易于浏览和易于保护。 秦人不暇自哀，而后人哀之；前人哀之而不鉴之，亦使前人而复哀前人也大小写保持一致能够对SQL关键字应用不同的大小写，然而要保持一致。看看这个： SELECT customer_city,count(*) from dim_customer WHERE customerProvince = '上海' Group by customer_city下面的SQL语句是不是很让人抓狂，大小写混用，看起来很不标准。总结起来，要留神上面几点： SQL的关键字能够大写，也能够小写，然而不要大小写混用。下面的SQL查问既有齐全大写，也有首字母大写，更有小写。看似是不拘小节，然而万万使不得。因为大小写是混合的，因而很难辨别小写的关键字实际上是关键字还是列。此外，浏览也很烦人。字段命名要保持一致的格调，下面的SQL与中customer_city是小写加下划线，而customerProvince字段是驼峰命名法，这种不一致性显然是不可取的。进行一些标准之后后，查问应如下所示： SELECT customer_city, count(*)FROM dim_customerWHERE customer_province = '上海'GROUP BY customer_city应用缩进再来看看上面的一条查问语句： SELECT dp.region_name,count(*) FROM user_behavior_log ubl JOIN dim_province dp ON ubl.province = dp.province_name WHERE ubl.province = '上海市' GROUP BY dp.region_name将下面的SQL语句格式化上面的模式： SELECT dp.region_name, count(*)FROM user_behavior_log ublJOIN dim_province dp ON ubl.province = dp.province_nameWHERE ubl.province = '上海市'GROUP BY dp.region_name下面的格式化模式仿佛清晰了很多，然而如果语句中蕴含了子查问、多个JOIN以及窗口函数时，同样会显得对浏览不是很敌对。 再换一种格式化形式，如下： SELECT dp.region_name, count(*)FROM user_behavior_log ubl JOIN dim_province dp ON ubl.province = dp.province_nameWHERE ubl.province = '上海市'GROUP BY dp.region_name-- 或者上面的模式SELECT dp.region_name ,count(*)FROM user_behavior_log ubl JOIN dim_province dp ON ubl.province = dp.province_nameWHERE ubl.province = '上海市'GROUP BY dp.region_name尖叫提醒：对于第二种模式，在SELECT字段中，从第二个字段开始，每个字段后面增加一个逗号，而不是每个字段前面应用逗号结尾。这种形式能够很不便地辨认FROM后面是否存在逗号，从而造成语法错误。当然，这个只是集体习惯问题，并不是硬性的规定。另外下面的SQL语句应用了4个字符缩进，当然也能够抉择2个字符缩进，这个也是集体习惯问题。 ...

20世纪80年代末期，数据仓库技术衰亡。自Ralph Kimball 于1996 年首次出版The Data Warehouse Toolkit(Wiley)一书以来，数据仓库和商业智能(Data Warehousing and Business Intelligence, DW/BI)行业渐趋成熟。Kimball提出了数据仓库的建模技术--维度建模(dimensional modelling),该办法是在实际察看的根底上开发的。尽管它不基于任何实践，然而在实践中却十分胜利。维度建模被视为设计数据仓库和数据集市的次要办法，对数据建模和数据库设计学科有着重要的影响。时至今日，维度建模仍然是构建数仓首选的数据建模办法，然而随着技术的倒退，获取超强的存储与计算能力的老本会变得很便宜。这在无形之中对传统的维度建模办法产生了肯定的影响。本文将探讨以下内容： 维度建模的概念维度建模的优缺点为什么星型模型仍然有用数据建模产生了哪些变动规定是用来被突破的First learn the rules, then break them 维度建模的概念事实表事实表作为数据仓库维度建模的外围，紧紧围绕着业务过程来设计，通过获取形容业务过程的度量来表白业务过程，蕴含了援用的维度和与业务过程无关的度量。 事实表中一条记录所表白的业务细节水平被称为粒度。通常粒度能够通过两种形式来表述：一种是维度属性组合所示意的细节水平；一种是所示意的具体业务含意。 作为度量业务过程的事实，个别为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型。可加性事实是指能够依照与事实表关联的任意维度进行汇总。半可加性事实只能依照特定维度汇总，不能对所有维度汇总，比方库存能够依照地点和商品进行汇总，而按工夫维度把一年中每个月的库存累加起来则毫无意义。还有一种度量齐全不具备可加性，比方比率型事实。对于不可加性事实可分解为可加的组件来实现汇集。 事实表通常只有很少的列和很多行，是一种"瘦高"型的表。事实表定义为以下三种类型之一： 事务事实表:记录无关特定事件的事实（例如，销售事件，保留在原子的粒度，也称为原子事实表）周期快照事实表记录给定工夫点的事实（例如，月末的帐户详细信息）累积快照事实表记录了给定工夫点的汇总事实（例如，某产品的当月迄今总销售额）维表维度是维度建模的根底和灵魂。在维度建模中，将度量称为事实，将环境形容为维度，维度是用于剖析事实所须要的多样环境。例如，在剖析交易过程时，能够通过买家、卖家、商品和工夫等维度形容交易产生的环境。维度所蕴含的示意维度的列，称为维度属性。维度属性是查问约束条件、分组和报表标签生成的根本起源，是数据易用性的要害。 维度通常是限定事实的描述性信息。例如，产品维度中的每个记录代表一个特定的产品。与事实表相比，维表通常具备绝对较少的记录，然而每个记录可能具备大量的属性来形容事实数据。维度能够定义各种各样的特色，一些常见的维表： 工夫维度表：以最低工夫粒度级别形容工夫天文维度表：形容了地位数据，例如国家/地区/城市产品维度表：表形容了产品的详细信息员工维度表：形容了员工，例如销售人员星型模型大多数的数据仓库都采纳星型模型。星型模型是由事实表和多个维表组成。事实表中寄存大量对于企业的事实数据，元祖个数通常很大，而且非规范化水平很高。例如，多个期间的数据可能会呈现在同一个表中。维表中通常寄存描述性数据，维表是围绕事实表建设的，通常来说具备较少的行。如下图所示： 星型模型存取数据速度快，次要是针对各个维做了大量预处理，如依照维度进行事后的统计、分组合排序等。与规范化的关系型数据库设计相比，星型模型是非规范化的，通过数据冗余晋升多维数据的查问速度，减少了存储空间的代价。当业务问题发生变化、原来的维度不能满足需要时，须要减少新的维度。因为事实表的主键由所有维表的主键组成，这种维的变动带来的数据变动将是非常复杂和耗时的。一个星型模型的示例： 雪花模型雪花模型是对星型模型的扩大，它将星型模型的维表进一步层次化，原来的各个维表可能被扩大为小的事实表，造成一些部分的档次区域。在雪花模型中可能定义多重父类维来形容某些非凡的维表，如在工夫维上减少月维表和年维表，通过查看与工夫无关的父类维，可能定义非凡的工夫统计信息，如月统计和年统计等。 雪花模式通过更多的连贯引入了更多的复杂性。随着存储变得越来越便宜，大多数状况，个别不采纳雪花模型办法。 雪花模型的有点是最大限度地缩小数据存储量，以及把较小的维表联结在一起来改善查问性能。然而它减少了用户必须解决的表的数量，减少了某些查问的复杂性。如下所示： 维度建模的优缺点长处每次须要从数据库中获取一些信息时，能够不必编写简短的查问针对读取进行了优化，能够写更少的JOIN，更快地返回后果毛病对数据进行非规范化意味着一次性插入或更新会导致数据异样。在实践中，星型模型是通过批处理实来补救这一问题剖析灵活性无限。星型模型通常是为特定目标而设计的。在剖析需要方面，它不像规范化数据模型那样灵便为什么星型模型仍然有用多种数据源公司从各种数据源中收集越来越多的数据，因而须要对后果数据集进行整顿以进行剖析，从而缩小异构数据源带来的剖析复杂性。 规范由Ralph Kimball编写的Data Warehouse Toolkit定义了业界宽泛了解的概念。新员工能够疾速把握数据仓库的构造，而无需相熟具体的业务零碎数据。数据工程师和分析师通常对事实、维度、粒度这些概念比拟理解，从而能够促成合作。 可扩展性新增加的事实表能够重用现有的维度。通过向事实表增加更多外键，实现向事实表增加新维度。另外，对于集成新的数据集，无需对模型进行重大调整。 数据建模产生了哪些变动大数据时代，突飞猛进的技术倒退促使存储和计算产生了翻天覆地的变动(存储和计算比以往任何时候都便宜)，因而数据模型也相应地产生了一些变动。 迟缓变动维(SCD)对于随工夫而变动的维度，比方：用户能够更改其家庭住址，产品能够更改名称。所以须要一种策略保留历史某个工夫点对应的维度信息。 Kimball书中介绍了许多类型的SCD策略，大多数应用UPDATE就地增加或批改信息。在保留历史记录的维度中，当记录中的任何属性产生更改时，都须要复制整行数据,当属性常常更改时，同样会应用更多存储空间。值得注意的是，这些技术很简单，因为它们是在严格的存储束缚下设计的。 其实，能够应用维度快照来解决SCD的问题，尽管须要更多的存储空间，但创立和查问更简略。 维度快照维度应比事实小得多。电子商务的交易，订单可能数以百万/千万计，然而客户（维度）的数量会少得多。 每天咱们都会在版本快照中从新写入整个维度表 /data_warehouse/dim_users/ds = 2020-01-01/data_warehouse/dim_users/ds = 2020-01-02 ...因为每天有一个快照数据，因而不论产生多少变动都没有影响。这种形式非常简单粗犷，但与简单的不同类型的迟缓变动维策略相比，不失为一种可选的计划。 应用此种形式，能够通过JOIN特定日期的维度快照来获取历史某个工夫点的维度信息。另外，这种形式不会对查问速度产生影响，因为通过分区日期能够间接定位抉择的日期，而不是加载所有的数据。 系统地对维度进行快照（为每个ETL打算周期存储维度的残缺正本，通常在不同的表分区中），作为解决迟缓变动的维度（SCD）的通用办法，是一种简略的通用办法，不须要太多的工程工作，并且与经典办法相比，在编写ETL和查问时很容易把握。 简单的SCD建模技术并不直观，并且会升高可拜访性。 分区为了防止上游数据处理谬误导致事实表装载谬误，须要从数据源零碎中提取日期作为分区字段，这样能够实现数据装载的幂等性。此外，倡议按 事件日期 进行分区，因为查问通常会将其用作过滤器（WHERE子句）。 代理键与冗余维度在维表中保护代理键是非常复杂的，除此之外，还会使事实表的可读性变差。在事实表中应用天然键和维度冗余的形式越来越广泛，这样能够缩小JOIN带来的性能开销。值得注意的是，反对编码和压缩的序列化格局(如Parquet、ORC)解决了非规范化相干的大多数性能损失。 总结本文次要介绍了维度建模的基本概念，包含维表、事实表、星型模型和雪花模型。其次对星型模型的优缺点进行了论述。最初指出了维度建模正在产生的一些变动。 公众号『大数据技术与数仓』，回复『材料』支付大数据资料包

作者 | 傅一平 来源 | 与数据同行今天跟着我来学学数据仓库的基础知识，希望你结合案例可以把它吃透。 一、数据仓库建模的意义如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。 数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，最能够说明数据模型的重要性。 只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用。 性能：帮助我们快速查询所需要的数据，减少数据的I/O吞吐，提高使用数据的效率，如宽表。 成本：极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低存储和计算成本。 效率：在业务或系统发生变化时，可以保持稳定或很容易扩展，提高数据稳定性和连续性。 质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。数据模型能够促进业务与技术进行有效沟通，形成对主要业务定义和术语的统一认识，具有跨部门、中性的特征，可以表达和涵盖所有的业务。 大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡！ 下图是个示例，通过统一数据模型，屏蔽数据源变化对业务的影响，保证业务的稳定，表述了数据仓库模型的一种价值： 二、数据仓库分层的设计为了实现以上的目的，数据仓库一般要进行分层的设计，其能带来五大好处： 清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。 数据血缘追踪：能够快速准确地定位到问题，并清楚它的危害范围。 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。 把复杂问题简单化：将复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。当数据出现问题之后，不用修复所有的数据，只需要从有问题的步骤开始修复。 屏蔽原始数据的异常：不必改一次业务就需要重新接入数据。 以下是我们的一种分层设计方法，数据缓冲区（ODS）的数据结构与源系统完全一致。基础数据模型(DWD)和融合数据模型（DWI与DWA）是大数据平台重点建设的数据模型。应用层模型由各应用按需自行建设，其中基础数据模型一般采用ER模型，融合数据模型采用维度建模思路。 三、两种经典的数据仓库建模方法前面的分层设计中你会发现有两种设计方法，关系建模和维度建模，下面分别简单介绍其特点和适用场景。 1、维度建模 （1）定义 维度模型是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。 典型的代表是我们比较熟知的星形模型： <figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">维度退化</figcaption> 星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。 这也是我们在使用hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。 （2）建模方法 通常需要选择某个业务过程，然后围绕该过程建立模型，其一般采用自底向上的方法，从明确关键业务过程开始，再到明确粒度，再到明确维度，最后明确事实，非常简单易懂。 以下是阿里的OneData的建模工作流，可以参考。 （3）优缺点 优点：技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模复杂查询的响应性能 缺点：维度表的冗余会较多，视野狭窄 2、关系建模 （1）定义 是数据仓库之父Inmon推崇的、从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象。 它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的“single version of the truth”。 ...

数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务，数据仓库的建设也是“数据智能”中必不可少的一环。本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个方面全面分享关于数仓的详细内容。 1.数据仓库简介数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。 数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变的越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术也在不停的发展。数据仓库的趋势： 实时数据仓库以满足实时化&自动化决策需求；大数据&数据湖以支持大量&复杂数据类型（文本、图像、视频、音频）； 2.数据仓库的发展数据仓库有两个环节：数据仓库的构建与数据仓库的应用。 早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略型决策）。 随着业务和环境的发展，这两方面都在发生着剧烈变化。 随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站 log，IoT 设备数据，APP 埋点数据等，这些数据量比以往结构化的数据大了几个量级，对 ETL 过程、存储都提出了更高的要求；互联网的在线特性也将业务需求推向了实时化，随时根据当前客户行为而调整策略变得越来越常见，比如大促过程中库存管理，运营管理等（即既有中远期策略型，也有短期操作型）；同时公司业务互联网化之后导致同时服务的客户剧增，有些情况人工难以完全处理，这就需要机器自动决策。比如欺诈检测和用户审核。 总结来看，对数据仓库的需求可以抽象成两方面：实时产生结果、处理和保存大量异构数据。 注：这里不讨论数据湖技术。3.数据仓库建设方法论3.1 面向主题从公司业务出发，是分析的宏观领域，比如供应商主题、商品主题、客户主题和仓库主题 3.2 为多维数据分析服务数据报表；数据立方体，上卷、下钻、切片、旋转等分析功能。 3.3 反范式数据模型以事实表和维度表组成的星型数据模型 4.数据仓库架构的演变数据仓库概念是 Inmon 于 1990 年提出并给出了完整的建设方法。随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构。 后来随着业务实时性要求的不断提高，人们开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是 Lambda 架构。 再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的 Kappa 架构。 4.1 离线大数据架构数据源通过离线的方式导入到离线数仓中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务，比如 MySQL 或 Redis。数据仓库从模型层面分为三层： ODS，操作数据层，保存原始数据；DWD，数据仓库明细层，根据主题定义好事实与维度表，保存最细粒度的事实数据；DM，数据集市/轻度汇总层，在 DWD 层的基础之上根据不同的业务需求做轻度汇总；典型的数仓存储是 HDFS/Hive，ETL 可以是 MapReduce 脚本或 HiveSQL。 4.2 Lambda 架构随着大数据应用的发展，人们逐渐对系统的实时性提出了要求，为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。 注：流处理计算的指标批处理依然计算，最终以批处理为准，即每次批处理计算后会覆盖流处理的结果。（这仅仅是流处理引擎不完善做的折中）Lambda 架构问题： 同样的需求需要开发两套一样的代码：这是 Lambda 架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分 4.3 Kappa 架构Lambda 架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的 Jay Kreps 提出了 Kappa 架构。 ...

8月26日，阿里云透露，正投入自研数据存储“超级高速”，核心存储产品ESSD已率先采用这一最新的自研存储网络协议，并实现大规模商用，数据传输效率提高50%。 据了解，未来该协议还将继续演进，有望取代传统TCP网络协议。此前，谷歌、微软也曾先后发表论文试图突破瓶颈，但都未大规模应用。 随着AIoT时代的到来，所有数据都要求实时采集、传输、计算，传统 TCP 和 RDMA 网络都无法完美适配云时代的存储需求。 ESSD是业内首个百万级 IOPS 、百微秒延时云存储产品，相当于一个千万平米的巨型数据仓库，自带时速超过120公里的超级高速，仅需1秒就可以完成1部高清电影的传输和存储。 其优异的性能得益于阿里云的多项技术自研，底层架构基于自研大规模分布式存储系统盘古 2.0，存储芯片采用自研Aliflash SSD，并且依托自研网络协议 Luna 和增强型RDMA 数据传输协议，结合自研HPCC流控算法，深度优化TCP，大幅降低计算资源消耗及响应延时，使ESSD的数据传输效率可提高50%。 采用全新网络协议的ESSD已正式商用，目前服务数万企业，涵盖自动驾驶、工业物联网、AR/VR、证券交易、电商搜索等数据高并发领域。 “ESSD为企业数据存储和业务敏捷创新提供了新的可能，成为AIoT海量数据存储场景的标配。”阿里云智能存储产品资深总监Alex Chen表示。 阿里云拥有全球最丰富的云存储产品家族，总数据存储量达数十EB，凭借多层次防护、跨区域容灾等能力连续三年入选Gartner全球云存储魔力象限，并且被列为全球领导者地位。 本文作者：阿里云头条阅读原文 本文为云栖社区原创内容，未经允许不得转载。

随着大数据技术的迅速发展以及对数据价值的认识逐渐加深，大数据已经融合到各行各业。据可靠权威数据显示，超过39.6%的企业正在应用数据并从中获益，超过89.6%的企业已经成立或计划成立相关的大数据分析部，超过六成的企业在扩大数据的投入力度度。在这样的大数据行业背景下AnalyticDB for MySQL3.0基础版发布了。AnalyticDB for MySQL3.0（以下简称ADB for MySQL3.0）基础版是在总结ADB for MySQL2.0产品研发与应用经验的基础上，匠心打磨推出的新一代分析型数据库，目前正在火热公测中。 ADB for MySQL3.0基础版融合了分布式、弹性计算与云计算的优势，对规模性、易用性、可靠性和安全性等方面进行了大规模的改进，充分满足不同场景数据仓库的需求。支持更大规模的并发访问、更快读写能力以及更智能的混合查询负载管理等，实现更精细化的资源利用和更低成本的投入，让用户能更加专注于业务发展，专注于数据价值。 相比于ADB for MySQL 2.0版本，3.0版本具有以下核心价值： 核心价值简单易用 好用是数据库价值真正的体现，ADB for MySQL3.0基础版高度兼容MySQL，更好的MySQL协议兼容以及完整的SQL和语法支持，大多数场景无需修改代码即可用ADB for MySQL3.0版平滑替换MySQL，迁移使用成本极低。对于MySQL社区周边工具也可以无缝接入。 更高性价比 支持按量付费和包年包月，除了灵活的计费模式外还支持单独磁盘扩容。磁盘灵活扩缩对用户而言最直接红利是进一步降低了成本。新购时根据实际使用量购买相应磁盘空间，无需为固定的多余空间买单；当用户磁盘达到瓶颈时降低了由于翻倍扩容来带的额外成本。 除了支持磁盘灵活扩缩外，ADB for MySQL 3.0版本售价也大幅度降低。以C8规格为例，其售卖价格比2.0版本同等规格便宜最多21%。 云原生 OSS分层存储，冷热数据分离存储，历史数据无限保留；无缝对接云端海量算力(PolarDB和DLA等)。 更大规模和更快读写能力 基于强一致raft协议的副本同步机制以及轻量的索引构建方式，具有承载更大吞吐数据实时写入和读取能力。优化分布式混合计算引擎和优化器以达到更高的复杂计算能力。3.0版本写入性能是2.0版本同等规格的1.5倍，查询TPC-H (100g)是2.0版本的1.4倍。 更高可用/可靠性 服务秒级恢复，AZ内/跨AZ部署，可用性高于99.95%，自动故障检测、摘除和副本重搭。数据三副本存储、定时全量和增量备份，提供金融级别的数据可靠性保证。 更高安全 相比2.0版本，具有更完善和细化的权限体系模型，白名单和集群级别RAM控制，回收站730天超长保存，审计与合规记录所有SQL操作。 AnalyticDB for MySQL典型应用场景场景一 数据仓库场景 ADB for MySQL给MySQL技术栈公司带来福音，是业界唯一一款完全兼容MySQL协议的数据仓库产品。通过ADB for MySQL企业客户可以低成本且快速搭建大数据平台，其实时特性又可以助力企业快速发展。 相比离线数仓方案，成本降低55%。相比ADB for MySQL2.0方案，成本降低约15%；相比离线数仓方案，报表数据延时从天级别缩短至秒级。相比ADB for MySQL2.0方案，数据延时更短； 场景二 实时运营场景 在互联网行业精益化运营的背景下，数据分析已成为运营的标配，大家都希望通过精细的分析来提高运营的效率。拿移动App行业为例，移动App行业面临以下两个主要问题： 营销推广困难移动APP推 困难， 户下载少，留存率低。如何提高下载量及留存率成为每个移动应用开发企业关注的核心问题缺少运营分析能 终端种类多，适配量大。综合性能和户体验等问题是移动APP产品从开发到上线需要一直关注并迭代改进。ADB for MySQL的实时和海量大数据高并发复杂查询特性，最适合做精细化运营。具体到App行业，ADB for MySQL的写入和数据实时特性可以很好的解决移动App行业面临的问题。 海量埋点以及指标数据实时写入，ADB for MySQL3.0写入更快，单表最大4PB；实时洞察用户行为、App终端各种指标透视分析； 场景三 实时计算清洗回流 在实时计算的某些场景下，客户通常会将流计算清洗结果数据回流至MySQL等单机数据库，作为报表库来查询使用。当单机数据量或者单表数据量非常大时，传统的关系型数据库会出现报表查询卡顿的问题。ADB for MySQL能够很好地解决卡顿的问题，支持实时计算单表数据数千亿条，快速查询分析PB级别的实时报表，无需分库分表。 ...

编译：诚历，阿里巴巴计算平台事业部 EMR 技术专家，Apache Sentry PMC，Apache Commons Committer，目前从事开源大数据存储和优化方面的工作。 像公有云数据湖和 Delta Lake 这样的平台指出了一个中央数据枢纽的趋势，用来支持决策和AI驱动的自动化决策。 数据仓库是否再次加入这股浪潮呢，或者会逐渐消亡？ 如果你不清楚这个问题的答案也很正常。数据仓库在一方面目前仍处于热门阶段。笔者作为一个长期的行业观察者，看到了在不断创新和创业活动浪潮下行业的快速发展。 这种趋势基本上始于十年前标准设备进入数据仓库主流，然后随着市场向新一代云数仓转移逐渐获得了新动力。在过去几年中，一个云数仓供应商（Snowflake） 在市场上获得了非常多的支持。 数据仓库的衰落但在另一方面，数据仓库也不断被行业中的新事物所冲击，例如大数据、机器学习和人工智能。这种趋势造成了数据仓库在企业IT优先级下降的印象，但事实上大多数组织至少有一个或者多个数据仓库服务于各种下游应用程序。 数据仓库一直作为企业核心工作服务，是几年前我觉得数据仓库远未消亡的原因，这也可能解释了为什么其他观察者认为他们必须重新定义数据仓库的概念，以使其在数据湖和云计算时代保持相关性。 数据仓库作为一种实践，不仅蓬勃发展，而且现在已被视为云计算行业的重要核心增长。但是，如果你只是关注以此数据仓库标签进入市场的那些平台（例如Snowflake），你也将错过这个领域大部分的动作。 数据湖的兴起许多人认为“数据湖”正在迅速发展成为下一代数据仓库。对于那些不熟悉这个概念的人来说，数据湖是多结构数据的系统或存储库，它们以原始格式和模式存储，通常作为对象“blob”或文件存储。 数据湖通常用作所有企业数据的单个存储，包括源系统数据的原始副本和用于生成报告，可视化，数据分析和机器学习等任务的转换数据。它们包含分布式文件或对象存储，机器学习模型库以及高度并行化的处理和存储资源集群。并且，数据库通常在读取时使用模式，并使用统计模型从中提取有意义的相关性和模式，而不是对它们存储的对象强制执行通用模式和语义。 这些都与Inmon和Kimball核心概念不一致，这些概念为大多数专业人员的数据仓库方法提供了信息。从根本上说，一个数据仓库主要用来聚合，保留和管理官方认可的“单一版本的真实”数据记录。此概念与所管理数据的特定应用程序域以及使用它的特定用例无关。 如果你怀疑我在那个分数上说的话，请看看Bill Inmon对数据仓库的定义以及Inmon和Ralph Kimball框架的比较。数据仓库通常都是关于数据驱动的决策支持，这使得它可以很好地扩展到AI驱动的推理的新世界。 下一代数据仓库在过去的一年中，一些备受瞩目的行业公告标志着数据仓库角色的转变。尽管决策支持（也称为商业智能，报告和在线分析处理）仍然是大多数数据仓库的核心用例，但我们看到了其向决策自动化的稳步转变。换句话说，数据仓库现在正支持着数据科学管道，为数据驱动的推理构建了机器学习应用程序。 新一代数据仓库实际上是数据湖，对那些用于构建和训练机器学习模型的清洗，整合和验证的数据进行管理。例如，去年秋天在Amazon re：Invent 大会上，亚马逊网络服务公布了AWS Lake Formation。这种新的托管服务的明确目的是简化和加速安全数据湖的设置。然而，AWS Lake Formation 拥有云数据仓库的所有特点，尽管AWS并没有这样称呼它，实际上已经提供了一个面向决策支持应用程序的经典数据仓库。 AWS Lake Formation的架构和功能类似于数据仓库。实际上，AWS以这种方式来描述它：“数据湖是一个集中的，策划的和安全的存储库，它以原始形式存储所有数据并为分析做好准备。通过数据湖，您可以分解数据孤岛并组合不同类型的分析，以获商业洞察力并指导更好的业务决策。“ 另一个例子是 Databricks 最近宣布的 Delta Lake开源项目。 Delta Lake的明确目的（现在可以在Apache 2.0许可下使用）类似于AWS Lake格式：通过对数据湖中维护的数据集的聚合，清洗，管理和治理，以支持机器学习。 Delta Lake 位于现有的内部部署或云数据存储平台之上，可以从Apache Spark访问，例如HDFS，Amazon S3或Microsoft Azure blob存储。 Delta Lake将数据存储在Parquet中，以提供Databricks所称的“事务存储层”.Parquet是一种开源的列式存储格式，无论数据处理框架的选择如何，都可用于Hadoop生态系统中的任何项目。它通过乐观并发可串行化，快照隔离，数据版本控制，回滚和模式实施来支持ACID事务。 Delta Lake和AWS Lake Formation之间的一个关键区别是 Delta Lake 处理该管道中的批量和流数据。另一个是Delta Lake支持所有数据的ACID事务，允许数百个应用程序同时进行多次写入和读取。此外，开发人员可以访问每个Delta Lake的早期版本，以进行审计，回滚或重现其MLFlow机器学习实验的结果。 在最广泛的层面上，Delta Lake似乎与使用最广泛的开源数据仓库项目 Apache Hive 竞争，尽管 Hive 完全依赖基于 HDFS 的存储，并且直到最近才解决对ACID交易的支持。Hive 3一年前被宣布终于为基于Hadoop的数据仓库提供ACID支持。 Hive 3使用delta文件为事务CRUD（创建读取更新删除）表提供操作的原子性和快照隔离。 ...

AnalyticDB for PostgreSQL 基于开源数据库 Greenplum 构建，兼容Greenplum 和 PostgreSQL 的语法，接口和生态。本章节介绍如何通过FineBI连接 分析型数据库PostgreSQL版 并进行报表开发。 准备工作 开始使用FineBI之前，用户需要先完成以下准备工作。下载并安装FineBI 操作步骤 首先进行”新建数据连接“，并选择 "Greenplum Database"。 之后将 JDBC URL，数据库名称，用户名密码等输入进行连接测试。 注意事项 对于新安装的FineBI，第一次连接 Greenplum 或 PostgreSQL 数据源时，需要先下载其 JDBC Driver，可以按操作步骤下载并将对应JDBC 驱动安装到 FineBI 目录。AnalyticDB for PostgreSQL 既支持 PostgreSQL JDBC Driver，也支持 Greenplum 社区 Driver。 本文作者：陆封阅读原文 本文为云栖社区原创内容，未经允许不得转载。

如何对数仓进行建模，点击链接前往

1.数据仓库简介数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。 数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变的越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术也在不停的发展。 数据仓库的趋势： 实时数据仓库以满足实时化&自动化决策需求；大数据&数据湖以支持大量&复杂数据类型（文本、图像、视频、音频）； 2.数据仓库的发展数据仓库有两个环节：数据仓库的构建与数据仓库的应用。 早期数据仓库构建主要指的是把企业的业务数据库如ERP、CRM、SCM等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略型决策）。 随着业务和环境的发展，这两方面都在发生着剧烈变化。 随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站log，IoT设备数据，APP埋点数据等，这些数据量比以往结构化的数据大了几个量级，对ETL过程、存储都提出了更高的要求；互联网的在线特性也将业务需求推向了实时化，随时根据当前客户行为而调整策略变得越来越常见，比如大促过程中库存管理，运营管理等（即既有中远期策略型，也有短期操作型）；同时公司业务互联网化之后导致同时服务的客户剧增，有些情况人工难以完全处理，这就需要机器自动决策。比如欺诈检测和用户审核。 总结来看，对数据仓库的需求可以抽象成两方面：实时产生结果、处理和保存大量异构数据。 注：这里不讨论数据湖技术。3.数据仓库建设方法论1）面向主题 从公司业务出发，是分析的宏观领域，比如供应商主题、商品主题、客户主题和仓库主题 2）为多维数据分析服务 数据报表；数据立方体，上卷、下钻、切片、旋转等分析功能。 3）反范式数据模型 以事实表和维度表组成的星型数据模型 4.数据仓库架构的演变数据仓库概念是Inmon于1990年提出并给出了完整的建设方法。随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构。 后来随着业务实时性要求的不断提高，人们开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是Lambda架构。 再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的Kappa架构。 4.1离线大数据架构 数据源通过离线的方式导入到离线数仓中。 下游应用根据业务需求选择直接读取DM或加一层数据服务，比如mysql 或 redis。 数据仓库从模型层面分为三层： ODS，操作数据层，保存原始数据；DWD，数据仓库明细层，根据主题定义好事实与维度表，保存最细粒度的事实数据；DM，数据集市/轻度汇总层，在DWD层的基础之上根据不同的业务需求做轻度汇总；典型的数仓存储是HDFS/Hive，ETL可以是MapReduce脚本或HiveSQL。 4.2 Lambda架构 随着大数据应用的发展，人们逐渐对系统的实时性提出了要求，为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。 注：流处理计算的指标批处理依然计算，最终以批处理为准，即每次批处理计算后会覆盖流处理的结果。（这仅仅是流处理引擎不完善做的折中）Lambda架构问题： 1.同样的需求需要开发两套一样的代码这是Lambda架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。2.资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分） 4.3 Kappa架构 Lambda架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着Flink等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的Jay Kreps提出了Kappa架构 Kappa架构可以认为是Lambda架构的简化版（只要移除lambda架构中的批处理部分即可）。 在Kappa架构中，需求修改或历史数据重新处理都通过上游重放完成。 Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。 Kappa架构的重新处理过程 重新处理是人们对Kappa架构最担心的点，但实际上并不复杂： 1.选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的时长，比如Kafka，可以保存全部历史数据。2.当某个或某些指标有重新处理的需求时，按照新逻辑写一个新作业，然后从上游消息队列的最开始重新消费，把结果写到一个新的下游表中。3.当新作业赶上进度后，应用切换数据源，读取2中产生的新结果表。4.停止老的作业，删除老的结果表。 4.4 Lambda架构与Kappa架构的对比对比项Lambda架构Kappa架构实时性实时实时计算资源批和流同时运行，资源开销大只有流处理，仅针对新需求开发阶段运行两个作业，资源开销小重新计算时吞吐批式全量处理，吞吐较高流式全量处理，吞吐较批处理低开发、测试每个需求都需要两套不同代码，开发、测试、上线难度较大只需实现一套代码，开发、测试、上线难度相对较小运维成本维护两套系统（引擎），运维成本大只需维护一套系统（引擎），运维成本小在真实的场景中，很多时候并不是完全规范的Lambda架构或Kappa架构，可以是两者的混合，比如大部分实时指标使用Kappa架构完成计算，少量关键指标（比如金额相关）使用Lambda架构用批处理重新计算，增加一次校对过程。（1） Kappa架构并不是中间结果完全不落地，现在很多大数据系统都需要支持机器学习（离线训练），所以实时中间结果需要落地对应的存储引擎供机器学习使用，另外有时候还需要对明细数据查询，这种场景也需要把实时明细层写出到对应的引擎中。（2）参考后面的案例 另外，随着数据多样性的发展，数据仓库这种提前规定schema的模式显得越来难以支持灵活的探索&分析需求，这时候便出现了一种数据湖技术，即把原始数据全部缓存到某个大数据存储上，后续分析时再根据需求去解析原始数据。简单的说，数据仓库模式是schema on write，数据湖模式是schema on read。（3） 5.实时数仓案例菜鸟仓配实时数据仓库 本案例参考自菜鸟仓配团队的分享，涉及全局设计、数据模型、数据保障等几个方面。 注：特别感谢缘桥同学的无私分享。 5.1 整体设计 整体设计如右图，基于业务系统的数据，数据模型采用中间层的设计理念，建设仓配实时数仓；计算引擎，选择更易用、性能表现更佳的实时计算作为主要的计算引擎；数据服务，选择天工数据服务中间件，避免直连数据库，且基于天工可以做到主备链路灵活配置秒级切换；数据应用，围绕大促全链路，从活动计划、活动备货、活动直播、活动售后、活动复盘五个维度，建设仓配大促数据体系。 5.2 数据模型 不管是从计算成本，还是从易用性，还是从复用性，还是从一致性……，我们都必须避免烟囱式的开发模式，而是以中间层的方式建设仓配实时数仓。与离线中间层基本一致，我们将实时中间层分为两层。 ...

1 什么是数据仓库数据仓库是面向主题的、集成的、具有时间特征的、稳定的数据集合，用以支持经营管理中的决策制定过程典型应用: 报表生成数据分析数据挖掘数据仓库其他特征 数据量非常大（TB以上）是数据库的一种新型应用使用人员较少商用数据仓库 典型代表: db2, teradata, vertica价格昂贵，支持数据量通常TB或以下大数据时代数据仓库 数据量非常大扩展性和容错性很重要成本考量不了解的数据仓库基本概念的，可以参考之前《了解一下数据仓库》这篇文章。 2 基于Hadoop数据仓库的基本架构技术手段 通常使用Hive作为数据仓库 超大数据集设计的计算扩展能力支持HQL查询 — 简单，学习代价低统一的元数据管理基本特点 支持海量数据多维数据分析使用人员较少数据延迟较高2.1 基于Hadoop的数据仓库:第一版 优点 满足了数据仓库的基本要求能够处理海量数据系统扩展性和容错性极好缺点 性能较低，实时性不好2.2 基于Hadoop的数据仓库:第二版 改进 使用MPP(Presto)系统提高查询性能优点 满足了数据仓库的基本要求能够处理海量数据系统扩展性和容错性极好实时性较好缺点 数据延迟高（数据从产生到入库，再到查询，整个周期长）2.3 基于Hadoop的数据仓库:第三版（增加实时pipeline） 改进 使用Spark Streaming系统降低数据延迟优点 满足了数据仓库的基本要求能够处理海量数据系统扩展性和容错性极好实时性较好数据延迟低3 数据仓库具体实例网站报表系统基本作用 按照业务要求生成报表报表可实时产生或按天产生数据规模 数据量: TB级表数目: 100+用户量 约几十个3.1 收集数据 3.2 ETL ETL Extract, Transform, Load可使用MapReduce/Spark/Pig实现存储格式: 行式存储与列式存储行存储与列存储 如何创建带压缩的ORC表ETL后日志格式（文本格式）如下: 临时表（文本格式）定义如下: CREATE EXTERNAL TABLE tmp_logs ( domain_id INT, log_time STRING, log_date STRING, log_type INT, uin BIGINT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE LOCATION '/user/hivetest/logs';将数据导入临时表tmp_logs: LOAD DATA INPATH '/nginx/logs/2016011206' OVERWRITE INTO TABLE tmp_logs; ...

0.什么是数据库？数据库（DB）是按照数据结构来组织、存储和管理数据的建立在计算机存储设备上的仓库数据库是长期存储在计算机内、有组织的、可共享的数据集合。数据库中的数据指的是以一定的数据模型组织、描述和储存在一起、具有尽可能小的冗余度、较高的数据独立性和易扩展性的特点并可在一定范围内为多个用户共享1.什么是数据仓库？数据仓库是面向主题的，集成的，相对稳定的，反映历史变化的数据集合，用于支持管理决策。 面向主题：在较高层次上将企业信息系统的数据综合归并进行分析利用的抽象的概念。每个主题基本上对应一个相应的分析领域。集成的：企业级数据，同时数据要保持一致性、完整性、有效性、精确性。稳定性：从某个时间段来看是保持不变的，没有更新操作、删除操作，以查询分析为主。变化的：反映历史变化。功能数据仓库数据库数据范围存储历史的、完整的、反应历史变化的当前状态数据数据变化可添加、误删除、无变更的、反映历史变化支持频繁的增、删、改、查操作应用场景面向分析、支持战略决策面向业务交易流程设计理论违范式、适当冗余遵照范式（1NF、2NF、3NF等范式）、避免冗余处理量非频繁、大批量、高吞吐、有延迟频繁、小批次、高并发、低延迟面向业务的数据库常称作OLTP，面向分析的数据仓库称为OLAP。2.数据仓库的发展历程数据仓库概念最早可追溯到20世纪70年代，希望通过一种架构将业务处理系统和分析处理分为不同的层次。20世纪80年代，简历TA2(Technical Architecture2)规范，该明确定义了分析系统的四个组成部分：_数据获取、数据访问、目录、用户服务_。 1988年，IBM第一次提出信息仓库的概念：一个结构化的环境，能支持最终用户管理其全部的业务，并支持信息技术部门保证数据质量；抽象出基本组件：_数据抽取、转换、有效性验证、加载、cube开发等_，基本明确了数据仓库的基本原理、框架结构，以及分析系统的主要原则。 [敲黑板，说重点]: 转换：Sqoop进行简单的数据转换，更多的转化操作是通过ETL来实现的 有效性验证：牵扯到数据质量的问题 那么如何去建设数据仓库呢？ 1) 1991年，Bill Inmon提出了自上而下（top-down）的方式建设企业数据仓库（Data Warehouse, DW），认为DW是一个整体的商业智能系统（BI）的一部分。一家企业只有一个DW，数据集市（Data Market, DM）的信息来源出自DW，在DW中，信息存储符合3NF范式。2）Ralph Kimball则主张自下而上(bottom-up)的方式建立DW，极力推崇建立数据集市，认为DW是企业内所有DM的集合，信息总是被存储在多维模型中。3）Bill Inmon提出了新的BI架构CIP（Corporation information factory），把DM包含了进来。CIP的核心是将DW架构划分为不同的层次以满足不同场景的需求，比如常见的ODS、DW（e g: DWD, DWS等）、DM等，每层根据实际场景采用不同的建设方案，该思路也是目前DW建设的架构指南，但到底是以top-down还是bottom-up方式进行DW建设，并未统一。[敲黑板，说重点]: 很多人说Hadoop时代维度建模已经不是必须的了，其实不然，在整个Hadoop时代建模依然是有用的，而且是非常有意义的。Hadoop为整个大数据应用提供了技术的基础，包括Hive、Spark，只是技术架构。而我们谈及大数据的时候，更多的关注的是大数据的价值，所以在组织梳理数据内容的时候依然会有数据建模的概念。 只不过很多公司做大数据可能是刚起步阶段，更在意与流量方面，所以不需要建模，但是等数据体量达到一定程度后，如果没有数据建模，那么数据质量也就无法保障，数据也就会废掉、烂掉。 数据仓库分层架构图： 核心简述： 将业务DB中数据同步到只读DB中使用Sqoop将只读DB中的数据Import到HDFS上（ODS）将ODS层Hive中的数据通过HQL筛选到DWS层中（DWS存储的是中间汇总的结果）将DWS层Hive中的数据通过HQL结合具体需求筛选到DM中（DM存储的是待计算的指标）将DM层Hive中的数据通过Sqoop，Spark SQL导入到RDBMS之MySQL中存储起来（用于数据可视化展示）通过可视化技术读取RDBMS中相应结果数据进行可视化展示（饼状图、柱形图、折线图等）为什么要对数据仓库进行分层？ 用空间换时间，通过大量的预处理来提升系统的用户体验（效率），因此数据仓库会存在大量的数据冗余。如果不分层的话，源业务系统的业务规则发生变化将会影响整个系统的清洗过程，工作量巨大。通过数据分层管理可以简化数据清洗的过程，因为原来把一步的工作分了多个步骤去执行，相当于把一个复杂的工作拆分成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理的逻辑都相对简单和容易理解，这样我们比较容易确定每一个步骤的正确性，当数据发生错误的时候，往往我们需要调整某个步骤即可。说了这么多，那么数据仓库的建立步骤呢？ 1) 收集和分析业务需求2）建立数据模型和数据仓库的物理设计3）定义数据源4）选择数据仓库技术和平台5）从操作型数据库中抽取，净化和转换数据到数据仓库中6）选择访问和报表工具7）选择数据库连接软件8）选择数据分析和数据展示软件9）更新数据仓库3.基于大数据的数仓构建特点1) 特点鉴于互联网行业的“要么变化，要么去死”的影响，决定了在互联网领域，基于大数据的数据仓库建设是无法按照原有的项目流程、开发模式进行，更多的是需要结合新的技术体系、业务场景进行灵活的调整，以快速响应需求为导向。 2) 广泛的应用场景传统的数仓基于大数据的数仓建设周期长要求快速响应需求需求稳定需求灵活、多变时效性要求不高对实时性有不同程度的要求面向DSS、CRM、BI等系统除了面向DSS、BI等传统应用外，还要响应用户画像、个性化推荐（比如你看了一遍文章，再给你推荐十片同类型文章）、及其学习、数据分析等各种复杂的应用场景阿里系：OneData（公司级别所有数据应用都基于我这一个数据，只有一个数据出口，不论实时还是离线都是统一的唯一出口），OneService（数据服务也是统一的） 很多时候，我们提供到数仓，就会觉得是 离线 的、至少也是 T+1 的，但是这是传统的数据仓库，而基于大数据的数据仓库不应该这么理解，实时也应该归纳到数据仓库中。 3) 技术栈更全面、复杂 传统数仓建设：更多是基于成熟的商业数据集成平台，比如Oracle、Informatica等，技术体系比较成熟完善，但相对较封闭，对实施者技术面要求也相对专业且单一。基于大数据的数仓建设：一般是基于非商业、开源的技术，且涉及技术较广泛、复杂，没有商业的公司提供服务，需要自己维护更多的技术框架。常见的是基于Hadoop的生态建设。技术栈总图： 4) 数仓模型设计更灵活 传统数仓： 有较为稳定的业务场景和相对可靠的数据质量，同时也有较为稳定的需求，对数仓的建设有较为完善的项目流程管控，数仓模型设计有严格的、稳定的建设标准互联网行业： 行业变化快、业务灵活，同时互联网又是个靠速度存活的行业源数据种类繁多：数据库、Nginx log、用户浏览轨迹等结构化、非结构化、半结构化数据数据质量相对差，层次不齐综上，在互联网领域，数仓模型是必须要存在（不一定是维度建模，但是至少需要一个建模），且数仓模型的设计更关注灵活、快速响应和应对多变的市场环境，更加以快速解决业务、运营问题为导向，快速数据接入、快速业务接入，更不存在一劳永逸。 4.数据仓库的应用范围与前景数仓存在的意义 工程治理基于大数据的数据仓库在互联网行业应用： BI消息推送千人千面用户画像反欺诈5.发展方向1）数据分析、数据挖掘、人工智能、机器学习、风险控制、无人驾驶2）数据化运营、精准运营3）广告精准、智能投放Resource Link[1] 数据仓库(三)之架构篇[2] 数据仓库学习笔记 --- 如何设计数据仓库

作者 | 张俊本文整理自 2019 年 4 月 13 日在深圳举行的 Flink Meetup 会议，分享嘉宾张俊，目前担任 OPPO 大数据平台研发负责人，也是 Apache Flink contributor。本文主要内容如下： OPPO 实时数仓的演进思路；基于 Flink SQL 的扩展工作；构建实时数仓的应用案例；未来工作的思考和展望。一.OPPO 实时数仓的演进思路1.1.OPPO 业务与数据规模 大家都知道 OPPO 是做智能手机的，但并不知道 OPPO 与互联网以及大数据有什么关系，下图概要介绍了 OPPO 的业务与数据情况： OPPO 作为手机厂商，基于 Android 定制了自己的 ColorOS 系统，当前日活跃用户超过 2 亿。围绕 ColorOS，OPPO 构建了很多互联网应用，比如应用商店、浏览器、信息流等。在运营这些互联网应用的过程中，OPPO 积累了大量的数据，上图右边是整体数据规模的演进：从 2012 年开始每年都是 2~3 倍的增长速度，截至目前总数据量已经超过 100PB，日增数据量超过 200TB。要支撑这么大的一个数据量，OPPO 研发出一整套的数据系统与服务，并逐渐形成了自己的数据中台体系。 1.2.OPPO 数据中台 今年大家都在谈数据中台，OPPO 是如何理解数据中台的呢？我们把它分成了 4 个层次： 最下层是统一工具体系，涵盖了"接入 - 治理 - 开发 - 消费"全数据链路；基于工具体系之上构建了数据仓库，划分成"原始层 - 明细层 - 汇总层 - 应用层"，这也是经典的数仓架构；再往上是全域的数据体系，什么是全域呢？就是把公司所有的业务数据都打通，形成统一的数据资产，比如 ID-Mapping、用户标签等；最终，数据要能被业务用起来，需要场景驱动的数据产品与服务。以上就是 OPPO 数据中台的整个体系，而数据仓库在其中处于非常基础与核心的位置。 ...

7天带你全面了解数据仓库 体验海量数据分析 数据仓库服务（Data Warehouse Service，简称DWS）是一种基于公有云基础架构和平台的在线数据处理数据库，为用户提供海量数据挖掘和分析服务。DWS数据库内核使用华为自主研发的GAUSS200 OLAP，基于PostgreSQL 9.2.4的数据库内核引擎，从单机OLTP数据库改造为企业级MPP架构的OLAP分布式数据库。也可借助DWS Express，将查询分析扩展至数据湖。华为云DWS是基于华为融合数据仓库GaussDB产品的云原生服务，兼容标准ANSI SQL 99和SQL 2003，同时兼容PostgreSQL/Oracle数据库生态，为各行业PB级海量大数据分析提供有竞争力的解决方案。接下来我们从其最基本的特性、优势方面着手了解数据仓库。数据仓库和数据库有什么区别呢？主要有以下几点：数据库是面向事务的设计，数据仓库是面向主题设计的；数据库一般存储在线交易数据，数据仓库存储的一般是历史数据；数据库设计是尽量避免冗余，数据仓库在设计是有意引入冗余；数据库是为捕获数据而设计，数据仓库是为分析数据而设计。数据仓库有哪些优势？数据仓库支持完善的监控管理能力，并提供专业高效的服务管理控制平台，用户可以快速申请DWS集群并开展业务，减少运维工作，专注业务发展和应用开发。与传统数据仓库相比，主要有以下特点与显著优势，可解决多行业超大规模数据处理与通用平台管理问题：1.采用大规模并行处理架构，支持行存储与列存储，提供海量数据的处理能力。2.设计查询优化模型，使得复杂查询的性能快速提升。3.集群分布式、并行化的运算模式，充分利用计算资源。数据仓库的适用场景？基于以上特性优势，DWS适用于不同行业的在线分析场景，例如，数据仓库迁移、大数据融合分析、增强型ETL和实时BI分析、实时数据分析等。那么该如何学习这款实时、简单、安全可信的企业级融合数据仓库呢？有办法能在7天内快速的学习数据仓库知识？想要与技术大牛一起探讨海量数据处理的乐趣？现在访问华为云学院（https://edu.huaweicloud.com/c...），报名《7天玩转数据仓库》课程，全面了解数据仓库，与专家互动学习！

阿里妹导读：MaxCompute 是阿里EB级计算平台，经过十年磨砺，它成为阿里巴巴集团数据中台的计算核心和阿里云大数据的基础服务。去年MaxCompute 做了哪些工作，这些工作背后的原因是什么？大数据市场进入普惠+红海的新阶段，如何与生态发展共赢？人工智能进入井喷阶段，如何支持与借力？本文从过去一年的总结，核心技术概览，以及每条技术线路未来展望等几个方面做一个概述。BigData 概念在上世纪90年代被提出，随 Google 的3篇经典论文（GFS，BigTable，MapReduce）奠基，已经发展了超过10年。这10年中，诞生了包括Google 大数据体系，微软 Cosmos 体系，开源 Hadoop 体系等优秀的系统，这其中也包括阿里云的飞天系统。这些系统一步一步推动业界进入“数字化“和之后的“ AI 化”的时代。同时，与其他老牌系统相比（如，Linux 等操作系统体系，数据库系统、中间件，很多有超过30年的历史），大数据系统又非常年轻，随着云计算的普惠，正在大规模被应用。海量的需求和迭代推动系统快速发展，有蓬勃的生机。（技术体系的发展，可以通过如下 Hype-Cycle 概述，作者认为，大数据系统的发展进入技术复兴期/Slope of Enlightenment，并开始大规模应用 Plateau of Productivity。）如果说，0到1上线标志一个系统的诞生，在集团内大规模部署标志一个系统的成长，在云上对外大规模服务标志一个系统的成熟。MaxCompute 这10年已经走向成熟，经过多次升级换代，功能、性能、服务、稳定性已经有一个体系化的基础，成为阿里巴巴集团数据中台的计算核心和阿里云大数据的基础服务。1. MaxCompute（ODPS）概述1.1 背景信息：十年之后，回头看什么是大数据"Big data represents the information assets characterized by such a high volume, velocity and variety torequire specific technology and analytical methods for its transformation intovalue. “用5个“V”来描述大数据的特点：Volume （数据量）：数据量非线性增长，包括采集、存储和计算的量都非常大，且增速很快。Variety （数据类型）：包括结构化和非结构化的数据，特别是最近随音视图兴起，非结构化数据增速更快。Velocity（数据存储和计算的增长速度）：数据增长速度快，处理速度快，时效性要求高。Veracity（信噪比）：数据量越大，噪声越多，需要深入挖掘数据来得到结果。Value（价值）：数据作为一种资产，有 1+1>2 的特点。1.3 竞品对比与分析大数据发展到今天，数据仓库市场潜力仍然巨大，更多客户开始选择云数据仓库，CDW仍处于高速增长期。当前互联网公司和传统数仓厂家都有进入领导者地位，竞争激烈，阿里巴巴CDW在全球权威咨询与服务机构Forrester发布的《The Forrester WaveTM: CloudData Warehouse, Q4 2018》报告中位列中国第一，全球第七。在 CDW 的领导者中，AWS Redshift 高度商业化、商业客户部署规模领先整个市场，GoogleBigQuery 以高性能、高度弹性伸缩获得领先，Oracle 云数仓服务以自动化数仓技术获得领先。MaxCompute 当前的定位是市场竞争者，目标是成为客户大数据的“航母”级计算引擎，解决客户在物联网、日志分析、人工智能等场景下日益增长的数据规模与计算性能下降、成本上升、复杂度上升、数据安全风险加大之间的矛盾。在此目标定位下，对 MaxCompute 在智能数仓、高可靠性、高自动化、数据安全等方面的能力提出了更高的要求。2. 2018年MaxCompute技术发展概述过去的一个财年，MaxCompute 在技术发展上坚持在核心引擎、开放平台、技术新领域等方向的深耕，在业务上继续匠心打造产品，扩大业界影响力。效率提升2018年9月云栖大会发布，MaxCompute 在标准测试集 TPC-BB 100TB整体指标较2017年提升一倍以上。得益于整体效率的提升，在集团内部 MaxCompute 以20%的硬件增长支撑了超过70%的业务增长。系统开放性和与生态融合联合计算平台 Cupid 逐步成熟，性能与 EMR Spark Benchmark 持平，支持K8S 接口，支持完整的框架安全体系，Spark On MaxCompute 已开始支持云上业务。Python 分布式项目 MARS 正式发布，开源两周内收获1200+ Star，填补了国内在 Python 生态上支持大规模分布式科学计算的空白，是竞品 Dask 性能的3倍。探索新领域MaxCompute 持续在前沿技术领域投入，保持技术先进性。在下一代引擎方向，如：AdaptiveOperatorsOperator FusionClusteredTable智能数仓 Auto Datawarehouse 方向上的调研都取得了不错的进展。在渐进计算、Advanced FailChecking and Recovery 、基于 ML的分布式计算平台优化、超大数据量 Query 子图匹配等多个方向上的调研也在进行中。深度参与和推动全球大数据领域标准化建设2018年11月，MaxCompute 与 DataWorks/AnalyticDB一起代表阿里云入选 Forrester Wave™ Q4 2018云数据仓库研究报告，在产品能力综合得分上力压微软，排名全球第七，中国第一。2019年3月，MaxCompute 正式代表 Alibaba 加入了 TPC 委员会推动融入和建立标准。MaxCompute 持续在开源社区投入。成为全球两大热门计算存储标准化开源体系 ORC 社区的 PMC，MaxCompute 成为近两年贡献代码量最多的贡献者，引导存储标准化；在全球最热门优化器项目 Calcite，拥有一个专委席位，成为国内前两家具备该领域影响力的公司，推动数十个贡献。3. 核心技术栈大数据市场进入普惠+红海的新阶段，如何借力井喷阶段中的人工智能，如何与生态发展共赢？基于横向架构上的核心引擎和系统平台，MaxCompute 在计算力、生态化、智能化3个纵向上着力发展差异化的竞争力。3.1 计算力首先我们从计算力这个角度出发，介绍一下 MaxCompute 的技术架构。a.核心引擎支撑 MaxCompute 的计算力的核心模块之一是其 SQL 引擎：在 MaxCompute 的作业中，有90%以上的作业是 SQL 作业，SQL 引擎的能力是 MaxCompute 的核心竞争力之一。在 MaxCompute 产品框架中，SQL 引擎将用户的 SQL 语句转换成对应的分布式执行计划来执行。SQL 引擎由3个主要模块构成：编译器 Compiler：对 SQL 标准有友好支持，支持100% TPC-DS 语法；并具备强大都错误恢复能力，支持 MaxCompute Studio 等先进应用。运行时 Runtime：基于LLVM优化代码生产，支持列式处理与丰富的关系算符；基于 CPP 的运行时具有更高效率。优化器 Optimizer：支持HBO和基于 Calcite 的 CBO， 通过多种优化手段不断提升 MaxCompute 性能。MaxComputeSQL 引擎当前的发展，以提升用户体验为核心目标，在 SQL 语言能力、引擎优化等多个方向上兼顾发力，建立技术优势，在 SQL 语言能力方面， 新一代大数据语言 NewSQL 做到了 Declarative 语言和 Imperative 语言的融合，进一步提升语言兼容性，目前已100% 支持 TPC-DS 语法。过去一年中，MaxCompute 新增了对 GroupingSets，If-Else 分支语句，动态类型函数，等方面的支持。b.存储MaxCompute 不仅仅是一个计算平台，也承担着大数据的存储。阿里巴巴集团99%的大数据存储都基于 MaxCompute，提高数据存储效率、稳定性、可用性，也是MaxCompute一直努力的目标。MaxCompute 存储层处于 MaxCompute Tasks 和底层盘古分布式文件系统之间，提供一个统一的逻辑数据模型给各种各样的计算任务。MaxCompute 的存储格式演化，从最早的行存格式 CFile1，到第一个列存储格式 CFile2，到第三代存储格式。支持更复杂的编码方式，异步预读等功能，进一步提升效能。在存储和计算2个方面都带来了效能的提升。存储成本方面，在阿里巴巴集团内通过 新一代的列存格式节省约8%存储空间，直接降低约1亿成本；在计算效率上，过去的一个财年中发布的每个版本之间都实现了20%的提升。目前在集团内大规模落地的过程中。在归档以及压缩方面，MaxCompute 支持 ZSTD 压缩格式，以及压缩策略，用户可以在 Normal，High 和 Extreme 三种 Stategy 里面选择。更高的压缩级别，带来更高效的存储，但也意味着更高的读写 CPU 代价。2018年， MaxCompute 陆续推出了 Hash Clustering 和 Range Clustering 支持富结构化数据，并持续的进行了深度的优化，例如增加了 ShuffleRemove，Clustering Pruning 等优化。从线上试用数据，以及大量的 ATA 用户实践案例也可以看出，Clustering 的收益也获得了用户的认可。c.系统框架资源与任务管理：MaxCompute 框架为 ODPS 上面各种类型的计算引擎提供稳定便捷的作业接入管理接口，管理着 ODPS 各种类型 Task 的生命周期。过去一年对短作业查询的持续优化，缩短 e2e 时间，加强对异常作业（OOM)的自动检测与隔离处理，全面打开服务级别流控，限制作业异常提交流量，为服务整体稳定性保驾护航。MaxCompute 存储着海量的数据，也产生了丰富的数据元数据。在离线元仓统计T+1的情况下，用户至少需要一天后才能做事后的数据风险审计，现实场景下用户希望更早风险控制，将数据访问事件和项目空间授权事件通过 CUPID 平台实时推送到用户 DataHub 订阅，用户可以通过消费 DataHub 实时获取项目空间表、volume数据被谁访问等。元数据管理：元数据服务支撑了 MaxCompute 各个计算引擎及框架的运行。每天运行在 MaxCompute 的作业，都依赖元数据服务完成 DDL，DML 以及授权及鉴权的操作。元数据服务保障了作业的稳定性和吞吐率，保障了数据的完整性和数据访问的安全性。元数据服务包含了三个核心模块：Catalog ：完成DDL，DML及DCL（权限管理）的业务逻辑，Catalog保障MaxCompute作业的ACID特性。MetaServer：完成元数据的高可用存储和查询能力。AuthServer：是高性能和高QPS的鉴权服务，完成对 MaxCompute 的所有请求的鉴权，保障数据访问安全。元数据服务经过了模块化和服务化后，对核心事务管理引擎做了多次技术升级，通过数据目录多版本，元数据存储重构等改造升级，保障了数据操作的原子性和强一致，并提高了作业提交的隔离能力，并保障了线上作业的稳定性。在数据安全越来越重要的今天，元数据服务和阿里巴巴集团安全部合作，权限系统升级到了2.0。核心改进包括：MAC（强制安全控制）及安全策略管理：让项目空间管理员能更加灵活地控制用户对列级别敏感数据的访问，强制访问控制机制(MAC)独立于自主访问控制机制(DAC)。数据分类分级：新增数据的标签能力，支持对数据做隐私类数据打标。精细权限管理：将ACL的管控能力拓展到了 Package 内的表和资源，实现字段级的权限的精细化管理。系统安全：系统安全方面，MaxCompute 通过综合运用计算虚拟化和网络虚拟化技术，为云上多租户各自的用户自定义代码逻辑提供了安全而且完善的计算和网络隔离环境。SQL UDF(python udf 和 java udf)，CUPID联合计算平台(Sparks/Mars等)，PAI tensorflow 等计算形态都基于这套统一的基础隔离系统构建上层计算引擎。MaxCompute 还通过提供原生的存储加密能力，抵御非授权访问存储设备的数据泄露风险。MaxCompute 内置的存储加密能力，可以基于KMS云服务支持用户自定义秘钥(BYOK)以及AES256加密算法，并计划提供符合国密合规要求的SM系列加密算法支持。结合MaxCompute元仓(MetaData)提供的安全审计能力和元数据管理(MetaService)提供的安全授权鉴权能力，以及数据安全生态中安全卫士和数据保护伞等安全产品，就构成了 MaxCompute安全栈完整大图。3.2 生态化作为一个大规模数据计算平台，MaxCompute 拥有来自各类场景的EB级数据，需要快速满足各类业务发展的需要。在真实的用户场景中，很少有用户只用到一套系统：用户会有多份数据，或者使用多种引擎。联合计算融合不同的数据，丰富 MaxCompute 的数据处理生态，打破数据孤岛， 打通阿里云核心计算平台与阿里云各个重要存储服务之间的数据链路。联合计算也融合不同的引擎，提供多种计算模式，支持开源生态。开源能带来丰富和灵活的技术以赋能业务，通过兼容开源API对接开源生态。另一方面，在开源过程中我们需要解决最小化引入开源技术成本及打通数据、适配开源接口等问题。a.Cupid 联合计算平台联合计算平台 Cupid 使一个平台能够支持 Spark、Flink、Tensorflow、Numpy、ElasticSearch 等多种异构引擎， 在一份数据上做计算。在数据统一、资源统一的基础上，提供标准化的接口，将不同的引擎融合在一起做联合计算。Cupid 的工作原理是通过将 MaxCompute 所依赖的 Fuxi 、Pangu 等飞天组间接口适配成开源领域常见的 Yarn、HDFS 接口，使得开源引擎可以顺利执行。现在，Cupid 新增支持了 Kubernetes 接口，使得联合计算平台更加开放。案例：Spark OnMaxComputeSpark 是联合计算平台第一个支持的开源引擎。基于 Cupid 的 Spark on MaxCompute 实现了与 MaxCompute 数据/元数据的完美集成；遵循 MaxCompute 多租户权限及安全体系；与Dataworks、PAI平台集成；支持 Spark Streaming,Mllib, GraphX,Spark SQL，交互式等完整 Spark生态；支持动态资源伸缩等。b.多源异构数据的互联互通随着大数据业务的不断扩展，新的数据使用场景在不断产生，用户也期望把所有数据放到一起计算，从而能取得 1+1 > 2 这样更好的结果。MaxCompute 提出了联合计算，将计算下推，联动其他系统：将一个作业在多套系统联动，利用起各个系统可行的优化，做最优的决策，实现数据之间的联动和打通。MaxCompute 通过异构数据支持来提供与各种数据的联通，这里的“各种数据”是两个维度上的：多样的数据存储介质（外部数据源），插件式的框架可以对接多种数据存储介质。当前支持的外部数据源有：OSSTableStore(OTS)TDDLVolume多样的数据存储格式：开源的数据格式支持，如 ORC、Parquet 等；半结构化数据，如包括 CSV、Json等隐含一定schema 的文本文件；完全无结构数据，如对OSS上的文本，音频、图像及其他开源格式的数据进行计算。基于MaxCompute 异构数据支持，用户通过一条简单的 DDL 语句即可在 MaxCompute 上创建一张EXTERNAL TABLE（外表），建立 MaxCompute 表与外部数据源的关联，提供各种数据的接入和输出能力。创建好的外表在大部分场景中可以像普通的 MaxCompute 表一样使用，充分利用 MaxCompute 的强大计算力和数据集成、作业调度等功能。MaxCompute 外表支持不同数据源之间的 Join，支持数据融合分析，从而帮助您获得通过查询独立的数据孤岛无法获得的独特见解。从而MaxCompute 可以把数据查询从数据仓库扩展到EB级的数据湖(如OSS)，快速分析任何规模的数据，没有MaxCompute存储成本，无需加载或 ETL。异构数据支持是MaxCompute 2.0升级中的一项重大更新，意在丰富 MaxCompute 的数据处理生态，打破数据孤岛，打通阿里云核心计算平台与阿里云各个重要存储服务之间的数据链路。c.Python 生态和 MARS科学计算引擎MaxCompute 的开源生态体系中，对 Python 的支持主要包括 PyODPS、Python UDF、和MARS。PyODPS 一方面是 MaxCompute 的 PythonSDK，同时也提供 DataFrame 框架，提供类似 pandas 的语法，能利用 MaxCompute 强大的处理能力来处理超大规模数据。基于 MaxCompute 丰富的用户自定义函数（UDF）支持，用户可以在 ODPS SQL 中编写 Python UDF 来扩展 ODPS SQL。 MARS 则是为了赋能 MaxCompute 科学计算，全新开发的基于矩阵的统一计算框架。使用 Mars 进行科学计算，不仅能大幅度减少分布式科学计算代码编写难度，在性能上也有大幅提升。3.3 智能化随着大数据的发展，我们在几年前就开始面对数据／作业爆发式增长的趋势。面对百万计的作业和表，如何做管理呢？MaxCompute 通过对历史作业特征的学习、基于对数据和作业的深刻理解，让 MaxCompute 上的业务一定程度实现自适应调整，让算法和系统帮助用户自动、透明、高效地进行数仓管理和重构优化工作，实现更好地理解数据，实现数据智能排布和作业全球调度，做到大数据处理领域的“自动驾驶”，也就是我们所说的Auto DataWarehousing。Auto Data Warehousing 在线上真实的业务中，到底能做什么呢？我们以Hash Clustering 的自动推荐来小试牛刀。Hash Clustering 经过一年多的发展，功能不断完善，但对用户来说，最难的问题仍然在于，给哪些表建立怎样的 Clustering 策略是最佳的方案？MaxCompute 基于 Auto Data Warehousing，来实现为用户推荐如何使用 HashClustering，回答如何选择 Table、如何设置Cluteringkey 和分桶数等问题，让用户在海量数据、海量作业、快速变化的业务场景下，充分利用平台功能。4. 商业化历程从2009年云梯到 ODPS，再到 MaxCompute，MaxCompute(ODPS) 这个大数据平台已经发展了十年。回顾 MaxCompute 的发展，首先从云梯到完成登月，成为了一个统一的大数据平台。2014年，MaxCompute 开始商业化的历程，走出集团、向公共云和专有云输出，直面中国、乃至全球的用户。面对挑战，MaxCompute 坚持产品核心能力的增强，以及差异化能力的打造， 赢得了客户的选择。回顾上云历程，公共云的第一个节点华东2上海在2014（13年）年7月开服，经过4年多发展，MaxCompute 已在全球部署18个Region，为云上过万家用户提供大数据计算服务，客户已覆盖了新零售、传媒、社交、互联网金融、健康、教育等多个行业。专有云的起点则从2014年8月第一套POC环境部署开始，发展至今专有云总机器规模已超过10000台；输出项目150+套，客户涵盖城市大脑，大安全，税务，等多个重点行业。今天，MaxCompute 在全球有超过十万的服务器，通过统一的作业调度系统和统一的元数据管理，这十万多台服务器就像一台计算机，为全球用户提供提供包括批计算、流计算、内存计算、机器学习、迭代等一系列计算能力。这一整套计算平台成为了阿里巴巴经济体，以及阿里云背后计算力的强有力支撑。MaxCompute 作为一个完整的大数据平台，将不断以技术驱动平台和产品化发展，让企业和社会能够拥有充沛的计算能力，持续快速进化，驱动数字中国。本文作者： 观涛阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。 ...

声明本文中介绍的非功能性规范均为建议性规范，产品功能无强制，仅供指导。参考文献《大数据之路——阿里巴巴大数据实践》——阿里巴巴数据技术及产品部 著。背景及目的数据对一个企业来说已经是一项重要的资产，既然是资产，肯定需要管理。随着业务的增加，数据的应用越来越多，企业在创建的数仓过程中对数据的管理也提出了更高的要求，而数据质量也是数仓建设过程不容忽视的环节。本文针对MaxCompute数仓建设过程中如何做数据质量给出规范建议，为实际数据治理提供依据及指导。数据质量保障原则评估数据质量的好坏不同行业甚至不同企业有不同标准，在此我们主要从四个方面进行评估，即完整性、准确性、一致性和及时性。完整性。完整性是指数据的记录和信息是否完整，是否存在缺失情况。数据缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确，可以说，完整性是数据质量最基础的保障。如某个相对稳定的业务数据量每天的都有100万条记录，某天突然下降1万条，那么可能就是记录缺失。而对于记录中某个字段信息缺失，如某科高考成绩表中一个考卷分数要对应一个准考证号，这个字段的空值数就该为0，一旦大于0，说明该信息缺失了。准确性。准确性是指数据中记录的信息和数据是否准确，是否存在异常或者错误的信息。比如成绩单中分数出现负数，比如订单没有买家信息等，这些都是有问题的。确保记录的准确性也是抱着数据质量必不可少的一个原则。一致性。一致性一般体现在跨度很大的数据仓库体现中。 比如公司中有很多业务数仓分支，对于同一份数据必须保证一致性。例如用户ID，从在线业务库加工到数据仓库，再到各个数据应用节点，必须都是同一种类型、长度保持一致。因此在《MaxCompute数仓建设规范指南》中有了“公共层”的加工，确保数据的一致性。及时性。保障数据的及时产出，体现数据的价值。如决策的分析师一般都希望当天可以看到前一天的数据而不是要等三五天才能看到某一个数据分析结果，否则就失去了数据及时性的价值，使得数据分析工作变得毫无意义。数据质量管理流程要做数据质量管理，制定满足以上数据质量原则集基础上的质量管理规范，需要考虑几方面：什么数据需要做质量管理。什么环节进行数据质量管理。数据质量管理具体怎么做。数据质量定义定义哪些数据需要做质量管理一般可以通过数据资产等级划分和元数据的应用链路分析得出。根据应用的影响程度，确定数据资产等级；根据数据链路血缘，将数据资产等级上推至各数据生产加工的各个环节，确定链路上所涉及的数据的资产等级和在各个加工环节上根据资产等级的不同所采取的不同处理方式。数据资产等级定义对于数据的资产等级，在质量管理方向，可以从数据质量“不满足四个原则”情况下对业务的影响性质，比如可以划分为5个等级的性质，即毁灭性质、全局性质、局部性质、一般性质、未知性质，不同性质的重要性一次降低，具体定义如下:毁灭性质，即数据一旦出错，将会引起重大资产损失，面临重大收益损失等。全局性质，即数据直接或间接用于企业级业务和效果评估、重要决策等。局部性质，即数据直接或间接用于某些业务线的运营、报告等，若出现问题会给业务线造成影响或者造成工作效率损失。一般性质，即数据主要用于日常数据分析，出现问题带来的影响极小。未知性质，即无法明确数据的应用场景。如table的label等级，资产等级可以用Asset进行标记：毁灭性质-A1，全局性质-A2，局部性质-A3，一般性质-A4，未知性质-Ax。重要程度为：A1>A2>A3>A4>Ax。若一份数据出现在多个应用场景汇总则遵循就高原则。数据资产等级落地方法定义划分好数据资产等级后，接下来就考虑怎么落地，对数仓中庞大的数据量进行资产等级打标。可以从数据流转链路着手。MaxCompute进行数据加工基本基本流程：数据从业务系统上产生，通过同步工具（DataWorks的数据集成或阿里云DTS）进入数据数仓系统（MaxCompute）,数据在数仓中进行清洗、加工、整合、算法、模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。整个流程数据都是以存放在表的形式体现，流转链路大致如下图：从数据流转链路上，整理哪些表是被哪些应用业务产品消费，通过给这些应用业务产品划分数据资产等级，再结合数据的上下游血缘，将整个链路打上某一类资产等级的标签。如，一个A2等级的的数据应用产品，对应导入这个数据产品的table即数仓（MaxCompute）的导出表Table1、Table2、Table3，几个表都打上A2-xxx数据产品标记，根据血缘往上追溯，将这几个表的上有都打上A2的标记，一直标记到源数据业务系统。通过如上方式完成数据资产等级的确认，给不同的数据定义不同的重要程度。知道了数据的重要等级针对不同的等级，采取不同的保障措施，接下来我们介绍在基于MaxCompute的数据仓库中针对不同等级的数据的保障方法。数据加工过程卡点校验在线系统卡点校验在线系统数据加工过程卡点校验，主要是指在业务系统的数据生成过程中进行的卡点校验。在线业务系统产生的数据也是数据仓库的数据来源，然而在线业务系统普遍都是复杂多变，且每次变更不可避免会带来数据的变化，数仓需要适应多变的业务发展，及时做到数据的准确性。因此，在线业务的变更如何高效的通知到基于MaxCompute的离线数据仓库，也是需要考虑的问题。这里我们介绍两个方法拱参考：工具和人员双管齐下。纪要在工具上自动捕捉每一次业务的变化，同时也要求开发人员在意识上自动进行业务变更通知。工具——发布平台。在业务进行重大变更时，订阅这个发布过程，通知到离线开发人员，使其知晓此次变更内容。当业务系统足够繁杂，日常发布变更频繁的情况下，若每次变更都通知离线业务，势必会造成不必要的浪费，同时也影响业务迭代效率。此时，可以通过数据资产等级的标识，对业务进行打标后，针对高等级的数据资产，整理出什么变更会影响数据的加工，如相关财务报表，如果业务系统的改造影响到财务报表的计算，使得约定好的计算口径被业务系统发布变更修改了，这种情况必须要告知离线业务，而离线开发人员也必须主动关注这类发布变更通知。注意：这里指的发布平台非阿里云提供发布平台，只是一种统称，指各个企业自己在线业务的相关发布平台。工具——数据库的变化感知。随着业务的发展，业务数据库（MaxCompute数仓的数据源）不可避免会出现数据库扩容或者DDL变更，这些变更都要主动通知到离线开发人员。基于MaxCompute的数据仓库在进行离线数据抽取时，通过DataWorks的数据集成工具，可能会限制某个业务数据库表，如果该数据库表发生扩容或者迁移等，数据集成工具感知不到，会可能导致数据抽取错漏，而一旦错漏，会影响下游一系列依赖该表的应用，因此建议业务数据库也需要有库表变更通知。工具只是一种辅助手段，操作工具的人员才是核心。数据资产等级的上下游打通，同样也将这个过程给到在线开发人员，使其知晓哪些是重要的核心数据资产，提高在线开发人员的数据风险意识。通过培训等方式将离线数据的诉求、离线数据的加工过程、数据产品的应用方式告诉在线业务开发人员，让其了解数据的重要性，了解数据的价值，同时也告知出错后果。让在线开发人员在完成业务目标时，也要考虑数据的目标，做到业务端和数据端一致。离线系统卡点校验首先我们再次认识MaxCompute进行数据加工的基本流程：数据从业务系统上产生，通过同步工具（DataWorks的数据集成或阿里云DTS）进入数仓系统（MaxCompute）,数据在数仓中进行清洗、加工、整合、算法、模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。整个流程中，有了数据加工，才有了数据仓库模型和数据仓库代码的建设，如何保障数据加工过程中的质量是离线数据仓库保障数据质量的一个重要环节。MaxCompute进行数据加工，可以通过DataWorks、也可以通过MaxCompute studio、或者直接通过MaxCompute SDK提交各种任务进行加工。无论用什么工具，都会经历代码开发->测试、发布->运维、变更 的过程，可以对这个过程每个环节进行卡点校验。代码提交的卡点校验。即在sql提交前进行相关规则校验。这个校验目前公共云没有直接可用的工具辅助，有能力的用户可以自己开发相关的工具。规则分类如：代码规范类规则，如表命名规范、生命周期设置、表注释等。代码质量类规则，如分母为0提醒、NULL值参与计算影响结果提醒、插入字段顺序错误等。代码性能类规则，如分区裁剪失效、扫描大表提醒、重复计算检测等。任务发布上线时的卡点校验。为了保障线上数据的准确性，每一次变更都需要测试后再发布到线上生产环境，且生产环境测试通过后才算发布成功。任务变更或者数据重跑，在离线数据加工过程中不可避免都会出现的操作。针对这个操作，在进行更新前，需要通知下游，将变更原因、变更逻辑、变更时间等信息表明，下游对此次变更没有异议后再按照约定时间执行发布变更，将变更对下游的影响降到最低。数据风险点监控前一章节主要介绍通过数据加工过程的卡点校验保障在线数据和离线数据的一致性问题，本章节主要通过对数据风险点的监控来介绍如何保障数据的准确性。在线数据风险点监控在线业务系统的数据生成过程需要保证数据质量，主要根据业务规则对数据进行监控。MaxCompute本身没有配套的工具，需用户自己实现，在此只能给出一些建议拱参考。如针对数据库表的记录进行规则校验，制定一些监控规则，在业务系统中，每个业务过程进行数据落库时对数据进行校验。监控规则如交易系统中，订单拍下时间、订单完结时间、订单支付金额、订单状态流转都配置校验规则，订单拍下时间不会大于当天时间，也不会小于业务系统上线时间，一旦出现异常校验就不通过。当业务繁杂且规则繁多，规则配置等运行成本高时，同样根据数据资产等级进行监控。离线数据风险点监控本小节将介绍基于MaxCompute的数据仓库建设过程中离线数据的风险点监控，主要报对数据准确性和数据产出及时性的监控。数据准确性数据准确性是数据质量的关键，因此数据准确成为数据直连的重中之重，是所有离线系统加工时的第一保障要素，在此我们主要介绍通过DataWorks的数据质量工具——DQC来保障MaxCompute离线数据的准确性。注意，要用DQC，必须是使用DataWorks进行任务调度执行。我们先来认识DQC工具架构：DQC以数据集（DataSet）为监控对象，当离线MaxCompute数据发生变化时，DQC会对数据进行校验，并阻塞生产链路，以避免问题数据污染扩散。同时，DQC提供了历史校验结果的管理，以便对数据质量分析和定级。由上图我们看出DQC主要是通过配置数据质量校验规则，自动在数据处理过程中进行数据质量监控。DQC能监控数据质量并报警，本身不对数据产出进行处理，需要报警接收人判断并决定如何处理。DQC数据监控规则有强规则和弱规则之分。强规则，一旦触发报警就会阻断任务的执行（将任务置为失败状态，使下游任务不会被触发执行）；弱规则，只告警不会阻断任务的执行。DQC根据阿里内部的经验，提供了一些常用的规则模板，包括：表行数较N天前波动率、表空间大小较N天前波动率、字段最大/最小/平均值相比N天前波动率、字段空值/唯一个数等等，更多请参考DataWorks用户手册中数据质量模块介绍。DQC的工作流程如下图所示：由此看出DQC的检查其实也是运行SQL任务，只是这个任务是嵌套在主任务中，若检查的太多也会影响整体的任务执行性能，因此哪些数据需要配置DQC规则，应该配置什么规则，也要根据数据资产等级来确定。如A1、A2类数据监控率要达到90%以上，规则类需要3种以上，而不重要的数据资产不做强要求。类似的规则都是有离线开发人员进行配置来确保数据准确性，当然不同的业务会有业务规则的约束，这些规则来源于数据产品或者消费的业务需求，有消费节点进行配置，然后上推到离线系统的起点进行监控，做到规则影响最小化。数据的及时性在确保数据准确性的前提下，需要进一步让数据能够及时的提供服务，否则数据的价值将大幅降低，甚至无价值，所以确保数据及时性也是保障数据质量重中之重的一环。基于MaxCompute的离线任务，如常见的以天作为时间间隔，对于天任务，一些重要的业务会对数据产出有时间要求，比如一些决策报表要求9:00或更早必须产出。为确保数据完整性，天任务一般都是0点开始执行，计算刚过去的一天的数据，这些任务大多在夜里运行，要确保数据按时产出，需要考虑任务的优先执行（当Project里任务很多而资源有限的时候不得不考虑）和任务执行失败或时长过长时的告警问题。这里说的重要业务的“重要性”同样是前面所说的数据资产等级的划分，等级越高保障优先级越高。任务优先级。MaxCompute平台上任务优先级都是一样，无法配置。因此要对MaxCompute的任务实现“优先级”功能，只能从调度平台入手，优先调度下发重要的任务。DataWorks平台的调度任务，当对应的Project是使用预付费资源（预购固定的计算资源仅供当前项目使用）时，可以通过“智能监控”工具进行优先级设置。DataWorks的调度是一个树形结构，当配置了叶子节点的优先级，这个优先级会传递到所有的上游节点，而叶子节点往往就是服务业务的消费节点。因此在优先级的设置上，先确定业务的资产等级，等级越高的业务对应的消费节点优先级配置越高，优先调度从而优先占用计算资源，确保高等级业务准时产出。当DataWorks的节点任务所属的Project使用的是MaxCompute的后付费资源（计算按量付费，无固定资源使用），智能监控配置的优先级无效，因此，需要评估是否要购买预付费资源，同时对任务进行优化，减少不必要的资源浪费，力争在有限的资源下更高效的完成计算。任务报警。任务报警和优先级类似，通过DataWorks的“智能监控”工具进行配置，只需要配置叶子节点即可向上游传递。任务执行过程中出错或者可能出现延迟都是不可避免的，为了保障最重要数据（资产等级高）产出，我们需要“出错”立即处理、“可能”延迟必须知晓并介入。DataWorks—智能监控。MaxCompute的离线任务，通过DataWorks进行离线任务调度时，DataWorks提供智能监控工具，对调度任务进行监控告警。智能监控是DataWorks任务运行的监控及分析系统。根据监控规则和任务运行情况，智能监控决策是否报警、何时报警、如何报警以及给谁报警。智能监控会自动选择最合理的报警时间，报警方式以及报警对象。智能监控旨在：降低您的配置成本。杜绝无效报警。自动覆盖所有重要任务（数量已经多到您自己无法梳理）。数据质量衡量前面章节给出了保障基于MaxCompute的数据仓库数据质量的方案，但是这些方案是否真的合适，或者哪些点需要改进，这些需制定一套指标进行度量。比如：频繁的接到DataWorks的智能监控发出的告警；每一个数据质量事件发生，必须分析有原因、处理过程、后续同类事件预防方案；严重的数据质量事件升级为故障，并对故障进行定义、等级划分、处理、review。相关工具链接DataWorks-数据质量管理工具，文档，工具界面。DataWorks—智能监控工具，文档，工具界面。本文作者：海清阅读原文本文为云栖社区原创内容，未经允许不得转载。

整理了一些相关的产品，包括：商业系统InfoBrightGreenplum（已开源）、HP Vertica、TeraData、Palo、ExaData、RedShift、BigQuery（Dremel）开源实现Impala、Presto、Spark SQL、Drill、HawqDruid、PinotKylinpresto、druid、sparkSQL、kylin的对比presto和spark sql都是解决分布式查询问题，提供SQL查询能力，但数据加载不一定能保证实时；Druid是保证数据实时写入，但查询上不支持SQL，或者说目前只支持部分SQL，我个人觉得适合用于工业大数据，比如一堆传感器实时写数据的场景；Kylin是MOLAP，就是将数据先进行预聚合，然后把多维查询变成了key-value查询。基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速； presto：facebook开源的一个java写的分布式数据查询框架，原生集成了Hive、Hbase和关系型数据库，Presto背后所使用的执行模式与Hive有根本的不同，它没有使用MapReduce，大部分场景下比hive快一个数量级，其中的关键是所有的处理都在内存中完成。 Druid：是一个实时处理时序数据的Olap数据库，因为它的索引首先按照时间分片，查询的时候也是按照时间线去路由索引。 spark SQL：基于spark平台上的一个olap框架，本质上也是基于DAG的MPP， 基本思路是增加机器来并行计算，从而提高查询速度。 kylin：核心是Cube，cube是一种预计算技术，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。这几种框架各有优缺点，存在就是合理，如何选型个人看法如下：从成熟度来讲：kylin > spark sql > Druid > presto从超大数据的查询效率来看：Druid > kylin > presto > spark sql从支持的数据源种类来讲：presto > spark sql > kylin > Druid大数据查询目前来讲可以大体分为三类：基于hbase预聚合的。适合相对固定的业务报表类需求。需要指定预聚合的指标，在数据接入的时候根据指定的指标进行聚合运算，只需要统计少量维度即可满足业务报表需求。比如Opentsdb,Kylin,Druid等基于Parquet列式存储的，基本是完全基于内存的并行计算，Parquet系能降低存储空间，提高IO效率，以离线处理为主，很难提高数据写的实时性，超大表的join支持可能不够好。spark sql也算类似，但它在内存不足时可以spill disk来支持超大数据查询和join。比如Presto, Drill，Impala等基于lucene外部索引的，比如ElasticSearch和Solr,能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋欢迎订阅「K叔区块链」 - 专注于区块链技术学习 博客地址：http://www.jouypub.com简书主页：https://www.jianshu.com/u/756c9c8ae984segmentfault主页：https://segmentfault.com/blog/jouypub腾讯云主页：https://cloud.tencent.com/developer/column/72548

【摘要】传统关系型数据仓库的问题包括：成本高、计算封闭、性能差、管理难。那么，关系数据仓库问题多，为什么还要用呢？为什么不直接使用文件系统存储？我们为什么需要一种文件型数据仓库 / 集市！！！去乾学院看个究竟吧！ 体系结构方案 - 文件型数据仓库 / 集市文件型数据仓库 / 集市【附件下载：】体系结构方案 - 文件型数据仓库 / 集市.pdf

【摘要】多样性数据源普遍存在，且本身没有计算能力，常规手段总是需要建设专门的数据仓库及 ETL 转入工作，增加额外工作量，且实时性也不好。若采用专业的数据计算引擎，这些不足将迎刃而解！去乾学院看个究竟吧！优化体系结构 - 解决多样性数据源【下载附件】优化体系结构 - 多样性数据源

【摘要】存在问题：BI 系统后台计算由中央分布式数据仓库（MPP）实现，性能不佳，导致交互式多维分析响应迟钝。产生的原因：中央数据仓库上挂数十个应用，计算负担太重！解决方案：数据前置计算 / 缓冲层，由应用程序直接计算，不再请求中央数据仓库。使用常规数据库实现前置计算的“烦恼”： 全量数据前置？高频数据前置？SQL 转换问题？性能问题？去乾学院看个究竟吧！ 体系结构方案 -BI 系统的前置计算BI 系统的前置计算参考：数据蒋堂《BI 系统数据前置》文章。 方案附件下载： 《BI 系统的前置计算 V1.8.pdf》