Kylin

敬爱的社区小伙伴们，2021 年 12 月 21 日，冬至，咱们很快乐地发表 MLSQL 正式更名为 Byzer。Byzer 将秉持 MLSQL 低成本落地 Data + AI 的技术初衷，并交融更加凋谢且多元的语言及产品能力，打造更加欠缺的新一代开源语言生态。与此同时，全新的 Byzer 开源社区正式成立，社区官网（https://www.byzer.org) 曾经上线，欢送大家拜访。 全新的 Byzer 以及 Byzer 开源社区Byzer 这一名称源于中国现代神兽「白泽」，其能语言，通万物之情，知鬼神之事。咱们心愿 Byzer 能够像神兽白泽一样，让数据说「人」话。 Byzer 是一门联合了申明式编程和命令式编程的混合编程语言，其低代码且类 SQL 的编程逻辑配合内置算法及插件的加持，能帮忙数据工作者们高效买通数据链路，实现数据的荡涤转换，并疾速地进行机器学习相干的训练及预测。Byzer 语言的关键词如下： 万物皆表（Everything is a table）类 SQL 语法（SQL-like Language）内置算法和插件（Built-in Algorithms and Plugins）可定制，简略，弱小（Customizable, Simple and Powerful）Byzer 社区次要围绕 Byzer 语言来打造面向 Data + AI 畛域的开源生态，旨在帮忙用户以低成本和高效率的形式落地数据平台和实现 AI 工程化，开释数据分析师、工程师以及运维人员的生产力。目前 Byzer 社区内的我的项目均采纳 Apache License V2 发行，容许所有社区参与者在该协定下进行自在应用。 咱们为什么须要 Byzer随着大数据、人工智能、云计算等技术的迅速倒退，云基础设施、根底软件、算法模型等都逐步欠缺和成熟，业界对数据平台的效率诉求越来越高，低效的跨平台数据运行逐步成为工程师落地数据平台和实现 AI 工程化的痛点。然而，无论是从更换基础设施动手，还是换上更易用的框架，又或是招聘更优良的研发人才，都无奈做到大幅度的效率晋升。 咱们置信只有在编程语言层面进行变革，能力从根本上进步数据平台落地和 AI 工程化的效率。Byzer 作为一门低代码的开源编程语言，能够在语言层面将数据处理链路、AI 工程中的简单操作以及权限管控进行形象，同时升高编程语言的学习老本和上手老本，从而帮忙企业真正将效率晋升上来。 ...

在 Kyligence 推出的首期 Data & AI Meetup 中，畅销书《深刻了解 Spark 》作者、Kyligence 高级性能工程师耿嘉安带来了主题为「Spark Code Generation & Vectorization」的分享，深入浅出地解说了「Spark 为什么须要 CodeGen」、「Spark CodeGen 与向量化原理」、「Spark 向量化的前沿」等多个与 Spark 无关的热门话题，在直播间播种了一众好评。想理解更多，快往下看吧～ 以下为耿嘉安在直播间演讲实录 主题背景Spark 我的项目是在2010年左右开源进去的，越来越多的人理解到了 Spark 这个开源大数据我的项目的存在。从其诞生之初到现在 Spark 3.2.0 版本的公布，整个大数据圈中但凡用了 Spark 的公司和集体，都始终致力于对它的性能进行极致的优化。时至今日，国内外的各大厂商都把性能优化的锋芒直指向量化技术，用意可能把 Spark 的性能齐全压迫进去，让它可能更加迫近硬件的性能。 Vectorization（向量化）明天分享的主题都围绕着一个关键词，即 Vectorization ，翻译成中文就是“向量化”的意思。什么叫“向量化”呢？ 其实程序员刚开始学习如何申明一个变量的时候，就曾经开始缓缓地接触到“向量化”了。一般来说，须要申明的这个变量是根底类型或是原始类型，这样的类型在向量化的畛域被称为标量，能够认为它是个一维的货色。比方我要去申明一个数组，这个数组中各个元素的值不一样，但代表的都是同一个含意，对这些内容进行操作时，如果采取批量操作，就可能防止独自操作的反复和繁琐。 作为一个向量，如果能用向量的计算形式，甚至是用一些离散数学中向量的计算形式，从数学的角度来看就曾经很简略了。而明天探讨的不光是数学的问题，更多的是计算机的问题。有了向量后，一些 CPU 的厂商也开始意识到了这个问题，研制出了一些专门的 CPU 指令，这些指令专门应答向量数据，可能对向量进行批量的计算解决。 演讲目录上面咱们开始由浅入深地一步一步来，我明天主题分享的 Agenda 如下： Java VectorizationVolcano Iterator ModelTungsten ProjectSpark Code GenerationSpark Code Generation & VectorizationThe frontier of Spark Vectorization主题分享1.Java Vectorization首先给大家介绍一下 Java 的向量化，因为其实在整个大数据畛域中，最次要的语言就是 Java，或者说是 Java 生态的货色。而明天又要讲 Spark，所以不可避免地要说一下 Java 的向量化是怎么做的。 ...

★NEWS★ Kyligence 再获国际级认可！The Channel Company® 旗下媒体 CRN® 于近日发表 Kyligence 入围 2021 Tech Innovator Award · Big Data（2021 年技术创新奖之大数据），并被评为 2021 Tech 10: Turning Big Data Into A Big Win（赋能企业利用数据获得竞争劣势的十大厂商）。此次间断入选 CRN 奖项是对 Kyligence 的翻新技术及产品的认可，亦再次彰显了 Kyligence 在国内市场一直增长的影响力。 随着各行业对数字转型的需要继续激增，技术创新的步调也在持续放慢。新冠疫情给商业世界带来了微小而粗浅的变动，在这个时机与挑战并存的环境中，寰球科技行业的厂商都开始推出差异化的翻新产品来助力寰球企业在强烈的竞争中取得劣势。 2021 Tech Innovator Award · Big Data 2021 年度技术创新奖之大数据类别 到底什么才是 2021年实现翻新的技术呢？哪些新技术为一线客户提供了优质的产品及解决方案？2021 年 CRN 技术创新者奖展现了带来重大提高技术和合作伙伴增长机会的产品，本年度奖项共笼罩了 47 个不同技术类别的信息技术渠道厂商，包含云、基础设施、平安、软件和网络等要害畛域。 为了提拔出真正具备技术创新性和渠道敌对的产品，在思考了要害能力、独特性、技术先进性以及满足客户和合作伙伴需要的能力后，CRN 评审委员组从 373 个产品及技术供应商中提拔出了入围者及获胜者。Kyligence 凭借在大数据管理和服务平台的技术深耕、翻新产品及业余服务，入围 2021 年技术创新奖之大数据类别。 “ CRN 2021 年度技术创新者奖旨在表彰寰球的技术厂商，这些入围的厂商利用翻新技术打造的产品和服务促成了寰球企业的继续业务增长。恭喜所有入选 CRN 技术创新奖的厂商，咱们也很骄傲地意识这些推动寰球信息技术畛域改革和翻新的一流企业。——The Channel Company CEO Blaine Raddon” ...

前言大家都晓得，数据分析我的项目从需要提出到最终交付要经验一个漫长的过程，须要进行数据源整合、指标定义、模型开发、数仓工作开发及运维、报表开发等一系列环节，开发周期动辄都是以周为单位，而且业务场景也并非变化无穷，一旦产生指标逻辑的变更，数仓就要从新开发刷数，这让需要和开发两方本就缓和的关系更加“雪上加霜”。总结起来，就是当下 BI 应用中的痛点： 数据加工链路长，灵活性差PB 级数据难以实现秒级响应能力数据起源繁冗，不足对立语义治理能力指标数量越来越多，达到上千甚至更多业务人员应用门槛过高只有突破了这些 BI 应用中的壁垒，能力让数据分析平民化不只停留在一句口号，数据分析师们才有机会把更多工夫投入到业务剖析这些更具价值的中央。那么问题来了，有没有一个“低门槛”的平台，能够让业务人员自主进行模型构建、指标定义和工作治理等操作，而后无缝对接 BI 工具进行探索性剖析呢？当初 Kyligence + Tableau 给企业提供了一个优良的解决方案。 Tableau 作为 BI 工具畛域的领导者, 始终是泛滥企业进行数据可视化的首选，其弱小而灵便的开发能力让数据分析师能够疾速进行报表开发，也能够让业务人员进行直观的自助式剖析。 Kyligence 提供了 AI 加强的数据服务和治理平台，帮忙数据分析师和工程师轻松从本地到多云架构上构建受治理的数据服务。Kyligence 提供了针对企业级客户场景的本地部署产品 Kyligence Enterprise 和云端托管产品 Kyligence Cloud。 无论是独自应用 Tableau Desktop，还是通过将内容公布到 Tableau Server，用户都能够间接应用存储在 Kyligence 中的数据。 Kyligence 向下可对接关系型数据或 Hadoop 数据源，如 Hive 等，在云上反对对象存储，及云上数据仓库，无效屏蔽底层数据源差别，在 Kyligence 对立建模，进行维度指标定义。同时向上连贯到 Tableau Desktop 或 Tableau Server，进行数据公布和剖析。 Kyligence + Tableau 联结解决方案的外围劣势如下： 架构可扩大，查问响应快。应用 Tableau 直连形式可解决万亿行数据，直连查问性能放弃在秒级，反对高并发的同时放弃高性能。对立的语义层。屏蔽底层数据源差别，在 Kyligence 端对立建模；同时反对一键同步 Kyligence 模型语义定义至 Tableau，无需反复建模。自助式剖析。在 Kyligence 多维模型与预计算技术撑持下，充分发挥 Tableau 灵便、自助个性，满足 BI 平民化的自助式剖析需要。AI 主动建模。Kyligence AI 智能举荐引擎可利用主动建模技术疾速设计和构建数据模型，进步数据开发效率，缩减数据分析周期。当初就让咱们用数据谈话，看看 Kyligence + Tableau 的解决方案是如何在理论业务场景中帮忙客户冲破数据分析链路上的瓶颈，赋能数据分析平民化的吧。 ...

近日，Kyligence 联结创始人兼 CTO 李扬缺席“亚马逊云科技 INNOVATE｜ 数据驱动翻新大会”，并发表 《 Kyligence + 亚马逊云科技｜实现云上的精细化经营和数字化指挥》主题演讲，他结合实际利用案例深入浅出地给出了 Kyligence 对于企业数字化转型过程中所面临的窘境的解答。 以下为李扬在大会演讲文字实录： 企业数字化治理的窘境Gartner 在采访完泛滥企业后总结出了当今数字化转型中很多 CIO 的次要焦虑所在： 无奈找到最有价值的数据；将大量工夫花在寻找数据中而非剖析数据中；在跨部门的全局数据分析中，不足对立的数据语义。造成这些焦虑的次要起因，是因为企业在事实的业务建设中采纳了垂直的烟囱式建设，短少程度的对齐。这就导致了企业的业务数据不足治理，会因为数据口径凌乱而造成数据过于简单、找不到数据等诸多问题。 那么如何解决这些焦虑呢？ 数字化指挥从“业务数字建模”开始在数据源到数据利用的过程中退出一个数字建模平台是解决这些焦虑的最好形式。以业务数字模型为核心，每一个业务人员都能够用数据来优化本人的日常工作，而非间接和技术数据打交道。 其中的逻辑关系与“农场经营类游戏”相似，在游戏中，农场主作为一个农场的数字化指挥官，可能在控制面板中以上帝视角掌控整个农场的日常运作，这便是业务数字建模的逻辑。 而将事实的农场形象到数字世界中，须要实现业务对象、业务流程、业务规定三者的数字化建模的过程。一旦实现了这一事实到电子世界的转换，就可能在电子世界当中指挥和运筹，优化事实中的工作效率。通过优化后的事实又会给到咱们最新的反馈、业务对象的状态以及流程的状态，安顿进行下一轮的指挥，这样就造成了一个正向的飞轮效应。 不过，这在事实环境中有些艰难。从技术的层面来看，这些企业的确曾经具备了如数据仓库、数据湖等的对立的数据平台，但当这些数据对接到业务之时，出现一种垂直型的“烟囱式建设”。在这种建设模式中，业务模型通常位于烟囱的最顶端，是由业务分析师在脑中产出这个业务模型后，再由数据工程师们实现由数据到业务模型的转化，即为一个分析师+一群工程师的一种劳动密集型的数据分析形式。 使用这种剖析形式，业务模型将无奈失去积淀。这意味着当企业须要建设一条新的业务线时，之前的业务教训难以被复用，也就没有横向的对齐，无奈产生全局视角，更不必谈全局指挥。 Kyligence 智能数据云底座 1.数据治理必须从技术层面回升到业务层面 要扭转这一现状，数据的治理必须从技术层面回升到业务层面。在技术的数字平台之上须要有一层业务的数字平台，能够将其称为业务数字模型层，也能够叫它业务语义层。作为一个平台层，它的作用是逐渐地整顿、积淀、复用企业的业务数字模型。在一条业务线进行垂直建设的同时，可能把业务数字模型留在这个档次中。这样当咱们做下一条垂直建设的时候，它就能够做到横向的对齐和买通，无效缩小反复建设。它的价值还在于可能造成一个全局统一口径的数字化指挥棒，不论是在高层、中层还是基层、跨部门，企业都可能使用这个对立的规范（比方：KPI 规范）。在企业日常经营的过程当中，就可能呈现出高度对齐、力出一孔的状态。 无关业务数字模型（即业务语义层）的想法在经典数仓实践与《华为数据之道》中均有所提及，经典实践也举荐咱们要将其进行积淀，而当下很多企业在数字化建设的过程中只关注到了技术层面，往往漠视了业务数字建模的层面。 2.基于业务模型提供服务，让人人都是分析师 一旦做到了业务数字建模，它将会产生一系列空谷传声的劣势。其中，最直观的一点就是：基于业务模型提供数据服务，能够让数据民主化失去实现，人人都能成为分析师。因为对于分析师来说，如若可能间接与数据服务层进行交互，就能够不再依赖工程师为其收集数据，而是间接进行数据分析，从而实现独立工作。 Kyligence的外围是一个多维数据库，它区别于传统的关系型数据库，是一个可能体现业务模型的中央。所谓业务模型，就是以“指标”、“标签”、“维度”、“度量”等这类传统业务人员都能够了解的概念提供数据服务，普通人无需数据库根底就能应用。相比于从前的关系型数据资产而言，给予了一般业务人员自我了解和本人操作的可能性。 在应用数据方面，Kyligence 反对摸索、微翻新甚至合作分享数据。比方某银行的某个站点产生了一些数据的摸索和翻新，银行心愿这些成绩可能积淀到业务模型中，甚至分享给平行的其余分行的大堂经理，这个指标能够在多维数据库的模型层面得以实现。 再举一个具体的例子，某银行用意在 2019 年减少 5000 个分析师，这 5000 个分析师如果是通过教会他们应用传统的关系型数据库来进行培训，产生现实成果的可能性很低。而如若应用多维数据模型提供的业务型的数据服务来赋能，他们不须要太多额定的学习就能间接应用数据。当他们用 Excel 的 PivotTable 性能连贯上 Kyligence 的多维数据模型服务，就可能间接自助式地应用数据。这样就能极大地开释数据的生产效率，让 5000 个一般的业务员间接应用数据来优化他们的日常工作。 3.AI 加强的数据服务和治理平台能力 Kyligence 提供的另一层能力是 AI 加强的数据服务和治理平台能力，可能通过 AI 自动化做到降本增效。一旦业务模型建设了之后，就能够依据业务模型中高频维度、度量组合来主动优化数据索引。能够在业务模型这一层通过统计很快发现最有价值的数据以及低频数据。咱们也能够通过逆向工程，从一些传统的 SQL 外面来帮忙大家倒推出业务模型。此外，还有主动的数据筹备，从业务的定义开始就可能主动地把技术层面的数据回升到业务层面。 Kyligence 具备凋谢的技术标准，整套零碎能够无缝对接各个支流的 BI 平台。这就意味着不论用的是哪种 BI 工具，都可能对接到统一标准的数据语义层，即规范的业务模型上。平台提供的数据接口也是规范且凋谢的，包含 SQL、MDX、Rest API。最底层有着开源的技术引擎，包含 Kylin、 ClickHouse 和 Spark 。 ...

明天，每家公司都是数据公司，人人都是数据专家。不管您是信贷经理、会计师、销售、人事经理还是工程师，这都不影响您进行数据处理并从中洞察先机。正是因而，平民数据科学家（CDS）这一概念应运而生，各行业的从业者们正借助数据和分析模型来获取与其业余畛域相干的洞察力。绝对平民数据科学家（CDS），咱们更偏向应用平民数据分析师（CDA）这种说法，因为在与数据的交互中，常识工作者所融入其中的不仅是迷信，还有艺术。 依据 Gartner 的定义，“平民数据科学家是创立或生成模型的人，这些模型使用了先进的诊断剖析、预测或阐明性能。不过这些人的本职工作却是在统计和剖析畛域之外。”[Idoine，2018 年] 那么，平民数据分析师们如何能从数据和剖析中获取决策洞察？又是哪些工具和个性赋能了他们？ 从根本上说，胜利的平民数据分析师能够通过三大要害因素获取洞察并进步业务绩效： 高质量的业务数据持重的自助剖析平台弱小的数据和剖析治理流程这三大要害因素有心愿满足当初日益简单的数据分析需要，赋能业务用户，使其能依据本身需要获取要害答案。尽管每家公司或组织中平民数据分析师们的能力多样，但这并不障碍咱们找出一些通用的要害因素或解决方案。 关注数据自身 首先，如何解决剖析中的数据品质问题？高质量数据，是指咱们须要有价值的、而非更多的数据来获取洞察。在数据分析畛域，咱们次要从以下三个方面来判断数据是否有价值： 正确的维度数据分析是要通过已知数据找出对已知问题的答案和未知问题的事后洞察。洞察的获取则取决于反馈（成果）和解释（起因）变量，也被称为特色或维度。维度的次要作用是限定诸如价格、数量和周期等业务相干度量的利用场景。 正确的数据结构在企业通过业务收集的数据中，高达 80% 是非结构化数据，比方文档、视频、音频、图像等数据。大家都晓得剖析算法须要数据模型来对数据进行剖析和解决，但因为这些非结构化数据中并没有预约义数据模型，企业难以充分利用这些数据和施展它们的价值。 较少的变动业务流程中不可避免的会存在一些变动，这种变动同样会反映在数据中。数据的变动使剖析算法很难做出及时和精确的预测。 自助式剖析平台聊完数据品质的重要性，咱们再来看看如何通过自助剖析平台赋能平民数据分析师。如能领有自助剖析平台，业务人员将只须要极少的 IT 反对就能执行查问并获取后果。在平民数据分析师们的剖析工作中，一个持重的自助剖析平台应提供如下外围性能： 数据加载剖析平台的价值取决于它的可用数据。因而，自助剖析平台应能轻松对接现有数据源，无论是规范数据库（如数据仓库）还是记录零碎（如 ERP 或 CRM）。不管数据源是部署在本地、云上还是混合云中，自助剖析平台都能轻松治理数据索引（以实现高效搜寻）、执行数据加载和刷新。 数据品质和及时性数据的品质和及时性决定了洞察的无效和准确性。如存在积重难返的数据孤岛，这二者都很难保障。如果没有良好的数据品质，洞察和论断的真实性将无奈保障。同样，如果没有足够及时的数据，那咱们极可能会基于过来的数据对明天进行假如。 性能、规模及并发性如果响应工夫很长，或仪表盘处于长期无响应状态，那自助剖析平台将无奈应用。真正的平民数据分析师， 更心愿能通过数据来跟踪和证实或反驳他们对所剖析世界的了解和判断。他们应该能疾速对数据进行摸索并失去想要的数据。 数据安全自助剖析平台并不代表安全性的升高或齐全没有安全性；平安治理是自助剖析和平民数据分析师胜利的先决条件。自助剖析平台应反对通过 IDM（身份治理）和 RBAC（基于角色的访问控制）对平民数据分析师进行身份验证，以便管制和治理对敏感数据的拜访，如 PCI DSS（支付卡行业数据安全规范）和 PII（个人身份信息）。 语义模型 剖析论断的得出依赖于从各个系统中获取的数据。思考到大家对数据元素的定义各不相同，咱们迫切需要能通过语义或其余形式来示意数据的含意。语义模型形容了特定数据值之间的关系 [Luisi, 2014]。因而，自助剖析平台应该能为平民数据分析师提供对立的语义模型，从而建设一个繁多的实在起源（SoT），以便获取精确、及时的洞察。 剖析算法库自助剖析平台中应蕴含大量经工夫验证的剖析算法库，包含能拜访如 TensorFlow、Keras、scikit-learn 等开源库。这样平民数据分析师将能轻松重用现有剖析算法，而非从头构建本人的解决方案。 数据治理最初，没有正确的数据治理，同样无奈赋能平民数据分析师。平民数据分析师无疑很弱小，但对他们的赋能同样须要一个弱小的治理框架来治理。治理框架应能： 明确数据所有权角色评估数据素养培训优化查问预计算后果标记未应用的报告和仪表板监控零碎性能其余监管和数据管理流动那么如何将高质量的业务数据、持重的自助剖析平台及弱小的数据和剖析治理流程组合在一起，胜利赋能平民数据分析师呢？Kyligence 以 Apache Kylin 为外围，通过平安的集成来自各数据源的数据为平民数据分析师提供了一个整体的剖析平台，为其创立一个整合的、有价值的语义数据库，使其能获取近乎实时的弱小洞察力。通过自动化数据发现、数据集成和提供低代码/无代码的剖析库，Kyligence 为平民数据分析师带来了无缝及平安的数据洞察，进一步解放他们的生产力。 Kyligence 和数据分析平民化 Kyligence 始终在提倡「数据分析平民化」这一理念。在大数据分析畛域，Kyligence 所打造的自助剖析平台取得了宽泛的利用，播种了来自金融、批发、制作等行业的客户，接下来咱们将简要介绍 Kyligence 的劣势： 数据源Kyligence 反对 Hadoop、RDBMS、数据仓库和数据湖等当先的数据平台，简化数据接入并实现多云部署。 数据品质Kyligence 通过治理来自不同数据平台及 Kafka 等实时流数据平台的数据，产出高质量数据，从而能构建反对批数据源和实时数据源的混合分析模型。借助对立语义层，平民数据分析师能够取得规范的维度和度量定义，实现繁多数据源。 高性能、高并发、大规模Apache Kylin（分布式 OLAP）和 ClickHouse（MPP）的强强联手，更使得 Kyligence 在剖析查问、明细查问或各类长期查问中都有十分高性能的体现。即使是面对极大数据集，平民数据分析师也能疾速执行数据检索。 保障数据安全Kyligence 可提供单元格级别的平安爱护，管制后端数据拜访，并使其对用户通明。除基于角色的访问控制外，Kylignece 还反对与 LDAP 和 Azure Active Directory 等用户管理系统集成以确保合作平安。 ...

Atlas视频教程公布后，有谷粉说：就这？我两天就学完了。垒哥小浣熊脸，不服又很无奈：人生路还很长，年轻人别太狂。咱们尚硅谷的大数据学科，不能给生产队的驴和老母猪争脸！ 来来来，视频教程包罗万象：DataX、大数据监控告警零碎、Superset、Flink CDC、Flume、数据仓库4.0、ClickHouse、Hive源码解析及优化、Zookeeper、Elasticsearch、Scala、Azkaban、Hadoop、Flink内核源码解析……更多大数据视频教程在路上！ 获取尚硅谷大数据学科全套视频，公众号聊天窗口发送暗号：大数据。在线看、下载看、学习线路图、课件……满足你对小电影的全副渴望！ 这么多视频还看不过瘾？本周五晚八点大海哥现身聊大数据：详解30万年薪和60万年薪的学习线路图。补常识不如补思维，学常识不如学办法，人与人的差异，骨子里是思维模式的差异。走过路过，不要错过尚硅谷最帅的男人！ 咱们要做大数据圈的微光，小树林里的响箭，做在寂寞里飞驰的真猛士。这不，垒哥也没闲着，再来拱一波：尚硅谷Kylin视频教程公布！ B站中转：传送门：https://www.bilibili.com/vide... Apache Kylin是一个开源的分布式剖析引擎，为大数据开发人员提供Hadoop/Spark之上的SQL查问接口及多维分析能力，并反对超大规模数据。目前在各大互联网企业有极其宽泛的利用，是大数据开发人员的必备技能之一。 本套视频教程不仅解说了Kylin的日常应用，还从根本的前置概念动手，解说了Kylin的底层架构，通过筹备原始数据，一步步开展介绍Kylin的装置部署和惯例操作；并联合具体案例，深入分析了Kylin的cube构建算法等底层原理；在理论利用层面详解了罕用的Kylin优化伎俩和BI工具，如JDBC和Zeppelin。教程提供全套视频、代码、笔记及材料，解说不局限于外表利用，更深刻其底层原理，一套教程搞定Kylin！Kylin教程简介尚硅谷视频下载导航及学习路线请拜访：http://www.atguigu.com/downlo...关注尚硅谷B站官网账号，一手最新视频教程领先看！传送门：https://space.bilibili.com/30...Kylin教程具体目录01.Kylin-简介02.Kylin-前置概念03.Kylin-架构介绍04.Kylin-特点介绍05.Kylin-hbase装置和启动06.Kylin-kylin的装置启动和登录07.Kylin-实战-筹备数据&创立工程&对接数据源08.Kylin-实战-创立model09.Kylin-实战-创立cube&构建cube10.Kylin-实战-kylin和hive性能比照11.Kylin-实战-应用注意事项12.Kylin-实战-实现每日主动构建Cube13.Kylin-原理-cube存储原理14.Kylin-原理-cube构建算法15.Kylin-优化-衍生维度16.Kylin-优化-聚合组17.Kylin-优化-RowKey设计优化18.Kylin-BI工具-JDBC19.Kylin-BI工具-Zeppelin 1024尚硅谷直播大会开启传送门：www.atguigu.com/1024大厂学苑第二季震撼改版重装上线：www.itdachang.com每个时代，自在都面临着四大挑战：强人对势力集中的渴望，富人对财产不均的恼恨，无知者对乌托邦的向往，无信仰者将自在和放荡一概而论。 ——阿克顿勋爵想在不学习和不提高的状况下找到高薪工作，就像试图在不出门和不聊天的状况下找到对象，要有“三日不学习，便觉面目可憎”的心态，只有足够自律，能力给你自在！《缄默的羔羊》里有这样一句歌词：我不是缄默的羔羊，我也有幻想，当今天太阳升起，照在我的脸上，我一样能散发光辉。 几十年后，你要挂了，但愿能够洒脱地说一句：岁月不饶人，我亦未曾饶过岁月。

全局字典解说为什么须要全局字典在OLAP数据分析畛域，去重计数(Count distinct)是十分常见的需要，而依据去重后果的要求又分为近似去重和准确去重。 在大规模数据集下，要想做到准确去重还要保障查问疾速响应还是很有挑战性的。咱们晓得准确去重常常用到的解决形式就是位图法(Bit map)。对于整型数据，咱们能够将统计信息保留在Bit map中，然而理论解决的数据中除了整型还会有String等其余类型，如果想做到准确去重首先就须要构建一个字典来为这些数据进行对立映射,而后再通过Bit map法进行统计。 咱们都晓得Kylin通过预计算技术来减速大数据分析。在增量构建Cube的时候，为了防止不同的segment独自构建字典导致最终去重后果出错，一个Cube中所有的Segment会应用同一个字典，也就是全局字典(Global Dictionary)。 全局字典的演变Kylin从1.5.3版本就开始反对全局字典性能，然而这时的构建形式也具备显著的缺点： 全局字典在Job Server上进行单点构建，随着数据增多构建时长变得不可控随着数据积攒，全局字典的构建对Kylin 构建节点的内存的需要会一直增多受限于整型最大数量的限度其实在Kylin3.1中曾经退出了基于Hive的分布式全局字典构建，它曾经解决了以上问题，详情能够查看Kylin分布式全局字典 。然而Kylin 4.0为了适应全新的构建查问引擎，基于spark实现了另外一种分布式构建全局字典的形式，明天咱们就来详细描述一下Kylin 4.0的全局字典是如何实现的。 基于Spark的全局字典Kylin 4.0构建全局字典的形式基于Spark进行分布式的编码解决，减小了单机节点的压力，构建字典数量可能冲破整型最大数量的限度。 设计与原理全局字典的构造每一次构建工作会生成一份新的全局字典每次新的构建工作的字典按版本号进行保留, 旧的全局字典会被逐步删除一份字典包含一份meta数据文件和多个字典文件, 每个字典文件称之为桶(Bucket)每个桶分为两个映射( Map<Object, Long>), 两者合并为残缺的映射关系 Bucket的概念与转化Kylin引入了桶这一概念，能够了解为在解决数据的时候，将数据分到若干个桶(即多个分区)中进行并行处理。 第一次构建字典的时候会对每个桶内的值从1开始编码，在所有桶的编码实现之后再依据每个桶的offset值进行整体字典值的调配。在代码中两次编码是通过两个HashMap进行存储的，其中一个存储桶内绝对的字典值，另一个存储所有桶之间相对的字典值。 下图所示的是编号为1的桶屡次构建工作中，桶内字典的传递，每一次构建都会为桶创立一个新的版本(即v1, v2, v3等)，退出版本控制的起因前面会有解释。Curr(current)和Prev(Previous)是一个桶内的两个HashMap，别离存储着以后桶内字典的绝对(Relative)编码值和之前曾经构建的所有字典值的相对(Absolute)编码值。 构建步骤通过 Spark 创立平表并获取需准确去重列的 distinct 值依据确定去重后的字面值数量来确认分片数, 并且依据需要判断是否须要扩容将数据调配(repartition)到多个分片(Partition)中，别离进行编码, 存储到各自的字典文件中为以后构建任务分配版本号保留字典文件和 metadata数据(桶数量和桶的 offset 值)依据条件判断须要删除旧版本首次构建计算桶的大小 取须要构建字典的数量解决单个桶阈值和桶数量默认值的最大值。创立桶并调配数据进行编码生成meta文件记录桶的offsets以下是相干配置项及其默认值。 kylin.dictionary.globalV2-min-hash-partitions=10kylin.dictionary.globalV2-threshold-bucket-size=500000 非首次构建依据字典数量确定桶是否须要扩容已编码的字典值对扩容后的桶进行重新分配读取之前最新版本的字典数据，并调配到各个桶中将新的值调配到桶中前一次构建的字典值不会扭转 版本控制全局字典会通过给单次构建调配基于工夫戳的版本号来进行隔离。退出版本控制的起因是构建工作可能会并发执行，而以后构建全局字典过程中的编码是不反对并发。通过版本控制，每一次编码都可能残缺的读取之前构建好的全局字典，这样就保障了最新版本的字典领有最残缺的全局字典编码，而且一个Cube的全局字典每次被读取的时候都会选取最新版本的字典。字典最终在文件存储系统(此处为HDFS)上按版本存储如下图所示。 常见问题为什么在一个BucketDIctionary须要应用两个Map?构建过程开始须要对调配到各个桶内的字典从1开始做一个绝对(Relative)编码，这一部分字典绝对编码值会存储在一个HashMap中，在绝对字典值编码实现后，会失去每个桶的offset值，也就是桶内字典的数量，而后依据这个字典值计算出每个桶(桶是有程序的)内字典值绝对于所有桶的offset值的相对(Absolute)编码,字典的相对编码也会用另一个HashMap进行存储。 会不会存在数据歪斜问题?当初测试下来因为热点构建不进去的概率很小，个别歪斜十亿级别才会过不去,列很多确实可能会造成这个问题,不过编码的桶数是能够有限放大的 除非单key热点，否则调整参数也是很轻松实现构建。 为什么全局字典的数量可能超过整型最大基数(21亿)的限度？因为引入了全新的BitMap数据结构Roaring64BitMap，在全局字典编码实现之后,编码会被压缩成二进制存储在Roaring64BitMap对象中，BitMap实际上是通过Long而不再是Integer进行存储的。

转载自Apache Kylin公众号(作者也是我)：原文链接，该文章是2020年4月18号Kylin on Parquet介绍及疾速上手线上meepup分享的总结文章。因为Kylin on Parquet目前还在不停地迭代倒退，所以此处也对原文中的局部中央做一下更新。 在构建局部讲到的CountDistinct, TopN, Percentile，这些度量目前曾经都反对了，详情请见KYLIN-4462。补充了主动重试局部PPT页构建局部性能数据是我的项目比拟晚期收集，最近又有了更新更具体的比照介绍，详情请见《去 HBase，Kylin on Parquet 性能体现如何？》前言Apache Kylin on Apache HBase 计划通过长时间的倒退曾经比拟成熟，然而存在着肯定的局限性。Kylin 查问节点以后次要的计算是在单机节点实现的，存在单点问题。而且因为 HBase 非真正列存的问题，Cuboids 信息须要压缩编码，读取 HBase 数据的时候再反序列化、宰割，额定减少了计算压力。另外，HBase 运维难度比拟大，不便于上云。面对以上问题，Kyligence 推出了 Kylin on Parquet 计划。下文中，Kyligence 的大数据研发工程师王汝鹏解说了 Kylin on Parquet 解决方案的架构、原理以及如何开发调试代码。本文次要包含以下几方面的内容：首先会给大家介绍架构设计，而后阐明一下咱们为什么会去做 Kylin on Parquet，接下来会介绍一下全新的构建和查问引擎以及相比拟于 Kylin 3.0 的性能体现，最初有一个现场演示 Demo，给大家介绍一下产品的应用和代码调试办法。 架构Apache Kylin 很早就被设计成了可插拔的架构，基于这种架构咱们就能够很不便的去替换某个模块而不会影响其余模块。 Kylin on Parquet 也是在 Kylin 原来架构的根底上实现了新的查问、构建引擎和存储模块。通过 Spark 实现的查问引擎，可能提交计算工作到 Yarn 上，实现分布式的解决。 Cube 构建这边也是齐全通过 Spark 进行解决，不再反对 MapReduce 构建。数据源当初反对 Hive 和本地 CSV 数据源，目前能够解脱沙箱的限度，通过本地的 CSV 数据源搭建一个调试环境。存储层去掉了 HBase，最终构建实现的 Cube 数据都是通过 Parquet 的模式间接存储在文件系统中。 ...