大数据

简介： 数据模型就是数据组织和存储办法，它强调从业务、数据存取和应用角度正当存储数据。 前言： -更多对于数智化转型、数据中台内容请退出阿里云数据中台交换群—数智俱乐部 和关注官网微信公总号（文末扫描二维码或点此退出） -阿里云数据中台官网 https://dp.alibaba.com/index起源：数智化转型俱乐部 随着DT时代互联网、智能设施及其他信息技术的倒退，数据爆发式增长，如何将这些数据进行有序、有构造地分类组织和存储是咱们面临的一个挑战。 如果把数据看作图书馆里的书，咱们心愿看到它们在书架上分门别类地搁置；如果把数据看作城市的修建，咱们心愿城市规划布局合理；如果把数据看作电脑文件和文件夹，咱们心愿依照本人的习惯有很好的文件夹组织形式，而不是蹩脚凌乱的桌面，常常为找一个文件而手足无措。 数据模型就是数据组织和存储办法，它强调从业务、数据存取和应用角度正当存储数据。Linux的创始人Torvalds有一段对于“什么才是优良程序员”的话：“烂程序员关怀的是代码，好程序员关怀的是数据结构和它们之间的关系”，其论述了数据模型的重要性。有了适宜业务和根底数据存储环境的模型，那么大数据就能取得以下益处。 性能：良好的数据模型能帮忙咱们疾速查问所须要的数据，缩小数据的I/O吞吐。老本：良好的数据模型能极大地缩小不必要的数据冗余，也能实现计算结果复用，极大地升高大数据系统中的存储和计算成本。效率：良好的数据模型能极大地改善用户应用数据的体验，进步应用数据的效率。品质：良好的数据模型能改善数据统计口径的不一致性，缩小数据计算错误的可能性。因而，毋庸置疑，大数据系统须要数据模型办法来帮忙更好地组织和存储数据，以便在性能、老本、效率和品质之间获得最佳均衡。 1．关系数据库系统和数据仓库E .F .Codd是关系数据库的鼻祖，他首次提出了数据库系统的关系模型，创始了数据库关系办法和关系数据实践的钻研。随着一大批大型关系数据库商业软件（如Oracle、Informix、DB2等）的衰亡，古代企业信息系统简直都应用关系数据库来存储、加工和解决数据。数据仓库零碎也不例外，大量的数据仓库零碎依靠弱小的关系数据库能力存储和解决数据，其采纳的数据模型办法也是基于关系数据库实践的。 尽管近年来大数据的存储和计算基础设施在分布式方面有了飞速的倒退，NoSQL技术也曾风行一时，然而不论是Hadoop、Spark还是阿里巴巴团体的MaxCompute零碎，依然在大规模应用SQL进行数据的加工和解决，依然在用Table存储数据，依然在应用关系实践形容数据之间的关系，只是在大数据畛域，基于其数据存取的特点在关系数据模型的范式上有了不同的抉择而已。对于范式的具体阐明和定义，以及其余一些关系数据库的实践是大数据领域建模的根底，有趣味的读者能够参考相干的经典数据库实践书籍，如《数据库系统概念》。 2．从OLTP和OLAP零碎的区别看模型方法论的抉择OLTP零碎通常面向的次要数据操作是随机读写，次要采纳满足3NF的实体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性问题；而OLAP零碎面向的次要数据操作是批量读写，事务处理中的一致性不是OLAP所关注的，其次要关注数据的整合，以及在一次性的简单大数据查问和解决中的性能，因而它须要采纳一些不同的数据建模办法。 3．典型的数据仓库建模方法论ER模型 数据仓库之父Bill Inmon提出的建模办法是从全企业的高度设计一个3NF模型，用实体关系（Entity Relationship，ER）模型形容企业业务，在范式实践上合乎3NF。数据仓库中的3NF与OLTP零碎中的3NF的区别在于，它是站在企业角度面向主题的形象，而不是针对某个具体业务流程的实体对象关系的形象。其具备以下几个特点： 1）须要全面理解企业业务和数据； 2）施行周期十分长； 3）对建模人员的能力要求十分高； 采纳ER模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性解决，为数据分析决策服务，然而并不能间接用于剖析决策。其建模步骤分为三个阶段： 1）高层模型：一个高度形象的模型，形容次要的主题以及主题间的关系，用于形容企业的业务总体详情。 2）中层模型：在高层模型的根底上，细化主题的数据项。 3）物理模型（也叫底层模型）：在中层模型的根底上，思考物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。 ER模型在实践中最典型的代表是Teradata公司基于金融业务公布的FS-LDM（Financial Services Logical Data Model），它通过对金融业务的高度形象和总结，将金融业务划分为10大主题，并以设计面向金融仓库模型的外围为根底，企业基于此模型做适当调整和扩大就能疾速落地施行。 **维度模型 ** 维度模型是数据仓库畛域的Ralph Kimball巨匠所提倡的，他的The Data Warehouse Toolkit-The Complete Guide to Dimensional Modeling是数据仓库工程畛域最风行的数据仓库建模的经典。 维度建模从剖析决策的需要登程构建模型，为剖析需要服务，因而它重点关注用户如何更疾速地实现需要剖析，同时具备较好的大规模简单查问的响应性能。其典型的代表是星形模型，以及在一些非凡场景下应用的雪花模型。其设计分为以下几个步骤。 抉择须要进行剖析决策的业务过程。业务过程能够是单个业务事件，比方交易的领取、退款等；也能够是某个事件的状态，比方以后的账户余额等；还能够是一系列相干业务事件组成的业务流程，具体须要看咱们剖析的是某些事件产生状况，还是以后状态，或是事件流转效率。 1）抉择粒度：在事件剖析中，咱们要预判所有剖析须要细分的水平，从而决定抉择的粒度。粒度是维度的一个组合。 2）辨认维表：抉择好粒度之后，就须要基于此粒度设计维表，包含维度属性，用于剖析时进行分组和筛选。 3）抉择事实：确定剖析须要掂量的指标。 Data Vault模型 Data Vault是Dan Linstedt发动创立的一种模型，它是ER模型的衍生，其设计的出发点也是为了实现数据的整合，但不能间接用于数据分析决策。它强调建设一个可审计的根底数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行适度的一致性解决和整合；同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式解决来优化模型，以应答源零碎变更的扩展性。Data Vault模型由以下几局部组成。 1）Hub：是企业的外围业务实体，由实体key、数据仓库序列代理键、装载工夫、数据起源组成。 2）Link：代表Hub之间的关系。这里与ER模型最大的区别是将关系作为一个独立的单元形象，能够晋升模型的扩展性。它能够间接形容1:1、1:n和n:n的关系，而不须要做任何变更。它由Hub的代理键、装载工夫、数据起源组成。 3）Satellite：是Hub的详细描述内容，一个Hub能够有多个Satellite。它由Hub的代理键、装载工夫、起源类型、具体的Hub形容信息组成。 Data Vault模型比ER模型更容易设计和产出，它的ETL加工可实现配置化。通过Dan Linstedt的比喻更能了解Data Vault的核心思想：Hub能够设想成人的骨架，那么Link就是连贯骨架的韧带，而Satellite就是骨架下面的血肉。看如下实例（来自Data Vault Modeling Guide，作者Hans Hultgren），如图所示。 ...

新冠疫情下，全民战疫。企业为了应答疫情、保护员工平安，目前在停工方面呈现出如下两种状态：状态1：有数字化触点的企业疾速开启近程办公，利用线上平台设计各种动作发展拉新、促活等用户经营工作，员工在家办公效率仿佛影响不大。 状态2：传统企业大多囿于设施、场地限度，在停工问题上仍放弃张望态度。线下门店有少许通过微信社群、员工朋友圈广告形式促活，联合物流保护老用户、发展交易。 一时间，“无接触”形式、“数字化”转型成为企业战疫的着力点。外部经营上，带火了钉钉、腾讯会议等近程办公工具；对外，能疾速帮企业晋升曝光，将用户经营数字化、智能化的直播平台、用户经营工具成为香饽饽。 01 易观方舟Argo 帮忙企业实现智能用户经营 1、想追踪流动海报的推广成果，怎么设置？ 2、最近上线了很多流动页，想看用户在哪个页面拜访多，拜访次数、pv这两个数据为什么不一样？ 3、最近优化了功能模块，想用热图看性能点击率，加载有点慢。 4、想把进入不同着陆页的用户进行分组，都有什么方法？ 因为线上用户经营动作的发展，易观方舟Argo社区里最近这些问题比拟高频。“原来只是当看板，最近全力投入线上经营，才发现这个收费工具的剖析能力、分群和经营模块能够帮我更多”，一位Argo用户这么说。 易观方舟Argo作为易观方舟的免费版，在产品能力上与商业版完全一致，集用户行为剖析、用户画像、用户经营为一体，帮忙企业通过数据驱动用户经营与产品迭代。企业里的技术团队只需按帮忙文档操作，简直便可实现一键私有化部署，咱们也提供了社区服务，帮忙Argo爱好者尽快理解产品。 帮忙企业实现智能用户经营，不止是易观方舟的职责，许多企业也早早自研或购买CRM产品来进行用户治理，但随着工具的增多，是否在一个工具上实现收集多维度用户数据、并进行智能剖析和使用，成为当下很多企业的迫切需要。 02 易观方舟Argo+CRM 达成更精准的沟通 CRM作为存储大量客户信息的工具，但在采集用户行为数据方面也存在先天不足。想找到更精准的数据，别离洽购CRM和用户行为剖析产品吗？成本上升的同时，在两套零碎查看用户数据又太过麻烦。 对于买通易观方舟与CRM，易观方舟团队的痛点来自sdr、销售该如何与用户达成精准的沟通。去年9月17日，Argo社区凋谢出将方舟与销售易买通的赏金打算，2天后社区成员实现工作，并将相干代码放在Argo的GitHub上。 CRM里有用户根底信息，如电话、姓名、公司名、职位、商务进度、需要、起源、合同金额、销售负责人，将这些字段以定时工作的形式每天传递给方舟，就会在方舟的用户属性里存在，能够帮销售辨认用户动静、划分用户分层，并进行经营触达，从而建构更精准的沟通。 ▌把握用户动静 通过把握归属于本人的线索/商机最近是否登陆了方舟、关注了什么内容，并整顿为看板实时关注，当线索活跃度下降时还能通过监控告警邮件提醒本人，对销售、sdr保护客户关系将带来微小价值。 ▌进行用户分层，精准沟通 当粗暴的经营形式不再实用，精细化经营成为每家有数字化触点企业的守则。能够将CRM中用户的交易、属性数据与易观方舟的用户行为数据相结合，作为划分人群的指标：基于用户的属性、行为、事件，在方舟设置用户分层，并进行邮件、短信等精准推送。 C端企业习用的RFM价值模型，其实也可通过方舟的分层性能来实现，如图： 03 让用户数据施展更大价值 易观方舟Argo + 更多 销售易的买通，通过社区流传引来了不少用户的问询，买通的代码也为企业自研其余CRM与方舟的联合提供了帮忙。更有用户示意，“想把方舟跟公司的CRM、OA、财务零碎以及钉钉整合到一起，正在钻研中。打算把方舟作为一个剖析平台，通过一个平台解决多种业务问题的整合计划”。 易观方舟Argo作为国内首个收费、可私有化部署的智能用户经营工具，在开源的路上一路向前，目前已在GitHub上开源了所有的SDK，并通过多个社区帮忙Argo爱好者疾速上手，期待能够成就更多人的智能用户经营能力。

摘要：如何保障企业大数据在满足各业务部门数据拜访需要的同时又能精细化保障数据拜访平安、防止数据泄露是每个企业大数据资产管理者必须关注的话题。现在，企业大数据资产在企业辅助决策、用户画像、举荐零碎等诸多业务流程中扮演着越来越重要的作用，如何保障企业大数据在满足各业务部门数据拜访需要的同时又能精细化保障数据拜访平安、防止数据泄露是每个企业大数据资产管理者必须关注的话题。 笔者联合在华为云数据湖摸索服务中的技术积淀与丰盛的企业数据安全治理教训，从以下几点来探讨如何精细化保障企业大数据安全。 1、企业大数据的平安挑战 2、数据资产权限治理的通用做法 3、以华为云DLI为例，对数据资产治理的实际&案例剖析 4、将来瞻望 数据隔离、分层拜访、受权，难题多多企业大数据的与日俱增，天然面临着大数据安全的挑战：数据起源宽泛，来源于不同的业务单元，又要服务于各种业务单元，还须要对不同层级的员工设置不一样的权限。如何防备企业数据不被未经受权的用户拜访，治理数据在不同业务单元的共享，隔离企业敏感数据……企业可能面临着以下的挑战： 1.1 数据隔离不同的我的项目业务数据须要隔离，如游戏经营数据，企业在设计大数据分析平台时可能冀望A游戏产生的业务数据用来撑持A游戏经营剖析，B游戏产生的业务数据是撑持B游戏经营剖析，那么须要对业务数据按我的项目进行隔离，A游戏经营部门员工只可拜访A游戏经营数据，B游戏经营部门员工只可拜访B游戏经营数据 1.2 数据分层拜访不同层级业务部门对数据具备不同的拜访权限，高层级部门能够拜访底层级部门的数据，而低层级部门不可拜访高层级部门的数据。如省级部门能够拜访地市级数据，而地市级部门只可拜访本地市数据，不可拜访跨区数据，也不可拜访省级部门数据。这就要求对数据的权限治理须要具备分层治理能力，可能分层级授予不同的权限。 1.3 列级数据受权不同业务部门对同一份数据的拜访权限要求不同，所以要求可能对数据进行精细化受权。如银行零碎中，用户表中的身份证号信息是敏感信息，柜台零碎能够查问用户的身份证号，但举荐零碎就不须要身份证信息，只须要用户ID就能够了。这种场景下须要对用户表可能分列受权，对不同的业务单元不同的权限。 1.4 批量受权随着企业规模的增大，企业员工可能十分宏大，分部门受权，批量受权也是很常见的业务场景。例如销售部门上面员工很多，如果单个单个的给销售人员受权，会十分麻烦，人员流动时勾销受权也很简单，这时就须要可能批量受权或者根本角色的受权模型，来实现一次受权，部门内员工均可应用的目标。 四种权限模型，孰优孰劣？目前比拟风行的大数据分析平台的有Hadoop，Hive，Spark等，它们应用的权限模型有POSIX模型、ACL模型、SQL Standard模型和RBAC模型。其中Hadoop大数据平台应用了POSIX和ACL权限模型来治理数据，HIVE和Spark应用了ACL和RBAC权限模型来治理数据。 POSIX权限模型是基于文件的权限模型，与Linux零碎的文件系统权限相似。即一个文件有相应的OWNER和GROUP，只能反对设置OWNER,、GROUP和其余用户的权限，可受权限也只有读写执行权限。 这种模型不适用于企业用户，有一个显著的毛病就是它只有一个GROUP，不能实现不同的GROUP有不同的权限，也无奈实现精细化的权限治理，只能在文件级受权，所受权限也只有读写与执行权限。 ACL即Access Control List，ACL权限模型能够补救POSIX权限模型的有余，能够实现比拟精细化的权限治理。通过设置访问控制列表，咱们能够授予某一个用户多个权限，也能够授予不同用户不同的权限。但ACL也有显著的毛病，当用户数较大时，ACL列表会变得宏大而难以保护，这在大企业中问题尤其显著。 RBAC（Role-Based Access Control）模型也是业界罕用的一种权限模型。是基于用户角色的权限治理模型，其首先将一个或多个权限受权某一个角色，再把角色与用户绑定，也实现了对用户的受权。一个用户能够绑定一个或多个角色，用户具备的权限为所绑定角色权限的并集。RBAC能够实现批量受权，能够灵便保护用户的权限，是以后比拟风行的权限治理模型。 SQL Standard模型是Hive/Spark应用权限模型之一，实质是应用SQL形式的受权语法来管理权限。Hive中的权限模型也是基于ACL和RBAC模型，即能够给独自的用户间接受权，也可能通过角色进行受权。 数据湖摸索怎么做数据资产治理？华为云DLI联合了ACL和RBAC两种权限模型来治理用户权限。DLI中波及到的概念有： DLI用户：DLI用户为IAM账号及其下的子用户，上面拜访权限阐明的用户均指IAM账号及其下的子用户。 DLI资源：DLI的资源分为数据库(Database)、表（table）、视图（View）、作业（Job）和队列(Queue)。资源是按我的项目隔离的，不同我的项目的资源不可相互拜访。表和视图是数据库(Database)下的子资源。 DLI权限：DLI权限为执行DLI相干操作所须要的权限。DLI中的权限比拟细，每项操作对应的权限都不一样，如创立表对应CREATE_TABLE权限，删除表对应DROP_TABLE权限, 查问对应SELECT权限等等。 DLI应用对立身份认证（IAM）的策略和DLI的访问控制列表（ACL）来治理资源的拜访权限。其中对立身份认证（IAM）的策略管制我的项目级资源的隔离，和定义用户为我的项目的管理员还是普通用户。访问控制列表（ACL）管制队列，数据库，表，视图，列的拜访权限和受权治理。 DLI应用对立身份认证来实现用户认证和用户角色治理。DLI在IAM中预约义了几个角色：Tenant Administrator（租户管理员），DLI Service Admin（DLI管理员），DLI Service User（DLI普通用户）。其中具备租户管理员或DLI管理员角色的用户在DLI内是管理员，能够操作该项目标所有资源，包含创立数据库，创立队列，操作我的项目下的数据库，表，视图，队列，作业。普通用户不可创立数据库，不可创立队列，依赖管理员的受权，能够执行创立表，查问表等操作。 DLI应用ACL和RBAC两种模型来治理用户权限。管理员或资源的所有者能够授予另外一个用户单个或多个权限，也可能创立角色，授予权限给创立好的角色，而后绑定角色和用户。 DLI提供了API和SQL语句两种形式来实现以上权限治理，不便用户灵便受权。具体应用形式能够参考DLI的权限治理。 案例剖析拿银行的大数据实际来剖析下如何利用DLI来治理数据的权限。家喻户晓，银行积攒了大量的用户数据，包含用户信息，交易信息，账户信息等等数以亿计的数据。而银行业务也是十分的简单，波及到柜员零碎，监管部门，经营部门，营销部门等等各个业务线，各业务线对数据的要求不同，拜访的权限不同。咱们拿反洗钱业务与画像业务来简略介绍下如何利用DLI平台实现大数剖析和数据资产权限治理。 典型的反洗钱业务个别是大额预警和黑名单机制，须要从海量的交易数据中筛选出大额交易或者是黑名单人员交易数据，将这些数据反馈给监管人员进行进一步剖析，波及到的数据是交易数据，账户信息和黑名单信息。 画像个别会剖析用户的交易类型与交易数据，推断出用户的兴趣爱好，给用户画像，标记用户的趣味点在哪些地方。波及交易信息中的交易类型和账号信息。 这两项业务中在DLI中，由数据管理员生成生成用户信息表，交易数据表，账户信息表，黑名单信息表，并导入相应的数据。 在检查钱业务，授予反洗钱业务部门或人员账户信息表的查问权限，交易数据表的查问权限，黑名单信息的查问权限，通过对账户信息表和交易数据表和黑名单表的联结查问，能够查找出异样交易信息及相干交易人员，反馈给反洗钱监管人员。 在画像业务中，由数据管理员授予画像业务部门或人员用户信息表的查问权限，交易数据表中交易金额和交易类型，交易商户等列的查问权限，账户信息表中的账户ID和用户ID列的查问权限，通过这几张表的联结与聚合查问，找出用户罕用交易信息，蕴含交易类型，金额，及相干地点等信息，描绘出用户画像信息。 将来瞻望传统企业数据资产面临着几个难题。各业务部门均会产生数据，数据规范不统一，保护简单。各业务部门数据存在在不同的零碎中，数据容易造成孤岛，无奈无效开掘利用。部门间数据共享简单，容易造成网状受权网络，保护老本微小。 数据湖DLI计划能够解决这样的难题，应用对立的数据管理平台、数据存储、数据规范，进行对立的数据资产治理、受权治理。 华为云828企业上云节期间，数据湖摸索DLI也在流动产品之列，有数据分析需要的企业连忙趁着促销动手试试。 点击关注，第一工夫理解华为云陈腐技术~

简介： Hive是大数据畛域罕用的组件之一，次要用于大数据离线数仓的运算，对于Hive的性能调优在日常工作和面试中是常常波及的一个点，因而把握一些Hive调优是必不可少的一项技能。影响Hive效率的次要因素有数据歪斜、数据冗余、job的IO以及不同底层引擎配置状况和Hive自身参数和HiveSQL的执行等。本文次要从建表配置参数方面对Hive优化进行解说。 创立一个一般的表 create table test\_user1(id int, name string,code string,code\_id string ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ','；                                          查看表信息 DESCRIBE FORMATTED test\_user1; 咱们从该表的形容信息介绍建表时的一些可优化点。 2.1表的文件数 numFiles示意表中含有的文件数，当文件数过多时可能意味着该表的小文件过多，这时候咱们能够针对小文件的问题进行一些优化，HDFS自身提供了 解决方案： 1.Hadoop Archive/HAR：将小文件打包成大文件。 2.SEQUENCEFILE格局：将大量小文件压缩成一个SEQUENCEFILE文件。 3.CombineFileInputFormat：在map和reduce解决之前组合小文件。 4.HDFS Federation：HDFS联盟，应用多个namenode节点管理文件。 除此之外，咱们还能够通过设置hive的参数来合并小文件。  1.输出阶段合并 须要更改Hive的输出文件格式即参hive.input.format 默认值是org.apache.hadoop.hive.ql.io.HiveInputFormat咱们改成org.apache.hadoop.hive.ql.io.CombineHiveInputFormat。 这样比起上面对mapper数的调整，会多出两个参数，别离是mapred.min.split.size.per.node和mapred.min.split.size.per.rack，含意是单节点和单机架上的最小split大小。如果发现有split大小小于这两个值（默认都是100MB），则会进行合并。具体逻辑能够参看Hive源码中的对应类。 2.输入阶段合并 间接将hive.merge.mapfiles和hive.merge.mapredfiles都设为true即可，前者示意将map-only工作的输入合并，后者示意将map-reduce工作的输入合并，Hive会额定启动一个mr作业将输入的小文件合并成大文件。 另外，hive.merge.size.per.task能够指定每个task输入后合并文件大小的期望值，hive.merge.size.smallfiles.avgsize能够指定所有输入文件大小的均值阈值，默认值都是1GB。如果均匀大小有余的话，就会另外启动一个工作来进行合并。 2.2表的存储格局 通过InputFormat和OutputFormat能够看出表的存储格局是TEXT类型，Hive反对TEXTFILE, SEQUENCEFILE, AVRO, RCFILE, ORC,以及PARQUET文件格式，能够通过两种形式指定表的文件格式： ...

受到新冠疫情影响，寰球经济面临冲击，国内经济已进入停工复产有序倒退的新常态阶段，企业想要实现持续增长需另寻突破点，越来越多的企业把眼帘转向了企业外部，心愿通过推动精细化治理来实现降本增效。 在企业精细化治理过程中，财务管理作为外围组成部分，是企业实现全面价值治理和风险管理的重要前提。因而，越来越多的企业开始引入新的治理模式和数字化零碎，通过搭建业财一体化平台，将团体总部、各事业部、各业务条线的业务和财务数据进行对立的解决和加工，造成团体级数据资产，深入数据服务能力，推动团体数字化转型。 大型团体的业财一体化大数据平台，对平台的性能、扩展性要求高，还要思考到技术的疾速迭代和数据量的指数级增长。 华为云EI 智能数据湖FusionInsight为企业提供离线剖析、交互查问、实时检索、实时流解决、交融剖析、数据仓库等数据全生命周期组件。 叠加在FusionInsight之上的Kyligence，为下层利用提供易用的数据模型服务，帮忙分析师和数据工程师轻松从本地到云架构上构建数据服务。 以后，FusionInsight联结Kyligence已在多个大型金融机构进行深度单干，并在诸多场景取得冲破，业财一体化就是其中的明星场景。 保险业要“正本清源”，传统数据仓库已落后在某产险公司保费增速和综合老本率双优指标背景下，须要以治理会计的全新视角归集财务老本，保障一线销售资源正本清源，帮助产险各分公司“看清楚、想明确、做到位”，解决分公司资源“往哪投、投得了、敢于投”的问题。 传统的数据仓库设施和平台因为自身技术架构的局限性，无奈解决快速增长的数据，无奈解决不同业务条线的数据孤岛问题，无奈满足对海量数据中各类维度和指标进行灵便高效剖析的需要，存在剖析维度和剖析指标偏少，剖析时效滞后，剖析预见性差以及回溯剖析艰难的痛点，无奈实现业财交融。 因而，全面实现业财交融，迭代资源配置形式及工具利用成为增强业务筛选、进步老本与效益均衡能力、晋升公司外围竞争力的外在需要。 国产大数据平台，多快好省业财一体化剖析平台在数据层抽取了该财险公司3.7亿个保单数据，构建了多层级多维度的业务分析模型。技术层面通过在FusionInsight智能数据湖上部署Kyligence，联合预计算技术，高效利用Hadoop分布式计算引擎Spark，批量预计算任意维度组合的分类、汇总统计数据。同时，向应用层提供反对规范SQL接口的JDBC和ODBC驱动，无缝集成企业已有的BI前端工具，实现对BI前端查问申请的疾速响应。 在本案例中部署的FusionInsight和Kyligence等产品均是国产商业软件，领有良好的本地反对团队，总体上老本较低、部署较快、扩展性较好，为企业构建了一个国产大数据平台利用。 通过此我的项目，该险企整合来自车险、非车险、渠道、费用、精算、再保等业务财务数据，搭建了一个高性能、高并发、可扩大的业财一体化大数据平台。 通过保单级老本多维构建组合分析，可反对40个维度300个指标形成的固定报表和灵便剖析报表。通过维度及老本指标细分，分公司可清晰直观的分析业务构造，筛选优质业务，联合具体业务指标及市场倒退理论状况，有针对性的制订资源投放策略应答市场。通过引入精算预期赔付率与细分销售跟单费用十个段，引入老本区间剖析、费赔相关系数等指标，让业务、财务均能及时分明地理解相干层级和维度的业务老本构造，明细赔付与费用投放的匹配关系，帮忙各层级机构强化对资源配置的治理。通过销管费控系统买通从销售费用估算管控到理论报销的流程，实现保单级费用险种、渠道等属性主动带入，生成最精准的分险种分渠道报表，破解过来手工指认老本属性的不精确、工作量大且业务认可度低的难题。通过保单级承保年月分类汇总“切片”，实现期间经营剖析，解决经营责任无奈回溯剖析清晰认定的难题。最初Kyligence基于FusionInsight搭建的业财一体化剖析平台，大幅晋升用户剖析效率，多维统计分析报表查问响应时效从“半小时”级晋升到“秒”级。平台已实现40个维度、300个指标的剖析规模，估算端定制报表已实现车险、非车险、农险等定制报表40余张，灵便报表数类。 目前该零碎已凋谢给1000多个总分公司机构、4000多名剖析用户应用，其中车险外围用户1000多人，无效解决分公司资源“往哪投、投得了、敢于投”的问题，全面实现业财交融。 828企业上云节，不如来革新降级你们的大数据平台，这里有一对一的专家服务和高价的数据库产品。 点击关注，第一工夫理解华为云陈腐技术~

Google File System但但凡要开始讲大数据的，都绕不开最后的Google三驾马车：Google File System（GFS）， MapReduce，BigTable。 为这所有的根底的Google File System，岂但没有任何垮台的迹象，还在一直的演变，事实上撑持着Google这个宏大的互联网公司的所有计算。 以下是原文内容，内容较长，倡议具体浏览。 摘要 咱们设计并实现了 Google GFS 文件系统，一个面向大规模数据密集型利用的、可伸缩的分布式文件系统。GFS 尽管运行在便宜的广泛硬件设施上，然而它仍然了提供劫难冗余的能力，为大量客户机提供了高性能的服务。 尽管 GFS 的设计指标与许多传统的分布式文件系统有很多相同之处，然而，咱们的设计还是以咱们对本人的利用的负载状况和技术环境的剖析为根底的，不论当初还是未来，GFS 和晚期的分布式文件系统的构想都有显著的不同。所以咱们从新扫视了传统文件系统在设计上的折衷抉择，衍生出了齐全不同的设计思路。 GFS 齐全满足了咱们对存储的需要。GFS 作为存储平台曾经被宽泛的部署在 Google 外部，存储咱们的服务产生和解决的数据，同时还用于那些须要大规模数据集的钻研和开发工作。目前为止，最大的一个集群利用数千台机器的数千个硬盘，提供了数百 TB 的存储空间，同时为数百个客户机服务。 在本论文中，咱们展现了可能反对分布式应用的文件系统接口的扩大，探讨咱们设计的许多方面，最初列出了小规模性能测试以及实在生产零碎中性能相干数据。 1 简介 为了满足 Google 迅速增长的数据处理需要，咱们设计并实现了 Google 文件系统(Google File System – GFS)。GFS 与传统的分布式文件系统有着很多雷同的设计指标，比方，性能、可伸缩性、可靠性以及可用性。 然而，咱们的设计还基于咱们对咱们本人的利用的负载状况和技术环境的察看的影响，不论当初还是未来，GFS 和晚期文件系统的假如都有显著的不同。所以咱们从新扫视了传统文件系统在设计上的折衷抉择，衍生出了齐全不同的设计思路。 首先，组件生效被认为是常态事件，而不是意外事件。GFS 包含几百甚至几千台一般的便宜设施组装的存储机器，同时被相当数量的客户机拜访。GFS 组件的数量和品质导致在事实上，任何给定工夫内都有可能产生某些组件无奈工作，某些组件无奈从它们目前的生效状态中复原。咱们遇到过各种各样的问题，比方应用程序 bug、操作系统的 bug、人为失误，甚至还有硬盘、内存、连接器、网络以及电源生效等造成的问题。所以，继续的监控、谬误侦测、劫难冗余以及主动复原的机制必须集成在 GFS 中。其次，以通常的规范掂量，咱们的文件十分微小。数 GB 的文件十分广泛。每个文件通常都蕴含许多应用程序对象，比方 web 文档。当咱们常常须要解决快速增长的、并且由数亿个对象形成的、数以 TB 的数据集时，采纳治理数亿个 KB 大小的小文件的形式是十分不明智的，只管有些文件系统反对这样的治理形式。因而，设计的假如条件和参数，比方 I/O 操作和 Block 的尺寸都须要重新考虑。第三，绝大部分文件的批改是采纳在文件尾部追加数据，而不是笼罩原有数据的形式。对文件的随机写入操作在理论中简直不存在。一旦写完之后，对文件的操作就只有读，而且通常是按程序读。大量的数据合乎这些个性，比方：数据分析程序扫描的超大的数据集；正在运行的应用程序生成的间断的数据流；存档的数据；由一台机器生成、另外一台机器解决的两头数据，这些两头数据的解决可能是同时进行的、也可能是后续才解决的。对于这种针对海量文件的拜访模式，客户端对数据块缓存是没有意义的，数据的追加操作是性能优化和原子性保障的次要考量因素。第四，应用程序和文件系统 API 的协同设计进步了整个零碎的灵活性。比方，咱们放松了对 GFS 一致性模型的要求，这样就加重了文件系统对应用程序的刻薄要求，大大简化了 GFS 的设计。咱们引入了原子性的记录追加操作，从而保障多个客户端可能同时进行追加操作，不须要额定的同步操作来保证数据的一致性。本文前面还有对这些问题的细节的具体探讨。Google 曾经针对不同的利用部署了多套 GFS 集群。最大的一个集群领有超过 1000 个存储节点，超过300TB 的硬盘空间，被不同机器上的数百个客户端连续不断的频繁拜访。2 设计概述2.1 设计预期 在设计满足咱们需要的文件系统时候，咱们的设计指标既有机会、又有挑战。之前咱们曾经提到了一些须要关注的关键点，这里咱们将设计的预期指标的细节展开讨论。 零碎由许多便宜的一般组件组成，组件生效是一种常态。零碎必须继续监控本身的状态，它必须将组件生效作为一种常态，可能迅速地侦测、冗余并复原生效的组件。零碎存储肯定数量的大文件。咱们预期会有几百万文件，文件的大小通常在 100MB 或者以上。数个 GB大小的文件也是普遍存在，并且要可能被无效的治理。零碎也必须反对小文件，然而不须要针对小文件做专门的优化。 ...

简介： 绝对于离线批处理技术，流式实时处理技术作为一个十分重要的技术补充，在阿里巴巴团体内被宽泛应用。 前言： -更多对于数智化转型、数据中台内容请退出阿里云数据中台交换群—数智俱乐部 和关注官网微信公总号（文末扫描二维码或点此退出） -阿里云数据中台官网 https://dp.alibaba.com/index起源：数智化转型俱乐部 数据价值是具备时效性的，在一条数据产生的时候，如果不能及时处理并在业务零碎中应用，就不能让数据放弃最高的“新鲜度”和价值最大化。 绝对于离线批处理技术，流式实时处理技术作为一个十分重要的技术补充，在阿里巴巴团体内被宽泛应用。 在大数据业界中，流计算技术的钻研是近年来十分热门的课题。 业务诉求是心愿能在第一工夫拿到通过加工后的数据，以便实时监控以后业务状态并做出经营决策，疏导业务往好的方向倒退。比方网站上一个访问量很高的广告位，须要实时监控广告位的引流成果，如果转化率非常低的话，经营人员就须要及时更换为其余广告，以防止流量资源的节约。在这个例子中，就须要实时统计广告位的曝光和点击等指标作为经营决策的参考。 依照数据的提早状况，数据时效性个别分为三种（离线、准实时、实时）： 离线：在明天（T）解决N天前（T-N，N≥1）的数据，延迟时间粒度为天。准实时：在以后小时（H）解决N小时前（H-N，N>0，如0.5小时、1小时等）的数据，延迟时间粒度为小时。实时：在以后时刻解决以后的数据，延迟时间粒度为秒；离线和准实时都能够在批处理零碎中实现（比方Hadoop、MaxCompute、Spark等零碎），只是调度周期不一样而已，而实时数据则须要在流式解决零碎中实现。简略来说，流式数据处理技术是指业务零碎每产生一条数据，就会立即被采集并实时发送到流式工作中进行解决，不须要定时调度工作来解决数据。 整体来看，流式数据处理个别具备以下特色。 1．时效性高 数据实时采集、实时处理，延时粒度在秒级甚至毫秒级，业务方可能在第一工夫拿到通过加工解决后的数据。 2．常驻工作 区别于离线工作的周期调度，流式工作属于常驻过程工作，一旦启动后就会始终运行，直到人为地终止，因而计算成本会绝对比拟高。这一特点也预示着流式工作的数据源是无界的，而离线工作的数据源是有界的。这也是实时处理和离线解决最次要的差异，这个个性会导致实时工作在数据处理上有肯定的局限性。 3．性能要求高 实时计算对数据处理的性能要求十分严格，如果解决吞吐量跟不上采集吞吐量，计算出来的数据就失去了实时的个性。比方实时工作1分钟只能解决30秒采集的数据，那么产出的数据的延时会越来越长，不能代表以后时刻的业务状态，有可能导致业务方做出谬误的经营决策。在互联网行业中，须要解决的数据是海量的，如何在数据量疾速收缩的状况下也能放弃高吞吐量和低延时，是以后面临的重要挑战。因而，实时处理的性能优化占了工作开发的很大一部分工作。 4．利用局限性 实时数据处理不能代替离线解决，除了计算成本较大这个因素外，对于业务逻辑简单的场景（比方双流关联或者须要数据回滚的状况），其局限性导致反对有余。另外，因为数据源是流式的，在数据具备上下文关系的状况下，数据达到工夫的不确定性导致实时处理跟离线解决得进去的后果会有肯定的差别。 流式技术架构在流式计算技术中，须要各个子系统之间相互依赖造成一条数据处理链路，能力产出后果最终对外提供实时数据服务。在理论技术选型时，可选的开源技术计划十分多，然而各个计划的整体架构是相似的，只是各个子系统的实现原理不太一样。另外，流式技术架构中的零碎跟离线解决是有穿插的，两套技术计划并不是齐全独立的，并且在业界中有合并的趋势。 各个子系统按性能划分的话，次要分为以下几局部： 1．数据采集 数据的源头，个别来自于各个业务的日志服务器（例如网站的浏览行为日志、订单的批改日志等），这些数据被实时采集到数据中间件中，供上游实时订阅应用。 2．数据处理 数据被采集到中间件中后，须要上游实时订阅数据，并拉取到流式计算零碎的工作中进行加工解决。这里须要提供流计算引擎以反对流式工作的执行。 **3．数据存储 ** 数据被实时加工解决（比方聚合、荡涤等）后，会写到某个在线服务的存储系统中，供上游调用方应用。这里的写操作是增量操作，并且是源源不断的。 4．数据服务 在存储系统上会架设一层对立的数据服务层（比方提供HSF接口、HTTP服务等），用于获取实时计算结果。 整体技术架构如图所示： 从图能够看出，在数据采集和数据服务局部实时和离线是专用的，因为在这两层中都不须要关怀数据的时效性。这样能力做到数据源的对立，防止流式解决和离线解决的不统一。 流式数据模型在流式计算技术中，须要各个子系统之间相互依赖造成一条数据处理链路，能力产出后果最终对外提供实时数据服务。在理论技术选型时，可选的开源技术计划十分多，然而各个计划的整体架构是相似的，只是各个子系统的实现原理不太一样。另外，流式技术架构中的零碎跟离线解决是有穿插的，两套技术计划并不是齐全独立的，并且在业界中有合并的趋势。 各个子系统按性能划分的话，次要分为以下几局部： 数据模型设计是贯通数据处理过程的，流式数据处理也一样，须要对数据流建模分层。实时建模跟离线建模十分相似，数据模型整体上分为五层（ODS、DWD、DWS、ADS、DIM）。 因为实时计算的局限性，每一层中并没有像离线做得那么宽，维度和指标也没有那么多，特地是波及回溯状态的指标，在实时数据模型中简直没有。 整体来看，实时数据模型是离线数据模型的一个子集，在实时数据处理过程中，很多模型设计就是参考离线数据模型实现的。 1．数据分层 在流式数据模型中，数据模型整体上分为五层。 ODS层：跟离线零碎的定义一样，ODS层属于操作数据层，是间接从业务零碎采集过去的最原始数据，蕴含了所有业务的变更过程，数据粒度也是最细的。在这一层，实时和离线在源头上是对立的，这样的益处是用同一份数据加工进去的指标，口径根本是对立的，能够更不便进行实时和离线间数据比对。例如：原始的订单变更记录数据、服务器引擎的拜访日志。 DWD层：DWD层是在ODS层根底上，依据业务过程建模进去的实时事实明细层，对于拜访日志这种数据（没有上下文关系，并且不须要期待过程的记录），会回流到离线零碎供上游应用，最大水平地保障实时和离线数据在ODS层和DWD层是统一的。例如：订单的领取明细表、退款明细表、用户的拜访日志明细表。 DWS层：订阅明细层的数据后，会在实时工作中计算各个维度的汇总指标。如果维度是各个垂直业务线通用的，则会放在实时通用汇总层，作为通用的数据模型应用。比方电商网站的卖家粒度，只有波及交易过程，就会跟这个维度相干，所以卖家维度是各个垂直业务的通用维度，其中的汇总指标也是各个业务线共用的。例如：电商数据的几大维度的汇总表（卖家、商品、买家）。 ADS层：个性化维度汇总层，对于不是特地通用的统计维度数据会放在这一层中，这里计算只有本身业务才会关注的维度和指标，跟其余业务线个别没有交加，罕用于一些垂直翻新业务中。例如：手机淘宝上面的某个爱逛街、微淘等垂直业务。 DIM层：实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线零碎中供实时利用调用。这一层对实时利用来说是动态的，所有的ETL解决工作会在离线零碎中实现。维表在实时利用的应用中跟离线稍有区别，前面章节中会具体阐明。例如：商品维表、卖家维表、买家维表、类目维表。 2．多流关联 在流式计算中经常须要把两个实时流进行主键关联，以失去对应的实时明细表。在离线零碎中两个表关联是非常简单的，因为离线计算在工作启动时曾经能够取得两张表的全量数据，只有依据关联键进行分桶关联就能够了。但流式计算不一样，数据的达到是一个增量的过程，并且数据达到的工夫是不确定的和无序的，因而在数据处理过程中会波及中间状态的保留和复原机制等细节问题。 比方A表和B表应用ID进行实时关联，因为无奈晓得两个表的达到程序，因而在两个数据流的每条新数据到来时，都须要到另外一张表中进行查找。如A表的某条数据达到，到B表的全量数据中查找，如果能查找到，阐明能够关联上，拼接成一条记录间接输入到上游；然而如果关联不上，则须要放在内存或内部存储中期待，直到B表的记录也达到。多流关联的一个关键点就是须要互相期待，只有单方都达到了，能力关联胜利。 上面通过例子（订单信息表和领取信息表关联）来阐明，如图示。 在下面的例子中，实时采集两张表的数据，每到来一条新数据时都在内存中的对方表截至以后的全量数据中查找，如果能查找到，则阐明关联胜利，间接输入；如果没查找到，则把数据放在内存中的本人表数据汇合中期待。另外，不论是否关联胜利，内存中的数据都须要备份到内部存储系统中，在工作重启时，能够从内部存储系统中复原内存数据，这样能力保证数据不失落。因为在重启时，工作是续跑的，不会从新跑之前的数据。 另外，订单记录的变更有可能产生屡次（比方订单的多个字段屡次更新），在这种状况下，须要依据订单ID去重，防止A表和B表屡次关联胜利；否则输入到上游就会有多条记录，这样失去的数据是有反复的。 以上是整体的双流关联流程，在理论解决时，思考到查找数据的性能，实时关联这个步骤个别会把数据依照关联主键进行分桶解决，并且在故障复原时也依据分桶来进行，以升高查找数据量和进步吞吐量。 3．维表应用 在离线零碎中，个别是依据业务分区来关联事实表和维表的，因为在关联之前维表的数据就曾经就绪了。而在实时计算中，关联维表个别会应用以后的实时数据（T）去关联T-2的维表数据，相当于在T的数据达到之前须要把维表数据筹备好，并且个别是一份动态的数据。 为什么在实时计算中这么做呢？次要基于以下几点的思考。 数据无奈及时筹备好：当达到零点时，实时流数据必须去关联维表（因为不能期待，如果等就失去了实时的个性），而这个时候T-1的维表数据个别不能在零点马上准备就绪（因为T-1的数据须要在T这一天加工生成），因而去关联T-2维表，相当于在T-1的一天工夫里加工好T-2的维表数据。 无奈精确获取全量的最新数据：维表个别是全量的数据，如果须要实时获取到当天的最新维表数据，则须要T-1的数据+当天变更能力获取到残缺的维表数据。也就是说，维表也作为一个实时流输出，这就须要应用多流实时关联来实现。然而因为实时数据是无序的并且达到工夫不确定，因而在维表关联上有歧义。 数据的无序性：如果维表作为实时流输出的话，获取维表数据将存在艰难。比方10:00点的业务数据胜利关联维表，失去了相干的维表字段信息，这个时候是否就曾经拿到最新的维表数据了呢？其实这只代表拿到截至10:00点的最新状态数据（实时利用永远也不晓得什么时候才是最新状态，因为不晓得维表前面是否会产生变更）。 因而在实时计算中维表关联个别都对立应用T-2的数据，这样对于业务来说，起码关联到的维表数据是确定的（尽管维表数据有肯定的延时，然而许多业务的维表在两天之间变动是很少的）。 在有些业务场景下，能够关联T-1的数据，但T-1的数据是不全的。比方在T-1的早晨22:00点开始对维表进行加工解决，在零点达到之前，有两个小时能够把数据筹备好，这样就能够在T的时候关联T-1的数据了，然而会缺失两个小时的维表变更过程。 另外，因为实时工作是常驻过程的，因而维表的应用分为两种模式。 全量加载：在维表数据较少的状况下，能够一次性加载到内存中，在内存中间接和实时流数据进行关联，效率十分高。但毛病是内存始终占用着，并且须要定时更新。例如：类目维表，每天只有几万条记录，在每天零点时全量加载到内存中。 ...

10月26日-27日，2018易观A10大数据利用峰会在北京如期召开，本次峰会以“数造将来 精益成长”为主题。来自国内外的大数据实践者、资本掌舵人、企业家、技术大咖、经营专家、利用开发者以及出名媒体人齐聚一堂，独特探讨和分享在数据驱动下的企业精益成长之道。 在10月27日上午举办的易观A10峰会数造将来主论坛上，易观CTO郭炜做了题为《流动水系数造将来》的主题演讲，郭炜在演讲中以本身丰盛的技术从业教训，为咱们分享大数据下的数据难题以及应答办法。以下为其演讲实录： 对于大数据，企业常常会遇到这样的问题：大数据大而不强、人工智能人工而不智能。为什么这么讲？过来咱们在做大数据时，常常把企业认为有价值的数据都存在一起，但当咱们应用的时候，会发现随着数据的沉积，越来越难以使用这些数据，为什么呢？因为随着工夫的流逝，数据的定义、数据的格局、业务的含意曾经逐步都发生变化，越来越不清晰。随着工夫的变动，咱们的数据湖（Data Lake）最终变成了一片数据沼泽。 我置信很多企业都会遇到这样的问题，于是有些企业开始做大数据治理。但真正数据治理十分艰难，这是为什么呢？因为长时间积攒下来的数据，每次规整和删除都十分苦楚，不晓得哪个业务部门在应用它，不晓得它真正的含意，或者未来是不是能够用到它。 每一次CTO和CIO都会遇到这个问题，大数据的价值到底在哪？感觉本人的大数据团队人员永远有余；感觉大数据存储永远不够；数据永远难以满足业务剖析维度，还有不对立的数据规范融入等等一系列问题。 当然易观也遇到这样的问题，易观SDK月活靠近5.9个亿，约6.8PB的数据存储，目前咱们曾经存储到了90%。当我找老板要服务器，跟老板汇报说：“咱们6.8PB数据曾经存满，当初只能存储不到一年数据，咱们须要更多的存储”，老板问，“这些数据在哪里应用，有什么用？”而我还持续说，“下一步物联网数据要来了，IOT数据的量级是咱们当初挪动互联网量级的10倍，还要多10倍的存储”。老板睁大眼睛问我说，“郭炜啊，你感觉咱们这些数据的价值在哪里？” 这是咱们每一个CTO或者大数据总监去跟老板要资源的时候都会遇到的问题，那么咱们该怎么解决这个问题？ 答案就是咱们要给企业做一个数据驱动的中台。很多企业都晓得数据中台的概念，认为数据中台就是把各种数据组件打包、把大数据存储好即可。然而这样做随着工夫积攒，数据中台就会从数据湖变成数据沼泽。怎么办呢？咱们的实践是提出一个数据河的概念。中国有句俗话叫“流水不腐，户枢不蠹”，就是数据肯定像河水一样流动起来，才不会产生瘀泥。 那数据河的概念是什么？数据河就是从数据产生端间接通过IOTA数据河实时流向数据使用者。这样有个益处，每一个数据的产生者都会有一个使用者，而不是大家设想中说这个数据很有用，但数据谁用了我不晓得，只是单纯把它存储下来。 这样做，会带来什么益处呢？数据的每一次产生和应用都是确定的，是否要存留是依据咱们数据使用者的状况去做的。大家都在探讨数据治理，这其实是一件十分苦楚的事。在10年前，我在IBM给一个数据银行做数据治理，那个我的项目过后消耗了两年多工夫，数据治理是件很简单的事。但当咱们变成数据河当前，咱们能够通过飞轮驱动效应来实现大数据治理。 什么叫飞轮驱动效应？这个名词来自于亚马逊，意味着一个货色在转起来的时候是本人驱动本人在减速运行。数据的使用者特地关注最初数据产生时的样子，所以当你的河水产生净化，外面数据品质不好的时候，不必放心最初变成瘀泥的时候再治理会很难。你的数据使用者会第一工夫通知你：对不起，咱们的数据有问题。 当把数据河放到整个企业的时候就会造成数据水生态。并不是说一个企业本人一条河流或者一个水系就能把所有的河都治理好。大数据是凋谢的，是要流动的。所以咱们在内部会有第三方合作伙伴，他们会把一些数据实时灌注到企业里，帮忙把企业里的数据水系裁减得更好。 再说说什么是IOTA架构？大数据IOTA架构是易观今年年初提出的。咱们所提倡的大数据不是存下来，而是实时流动起来的。它分为几局部，边缘计算的SDK，对立数据模型，云端存储于计算引擎。 IOTA架构能够演绎以下4个特点：去ETL架构；边缘SDK计算；非结构化实时转化结构化数据存储；反对IOT设施。 大家过来在做大数据计算的时候，都要把它放到云端，放到一个平台外面去算，但随着咱们手机端越来越弱小，大家发现其实当初的手机可能就像5年前的电脑一样弱小。为什么咱们还要把所有的数据放到云端去算？IOTA架构给了大家一个答案，咱们的数据其实在数据产生的时候就边缘SDK计算了，在云端时只负责存储和查问。 而对立数据模型，就是IOTA架构下从头至尾从云端、计算端到最初应用端都是一套数据模型。 我举一个大家在做用户行为剖析时会应用的模型，叫做主谓宾模型：就是谁、什么工夫、在哪、干了什么。比方，过来看挪动端用户行为数据的时候，很简略，某一个用户的ID在这个页面点击了这个按纽；而IOT时代，智能wifi去采集的时候也是一样这个模型——能够看到用户的MAC地址什么工夫呈现在哪一个楼层；对于人脸摄像头来讲也是如此，人脸的特色什么工夫进入某一个汽车站。同样你会发现，在过来做各种各样数据采集的时候，每一次都要在云端做ETL简单的事件，而IOTA架构把数据扩散在数据产生端，就能够去解决在云端解决时的各种简单状况。 当然IOTA架构也有它的毛病，就像咱们后面提到，一个IOTA架构的数据河只能解决一个主题域的数据，比如说用户行为的对立数据模型，对于另一个主题域咱们会有另外一条IOTA的数据河让它去解决，例如产品生产和库存。 IOTA架构的益处就是在数据的产生端，间接实时传送给最初的用户行为剖析人员去应用，而不是把它寂静下来再看怎么去做，这样间接进步了咱们整个大数据的应用效率，实现了数据驱动的业务闭环。 易观本人基于IOTA架构开发了一个实例，叫做易观秒算，由底层边缘的SDK到相干的数据接入子模块，到查问引擎反对前端利用，目前曾经在易观方舟产品中应用。而昨天公布的企业成长版易观方舟就是基于企业生态水系实现营销闭环的数据平台，它既有能采集到企业外部的各种不同数据的SDK（手机端、小程序、H5、Java、Python等），也反对易观或第三方任何一家的内部数据增补，还能够对接企业外部的ERP、CRM数据。而底层的秒算引擎提供让BI和大数据人员二次开发的SQL接口，以便企业精细化经营闭环的各种剖析和应用。 对于易观方舟来讲，咱们提供的是一个PAAS平台，就像咱们方才说的数据生态一样，咱们不认为易观一家就能够把这个平台做好。所以易观怀着十分凋谢的心态违心和大家单干。那么易观能给大家提供什么呢？ 易观通过18年的积攒，曾经有三千多家企业客户，咱们违心和大家一起共享资源。 易观有丰盛的数据资源，每个月月活5.9亿设施的数据资源。心愿有更多算法公司或者集体开发者加盟到联盟中，一起利用好这些数据。 易观有IOTA架构的方舟PAAS，大家能够在下面开发本人的组件，易观将帮忙你们把这些组件打包卖给客户实现盈利。 当然，咱们也有深刻行业的各种业务剖析场景。无论你是企业还是开发者，咱们都能够提供多种场景帮忙大家解决相干商业问题，与大家独特推动国内大数据生态倒退。 在这，我也代表易观，期待更多大数据开发者和企业加盟，给国内外企业提供更好的大数据服务。谢谢各位！

这周233酱和多年未见的老友聚了聚，除了变秃了点，大家都还是当初的模样儿～ 我只好把从果壳看来的防秃指南通知她。尽管没有一招制胜的卵办法，但也打消了我写防秃水文的念头... 从知乎「有哪些令人赞不绝口的算法？」话题下看到一个简略乏味的答复，是原作者「时宇电」面试腾讯的一道算法题。233酱的思考路线和作者的差不多，这里整顿后分享给大家～ 题目形容有一种玻璃杯从一栋100层的大楼扔下，该种玻璃杯超过某一层楼会摔碎。当初给你两个杯子，问确定最低摔碎的楼层须要摔多少次？ 题目剖析这道题的假如是：最低摔碎的楼层可能是每一层楼，且概率雷同。咱们须要找一种办法，使得定位到[1-100]之间的任意一个数都是疾速的。 解题思路最简略的办法是用一个杯子从第一层开始，一直一层层的往上试。然而这样的工夫复杂度是O(n)。直觉也通知咱们想放大步子扔。 因为咱们有两个杯子，能够思考成一个杯子Cup1一直扔直到破碎，它用来确定最低摔碎的楼层在什么范畴， 另一个杯子Cup2再此基础上一层层的扔。用来精确确定最低摔碎的楼层是多少。 如果凭空想象，咱们可能会想到二分法，每次隔5个楼层扔，10个楼层扔... 可是咱们马上也应该会想到这么分的不妥之处在于： 确定最低摔碎的楼层所需次数是不均匀分布的。 咱们再来看：每次扔的楼层距离会带来什么影响？ 确定最低摔碎的楼层： 总次数 = Cup1扔的次数 + Cup2扔的次数 楼层距离越大，Cup2须要扔的次数越多。 雷同楼层距离下：最低摔碎的楼层越高，Cup1须要扔的次数越多，Cup2须要扔的次数可认为雷同。 咱们的目标其实是须要尽可能保障：不论最低摔碎的楼层是第一层还是第99层，扔的总次数都尽可能统一且缩小。 如果小伙伴有看我上篇文章中LSMT分层步隆过滤器的实现，有没有受到启发？ 这里咱们能够使Cup1须要扔的楼层距离递加，这样可改善高楼层所需Cup1/Cup2扔的次数。 假如第一次扔的楼层距离为X，尔后顺次递加1层，直到楼层距离为2.则：x+(x-1)+(x-2)+...+2 >=100 求解出答案为14。 如果感觉有播种也请帮忙 四连【关注，点赞，再看，转发】 反对一下233酱，谢谢～

小白开发者不晓得从哪里入门大数据？ 入行不久对专业技能只知其一;不知其二？ 老板的新我的项目无力招架？ 想精进本人的常识体系，多个我的项目死记硬背？ 想拜师大数据行业大佬，求其指导一二？ ······ 机会来了！今夏最值得期待的大数据开发者技术盛筵，9大训练营齐发，想成为数据专家的同学千万不要错过。 大数据训练营“九营齐开”打算由阿里云智能高级研究员贾扬清出品，邀请了来自9个产品及技术团队的多位技术专家倾力打造。前所未有的嘉宾阵容，丰盛实用的技术干货，9个开源社区及产品团队精心打磨的9场训练营，超过40节课，笼罩大数据畛域方方面面，总有一场总有一课总有一个讲师，能在某一章某一段某一页启发到你，成为你2020年隆冬的一阵大风、一口西瓜味的冰淇淋、赶走乌云的一片晴天；让你想起小时候那句“我要创造一台能够让爸爸不必再加班的电脑”、“我心愿有人猜到全副我喜爱的变形金刚”。 咱们赤贫如洗，空余一身行走江湖的技能傍身，足以解忧。退出到大数据“九营齐开”打算，与你有同样期许的同学们来自四面八方，以少年之名，共赴夏日之约。 理解详情及报名请点击：https://developer.aliyun.com/learning/trainingcamp/dashuju亮点一：前所未有的嘉宾阵容阿里云智能高级研究员贾扬清出品，实时计算 Flink、Hologres、EMR、机器学习 PAI、MaxCompute、DataWorks、ElasticSearch 等多个技术/产品一线专家齐上阵，外围开发阵容在线直播教学。 亮点二：大数据畛域核心技术全笼罩课程内容波及数仓、数据湖、大数据建模、机器学习、搜索引擎以及数据智能利用等多个畛域，不仅讲清楚原理，还有 Demo 实操与利用实际，以丰盛的内容打造史上阵容最强、干货最多、笼罩技术畛域最宽泛的训练营。 亮点三：独家材料收费下载每期训练营出品人将围绕某一核心技术及训练营直播课程布局课外阅读材料，提供从入门到上手的全套学习教材，保障实操演示与扩大浏览同步进行，让您免于“想自学没材料想实操没人教”的各种懊恼。 ▼ 残缺9营具体介绍 ▼ 即日起，阿里云大数据训练营九营齐开！实践与实际，概念与案例，大数据从0到1上手学习，行业大神真人带练，这个夏日离成为数据科学家的幻想最近的间隔，就是在报名链接这里，你刚好点了～???????? 详情及报名链接：https://developer.aliyun.com/learning/trainingcamp/dashuju ▼ 九营齐开合作伙伴 ▼

小白开发者不晓得从哪里入门大数据？ 入行不久对专业技能只知其一;不知其二？ 老板的新我的项目无力招架？ 想精进本人的常识体系，多个我的项目死记硬背？ 想拜师大数据行业大佬，求其指导一二？ ······ 机会来了！今夏最值得期待的大数据开发者技术盛筵，9大训练营齐发，想成为数据专家的同学千万不要错过。 大数据训练营“九营齐开”打算由阿里云智能高级研究员贾扬清出品，邀请了来自9个产品及技术团队的多位技术专家倾力打造。前所未有的嘉宾阵容，丰盛实用的技术干货，9个开源社区及产品团队精心打磨的9场训练营，超过40节课，笼罩大数据畛域方方面面，总有一场总有一课总有一个讲师，能在某一章某一段某一页启发到你，成为你2020年隆冬的一阵大风、一口西瓜味的冰淇淋、赶走乌云的一片晴天；让你想起小时候那句“我要创造一台能够让爸爸不必再加班的电脑”、“我心愿有人猜到全副我喜爱的变形金刚”。 咱们赤贫如洗，空余一身行走江湖的技能傍身，足以解忧。退出到大数据“九营齐开”打算，与你有同样期许的同学们来自四面八方，以少年之名，共赴夏日之约。 理解详情及报名请点击：https://developer.aliyun.com/learning/trainingcamp/dashuju亮点一：前所未有的嘉宾阵容阿里云智能高级研究员贾扬清出品，实时计算 Flink、Hologres、EMR、机器学习 PAI、MaxCompute、DataWorks、ElasticSearch 等多个技术/产品一线专家齐上阵，外围开发阵容在线直播教学。 亮点二：大数据畛域核心技术全笼罩课程内容波及数仓、数据湖、大数据建模、机器学习、搜索引擎以及数据智能利用等多个畛域，不仅讲清楚原理，还有 Demo 实操与利用实际，以丰盛的内容打造史上阵容最强、干货最多、笼罩技术畛域最宽泛的训练营。 亮点三：独家材料收费下载每期训练营出品人将围绕某一核心技术及训练营直播课程布局课外阅读材料，提供从入门到上手的全套学习教材，保障实操演示与扩大浏览同步进行，让您免于“想自学没材料想实操没人教”的各种懊恼。 ▼ 残缺9营具体介绍 ▼ 即日起，阿里云大数据训练营九营齐开！实践与实际，概念与案例，大数据从0到1上手学习，行业大神真人带练，这个夏日离成为数据科学家的幻想最近的间隔，就是在报名链接这里，你刚好点了～???????? 详情及报名链接：https://developer.aliyun.com/learning/trainingcamp/dashuju ▼ 九营齐开合作伙伴 ▼

小白开发者不晓得从哪里入门大数据？入行不久对专业技能只知其一;不知其二？老板的新我的项目无力招架？想精进本人的常识体系，多个我的项目死记硬背？想拜师大数据行业大佬，求其指导一二？······ 机会来了！今夏最值得期待的大数据开发者技术盛筵，9大训练营齐发，想成为数据专家的同学千万不要错过。 大数据训练营“九营齐开”打算由阿里云智能高级研究员贾扬清出品，邀请了来自9个产品及技术团队的多位技术专家倾力打造。前所未有的嘉宾阵容，丰盛实用的技术干货，9个开源社区及产品团队精心打磨的9场训练营，超过40节课，笼罩大数据畛域方方面面，总有一场总有一课总有一个讲师，能在某一章某一段某一页启发到你，成为你2020年隆冬的一阵大风、一口西瓜味的冰淇淋、赶走乌云的一片晴天；让你想起小时候那句“我要创造一台能够让爸爸不必再加班的电脑”、“我心愿有人猜到全副我喜爱的变形金刚”。 咱们赤贫如洗，空余一身行走江湖的技能傍身，足以解忧。退出到大数据“九营齐开”打算，与你有同样期许的同学们来自四面八方，以少年之名，共赴夏日之约。 亮点一：前所未有的嘉宾阵容阿里云智能高级研究员贾扬清出品，实时计算 Flink、Hologres、EMR、机器学习 PAI、MaxCompute、DataWorks、Elasticsearch 等多个技术/产品一线专家齐上阵，外围开发阵容在线直播教学。 亮点二：大数据畛域核心技术全笼罩课程内容波及数仓、数据湖、大数据建模、机器学习、搜索引擎以及数据智能利用等多个畛域，不仅讲清楚原理，还有 Demo 实操与利用实际，以丰盛的内容打造史上阵容最强、干货最多、笼罩技术畛域最宽泛的训练营。 亮点三：独家材料收费下载每期训练营出品人将围绕某一核心技术及训练营直播课程布局课外阅读材料，提供从入门到上手的全套学习教材，保障实操演示与扩大浏览同步进行，让您免于“想自学没材料想实操没人教”的各种懊恼。 ▼ 残缺9营具体介绍 ▼ 即日起，阿里云大数据训练营九营齐开！实践与实际，概念与案例，大数据从0到1上手学习，行业大神真人带练，这个夏日离成为数据科学家的幻想最近的间隔，就是在报名链接这里，你刚好点了～???????? 报名链接：9营报名链接：https://developer.aliyun.com/learning/trainingcamp/dashuju# Hologres实时数仓训练营报名链接：https://developer.aliyun.com/learning/trainingcamp/holo/1?spm=a2c6h.17708709.J_2920514840.1.5ce86860U8pdzO

小白开发者不晓得从哪里入门大数据？入行不久对专业技能只知其一;不知其二？老板的新我的项目无力招架？想精进本人的常识体系，多个我的项目死记硬背？想拜师大数据行业大佬，求其指导一二？······ 机会来了！今夏最值得期待的大数据开发者技术盛筵，9大训练营齐发，想成为数据专家的同学千万不要错过。 大数据训练营“九营齐开”打算由阿里云智能高级研究员贾扬清出品，邀请了来自9个产品及技术团队的多位技术专家倾力打造。前所未有的嘉宾阵容，丰盛实用的技术干货，9个开源社区及产品团队精心打磨的9场训练营，超过40节课，笼罩大数据畛域方方面面，总有一场总有一课总有一个讲师，能在某一章某一段某一页启发到你，成为你2020年隆冬的一阵大风、一口西瓜味的冰淇淋、赶走乌云的一片晴天；让你想起小时候那句“我要创造一台能够让爸爸不必再加班的电脑”、“我心愿有人猜到全副我喜爱的变形金刚”。 咱们赤贫如洗，空余一身行走江湖的技能傍身，足以解忧。退出到大数据“九营齐开”打算，与你有同样期许的同学们来自四面八方，以少年之名，共赴夏日之约。 亮点一：前所未有的嘉宾阵容阿里云智能高级研究员贾扬清出品，实时计算 Flink、Hologres、EMR、机器学习 PAI、MaxCompute、DataWorks、Elasticsearch 等多个技术/产品一线专家齐上阵，外围开发阵容在线直播教学。 亮点二：大数据畛域核心技术全笼罩课程内容波及数仓、数据湖、大数据建模、机器学习、搜索引擎以及数据智能利用等多个畛域，不仅讲清楚原理，还有 Demo 实操与利用实际，以丰盛的内容打造史上阵容最强、干货最多、笼罩技术畛域最宽泛的训练营。 亮点三：独家材料收费下载每期训练营出品人将围绕某一核心技术及训练营直播课程布局课外阅读材料，提供从入门到上手的全套学习教材，保障实操演示与扩大浏览同步进行，让您免于“想自学没材料想实操没人教”的各种懊恼。 ▼ 残缺9营具体介绍 ▼ 即日起，阿里云大数据训练营九营齐开！实践与实际，概念与案例，大数据从0到1上手学习，行业大神真人带练，这个夏日离成为数据科学家的幻想最近的间隔，就是在报名链接这里，你刚好点了～???????? 报名链接：9营报名链接：https://developer.aliyun.com/learning/trainingcamp/dashuju# Hologres实时数仓训练营报名链接：https://developer.aliyun.com/learning/trainingcamp/holo/1?spm=a2c6h.17708709.J_2920514840.1.5ce86860U8pdzO

简介： 即日起，阿里云大数据训练营九营齐开！实践与实际，概念与案例，大数据从0到1上手学习，行业大神真人带练！ 小白开发者不晓得从哪里入门大数据？ 入行不久对专业技能只知其一;不知其二？ 老板的新我的项目无力招架？ 想精进本人的常识体系，多个我的项目死记硬背？ 想拜师大数据行业大佬，求其指导一二？ ······ 机会来了！今夏最值得期待的大数据开发者技术盛筵，9大训练营齐发，想成为数据专家的同学千万不要错过。 大数据训练营“九营齐开”打算由阿里云智能高级研究员贾扬清出品，邀请了来自9个产品及技术团队的多位技术专家倾力打造。前所未有的嘉宾阵容，丰盛实用的技术干货，9个开源社区及产品团队精心打磨的9场训练营，超过40节课，笼罩大数据畛域方方面面，总有一场总有一课总有一个讲师，能在某一章某一段某一页启发到你，成为你2020年隆冬的一阵大风、一口西瓜味的冰淇淋、赶走乌云的一片晴天；让你想起小时候那句“我要创造一台能够让爸爸不必再加班的电脑”、“我心愿有人猜到全副我喜爱的变形金刚”。 咱们赤贫如洗，空余一身行走江湖的技能傍身，足以解忧。退出到大数据“九营齐开”打算，与你有同样期许的同学们来自四面八方，以少年之名，共赴夏日之约。 理解详情及报名请点击： https://developer.aliyun.com/learning/trainingcamp/dashuju亮点一：前所未有的嘉宾阵容阿里云智能高级研究员贾扬清出品，实时计算 Flink、Hologres、EMR、机器学习 PAI、MaxCompute、DataWorks、ElasticSearch 等多个技术/产品一线专家齐上阵，外围开发阵容在线直播教学。 亮点二：大数据畛域核心技术全笼罩课程内容波及数仓、数据湖、大数据建模、机器学习、搜索引擎以及数据智能利用等多个畛域，不仅讲清楚原理，还有 Demo 实操与利用实际，以丰盛的内容打造史上阵容最强、干货最多、笼罩技术畛域最宽泛的训练营。 亮点三：独家材料收费下载每期训练营出品人将围绕某一核心技术及训练营直播课程布局课外阅读材料，提供从入门到上手的全套学习教材，保障实操演示与扩大浏览同步进行，让您免于“想自学没材料想实操没人教”的各种懊恼。 ▼ 残缺9营具体介绍 ▼ 即日起，阿里云大数据训练营九营齐开！实践与实际，概念与案例，大数据从0到1上手学习，行业大神真人带练，这个夏日离成为数据科学家的幻想最近的间隔，就是在报名链接这里，你刚好点了～???????? 详情及报名链接： https://developer.aliyun.com/learning/trainingcamp/dashuju

1 引言Excel是数据分析师的根底入门工具，在日常工作过程中，用好Excel函数能够节俭很多工夫，起到事倍功半的成果。 介绍函数之前，须要强调几个概念： 绝对援用、相对援用和混合援用 绝对援用简略的说就是在横向竖向复制含有公式单元格，会发生变化，单元格输出 =A1，填充的时候就变为=A2、=A3、=B1、=C1等等。 相对援用简答的说就是在横向竖向复制含有公式单元格，不会发生变化。单元格输出 =$A$1，填充的时候不会扭转，始终为A1的内容。 混合援用分为行相对列绝对和行绝对列相对。单元格输出 =A$1 **、**=$A1 运算符算法运算符：加、减、乘（*）、除（/）、^（次方 2^2=4）、%（百分比 2%=0.02） 比拟运算符：=、>、>=、<、<=、<>（不等于） 文本运算符：&（=A1&A2、=A1&"字符"） 援用运算符：冒号：（区域运算符=SUM(A1:B3) ）、逗号，（联结运算符 =SUM(A1:B3,B5:C5) ） 须要留神的点： 运算符的计算程序是：先乘除、后加减、再比拟。从左到右，括号优先。输出公式要以 =开始2 函数函数分为财务、逻辑、文本、日期和工夫、查找和援用、数学和三角函数、其余函数。总共加起来差不多有400多个函数。 2.1 逻辑函数逻辑函数与、或、非、条件、IS等。 2.2 文本函数文本函数能够用来做数据荡涤，比方TRIM函数，用于革除字符串两边的空格。REPLACE函数替换单元格中指定地位长度的字符。LEFT/RIGHT/MID函数用于截取字符串中的字符。FIND？SEARCH函数用于查找字符。TEXT函数用于将数值转为指定的文本格式。等等 2.3 数学和三角函数数学和三角函数为罕用的根底计算、剖析、统计函数。如求和、求均匀、计数、排序、取值等等。 2.4 日期和工夫函数日期和工夫函数如取年、月、日。计算日期之间的天数/月数/年数。工作日和周末计算等。 2.5 查找和援用函数查找和援用函数多用于表之间关联时用于取数，如VLOOKUP函数、INDEX函数、MATCH函数等。 以上列出的函数，并不是Excel中的全副函数，只是列出比拟常见的函数。并没有给出每个函数的更为细节的用法，大家在应用某个函数的时候，能够具体百度。 3 Excel根底补充Excel根底除第一次介绍的，还有条件格局、套用表格格局、高级筛选、组合和分组、对象和文件爱护。我在这列了纲要，能够自行去理解一下。 后记Excel那篇格局的确是有点乱，第一次采纳MarkDown格局，语法把握的还不是很纯熟。不过比刚开始写公众号的时候提高了，那时采纳的富文本，还有空格，的确不业余。我搭建的工具为Typora软件和阿里云的图床。后续有工夫介绍一下，整个工具配置的过程。 不求点赞，只求有用 本文由微信公众号《大数据分析师常识分享》公布

阿里巴巴始终在面向未来摸索B类新电商模式，并从2019年开始重点构建“新供应、新链接、新营销”三新体系。买家是三新体系的外围，短少买家维度的数字化经营体系是不残缺的。平台场景目标群体及场景间买家差异性尚不明确，客群矩阵就是为场景中控解决这一业务痛点、进步场货散发效力而专门设置的算法钻研主题。同时，客群矩阵也是用户增长和算法特色的外围数据。鉴于客群矩阵如此重要且领有诸多利用，其构建火烧眉毛。 阿里巴巴意在将客群矩阵打造成平台的一个风向标，以便业务有指标、有档次、有差别、高效地选品和进行场景经营及商家经营，为用户增长和算法模型优化提供能源，为数字化经营提供根据。咱们次要围绕人、货、场、商4个维度构建，客群矩阵详情如图1所示。 客群矩阵同场景矩阵叠加，在构建场景指标用户、掂量场景差异性的同时，也能进步场景效力，无效疏导指标流量，进而为各类业务场景的算法建模提供底层数据根底。 1 洽购力B类买家不像C类买家有明确的年龄、性别等根底坐标维度，B类用户多是企业或者批发商，如何刻画B类特色的客群矩阵，这对于B类电商十分重要，也是B类电商“小二”始终在思考的问题。 既然B类用户群体次要是企业和批发商，那么如何精确地形容客群矩阵呢？洽购力就是突出的表征，洽购力蕴含洽购金额和洽购频率，从洽购力能够看出用户的经营规模和耗费能力。因而，咱们将洽购力作为根底坐标维度，分层提供精准差异化服务。 洽购金额次要是肯定周期内用户洽购的金额。为了躲避不同品类价格差别较大带来的分层烦扰，首先分类目对洽购金额划档，而后再依照金额档不分类目看，占比最多的金额档就是此用户的洽购金额档层。 洽购频率是肯定周期内用户的洽购频次。将用户依照洽购工夫排序，而后计算用户在肯定工夫周期内洽购的频次。将所有用户依照高斯分布比例划分出高、中、低档，作为洽购频率的分层品位。 2 生命周期包含新装机、新用户、低活、中活、中高活、高活、沉睡、散失等阶段，该生命周期次要是依照用户在电商平台的活跃度来划分的，其中也融入了局部业务知识。例如，新装机用户是指刚装机的用户，新用户是指成交在2单以内的用户，低活是指一个月拜访天数在2天以内的用户等。 从交易周期剖析用户生命周期，如图2所示，包含新装机激活用户、登录用户、首单用户、沉闷买家（高洽购力买家、后劲买家）、潜睡买家、深睡买家等阶段，各个生命周期阶段之间的转换关系在图中也有直观出现。精准化用户经营依据买家生命周期阶段不同而调整指标，所采取的策略也会相应调整。 理解了用户生命周期，就能够有针对性地做用户拉新、促活、留存，以进步用户黏性：对于新装机和新用户，次要是进步他们的用户体验，造就用户的生产习惯，做留存转化；对于中低活用户，次要是促活、留存；对于中高活用户，次要是维持用户的习惯，增强黏性；对于沉睡和散失用户，次要是通过红包权利等形式促活。用户生命周期的保护对于电商继续用户增长施展着至关重要的作用。 3 外围主营CBU作为B2B电商平台的典型代表，始终致力于服务寰球亿万B类买家用户。用户核实身份与主营类目（如进口母婴店店主、精品女装店店主、微商兼职、小超市店主等）作为B类用户画像最为外围的属性之一，不仅代表着用户的线下实体身份，还间接影响着用户在电商平台上的行为偏好、洽购周期及对商家服务能力的诉求等，因而始终是B类电商平台致力于深耕与经营的外围用户画像属性之一。 大多数C类用户画像属性能够间接基于用户在网站上的历史行为进行建模，但B类用户画像则不同。因为要核实用户核身身份以及对主营类目有精准性的要求，个别B类电商平台次要以用户自填表单的模式进行用户核实身份的确定。这种用户自填形式后果准确度较高，但地位荫蔽、链路简短、没有利益点的疏导，不仅用户填写率低，而且与场景结合力有余。 为解决原表单式核身用户操作老本高的问题，阿里巴巴CBU电商平台通过用户核身组件借力算法模型对用户核身进行预测，根据置信度排序，为用户推出Top K个选项供用户点选。整体算法解决方案如下。 01 数据源1）用户站内行为用户站内行为是用户需要与偏好的第一反馈基地，是算法须要着重去开掘的数据源。绝对其余偏好类画像属性来说，用户核身是一个绝对稳固和长期的用户属性，因而在算法利用中，咱们选取了用户最近半年的站内全域行为作为底层数据。定义半年的长时间窗口选取次要有两方面思考：一是目前网站商品丰盛、优质，搜寻与举荐算法日渐精进，用户浏览各类商品的老本较低，所以B类用户在网站上的注意力难以放弃专一，用户B类/C类的需要与行为混淆，数据较脏，较长的工夫窗口有利于滤除烦扰，捕捉用户更为长期和稳固的需要；二是用户行为数据，特地是洽购行为，绝对稠密，然而B类用户的洽购行为是反映用户核身身份最为外围的特色之一，且用户洽购行为又具备肯定的周期性，因而长期的工夫窗口可能帮忙算法更加全面地意识用户。 2）用户站外上下游身份不同于很多偏好类用户画像属性，用户核身身份可能与用户在事实中的身份产生实在的映射关系，如奶茶店店主—喜茶店主、烘焙店店主—宝岛金典店主、精品女装店店主—淘宝女装店店主等。因而，用户站外上下游的身份映射关系，可能辅助咱们进一步欠缺用户核身身份的预测，进步覆盖率和准确率。 3）行业常识鉴于用户在网站上B类/C类行为混淆，噪声较多，B类用户核身偏好易受网站热门类目与商品的烦扰，因而咱们也引入了大量行业常识作为领导来帮助实现B类用户核身身份的预测，并基于此积淀下来一份核身偏好类目数据。 02 算法计划利用以上用户站内行为、站外上下游身份和行业常识的数据，算法端能够通过以下几个步骤实现用户核身身份的预测工作，预测流程如图3所示。 图3　用户核身预测流程图 1）种子用户圈选种子用户次要定义为站内已核身用户及站外上下游有映射关系的核身信息的用户。 2）行业常识领导咱们基于种子用户最近一段时间的站内行为数据，开掘辨认显著性特色，提供给经营共事，对种子用户再进行一轮划拨，把日常外围行为与行业偏好显著不合乎的用户排除，优化种子用户的圈选。 3）种子商品圈选以行业偏好类目作为门槛，筛选出种子用户在门槛下最近半年内洽购过的商品作为种子商品。 4）种子商品扩大基于团队积淀现有商品的I2I表，利用种子商品作为trigger触发Key，对种子商品进行扩大，扩大种子商品的偏好分等于商品I2I类似分与trigger种子商品偏好分的乘积。 5）用户核身预测对于一个用户的核身预测，咱们选取其最近半年的行为数据进行建模打分。而后基于打好分的用户行为商品计算用户对每一个可能的核身身份的偏好置信度，并用以辨别用户的集体洽购行为和B类洽购行为，升高用户的集体洽购行为对预测后果的影响，加大用户的B类洽购行为的权重。 本文摘编于《阿里巴巴B2B电商算法实战》经出版商受权公布。 本书是阿里巴巴CBU技术部（1688.com）深耕B2B电商15年的经验总结。阿里巴巴B2B在策略状态上经验了信息平台、交易平台和营销平台的降级迭代，本书聚焦营销平台商业状态背地的算法和技术能力，试图从技术和商业互为驱动的视角论述技术如何赋能业务，并联合阿里巴巴团体在根底设域和算法翻新上的积淀，打造出智能B2B商业操作系统。 阿里巴巴B2B电商算法实战作者：阿里团体,新批发技术事业部,CBU技术部 举荐浏览 《用户画像：方法论与工程化解决方案》 这是一本从技术、产品和经营3个角度解说如何从0到1构建用户画像零碎的著述，同时它还为如何利用用户画像零碎驱动企业的营收增长给出了解决方案。 用户画像：方法论与工程化解决方案作者：赵宏田 关注“实时流式计算” 后盾回复 “0814” 参加抽奖 将于8月15号中午12:00开奖 共送出两本图书 欢送大家参加~

凭借多年大数据平台建设教训，易观 CTO郭炜为大家分享了易观在大数据实时查问引擎建设过程所获教训与挑战，以及大数据人员如何疾速建设本人的大数据查问引擎套件，让本人的数据人员不再是“表哥表妹”的办法。 以下是具体内容： 作为数据人的你，是不是遇到这样的状况？ 数据需要80%都是提数、出报表的需要，而很多报表往往只用一次…长期剖析泛滥，不管怎么提前做汇总减速开发，业务部门总感觉慢…长期报表数据口径重复和业务部门核查，最初出的数据还是对不上，“写脚本3分钟，对数3小时”…业务疾速变动导致数据源的变动层出不穷，汇总层数据放弃精确十分难，数据治理建设不易，保护老本更是昂扬…大数据工程师每日工作在写各种ETL、数据流脚本，而无奈专一在大数据技术上…究其原因会发现，不是数据技术能力不行，而是世界变动太快。数据驱动自身，是一个透明化的过程，挑战是业务变动很快，让数据自身“不通明”。 业务变动，数据定义变动快，例如，APP迭代，页面变动；数据通过层层加工，原始信息失落，仓库表繁多，层层血缘关系，牵一动员全身；数据处理能力有余，工夫滞后：T+1，长期需要 T+N，OLAP Cube也无奈满足需要；想用Ad-hoc查问，但数据量过大，Tb 级别数据一般查问以数十分钟为单位出后果，跟不上分析师思路。 怎么办呢？破局的关键在于，将Ad-hoc查问从现有大数据体系中分离出来。 应用最新的大数据技术Ad-hoc，间接让业务人员从最明细的数据中统计，秒级返回后果，把业务口径还给业务人员，技术人员只做最底层的数据整顿。 大数据Ad-hoc引擎的优缺点有哪些呢？ 长处： 业务人员无需期待，间接统计相干数据 业务人员自定义口径，数据治理工作量小 技术人员无需天天提数，专一在技术平台 毛病： 须要额定的硬件/系统资源 数据场景绝对繁多，须要优良的数据模型形象 新的技术引入，保护、降级工作量问题 企业需依据本人的状况抉择是否建设大数据Ad-hoc查问引擎。 那么，如何去构建企业级大数据Ad-hoc查问引擎呢？要害是做好这三步：抉择要解决的业务场景并建模；抉择数据查问底层引擎与技术生态；企业自建Ad-hoc引擎要点与参考架构。 抉择要解决的业务场景并建模首先须要抉择固定的业务场景。 日常业务场景中数据量微小，秒级返回硬件老本过高，不是每家公司都是Google；因为数据结构简单，所以多个业务场景导致数据模型很难形象和固定下来；最初就是查问无奈优化，秒回的查问是须要建设大量适合的索引和算法。 固定场景下的大数据中台——深中台 vs 广中台 ， 不是替换关系，而是补充和增强 接着须要思考固定场景须要什么粒度？以能够确定概念数据模型为准。 总结来说就是，高度形象，涵盖这个场景多个查问；业务人员可懂，能够和业务人员沟通，并验证场景；数据关系与逻辑可验证，联合概要设计，能够初步验证整体数据逻辑与设计逻辑。 概念数据模型（Conceptual Data Model）：简称概念模型，是面向数据库用户的事实世界的模型，次要用来形容世界的概念化构造，它使数据库的设计人员在设计的初始阶段，解脱计算机系统及DBMS的具体技术问题，集中精力剖析数据以及数据之间的分割等。 概念模型举例——用户数据分析、物流剖析 概念数据模型验证，帮忙技术和业务建设深刻交换通道，大数据中台本不是一个技术（IT）我的项目，它是技术和业务相结合的我的项目。 次要目标是为了让技术人员更深刻了解业务场景，修改模型，同时验证业务计算逻辑，为算法设计铺路，最终让业务人员了解最终底层逻辑，有利于将来业务人员本人定义本人的查问逻辑和业务指标。 业务验证先验证实细业务逻辑与思路，口径细节最终交给业务用户，算法和优化是另外的事件。 须要留神的是，概念模型尽管能够应用大宽表，但笼罩的场景绝对更少，也须要留神明细数据而不是汇总数据，这与大数据平台、数据仓库的BDS层（业务汇总层）有区别。 理论状况vs现实状况 抉择数据查问底层引擎与技术生态Ad-hoc 底层引擎选型规范有4条，即反对SQL，反对JDBC；内存计算而不是磁盘计算；反对即席从明细当中进行统计，而不是当时生成Cube（查问场景不同）；开源（举荐Apache社区或者全副Apache协定）。 这里须要给大家介绍以下，为什么会举荐开源抉择Apache生态？ Apache开源确保Licence、将来各种应用不会呈现任何商业问题，而且社区互动也能够疾速进步团队能力。同时，Apache开源版本对人员素质要求较高，启动时代价绝对较高。 Apache HDFS 常见Ad-hoc底层引擎介绍 Spark SQL ：Spark 解决结构化数据的程序模块。它将 SQL 查问与 Spark 程序无缝集成,能够将结构化数据作为 Spark 的 RDD 进行查问。 Presto：一个分布式SQL查问引擎， 它被设计为用来专门进行高速、实时的数据分析。Presto 自身并不存储数据，然而能够接入多种数据源，并且反对跨数据源的级联查问。 Impala ：Cloudera 在受到 Google 的 Dremel 启发下开发的实时交互SQL大数据查问工具，它领有和Hadoop一样的可扩展性、它提供了类SQL（类Hsql）语法，在多用户场景下也能领有较高的响应速度和吞吐量。 ...

作者：阿里巴巴菜鸟物流团队（弃疾，孝江，姜继忠） 一、业务背景菜鸟智能物流剖析引擎是基于搜寻架构建设的物流查问平台，日均解决包裹事件几十亿，承载了菜鸟物流数据的大部分解决工作。 智能物流剖析引擎将基于运配网络的各类利用场景集中到了对立的一个技术架构，以此提供弱小的吞吐和计算能力。基于原架构的数据处理流程为：Datahub实时采集数据源，蕴含仓、配、运和订单等数据，实时计算Flink基于流批一体的模式对数据预处理，造成一个以订单为单位，蕴含订单跟踪事件的宽表，写入存储引擎HBase中，再供内部查问。 在数据处理局部，随着数据量的减少，原有的存储系统HBase在维表全量导入中所须要的工夫越来越长，这就须要消耗大量的资源，另外其单机吞吐的体现不是很好，单位成本高。在数据量较小时，老本不是须要思考的关键因素，但当数据量规模变大时，老本的重要性就体现进去了。菜鸟智能物流每天须要解决大批量的数据，这也就意味着每天将会节约大量的资源。 同时，在咱们的场景中，有些表是作为Flink维表基于PK进行PointQuery，有些表须要进行OLAP剖析，而HBase并不能两种场景都满足。为了OLAP剖析，须要将数据同步到批处理零碎中，为了KV查问，须要将数据同步到KVStore。不同的查问需要就须要借助多个零碎，数据在不同零碎之间的导入导出不仅会加深数据同步的累赘，也会带来冗余存储，也极容易呈现数据不统一的状况，并且多个零碎也会给开发和运维带来肯定的老本。 基于以上背景，以后咱们最须要解决的问题是升高整体的资源耗费老本，那么就须要有一款产品既能提供存储能力还要提供高性能的写入能力。而在查问场景上，若是这款产品能同时满足KV查问和简单OLAP查问将会是加分项，这样就会解决多个零碎带来的数据孤岛问题，一次性满足所有需要。咱们在团体内对多个产品进行了调研，最终抉择了Hologres替换现有的HBase。 二、业务架构菜鸟物流引擎须要解决大量的表和数据，全量工作快递线和仓配线通过MaxCompute（原ODPS）表的日分区快照做驱动源，增量工作通过对应的事件流做驱动，来进行引擎数据写入。 全量工作会依据包裹的历史履行进度进行聚合，生成这个包裹的主观履行和历史属性信息，并通过Flink Job实时同步更新到Hologres里，提供给数据工作进行关联。实时数据在接管到一条事件音讯后，首先会去关联这条包裹历史履行，并会调用算法服务链，进行拆合单、末端网点预测、路由抉择、时效预测等，生成新的预测履行进度。新的预测履行会作为回流数据写入TT（消息中间件，相似Kafka）和Hologres中，并再提供给数据工作进行关联。 通过数据工作之间的相互协同，咱们对数据关系进行了梳理，并尽量升高数据之间的依赖，最终业务解决架构如下图所示： 数据驱动层 在数据驱动层中，蕴含几个局部：全量工作的主表驱动、增量工作的主表驱动、业务辅表的驱动。数据关联层 数据关联层次要包含各种Flink的SQL Operator。为了晋升全量工作和增量工作的吞吐，通过存储和计算优化，将数据关联尽可能的散布到不同的数据分区上，来进行性能晋升。数据交互层 索引数据通过Swift Sink的形式写入到索引构建服务中；要长久化的外部数据，通过写入接口保留到存储服务中。 三、业务价值将HBase替换成Hologres之后，给业务带来的价值次要有以下几个方面： 1.整体硬件资源老本降落60%+比照HBase，雷同配置的Hologres有着更强的写入性能，可能提供更好的吞吐量，也就是说咱们能够用更少的资源来满足现有数据规模的解决需要。在理论业务利用中，整体硬件资源老本降落60%+，解决了咱们最辣手的问题。 2.更快的全链路处理速度（2亿记录端到端3分钟）全量数据处理所需的工夫是十分重要的指标，构想某一天新公布的数据处理代码有bug，新产出的数据不可用，即便修复了代码，还得持续解决曾经存在的谬误数据，此时就要跑一次全量，用失常的数据笼罩谬误的数据。全量工作的运行工夫决定了故障的持续时间，全量运行的速度越快，故障能力越快解决。在物流剖析引擎的全量中，咱们须要先通过所有维表的数据，确保维表本身的数据是正确的，这是一个十分耗时的操作。以其中一张表为例，2亿多的数据量，应用Hologres同步只须要3分钟左右，这也意味着能够更快的执行结束全量数据，以便咱们可能更从容应对突发状况。 3.一个零碎，满KV和OLAP两个场景，没有数据冗余Hologres在存储上反对行存和列存两种存储模式。列存适宜海量数据的交互式剖析，而行存适宜基于Primary Key的整行读取。这就意味着咱们能够将所有的数据存储在Hologres中，须要PointQuery就抉择行存模式，须要简单OLAP剖析就抉择列存模式，满足了OLAP和KV查问，无需在借助其余零碎，既保证了数据存储的唯一性，也防止了各种零碎之间的导入导出和简单运维。 4.大维表实时SQL查问以前如果想查一下维表中的数据，因为是KV接口，并不是很不便。Hologres兼容PostgreSQL生态，能够间接应用psql客户端拜访，通过规范的PostgreSQL语法查问表中的数据，反对各种过滤条件，可能很不便的实时检查数据是不是有问题。 5.强Schema原有的维表存储是一个弱Schema的存储服务，在Flink工作中，即便拜访不存在的字段也不会报错，只是获取到的字段值为空。代码里不小心写错了字段名，一是很难立即发现，通常要等到数据产出时候能力发现，甚至只能等用户发现，另外排查起来也很麻烦，没法间接定位。应用Hologres的时候字段名写错立刻报错，错误信息很明确，防止了潜在的谬误危险，还能节省时间。

今天在openstack中遇到了删除实例删除失败的现象，检查界面上显示状态–deleting,后台日志/var/log/nova/nova-compute.log显示During sync_power_state the instance has a pending task (deleting). Skip错误。 检查存储端，发现对应的实例已经删除，所以决定重启下compute服务。 systemctl restart openstack-nova-compute 然后刷新界面，发现所有出错的实例已经都成功被删除了。

LSM Tree（Log-structured merge-tree）广泛应用在HBase，TiDB等诸多数据库和存储引擎上，咱们先来看一下它的一些利用：这么牛X的名单，你不想理解下LSM Tree吗？装X之前，咱们先来理解一些基本概念。 设计数据存储系统可能须要思考的一些问题有：ACID，RUM（Read,Write,Memory）。 ACIDACID 置信小伙伴都被面试官问过，我想简略探讨的一点是：如何 长久化数据 能力保证数据写入的 事务性 和 读写性能？ 事务性可简略了解为：1.数据必须长久化。2.一次数据的写入返回给用户 写入胜利就肯定胜利，失败就肯定失败。读写性能可简略了解为：一次读 或 一次写 须要的IO次数，因为拜访速率：CPU>>内存>>SSD/磁盘。 对于单机存储，最简略的形式当然是：写一条就长久化一条，读一条就遍历一遍所有数据，而后返回。当然没人这么干，在内存中咱们都还晓得用个HashMap呢。 拿Mysql InnoDB举例子：读性能体现在数据的索引在磁盘上次要用B+树来保障。写性能体现在使用 WAL机制 来防止每次写都去更新B+树上的全量索引和数据内容，而是通过redo log记录下来每次写的增量内容，程序将redo log写入磁盘。同时在内存中记录下来本次写入应该在B+树上更新的脏页数据，而后在肯定条件下触发脏页的刷盘。 redo log是数据增删改的实时增量数据，程序写入保障了写性能和事务性。磁盘上的B+树是数据增删改的全量数据，通过定时脏页刷盘保障这份数据的完整性。 这里的问题是：尽管通过WAL机制，进步了写入性能，然而依然防止不了脏页数据定时刷盘的随机IO写入。因为数据在磁盘上是以block为单位存储的（比方4K，16K）,如果你更新了Order表一条数据，又更新了Product表一条数据，脏页刷盘时，这两条数据在磁盘上的block地位可能差了十万八千里，就变成了随机IO的写入。 RUMRUM（Read,Write,Memory）相似分布式畛域的CAP定理。如果想得到三者中的两者性能，必须以就义第三者的性能为代价。掂量这三者的性能指标有：读放大、写放大、空间放大。 读放大：是指每次查问读取磁盘的次数。如果每次查问须要查问5个page (或block)，则读放大是5. 写放大：是指数据写入存储设备的量和数据写入数据库的量之比。如果用户写入数据库的大小是10MB，而理论写入磁盘的大小是30MB，则写放大是3.另外SSD的写入次数是无限的，写放大会缩小SSD的寿命。 空间放大：是指数据在存储设备的总量和数据在数据库的总量之比。如果用户往数据库上存10MB，而数据库理论在磁盘上用了100MB去存，则空间放大就是10. 通常，数据结构能够最多优化这其中的两者，如B+树有更少的读放大，LSM Tree有更少的写放大。 上面咱们将介绍LSM Tree的构造，它是如何解决 B+树中“全量数据的随机写入” 问题的；在RUM问题上，又该如何优化LSM Tree。 为什么要有LSM TreeLSM Tree（Log-structured merge-tree）起源于1996年的一篇论文：The log-structured merge-tree (LSM-tree)。过后的背景是：为一张数据增长很快的历史数据表设计一种存储构造，使得它可能解决：在内存不足，磁盘随机IO太慢下的重大写入性能问题。 如果咱们先后批改两条数据，那么在脏数据块落盘时，不是一条条随机写入，而是以一个脏块批量落盘时，就能解决 B+树中“全量数据的随机写入” 问题了。 所以大佬设计了这么一种构造： Ck tree是一个有序的树状构造，数据的写入流转从C0 tree 内存开始，一直被合并到磁盘上的更大容量的Ck tree上。这种形式写入是程序写的，增删改操作都是append。这样一次I/O能够进行多条数据的写入，从而充分利用每一次写I/O。 merge所做的事件有：当上一棵树容量有余时，1.将上棵树中要删除的数据删除掉，进行GC回收。2.合并数据的最新版本，使得Ck tree不会适度收缩。 这种初始构造存在的问题有：随着数据量的增大，merge吃力，没有好的索引构造，读放大重大。古代的LSM Tree构造如下： MemTable：是LSM Tree在内存中还未刷盘的写入数据，这外面的数据能够批改。是一个有序的树状构造，如RocksDB中的跳表。 SSTable（Sorted String Table）：是一个键是有序的，存储字符串模式键值对的磁盘文件。当SSTable太大时，能够将其划分为多个block；咱们须要通过 下图中的Index 记录下来每个block的起始地位，那么就能够构建每个SSTable的稠密索引。这样在读SSTable前，通过Index构造就晓得要读取的数据块磁盘地位了。 ...

大数据时代，人人离不开数据，然而数据是怎么组织治理，如何为咱们的生存服务的呢？ 作为一个数据从业者，基于我集体的了解文言下。 数据与生存比照线下时代，数据从两个方面晋升了大家的生存： 交易，技术上对应的术语叫联机事务处理（OLTP online transaction processing），数据是交易系统中流淌的血液，他能够对应你在电商上的一个订单、一件商品、一笔领取流水，通常应用数据库进行数据管理剖析，技术上对应的术语叫联机剖析解决（OLAP online analysis processing），数据是剖析零碎的原料，通过数据分析电商上能够给你举荐商品、进行产品定价、销量预测，通常应用数据仓库进行数据管理 本文从上面几个角度给大家介绍下数据仓库。 什么是数仓数据库（次要指关系型数据库）为交易系统提供底层服务，反对数据的增删查改，且要求高度的范式保障（具备ACID个性，即原子性、一致性、隔离性、持久性），实现了疾速的事务响应和吞吐； 剖析系统对数据的要求： 数据体量微小（能够理解大数据的4V实践）数据查问为主，且长久的数据存储（通常不进行删除、更新操作）数据的设计更好的反对剖析决策数据仓库就是一种面向数据分析决策需要的系统性解决方案，用数据模型形容映射事实世界，面向不同的场景制订数据建设标准，同时确保高效平安稳固的数据生产。 数据模型后面提到数据模型是对事实世界的映射，常见的模型有：层次模型、网状模型、关系模型： 关系模型，对应关系型数据库，用表格形式映射事实世界；通过表、行、字段等示意了显示世界中的对象、对象属性、对象之间的关系；构造简略、级联查问效率低网状模型，对应图数据库，结构复杂，不不便保护；典型的数据库有neo4j titan等，在社交网络分析中有肯定利用场景层次模型，用树来映射事实世界；查找不便、构造板滞目前利用最宽泛的是关系模型，具体到数据仓库有有两种建模形式：Inmon企业信息工厂架构 vs Kimball总线体系结构 建模形式范式建模维度建模特点更像数据库 少冗余 字段只依赖主键一系列的事实表 + 维度表，构造上冗余较多，绝对灵便建设形式自顶而下的建设形式自下而上形式构建业务适应适应业务变动偏弱较好适应业务变动模型3NF范式模型星型模型或者雪花模型目前支流互联网的数据仓库建设都抉择维度模型，或者在公共数据域采纳绝对固定的范式建模，在数据应用层采纳更灵便的维度模型。 维度模型维度模型中最重要的两个概念： 维度—看世界、事务的角度； 档次维、变动维、角色扮演维、分类维、其余类事实—对世界、事务的度量 维度模型常见建模形式： 星型模型（上图就是典型的星型模型）雪花模型（事实-维度-子维度组合）星座模型（多事实多维度）数据立方体cube（预处理 疾速剖析应用）维度模型的设计通过数据来映射事实世界，进行维度建模的时候通常遵循上面的设计流程：从业务需要登程，将业务流程进行拆分，颗粒度细到咱们能够用维度+事实来形容事物，将事实世界中事物形象为具体的表、字段，并通过示例数据、业务规定进行辅助阐明 数仓的分层通过维度模型咱们构建了事实事物的数据映射后，事物倒退的过程中咱们一直的进行数据采集，最终的数据量是十分微小的（4V的volume），通常这种数据是无奈间接进行剖析应用的，咱们须要对数据进行逐层的收敛聚合，于是产生了数仓分层的概念。 在介绍数仓分层之前咱们先介绍下数据仓库的管理工具Hive 数据仓库与hivehive基于hadoop的数据仓库工具，用来进行数据提取、转化、加载，能够存储、查问和剖析存储在hadoop中的大规模数据的机制； hive将hdfs中结构化的数据文件映射为一张张数据库表，提供sql查问性能，将sql转换为mr计算（交叉了hadoop的整个体系，给用户相熟的SQL形式进行数据的解决和交互） hadoop三大模块： hdfs分布式存储、yarn调度零碎、mr计算零碎。应用hadoop体系构建数据仓库能够反对大容量、分布式的存储和计算数仓分层及复用常见的数仓分层： 根底层/ods层数据，个别是通过datasink的技术将oltp零碎中记录的数据、日志等转移到数仓，数据的转移有离线、实时等多种解决计划，具体参考数据时效性要求、数据容量以及解决老本仓库层，以事实表+维度表的形式进行数据的治理，其中的事实表又辨别原子事实表、汇集事实表（di）、累积事实表（df）主题层/应用层，依照业务主题进行数据组织，必要状况会应用宽表进行事实和维度的组合，主题层也会依照剖析的需要进行数据的预聚合，造成一系列的指标表在数据分层设计的时候要确保： 尽量的数据复用，即同层外部确保数据少冗余层之间的边界确定，思考数据的容量、解决的老本、查问的要求等为了晋升数据处理的速度在引擎层面、计算层面也有一些晋升的技术： 引擎层：通过spark进行更疾速的计算（代替MR）；通过flink计算引擎提供实时的数据流解决能力存储层：druid、clickhouse、hbase等kv、列式存储技术在数据查问、剖析场景提供更快的处理速度以上介绍数据仓库的一些基本概念，下一篇咱们介绍如何应用hive sql查问获取数据仓库中的数据。 对于作者：大家好，我是数据展博，致力于在生存和工作中更好的了解数据、利用数据，让数据谈话，用数据赚钱、数据使生存更美妙。

最近233酱其实忙坏了。开发重构一个长达3个多月的我的项目，拉上一个从不加班的小伙伴和我一起天天加班，大略1095 —10105的加班节奏。他说最近根本是在我司两年多来加班最频繁的时候了。 原本这周内咱们终于要上线了，然而因为一个netty的异步回调使用不当的问题，咱们又破费了两天工夫大改大测。当初小伙伴都学会周末拉我加班了。 在这段时间内，周内加班，周末写公众号文章。我的心情简单交变着。有过兴奋，缓和，满足，空虚，欣慰...也有过丧气，烦躁，不安，迷茫，埋怨，惆怅... 我开始思考我做每件事件的目标到底是什么？我为什么情绪越来越容易起伏。我为什么会越来越容易被负面情绪左右着，也可能影响到四周的人。 一件事件做的不好时，我可能当下就意识到了。可当我处在有压力，有情绪的时候，我更容易解决的不好。这不是我想要的。 我自认为本人在一直成长着，也向往着美妙的事物，实质上并不是一个消极的人。这两天我决定整顿一下本人的情绪，从TED等网站寻找一些对于「幸福」的答案。 为了打消一些我灌鸡汤的嫌疑，我会用「粗体」标示出一些有数据和钻研后果撑持的内容。同时也强烈推荐感兴趣的小伙伴观看文末的参考链接，进一步理解以下论断。心愿在你我软弱，烦躁迷茫时能有所启发，共勉之。 如果有人问「你想要什么？」，会有很多答案。具象些的可能是：我想要一个女朋友，我想要一个房子，我想要升职加薪，我想要不加班，我想要不工作，我想要名和利，我想要财产自在... 这些答案的背地是大多数人想要更好的生存，大多数时候咱们很容易认为失去了这些，咱们就能够领有更好的生存。 钻研表明，失去想要的货色确实能让咱们快乐一阵子，但也仅是一阵子。一是因为咱们有弱小的对外界环境的适应能力，二是会接着有下一个具象想要的货色，三是因为决定生存品质的更多是一种心态。 好的生存品质通常意味着「幸福」。可幸福怎么定义？ 幸福生活人根本处在一个踊跃侧面的心态和情绪中，是幸福的。 哈佛大学曾做过一个长达75年的试验，跟踪了724集体的毕生。年复一年，理解他们的工作、家庭生存和健康状况。发现最重要的一点： 良好的人际关系能让人更加高兴和衰弱。对于人际关系有三点： 1.社会关系对咱们是无益的，孤单和寂寞无害衰弱。 2.人群中的孤单也是一种孤单，社会关系的品质才是起作用的。对家庭关系的满意度，有真正密切的好友才是最重要的。 3.良好的婚姻和敌人关系不仅能缓解苍老带来的身材苦楚，还能爱护身心健康。关系融洽并不是指不拌嘴，而是建设在信赖和依赖上。 人际关系的保护不是久而久之的事件，须要一辈子的付出。兴许婚姻不仅只是利益的合作伙伴，而更应该是互相理解反对，爱的共同体。 独身狗小伙伴们懂我在说什么吧。。 顺境生存和压力做敌人**压力不是无害的，用消极的心态去对待压力时，才是无害身心的。当咱们把压力当成一种能源，用踊跃的心态去对待压力时，去口头时，压力无利衰弱。** 软弱的力量当咱们感觉咱们不够好（比方不够苗条，不够丑陋，不够有钱，职位不够高...）的时候，这种 羞耻感，恐怖，对自我价值狐疑 是软弱的起源。没有人能够永远以一种强人的视角回绝软弱。 领有自我价值感的人（敢于去爱并且领有强烈归属感的人），置信他们值得被爱，值得领有归属感。 这些人领有勇气，全然承受本人和别人的软弱，全身心投入生存。 对于幸福的一些修炼习惯提起幸福，可能很多人也会联想到西藏的喇嘛。 佛教中认为幸福是：心田的一种安定和圆满，是一种能把所有心田情感交融进去的心情，包含高兴和悲伤所有的情绪。 人的行为形式和心态是能够修炼的。 修炼心田的形式是以一种踊跃，充斥同情心的心情长时间冥想。 主观察看事物的实质，无我。意识到事物之间的关联性，一直修改心田。 钻研也证实了这种形式即便对成年大脑，也有很大的可塑性。 其实写到这里，阿姨又元气满满了，是TED上这些有趣的心理学家的功绩。再次强推小伙伴们特地是在不开心的时候，享受以下参考视频。 感觉有播种就来关注我吧，我的微信公众号：「码农知识点」 有更多乏味的内容哦～ 参考资料：[1].what_makes_a_good_life_lessons_from_the_longest_study_on_happiness?[2].how_to_make_stress_your_friend?[3].the_power_of_vulnerability[4].the_habits_of_happiness

最近233酱其实忙坏了。开发重构一个长达3个多月的我的项目，拉上一个从不加班的小伙伴和我一起天天加班，大略1095 —10105的加班节奏。他说最近根本是在我司两年多来加班最频繁的时候了。 原本这周内咱们终于要上线了，然而因为一个netty的异步回调使用不当的问题，咱们又破费了两天工夫大改大测。当初小伙伴都学会周末拉我加班了。 在这段时间内，周内加班，周末写公众号文章。我的心情简单交变着。有过兴奋，缓和，满足，空虚，欣慰...也有过丧气，烦躁，不安，迷茫，埋怨，惆怅... 我开始思考我做每件事件的目标到底是什么？我为什么情绪越来越容易起伏。我为什么会越来越容易被负面情绪左右着，也可能影响到四周的人。 一件事件做的不好时，我可能当下就意识到了。可当我处在有压力，有情绪的时候，我更容易解决的不好。这不是我想要的。 我自认为本人在一直成长着，也向往着美妙的事物，实质上并不是一个消极的人。这两天我决定整顿一下本人的情绪，从TED等网站寻找一些对于「幸福」的答案。 为了打消一些我灌鸡汤的嫌疑，我会用「粗体」标示出一些有数据和钻研后果撑持的内容。同时也强烈推荐感兴趣的小伙伴观看文末的参考链接，进一步理解以下论断。心愿在你我软弱，烦躁迷茫时能有所启发，共勉之。 如果有人问「你想要什么？」，会有很多答案。具象些的可能是：我想要一个女朋友，我想要一个房子，我想要升职加薪，我想要不加班，我想要不工作，我想要名和利，我想要财产自在... 这些答案的背地是大多数人想要更好的生存，大多数时候咱们很容易认为失去了这些，咱们就能够领有更好的生存。 钻研表明，失去想要的货色确实能让咱们快乐一阵子，但也仅是一阵子。一是因为咱们有弱小的对外界环境的适应能力，二是会接着有下一个具象想要的货色，三是因为决定生存品质的更多是一种心态。 好的生存品质通常意味着「幸福」。可幸福怎么定义？ 幸福生活人根本处在一个踊跃侧面的心态和情绪中，是幸福的。 哈佛大学曾做过一个长达75年的试验，跟踪了724集体的毕生。年复一年，理解他们的工作、家庭生存和健康状况。发现最重要的一点： 良好的人际关系能让人更加高兴和衰弱。对于人际关系有三点： 1.社会关系对咱们是无益的，孤单和寂寞无害衰弱。 2.人群中的孤单也是一种孤单，社会关系的品质才是起作用的。对家庭关系的满意度，有真正密切的好友才是最重要的。 3.良好的婚姻和敌人关系不仅能缓解苍老带来的身材苦楚，还能爱护身心健康。关系融洽并不是指不拌嘴，而是建设在信赖和依赖上。 人际关系的保护不是久而久之的事件，须要一辈子的付出。兴许婚姻不仅只是利益的合作伙伴，而更应该是互相理解反对，爱的共同体。 独身狗小伙伴们懂我在说什么吧。。 顺境生存和压力做敌人**压力不是无害的，用消极的心态去对待压力时，才是无害身心的。当咱们把压力当成一种能源，用踊跃的心态去对待压力时，去口头时，压力无利衰弱。** 软弱的力量当咱们感觉咱们不够好（比方不够苗条，不够丑陋，不够有钱，职位不够高...）的时候，这种 羞耻感，恐怖，对自我价值狐疑 是软弱的起源。没有人能够永远以一种强人的视角回绝软弱。 领有自我价值感的人（敢于去爱并且领有强烈归属感的人），置信他们值得被爱，值得领有归属感。 这些人领有勇气，全然承受本人和别人的软弱，全身心投入生存。 对于幸福的一些修炼习惯提起幸福，可能很多人也会联想到西藏的喇嘛。 佛教中认为幸福是：心田的一种安定和圆满，是一种能把所有心田情感交融进去的心情，包含高兴和悲伤所有的情绪。 人的行为形式和心态是能够修炼的。 修炼心田的形式是以一种踊跃，充斥同情心的心情长时间冥想。 主观察看事物的实质，无我。意识到事物之间的关联性，一直修改心田。 钻研也证实了这种形式即便对成年大脑，也有很大的可塑性。 其实写到这里，阿姨又元气满满了，是TED上这些有趣的心理学家的功绩。再次强推小伙伴们特地是在不开心的时候，享受以下参考视频。 感觉有播种就来关注我吧，我的微信公众号：「码农知识点」 有更多乏味的内容哦～ 参考资料：[1].what_makes_a_good_life_lessons_from_the_longest_study_on_happiness?[2].how_to_make_stress_your_friend?[3].the_power_of_vulnerability[4].the_habits_of_happiness

导读 IOTA架构是基于IOTA和AI时代背景下的大数据架构模式，其整体技术构造的外围是贯通于整体业务始终的数据模型，具备进步整体的估算效率的作用。IOTA架构这一概念由易观首次提出，并将其利用于最新研发的精细化经营工具中。 在之前文章中介绍过易观提出的IOTA架构，置信很多同学曾经对整体有了一个理解。本文将介绍IOTA架构下的数据采集。 通过上图能够看出，在IOTA架构下，在当下终端设备计算能力一般较强的状况下，SDK不仅承载着以往的根底性能，并且被赋予了边缘计算的角色。例如在设施端就开始做数据完整性和有效性的校验、将用户行为转化成为对立的数据模型，而后传送给服务端。 一个稳固的数据采集端须要有如下性能，存储、回数、管制、爱护。 存储： 数据存储，校验以后存储数据合法性，及避免数据被第三方串改。 回数： 数据上报，加密上报数据，避免被第三方截取，保障不受HOOK等影响，避免DNS净化等。 管制： 管制发送策略，能够指定3G/4G/wifi 环境上传，能够调整上报工夫频次、本地数据缓存规定全副可动静调整。 爱护： 有自爱护机制。不要影响用户的失常应用，缩小因逆向导致的数据异样 不言而喻，一般的采集端都具备这些性能。作为IOTA架构下的采集端进行了哪些优化呢？如下: 对立模型： 在IOTA架构下从数据采集到数据接管以及数据处理都是用一套数据模型。例如对于用户行为剖析时会用到的模型中，咱们能够形象出以下几个基本要素： 产生行为主体 （who），行为产生的工夫(when), 行为的产生地点(where)，发送的事件(what)。在IOTA架构下也统称为Common Data Model。 聚合： 同样的数据进行边缘聚合计算，如某些用户拜访门路能够间接由采集端来实现，生成对应相似漏斗的事件。个别这个计算是服务器下发策略来动态控制的，当然也能够随时做出调整，值得注意的是这是不能够逆的运算，并且这种模式只实用于适宜距离发送模式的数据。 校验： 数据的残缺和有效性能够放到采集端解决，确保SDK给server的数据不是被批改的，产生的数据是正当的，这就要求采集端退出防舞弊的性能。 这是一个成熟产品长期须要投入的我的项目，大部分公司的风控做的也有一部分这样的工作。典型的案例如避免Xposed拦挡，避免反编译，避免二次打包。 实时： 数据实时上报给服务器，这样能力让用户感觉到零提早，实时计算。如12306购票，要立刻的进行查看后果，不能等失去次日才看到后果。同样的带来另一个问题，集体高频上报、用户高峰期大量用户上报须要进行辨别，两者对收数服务器而言是一样的，那这个时候就须要收数服务器和采集端进行通信，动态控制。 高可控： 高可控是对数据采集最根底，也是最重要的一个要求。不然面对攻打，服务器无奈实时监控，动静调整，立刻解决，可能会导致服务器的短时间无奈失常工作(如数据处理提早，重大的乃至宕机)。如图： 当然对于很多大数据架构中，数据采集端各不相同，这也是咱们在反对大量用户后的一个分享。 总的来说，IOTA架构下的数据采集有如下特点：采纳对立的数据模型，反对边缘计算、反对与服务器端动静交互的控制策略。这些曾经在易观的数据产品中宽泛应用，也欢送大家试用易观方舟、易观千帆。

一、依据日期进行增量数据抽取1.页面工作配置关上菜单工作治理页面，抉择增加工作 按下图中5个步骤进行配置 1.工作类型选DataX工作2.辅助参数抉择工夫自增3.增量开始工夫抉择，即sql中查问工夫的开始工夫，用户应用此选项不便第一次的全量同步。第一次同步实现后，该工夫被更新为上一次的工作触发工夫，工作失败不更新。4.增量工夫字段,-DlastTime='%s' -DcurrentTime='%s' 先来解析下这段字符串1.-D是DataX参数的标识符，必配2.-D前面的lastTime和currentTime是DataX json中where条件的工夫字段标识符，必须和json中的变量名称保持一致3.='%s'是我的项目用来去替换工夫的占位符，比配并且格局要完全一致4.留神-DlastTime='%s'和-DcurrentTime='%s'两头有一个空格，空格必须保留并且是一个空格5.工夫格局，能够抉择本人数据库中工夫的格局，也能够通过json中配置sql工夫转换函数来解决留神，留神，留神: 配置肯定要认真看文档（前面咱们也会对这块配置进行优化，防止大家犯错） 2.JSON配置datax.json { "job": { "setting": { "speed": { "channel": 16 } }, "content": [ { "reader": { "name": "mysqlreader", "parameter": { "splitPk": "id", "username": "root", "password": "root", "column": [ "*" ], "connection": [ { "jdbcUrl": [ "jdbc:mysql://localhost:3306/test?characterEncoding=utf8" ],"querySql": [ "select * from test_list where operationDate >= FROM_UNIXTIME(${lastTime}) and operationDate < FROM_UNIXTIME(${currentTime})" ] } ] } }, "writer": { "name": "mysqlwriter", "parameter": { "username": "root", "password": "123456", "column": [ "*" ], "batchSize": "4096", "connection": [ { "jdbcUrl": "jdbc:mysql://localhost:3307/test?characterEncoding=utf8", "table": [ "test_list" ] } ] } } } ] }}querySql解析select * from test_list where operationDate >= ${lastTime} and operationDate < ${currentTime}1.此处的关键点在${lastTime}，${currentTime}，${}是DataX动静参数的固定格局，lastTime，currentTime就是咱们页面配置中-DlastTime='%s' -DcurrentTime='%s'中的lastTime，currentTime，留神字段肯定要统一。 ...

Apache DolphinScheduler 诞生记DolphinScheduler，简称”DS”, 中文名 “小海豚调度”（海豚聪慧、人性化，又左右脑可相互换班，终生不必睡觉）。心愿 DolphinScheduler 就像它的名字一样，成为一个“开箱即用”的灵便易用的调度零碎。 1概述DAG 全称Directed Acyclic Graph，简称DAG。工作流中的Task工作以有向无环图的模式组装起来，从入度为零的节点进行拓扑遍历，直到无后继节点为止。 Apache DolphinScheduler（目前处在孵化阶段）是一个分布式、去中心化、易扩大的可视化DAG工作流任务调度零碎，其致力于解决数据处理流程中盘根错节的依赖关系，使调度零碎在数据处理流程中开箱即用。 DolphinScheduler是2019年开源的一个调度零碎，在去年美国工夫2019年8月29号，分布式任务调度引擎DolphinScheduler（原EasyScheduler）正式通过顶级开源组织Apache基金会的投票决定，以全票通过的优良体现正式成为了Apache孵化器我的项目！ 2背景在2017年，易观在经营本人6.8Pb大小、6.02亿月活、每天近万个调度工作的大数据平台时，受到ETL简单的依赖关系、平台易用性、可维护性及二次开发等方面掣肘，易观的技术团队渴望找到一个具备以下性能的数据调度工具： 易于应用，开发人员能够通过非常简单的拖拽操作构建ETL过程。不仅对于ETL开发人员，无奈编写代码的人也能够应用此工具进行ETL操作，例如系统管理员和分析师；解决“简单工作依赖”问题，并且能够实时监督ETL运行状态；反对多租户；反对许多工作类型：Shell，MR，Spark，Flink，SQL（mysql，postgresql，hive，sparksql，clickhouse等），DataX，Sqoop，Python，Sub_Process，Procedure等；反对HA和线性可扩展性。易观技术团队意识到现有开源我的项目没有可能达到他们要求的，因而决定自行开发这个工具。他们在2017年底设计了DolphinScheduler的次要架构；2018年5月实现第一个外部应用版本，起初又迭代了几个外部版本后，零碎逐步稳定下来。 3特点DolphinScheduler提供了许多易于应用的性能，可放慢数据ETL工作开发流程的效率。其次要特点如下： 通过拖拽以DAG 图的形式将 Task 依照工作的依赖关系关联起来，可实时可视化监控工作的运行状态；反对丰盛的工作类型；反对工作流定时调度、依赖调度、手动调度、手动暂停/进行/复原，同时反对失败重试/告警、从指定节点复原失败、Kill 工作等操作；反对工作流全局参数及节点自定义参数设置；反对集群HA，通过 Zookeeper实现 Master 集群和 Worker 集群去中心化；反对工作流运行历史树形/甘特图展现、反对工作状态统计、流程状态统计；反对补数，并行或串行回填数据。4零碎架构DolphinScheduler 是从数据处理的痛点登程，其解决的问题以及优化的方向次要有以下 5 点： 可视化流程设计加重了开发者配置工作流的复杂度，从繁琐的根底配置中解放出来，不必再靠编程来配置流程，晋升开发效率；扩展性强，在当下这样一个业务变动快、技术迭代频繁的当初，丰盛的工作类型、跨语言和自定义插件机制良好的可扩展性，无疑使这款框架具备了更长的寿命和更宽泛的落地场景；反对工作流定时调度、依赖调度、手动调度、手动暂停 / 进行 / 复原，同时反对失败重试 / 告警、从指定节点复原失败、Kill 工作等操作反对集群 HA，通过 Zookeeper 实现 Master 集群和 Worker 集群的人造去中心化架构设计，使得零碎的高可用性失去保障；通过拖拽以 DAG 图的形式将 Task 依照工作的依赖关系关联起来，可实时可视化监控工作的运行状态，欠缺的服务监控零碎，不便运维人员疾速进行问题定位。目前，IBM、中国安全、美团、360、招商银行、科大讯飞、联通、多点、芒果tv、雪球等多家企业都曾经将 Apache DolphinScheduler 利用到了理论场景中。 1.2.x 架构5开源推动路线万丈高楼平地起，从我的项目启动的那一刻，咱们就确定了开源的指标，从那一刻，开源的种子就种在了每一位我的项目成员的心中，它是一个使命，也是所有人的共识和承诺。 要采纳模块化的设计，这样能力便于开源后的协同开发；要选用开源的技术组件，这样能力便于开源后让更多的开发者参加进来；大道至简，肯定要做到开箱即用，咱们调度的名字就叫EasyScheduler。...就这样，随同着每一位的载歌载舞，激情磅礴和唇枪舌剑，2017年12月在北京市朝阳区恒通商务园B12栋3层办公室里，拉开了EasyScheduler的尾声。 使命必达、争分夺秒，每一位搭档都自动自发、随时待命。 2018年5月，EasyScheduler在易观千帆胜利上线应用。 2019年3月，凋谢给内部种子用户应用，正式公布第一个开源版本1.0.0。 2019年5月，相继推出了1.0.1、1.0.2和1.0.3版本。 开源的种子早已种下，只有破土而出，能力扎根于大地。ASF作为寰球最大的开源基金会，始终致力于开源软件生态的营造，让软件技术可能在寰球共享，这是ASF无比夺目的魅力所在。 咱们要扎根ASF，咱们要进入到寰球最大的开源组织，让咱们的我的项目在寰球共享，于是咱们决定正式摸索Apache开源孵化之路。 这是一个0到1的问题，这是一个须要拿到入场券资格的问题，那么如何才可能进入Apache呢？ 一个我的项目如果心愿进入到Apache孵化器，至多须要1名Champion和2名mentor。所以咱们的第一个难题就是如何找到champion和mentor.ASF孵化器领有导师200多位，然而沉闷的中国导师不超过5位，ALC Beijing也没有成立，咱们只能到处询问，八方求援，经验了无数次的尝试，甚至呈现了一丝丝的波动，然而咱们马上就想到团队每一个人的付出和致力、想到那些默默反对咱们前行的用户、想到一开始就种在咱们心中的开源之梦，咱们深信有信念就肯定有远方，有幻想就肯定有心愿，咱们深信彩虹肯定会呈现，最终咱们幸运地迎来了咱们的champion和mentor。 ...

上篇文章咱们次要介绍了线性数据结构，本篇233酱带大家康康 无所不在的非线性数据结构之一：树形构造的特点和利用。 树形构造，是指：数据元素之间的关系像一颗树的数据结构。咱们看图谈话：它具备以下特点： 每个节点都只有无限个子节点或无子节点；没有父节点的节点称为根节点；每一个非根节点有且只有一个父节点；除了根节点外，每个子节点能够分为多个不相交的子树；树外面没有环路(cycle)维基百科中列举了计算机科学中树形构造的品种233酱当然不会一个个讲，咱们只挑一些相熟的脸孔：多叉树，二叉树，二叉查找树，红黑树，堆，Trie树，B树，B+树，LSM Tree，理解他们在对不同规模的数据 增，删，改，查 时所起到的作用就够了。 限于篇幅，本文次要介绍非LSM Tree的内容。 多叉树树体现了一种 继承 的关系，节点之间为父子关系。多叉树 是指一个父节点能够有多个子节点。也就是：爸爸能够有多个儿子，儿子只能有一个爸爸。当须要这种分层，继承的场景下均能够思考用树结构来实现，能够简化咱们对数据关系的形容。 此外，节点的每个分支也代表着一种抉择，能够用来做决策。 利用场景：1.Linux文件系统2.组织关系示意，如公司的组织架构，角色权限零碎等。3.XML/HTML数据。4.类的继承关系5.决策，如游戏中怪物应用的技能抉择，机器学习...二叉树二叉树（Binary tree）是每个节点最多只有两个分支（即不存在分支度大于2的节点）的树结构，也就是说 爸爸 最多只能有 两个儿子。因为计算机利用中存在很多“非黑即白”的场景，同样咱们能够利用 不是走左分支，就是走右分支 这种构造抉择来做一些决策。另外，利用每个节点下参与方最多为两个，也能够做一些事件。 利用场景：1.编译器的语法树结构。2.表达式求值和判断：非叶子节点为操作符，叶子节点为数值。3.Boolean求值，如（a and b）or (c or d)。4.霍夫曼编码5.IPv4路由表的存储...在咱们的日常开发中，常常须要对数据进行增删改查，每一个步骤的工夫空间效率决定了利用最终的性能。 工夫复杂度 体现在 是否疾速定位到要操作的数据元素，外围在于 索引的好坏； 空间复杂度 体现在 是否占用 更小的内存空间，是否利用计算机各层介质的缓存性能进步访问速度（访问速度：CPU>> 内存>>磁盘）。 在以下树形构造的探讨中，心愿小伙伴能多从 索引，所占用内存空间，操作的介质 这些方面思考数据的增删改查性能。 二叉查找树二叉查找树（Binary Search Tree）首先是二叉树，同时满足肯定的有序性：节点的左子节点比本人小，节点的右子节点比本人大。这样当咱们定位一个元素的地位时，从根节点开始查找，小于节点左拐，大于节点右拐。等于节点排序值就刚好找到。二分的索引思维就体现在其中。 利用场景：二叉查找树的有序性是它可能广泛应用的起因。然而是否高效二分体现在树的高度合理性上。上面要讲的 红黑树/堆构造才是其广泛应用。红黑树二叉查找树的毛病在于：只限度了节点的有序性，但有序树的结构有好坏。一颗“坏”的有序树间接会被拉成 “有序链表”。所以须要通过肯定的条件保障树的平衡性。 树的平衡性是指整棵树的最高子树和最矮子树相差不大，这样整棵树的高度相对来说低一些，相应的增，删，改，查操作的效率较高较稳固（与树高无关）。 红黑树（Red–black tree）是利用很宽泛的一种均衡树，是面试官的装X利器。咱们来看一下它保障平衡性的一些个性： 节点是红色或彩色。根是彩色。所有叶子都是彩色（叶子是NIL节点）。每个红色节点必须有两个彩色的子节点。（从每个叶子到根的所有门路上不能有两个间断的红色节点。）从任一节点到其每个叶子的所有简略门路都蕴含雷同数目的彩色节点。 这些束缚确保了红黑树的要害个性：从根到叶子的最长门路不多于最短门路的两倍长(依据性质4和性质5)。从而整棵树的高度比较稳定，相应的增、删、改、查操作的效率较高较稳固，而不同于一般的二叉查找树。 此外相比其余的均衡树：如高度均衡树AVL树，红黑树的增删改效率较高，同时查找性能没有降落很多也比较稳定。所以工业级利用更为宽泛。 利用场景：适宜排序，查找的场景。1.容器的根本组成，如Java中的HashMap/TreeMap.2.Linux内核的齐全偏心调度器3.Linux中epoll机制的实现...堆堆是一种非凡的数据结构，它满足两个个性： 堆是一个齐全二叉树；堆中每一个节点的排序值都必须大于等于（或小于等于）其左右子节点的排序值。这里解释以下齐全二叉树。它是指：除了最初一层，其余层的节点个数都是满的，最初一层的节点都靠左排列。 这样咱们就能够用数组来存储。 假如根节点在i=0的地位：如果父节点的数组下标为i，则左子节点的数组下标为2 * i+1，右子节点的数组下标为 2 * i + 2。数组比链表的存储益处上篇文章233酱提过了，这里就不赘述了。 针对第2点，如果每个节点的值都大于等于子树中每个节点值的堆，叫做“大顶堆”。反之叫做“小顶堆”。 堆这种构造绝对有序，且堆顶元素要么最小，要么最大。且利用了 数组和本身个性 增删改查的工夫复杂度较低。 ...

近日，易观CTO郭炜在易观A10大会对易观方舟开源体系以及易观方舟智能用户数据中台的架构建设进行了系统地论述，并重磅发表：将易观方舟“不必7天，只用70秒"的可视化埋点SDK全副开源！ ▌ 全新易观方舟智能用户数据中台 现在易观曾经胜利搭建起了“面向业务、凋谢连贯、共享共建”的全新易观方舟智能用户数据中台，反对更多数据接口，提供了更好的扩展性和开放性，企业能够更不便地基于它开发本人的方舟扩大甚至简单利用。 数据获取是易观方舟智能用户数据中台的根底能力之一，当初企业的产品迭代速度越来越快，每天都有新版本，产品与业务人员如何能更快地获取数据也是咱们将要面对的，所以在数据获取方面易观能够提供可视化、全埋点、安卓、IOS，以及六种服务器端的解决方案。 易观CTO郭玮指出，对于从业者来说埋点仍是一个难以攻克的难题： 经营的小伙伴是不是因为数据对不上和工程师面红耳赤？产品的小伙伴是否为发版之后错做一个埋点而追悔莫及？技术的小伙伴在失常研发发版的时候还要加一段埋点代码，还要来回调试，该怎么办？面对这些直击从业者痛点的问题，易观为整个行业提供了一个无效且可行的解决方案：将易观“不必7天，只用70秒"的可视化埋点SDK全副开源！ ▌共建共享，可视化埋点SDK开源 开源意味着什么？正是因为开源的Linux，才有基于Linux的自在及凋谢源代码而产生的Android挪动端操作系统，才有现在曾经更迭到Android 10以及更多改良版本和海量的利用App，才得以建设包含终端厂商和宽广利用开发者在内的凋谢生态，才会有向全人类逐步敞开的挪动设施智能化的大门。 开源意味着共享共建。因为数据利用刚起步，掂量支流的模式还未确定，在这种百花齐放的状态下，用开源模式倒退技术，不仅可能集思广益，与更多行业搭档一起解决行业难题，而且也能集众所长，通过互相分享各自有价值的想法，助推支流模式的造成。 开源意味着信赖关系。不论是公司、开发者或是客户，通过开源的形式更容易建设一种信赖关系，通过开源，可能对消传统的营销形式中单方的不信任感，为单干单方的业务往来提供最根本的保障。 开源意味着数字化。在数字化时代，数字化水平是评判一个企业是否具备外围竞争力的重要指标，开源的价值就在于此，企业除了传统的竞争力以外，应该把本人的外围竞争力建设在自主可控可继续翻新的平台，这是以后企业数字化转型倒退的趋势。 这次开源，是易观以一种凋谢的姿势率领其余开发者和每一个想参加到可视化的行业同仁一起攻克埋点难关的战略性动作。 Pivotal中国公司常务董事和研发体系总经理冯雷：“我理解易观可视化埋点SDK开源的整个过程，它的呈现让相干社群感到喜悦和振奋。” 数知科技、乌镇智库首席科学家陈利人：“易观能必定开源是一种好的形式，对开发者来说是激励。咱们心愿中国有越来越多的公司开源，这是一个漫长的过程，先把边缘的货色缓缓开源进去，最初才有可能整体开源。” ▌凋谢社区：易观方舟Argo社区 间隔易观颁布可视化埋点SDK开源仅仅过来十分钟，由易观方舟打造的Argo社区上，迎来了第一个源代码的贡献者。易观方舟Argo作为一个收费的用户剖析平台及凋谢社区社区由易观于往年3月份推出，正在集结越来越多的产品、经营和技术人才，不仅丰盛和改良了易观方舟的行业性利用，而且鼎力助推了小创企业的数据分析平台建设。 往年9月份易观开源的分布式任务调度引擎Dolphin Scheduler（海豚调度）以全票通过的优良问题胜利进入寰球顶级开源社区Apache基金会孵化器，证实了Dolphin Scheduler在寰球数据调度技术畛域内的先进性。这是国内的Apache社区的第16个我的项目，易观也成为国内继华为、阿里、百度、清华、京东后的第6个奉献方。 过来几个月，易观方舟Argo的社区曾经播种了300+个团队和1000+集体参与者。易观在提供收费用户行为数据分析服务的同时，也吸引了100+个社区的成员奉献各种各样的想法和场景，并且依附这些用户的应用场景进步了易观本身产品的迭代速度。借助易观方舟Argo团队，易观曾经将本来2周公布一个版本的失常麻利的迭代速度晋升到从3月份到当初曾经是150次的迭代速度。 易观一直在践行“让数据能力平民化”这一使命，当初易观方舟Argo的开放性也失去宽广开发者认可，曾经有不少团队基于易观方舟Argo开发出多款利用插件，也示意将收费分享给更多用户，易观也将继续让易观方舟Argo具备更好的凋谢能力。 拥抱开源，共建生态。易观从过来到将来始终都在与各位行业同仁携手共进，攻克行业难关，持续摸索行业倒退新模式。

原文 http://tecdat.cn/?p=1573“明天咱们见证了数据的爆炸式增长：社交媒体数据、零碎数据、CRM数据以及大量网络数据。然而， 在大多数状况下，这些数据通知了咱们用户行为的常见模式。 数据的异样变动可能是咱们零碎中的故障或用户散失的“症结”所在。如何辨认数据陆地中的“暗礁”是用户行为异样行为剖析所要探讨的问题。▼▍什么是异样检测？异样检测是在数据中找到不合乎“失常”的行为模式的过程。在工夫序列数据中检测到与预期行为有偏差的数据对于确保零碎的失常运行十分重要。一般来说，异样能够分成两种：▍全局异样/部分异样部分异样很多时候咱们能够看到数据的潜在趋势，看起来像一个“波浪”：早上的流动有余，白天很高，早晨很低。 部分异样产生在这种状况下。 例如：早晨的高流动意味着异样。全局异样这是咱们最相熟的那种异常现象。 这是一个随机呈现在平时工夫的异常现象。 个别应用95%分位数就能够检测到。▍异样检测办法咱们应用历史数据来构建由每个被监测的数据的估计值。将实时数据与这些值进行比拟，并调配一个分数。基于从最近的数据察看失去的阈值，决定实时数据是否为异样。这种办法的长处是阈值不是动态的，而是实时的。检测场景：tecdat的解决方案从收集网站的行为数据开始。掂量趋势的三个次要组成部分，即固定趋势、周期趋势和季节性数据，别离进行了总结，该算法查找到数据中的异样，向用户发送主动实时警报。通过实时的异样数据监测，咱们能够分明地看到网站流量的差别，在产生异样情况时迅速进行故障排除和修复，缩小网站停机，缩小潜在客户的散失。

简介： 在交通行业中，阿里云不仅具备成熟的方法论和工具，还联结高德、支付宝、阿里达摩院等，形成了一个外部协同生态，内部也踊跃与生态搭档开展单干，全方位浸透交通各个领域和场景，是建设智能计算和催生智能剖析的引擎。 数字经济时代，计算、剖析、解决等作为“要害生产因素”已成为行业和社会的共识。然而对于交通畛域而言，以往端到端的形式进行平台搭建和利用开发已不能适应数字爆炸和产品疾速迭代的要求。交通行业在计算剖析方面面临着信息采集难、款式杂、变动快、价值低、利用难度低等诸多痛点。总结而言，次要体现在4个方面： （1）交通业务零碎互相独立，数据孤岛景象重大，业务解决容量大然而无统一标准，采集的字段凌乱，难以了解和利用？ （2）先前曾经搭建了交通大数据平台，然而不足行业知识库，计算剖析能力弱，数据只是简略地BI展示，不能赋能业务翻新？ （3）业务部门多，资源接口凌乱，复用性差，每次调用计算都须要开发新的接口，费时费力？ （4）数字零散，全域交融难，不足计算价值开掘，并且未和公众服务平台买通，交通相干APP用户量太少，不能从根本上解决“市民出行难”的问题？ 那么，如何用新一代信息技术伎俩买通交通业务之间的内在联系，晋升交通部门的协同效率？如何建成一个交通智能剖析的全流程平台，实现交通系统上云、治理、剖析、决策、后果展示等性能？这是咱们探讨和解决的内容，以更好地撑持交通管理部门晋升效力。 数据中台是交通行业数字化转型的最佳门路 交通体系是一个简单的零碎，笼罩的场景丰盛，关涉的业务宽泛，行政治理关系归口多，不仅有公路、铁路、水运、航空等行业线，执法、车管等职能线，还有区县、市级、省级等区域线。从组织架构上来看，管辖范畴和侧重点不同，计算协同与利用自身就是一个微小的挑战。 如何让纷繁复杂的计算为业务场景服务，为交通治理提效？从以后的技术、业务和实际来看，“数据中台”是应答挑战的最佳门路，它以信息充沛共享、资源高度交融、信息深度开掘、部门协调联动为外围，通过构建一套大数据技术体系和对立的计算资源池，帮忙交通企业疾速推动施行数字化转型策略。 数据中台概念首次被阿里提出时是在2015年, 其定位就是紧贴业务，集方法论、工具、组织于一体的“快、准、全、统、通”的智能体系。历经外部简单场景的实际后,在2018年正式通过阿里云全面对外输入数据中台能力,帮忙企业实现数智化转型。在2020阿里云线上峰会上, 阿里云智能总裁张建锋示意，阿里云将会做深根底，做厚中台，做强生态，有信念真正做好数字经济时代的基础设施。这标记着阿里云进一步把数据中台引入全速重构业务数智化的深地。 从“首次提出”到“全速重构”，阿里云数据中台累积了丰盛的教训。而在交通畛域，数据中台越来越受到重视，交通企业通过构建交通数据中台，能够造成数字资产，对业务方提供高价值、高可靠性、高效率、低成本、少节约的的共享多样计算服务，疾速撑持百花齐放的利用。 阿里云交通数据中台解决方案提供从交通信息接入到计算利用的全链路智能资源构建与治理能力，帮忙交通客户突破信息孤岛、交融全域信息，在把资源对立之后，会疾速造成数据资产、开掘计算价值，进而赋能交通业务，为客户提供高效服务。这些服务跟交通客户的业务有较强的关联性，是交通企业业务和资源的积淀，其不仅能升高反复建设、缩小烟囱式合作的老本，也是差异化竞争劣势所在，助力交通行业数字化转型及智能利用的翻新和推广。 3大次要利用场景：自在流免费稽核、交通态势感知、ETC用户经营 （1）合纠偏，对立路网表白，全量轨迹实时还原，实现最精准、全面、实时的免费稽核后果。 （2）交通态势感知：基于视频、地图和人工录入事变等数据，对路线状况进行实时感知，并对事变进行智能剖析解决。 （3）ETC客户经营：ETC客户数字化经营，与异业协同共赢，共建会员生态，实现体验晋升、穿插销售、协同获客、会员互认、权利互通等服务。 5大外围劣势：数据中台建设+施行的方法论和解决方案 基于长期的最佳实际，阿里云积淀了一整套数据中台建设+施行的方法论和解决方案，该解决方案具备5大外围劣势： （1）对立的数据集成治理：对立集成治理不同起源、格局、特点性质的资源，从而为企业提供全面的资源共享。 （2）高效的内容加工、服务能力：全域计算剖析主题和场景设计，依据应用领域和类别，联合业务流程中的理论痛点和问题，确定剖析洞察主题、相应的剖析场景及外围的剖析维度和指标。 （3）端到端的行业数据安全策略：提供计算辨认、敏感信息发现、信息分类分级、脱敏、拜访监控、危险发现预警与审计能力，进步信息安全等级，便于进行信息权限管控。 （4）提供丰盛的交通行业知识库/模型：通过多年在城市大脑、智慧高速等我的项目上的积攒，再加上对交通信息建模畛域的深入研究，积淀了丰盛的交通算法模型，涵盖交通态势感知、调度优化、仿真预测、免费稽核等多个畛域。 （5）高效的全域信息共享替换：通过全域信息共享替换平台升高交通业务对技术的依赖，晋升交通信息生产体验和效率，充分发挥交通业务翻新潜能，提供交通数据资产变现能力。 5大外围价值：让大数据真正驱动客户业务 （1）开发更简略：中台提供的各种工具产品可能极大的简化开发过程，缩短治理周期，升高治理老本。 （2）服务更便捷：可能赋予数据以业务价值，让各级用户可能直观的了解，并以此为根底向利用输入计算服务。 （3）利用更智能：通过一直晋升数字面向业务的价值，积攒积淀业务模型，可能向下层利用提供更加智能的信息计算。 （4）资产更清晰：从宏观到宏观助力资源管理方全面盘点数据资产，理清策略资源，做到让管理者成竹在胸。 （5）经营更高效：遵循利用后行、以用带存、由存而通、因通促用的理念，实现城市智能化经营，驱动客户业务翻新。 在交通行业中，阿里云不仅具备成熟的方法论和工具，还联结高德、支付宝、阿里达摩院等，形成了一个外部协同生态，内部也踊跃与生态搭档开展单干，全方位浸透交通各个领域和场景，是建设智能计算和催生智能剖析的引擎。 将来，阿里云交通数据中台解决方案将发力高速公路、大中型机场、汽车制造商、大型港口以及城市的市内交通等各个领域，以数据产品+数据技术+方法论+场景实现的综合性输入，构建新一代交通数字化基础设施，推动交通智能化计算、技术极致晋升和智能化业务的翻新摸索，为交通建设及城市倒退注入智能化的新动力。 阿里云智慧交通对立门户正式上线

易观方舟SDK又双叒叕更新了。 此次更新，新增5 个SDK、Android/iOS/JS 全埋点、页面停留时长、APP起源监测以及性能优化等，一直满足客户更多端的数据采集、更个性化的上报策略和更优性能的需要。具体更新如下： 1、新增5个SDK 新增C#SDK，实用于服务端.NET 框架之上的利用；新增 字节跳动小程序SDK，实用于今日头条/头条极速版/抖音/西瓜视频小程序等；新增钉钉小程序SDK，实用于钉钉小程序；新增百度小程序SDK，实用于百度小程序；新增支付宝小程序SDK，实用于支付宝小程序；易观方舟SDK弱小的全段惟一用户买通，目前已反对采集超过22种数字用户触点（易观方舟产品目前除渠道剖析仅反对微信小程序的剖析之外，其余剖析模块均反对新增厂商小程序的剖析）。 2、Android/iOS/JS SDK 新增全埋点 Android/iOS/JS SDK新增全埋点，$user_click，默认敞开，用户可手动关上。作为以后代码埋点和可视化埋点的无效补充，全埋点可能事后采集用户的所有点击行为，缩小工程师的埋点工作量，但同时会有数据量大导致的占用资源多、后续剖析解决繁琐的毛病，所以在利用时依然须要依据客户的理论利用场景来抉择最适宜的埋点形式。 Android/iOS/JS SDK中对全埋点、热图和浏览页面的采集新增黑名单设置。实现更精细化的采集管制，比方热图通常用于剖析着陆页，一些没有剖析需要的页面就能够退出黑名单不采集热图数据，缩小资源占用。3、Android/iOS/JS SDK 新增APP启动起源监测 用户自行设置后，能够检测APP是从桌面图标、点击推送音讯、DeepLink还是其余形式启动。4、JS SDK 新增页面拜访时长插件 反对用户在页面敞开/手动调用pageView时，主动上报敞开页面的事件 $page_close，采集页面停留时长、页面URL、页面题目，在事件剖析中抉择[敞开页面]事件的页面停留时长相干指标，增加页面条件或者细分页面题目，即可剖析单个页面的页面停留时长（停留时长默认采集为毫秒，用户应用时能够通过自定义指标转换单位）。5、其余新增性能 Android、iOS SDK 新增解体检测，$app_crash，默认敞开，用户可手动关上。Android、iOS  SDK 新增setUploadNetworkType 接口。反对用户自行设置发送不同网络状态下的发送规定，比方挪动网络下、Wi-Fi下还是所有网络下都可发送。Android、iOS 新增 $device_id，默认不采集，用于可关上，用于更精准的辨认设施。（Android：AdvertisingID（Google AD 标识）> AndroidID > UUID；iOS：IDFA > IDFV > UUID）Android、iOS 新增接口 cleanDBCache。反对清理用户曾经缓存的所有数据，满足GDPR合规需要。JS SDK 所有API反对执行结束回调函数，解决跳页同时上报数据导致的数据失落问题。Android、iOS 新增推送的自定义参数。Android、iOS、JS SDK 新增获取预置属性的接口 getPresetProperties。客户端 SDK 新增工夫校准配置，用于校准客户端工夫与网络工夫不同步导致剖析时发现异常工夫数据的问题。JS SDK 新增 npm形式集成。各SDK更具体的更新阐明详见Github https://github.com/analysys 各SDK 集成指南详见官网帮忙核心 http://docs.analysys.cn/ark/i... 更多精彩视频，请返回腾讯视频、b站、西瓜视频搜寻「易观方舟SDK」 易观现凋谢《智能用户经营实战手册》下载 扫描下图二维码即可收费获取↓↓↓

讲埋点的文章的那么多，咱们为什么还要写它？首先，这不是一篇纯技术文章，而是从一个非技术人员的角度，心愿通过通俗的语言形容，让大家能疾速理解这些技术概念。此外，目前市面上说埋点的文章，要么没有进行系统性的常识梳理，要么不够主观，存在偏差性，而咱们则心愿让大家透过表象，通过零碎的解说和梳理，从而理解埋点的真正含意。 ▌为什么要专门埋点？ 互联网利用（网站、APP）在研发时往往不会专门记录用户身份和行为数据，也不会蕴含业余的数据分析性能。但有时为了剖析用户产生某些动作或不产生某些动作的深层起因，就须要具体的用户数据进行剖析。这个时候就须要用到业余的用户剖析工具以及埋点了。数据获取是任何一个数据平台的起始动作。对于互联网利用来说，用户行为的捕获及获取是重中之重。如果没有精确、全面的用户身份和行为数据作为输出，在后续剖析中失去精确洞察的可能性就会存在不确定性，营销闭环也会短少过程数据根据，精细化经营更难以发展。 ▌埋点原理 对基于用户行为的数据平台来说，产生在用户界面的，能获取用户信息的触点就是用户数据的间接起源，而建设这些触点的形式就是埋点。当这些触点获取到用户行为、身份数据后，会通过网络传输到服务器端进行后续的解决。埋点从准确性角度思考，分为客户端埋点和服务端埋点。客户端埋点，即客户操作界面中，在客户产生动作时对用户行为进行记录，这些行为只会在客户端产生，不会传输到服务器端；而服务端埋点则通常是在程序和数据库交互的界面进行埋点，这时的埋点会更精确地记录数据的扭转，同时也会减小因为网络传输等起因而带来的不确定性危险。 从剖析的角度登程，数据越精确、越全面就越能达到现实状态；但在理论生产过程中却不得不思考数据获取可行性等问题。因为数据分析工具的最终用户可能是企业外部的各种角色，如工程师、产品经营、市场甚至其余业务人员；大家会在不同工夫，在产品不同的模块中，以不同的规定向产品中注入本人关怀的采集代码。遵循传统形式，常见工作流程如下： 团队外部还会应用一种表格来收集各个团队的埋点需要，而后再交给工程师。如下图： 实际上，即便是赫赫有名的数据分析服务商Mixpanel，在很长一段时间内也只能将这种工作流程作为它所倡议的最佳实际，甚至不得不花篇幅在文档核心提供了几种不同格调的文档，以此帮忙大家相熟这种工作流程。 ▌传统埋点的有余 一遍又一遍的迭代，使行为采集及埋点治理这两个动作形成了这个工作流的一个闭环，但这个闭环却存在几个显著的弊病，因而，它们也是当初理论工作中让大家十分苦恼的中央： 人力成本增加，即须要投入对业务和技术都具备肯定业余程度的人专门负责沟通成本增加，即后期须要同多方合作犯错成本增加，即发现错漏无奈疾速预先补救治理成本增加高，即跨版本后，废点会造成代码垃圾也会影响性能理论工作过程中，局部企业一方面强调数据获取的重要性，另一方面却仍然没有真正把重心投入进来。 对行业从业者来说，数据获取及治理，从来不是一个做到某种程度就够用的问题，而是只有数据业务还在倒退，就要一直通过自行迭代，去摸索更好的获取及治理形式的问题。时至今日，Mixpanel等驰名国外厂商仍然在致力开掘提供更高效、精确的埋点形式；国内的厂商，也还有很大的晋升提高空间。 聊完“埋点”这个大的概念，其细分概念随即呈现，如“无埋点”、“全埋点”、“无痕埋点”、“无码埋点”、“可视化埋点”等等。而站在用户的角度，如果依然对这些概念不甚了解，那么联合业务做好数据采集就难以开展，抉择适宜本人团队和业务的埋点办法也无奈进行...... 上面我将所有可能遇到的埋点形式和它们的名称梳理并做简略解说，须要对你的工作有帮忙。 ▌代码埋点：最可控的埋点形式 代码埋点是最经典的帮忙工程师理解用户是如何应用产品的埋点形式。因为是工程师人工将埋点联合到代码逻辑中，实践上只有是客户端种的操作，再简单也能采集到。常见的如：页面停留时间，页面浏览深度，视频播放时长，用户鼠标轨迹，表单项停留及终止等等。尤其是一些非点击的、不可视的行为，是非要代码埋点来实现不可了。所以如果咱们须要对埋点有更加精准的控制力，那么代码埋点是最好的抉择。 兴许你还分不清集成和埋点。为了进行埋点，厂商通常都提供一个代码包，能够了解为一个工具包，外面蕴含罕用的工具。想埋点就要先有这个工具包，也就是集成SDK。而后依据外面的说明书，再应用这个工具包制作出各种货色，也就是埋点了。当然弊病也是很显著的，前文说形容的那些苦恼简直全是代码埋点相干的。为了能让埋点过程更高效，厂商们做了很多致力。 ▌全埋点：让我欢喜让我忧 全埋点，一些国内的团队也称“无埋点”、“无痕埋点”以及“主动埋点”。是一种对全自动的埋点形式的摸索，而且从名字看好像是个一劳永逸的解决方案，那咱们先看看什么是“全埋点”。 客户端埋点个别分为拜访级、页面级、页内行为级。用户拜访一个网站或启动一个挪动利用时简直所有的厂商都会主动采集上报用户的拜访；当用户拜访不同页面时，有一部分厂商就会抉择不默认主动采集，而将其作为一个选项交给用户；而对于用户在某一个页面内具体的操作行为，只有极少数厂商反对主动采集上报。实现了后两种主动采集的厂商，通常会说本人是全埋点。但页内行为级的采集也还能够进一步探讨其采集的范畴。最常见的就是主动采集可交互元素和主动采集所有元素的差异。 可交互元素蕴含：链接、表单项（如按钮、输入框等）、HTML 的对象级元素等。不可交互元素就太多了，绝大多数的页面元素都属于此类。因为实际上网页和挪动利用中的大家能够看失去的界面很多都并不是规范元素，所以实际上界面上很多看似可交互的元素也都是无奈主动采集上报的。这一点不可不谓之遗憾。 不过咱们还是来看看长处。 首先，全埋点的确会主动采集十分多的数据，而且将来在应用数据的时候就能够从数据库中间接查问，不会面临我想看的时候因为没有埋点采集而获取不到的状况。这是十分受分析师青睐的形式，因而常常会听到“能采集就尽量都采集，后续剖析总能用失去”。其次，埋点是比拟耗时的工作，须要业务方提供计划，工程师进行埋点，测试团队进行测试。而因为理论工作中埋点数量比拟多，每次公布新性能或新流动都须要新的埋点，所以埋点岂但费时，而且错误率也难以管制。有了全埋点，数据用不必都先发出来，因为都是程序主动实现，业务人员想要A 而工程师埋成B 这种谬误也简直不存在。 然而任何事务都有它的两面性。 首先，全埋点的“全”并非真的全副。根本的电脑浏览器和挪动利用中页面内常见的用户操作包含鼠标行为、键盘行为和手指行为。例如网页端常见的鼠标点击、鼠标滑动、屏幕滚动、键盘录入、光标选取甚至静止等，挪动端除了相似点击的按下，还有多指开合、拉动、使劲按下等等行为。但这些操作并不会都被“埋点”，能埋点的通常仅限点击或者按下，这显然是远远不够的，甚至咱们都不能称之为全埋点。 其次，全埋点的“全”以采集上报的数据量为代价，随着数据量回升导致客户端解体的概率也会回升。尤其是挪动端，更多的数据量意味着更多的电量、流量和内存耗费。从这个角度来看，想做到真正的“全”在现阶段也是很难。 第三，即便全副行为数据能够被接管回来，具体分析时的二次梳理和加工也无奈防止，甚至苦楚。因为机器无奈在采集时能依照咱们想要的形式对全副事件进行有意义的命名，甚至无奈保障采集上来的事件都正好是正确的。于是后期埋点时节省下来的人力老本，这个时候又都搭进去了。 第四，现阶段全埋点对于用户身份信息和行为附带的属性信息也简直无能为力。 那么这个性能到底是我须要的吗？这其实是个度的问题。对于这个问题，只能说得联合你理论状况，如果你更须要随机摸索过来点击行为的趋势，那么这个性能就还适合，否则还有更好的抉择。 ▌可视化埋点：一种所见即所得的埋点形式 代码埋点和全埋点并没有在易用性和准确性方面达到均衡。可视化埋点，很多时候也被称为“无码埋点”。前文提到，代码埋点的毛病对于网站还好，但对于挪动利用来讲无疑是分外低效的。为了解决这个问题，在一部分厂商抉择全埋点的同时也有大量厂商抉择了一种所见即所得埋点的路线，即可视化埋点。 可视化埋点的益处是能够间接在网站或挪动利用的实在界面上操作埋点，而且埋点之后立刻能够验证埋点是否正确，这还不算完，将埋点部署到所有客户端也是简直实时失效的。因为可视化埋点的这些益处，剖析的需求方，业务人员，没有权限触碰代码或者不懂得编程的人都能够非常低的门槛获取到用于剖析的数据。堪称是埋点的一大提高。 可视化埋点的部署原理反对可视化埋点的SDK 会在被监测的网站或挪动利用被拜访时向服务器校验是否有新的埋点，如果发现更新的埋点，则会从服务器下载并且立刻失效。这样就能确保服务器收到最新的埋点后，所有客户端都能在下一次拜访时失去部署了。 可视化埋点和全埋点有着对埋点和剖析全然不同的谋求。可视化埋点的理念是晋升原工作流程的效率——仍然要梳理需要、设计埋点；全埋点则是将工作流都进行了简化——反正数据会被采集回来，这两步的必要性就容易被忽视。这里不能说孰优孰略，因为当时谨严的打算和预先发散的摸索都是剖析中的不同角度。况且这两种埋点也齐全不是排他的，齐全能够同时应用。 可视化埋点局限性也很多。 首先，可视化埋点也只是针对点击可见元素的，其中可见元素最常见的就是点击行为了。对于点击操作的埋点也的确是目前可视化埋点的主攻点。但从理论状况看，简单页面、不规范页面、动静页面都给可视化埋点减少不可用的危险，一旦遇到就还是只能代码埋点了。 其次，对于点击操作附带的业务属性，尽管也可通过进一步选取属性所在元素来获取属性信息，但国内厂商反对得好的就比拟少了。 第三，为了确保埋点准确性，可视化埋点也逐渐整合了更为简单的高级设置，例如：“同页面”、“同版本”、“同层级”、“同文本”……，加上了这些简单设置的可视化埋点也是那个为提效而生的可视化埋点吗？ ▌标签管理器（Tag manager）：低调的高手 大家可能对标签比拟生疏，但用于采集网页数据的SDK 大家曾经不生疏，这些嵌入到网页中，能采集网页上、挪动利用或者视频中的数据的，就是监测类的标签。但标签的用处远不止于此，通过在网站中嵌入代码，工程师能够对网站提供很多额定的能力。除了刚刚提到的数据监测，还可能为网站提供一些额定的性能，最常见的就是推送个性化的内容，例如：A/B 测试，音讯推送，个性化广告等等。 如果网站或者挪动利用借助标签的能力实现很多性能，那么就须要用到很多标签，而且标签可能也须要频繁更新或改变。同样网页还好，上线很容易，但挪动利用可就难了，如果再呈现了错漏，改过就要面临十分长的改过周期。这种状况下，标签管理器就派上了用场。 标签管理器提供了一个容器，工程师只须要在网页或挪动利用中正确嵌入这个容器，之后不懂技术的团队也能通过在线治理的形式将后续各种标签公布到网页或挪动利用中。这样就实现了技术人员和业务人员工作的各自为战。听起来是不是跟可视化埋点很像？是的，他们的原理是简直截然不同的。只不过可视化埋点更偏向于针对客户端的用户点击行为提供了直观的办法，而标签管理器是代码层面的，能做的事件会更多一些。 标签管理器十分弱小的中央在于能免去代码埋点而通过DataLayer 就能获取到页面中的变量，如每个用户不同的用户ID、用户等级、登录状态、购买的产品的名称以及价格等；而通过触发器能在这些变量合乎肯定的时才触发事件的上报。是不是十分厉害！目前最驰名的标签管理器是谷歌推出Google Tag manager，简称GTM，占据了83% 的份额。个人版是收费的，但仍然提供了极其弱小的性能，个别团队用都足够了。想进一步地理解GTM 的性能，能够浏览它的官网，外面有十分丰盛的解说和案例。 综上，目前客户端中对用户数据的获取并不存在既简略又万能的解决方案，大家应该在适合的场景抉择相应的埋点形式，均衡老本和收益来进行。好在当初厂商也基本上都反对以上多种客户端行为采集形式。将来，对于客户端埋点来说，整合了标签管理器的某些个性的可视化埋点肯定能更多地代替代码埋点，解决工作中常见的所有客户端行为采集需要。 就像晚期论坛的编辑框，只能通过公布或者预览性能能力看到帖子的成果，但起初所见即所得的编辑器呈现使得文字的编辑变得十分高效和愉悦。目前开源社区风行的Markdown 格局仍然沿用了这种形式，在诸多风行的Markdown 编辑器中，仍然是一侧编辑、一侧实时预览，或间接就以最终格局的形式来编辑。随着IoT 时代的带来，越来越多的用户界面会呈现在电脑和手机之外，越来越多的内容是因人而异的。届时，将来越来越多的SDK 集成后会主动采集更多规范的用户行为，而对于非标准以及业务含意强的，须要计算的，或者须要依照特定条件失效的埋点，则能够交给可视化埋点来实现。但目前这个阶段，最好的组合恐怕还是GTM 联合可视化埋点来实现吧。 ...

简介： 近几年里，大数据行业发展势头迅猛，故而相应的分布式产品和架构层出不穷，本文分享作者在大数据系统实际过程中接触过的一些工具及应用感触，抛砖引玉，和同学们一起构建一个分布式产品的全景图。 下图是由驰名的数据观察家Matt Turck在他的BLOG（https://mattturck.com/） 里收回的2019年人工智能和大数据产业图，他从2012年开始每年都会绘制一张，大抵形容这个产业里的公司及其数据相干的产品，以及所属问题的畛域。这外面大部分是商业软件，而对于绝大多数互联网公司，两头绿色的开源产品可能大家接触的更多一些，而这些产品里，绝大多数都属于Apache基金会。 上面我从中筛选一些货色轻易聊聊，因为是轻易聊聊，所以知识点并不全，也不能帮忙大家晓得如何搭建和应用，以及如何避坑，只是谈谈我对这些货色的印象，形容一个大略的轮廓，如有应用需要能够搜寻网上其它文章，材料还是很多的。当然，大家对其中的内容有趣味能够随时找我交换探讨，对文中如有形容谬误的中央也欢送大家斧正，独特学习，谢谢。 Apache Hadoop官网：http://hadoop.apache.org/ Hadoop我的项目下蕴含了很多子项目，从计算到存储都有，比方HDFS、MapReduce、YARN、HBase。 HDFS全称叫做Hadoop分布式文件系统，其次要由一个NameNode(NN)和多个DataNode(DN)组成，数据文件会分成多个Block，这些Block依照不同主机，不同机架的策略以默认一备三的状况散布存储在各个节点。当初每个Block大小默认是128MB，当前随着磁盘寻址速度的减少，这个Block也会一直增大。而NN外面则存储了这些Block元数据的信息，这样客户端进行数据查问的时候，DN告知所需数据的地位。从这种构造上能看出一些比拟显著的问题就是NN节点的单点问题，所以在Hadoop 2.x的时候，针对NN做了一些改良。 首先是在零碎可用性上，减少了一个StandBy状态的NN，作为服务中NN（Active NN）的备机，当服务中的NN挂掉后，由StandBy的NN主动接替工作。而NN节点状态的衰弱和服务切换，由ZKFC负责。主备NN之间的信息同步则由Quorum Journal Node负责。 其次，因为单台NN中存储了大量的元数据信息，所以随着HDFS数据量的一直减少，显然NN必将成为零碎的瓶颈，为了解决这个问题，Hadoop 2.x减少了Federation，该技术容许零碎中有多台NN同时对外提供服务，这多台NN将DN中的所有文件门路进行了横向拆分，每个DN负责不同的门路，达到了横向扩大的成果。 除了HDFS，Hadoop 2.x也引入了YARN，该工具负责对集群中的资源进行治理和工作的协调。该工具分成一个ResourceManager(RM)和多个NodeManager(NM)，当一个工作提交给YARN之后，会先在某一服务器上启动一个ApplicationMaster(AM)，AM向RM申请资源，RM通过NM寻找集群中闲暇的资源，NM将资源打包成一个个Container，交给AM。AM将数据和程序散发到对应节点上解决，如果某个Container中的工作执行失败了，AM会从新向RM申请新的Container。 Apache Hadoop HBase & Kudu官网：http://hbase.apache.org/ 家喻户晓，HBase一个分布式列式存储系统，同样属于Hadoop的子项目，列式存储的优劣在这里不说了，提一下HBase的WAL和LSM，WAL全称为Write Ahead Log，只是在数据批改操作前，会先将此操作记录在日志中，这样一旦服务解体，通过该日志即可进行数据的复原，提到这里有些人就会联想到MySQL，因为InnoDB引擎的redo log就是典型的WAL利用。而在HBase中该性能是由叫做HLog的模块所实现的。再说LSM，其全称为Log Structured Merge Trees，介绍原理的文章也有很多，在HBase中，LSM树是MemStore模块的底层存储构造，而MemStore有三个作用，一是当有数据写入的时候，间接写到MemStore中，从而晋升写数据的效率。二是充当读取数据时的缓存。三是定期对数据操作去重，并进行数据落盘。HBase的次要角色别离有HMaster和HRegionServer，同样是一对多的关系，而各节点的状态全都交由Zookeeper负责。Kudu是一个和HBase十分相似的产品，其不同之处在于Kudu不依赖Zookeeper来治理本人的集群，并且HBase的数据是保留在HDFS上的，而Kudu领有本人的数据文件格式。 Apache Spark官网：https://spark.apache.org/ Spark是由加州大学伯克利分校推出的分布式计算引擎，在Spark的官方主页上有一张和Hadoop的性能比照图，权且不谈这张图中数据的准确性，然而Spark确实将Hadoop（次要是指MapReduce）的性能晋升了一个量级。我了解这次要得益于两个方面：第一个是Spark计算过程中生成的两头数据不再落盘，没有了Spill的阶段。第二个是引入DAG对工作进行拆解，一个残缺的Job被分成多个Stage，每个Stage外面又有多个Task，通过一张有向无环图，使得没有依赖关系的Task能够并行运行。 Spark不只是在批处理上有所问题，而是更加重视整个生态圈的建设，其领有流式解决框架SparkStreaming，采纳微批的模式达到相似流解决的成果，当初又推出了Structured Streaming，实现基于状态的流解决框架。此外还领有SparkSQL来帮忙非开发人员更加便捷的调用Spark的服务和Spark MLlib这个机器学习库。 Spark虽好，但其对内存资源耗费也很大，同时也使得他在稳定性上不如MapReduce，所以有些大公司数仓的日常工作仍旧采纳传统MapReduce的形式执行，不求最快，但求最稳。咱们的零碎在刚从MapReduce上切到Spark时，每天夜里也是工作异样频发，最初调整了工作和资源分配，再加上一个很粗犷的重试机制解决了。 Apache Flink官网：https://flink.apache.org/ Flink是德国Data Artisans公司开发一款分布式计算零碎，该公司于19年初被阿里巴巴团体收买。包含Spark和Kafka，也都看到了将来流式计算的前景是十分微小的，纷纷建设属于本人的流式计算生态圈。 Flink和Spark Streaming相比，前者是真正的流式计算，而后者是微批处理，尽管批次足够小，但其本质毕竟还是批处理，这就导致有些场景SparkStreaming注定无奈满足，尽管Spark当初将重心转移到了Structured Streaming，它补救了Spark Streaming很多的有余，然而在解决流程上依然是微批处理。 而Flink在设计之初就同时思考了批处理和流解决这两种需要，所以使用者也能够只通过一个计算引擎，就能实现批处理和流解决两种计算场景，其次要几个须要分明的个性我感觉别离是：State状态治理，CheckPoint容错机制，Window滑动窗口，和Watermark乱序解决。这些内容网上都有很多介绍，不再论述。 Apache Impala官网：https://impala.apache.org/ Impala是Cloudera公司用C++开发的反对SQL语义的查问零碎，能够用来查问HDFS、HBase、Kudu的内容，也反对多种序列化和压缩格局，因为也是基于内存的计算，比传统MapReduce快很多。不过因为曾经应用了Spark，所以组里并没有对Impala进行大规模的利用。通过一些零散的调研和理解，如同其它公司对Impala的利用也不是十分多。 Apache Zookeeper官网：https://zookeeper.apache.org/ Zookeeper无论在数据系统还是在其它后端系统的应用场景都十分广，它能够用作分布式锁服务，能够用做零碎的配置核心，能够帮助实现一致性算法的选主过程，能够用于ZKFC做节点衰弱状况的探查，总之用途还有很多。而它的工作机制，根本就是ZAB协定的机制，一个反对解体复原的原子播送协定，其次要组成也是由一个Leader和多个Follower组成的，数据的提交遵循2PC协定。当Leader解体时，Follower会主动切换状态开始从新选主，从新选完之后再进行多节点的数据对齐。 Apache Sqoop官网：https://sqoop.apache.org/ 一款用于在传统关系型数据库和HDFS之间相互进行数据传递的工具，无论是import还是export都提供了大量的参数，因为是分布式执行，数据传输的速度也十分快。只是在应用的过程中须要留神数据源中的异样数据，会比拟容易造成数据传递过程中的异样退出。为了补救Sqoop的性能繁多，推出了Sqoop 2，架构上比Sqoop 1简单了很多，不过我没有用过。 Apache Flume官网：http://flume.apache.org/ 分布式数据传输工具，反对蕴含文件、Netcat、JMS、HTTP在内的多种数据源。其构造上分成Source、Channel、Sink三局部，Source将获取到的数据缓存在Channel中，这个Channel能够是文件，能够是内存，也能够应用JDBC，Sink从Channel生产数据，传递给零碎中的其余模块，比方HBase、HDFS、Kafka等等。 ...

近来有小伙伴问我：刷leetcode真的有用吗，感觉收益很小，越刷越迷茫了... 诚然每个人刷题的目标不一样，233酱还不是为了能水几篇文章... 当然不止。我感觉刷题是一件有意思的事，就像小猫小狗咬本人尾巴，捉弄的不可开交。比喻可能不太失当，是有种沉迷小游戏的感觉。可是在艰巨打野的过程中，咱们不要忘了，最重要的是：理解每种技能包的特点，适宜解决的问题和场景。在特定实战场景下可能应用特定的技能包，借鉴技能包。这才是文治的至高境界。 装X完结，浅谈开始。。 数据结构是指：一种数据组织、治理和存储的格局，它能够帮忙咱们实现对数据高效的拜访和批改。 数据结构 = 数据元素 + 元素之间的构造。 如果说数据结构是造大楼的骨架，算法就是具体的造楼流程。流程不同，效率资源不同。我会两者联合简略探讨下他们的特点和利用。 常见的数据结构可分为：线性构造、树形构造 和 图状构造。 常见的算法有：递归、排序、二分查找、搜寻、哈希算法、贪婪算法、分治算法、回溯算法、动静布局、字符串匹配算法等。 本文从 线性数据结构、递归 和 排序算法 谈起。 线性构造线性构造：是指数据排成像一条线一样的构造。每个元素结点最多对应一个前驱结点和一个后继结点。如数组, 链表，栈 ，队列等。 数组数组是是由雷同类型的元素（element）的汇合所组成的数据结构，调配一块间断的内存来存储。利用元素的下标地位能够计算出该元素对应的存储地址。 长处：调配基于间断内存，是一种天生的索引构造，查问批改元素的效率O(1)。同时能够借助 CPU 的缓存机制，预读数组中的数据，所以拜访效率更高。 毛病：数组的索引长处也是它的毛病，因为它的索引是基于一块间断内存元素存储的地位下标决定的，增删arr[i]工夫复杂度O(n)，须要整体挪动数组arr[i-n-1]的地位。此外，调配大数组会占用较大的内存。 可通过以下形式防止元素拷贝和占用大的开销： 1.懒删除：删除时只标记元素被删除，并不真正的执行删除。当数组整体内存不够用时，再执行真正的删除。2.分块思维：将一大块内存分为n个小块，以 小块 为单位进行数组内存的拷贝。如Mysql的InnoDB引擎中每个Buffer Pool实例由若干个chunk组成，理论内存申请操作以chunk为单位。3.缩容：已经面试阿里时，就让设计了一个缩容版的HashMap。节约可耻，节约光彩。4.链表。 链表链表的存在就是为了解决数组的增删简单耗时，内存占用较大的问题。它并不需要一块间断的内存空间，它通过 指针 将一组零散的内存块串联起来。依据指针的不同，有单链表，双向链表，循环链表之分。 长处：增删arr[i]工夫复杂度O(1)，应用链表自身没有大小的限度，人造地反对动静扩容。 毛病：没有“索引”，查问工夫复杂度O(n)。须要保护指针，更占内存。同时内存不间断，容易造成内存碎片。 能够看出：数组和链表是互相补充的一对数据结构。那怎么补救链表的有余呢？ 内存这块是不好解决，这是由 指针 决定的。对于索引，没索引就帮它建索引好了： 1.联合hash表，记录链表每个结点的地位。2.链表长度拉的过长时，思考跳表，红黑树这类数据结构。（别慌，前面会讲～） 利用场景：数组和链表的使用很宽泛，他们是形成 数据结构的根底。如栈，队列，汇合等等。栈栈是一种受限制的线性数据结构。元素只能够在栈顶被拜访。 合乎先进后出的First-In-Last-Out的拜访形式。 用数组实现的叫程序栈，用链表实现的叫链式栈。可能有人会有疑难：我用数组链表在头尾两端可伸可缩，为毛要用只能在头部操作的栈构造呢？这种FILO的构造当然是只实用于FILO的场景。如果咱们将数组/链表这种构造封装为栈，就能够只应用其pop/push的API，屏蔽掉实现细节。 利用场景：1.编辑器的redo/undo操作。2.浏览器的后退/后退操作。3.编译器的括号匹配校验4.数学计算中的表达式求值5.函数调用6.递归7.字符串反转...队列队列也是一种受限制的线性数据结构。 合乎先进先出的First-In-First-Out 的拜访形式。同样，用数组实现的队列叫作程序队列，用链表实现的队列叫作链式队列。 依据头尾指针和操作的不同，队列又可分为双端队列，循环队列，阻塞队列，并发队列。 双端队列：头尾均能够进行插入，删除，拜访元素，更为实用。不存在FIFO这种限度。 循环队列：把队列的头尾相连接并且应用顺序存储构造进行数据存储的队列。 存在并发的场景下，队列存取元素的临界区为 队列空时的取操作 和 队列满时的存操作。保障并发下的队列存取平安为阻塞队列 和 并发队列。两者的区别在于 同步资源的粒度不同。 阻塞队列：通过 互斥锁 保障enqueue、dequeue的平安，锁粒度较大。如Java JUC包中的阻塞队列。并发队列：基于数组的循环队列，利用 CAS 原子操作保障enqueue、dequeue的平安。其实就是通过：屡次volatile读 + CAS操作 这种乐观思维 批改头尾指针的地位，保障enqueue、dequeue的平安。CAS的同步代价小较小，所以称为：无锁并发队列。如Disruptor框架中Ring Buffer就使用了这点。PS: 很多框架对线程池的需要都替换成了Disruptor来实现，如Log4j2、Canal等。利用场景：队列的作用其实就是事实中的排队。当资源有余时，通过“队列” 这种构造来实现排队的成果。用于：1.任务调度存在的中央：CPU/磁盘/线程池/任务调度框架...2.两个过程中数据的传递：如pipe/file IO/IO Buffer...3.生产者消费者场景中..4.LRU ...

流动背景2020年，大数据成为国家基建的一个重要组成，大数据在越来越多的畛域展示威力。随着大数据的利用场景越来越多，大家对数据的响应速度和数据加工工作流的不便水平也提出了更高的要求。在这种背景下，置信做过大数据的技术小伙伴应该对 Apache 一词不会生疏，Apache 基金会旗下领有被宽泛应用的泛滥开源软件，本次顺便邀请到 2 个外乡的 Apache 大数据利用我的项目的开发者来一起分享解决数据响应速度和数据工作流任务调度方面的开源技术，一起为中国开源献力。 Apache Doris(Incubating)是一个现代化的 MPP 剖析型数据库产品。仅需亚秒级响应工夫即可取得查问后果，无效地反对实时数据分析。Apache Doris 的分布式架构十分简洁，易于运维，并且能够反对 10PB 以上的超大数据集。 Apache DolphinScheduler(Incubating) 是一个分布式去中心化，易扩大的可视化工作流任务调度零碎。致力于解决数据处理流程中盘根错节的依赖关系，使调度零碎在大数据处理流程中开箱即用。 流动工夫工夫：2020-07-25 14:00 面向人群：对开源技术感兴趣的小伙伴均可参加 议程安顿14:00 - 14:40 Introduction of Doris core features - pre-aggregation engine and materialized view 《Doris外围性能介绍--预聚合引擎和物化视图》 缪翎，百度研发工程师，Doris PPMC14:40 - 15:10 Distributed task management platform, making job submit easier 《分布式作业管理平台，让作业提交变得更简略》 李杰，奇安信大数据研发工程师，次要参加DolphinScheduler和Flink的开发与保护15:10 - 15:50 Doris global dictionary design and implementation based on hive table 《Doris基于hive表的全局字典设计与实现 》 王博，美团点评数据开发工程师，次要参加Doris和Kylin的开发与保护15:50 - 16:30 DolphinScheduler architecture evolution journey ...

在应用eventTime的时候如何解决乱序数据？咱们晓得，流解决从事件产生，到流经source，再到operator，两头是有一个过程和工夫的。尽管大部分状况下，流到operator的数据都是依照事件产生的工夫程序来的，然而也不排除因为网络提早等起因，导致乱序的产生，特地是应用kafka的话，多个分区的数据无奈保障有序。所以在进行window计算的时候，咱们又不能无限期的等上来，必须要有个机制来保障一个特定的工夫后，必须触发window去进行计算了。这个特地的机制，就是watermark。Watermark是用于解决乱序事件的，用于掂量Event Time停顿的机制。watermark能够翻译为水位线。 一、Watermark的外围原理Watermark的外围实质能够了解成一个提早触发机制。 在 Flink 的窗口处理过程中，如果确定全副数据达到，就能够对 Window 的所有数据做 窗口计算操作（如汇总、分组等），如果数据没有全副达到，则持续期待该窗口中的数据全 部达到才开始解决。这种状况下就须要用到水位线（WaterMarks）机制，它可能掂量数据处 理进度（表白数据达到的完整性），保障事件数据（全副）达到 Flink 零碎，或者在乱序及 提早达到时，也可能像预期一样计算出正确并且间断的后果。当任何 Event 进入到 Flink 零碎时，会依据以后最大事件工夫产生 Watermarks 工夫戳。 那么 Flink 是怎么计算 Watermak 的值呢？ Watermark =进入Flink 的最大的事件工夫(mxtEventTime)-指定的延迟时间(t) 那么有 Watermark 的 Window 是怎么触发窗口函数的呢？ 如果有窗口的进行工夫等于或者小于 maxEventTime - t(过后的warkmark)，那么这个窗口被触发执行。 其外围解决流程如下图所示。 二、Watermark的三种应用状况1、原本有序的Stream中的 Watermark如果数据元素的事件工夫是有序的，Watermark 工夫戳会随着数据元素的事件工夫按顺 序生成，此时水位线的变动和事件工夫放弃始终（因为既然是有序的工夫，就不须要设置提早了，那么t就是 0。所以 watermark=maxtime-0 = maxtime），也就是现实状态下的水位 线。当 Watermark 工夫大于 Windows 完结工夫就会触发对 Windows 的数据计算，以此类推， 下一个 Window 也是一样。这种状况其实是乱序数据的一种非凡状况。 2、乱序事件中的Watermark现实情况下数据元素往往并不是依照其产生程序接入到 Flink 零碎中进行解决，而频繁 呈现乱序或早退的状况，这种状况就须要应用 Watermarks 来应答。比方下图，设置延迟时间t为2。 3、并行数据流中的Watermark在多并行度的状况下，Watermark 会有一个对齐机制，这个对齐机制会取所有 Channel 中最小的 Watermark。 ...

作者：友盟+数据科学家 杨玉莲 人群细分是数据分析师们进行用户经营最罕用的数据分析办法之一。通过人群细分，能够疾速理解产品的外围受众，进而得出洞察论断，领导优化经营策略。很多时候，人群细分之后，剖析人员还会进一步剖析不同人群在产品外围指标下面的体现差别，从而发现问题并进行优化。 从技术视角，用户分群的形式次要有两种：基于规定的分群办法 （Rule-based Segmentation）和基于算法的分群办法（ML-based Segmentation）。前者次要实用于业务规定确定，分群采纳的用户特色维度繁多的场景，而后者次要用于用户特色维度高，人工无奈设定正当分群规定的场景。 从业务视角，分析师或者经营人员须要思考的更多是要基于哪些特色维度来对用户进行分群。这往往跟要剖析的问题非亲非故。常见的用户分群维度包含如下几种： · 基于人口属性的用户分群 · 基于地区属性的用户分群 · 基于渠道起源的用户分群 · 基于用户生命周期的分群 然而，在理论利用中，咱们也常常通过用户应用的设施品牌，机型，用户应用产品的版本，在产品中的高频行为来对用户进行分群。 以基于人口属性的用户分群办法为例，咱们次要思考用户的年龄，性别，学历，职业，支出，婚育状态等属性。这些信息能够在用户第一次进入产品页面时或者通过在线问卷调查的形式收集。但随着用户的集体信息安全意识越来越强，通过产品页面或问卷调查收集的用户信息存在不准确甚至缺失的问题。这时候，就须要通过数据挖掘的伎俩对用户的人口属性信息进行预测。以性别预测为例，根本的操作步骤如下：! 其中特色加工阶段抉择什么样的特色来建模，决定了最终模型预测成果的下限。比方，对于性别预测来讲，观看视频的行为特色根本是没用的，但浏览了美妆页面的行为就是一个十分有用的特色。有了用户的人口属性，最常见的人群细分伎俩是基于人群属性的某一个维度，比方年龄段，进行准确的人群切分（下图）。 然而基于一维属性的人群细分有一个十分大的毛病：无奈看到平面的用户分群状况。于是咱们有了基于二维属性的人群细分办法。针对属性的不同取值类型 - 离散型和连续型，人群的细分办法会有所不同。对于离散型的属性，能够间接通过属性值组合的形式进行人群细分，如下图一，通过性别和生命周期阶段能够将人群分为8个子群，咱们能够看到次要的人群集中在沉闷人群和新增女性，同时男性转化与散失人群占比也较高；对于连续型的属性，则需选定每个维度的切分点，而后在二维立体上将人群切成对应的不同分组。以下图二为例，能够看到人群大部分都集中在二维立体的第一象限，在其余象限别离有一个离散的点。! 基于二维属性的人群细分办法实质上是基于一维属性的人群细分办法的扩大。以此类推，咱们也有基于三维 属性的人群细分办法，大家耳熟能详的RFM人群分层模型就是属于这一类。 以上介绍的人群细分办法，在人群属性值比拟多或者维度较高的状况下，可扩展性会受到重大挑战。设想一下，人群的属性有N维，假如每一维有两个离散的取值，如果咱们依照这些取值的组合对人群做细分，就会有2的N次方个用户群体。随着N的减少，人群数也会指数级地增长，最终人群细分就会变成超级细分，细分的后果也就很难剖析出有价值的洞见。在这种状况下，如何疾速地找出所有用户中的典型人群，就变得有挑战了。 具体的挑战在于：1 、如何基于高维或者多属性值特色疾速定位出外围人群 2 、如何确认外围人群的要害属性。要解决这两个挑战，非数据挖掘算法莫属了。在友盟+，咱们摸索了两种基于算法的人群细分办法，均获得了不错的成果。 其一是基于决策树模型的办法。这种办法次要用于人群特色维度低，然而特色取值比拟多的场景。先看一下咱们的后果，而后我来解释具体的原理。 （图片起源：友盟+U--APP用户洞察） 咱们能够看到，跟大盘相比，咱们要剖析的人群的显著特色之一是地区集中在一线城市。其中年龄25-39岁和男性这两个特色尤为显著，其人群数量占整体的39%。整个过程通过决策树算法全自动化生成，无需人工干预。相比之下，如果是用后面讲述的办法从城市等级（6个取值），年龄段（6个取值），性别（2个取值）这三个维度对用户分群，咱们会生成6*6*2=72个人群，剖析72个人群并从中找出外围人群不仅费时，还费劲。 咱们是怎么做到全自动化地对以上人群进行细分的呢？这里咱们采纳了决策树的思维, 通过在每一层基于信息增益抉择一个最优的切分维度和分隔点，将与大盘人群差别最大的群组辨别进去。这种办法也实用于特色维度高于3的人群细分问题。 当特色维度高于3的时候，咱们能够通过管制树的高度，来管制决策数优先选出的最显著的特色数，最初通过TGI来量化特色的显著性。 另一种人群细分的办法是基于聚类（clustering）的办法。这种办法实用于用户特色维度比拟高的场景。比方，在咱们给客户做的一个分群服务中，客户须要基于用户的人口属性，手机特色（品牌，机型，屏幕大小，硬件参数），以及用户的APP应用趣味来进行人群细分。 这时候，后面的任意一种办法都不论用了，必须求助于更简单的技术手段：聚类分析。以下是基于聚类办法进行用户分群的个别步骤： 其中第一，二，五步的工作是与人群细分的业务场景严密相干的三个步骤。咱们能取得多少的待分群样本，抉择哪些特色维度作为人群的属性维度，以及基于细分人群得出的商业论断和action，均与这个人群细分自身的利用场景非亲非故，要case by case来看待。而第三步，第四步的上半局部，背地的技术手段则绝对来讲比拟通用。 为了失去一个好的聚类后果，须要一直地尝试不同的类别个数和聚类办法，而后对类内聚合度和类间区分度进行迷信的评估。其中，数据摸索是须要最先进行的一个步骤。在咱们的实际中，发现档次聚类是一种十分好的数据摸索形式。 以下图为例，输出市场上机型的配置信息（17维特色），咱们产出档次聚类后果：间隔最近的机型最早被聚在一起，间隔最远的机型最初被聚在一起。从后果中能够看到，被聚在一起的机型具备肯定的共性，比方FindX及Mate均为偏高端的手机，而华为畅享/光荣畅玩/红米数字/VIVO Y则为千元机系列。依据不同机型之间的间隔远近，咱们决定将这些机型分成10类（粉色和蓝色带）。 值得注意的是，最佳的聚类后果并不一定是迷信评估最优的聚类后果。在迷信评估之上，一个正当的聚类后果还须要具备可解释性，迷信评估合格且人工解读正当有用的聚类后果才是最优的用户分群。持续以上图为例，因为聚类产出的后果自身具备可解释性：不同聚类的设施背地的用户群体不同，因而能够间接应用档次聚类的后果作为最终的聚类后果。否则，能够进一步尝试其余的特色输出和聚类办法，通过比照多种后果，抉择最正当的作为最终后果。 以上就是用户分群的N种形式，你学会了几种？

导语：什么是埋点？咱们为什么须要懂埋点？易观方舟官网项目经理李伟涛，通过本身教训实例为大家深入浅出解析，作为技术工程师、程序员，也为了更好推动公司业务产品及我的项目，在经营市场提出需要之前，咱们也能够提前做好一份可行性的埋点设计方案。 很多人看到这个一脸懵，埋点到底是啥玩意儿，这么技术业余的常识也要强制“人人都该懂”？其实不是，我想说的埋点常识，也是配合经营和市场部门的一项重要工作。 说到埋点，不得不说的就是目前比拟火的经营剖析工具，市场部门在做产品推广和产品迭代时，离不开市场对产品的反馈，以往做法是通过做很多的考察问卷，让客户给予反馈，这些问卷相比当初的剖析工具收集的信息有其局限性，比方问题属于提前设计，有误导用户之嫌，用户只是干燥地执行选项抉择，可能心田实在的想法并没有列在选项之中。 这样的数据往往达不到收集数据的初衷，用户实在的想法是什么？产品性能用户应用状况到底如何？应用频率又是怎么样？这些是企业市场部和产品经理最关怀的问题。 埋点其实就是经营剖析工具收集用户行为的一种形式，它能够将用户在产品下面的点击和浏览状况，通过数据可视化直观展示给市场经营及产品人员。 埋点目前有全埋点、可视化埋点和代码埋点三种支流形式，全埋点和可视化埋点在操作下面并没有很明确的辨别，次要区别在于圈选的元素范畴下面，这两种都是无埋码实现数据采集。全埋点和可视化埋点比拟适宜给经营和市场人员应用，界面上简略圈选就能够生成一个埋点。应用可视化埋点基本上能够涵盖大部分的埋点场景。 然而如果有一些属性须要计算过之后才上报，比方商品数量和商品总价，那么就须要咱们技术人员通过代码埋点来配合施行。 代码埋点顾名思义，就是通过在源码外面写上一个埋点代码，而后上报用户点击的行为数据。咱们以易观方舟官网（https://ark.analysys.cn）为例： 比方我想理解易观方舟官网首屏上，那个“体验Deo”按钮的点击状况，进而理解其点击率和按钮转化率，那么咱们就能够在这个按钮下面减少埋点。这里我次要举例JS端的埋点，其它端埋点思路统一。 易观方舟官网（https://ark.analysys.cn） 我在做这个埋点时，会依据“业务类型”+“空间地位”+“页面地址”这三个纬度来命名这个埋点事件。 页面地址：首页空间地位：首屏业务类型：体验Demo的点击状况 下面就是一个按钮点击的埋点部署，是不是很简略？其实埋点在代码执行层面并不难，无非就是在适合的地位放上一段代码，可是如何设计埋点、哪些埋点须要放，哪些埋点应该上报属性，哪些埋点又能够让经营人员本人通过可视化实现埋点，这就须要咱们对业务有肯定的理解，这样能够让代码埋点更正当而少做无用功。 设计埋点并不齐全是经营和产品人员的事件，技术也能够设计一套合乎业务场景的埋点计划。在做页面研发时就能够将埋点做好，页面上线就能够统计数据，也并不需要经营共事分割你才做，如果依照业务倒追技术来埋点的流程，一来二去，企业曾经失落了1天的用户行为数据，这是十分得失相当。 那么作为技术人员，该如何设计埋点计划呢？咱们能够业务场景和代码施行两个方面说： 1、业务场景 持续以易观方舟官网为例，方舟官网体验demo按钮最多，基本上每个页面都有一个，如果依照下面那行代码来部署的话，同样的业务场景，咱们埋了十分多的点，前期统计体验Demo按钮点击状况时，要将所有的体验Demo按钮事件并列统计，这十分不合理。 针对这样的状况，咱们应该通过属性辨别，事件名都是同一个，通过一个属性值来辨别不同的地位。 这样咱们将同一个业务场景的事件归为一个事件，既能够全面统计也能够繁多统计。 再举个例子，咱们常常要统计一个表单的输出状况，比方注册表单里验证手机号和发送验证码这个场景，个别做法会在验证码发送胜利之后上报一个“验证码验证胜利事件”。 如果咱们思考的再粗疏点，比方输出手机号和点击发送验证码两步的漏斗状况如何？输出手机号和验证胜利漏斗状况如何？那么这里就不单单是一个事件就能够了。 咱们须要将表单细化到每步操作，比方用户输出手机号之后，失去光标时，上报输出手机号事件，属性值为手机号。 咱们将一个事件细化之后，就能够晓得哪些用户输出了手机号并且收到了验证码，哪些用户没有收到验证码。 这有个益处就是，假如短信供应商呈现了问题，没有及时发送验证码，咱们能够做前期补救，整顿出没有发送胜利的用户，再次群发，以避免客户散失。 从下面两个例子，咱们能够看出有些步骤经营人员是不分明的，比方手机验证这个过程，这就须要咱们技术工程师来了解场景，补充经营提供的埋点计划。 2、代码部署 一个优良的程序员，会将重复使用的性能进行代码封装，埋点也一样，埋点尽管事件名称不一样，然而逻辑大体一致。 比方易观方舟官网体验demo按钮，每次点击时咱们会判断用户是否登录，登录的用户间接跳转到具体demo页，没有登录的用户咱们会疏导登录。 易观方舟官网这么多体验emo按钮，每个按钮都去写一个判断那不是会疯掉吗？所以咱们将这类操作封装为一个函数，而后将每个按钮下面带上他的地位阐明，这样只有触发这个按钮，就能够将地位信息作为参数模式，传递给埋点事件。 下面是一个判断是否登录接着执行下一步动作的场景。咱们再来想一个场景，假如咱们是一家电商网站，退出购物车、提交订单、领取订单这些事件都是有一个共有属性那就是商品ID和商品名称，咱们能够将这类事件对立封装为一个函数，集中处理共用属性，简化事件上报操作。 代码埋点次要针对须要上报具体属性的事件，比方退出购物车，输出手机号等等，如果只是为了统计按钮点击量，那么能够让经营共事间接应用可视化埋点进行圈选。 埋点这个事件的确很简略，比方易观方舟的埋点就一行代码，次要还是在场景使用中去思考更好的计划。下面咱们抛出了一些埋点的具体思路，次要还是为了将埋点这个工作做得更好。 一个好的埋点设计能节俭咱们很多工夫，少走很多弯路。还要留神一个点就是，变动是恒久不变的规定，咱们的埋点设计也应该拥抱变动，不要为了一个业务场景去写一段代码，应该和经营同学一起沟通这场景的目标是什么，从而联想更多的场景，将埋点尽可能地做粗疏。否则隔三差五经营过去找你批改埋点时，你会十分头大。 记录埋点信息，将咱们做过的埋点事件ID和备注名称记录到表格，不便前期排查埋点问题时应用。有时经营同学也会问某个按钮的埋点事件是哪个，这个时候你的表格就派上了用场，十分不便。易观方舟能够动静治理埋点信息、反对线上搜寻，这个工作咱们程序员倒是省了很多力量。 文至序幕，我也来做个总结。埋点是收集用户行为欠缺咱们产品的重要工作，作为埋点实施者不单单是为了配合经营去执行埋点，应该融入咱们技术角度的思考，将这个事件做得更完满，保证数据精确的同时，也让埋点代码做得够灵便，同时不便咱们前期保护和批改。 （本文作者：易观方舟官网项目经理 李伟涛）

1.技术背景在SQL语句简单、解决数据量大的AP场景下，单个查问对内存的需要越来越大，多个语句的并发很容易将零碎的内存吃满，造成内存不足的问题。为了应答这种问题，GaussDB for DWS引入了内存自适应控制的技术，在上述场景下可能对运行的作业进行内存级的管控，防止高并发场景下内存不足产生的各种问题。 2. GaussDB的动态内存管理机制及缺点GaussDB的执行引擎继承自PG，对于优化器生成的执行打算树，总体采取执行算子+流水线的解决形式，如下图所示。 对于NestLoop算子节点，须要首先从左树的IndexScan算子节点获取元组，而后到右子树的IndexScan算子节点进行连贯，匹配元组后进行输入。流水线的执行形式使得对于NestLoop, IndexScan类的个别算子，同时只有肯定数量的元组处于内存中，对于行引擎每个算子仅占用一条元组的空间，对于列引擎占用一个batch（最多1000条元组）的空间，占用的空间较小，根本能够忽略不计。 然而，GaussDB中也有一些须要将所有数据收集后进行解决的算子，在执行时须要应用较多的内存，通常咱们称这类算子为物化算子。GaussDB中次要存在如下不同品种的物化算子： （1）HashJoin：Hash连贯操作符，次要思维是计算左右两表连贯列的hash值，通过hash值比拟缩小元组比拟的次数，须要将一个表建设hash表，另一个表进行hash值比拟操作，建设hash表须要在内存中进行。 （2）HashAgg：Hash汇集操作符，次要思维同HashJoin相似，通过hash值比拟缩小元组去重比拟的次数，须要将不同值的元组保留的内存中。 （3）Sort：排序操作符，须要获取所有元组后进行排序操作，待排序元组均存在于内存中。 （4）Materialize：物化操作符，通常在须要反复扫描时应用，通过将后果存储在内存中，保障反复扫描时的效率。 同时，GaussDB也提供下盘的机制，当上述操作符须要应用的内存太大时，能够将局部或全副的数据下盘解决，进步内存的应用效率，但相应的查问性能也会受到影响。PG应用 work_mem参数来管制算子可应用内存的阈值，当应用内存超过阈值时，就须要做下盘解决。GaussDB的动态内存管理机制也连续了PG的解决机制，应用work_mem来管制单算子的内存应用下限。 GaussDB的动态内存治理存在较大弊病，须要调优人员可能依据数据量、语句复杂程度和零碎的内存大小设置正当的work_mem，既防止work_mem设置太大导致系统资源不够用，还要思考到数据规模，保障大部分算子不下盘。通常状况下，这个是很难做到的，有以下几点起因： （1）通常状况下，简单语句的执行打算中蕴含多个简单算子，每个算子的内存应用下限是work_mem，咱们没有方法计算一个语句要应用多少内存，因而也就不容易设置一个最优的work_mem参数，保障尽可能不下盘，同时内存又够用。并发场景更无奈设置了。 （2）work_mem只是每个算子内存应用的下限，并不是预调配；如果数据量没有那么大的话，理论内存应用是达不到work_mem的。因而也会影响work_mem的设置。 （3）每个语句的场景不一样，有的语句蕴含多个物化算子，而另外的语句只有一个物化算子，而这个算子对内存的需要会比拟大，因而无奈全局对立地进行设置。 3. GaussDB的内存自适应技术介绍针对动态内存管理机制的弊病，咱们设计了内存自适应控制技术，目标有两个： （1）去除动态内存治理对work_mem的依赖。能够由SQL引擎优化器模块主动估算每个算子所需的内存。 （2）防止大并发场景下内存不足景象的产生。资源管理模块依据SQL引擎优化器对于每个查问内存的估算值，对每个查问进行调度，如果超过零碎可用内存，则进行排队。 如上图所示，动静资源管理与内存自适应技术的组件图如上图所示。咱们从多个CN中抉择一个CN，命名为CCN（Central CN），进行语句队列的治理。对于每个查问SQL，CN在生成完执行打算后，为每个物化算子调配适合的内存，同时计算整个语句内存使用量，并将语句及对应的内存使用量发给CCN。CCN保护零碎可用的内存值，对于新来的语句，如果语句内存使用量小于可用内存值，则容许其下发到DN执行，否则挂起，等到有语句完结开释内存后再次将其唤醒，是否能够下发。 为了达到上述目标，SQL引擎实现了内存自适应控制技术，步骤如下： （1）对于每个SQL，生成打算前首先从资源管理模块获取零碎以后的最大可用内存（Query Max Mem）和以后可用内存（System Available Mem）。最大可用内存通常为每个DN的最大可用内存去除零碎预分配内存，例如：数据缓存等，示意语句可用的最大内存，如果语句应用内存超过该值，必须下盘。以后可用内存用于示意以后零碎的忙碌水平，如果以后可用内存比拟小，偏向于抉择消耗内存少的打算。 （2）根据以后可用内存生成打算，同时依据SQL引擎优化器打算生成过程中的cost估算值估算每个物化算子的内存使用量，以及流水线场景下整个查问应用的内存总量估算值。如果该值大于以后可用内存，则尝试将整个查问的内存使用量调到以后可用内存以下，此时会造成局部算子下盘。 （3）将语句及估算的语句内存发送到CCN，如果以后可用内存小于语句估算内存，则估算语句的内存进一步缩小是否对查问性能造成较大的影响，如果依据cost评估影响不大，则进一步缩小算子的内存应用，使语句内存应用满足以后可用内存，将语句下发执行，否则则进入排队状态。 （4）因为每个算子的内存使用量是基于cost评估取得，可能存在肯定的误差。因而，在SQL语句执行时，反对内存的动静调整，包含：执行算子内存的主动扩大和提前下盘。当算子达到估算的内存值下限，但零碎还有拮据的内存时，会进行算子内存的扩大，持续放弃不下盘的状态。当零碎已用内存达到80%或更高时，如果算子已有最小内存保障，则会触发提前下盘逻辑，保障不会因为内存不足而报错。 4.GaussDB内存自适应的应用和参数管制通过开启use_workload_manager和enable_dynamic_workload两个参数开启GaussDB for DWS的内存自适应控制机制。 应用内存自适应机制时，打印SQL语句的explain performance执行打算运行信息时，会蕴含以下额定的信息辅助定位问题： （1）在最下方的Query Summary一栏中，会显示出System available mem、Query max mem和Query estimated mem，别离示意：零碎以后可用内存、语句可用最大内存（零碎可用最大内存），语句估算内存使用量，均为单DN的掂量值。下图示意以后语句的语句最大可用内存和零碎以后可用内存均为22G，语句估算内存应用为1.6G。 （2）在Memory Information一栏，会显示CN和每个DN的内存应用峰值，如下图所示，语句理论内存应用，单DN应用16GB，CN应用76MB。 （3）在Memory Information一栏下方每个算子对应的地位，会显示每个算子单DN的内存峰值，同时会显示每个DN上内存应用的主动扩大和提前下盘状况，例如下图，能够看出第15号HashJoin算子，每个SMP线程的内存应用均为3.8GB，估算内存是860MB，经验了五次内存主动扩大，在第五次扩大后，零碎内存告急，算子未用到第五次扩大后的峰值即提前下盘。 （4）在explain performance最顶层的表格中，汇总了每个算子的估算内存和理论应用内存的状况，见下图的E-memory和Peak Memory两列所示。与下面信息对应，第15号算子单SMP线程的peak memory，最大值为3766MB，最小值为3753MB，估算内存值（单DN4个SMP线程）为860MB。 能够看出，下面例子因为cost估算不准导致内存估算值较小，理论场景也会呈现内存估算值较大的场景，会导致CCN预留内存较多，阻塞其它作业的执行。因而，能够应用参数query_mem来管制语句最大可用内存下限（单DN），相当于代替了Query max mem。此参数默认为0，示意未开启。当此值大于32MB（最小语句内存调配值）时，示意开启，此时应用work_mem控制系统以后可用内存进行估算，相当于代替了System available mem进行估算。此时，CCN会应用query_mem值进行语句内存估算值的预留和排队，进步并发场景下的内存应用效率。 5.总结内存自适应控制技术是GaussDB for DWS的资源管理联合SQL引擎所做的一次尝试，当然还存在一些有余，比方：cost估算对内存的评估影响较大，局部场景存在失真须要进行参数管制；零碎中内存应用状况比较复杂，还存在局部内存不在管控范畴内须要加强。欢送各位在实用过程中，将遇到的各种问题及时反馈，也帮忙咱们更好的改良！ ...

简介： 7 月 7 日，Flink 1.11.0 正式公布。历时近 4 个月，Flink 在生态、易用性、生产可用性、稳定性等方面都进行了加强和改善。Apache Flink PMC、阿里巴巴高级技术专家王治江，同时也是这个版本的 release manager 之一，将和大家一一分享，并深度分析 Flink 1.11.0 带来了哪些让大家期待已久的个性，对一些有代表性的 feature 从不同维度解读。 在进入深度解读前，咱们先简略理解下社区公布的个别流程，帮忙大家更好的了解和参加 Flink 社区的工作。 首先在每个版本的布局初期，会从志愿者中选出 1-2 名作为 release manager。1.11.0 版本我作为中国这边的 release manager，同时还有一名来自 Ververica 的 Piotr Nowojski 作为德国方的 release manager，这在某种程度上也阐明中国的开发者和贡献度在整个社区的占比很重要。 接下来会进行这个版本的 feature kickoff。在一些大的方向上，社区的布局周期可能比拟久，会分阶段、分步骤逾越多个版本实现，确保品质。每个版本的侧重点也会有所不同，比方前两个版本侧重于批处理的增强，而这个版本更侧重于流解决易用性的晋升。社区规划的 feature 列表会在邮件列表中发动探讨，以收集更多的用户/开发者意见和反馈。 个别的开发周期为 2-3 个月工夫，提前会明确布局出大略的 feature freeze 工夫，之后进行 release candidate 的公布和测试、以及 bug fix。个别通过几轮的迭代周期后会正式投票通过一个绝对稳固的 candidate 版本，而后基于这个版本正式公布。 Flink 1.11.0 从 3 月初的性能布局到 7 月初的正式公布，历经了差不多 4 个月的工夫，对 Flink 的生态、易用性、生产可用性、稳定性等方面都进行了加强和改善，上面将一一跟大家分享。 ...

【导读】：2020年7月9日，对于联邦学习的个人规范—《基于联邦学习的数据流通产品技术要求与测试方法》首次公布，百度作为次要参加拟订单位参加了规范的制订及公布。 2020年7月9日，对于联邦学习的个人规范——《基于联邦学习的数据流通产品技术要求与测试方法》首次公布，百度作为次要参加拟定单位参加了规范的制订及公布。 此次规范由中国通信标准化协会提出并归口，中国信息通信研究院、北京百度网讯科技有限公司等十余家单位及企业参加了规范的拟订工作。标准规定了基于联邦学习的数据流通产品必要的技术要求及相应的测试方法，实用于基于联邦学习的数据流通产品的研发、测试、评估和验收等场景。 中国通信标准化协会于2002年在北京成立，负责组织信息通信畛域或国家标准、行业标准及个人规范的制订正工作，承当国家标准化治理委员会、工业及信息化部信息通信畛域规范归口管理工作。此次规范的公布，标记着联邦学习这一技术将向着更加成熟化、标准化、产业化的方向倒退，为今后各界共建联邦生态打下坚实基础。 至目前，百度平安联邦计算已参加了多项国内、国际标准的定制工作，包含 TC260国家标准——《信息安全技术数据脱敏产品安全技术要求和测试评估办法》（在研）；TC601行业标准——《基于多方平安计算的数据流通产品技术要求与测试方法》、《数据脱敏工具技术要求与测试方法》（在研）；相干国际标准——IEEE P2842 《Recommended Practice for Secure Multi-party Computation》（在研），在数据安全和隐衷爱护技术方面建设了多维度行业影响力。 百度平安联邦计算 联邦学习畛域新摸索在大数据市场倒退迅猛，国家法律法规逐渐健全，监管从严的大潮下，通过数据安全技术实现跨机构数据安全单干已成为行业广泛共识，与此同时，促成数据安全流通共享，进一步开释数据价值，减速数据单干共赢也成为行业刚需。在此基础上，百度平安推出联邦计算平台，致力打造更平安的数据单干体验，为跨机构数据单干提供联结剖析、联结建模等隐衷平安能力，为联邦学习的大规模工业化落地提供产品技术解决方案。 什么是百度平安联邦计算？ 百度平安联邦计算（Baidu Federated Computing, BFC），高效交融多方平安计算（Secure Multi-Party Computation，MPC或SMC ）、可信执行环境（ Trusted Execution Environment，TEE）、差分隐衷（Differential Privacy，DP）和数据脱敏（Data Masking）等多种当先数据安全和隐衷爱护技术，可在各方数据不出域的根底上进行联结计算，获取各方所需的计算结果，全力打造跨组织数据单干“可用不可见，相逢不相识”的极致平安服务体验。 目前，百度平安联邦计算已在联结营销等多个场景实现最佳实际，将来，亦将持续打磨平安可控、分布式计算的产品能力，深耕广告、政务、金融、医疗、工业等重点垂直畛域，深入与ABC、边缘计算、区块链在资源、产品、解决方案方面的协同，更好的满足业务需要。

大数据及人工智能飞速发展的今天，法律法规和信任问题严重阻碍了企业之间的数据流通，数据孤岛问题像一只无形的手挡在了企业之间，因为缺乏有价值的数据合作，各行业用户获取成本居高不下。为了满足企业间数据安全共享、释放数据价值，助力业务创新，腾讯“神盾-联邦计算”平台应运而生！面向数据安全与隐私保护的多方计算技术研究最早可追溯到上世纪70年代，而新兴的联邦学习概念在国内从2019年开始蓬勃发展。 “神盾-联邦计算”平台的成型也正是这个时期，经过2-3个月系统评测、安全算法评测及现场答辩，2019年12月“神盾-联邦计算”代表腾讯获得了信通院颁发的基于多方安全计算的数据流通产品证书，全国首批获得该证书的团队只有5家。目前神盾正在主导信通院联邦学习标准制定。 腾讯“神盾-联邦计算”平台应运而生大数据及人工智能飞速发展的今天，法律法规和信任问题严重阻碍了企业之间的数据流通，数据孤岛问题像一只无形的手挡在了企业之间，因为缺乏有价值的数据合作，各行业用户获取成本居高不下，银行信用卡不良用户占比全面上升，金融信贷审核成本陡增，AI发展也遭遇前所未有的瓶颈，为了让这些企业在合法合规、安全、高效无损的基础上进行数据合作，腾讯“神盾-联邦计算”平台应运而生！ 这是一个主要基于联邦学习、多方安全计算(MPC)、区块链、可信计算等安全技术的分布式计算平台，产品针对机器学习算法进行定制化的隐私保护改造，保证数据不出本地即可完成联合建模，最大化各个合作企业的数据价值： 根据合作双方的实际场景需求，其上层可以覆盖风控、营销、推荐、AI等主流业务，同时“神盾-联邦计算”也将扮演业务与数据之间桥梁的角色，撮合有数据需求的业务方和有价值变现的数据方之间展开合作。 产品首先在联合建模的数据格式规范、安全求交、特征工程、算法参数调试等细节进行了细致的打磨，然后在处于联邦底层核心地位的数据安全与隐私保护技术相关领域做了深入的基础研究，取得了多项突破性的成就，处于行业领先地位。 这其中包含非对称联邦概念的首创及落地、安全信息检索方案的首创及落地 ，涵盖同态加密、不经意传输、隐私集合求交在内的多项MPC技术的创新及应用、主流联邦学习协议的效率优化、精度提升及可信中间方的剥离改造、单向联邦网络策略的推进等，下面将简要介绍其中几项重要突破。 首创非对称联邦学习框架在纵向联邦学习的标准流程中，两个跨特征的参与方需要执行以下两个操作： 1. ID对齐主要依托隐私求交 [2,3] (Private Set Intersection, PSI) 技术 ，在各参与方处输出所有输入的样本ID集合的交集。 2. 加密模型训练各参与方以前文提到的输出交集为基础，计算、通信基于原始数据集计算的加密中间变量。 在前沿的联邦学习圈，大量的研究工作投入到加密模型训练中，包括新联邦协议的设计[4]、联邦通信机制的优化[5, 6]、联邦激励系统的设计[7]，却鲜有对 ID对齐的系统性研究。 实际的纵向联邦学习的场景中，我们发现，往往其中一方的ID集合较少，并且具有较强的业务属性，是ID拥有方希望保护的信息。但是ID较少的参与方却不得不在ID对齐操作中暴露出这些ID，显得较为“弱势”。 例如，联盟中的信贷公司为了实现风控预测，需要将其客户的违约记录输入联邦学习系统中，而每一条这种违约记录的获取都是该类公司以巨额的经济损失作为交换，属于最高等级的商业机密。 为了解决这个问题，将ID、特征、标签三要素的全方位隐私保护放在产品第一要位，彻底解除高敏感领域的数据安全担忧，我们在联邦学习领域首创非对称联邦学习概念，首度发明Asymmetrical-PSI、Genuine-with-Dummy等技术，支撑起一条完整的非对称加密实体对齐 + 非对称加密特征工程 + 非对称加密模型训练联邦学习数据链路。我们将在FL-IJCAI20国际会议上展示部分相关工作[8]。 首创面向联邦成果分享的安全信息检索技术非对称联邦解决了训练过程中样本ID泄漏的问题，但在生产线上查询环节依然会因查询行为泄漏用户清单。若通过返回全量预测分数来保护查询方用户清单，则不便于按量计费，商业上存在障碍。 神盾联邦计算平台深度结合业务场景和需求，首创面向联邦成果分享的安全信息检索技术，解决联邦学习应用的重要隐私性问题，做到样本预处理-数据挖掘-联邦推理-联邦成果安全分享的完整、新型安全信息流。安全信息检索技术解决了联邦学习工程实践中的多方成果共享问题，填补联邦学习系统运行的最后一块短板。 安全信息检索协议基于Pohlig-Hellman交换加密技术和MPC中的不经意传输 (Oblivious Transfer) 技术，强有力保障联邦成果发送方精准分享目标客户群推理结果，全方位保护联邦成果接收方的目标客户群隐私。神盾联邦计算平台已凭借该项成果递交多项国家专利申请。 首创具语义安全性高性能同态加密技术初次使用联邦学习系统的用户可以明显感知到，联邦学习与Spark MLlib, Tensorflow等面向扩展性的传统分布式机器学习框架的性能差异，从而对如此“低效”的联邦服务产生一些疑惑。 神盾联邦计算平台从联邦学习的核心隐私保护技术——同态加密入手优化联邦服务的性能，首创了具有语义安全性的高性能同态加密技术。在单元测试中，我们的成果计算效率相比现有的同态加密提升千倍以上；整个模型的训练耗时也可以节省87%以上。 同态加密是当前工业界广为应用的若干联邦协议中最为通用和便携的安全多方计算技术之一，它能够在保护隐私的前提下，轻易解耦数据提供方角色和计算方角色，完美契合联邦学习的面向隐私保护的分布式计算本质。 同态加密的研究吸引了广泛学者，大量的工作投入到支持运算层数深、运算类型多、安全等级高的各类同态密码研究中[9-11]。然而，受限于现代计算机处理器的性能和实际业务场景的高时效、低时延要求，即使大幅提升服务器配置的前提下，许多完备却复杂的同态密码并不能在令人满意的时间内、在足够大的数据集上、完成足够多轮的联邦建模训练，这是用户感知联邦学习与传统分布式建模系统性能差异较大的核心因素。 为了通过改进底层同态加密的方式提速联邦学习，我们借鉴了经典的对称密码Affine Cipher的群运算类型和非对称密码ElGamal的多元组密文混淆思想，全球首创随机化迭代型仿射密码 (Randomized Iterative Affine Cipher, RIAC)。我们的成果RIAC在保留了经典同态密码的运算次数隐蔽性和语义安全性的前提下，大幅提升同态运算效率，处于国内相关技术的领先梯队。神盾联邦计算平台已凭借该项成果递交多项国家专利申请。 首创地位对等的分布式安全聚合技术在一个联邦学习系统中，数据隐私的保护依赖于其内部的各种安全子协议，例如对加法、乘法、聚合等操作的联邦子协议[13, 14]。其中，聚合技术能够在保护各参与方数据隐私的前提下，完成对分布在各方的模型更新所需参数（如梯度、残差等）、模型估计（如权重）和模型预测值等中间变量的中心化。 安全求和 (Secure Summation) 协议是聚合协议最为直观的实现之一，也是众多安全聚合技术的基准测试方案之一。 目前在学业界广泛流行的安全求和实现方案包括高效安全求和协议[15]、同态加密[10, 11]、秘密分享[16]、面向隐私保护的共识协议[17, 18]等，但在联邦协议的应用中，这些已有协议存在各种问题，包括共谋的威胁[15]、计算复杂较高[10,11,18]、精度损失[17]、完全去中心化 (full decentralization) 问题[10, 11]、动态环境问题[19]等。 ...

概述集群是副本和分片的基础，它将ClickHouse的服务拓扑由单节点延伸到多个节点，但它并不像Hadoop生态的某些系统那样，要求所有节点组成一个单一的大集群。ClickHouse的集群配置非常灵活，用户既可以将所有节点组成一个单一集群，也可以按照业务的诉求，把节点划分为多个小的集群。在每个小的集群区域之间，它们的节点、分区和副本数量可以各不相同 从作用来看，ClickHouse集群的工作更多是针对逻辑层面的。集群定义了多个节点的拓扑关系，这些节点在后续服务过程中可能会协同工作，而执行层面的具体工作则交给了副本和分片来执行。副本和分片这对双胞胎兄弟，有时候看起来泾渭分明，有时候又让人分辨不清。这里有两种区分的方法。一种是从数据层面区分，假设ClickHouse的N个节点组成了一个集群，在集群的各个节点上，都有一张结构相同的数据表Y。如果N1的Y和N2的Y中的数据完全不同，则N1和N2互为分片；如果它们的数据完全相同，则它们互为副本。换言之，分片之间的数据是不同的，而副本之间的数据是完全相同的。所以抛开表引擎的不同，单纯从数据层面来看，副本和分片有时候只有一线之隔。 另一种是从功能作用层面区分，使用副本的主要目的是防止数据丢失，增加数据存储的冗余；而使用分片的主要目的是实现数据的水平切分 本章接下来会按照由易到难的方式介绍副本、分片和集群的使用方法。从数据表的初始形态1分片、0副本开始介绍；接着介绍如何为它添加副本，从而形成1分片、1副本的状态；再介绍如何引入分片，将其转换为多分片、1副本的形态（多副本的形态以此类推） 这种形态的变化过程像极了企业内的业务发展过程。在业务初期，我们从单张数据表开始；在业务上线之后，可能会为它增加副本，以保证数据的安全，或者希望进行读写分离；随着业务量的发展，单张数据表可能会遇到瓶颈，此时会进一步为它增加分片，从而实现数据的水平切分。在接下来的示例中，也会遵循这样的演示路径进行说明。 数据副本不知大家是否还记得，在介绍MergeTree的时候，曾经讲过它的命名规则。如果在*MergeTree的前面增加Replicated的前缀，则能够组合成一个新的变种引擎，即Replicated-MergeTree复制表。换言之，只有使用了ReplicatedMergeTree复制表系列引擎，才能应用副本的能力（后面会介绍另一种副本的实现方式）。或者用一种更为直接的方式理解，即使用ReplicatedMergeTree的数据表就是副本。 ReplicatedMergeTree是MergeTree的派生引擎，它在MergeTree的基础上加入了分布式协同的能力。在MergeTree中，一个数据分区由开始创建到全部完成，会历经两类存储区域。（1）内存：数据首先会被写入内存缓冲区。（2）本地磁盘：数据接着会被写入tmp临时目录分区，待全部完成后再将临时目录重命名为正式分区。ReplicatedMergeTree在上述基础之上增加了ZooKeeper的部分，它会进一步在ZooKeeper内创建一系列的监听节点，并以此实现多个实例之间的通信。在整个通信过程中，ZooKeeper并不会涉及表数据的传输。 副本的特点作为数据副本的主要实现载体，ReplicatedMergeTree在设计上有一些显著特点。❑ 依赖ZooKeeper：在执行INSERT和ALTER查询的时候，ReplicatedMergeTree需要借助ZooKeeper的分布式协同能力，以实现多个副本之间的同步。但是在查询副本的时候，并不需要使用ZooKeeper。关于这方面的更多信息，会在稍后详细介绍。❑ 表级别的副本：副本是在表级别定义的，所以每张表的副本配置都可以按照它的实际需求进行个性化定义，包括副本的数量，以及副本在集群内的分布位置等。❑ 多主架构（Multi Master）：可以在任意一个副本上执行INSERT和ALTER查询，它们的效果是相同的。这些操作会借助ZooKeeper的协同能力被分发至每个副本以本地形式执行。❑ Block数据块：在执行INSERT命令写入数据时，会依据max_insert_block_size的大小（默认1048576行）将数据切分成若干个Block数据块。所以Block数据块是数据写入的基本单元，并且具有写入的原子性和唯一性。❑ 原子性：在数据写入时，一个Block块内的数据要么全部写入成功，要么全部失败。❑ 唯一性：在写入一个Block数据块的时候，会按照当前Block数据块的数据顺序、数据行和数据大小等指标，计算Hash信息摘要并记录在案。在此之后，如果某个待写入的Block数据块与先前已被写入的Block数据块拥有相同的Hash摘要（Block数据块内数据顺序、数据大小和数据行均相同），则该Block数据块会被忽略。这项设计可以预防由异常原因引起的Block数据块重复写入的问题。如果只是单纯地看这些特点的说明，可能不够直观。没关系，接下来会逐步展开，并附带一系列具体的示例。 ZooKeeper的配置方式ClickHouse使用一组zookeeper标签定义相关配置，默认情况下，在全局配置config. xml中定义即可。但是各个副本所使用的Zookeeper配置通常是相同的，为了便于在多个节点之间复制配置文件，更常见的做法是将这一部分配置抽离出来，独立使用一个文件保存。 首先，在服务器的/etc/clickhouse-server/config.d目录下创建一个名为metrika.xml的配置文件：接着，在全局配置config.xml中使用<include_from>标签导入刚才定义的配置：并引用ZooKeeper配置的定义：其中，incl与metrika.xml配置文件内的节点名称要彼此对应。至此，整个配置过程就完成了。 ClickHouse在它的系统表中，颇为贴心地提供了一张名为zookeeper的代理表。通过这张表，可以使用SQL查询的方式读取远端ZooKeeper内的数据。有一点需要注意，在用于查询的SQL语句中，必须指定path条件，例如查询根路径： SELECT * FROM system.zookeeper where path = '/'; SELECT name,value,czxid,mzxid FROM system.zookeeper where path = '/clickhouse'; 副本的定义形式正如前文所言，使用副本的好处甚多。首先，由于增加了数据的冗余存储，所以降低了数据丢失的风险；其次，由于副本采用了多主架构，所以每个副本实例都可以作为数据读、写的入口，这无疑分摊了节点的负载。 在使用副本时，不需要依赖任何集群配置, ReplicatedMergeTree结合ZooKeeper就能完成全部工作。 ReplicatedMergeTree的定义方式如下： ENGINE =ReplicatedMergeTree('zk_path','replica_name')zk_path用于指定在ZooKeeper中创建的数据表的路径，路径名称是自定义的，并没有固定规则，用户可以设置成自己希望的任何路径。即便如此，ClickHouse还是提供了一些约定俗成的配置模板以供参考，例如： /clickhouse/tables/{shard}/table_name其中：❑ /clickhouse/tables/是约定俗成的路径固定前缀，表示存放数据表的根路径。❑ {shard}表示分片编号，通常用数值替代，例如01、02、03。一张数据表可以有多个分片，而每个分片都拥有自己的副本。❑ table_name表示数据表的名称，为了方便维护，通常与物理表的名字相同（虽然ClickHouse并不强制要求路径中的表名称和物理表名相同）；而replica_name的作用是定义在ZooKeeper中创建的副本名称，该名称是区分不同副本实例的唯一标识。一种约定成俗的命名方式是使用所在服务器的域名称。 对于zk_path而言，同一张数据表的同一个分片的不同副本，应该定义相同的路径；而对于replica_name而言，同一张数据表的同一个分片的不同副本，应该定义不同的名称。 ReplicatedMergeTree原理解析ReplicatedMergeTree作为复制表系列的基础表引擎，涵盖了数据副本最为核心的逻辑，将它拿来作为副本的研究标本是最合适不过了。因为只要剖析了ReplicatedMergeTree的核心原理，就能掌握整个ReplicatedMergeTree系列表引擎的使用方法。 数据结构在ReplicatedMergeTree的核心逻辑中，大量运用了ZooKeeper的能力，以实现多个ReplicatedMergeTree副本实例之间的协同，包括主副本选举、副本状态感知、操作日志分发、任务队列和BlockID去重判断等。在执行INSERT数据写入、MERGE分区和MUTATION操作的时候，都会涉及与ZooKeeper的通信。但是在通信的过程中，并不会涉及任何表数据的传输，在查询数据的时候也不会访问ZooKeeper，所以不必过于担心ZooKeeper的承载压力。 因为ZooKeeper对ReplicatedMergeTree非常重要，所以下面首先从它的数据结构开始介绍。 ZooKeeper内的节点结构ReplicatedMergeTree需要依靠ZooKeeper的事件监听机制以实现各个副本之间的协同。所以，在每张ReplicatedMergeTree表的创建过程中，它会以zk_path为根路径，在Zoo-Keeper中为这张表创建一组监听节点。按照作用的不同，监听节点可以大致分成如下几类： （1）元数据：❑ /metadata：保存元数据信息，包括主键、分区键、采样表达式等。❑ /columns：保存列字段信息，包括列名称和数据类型。❑ /replicas：保存副本名称，对应设置参数中的replica_name。 （2）判断标识：❑ /leader_election：用于主副本的选举工作，主副本会主导MERGE和MUTATION操作（ALTER DELETE和ALTER UPDATE）。这些任务在主副本完成之后再借助ZooKeeper将消息事件分发至其他副本。❑ /blocks：记录Block数据块的Hash信息摘要，以及对应的partition_id。通过Hash摘要能够判断Block数据块是否重复；通过partition_id，则能够找到需要同步的数据分区。❑ /block_numbers：按照分区的写入顺序，以相同的顺序记录partition_id。各个副本在本地进行MERGE时，都会依照相同的block_numbers顺序进行。❑ /quorum：记录quorum的数量，当至少有quorum数量的副本写入成功后，整个写操作才算成功。quorum的数量由insert_quorum参数控制，默认值为0。 （3）操作日志：❑ /log：常规操作日志节点（INSERT、MERGE和DROP PARTITION），它是整个工作机制中最为重要的一环，保存了副本需要执行的任务指令。log使用了ZooKeeper的持久顺序型节点，每条指令的名称以log-为前缀递增，例如log-0000000000、log-0000000001等。每一个副本实例都会监听/log节点，当有新的指令加入时，它们会把指令加入副本各自的任务队列，并执行任务。关于这方面的执行逻辑，稍后会进一步展开。 ❑ /mutations:MUTATION操作日志节点，作用与log日志类似，当执行ALERTDELETE和ALERT UPDATE查询时，操作指令会被添加到这个节点。mutations同样使用了ZooKeeper的持久顺序型节点，但是它的命名没有前缀，每条指令直接以递增数字的形式保存，例如0000000000、0000000001等。关于这方面的执行逻辑，同样稍后展开。 ...

MergeTree系列表引擎目前在ClickHouse中，按照特点可以将表引擎大致分成6个系列，分别是合并树、外部存储、内存、文件、接口和其他，每一个系列的表引擎都有着独自的特点与使用场景。在它们之中，最为核心的当属MergeTree系列，因为它们拥有最为强大的性能和最广泛的使用场合。 大家应该已经知道了MergeTree有两层含义： 其一，表示合并树表引擎家族； 其二，表示合并树家族中最基础的MergeTree表引擎。 而在整个家族中，除了基础表引擎MergeTree之外，常用的表引擎还有ReplacingMergeTree、SummingMergeTree、AggregatingMergeTree、CollapsingMergeTree和VersionedCollapsingMergeTree。每一种合并树的变种，在继承了基础MergeTree的能力之后，又增加了独有的特性。其名称中的“合并”二字奠定了所有类型MergeTree的基因，它们的所有特殊逻辑，都是在触发合并的过程中被激活的。在本章后续的内容中，会逐一介绍它们的特点以及使用方法。 MergeTreeMergeTree作为家族系列最基础的表引擎，提供了数据分区、一级索引和二级索引等功能。 数据TTLTTL即Time To Live，顾名思义，它表示数据的存活时间。在MergeTree中，可以为某个列字段或整张表设置TTL。当时间到达时，如果是列字段级别的TTL，则会删除这一列的数据；如果是表级别的TTL，则会删除整张表的数据；如果同时设置了列级别和表级别的TTL，则会以先到期的那个为主。无论是列级别还是表级别的TTL，都需要依托某个DateTime或Date类型的字段，通过对这个时间字段的INTERVAL操作，来表述TTL的过期时间，例如： TTL time_col + INTERVAL 3 DAY上述语句表示数据的存活时间是time_col时间的3天之后。又例如： TTL time_col + INTERVAL 1 MONTH 上述语句表示数据的存活时间是time_col时间的1月之后。INTERVAL完整的操作包括SECOND、MINUTE、HOUR、DAY、WEEK、MONTH、QUARTER和YEAR。 列级别TTL如果想要设置列级别的TTL，则需要在定义表字段的时候，为它们声明TTL表达式，主键字段不能被声明TTL。以下面的语句为例： CREATE TABLE ttl_table_v1 ( id String, create_time DateTime, code String TTL create_time + INTERVAL 10 SECOND, type UInt8 TTL create_time + INTERVAL 10 SECOND)ENGINE = MergeTreePARTITION BY toYYYYMM(create_time)ORDER BY id ;其中，create_time是日期类型，列字段code与type均被设置了TTL，它们的存活时间是在create_time的取值基础之上向后延续10秒。现在写入测试数据，其中第一行数据create_time取当前的系统时间，而第二行数据的时间比第一行增加10分钟： SELECT * FROM ttl_table_v1;接着心中默数10秒，然后执行optimize命令强制触发TTL清理： OPTIMIZE TABLE ttl_table_v1 FINAL;再次查询ttl_table_v1则能够看到，由于第一行数据满足TTL过期条件（当前系统时间 >= create_time + 10秒），它们的code和type列会被还原为数据类型的默认值： ...

MergeTree原理解析表引擎是ClickHouse设计实现中的一大特色。可以说，是表引擎决定了一张数据表最终的“性格”，比如数据表拥有何种特性、数据以何种形式被存储以及如何被加载。ClickHouse拥有非常庞大的表引擎体系，截至本书完成时，其共拥有合并树、外部存储、内存、文件、接口和其他6大类20多种表引擎。而在这众多的表引擎中，又属合并树（MergeTree）表引擎及其家族系列(*MergeTree)最为强大，在生产环境的绝大部分场景中，都会使用此系列的表引擎。因为只有合并树系列的表引擎才支持主键索引、数据分区、数据副本和数据采样这些特性，同时也只有此系列的表引擎支持ALTER相关操作。合并树家族自身也拥有多种表引擎的变种。其中MergeTree作为家族中最基础的表引擎，提供了主键索引、数据分区、数据副本和数据采样等基本能力，而家族中其他的表引擎则在MergeTree的基础之上各有所长。例如ReplacingMergeTree表引擎具有删除重复数据的特性，而SummingMergeTree表引擎则会按照排序键自动聚合数据。如果给合并树系列的表引擎加上Replicated前缀，又会得到一组支持数据副本的表引擎，例如ReplicatedMergeTree、ReplicatedReplacingMergeTree、ReplicatedSummingMergeTree等。合并树表引擎家族如图所示： 虽然合并树的变种很多，但MergeTree表引擎才是根基。作为合并树家族系列中最基础的表引擎，MergeTree具备了该系列其他表引擎共有的基本特征，所以吃透了MergeTree表引擎的原理，就能够掌握该系列引擎的精髓。 MergeTree的创建方式与存储结构MergeTree在写入一批数据时，数据总会以数据片段的形式写入磁盘，且数据片段不可修改。为了避免片段过多，ClickHouse会通过后台线程，定期合并这些数据片段，属于相同分区的数据片段会被合成一个新的片段。这种数据片段往复合并的特点，也正是合并树名称的由来。 MergeTree的创建方式创建MergeTree数据表的方法，与我们第4章介绍的定义数据表的方法大致相同，但需要将ENGINE参数声明为MergeTree()，其完整的语法如下所示：MergeTree表引擎除了常规参数之外，还拥有一些独有的配置选项。接下来会着重介绍其中几个重要的参数，包括它们的使用方法和工作原理。但是在此之前，还是先介绍一遍它们的作用。 （1）PARTITION BY [选填]：分区键，用于指定表数据以何种标准进行分区。分区键既可以是单个列字段，也可以通过元组的形式使用多个列字段，同时它也支持使用列表达式。如果不声明分区键，则ClickHouse会生成一个名为all的分区。合理使用数据分区，可以有效减少查询时数据文件的扫描范围。 （2）ORDER BY [必填]：排序键，用于指定在一个数据片段内，数据以何种标准排序。默认情况下主键（PRIMARY KEY）与排序键相同。排序键既可以是单个列字段，例如ORDER BY CounterID，也可以通过元组的形式使用多个列字段，例如ORDER BY（CounterID, EventDate）。当使用多个列字段排序时，以ORDERBY（CounterID, EventDate）为例，在单个数据片段内，数据首先会以CounterID排序，相同CounterID的数据再按EventDate排序。 （3）PRIMARY KEY [选填]：主键，顾名思义，声明后会依照主键字段生成一级索引，用于加速表查询。默认情况下，主键与排序键(ORDER BY)相同，所以通常直接使用ORDER BY代为指定主键，无须刻意通过PRIMARY KEY声明。所以在一般情况下，在单个数据片段内，数据与一级索引以相同的规则升序排列。与其他数据库不同，MergeTree主键允许存在重复数据（ReplacingMergeTree可以去重）。 （4）SAMPLE BY [选填]：抽样表达式，用于声明数据以何种标准进行采样。如果使用了此配置项，那么在主键的配置中也需要声明同样的表达式，例如：抽样表达式需要配合SAMPLE子查询使用，这项功能对于选取抽样数据十分有用。 （5）SETTINGS: index_granularity [选填]:index_granularity对于MergeTree而言是一项非常重要的参数，它表示索引的粒度，默认值为8192。也就是说，MergeTree的索引在默认情况下，每间隔8192行数据才生成一条索引，其具体声明方式如下所示：8192是一个神奇的数字，在ClickHouse中大量数值参数都有它的影子，可以被其整除（例如最小压缩块大小min_compress_block_size:65536）。通常情况下并不需要修改此参数，但理解它的工作原理有助于我们更好地使用MergeTree。关于索引详细的工作原理会在后续阐述。 （6）SETTINGS: index_granularity_bytes [选填]：在19.11版本之前，ClickHouse只支持固定大小的索引间隔，由index_granularity控制，默认为8192。在新版本中，它增加了自适应间隔大小的特性，即根据每一批次写入数据的体量大小，动态划分间隔大小。而数据的体量大小，正是由index_granularity_bytes参数控制的，默认为10M(10×1024×1024)，设置为0表示不启动自适应功能。 （7）SETTINGS: enable_mixed_granularity_parts [选填]：设置是否开启自适应索引间隔的功能，默认开启。 （8）SETTINGS: merge_with_ttl_timeout [选填]：从19.6版本开始，MergeTree提供了数据TTL的功能。 （9）SETTINGS: storage_policy [选填]：从19.15版本开始，MergeTree提供了多路径的存储策略。 MergeTree的存储结构MergeTree表引擎中的数据是拥有物理存储的，数据会按照分区目录的形式保存到磁盘之上，其完整的存储结构如图所示： 从图中可以看出，一张数据表的完整物理结构分为3个层级，依次是数据表目录、分区目录及各分区下具体的数据文件。接下来就逐一介绍它们的作用。（1）partition：分区目录，余下各类数据文件（primary.idx、[Column].mrk、[Column]. bin等）都是以分区目录的形式被组织存放的，属于相同分区的数据，最终会被合并到同一个分区目录，而不同分区的数据，永远不会被合并在一起。更多关于数据分区的细节会在6.2节阐述。（2）checksums.txt：校验文件，使用二进制格式存储。它保存了余下各类文件(primary. idx、count.txt等)的size大小及size的哈希值，用于快速校验文件的完整性和正确性。（3）columns.txt：列信息文件，使用明文格式存储。用于保存此数据分区下的列字段信息，例如：（4）count.txt：计数文件，使用明文格式存储。用于记录当前数据分区目录下数据的总行数：（5）primary.idx：一级索引文件，使用二进制格式存储。用于存放稀疏索引，一张MergeTree表只能声明一次一级索引（通过ORDER BY或者PRIMARY KEY）。借助稀疏索引，在数据查询的时能够排除主键条件范围之外的数据文件，从而有效减少数据扫描范围，加速查询速度。（6）[Column].bin：数据文件，使用压缩格式存储，默认为LZ4压缩格式，用于存储某一列的数据。由于MergeTree采用列式存储，所以每一个列字段都拥有独立的．bin数据文件，并以列字段名称命名（例如CounterID.bin、EventDate.bin等）。（7）[Column].mrk：列字段标记文件，使用二进制格式存储。标记文件中保存了．bin文件中数据的偏移量信息。标记文件与稀疏索引对齐，又与．bin文件一一对应，所以MergeTree通过标记文件建立了primary.idx稀疏索引与．bin数据文件之间的映射关系。即首先通过稀疏索引（primary.idx）找到对应数据的偏移量信息（.mrk），再通过偏移量直接从．bin文件中读取数据。由于．mrk标记文件与．bin文件一一对应，所以MergeTree中的每个列字段都会拥有与其对应的．mrk标记文件（例如CounterID.mrk、EventDate.mrk等）。（8）[Column].mrk2：如果使用了自适应大小的索引间隔，则标记文件会以．mrk2命名。它的工作原理和作用与．mrk标记文件相同。（9）partition.dat与minmax_[Column].idx：如果使用了分区键，例如PARTITION BY EventTime，则会额外生成partition.dat与minmax索引文件，它们均使用二进制格式存储。partition.dat用于保存当前分区下分区表达式最终生成的值；而minmax索引用于记录当前分区下分区字段对应原始数据的最小和最大值。例如EventTime字段对应的原始数据为2019-05-01、2019-05-05，分区表达式为PARTITION BY toYYYYMM(EventTime)。partition.dat中保存的值将会是2019-05，而minmax索引中保存的值将会是2019-05-012019-05-05。在这些分区索引的作用下，进行数据查询时能够快速跳过不必要的数据分区目录，从而减少最终需要扫描的数据范围。 （10）skp_idx_[Column].idx与skp_idx_[Column].mrk：如果在建表语句中声明了二级索引，则会额外生成相应的二级索引与标记文件，它们同样也使用二进制存储。二级索引在ClickHouse中又称跳数索引，目前拥有minmax、set、ngrambf_v1和tokenbf_v1四种类型。这些索引的最终目标与一级稀疏索引相同，都是为了进一步减少所需扫描的数据范围，以加速整个查询过程。 数据分区通过先前的介绍已经知晓在MergeTree中，数据是以分区目录的形式进行组织的，每个分区独立分开存储。借助这种形式，在对MergeTree进行数据查询时，可以有效跳过无用的数据文件，只使用最小的分区目录子集。这里有一点需要明确，在ClickHouse中，数据分区（partition）和数据分片（shard）是完全不同的概念。数据分区是针对本地数据而言的，是对数据的一种纵向切分。MergeTree并不能依靠分区的特性，将一张表的数据分布到多个ClickHouse服务节点。而横向切分是数据分片（shard）的能力。 数据的分区规则MergeTree数据分区的规则由分区ID决定，而具体到每个数据分区所对应的ID，则是由分区键的取值决定的。分区键支持使用任何一个或一组字段表达式声明，其业务语义可以是年、月、日或者组织单位等任何一种规则。针对取值数据类型的不同，分区ID的生成逻辑目前拥有四种规则： （1）不指定分区键：如果不使用分区键，即不使用PARTITION BY声明任何分区表达式，则分区ID默认取名为all，所有的数据都会被写入这个all分区。（2）使用整型：如果分区键取值属于整型(兼容UInt64，包括有符号整型和无符号整型)，且无法转换为日期类型YYYYMMDD格式，则直接按照该整型的字符形式输出，作为分区ID的取值。（3）使用日期类型：如果分区键取值属于日期类型，或者是能够转换为YYYYMMDD格式的整型，则使用按照YYYYMMDD进行格式化后的字符形式输出，并作为分区ID的取值。（4）使用其他类型：如果分区键取值既不属于整型，也不属于日期类型，例如String、Float等，则通过128位Hash算法取其Hash值作为分区ID的取值。数据在写入时，会对照分区ID落入相应的数据分区，下表列举了分区ID在不同规则下的一些示例。如果通过元组的方式使用多个分区字段，则分区ID依旧是根据上述规则生成的，只是多个ID之间通过“-”符号依次拼接。例如按照上述表格中的例子，使用两个字段分区：则最终的分区ID会是下面的模样： 分区目录的命名规则我们已经知道了分区ID的生成规则。但是如果进入数据表所在的磁盘目录后，会发现MergeTree分区目录的完整物理名称并不是只有ID而已，在ID之后还跟着一串奇怪的数字，例如201905_1_1_0。那么这些数字又代表着什么呢？ 众所周知，对于MergeTree而言，它最核心的特点是其分区目录的合并动作。但是我们可曾想过，从分区目录的命名中便能够解读出它的合并逻辑。在这一小节，我们会着重对命名公式中各分项进行解读，而关于具体的目录合并过程将会留在后面小节讲解。一个完整分区目录的命名公式如下所示：如果对照着示例数据，那么数据与公式的对照关系会如同下图所示一般。上图中，201905表示分区目录的ID;1_1分别表示最小的数据块编号与最大的数据块编号；而最后的_0则表示目前合并的层级。接下来开始分别解释它们的含义：（1）PartitionID：分区ID，无须多说，关于分区ID的规则在上一小节中已经做过详细阐述了。（2）MinBlockNum和MaxBlockNum：顾名思义，最小数据块编号与最大数据块编号。ClickHouse在这里的命名似乎有些歧义，很容易让人与稍后会介绍到的数据压缩块混淆。但是本质上它们毫无关系，这里的BlockNum是一个整型的自增长编号。如果将其设为n的话，那么计数n在单张MergeTree数据表内全局累加，n从1开始，每当新创建一个分区目录时，计数n就会累积加1。对于一个新的分区目录而言，MinBlockNum与MaxBlockNum取值一样，同等于n，例如201905_1_1_0、201906_2_2_0以此类推。但是也有例外，当分区目录发生合并时，对于新产生的合并目录MinBlockNum与MaxBlockNum有着另外的取值规则。对于合并规则，我们留到下一小节再详细讲解。（3）Level：合并的层级，可以理解为某个分区被合并过的次数，或者这个分区的年龄。数值越高表示年龄越大。Level计数与BlockNum有所不同，它并不是全局累加的。对于每一个新创建的分区目录而言，其初始值均为0。之后，以分区为单位，如果相同分区发生合并动作，则在相应分区内计数累积加1。 分区目录的合并过程MergeTree的分区目录和传统意义上其他数据库有所不同。首先，MergeTree的分区目录并不是在数据表被创建之后就存在的，而是在数据写入过程中被创建的。也就是说如果一张数据表没有任何数据，那么也不会有任何分区目录存在。其次，它的分区目录在建立之后也并不是一成不变的。在其他某些数据库的设计中，追加数据后目录自身不会发生变化，只是在相同分区目录中追加新的数据文件。而MergeTree完全不同，伴随着每一批数据的写入（一次INSERT语句）,MergeTree都会生成一批新的分区目录。即便不同批次写入的数据属于相同分区，也会生成不同的分区目录。也就是说，对于同一个分区而言，也会存在多个分区目录的情况。在之后的某个时刻（写入后的10～15分钟，也可以手动执行optimize查询语句）, ClickHouse会通过后台任务再将属于相同分区的多个目录合并成一个新的目录。已经存在的旧分区目录并不会立即被删除，而是在之后的某个时刻通过后台任务被删除（默认8分钟）。 属于同一个分区的多个目录，在合并之后会生成一个全新的目录，目录中的索引和数据文件也会相应地进行合并。新目录名称的合并方式遵循以下规则，其中：❑ MinBlockNum：取同一分区内所有目录中最小的MinBlockNum值。❑ MaxBlockNum：取同一分区内所有目录中最大的MaxBlockNum值。❑ Level：取同一分区内最大Level值并加1。 合并目录名称的变化过程如图所示： partition_v5测试表按日期字段格式分区，即PARTITION BYtoYYYYMM（EventTime）, T表示时间。假设在T0时刻，首先分3批（3次INSERT语句）写入3条数据人： ...

数据字典数据字典是ClickHouse提供的一种非常简单、实用的存储媒介，它以键值和属性映射的形式定义数据。字典中的数据会主动或者被动（数据是在ClickHouse启动时主动加载还是在首次查询时惰性加载由参数设置决定）加载到内存，并支持动态更新。由于字典数据常驻内存的特性，所以它非常适合保存常量或经常使用的维度表数据，以避免不必要的JOIN查询。数据字典分为内置与扩展两种形式，顾名思义，内置字典是ClickHouse默认自带的字典，而外部扩展字典是用户通过自定义配置实现的字典。在正常情况下，字典中的数据只能通过字典函数访问（ClickHouse特别设置了一类字典函数，专门用于字典数据的取用）。但是也有一种例外，那就是使用特殊的字典表引擎。在字典表引擎的帮助下，可以将数据字典挂载到一张代理的数据表下，从而实现数据表与字典数据的JOIN查询。关于字典表引擎的更多细节与使用方法将会在后续章节着重介绍。 内置字典 ClickHouse目前只有一种内置字典——Yandex.Metrica字典。从名称上可以看出，这是用在ClickHouse自家产品上的字典，而它的设计意图是快速存取geo地理数据。但较为遗憾的是，由于版权原因Yandex并没有将geo地理数据开放出来。这意味着ClickHouse目前的内置字典，只是提供了字典的定义机制和取数函数，而没有内置任何现成的数据。所以内置字典的现状较为尴尬，需要遵照它的字典规范自行导入数据。 外部扩展字典外部扩展字典是以插件形式注册到ClickHouse中的，由用户自行定义数据模式及数据来源。目前扩展字典支持7种类型的内存布局和4类数据来源。相比内容十分有限的内置字典，扩展字典才是更加常用的功能。 准备字典数据 在接下来的篇幅中，会逐个介绍每种扩展字典的使用方法，包括它们的配置形式、数据结构及创建方法，但是在此之前还需要进行一些准备工作。为了便于演示，此处事先准备了三份测试数据，它们均使用CSV格式。其中，第一份是企业组织数据，它将用于flat、hashed、cache、complex_key_hashed和complex_key_cache字典的演示场景。这份数据拥有id、code和name三个字段，数据格式如下所示： 第二份是销售数据，它将用于range_hashed字典的演示场景。这份数据拥有id、start、end和price四个字段，数据格式如下所示： 最后一份是asn数据，它将用于演示ip_trie字典的场景。这份数据拥有ip、asn和country三个字段，数据格式如下所示： 扩展字典配置文件的元素组成 扩展字典的配置文件由config.xml文件中的dictionaries_config配置项指定： 在默认的情况下，ClickHouse会自动识别并加载/etc/clickhouse-server目录下所有以_dictionary.xml结尾的配置文件。同时ClickHouse也能够动态感知到此目录下配置文件的各种变化，并支持不停机在线更新配置文件。在单个字典配置文件内可以定义多个字典，其中每一个字典由一组dictionary元素定义。在dictionary元素之下又分为5个子元素，均为必填项，它们完整的配置结构如下所示： 在上述结构中，主要配置的含义如下。name：字典的名称，用于确定字典的唯一标识，必须全局唯一，多个字典之间不允许重复。structure：字典的数据结构。layout：字典的类型，它决定了数据在内存中以何种结构组织和存储。目前扩展字典共拥有7种类型。source：字典的数据源，它决定了字典中数据从何处加载。目前扩展字典共拥有文件、数据库和其他三类数据来源。lifetime：字典的更新时间，扩展字典支持数据在线更新。 扩展字典的数据结构 扩展字典的数据结构由structure元素定义，由键值key和属性attribute两部分组成，它们分别描述字典的数据标识和字段属性。structure的完整形式如下所示（在后面的查询过程中都会通过这些字段来访问字典中的数据）： 接下来具体介绍key和attribute的含义。 keykey用于定义字典的键值，每个字典必须包含1个键值key字段，用于定位数据，类似数据库的表主键。键值key分为数值型和复合型两类。（1）数值型：数值型key由UInt64整型定义，支持flat、hashed、range_hashed和cache类型的字典（扩展字典类型会在后面介绍），它的定义方法如下所示。 （2）复合型：复合型key使用Tuple元组定义，可以由1到多个字段组成，类似数据库中的复合主键。它仅支持complex_key_hashed、complex_key_cache和ip_trie类型的字典。其定义方法如下所示。 attributeattribute用于定义字典的属性字段，字典可以拥有1到多个属性字段。它的完整定义方法如下所示： 在attribute元素下共有7个配置项，其中name、type和null_value为必填项。这些配置项的详细说明如表所示。 扩展字典的类型 扩展字典的类型使用layout元素定义，目前共有7种类型。一个字典的类型，既决定了其数据在内存中的存储结构，也决定了该字典支持的key键类型。根据key键类型的不同，可以将它们划分为两类：一类是以flat、hashed、range_hashed和cache组成的单数值key类型，因为它们均使用单个数值型的id；另一类则是由complex_key_hashed、complex_key_cache和ip_trie组成的复合key类型。complex_key_hashed与complex_key_cache字典在功能方面与hashed和cache并无二致，只是单纯地将数值型key替换成了复合型key而已。 接下来会结合已准备好的测试数据，逐一介绍7种字典的完整配置方法。通过这个过程，可以领略到不同类型字典的特点以及它们的使用方法。 flatflat字典是所有类型中性能最高的字典类型，它只能使用UInt64数值型key。顾名思义，flat字典的数据在内存中使用数组结构保存，数组的初始大小为1024，上限为500000，这意味着它最多只能保存500000行数据。如果在创建字典时数据量超出其上限，那么字典会创建失败。代码所示是通过手动创建的flat字典配置文件。 <?xml version="1.0"?><dictionaries> <dictionary> <name>test_flat_dict</name> <source> <file> <path>/chbase/data/dictionaries/organization.csv</path> <format>CSV</format> </file> </source> <layout> <flat/> </layout> <structure> <id> <name>id</name> </id> <attribute> <name>code</name> <type>String</type> <null_value></null_value> </attribute> <attribute> <name>name</name> <type>String</type> <null_value></null_value> </attribute> </structure> <lifetime> <min>300</min> <max>360</max> </lifetime> </dictionary></dictionaries> 在上述的配置中，source数据源是CSV格式的文件，structure数据结构与其对应。将配置文件复制到ClickHouse服务节点的/etc/clickhouse-server目录后，即完成了对该字典的创建过程。查验system.dictionaries系统表后，能够看到flat字典已经创建成功。 SELECT name,type,key,attribute.names,attribute.types FROM system.dictionaries; ...

单机安装ClickHouse支持运行在主流64位CPU架构（X86、AArch和PowerPC）的Linux操作系统之上，可以通过源码编译、预编译压缩包、Docker镜像和RPM等多种方法进行安装。由于篇幅有限，本节着重讲解离线RPM的安装方法。更多的安装方法请参阅官方手册，此处不再赘述。 操作系统:centos7.x ClickHouse版本:19.17.4.11 ClickHouse安装包下载地址:https://packagecloud.io/altin... https://repo.yandex.ru/clickh... 需要下载下面四个安装包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 关闭防火墙，检查环境:systemctl stop firewalld.servicesystemctl disable firewalld.service 需要验证当前服务器的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 设置FQDN:hostnamectl --static set-hostname ch5.nauu.com 验证修改:hostname -f ch5.nauu.com 最后需要配置hosts文件，配置后的效果如下：192.168.59.136 ch5.nauu.com ch5 安装执行将RPM包上传到/chbase/setup目录下cd /chbase/setup rpm -ivh *.rpm 如果报错缺少依赖包，需要一一补齐 目录结构 程序在安装的过程中会自动构建整套目录结构，接下来分别说明它们的作用。首先是核心目录部分：（1）/etc/clickhouse-server：服务端的配置文件目录，包括全局配置config.xml和用户配置users.xml等。（2）/var/lib/clickhouse：默认的数据存储目录（通常会修改默认路径配置，将数据保存到大容量磁盘挂载的路径）。（3）/var/log/clickhouse-server：默认保存日志的目录（通常会修改路径配置，将日志保存到大容量磁盘挂载的路径）。 接着是配置文件部分：（1）/etc/security/limits.d/clickhouse.conf：文件句柄数量的配置，默认值如下所示。 该配置也可以通过config.xml的max_open_files修改。（2）/etc/cron.d/clickhouse-server:cron定时任务配置，用于恢复因异常原因中断的ClickHouse服务进程，其默认的配置如下。 可以看到，在默认的情况下，每隔10秒就会使用condstart尝试启动一次ClickHouse服务，而condstart命令的启动逻辑如下所示。 如果ClickHouse服务正在运行，则跳过；如果没有运行，则通过start启动。最后是一组在/usr/bin路径下的可执行文件：（1）clickhouse：主程序的可执行文件。（2）clickhouse-client：一个指向ClickHouse可执行文件的软链接，供客户端连接使用。（3）clickhouse-server：一个指向ClickHouse可执行文件的软链接，供服务端启动使用。（4）clickhouse-compressor：内置提供的压缩工具，可用于数据的正压反解。 启动服务 在启动服务之前，建议修改默认的数据保存目录，将它切换到大容量磁盘挂载的路径。打开config.xml配置文件，修改数据保存的地址：vim /etc/clickhouse-server/config.xml 安装过程中clickhouse用户已经被创建，usermod -s /bin/bash clickhouse 在root用户下启动： 在启动成功之后，就可以使用客户端测试连接了：clickhouse-client 到此，单节点安装结束。 版本升级在使用离线RPM安装包安装后，可以直接通过rpm命令升级： 客户端的访问接口 ClickHouse的底层访问接口支持TCP和HTTP两种协议，其中，TCP协议拥有更好的性能，其默认端口为9000，主要用于集群间的内部通信及CLI客户端；而HTTP协议则拥有更好的兼容性，可以通过REST服务的形式被广泛用于JAVA、Python等编程语言的客户端，其默认端口为8123。通常而言，并不建议用户直接使用底层接口访问ClickHouse，更为推荐的方式是通过CLI和JDBC这些封装接口，因为它们更加简单易用。 ...

一、Spark SQL简介Spark SQL是Spark用来处理结构化数据的一个模块，它提供了一个编程抽象叫做DataFrame并且作为分布式SQL查询引擎的作用。 为什么要学习Spark SQL？我们已经学习了Hive，它是将Hive SQL转换成MapReduce然后提交到集群上执行，大大简化了编写MapReduce的程序的复杂性，由于MapReduce这种计算模型执行效率比较慢。所以Spark SQL的应运而生，它是将Spark SQL转换成RDD，然后提交到集群执行，执行效率非常快！同时Spark SQL也支持从Hive中读取数据。 二、Spark SQL的特点无缝集成在Spark中，将SQL查询与Spark程序混合。Spark SQL允许您使用SQL或熟悉的DataFrame API在Spark程序中查询结构化数据。适用于Java、Scala、Python和R语言。提供统一的数据访问，以相同的方式连接到任何数据源。DataFrames和SQL提供了一种访问各种数据源的通用方法，包括Hive、Avro、Parquet、ORC、JSON和JDBC。您甚至可以通过这些源连接数据。支持Hive集成。在现有仓库上运行SQL或HiveQL查询。Spark SQL支持HiveQL语法以及Hive SerDes和udf，允许您访问现有的Hive仓库。支持标准的连接，通过JDBC或ODBC连接。服务器模式为业务智能工具提供了行业标准JDBC和ODBC连接。三、核心概念：DataFrames和DatasetsDataFrameDataFrame是组织成命名列的数据集。它在概念上等同于关系数据库中的表，但在底层具有更丰富的优化。DataFrames可以从各种来源构建，例如： 结构化数据文件hive中的表外部数据库或现有RDDsDataFrame API支持的语言有Scala，Java，Python和R。 从上图可以看出，DataFrame多了数据的结构信息，即schema。RDD是分布式的 Java对象的集合。DataFrame是分布式的Row对象的集合。DataFrame除了提供了比RDD更丰富的算子以外，更重要的特点是提升执行效率、减少数据读取以及执行计划的优化。 DatasetsDataset是数据的分布式集合。Dataset是在Spark 1.6中添加的一个新接口，是DataFrame之上更高一级的抽象。它提供了RDD的优点（强类型化，使用强大的lambda函数的能力）以及Spark SQL优化后的执行引擎的优点。一个Dataset 可以从JVM对象构造，然后使用函数转换（map， flatMap，filter等）去操作。 Dataset API 支持Scala和Java。 Python不支持Dataset API。 四、创建DataFrames测试数据如下：员工表 定义case class（相当于表的结构：Schema）case class Emp(empno:Int,ename:String,job:String,mgr:Int,hiredate:String,sal:Int,comm:Int,deptno:Int)将HDFS上的数据读入RDD，并将RDD与case Class关联val lines = sc.textFile("hdfs://bigdata111:9000/input/emp.csv").map(_.split(","))把每个Array映射成一个Emp的对象val emp = lines.map(x => Emp(x(0).toInt,x(1),x(2),x(3).toInt,x(4),x(5).toInt,x(6).toInt,x(7).toInt))生成DataFrameval allEmpDF = emp.toDF通过DataFrames查询数据 将DataFrame注册成表（视图）allEmpDF.createOrReplaceTempView("emp")执行SQL查询spark.sql("select * from emp").show

魔盒是禧云自研的大数据开发协作平台，前一篇介绍了魔盒在离线任务打包过程中怎么提高RabbitMQ消费速度；数据开发人员通过魔盒不仅可以很方便的进行离线任务的打包、测试、上线，还可以方便的设置离线任务的串行、并行工作流调度；本文以创建一个需要依赖多个并行job的工作流为例，来介绍魔盒集成 Azkaban实现离线任务工作流调度的思路和流程。一. 离线计算魔盒管理离线任务禧云离线计算支持 Hive，Spark 等计算框架；数据开发人员用 Spark 编写完分析代码后，通过使用魔盒可以打包、测试、上线（详细可以看这篇文章）。二. 任务调度为什么需要工作流调度器一个完整的数据分析系统通常都是由大量任务单元组成： shell 脚本程序、java 程序、mapreduce 程序、hive 脚本等；各任务单元之间存在时间先后及前后依赖关系，禧云每天运行着上百个离线分析任务，不同优先级的任务调度时机也不同；为了很好地组织起这样的复杂执行计划，需要一个工作流调度系统来调度执行。crontab+shell为了解决上述问题，我们早期使用的是 crontab+shell 的方式来执行，但是这种方式的弊端如下： 任务之间的依赖关系完全依靠脚本来控制；在任务比较多的情况下，管理和维护起来比较麻烦；出现问题也难以排查。AzkabanAzkaban是由 Linkedin 开源的一个批量工作流任务调度器，优势如下： 可以在一个工作流内以一个特定的顺序运行一组工作和流程；可以通过一种 KV 文件格式来建立任务之间的依赖关系；并提供一个易于使用的 web 用户界面维护，通过它可以跟踪你的工作流。三.魔盒实现工作流调度魔盒的离线计算部分集成了 Azkaban，通过 ajax 调用接口的方式与 Azkaban 进行交互，用户不用登陆 Azkaban 的 web UI，直接通过魔盒就可以完成： 工作流的创建；工作流的删除；执行工作流；取消执行工作流；查看工作流执行记录、执行状态、执行时长等。下面我会介绍一下在魔盒中怎么去创建一个多个Job并行的工作流，要创建的工作流任务依赖关系图如下所示： 备注 Azkaban 流程名称以最后一个没有依赖的 job 定义的。1. 创建Spark任务工作流会依赖一个或多个任务，因此在创建工作流之前，需要准备好任务： 在魔盒中，通过指定任务处理类、设置执行任务所需的参数来创建 Spark 任务；任务创建成功后，通过魔盒的项目构建、测试无误后，会将运行任务所需要的 jar 包自动上传至 HDFS 中。 执行参数会以 JSON 字符串的格式存入表中去，大概格式如下： {"type":"spark","conf.spark.yarn.am.extraJavaOptions":"-Dhdp.version=3.1.0.0-78","conf.spark.history.fs.logDirectory":"hdfs://dconline/spark/eventlog","conf.spark.driver.extraJavaOptions":"-Dhdp.version=3.1.0.0-78","conf.spark.eventLog.enabled":"true","master":"yarn","conf.spark.dynamicAllocation.executorIdleTimeout":"60","deploy-mode":"cluster","queue":"develop",// 创建spark任务时表单里填写的任务处理类"class":"...Main",// 默认为空，会在创建工作流时赋值"name":"",// 默认为空，会在创建工作流时赋值"execution-jar":"",// 默认为空，会在创建工作流时赋值"dependencies":"",}主要执行参数解释name：spark 任务提交到 Yarn 平台上时的 application 名字；execution-jar： 为执行该任务时依赖的 jar 包；dependencies：在这里设置依赖关系（比如：task_a,task_b，则表明该工作流依赖task_a和task_b）；这三个参数默认值为空，在创建工作流的时候，会根据配置的工作流依赖关系，动态更新赋值。 备注 上图中，我创建了一个 spark 任务：离线任务测试001（离线任务测试001为魔盒中记录的任务名字，对应到 Azkaban 中的 job 名称为为：spark_task_10046）；照此步骤，还需要创建二个 spark 任务，分别对应job： spark_task_10006 和 spark_task_10008，这里不再截图展示。2. 身份验证所有 Azkaban API 调用都需要进行身份验证，其实就是模拟一个用户登录的过程。因此在与 Azkaban 进行交互之前，首先需要进行身份验证。 ...

近日，国内专业数据智能A股上市公司每日互动（个推）成立了“西湖数据智能研究院”。该研究院将为构建新时代数据智能创新大生态，加快数字经济与实体经济融合打造“超级大脑”。在西溪论数2020数据智能高峰论坛上，举行了西湖数据智能研究院”的发布与授牌仪式。。   西湖数据智能研究院由杭州市科技局和杭州市经济和信息化局联合指导，每日互动（个推）发起成立，旨在融合数据、技术与资本的力量，不断实现技术创新应用能级提升、产业数字化应用示范和数字人才培养三方面的高效协同，为杭州数字经济的发展增添强劲动能。研究院以“成为中国数据智能研究领域的领头雁”为愿景，下设人与时空联合实验室、网络安全联合实验室、智能风控实验室、人工智能联合实验室、动态本体实验室、安全计算实验室、数字健康联合实验室、浙大温州数智实验室等8个实验室。   西湖数据智能研究院执行院长姚建明现场详细介绍了研究院的发展和规划。目前，研究院下八大实验室都取得了不同程度的研究突破。例如，在人与时空领域，研究院通过研究人口、时间、空间的动态联系，为数字政务、城市管理、城市规划等提供全面客观的数据支持，助力城市发展科学决策；在安全计算领域，研究院通过探索研究联邦学习，建立起安全、可信赖的中立国计算模式，促成消除数据孤岛，保障数据安全。   未来，研究院将以每日互动（个推）现有的研发设备、研发人才和数据资源为基础，打造新时代数据智能技术创新策源地、典型场景应用先行地、企业培育发展主阵地、高层次人才集聚地，建设成为国家新一代数据智能创新发展试验场所。   学术研究一直是数据智能产业核心竞争力的重要组成部分。现场，姚院长也表示希望各位专家学者踊跃加入，不断为西湖数据智能研究院的发展注入新鲜的学术端血液，与研究院一起，用数据智能更好地服务社会，推动数字化经济发展。   每日互动（个推）作为西湖数据智能研究院的发起方，一直以来都非常重视技术研发与人才队伍建设，不断加大新产品研发力度、积极建设大数据平台、持续探索多垂直领域应用。除此次发起成立的西湖数据智能研究院外，每日互动（个推）也积极与各类顶尖科研机构、高等学府成立多个数据智能联合实验室，共同推进大数据、人工智能等尖端技术的飞速发展。   未来，每日互动（个推）将充分发挥自身的数据及技术优势，整合资源，将西湖数据智能研究院打造成顶级的产学研一体化殿堂。西湖数据智能研究院也将稳扎稳打，在推进数字产业化、产业数字化、城市数字化“三化融合”的道路上发挥更加积极的作用。可以看到的是，一个能够为数据智能提供无限想象的顶级研究机构，正朝着我们走来。   

个推资深数据分析师 远见 在数据智能时代，对企业而言，“数据驱动业务”或者“数据即是业务”的理念逐渐成为业界的一种共识。然而，数据孤岛、数据标准不统一等问题在一定程度上阻碍了数据资产价值的最大化体现。个推作为专业的数据智能服务商，在数据治理方面有着丰富的实践，旨在帮助提升效率、节省成本、获取数据资产价值。 本文将从三部分讲述个推数据治理：数据治理概念解析、数据实践、常见问题分析。 01 什么是数据治理 讲具体概念前，我们先看一个生活中的例子。大家去超市买菜或买水果时，通过分区指引很快就会找到对应的蔬菜区和水果区。蔬果有打包好的、散称的，方便大家自助购买。而老的菜市场模式，菜品有些在台面上，有些还在袋子里，我们需要问老板有茄子没？有西红柿没？多少钱1斤等等。或者更原始的自家种菜模式，需要时临时去采摘。通过上述模式对比，如果我们是数据使用者，我们期望通过什么样的方式使用数据呢？数据治理的一个工作就是让数据从混乱无序到规整统一的过程，让数据使用更便捷。 图片来源自摄图网 数据治理目标 企业数据治理的目标主要是为了企业能够快速发展和效益的最大化，比如提升效率（数据开发效率或者使用效率）、节省成本、业务创新增收、风险控制等。企业通过治理运营可以及时发现并规避一些经营风险问题，有效确保数据使用的合理性与合规性。 数据治理规范 根据ISO定义，数据治理 (Data Governance, DG) 就是以服务组织战略目标为基本原则，通过组织成员的协同努力、流程制度的制定以及数据资产的梳理、采集清洗、结构化存储、可视化管理和多维度分析，实现数据资产价值获取、业务模式创新和经营风险控制的过程。治理工作旨在让数据使用更便捷，价值更易被挖掘。 上图是我们国家标准化管理委员会于18年6月发布，19年初正式实施的《数据治理规范》。由图可知，数据治理一共分为四大模块：顶层设计、数据治理环境、数据治理域、数据治理过程。其中，顶层设计是数据治理工作的基础。数据治理工作会涉及到多部门、多团队、多工种，需要根据组织当前的业务和数据现状，设定实体或虚拟组织机构，确保治理工作朝着组织战略目标前进。 目前，个推也设立了各专业的委员会和执行组织，负责把控数据工作的目标和方向、指导数据工作的开展落地等。 数据治理环境是数据治理得以成功实施的保障条件。开展数据治理之前我们需要理清领导层、管理层、业务层、执行层等等利益相关方的需求，同时识别出项目支持力量和阻力。值得注意的是，数据治理工作是个长期的过程。有关准备工作和支持力量不容忽视，因为两者直接决定了后续工作的推进是否顺利。 架构中部的数据治理域主要负责治理工作相关的制度规范、流程的制定和落地。数据治理域由数据管理体系与数据价值体系两部分构成。前者主要包括数据质量、数据安全相关的标准制度，后者主要指的是数据共享、数据服务和数据使用分析体系相关的制度。 数据治理工作需要长期持续投入，所以在具体执行过程中，我们就需要考虑用正循环的闭环方式去开展。治理过程主要包括确定数据治理目标、制定数据治理计划、执行业务梳理、设计数据架构、采集清洗数据、存储核心数据、实施元数据管理和数据血缘追踪，并定期检查治理结果与治理目标的匹配程度。 02 数据治理实践 治理工作的主要流程可以概括为“理—采—存—管—用”。“理”指的是理组织、理业务、理数据；“采”指的是让这些数据能方便地流入到中心集群中；“管”是治理的核心，指的是管元数据、管质量等等。“用”这个环节，常规方式一般是通过API予以提供。基于此流程，个推构建了自己的数据治理平台。 本文主要从系统建设层面论述数据治理的具体实践过程，系统外的工作将不再赘述。 数据集成 系统工作首先需要进行数据集成，该环节也是数据汇集和后续开展治理的前提。目前个推的数据集成模块以标准化接入为主，通过Flume采集数据到Kafka集群，再由Camus进行消费然后落地到HDFS。相较于之前需要多团队协作才能完成的数据接入工作，现在数据分析人员仅通过个推数据集成模块即可完成相应的工作。此外，为了解决数据的异地互备问题，个推还研发了数据拉取、同步功能。核心的底盘数据会通过该功能，同步到多IDC机房和集群，这样一旦某一机房发生故障，业务还可以在其他集群进行正常运转。 安全管理 为保证数据使用的安全性以及授权工作的高效化，个推构建了用户维度的角色体系和数据维度的安全策略体系。管理员根据用户所需的权限，即可进行合理化的授权。 1） 用户角色 用户角色的本质在于用户分组。我们将用户分成不同组，并赋予每个组的用户不同的权限等级。权限等级可根据人员的入职时间和岗位要求等予以设定，也可根据线上线下任务情况以及业务场景予以设定。 2）数据安全和策略 数据安全策略支持表、字段、行三种策略。表策略解决DB里相关的表是否可被使用的问题；字段策略解决表中字段是否可见及脱敏问题。个推通过去多重、去标识化的手段进行脱敏处理，有效解决了访问控制问题。 03 数据治理各阶段常见问题分析 数据查找阶段-表维度 在数据查找环节，我们会对用户设置归属组或者对数据进行打标。用户可以了解其所在组权限内的所有数据。这些数据基于访问热度，从高频到低频进行排序。根据28原则，20%的高频数据能满足80%工作需求。新员工就可以用最快的时间快速熟悉相关业务数据，数据源涵盖了Hive、HBase、MYSQL等介质。 表格上方设置了搜索框，支持表、路径、标签等维度的查询。如果发现所需数据后，我们可以进行收藏。在后续进行数据变更时，该治理平台可以及时通知使用方和收藏方；该平台也可以在新增数据资产时，根据用户使用数据的特点，进行新资产的推荐，从而提升数据使用效率，实现数据价值的最大化。 数据查找阶段-字典维度 除了表维度的查找方式，我们也提供了字典维度的查询。比如上图的地区字段，涉及到了40张表。我们只需要一键点击，这些表格就会自动按照热度进行排序。 数据学习阶段 数据的基本信息模块不仅包含字段说明、简要、生产程序、负责人、大小、标签、权限等信息，还提供对数据各字段的基本描述统计信息和样例展示。如果不满足于平台上已有的信息，我们可以通过该数据的基本信息模块找到数据生产负责人，进行进一步沟通、学习。 数据开发落地阶段 在数据开发和分析环节，个推数据治理平台支持查看数据大小、分区和文件数等信息。处理小量数据时，我们可以采用count(distinct *)方法，操作方便。但当处理百G或T级别数据量时，该方法就不奏效了。我们需要用group by 后再做count。 参照百度百科、维基百科等知识众包平台的理念，数据治理平台还提供了数据的实现逻辑、适用范围、更新历史和最佳实践板块。开发者在使用数据过程中就可以把数据的适用范围和最佳实践等信息更新到平台上。 数据链路的复杂性以及数据使用场景的多样性，会对测试和上线工作带来一定的挑战。为此，我们需要构建一个数据血缘模块，理清数据和服务的上下游。在此基础上，平台还提供了数据近期使用的频次信息，便于我们进行数据上下线的通知，也为后续数据生命周期的科学管理提供决策依据。 本文主要介绍了个推数据治理实践工作。作为拥有海量数据沉淀的数据智能公司，个推也将不断打磨自身技术，持续创新数据治理模式，与开发者一同分享数据治理实践的前沿理念与方法。 完整版分享材料获取 关注【个推技术学院】微信公众号 （微信号：getuitech） 回复关键词“数据智能” 即可领取数据治理实践完整版分享材料！  此外，通过视频链接还可观看本文配套解析： http://live.vhall.com/221291802 ...

摘要：HBase自带许多运维工具，为用户提供管理、分析、修复和调试功能。本文将列举一些常用HBase工具，开发人员和运维人员可以参考本文内容，利用这些工具对HBase进行日常管理和运维。HBase组件介绍HBase作为当前比较热门和广泛使用的NoSQL数据库，由于本身设计架构和流程上比较复杂，对大数据经验较少的运维人员门槛较高，本文对当前HBase上已有的工具做一些介绍以及总结。 写在前面的说明： 1） 由于HBase不同版本间的差异性较大（如HBase2.x上移走了hbck工具），本文使用的所有命令行运行的环境为MRS_1.9.3，对应的HBase版本为1.3.1，部分命令在HBase2上不支持（有时间的话会对HBase2做单独的介绍）。 2） 本文所涉及的HBase工具均为开源自带工具，不涉及厂商自研的优化和运维工具。 Canary工具HBase Canary是检测HBase集群当前状态的工具，用简单的查询来检查HBASE上的region是否可用（可读）。它主要分为两种模式 1） region模式（默认），对每个region下每个CF随机查询一条数据，打印是否成功以及查询时延。 #对t1和tsdb-uid表进行检查 hbase org.apache.hadoop.hbase.tool.Canary t1 tsdb-uid #注意：不指定表时扫所有region2） regionserver模式，对每个regionserver上随机选一个表进行查询，打印是否成功以及查询时延。 #对一个regionserver进行检查 hbase org.apache.hadoop.hbase.tool.Canary -regionserver node-ana-coreQZLQ0002.1432edca-3d6f-4e17-ad52-098f2adde2e6.com #注意：不指定regionserver时扫所有regionserverCanary还可以指定一些简单的参数，可以参考如下 总结： 对集群影响：2星（只是简单的读操作，region个数极多的时候会占用少部分请求吞吐）实用性：2星HFile工具HBase HFile查看工具，主要用来检查当前某个具体的HFile的内容/元数据。当业务上发现某个region无法读取，在regionserver上由于文件问题无法打开region或者读取某个文件出现异常时，可用此工具单独来检查HFile是否有问题 #查看t1表下的其中一个HFile的详情，打印KVhbase org.apache.hadoop.hbase.io.hfile.HFile -v -m -p -f /hbase/data/default/t1/4dfafe12b749999fdc1e3325f22794d0/cf1/06e102be436c449693734b222b9e9aab使用参数如下： 总结： 对集群影响：1星（此工具不走HBase通道，只是单纯的读取文件，不影响集群）实用性：4星（可精确判断具体的HFile内容是否有问题）RowCounter和CellCounter工具RowCounter 是用MapReduce任务来计算表行数的一个统计工具。而和 RowCounter类似，但会收集和表相关的更细节的统计数据，包括：表的行数、列族数、qualifier数以及对应出现的次数等。两个工具都可以指定row的起止位置和timestamp来进行范围查询 # RowCounter扫描t1hbase org.apache.hadoop.hbase.mapreduce.RowCounter t1#用CellCounter扫描t1表并将结果写入HDFS的/tmp/t1.cell目录hbase org.apache.hadoop.hbase.mapreduce.CellCounter t1 /tmp/t1.cell使用参数如下： 总结： 对集群影响：3星（需要起MapReduce对表所有region进行scan，占用集群资源）实用性：3星（HBase统计自身表行数的唯一工具， hbase shell中count效率比较低）Clean工具clean命令是用来清除HBase在ZooKeeper合HDFS上数据的工具。当集群想清理或铲除所有数据时，可以让HBase恢复到最初的状态。 #清除HBase下的所有数据hbase clean --cleanAll使用参数如下： 总结： 对集群影响：5星（删除HBase集群上所有数据）实用性：2星（除开需要重新设置HBase数据的场景如要切换到HBase on OBS，平时很少会用到）HBCK工具HBase的hbck工具是日常运维过程中使用最多的工具，它可以检查集群上region的一致性。由于HBase的RIT状态较复杂也最容易出现问题，日常运维过程中经常会遇到region不在线/不一致等问题，此时就可以根据hbck不同的检查结果使用相应的命令进行修复。 #检查t1表的region状态hbase hbck t1#修复t1表的meta并重新assign分配hbase hbck -fixMeta -fixAssignments t1由于该工具使用的场景太多太细，此处就不作展开介绍了，可以查看参数的描述来对各种异常场景进行修复。注意：在不清楚异常原因的情况下，千万不要乱使用修复命令病急乱投医，很有可能会使问题本身更糟糕。 ...

导读：众所周知，在大数据/数据库领域，数据的存储格式直接影响着系统的读写性能。spark是一种基于内存的快速、通用、可扩展的大数据计算引擎，适用于新时代的数据处理场景。在“大数据实践解析（上）：聊一聊spark的文件组织方式”中，我们分析了spark的多种文件存储格式，以及分区和分桶的设计。接下来，本文通过简单的例子来分析在Spark中的读写流程，主要聚焦于Spark中的高效并行读写以及在写过程中如何保证事务性。 1、文件读如何在Spark中做到高效的查询处理呢？这里主要有两个优化手段： 1）减少不必要的数据处理。数据处理涉及文件的IO以及计算，它们分别需要耗费大量的IO带宽和CPU计算。在实际的生产环境中，这两类资源都是有限的，同时这些操作十分耗时，很容易成为瓶颈，所以减少不必要的数据处理能有效提高查询的效率； 以下面的查询为例： spark.read.parquet("/data/events").where("year = 2019").where("city = 'Amsterdam'").select("timestamp")由于在events表中按照year字段做了分区，那么首先通过 year 字段我们就可以过滤掉所有year字段不为 2019 的分区： 因为文件是parquet的文件格式，通过谓词下推可以帮助我们过滤掉 city 字段不是 "Amsterdam" 的 row groups；同时，由于我们的查询最终需要输出的投影字段只有 "timestamp" ，所以我们可以进行列裁剪优化，不用读取其他不需要的字段，所以最终整个查询所读的数据只有剩下的少部分，过滤掉了大部分的数据，提升了整体的查询效率： 2）并行处理，这里主流的思想分为两类：任务并行和数据并行。任务并行指充分利用多核处理器的优势，将大的任务分为一个个小的任务交给多个处理器执行并行处理；数据并行指现如今越来越丰富的SIMD指令，一次动作中处理多个数据，比如AVX-512可以一次处理16个32bit的整型数，这种也称为向量化执行。当然，随着其他新硬件的发展，并行也经常和GPU联系在一起。本文主要分析Spark读流程中的任务并行。 下面是Spark中一个读任务的过程，它主要分为三个步骤： （1）将数据按照某个字段进行hash，将数据尽可能均匀地分为多个大小一致的Partition； （2）发起多个任务，每个任务对应到图中的一个Executor； （3）任务之间并行地进行各自负责的Partition数据读操作，提升读文件效率。 2、文件写Spark写过程的目标主要是两个：并行和事务性。其中并行的思想和读流程一样，将任务分配给不同的Executor进行写操作，每个任务写各自负责的数据，互不干扰。 为了保证写过程的事务性，Spark在写过程中，任何未完成的写都是在临时文件夹中进行写文件操作。如下图所示：写过程中，results文件夹下只存在一个临时的文件夹_temporary；不同的job拥有各自job id的文件目录，相互隔离；同时在各目录未完成的写操作都是存在临时文件夹下，task的每次执行都视为一个taskAttempt，并会分配一个task attempt id，该目录下的文件是未commit之前的写文件。 当task完成自己的写任务时，会进行commit操作，commit成功后，该任务目录下的临时文件夹会移动，写文件移到对应的位置，表示该任务已经写完成。 当写任务失败时，首先需要删除之前写任务的临时文件夹和未完成的文件，之后重新发起该写任务（relaunch)，直到写任务commit提交完成。 整个任务的描述可用下图表示，如果commit成功，将写完成文件移动到最终的文件夹；如果未commit成功，写失败，删除对应的文件，重新发起写任务。当写未完成时，所有写数据都存在对应的临时文件中，其他任务不可见，直到整个写commit成功，保证了写操作的事务性。 当所有任务完成时，所有的临时文件夹都移动，留下最终的数据文件，它是最终commitJob之后的结果。 本文介绍的算法是 FileOutputCommitter v1的实现，它的commitJob阶段由Driver负责依次移动数据到最终的目录。但是在当前广泛应用的云环境下，通常采取存算分离的架构，这时数据一般存放在对象存储中（如AWS S3，华为云OBS），Spark FileOutputCommitter中的数据移动并不像HDFS文件系统移动那么高效，v1的commitJob过程耗时可能会非常长。为了提升FileOutputCommitter 的性能，业界提出了FileOutputCommitter v2的实现，它们可以通过 spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version = 1或2 配置项来设置，它和v1的不同点在于，每个Task在commitTask时就将文件移动到最终的目录，而在commitJob时，Driver只需要负责将Task留下来的空目录删除，这样相比 v1 带来好处是性能提升， 但是由于commit task时直接写最终目录，在执行未完成时，部分数据就对外可见。同时，如果job失败了，成功的那部分task产生的数据也会残留下来。这些情况导致spark写作业的事务性和一致性无法得到保障。 其实v1也不完全一定能保证数据一致性，文件移动过程中完成的数据对外是可见的，这部分数据外部已经可以读取，但是正在移动和还未移动的数据对外是不可见的，而在云环境下，这个移动耗时会进一步加长，加重数据不一致的情况。 那么有没有能够使得Spark 分析在云环境下也可以保证数据的事务性和一致性的解决方案呢？华为云数据湖探索DLI（Data Lake Insight）改进了v1和v2这两种算法，使得Spark 分析在云环境下也可以保证数据的事务性和一致性，同时做到高性能，并且完全兼容Apache Spark和Apache Flink生态， 是实现批流一体的Serverless大数据计算分析服务，欢迎点击体验。 ...

摘要：本文针对“数据牵引改进，工具固化规范”这一思路在业务团队落地过程中的动作流程进行详细阐述，并明确了支撑整个流程的关键角色定义和组织运作形式。目的为实现云服务开发的过程可信，需要基于数据对各个服务产品部的可信变革动作进行数据采集、进展可视、目标牵引、能力评估，最终用数据反映目标达成。与传统的“基于数据晾晒驱动业务团队改进，6+1指标度量”的运作方式有本质的区别，我们是基于统一的作业工具上产生的客观数据呈现，识别研发过程中基本的流程断裂点和质量缺失动作，和业务团队达成一致的目标后，把大部分改进动作固话到作业工具中自动化承载，我们称这个思路为“数据牵引改进，工具固化规范”，也就是我们不仅告诉业务团队哪里有问题，同时也要基于我们的作业工具，辅助业务团队一起改进完善。 本文针对“数据牵引改进，工具固化规范”这一思路在业务团队落地过程中的动作流程进行详细阐述，并明确了支撑整个流程的关键角色定义和组织运作形式。 数据牵引改进，是指关注软件交付过程中各种度量数据的收集、统计、分析和反馈，通过可视化的数据客观反映整个研发过程的状态，以全局视角分析系统约束点，并和业务团队达成共识，提炼出客观有效的改进目标；工具固化规范，针对识别出来的Gap点和重点问题进行分析，制定出可以在作业工具承载的模板规范，以及需要工程师行为做出改变的能力要求，并在作业工具上对这些规范要求的落地效果进行检查，用数据度量改进效果。最后，对改进项目进行总结分享，打造学习型组织，不断驱动持续改进和价值交付，牵引研发团队模式和文化的转变。 2020年的研发过程可信围绕CleanCode、构建、开源、E2E追溯四个领域开展，这也是公司要求的可信变革中最基本、最重要、投入产出比最大的四个点。 整体流程说明整个运作流程，围绕数据，按照“定义软件工程规范->定义数据分析模型->工具实现数据度量和分析->数据运营发现实际软件工程活动和规范的偏差->工具辅助团队改进->工具固化软件工程规范”这个流程进行实施，并对最终效果进行阶段性总结。随着业务团队能力的提升以及软件工程规范性、开发模式的改变，对最初定义的软件工程规范，会阶段性的进行完善，循环往复、持续优化，最终让业务团队在遵守公司要求的研发过程可信规范的前提下，实现业务成功。 1) 定义软件工程规范：围绕公司可信变革的目标，BU对各个服务产品部的研发模式规范和能力要求，COE制定适合BU现状的软件工程规范； 2) 定义数据模型：COE针对制定的软件工程规范，提炼出核心的、有针对性、可用工具度量的数据模型，并且和各个服务产品部达成一致； 3) 工具实现数据度量和分析：根据这几个数据模型，数据分析工具自动从数据源进行采集、汇总、计算，并把结果呈现在数据看板上；业务团队可以打开汇总数据，根据明细数据进行动作规范自检和改进； 4) 数据运营发现实际软件工程活动和规范的偏差：数据治理小组在实际运营过程中，分析度量指标的数据，识别业务团队实际的软件工程活动和要求规范不一致的Gap点和关键问题； 5) 工具辅助业务团队改进：COE针对分析出来的Gap点和关键问题，制定相应的改进措施，作业工具承载流程规范模板化整改，并针对业务团队的不规范行为，制定适合各个服务产品部的公约要求，促使业务团队人员能力提升； 6) 工具固化软件工程规范：针对业务团队的公约要求，在作业工具上进行check，最终作业工具承载了整个软件工程规范要求，以及融入到作业流程中的规范要求事前检查。 三层数据分析模型我们采用了三层数据分析模型，由作业工具自动采集用户研发过程行为明细数据，数据分析工具进行准实时汇总计算呈现总体目标，三层数据系统性的辅助业务团队系统性的识别研发过程中的不规范点和能力短板，让业务团队“知其然，知其所以然”。这三层数据模型是层层深入，迭代完善，下层支撑上层的关系。 第一层：目标、进展、结果数据分析；和公司可信变革目标牵引对齐，结合BU实际情况，形成BU的整体可信要求，并在数据分析看板上呈现各个服务产品部要达成的过程可信目标、每日的改进进展和最终完成情况；例如，对各个服务产品部要求达成CleanCode的目标。 第二层：词法/语法分析数据；COE针对第一层的目标牵引，分解出来的具体实施环节的度量指标，只有这些分解的指标都完成，第一层的目标才达成。这一层数据的目的主要是围绕帮助业务团队分析自己的能力短板在哪里，进行有针对性的改进指；通过打开汇总数据的层层下钻，用明细数据来分析业务团队在DevSecOps软件工程规范流程中关键动作执行的缺失点，并针对性的制定改进规范要求，牵引作业工具或者业务团队补齐该部分缺失动作；例如，CleanCode的过程可信目标达成，可以分解成：静态检查配置合规率、Committer合入保障率、代码仓Clean三个目标，只有这三个目标达成，就可以认为CleanCode总体目标达成。 第三层：语义分析数据：COE打开第二层数据，不仅要看这些关键动过做没做，还要看做的效果怎么样，最终效果体现在业务团队的DevSecOps软件工程规范提升；这一层的数据分析聚焦在防止为了指标而做第二层的数据，而是看业务团队是否在真正参考BU制定的规范牵引的目标，提升业务交付过程中的效能、可信、质量能力，以及最终产生实际的业务效果。通过打开各个团队的明细数据分析审视业务团队执行的关键动作是否符合规范，是否在合适的阶段点执行，执行效果是否有效；并阶段性的总结和提炼经验，形成知识资产固化到作业工具。例如，针对第二层的静态检查配置合规率，可以分解为：静态检查配置有效性和静态检查执行有效性。静态检查配置有效性，包括：检查静态检查工具配置的数量、是否符合BU的配置规范，以及是否在代码合入主干master时进行了配置；静态检查执行有效性，主要看是否每一次MR提交时都执行静态检查、是否发现问题在研发活动的最早阶段，拦截的问题的效果怎么样。只有第三层的动作度量都达成后，才可以说第二层的目标是达成的。 数据治理过程流程图为了实现“数据牵引改进，工具固化规范”这个目标，准确、一致、准实时的数据是核心关键，但因为数据采集不完整、业务团队不规范、数据呈现维度不一致等原因，数据的准确性有一个不断提升的过程，因此需要对各个层级展示的数据进行治理。整个数据治理过程中，由“业务团队/作业工具/治理小组/数据分析工具（阿基米德）/COE”五个角色紧密配合，而且以年/半年为目标，不断总结经验，循环往复、持续优化的过程。 a) COE：和公司可信变革目标牵引对齐，结合BU能力现状，形成BU的整体可信要求； b) COE：针对BU的业务现状，定义出适合BU现状的软件工程规范要求；业务团队：和BU发布的各个领域的软件工程规范牵引目标达成一致； c) COE：针对规范分解出核心的度量指标，并制定度量数据模型； d) 研发用户：在使用作业工具进行研发活动；作业工具：承载了BU各个服务产品部在使用过程中沉淀的行为数据； e) 数据分析（阿基米德）：准实时接入作业工具的数据，展示各个服务产品部当前的研发能力现状； f) COE：和各个服务产品部达成一致，制定各个服务产品部的年度牵引目标； g) 数据分析（阿基米德）：用数据呈现各个服务产品部的牵引目标和能力现状，统一数据口径；呈现月/周/天的明细数据，以及支撑Gap分析和重点问题的数据视图； h) COE：根据牵引目标和能力现状，分析Gap原因和关键问题；治理小组：在数据运营过程中，根据数据分析团队当前的能力现状是否和数据呈现一致； i) 研发用户：可以实时登录数据工具（阿基米德）进行查看各个层级的明细数据； j) 治理小组：根据准实时进展数据，分析当前团队研发过程中的实际问题，并汇总给COE； k) COE：结合细粒度的分析数据、以及治理小组汇总出来的各个服务产品部的实际问题，制定规范和改进措施，包括作业工具的规范和研发用户的动作行为公约； l) 作业工具：承载作业工具上落地的规范要求；治理小组：作为接口人，承接研发工程师的行为规范公约，结合各个服务产品部实际情况来负责落地； m) 研发用户：按照规范要求和针对数据的自检进行研发过程行为规范化； n) 研发工具：对研发用户的行为规范是否满足要求进行自动化检查；最终目标是让整个软件工程规范都固化在工具中进行承载； o) 数据分析（阿基米德）：呈现按照规范改进后的明细数据和汇总目标；研发用户：自助查看整改后的明细数据； p) COE：根据数据改进的效果，以及过程中暴露的问题进行总结后形成经验资产，并持续改进； 数据流图过程可信的数据在各个工具系统中采集、流转、汇聚、分析、呈现，整个数据流图如下： 其中，识别出6个重要的全量数据源： a) 代码库数据：该数据由伏羲的服务信息树上配置的代码库数据，加上阿基米德上人工配置的代码库，构成各个云服务发布到生产仓的代码全集； b) Workitem信息流数据：当前识别vision上的需求、问题、task，加上Gitlab/Codeclub上的issue，构成可识别的Workitem数据全集； c) SRE现网包数据：包括普罗部署、CCE、CPS、CDK各种类型部署的包数据，构成全量现网包数据； ...

一、什么是工作流？工作流（WorkFlow）就是工作流程的计算模型，即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。工作流要解决的主要问题是：为实现某个业务目标，在多个参与者之间，利用计算机，按某种预定规则自动传递。下面我们以“员工请假的流程”为例，来为大家介绍什么是工作流。 这个例子包含了一个完整的员工请假流程。从“请假流程开始”，到“员工填写请假条”，再到“部门经理审批”，如果审批不通过，流程回到“员工填写请假条”；如果部门经理审批通过，则流程进入下一个节点；直到最后的流程结束。在Java中，我们可以使用一些框架帮助我们来实现这样的过程。Java的三大主流工作流引擎分别是：Shark，osworkflow，JBPM 二、什么是Oozie？关于什么是Oozie，其实Oozie是服务于Hadoop生态系统的工作流调度工具，Job运行平台是区别于其他调度工具的最大的不同。但其实现的思路跟一般调度工具几乎完全相同。Oozie工作流通过HPDL(一种通过XML自定义处理的语言,类似JBOSS JBPM的JPDL)来构造。Oozie工作流中的Action在运程系统运行如(Hadoop，Pig服务器上)。一旦Action完成，远程服务器将回调Oozie的接口 并通知Action已经完成，这时Oozie又会以同样的方式执行工作流中的下一个Action，直到工作流中所有Action都完成(完成包括失败)。Oozie工作流提供各种类型的Action用于支持不同的需要，如Hadoop Map/Reduce，Hadoop File System，Pig，SSH，HTTP，Email，Java以及Oozie子流程。Oozie也支持自定义扩展以上各种类型的Action。 一个正常工作的Oozie系统须包含如下四个模块：Oozie Client、Oozie Server、DataBase和Hadoop集群。 Oozie Client可以通过Web Service API、Java API、Command line 方式向Oozie Server提交工作流任务请求。Oozie客户端可以通过REST API或者Web GUI来从Oozie服务端获取Job的日志流。通常在Client端包括工作流配置文件、工作流属性文件和工作流库。Oozie Server负责接收客户端请求、调度工作任务、监控工作流的执行状态。Oozie本身不会执行具体的Job，而是将Job的配置信息发送到执行环境。DataBase用于存储Bundle、Coordinator、Workflow工作流的Action信息、Job信息，记录Oozie系统信息。简单说，除了Oozie 运行日志存在本地硬盘不存在DB中，其他信息都存储到DB。Hadoop集群运行Oozie工作流的实体，负责处理Oozie Server提交来的各种Job。包括HDFS、MapReduce、Hive、Sqoop等Hadoop组件提交的Job。三、编译Oozie使用的版本信息如下Hadoop 2.4.1JDK 1.7Maven 3.5.0Oozie 4.3在oozie解压后的目录下，编译oozie，执行命令：bin/mkdistro.sh -DskipTests -Dhadoop.version=2.4.1注意：如果第一次安装，Maven会自动下载依赖的jar包，时间可能    会比较长。 如果出现下面的错误，表示Maven的内存溢出。 设置环境变量：export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=128m"，并且重新编译。编译完成，成功出现以下提示。 四、安装部署Oozie解压安装包tar -zxvf oozie-4.3.0-distro.tar.gz -C ~/training/设置环境变量 建立MySQL数据库create database oozie;create user 'oozieowner'@'%' identified by 'password'; grant all on oozie.* TO 'oozieowner'@'%'; grant all on oozie.* TO 'oozieowner'@'localhost' identified by 'password';修改文件：conf/oozie-site.xml 配置oozie的web console（*）创建目录：mkdir /root/training/oozie-4.3.0/libext（*）将文件ext-2.2.zip和mysql的驱动上传到这个目录（*）拷贝$HADOOP_HOME/share/hadoop/*/*.jar和$HADOOP_HOME/share/hadoop/*/lib/*.jar到Oozie的libext目录下（*）由于hadoop和oozie自带的tomcat jar包有冲突，所以需要把冲突的jar包驱动。执行下面的命令： cd /root/training/oozie-4.3.0/libext mv servlet-api-2.5.jar servlet-api-2.5.jar.bak mv jsp-api-2.1.jar jsp-api-2.1.jar.bak mv jasper-compiler-5.5.23.jar jasper-compiler-5.5.23.jar.bak mv jasper-runtime-5.5.23.jar jasper-runtime-5.5.23.jar.bak 初始化oozie（*）生成oozie web console的war包：oozie-setup.sh prepare-war（*）初始化数据库：ooziedb.sh create -sqlfile oozie.sql -run（*）将不同任务依赖的共享jar包上传到HDFS： oozie-setup.sh sharelib create -fs hdfs://hadoop111:9000（*）修改oozie-4.3.0/oozie-server/conf/server.xml，注释掉下面的记录： ...

一、Kafka持久化概述Kakfa 依赖文件系统来存储和缓存消息。对于硬盘的传统观念是硬盘总是很慢，基于文件系统的架构能否提供优异的性能？实际上硬盘的快慢完全取决于使用方式。同时 Kafka 基于 JVM 内存有以下缺点： 对象的内存开销非常高，通常是要存储的数据的两倍甚至更高随着堆内数据的增加，GC的速度越来越慢实际上磁盘线性写入的性能远远大于任意位置写的性能，线性读写由操作系统进行了大量优化（read-ahead、write-behind 等技术），甚至比随机的内存读写更快。所以与常见的数据缓存在内存中然后刷到硬盘的设计不同，Kafka 直接将数据写到了文件系统的日志中： 写操作：将数据顺序追加到文件中读操作：从文件中读取这样实现的好处： 读操作不会阻塞写操作和其他操作，数据大小不对性能产生影响硬盘空间相对于内存空间容量限制更小线性访问磁盘，速度快，可以保存更长的时间，更稳定。二、Kafka的持久化原理解析一个 Topic 被分成多 Partition，每个 Partition 在存储层面是一个 append-only 日志文件，属于一个 Partition 的消息都会被直接追加到日志文件的尾部，每条消息在文件中的位置称为 offset（偏移量）。 如下图所示，我们之前创建了mytopic1，具有三个分区。我们可以到对应的日志目录下进行查看。 Kafka日志分为index与log（如上图所示），两个成对出现：index文件存储元数据，log存储消息。索引文件元数据指向对应log文件中message的迁移地址；例如2,128指log文件的第2条数据，偏移地址为128；而物理地址（在index文件中指定）+ 偏移地址可以定位到消息。 我们可以使用Kafka自带的工具来查看log日志文件中的数据信息：

Kakfa在大数据消息引擎领域，绝对是没有争议的国民老公。 这是kafka系列的第一篇文章。预计共出20篇系列文章，全部原创，从0到1，跟你一起死磕kafka。 本文盘点了 Kafka 的各种术语并且进行解读，术语可能比较枯燥，但真的是精髓中的精髓！ 了解Kafka之前我们必须先掌握它的相关概念和术语，这对于后面深入学习 Kafka 各种功能将大有裨益。所以，枯燥你也得给我看完！ 大概是有这么些东西要掌握，不多不多，预计20分钟可以吃透： 主题层主题层有三个儿子，分别叫做:Topic、Partition、Replica。既然我说是三个儿子，那你懂了，是不可分割的整体。 Topic（主题）Kafka 是分布式的消息引擎系统，它的主要功能是提供一套完备的消息（Message）发布与订阅解决方案。 在 Kafka 中，发布订阅的对象是主题（Topic），你可以为每个业务、每个应用甚至是每类数据都创建专属的主题。 一个Topic是对一组消息的归纳。也可以理解成传统数据库里的表，或者文件系统里的一个目录。 Partition（分区）一个Topic通常都是由多个partition组成的，创建topic时候可以指定partition数量。 ???? 分区优势 为什么需要将Topic分区呢？如果你了解其他分布式系统，你可能听说过分片、分区域等说法，比如 MongoDB 和 Elasticsearch 中的 Sharding、HBase 中的 Region，其实它们都是相同的原理。 试想，如果一个Topic积累了太多的数据以至于单台 Broker 机器都无法容纳了，此时应该怎么办呢？ 一个很自然的想法就是，能否把数据分割成多份保存在不同的机器上？这不就是分区的作用吗？其实就是解决伸缩性的问题，每个partition都可以放在独立的服务器上。 当然优势不仅于此，也可以提高吞吐量。kafka只允许单个partition的数据被一个consumer线程消费。因此，在consumer端，consumer并行度完全依赖于被消费的分区数量。综上所述，通常情况下，在一个Kafka集群中，partition的数量越多，意味着可以到达的吞吐量越大。 ???? partition结构 每个partition对应于一个文件夹，该文件夹下存储该partition的数据和索引文件。 如图所示,可以看到两个文件夹，都对应着一个叫做asd的topic，在该台服务器上有两个分区，0和2，那么1呢？在其他服务器上啦！毕竟是分布式分布的！ 我们进去asd-0目录中看看是什么？有后缀为.index和.log的文件，他们就是该partition的数据和索引文件： 现在先不管它们是何方神圣，因为我会在【分区机制原理】这篇文章中详细描述。 ???? partition顺序性 现在，我需要你睁大眼睛看看关于分区非常重要的一点： 【每个partition内部保证消息的顺序。但是分区之间是不保证顺序的】 这一点很重要，例如kafka中的消息是某个业务库的数据，mysql binlog是有先后顺序的，10:01分我没有付款，所以pay_date为null，而10:02分我付款了，pay_date被更新了。 但到了kafka那，由于是分布式的，多分区的，可就不一定能保证顺序了，也许10:02分那条先来，这样可就会引发严重生产问题了。因此，一般我们需要按表+主键来分区。保证同一主键的数据发送到同一个分区中。 如果你想要 kafka 中的所有数据都按照时间的先后顺序进行存储，那么可以设置分区数为 1。 Replica （副本）每个partition可以配置若干个副本。Kafka 定义了两类副本：领导者副本（Leader Replica）和追随者副本（Follower Replica）。只能有 1 个领导者副本和 N-1 个追随者副本。 为啥要用副本？也很好理解，反问下自己为什么重要的文件需要备份多份呢？备份机制（Replication）是实现高可用的一个手段。 需要注意的是：仅Leader Replica对外提供服务，与客户端程序进行交互，生产者总是向领导者副本写消息，而消费者总是从领导者副本读消息。而Follower Replica不能与外界进行交互，它只做一件事：向领导者副本发送请求，请求领导者把最新生产的消息发给它，保持与领导者的同步。 如果对于刚刚所说的主题、分区、副本还有疑惑，那么结合下面这张图再思考一下，我相信你就可以玩转它了： 下图所示，TopicA，具有三个partition，每个partion都有1 个leader副本和 1 个follower者副本。为了保证高可用性，一台机器宕机不会有影响，因此leader副本和follower副本必然分布在不同的机器上。 ...

计算机只能识别机器码0101...编程语言->能执行的机器码 需要经过 预处理->编译->汇编->链接->机器码过程。一个语言处理系统的示意图如下： 编译器 是将源语言程序一次性翻译成一个等价的，用目标语言编写的程序。还存在另一种常见的语言处理器，解释器：它是逐个语句的执行源语言程序。由一个编译器产生的目标语言程序通常比一个解释器快，但解释器的错误诊断效果通常更好。 Java语言处理器结合了编译和解释的过程。一个.Java源程序首先被编译为.class字节码文件，被加载到虚拟机中，然后由虚拟机将字节码翻译成机器码。 虚拟机的好处在于：一旦一个程序被转换成 Java 字节码，那么它便可以在不同平台上的虚拟机实现里运行。实现一次编写，到处运行。另外一个好处是它带来了一个托管环境。这个托管环境能够代替我们处理一些代码中冗长而且容易出错的部分，如自动内存管理与垃圾回收。 在Hotspot中，虚拟机翻译字节码有两种方式： 1.解释执行即逐条将字节码翻译成机器码并执行。 2.即时编译即将一个方法中包含的所有字节码编译成机器码后再执行。 前者的优势在于无需等待编译，而后者的优势在于实际运行速度更快。HotSpot 默认采用混合模式，综合了解释执行和即时编译两者的优点。它会先解释执行字节码，而后将其中反复执行的热点代码，以方法为单位进行即时编译。 即时编译建立在程序符合二八定律的假设上，也就是百分之二十的代码占据了百分之八十的计算资源。 好了，装X结束。 阿姨知道的编译知识全在上面了。。(っ╥╯﹏╰╥c) 如题，下面我们来看一下让Java项目运行起来我们能做什么。 我们能做的很简单，当然不是写虚拟机。我们只需要： 1.执行command javac，将.Java文件变为.class文件。2.执行command java，让.class文件运行起来。 也就是 执行command ：） Java程序的运行方式Java程序可以通过java命令运行.class文件或运行可执行Jar文件。我们先看第一种方式：从Hello World开始。 运行.class文件Step1:编写Java文件 Step2:执行 command javac 将.Java文件变为.class文件 小贴士：class文件的全路径名是包名目录+ 类文件名。Step3:执行 command java 运行.class文件 神奇，我们没有用IDE让Java程序运行起来了 ：） 小伙伴先别喷老阿姨，哪特么有这么简单的Java项目啊。。我们工作中用的明明都是Jar文件啊...Jar文件咋运行啊！！ 运行可执行Jar文件Jar文件是基于ZIP文件格式的一种文件格式，它将大量的Java类文件、相关的元数据和资源（文本、图片等）文件聚合到一个Jar文件中，此外还包含一个可选的META-INF文件夹。这个文件夹下的文件或文件夹主要用来打包和扩展配置信息，包括安全，版本，扩展程序和服务等。如MANIFEST.MF文件定义了扩展和打包的相关数据信息。一个Jar文件通常在项目中用作第三方类库使用，也是项目构建的一部分。 生成一个Jar文件大致分为两步： 1.将源文件编译为.class文件 2.通过 command jar命令将.class文件，资源文件等等打成一个文件格式的Jar文件。 我们以一个SbDemo项目为例来看Jar文件的打包和运行。项目目录结构如下： Test2.java中调用了Test1.java的方法， 我们需要先将Test1.java编译并打成一个Test1.jar文件，然后通过Test1.jar将Test2.java编译并打成一个可执行的Test2.jar文件。 可执行和不可执行的Jar文件 区别在于是否在Jar文件中指定了main方法的入口，我们后面再看。 Step1:Test1.java的编译Step2:将编译后的classes/com/Test1.class文件打成一个Test1.jar包 Java中和jar包相关的命令是jar命令，生成一个jar包我们需要定义信息文件(manifest-file)，它可以定义所生成jar包的classpath类搜索路径,jar包的入口类等等。可以理解为与Jar包相关的元数据配置信息。Step2.1 书写信息文件这里我们使用resources/manifest-test1.text文件作为信息文件是的，Test1.java太简单了，就是打成一个可被他人引用的jar包，信息文件不重要。Step2.2 执行打包命令 Step3. 编译Test2.java文件因为Test2.java中引用了com.Test1类，所以我们需要在编译时指定Classpath路径。Classpath：顾名思义，是指待编译类依赖的类所在路径位置。我们可以通过 javac 的 -cp 参数指定。关于编译时classpath的值优先级如下： ...

近来有一些小伙伴私信问我 “怎么提高学习效率”， “怎么看源码”，“如何进大厂”... 我...我有些语塞。。这类和综合因素有关的问题我不好回答，也不觉得能回答好。 我会试着从我个人的角度扯一扯 我转行来，从小厂渣渣变大厂渣渣（进过阿里某个BU，姑且算吧：）的 一些“学习方法”和“技术学习路线”。扯的不好的地方还请大家见谅：） 所谓对症下药，指的是 医生针对患者病症用药。比喻针对事物的问题所在，采取有效的措施。出自《三国志·魏志·华陀传》。 小伙伴们配合下啊，阿姨在讲笑话。。但大体也可按这个思路来思考。不管是什么样的问题，我们都得先理解问题是什么，想要的结果是什么。然后才能针对诉求制定一些解决方法，执行起来，并不断反思，总结，改进。 学习方法提问 有时候我们并不知道问题是什么。 比如为啥我的tomcat起不来啦，为啥...这类问题在技术群里很多，当然大多只有问题，没有回答... 并不是大佬们特别不愿意回答，而是一个宽泛没有重点的问题让人无法回答。你说我本来就不知道问题在哪啊？ 兄弟，不清楚问题，不要加工，不要宽泛描述问题，原封不动的用报错信息搜索，用问题的关键字搜索，用google搜索（用了就回不去了：） 任何问题都一样，提问之前先搜索。网上的专业回答大多时候更香。 我们有时也不知道怎么分析问题。没办法。一层层问下去，一层层解析下去，直到触碰自己的知识盲点，学起来，通过问题由浅入深的搭建自己的知识体系。刚入行时我就买了《编译原理》，我是个憨憨。。 办法 了解了问题，知道了想要的结果。解决办法就知道了，不知道就还是一个新的问题，接着搜，接着问，接着分析。 比如说如何提高学习效率？ 重点是 “提高” “学习” “效率”。 首先你明确你想要的学习结果了吗？你细化每个结果了吗？你知道结果的二八原则部分是哪些吗？好吧，阿姨扯不下去了，意会之。。 行动力 道理不难懂，行动了吗。。 反思总结 要知道我们想要的结果是什么，如果目标没有达到，就一定要反思总结其他阶段哪些地方出错了，并不断改进。不要自己骗自己，做无用功。 “学习方法”总算扯完了，我相信大家和小姐姐一样都不笨 :D，更多的是思想上和行动上的偷懒。当然偷懒也没什么不好，但一定要言行一致 :） 学习路线小姐姐之前的目标很明确，面向 “大厂面试” 学习。 单从技术知识储备角度说，我觉得大厂面试既要深度，又要广度。但是不要怕，Java码农深又能深到哪... 如果你觉得深，问题不大，只是现在还太菜的原因，三年工作经验足够学习深入了：） 我比较实在的学习主要是一年时间，当时结合工作内容和打工市场上问到的技术栈，学习了Java并发包/Java IO/JVM/Spring系列/Mysql/Redis/ZooKeeper/Kafka/Canal/Netty等源码知识，并且写了一些博客文章思考总结。 这里求生一下，我并不是觉得学习源码就一定是更深入的学习方式。在我看来，学习知识要先从概念，理念这些思想上理解是解决了什么样的问题，源码只是具体的实现方式。透过源码要能明白前者，然后面试才好扯淡。 并发 操作系统类的书籍总有一章是讲并发编程的，这是一个通用问题。在啃J.U.C包前不妨先理解一下什么是临界区，什么是竞态条件... 这里推荐看《深入理解计算机系统》和MOOC网上南京大学骆斌老师的《计算机操作系统》视频课程，好吃免费。。 啃J.U.C包的话，也可以先看看《Java并发编程实战》和《Java并发编程的艺术》这两本书。前者是国外一堆领域大牛（包括作者Doug Lea大神）的译作，后者是国内“并发编程网”的发起人方腾飞的著作。 看源码时，可以参考网上一些源码分析文章，如小明哥的死磕Java并发系列。最重要的是看源码注释！！！作者的设计思想都写在上面了，Doug Lea会和你随便扯淡吗。。 Java IO 同样支撑起它的还是计算机基础知识。说来惭愧，阿姨还没看过《TCP/IP协议详解》这类经典书籍。不过我倒是用极客时间刘超老师的《趣谈网络协议》课程催眠了许久：） 不管通过什么途径，在对网络知识有了一定了解后，才能刚好的理解Unix IO模型，epoll机制，Reactor模型... 学习Java NIO时，可以找一些github上的NIO Server框架模仿着实现下。阅读Netty/ZooKeeper等框架的NIO实现，也可以类比学习Redis的实现。会加深对这块知识的理解。 JVM 话不多说。个人是没有深入啃这块内容的，也觉得深入啃这个不如啃其他的，比如计算机基础知识（仅代表个人想法，不喷：）这块可以看周志明的《深入理解Java虚拟机:JVM高级特性与最佳实践》(第三版)，极客时间郑雨迪的《深入拆解Java虚拟机》，网上JVM调优的文章也不少，如R大，你假笨，占小狼... Spring系列 基础还是IOC和AOP，网上的文章实在是太多了，比如芋道源码整理并写了很多源码分析文章。另外，太过庞大无从下手时，可以学习最初的版本，github的interface21，小而香。 Mysql 这里吹爆 掘金小册 小孩子4919 的《MySQL 是怎样运行的：从根儿上理解 MySQL》。看了四五遍这个，基本了解mysql的单机原理了，我也不想再看什么其他Mysql书籍了。多说一句，现在全民知识付费的环境下，这个付费质量实在太高了。都买了N年了，群里每个Mysql的问题，作者几乎都会回答。我怀疑29.9元是笔巨款。极客时间林晓斌的《MYSQL实战45讲》也很香，更偏向从实战问题出发，讲解原理。 ...

近来小姐姐又犯憨憨错误，问组内小伙伴export命令不会持久化环境变量吗？反正我是问出口了。。然后小伙伴就甩给了我一个《The Linux Command Line》PDF链接。感谢老大不杀之恩～ Shell是命令解释器，它会接受用户输入的各种命令，并传递给操作系统执行。它的作用类似于Windows系统的命令行。在UNIX或Linux系统中，Shell即是用户交互的界面，也是控制系统的脚本语言。当然现在用户也可以选择图形化界面做一些和操作系统的交互。层次示意图如下： 对于初学者来说，可能搞不清楚Shell怎么会有那么多分类，Shell的语法怎么那么随便... 小姐姐结合自己初学Shell傻傻分不清的问题点，主要从Shell的种类,变量的分类,条件测试的表达三个部分来介绍。 Shell的种类shell程序有sh，bash,zsh等分类，我从网上找到一张图可以看出shell程序的发展史。对于这些Shell程序，其语法或多或少有一些差异，不过我们通常使用的都是bash。 Shell程序信息在Linux系统我们可以通过一些命令查看或修改当前Shell程序信息。 一般发行版的Linux系统中，默认的shell程序就是bash。我们在写shell脚本时，通常也会在脚本文件头部指定bash作为脚本解释器。 这里多说一句，zsh有时也作为猿媛们的默认shell。zsh语法大多是和bash匹配的，也不会影响shell脚本的执行（因为脚本头部指定bash就还是bash：），也不会影响像小姐姐这样的渣渣使用。用它是因为它有神奇的开源框架 Oh My God.. 哦不，是 Oh My Zsh !!! 后面的内容我们还是以Linux系统中的bash为例来介绍：） 变量的分类Shell是一门动态类型语言和弱类型语言，我们可以把变量理解为KV对，key是变量名，value是变量值。变量大体可以分为环境变量，系统变量，用户定义的变量三类。 环境变量比如我们经常配置的JAVA_HOME就属于环境变量，这些变量是所有Shell程序运行时都可以使用的变量。关于环境变量的操作命令举例如下： 使用export命令定义的环境变量只在当前运行的shell进程中有效，结束进程就没了。所以我们要将配置变量定义在令小姐姐懵逼的一系列配置文件中，持久化下来。 说起配置文件，又不得不先提下shell程序和用户的Interactive和Login模式:) Interactive & Non-Interactive`Interactive通常是指读入写出数据都是从用户的terminal，也就是我们平时用命令行打开终端就是Interactive模式，而执行一个shell脚本就是Non-interactive模式。怎么检验当前shell运行的模式是不是Interactive呢？小姐姐从GNU网站拷贝了一段装X脚本： case "$-" in*i*) echo This shell is interactive ;;*) echo This shell is not interactive ;;esac结果如上所述。 Login & Non-Login`Login模式指的是用户成功登录后开启的shell进程，这时候会读取/etc/passwd下用户所属的shell去执行。 Non-login模式指的是非登录用户状态下开启的shell进程，我们可以通过echo $0区分。 扯这么多是因为配置文件的加载顺序和shell进程是否运行在Interactive和Login模式有关系:D 这是阿姨从网上粘的图。bash支持的配置文件有/etc/profile,~/.bashrc等。 当调用一个Interactive&Login模式的shell进程时，配置文件的加载顺序为： /etc/profile —>( ~/.bash_profile, ~/.bash_login, ~/.profile)其中之一 —>~/.bash_loginout(退出shell时调用) 当调用一个Interactive&non-Login模式的shell进程时，配置文件的加载顺序为： /etc/bash.bashrc —> ~/.bashrc 当调用一个non-nteractive模式的shell进程时，通常是执行脚本时，此时配置项是从环境变量中读取和执行的，也就是env命令输出的配置项。 另外，在开启一个shell进程中，有一些参数的值也会影响到配置文件的加载。如--rcfile <file>，--norc等。这些参数的含义值可以使用man bash进一步了解。只要保持默认值，其实就是我们上面介绍的配置文件加载顺序。 ...

OLAP（On-Line Analytical Processing），是数据仓库系统的主要应用形式，帮助分析人员多角度分析数据，挖掘数据价值。本文基于QQ音乐海量大数据实时分析场景，通过QQ音乐与腾讯云EMR产品深度合作的案例解读，还原一个不一样的大数据云端解决方案。一、背景介绍 QQ音乐是腾讯音乐旗下一款领先的音乐流媒体产品，平台打造了“听、看、玩”的立体泛音乐娱乐生态圈，为累计注册数在8亿以上的用户提供多元化音乐生活体验，畅享平台上超过3000万首歌曲的海量曲库。优质服务的背后，是每天万亿级新增音乐内容和行为数据，PB数据量级的数据计算服务。 海量的数据意味着更高标准的数据分析业务，对于离线分析的时效、实时与近实时的即席实时交互分析，提出了更高的要求。如何通过用户行为以及音乐内容标签数据，深入洞察用户需求，来优化泛音乐内容创作分享生态，为亿万用户带来更优质的音乐体验？是对QQ音乐大数据团队的巨大挑战以及机遇。 腾讯云弹性 MapReduce（EMR），结合云技术和社区开源技术，提供安全、低成本、高可靠、可弹性伸缩的云端泛Hadoop服务。EMR助力构建企业的大数据平台架构，适用于HBase在线业务，数据仓库，实时流式计算等大数据场景。 QQ音乐大数据团队基于业务需求，搭建和优化基于ClickHouse的OLAP实时大数据分析平台，并与腾讯云EMR团队深入场景合作，共建大数据云端解决方案。下文将通过案例解读，深入解析QQ音乐大数据团队OLAP系统架构演进之路，不断发掘音乐数据背后的价值。 二、大数据分析的挑战早些年在传统离线数仓阶段，QQ音乐使用Hive作为大数据分析的主要工具，对TB至PB级的数据进行分析，但存在着以下的可提升点： 1. 时效性低对于音乐服务来说，实时下钻和分析PV、UV，用户圈层、歌曲的种类、DAU等数据，分析结果的价值取决于时效性。核心日报与统计报表场景下，基于Hive的离线分析仅能满足T+1的时效，对于实时日报和分析的需求越来越强烈。 2. 易用性低基于Hive离线数据分析平台，对于产品、运营、市场人员具有较高的技术门槛，无法满足自助的实时交互式分析需求；开发在上报和提取分析数据时，无法实时获取和验证结果，查询和分析日志经常需要几个小时。 3. 流程效率低数据分析需求，需由数据分析团队完成，经过排期、沟通、建模、分析、可视化等流程步骤，所需时间以周计算，落地可能达数周，分析结果不及时，影响和拖慢了决策进度。 为了应对以上问题，提升流程效率，提高数据分析处理的时效性和易用性，数据的即席分析和数据可视化能力支撑需要优化和提升，让问题秒级有响应，分析更深入，数据分析更高效。 三、QQ音乐大数据架构技术演进QQ音乐大数据团队基于ClickHouse+Superset等基础组件，结合腾讯云EMR产品的云端能力，搭建起高可用、低延迟的实时OLAP分析计算可视化平台。 集群日均新增万亿数据，规模达到上万核CPU，PB级数据量。整体实现秒级的实时数据分析、提取、下钻、监控数据基础服务，大大提高了大数据分析与处理的工作效率。 通过OLAP分析平台，极大降低了探索数据的门槛，做到全民BI，全民数据服务，实现了实时PV、UV、营收、用户圈层、热门歌曲等各类指标高效分析，全链路数据秒级分析定位，加强数据上报规范，形成一个良好的正循环。 1. ClickHouse介绍ClickHouse由俄罗斯第一大搜索引擎Yandex发布，是一个基于列的，面向OLAP的开源轻量级数据库管理系统，能够使用SQL查询实时生成分析数据报告，适合PB数据量级的实时大数据分析。 在场景适用和性能方面，ClickHouse在OLAP的众多组件中有较为突出的优势。 （1）场景适用方面ClickHouse主要为OLAP应用场景的数据仓库，以库表的方式存储数据，可简单、高效地分析数据，结合Superset以可视化的方式输出分析数据图表。 （2）性能方面ClickHouse有着卓越的实时分析能力。以性能表现突出的单表为例，使用单表100G，3亿行数据，集群规模8核20G*3，简单的查询在毫秒级完成，复杂查询秒级，查询速度较Presto、SparkSQL提升3-6倍，较Hive提升30-100倍。 对比Presto、Impala、Hawq、Greenplum，ClickHouse以其分布式计算、多核计算、向量化执行与SIMD、代码生成技术以及列式存储等特性，实现了超高速的查询，凸显了更优越的性能。  2. ClickHouse架构系统技术攻克点面对上万核集群规模、PB级的数据量，经过QQ音乐大数据团队和腾讯云EMR双方技术团队无数次技术架构升级优化，性能优化，逐步形成高可用、高性能、高安全的OLAP计算分析平台。 （1）基于SSD盘的ZooKeeperClickHouse依赖于ZooKeeper实现分布式系统的协调工作，在ClickHouse并发写入量较大时，ZooKeeper对元数据存储处理不及时，会导致ClickHouse副本间同步出现延迟，降低集群整体性能。 解决方案：采用SSD盘的ZooKeeper大幅提高IO的性能，在表个数小于100，数据量级在TB级别时，也可采用HDD盘，其他情况都建议采用SSD盘。 （2）数据写入一致性数据在写入ClickHouse失败重试后内容出现重复，导致了不同系统，如Hive离线数仓中分析结果，与ClickHouse集群中运算结果不一致。 解决方案：基于统一全局的负载均衡调度策略，完成数据失败后仍然可写入同一Shard，实现数据幂等写入，从而保证在ClickHouse中数据一致性。 （3）实时离线数据写入ClickHouse数据主要来自实时流水上报数据和离线数据中间分析结果数据，如何在架构中完成上万亿基本数据的高效安全写入，是一个巨大的挑战。 解决方案：基于Tube消息队列，完成统一数据的分发消费，基于上述的一致性策略实现数据幂同步，做到实时和离线数据的高效写入。  （4）表分区数优化部分离线数据仓库采用按小时落地分区，如果采用原始的小时分区更新同步，会造成ClickHouse中Select查询打开大量文件及文件描述符，进而导致性能低下。 解决方案：ClickHouse官方也建议，表分区的数量建议不超过10000，上述的数据同步架构完成小时分区转换为天分区，同时程序中完成数据幂等消费。 （5）读/写分离架构频繁的写动作，会消耗大量CPU/内存/网卡资源，后台合并线程得不到有效资源，降低Merge Parts速度，MergeTree构建不及时，进而影响读取效率，导致集群性能降低。 解决方案：ClickHouse临时节点预先完成数据分区文件构建，动态加载到线上服务集群，缓解ClickHouse在大量并发写场景下的性能问题，实现高效的读/写分离架构，具体步骤和架构如下： a）利用K8S的弹性构建部署能力，构建临时ClickHouse节点，数据写入该节点完成数据的Merge、排序等构建工作； b）构建完成数据按MergeTree结构关联至正式业务集群。 当然对一些小数据量的同步写入，可采用10000条以上批量的写入。                （6）跨表查询本地化在ClickHouse集群中跨表进行Select查询时，采用Global IN/Global Join语句性能较为低下。分析原因，是在此类操作会生成临时表，并跨设备同步该表，导致查询速度慢。 解决方案：采用一致性hash，将相同主键数据写入同一个数据分片，在本地local表完成跨表联合查询，数据均来自于本地存储，从而提高查询速度。 这种优化方案也有一定的潜在问题，目前ClickHouse尚不提供数据的Reshard能力，当Shard所存储主键数据量持续增加，达到磁盘容量上限需要分拆时，目前只能根据原始数据再次重建CK集群，有较高的成本。 3. 基于Superset的自助数据分析可视化平台Apache Superset(孵化)是一个现代的、企业级的商业智能Web应用程序，为业务提供处理PB级数据的高性能的OLAP在线数据分析服务，提供丰富的数据可视化集，支持包括ClickHouse、Spark、Hive等多个组件的接口。 QQ音乐大数据团队结合自身业务特点丰富完善功能，结合腾讯云EMR云端弹性能力，深入参与Superset开源共建： ...

整理 | 高赟、程鹤群Review | 王治江 Flink 1.11 版本即将正式宣告发布！为满足大家的好奇与期待，我们邀请 Flink 核心开发者对 1.11 版本的功能特性进行解读与分享。Flink 1.11 在 1.10 的基础上对许多方面进行了完善和改进，并致力于进一步提高 Flink 的可用性及性能。 本文将详细介绍 1.11 版本的新功能、改进、重要变化及未来的发展计划。更多信息可以参考相应的 FLIP 或 Jira 页面，并关注我们后续的专题直播。 集群部署与资源管理在集群部署方面1.[FLIP-85] Flink 支持 Application Mode目前 Flink 是通过一个单独的客户端来创建 JobGraph 并提交作业的，在实际使用时，会产生下载作业 jar 包占用客户端机器大量带宽、需要启动单独进程（占用不受管理的资源）作为客户端等问题。为了解决这些问题，在 Flink-1.11 中提供了一种新的 Application 模式，它将 JobGraph 的生成以及作业的提交转移到 Master 节点进行。 用户可以通过 bin/flink run-application 来使用 application 模式。目前 Application 模式支持 Yarn 和 K8s 的部署方式，Yarn Application 模式会在客户端将运行任务需要的依赖都通过 Yarn Local Resource 传递到 Flink Master，然后在 Master 端进行任务的提交。K8s Application 允许用户构建包含用户 Jar 与依赖的镜像，同时会根据 job 自动创建 TaskManager，并在结束后销毁整个 Cluster。 ...

本文来源于公众号【胖滚猪学编程】，转载请注明出处。从今天开始，想和你一起死磕ElasticSearch，学习分布式搜索引擎，跟着胖滚猪就对了！ 既然是ES的第一课，那么最重要的是让你爱上它！不想说那些单纯的优势、概念了，直接上大厂的生产案例，才是最能吸引你的！跟着大厂走，没问题的！ 为啥选择ES?一个技术服务组件，首先需要了解全面它的使用场景，才能更针对性的去研究及推广。因此第一要务是搞懂为什么要学习ElasticSearch，开头po先一张排行图，大哥的地位可不是瞎搞来的，没点实力能上位？凭这排名就是你要学习它的理由！ 凭啥排这么前呢？不就是个搜索引擎吗。额，也许提到Elasticseach，你第一反应就是"搜索引擎"。类似百度搜索、淘宝搜索那种。而我写这篇文章就是为了纠正你这个"错误"的观点。 Elasticseach 确实是做搜索引擎出家的，但是到现在已经进化成了一个全能型的数据产品。因此你的思维决不能限制在搜索引擎上。 本文通过一线大厂的八个案例，全方位让你了解ElasticSearch的应用场景和优势，包括： 日志实时分析搜索服务数据分析数据监控查询服务后端存储ElasticSearch在腾讯的应用ElasticSearch在腾讯的应用非常广泛，主要有三：日志实时分析场景、搜索服务、时序数据分析。 搜索服务： 例如像腾讯文档基于 ES 做全文检索，电商客户拼多多、蘑菇街等大量的商品搜索都是基于 ES。日志分析： 这个是 ES 应用最广泛的领域，支持全栈的日志分析，包括各种应用日志、数据库日志、用户行为日志、网络数据、安全数据等等。ES 拥有一套完整的日志解决方案，可以秒级实现从采集到展示。时序分析： 典型的场景是监控数据分析，比如云监控，整个腾讯云的监控都是基于 ES 的。此外还包括物联网场景，也有大量的时序数据。时序数据的特点是写入吞吐量特别高，ES 支持的同时也提供了丰富的多维统计分析算子。日志实时分析典型日志如下： 运营日志，比如慢日志、异常日志，用来定位业务问题；业务日志，比如用户的点击、访问日志，可以用来分析用户行为；审计日志，可以用于安全分析。ES 很完美的解决了日志实时分析的需求，它具有如下特点：Elastic 生态提供了完整的日志解决方案，任何一个开发、运维同学使用成熟组件，通过简单部署，即可搭建起一个完整的日志实时分析服务。 在 Elastic 生态中，日志从产生到可访问一般在 10s 级。相比于传统大数据解决方案的几十分钟、小时级，时效性非常高。ES 拥有一套完整的日志解决方案（ELK），可以秒级实现从采集到展示。由于支持倒排索引、列存储等数据结构，ES 提供非常灵活的搜索分析能力。支持交互式分析，即使在万亿级日志的情况下，ES 搜索响应时间也是秒级。日志是互联网行业最基础、最广泛的数据形式，ES 非常完美的解决了日志实时分析场景，这也是近几年 ES 快速发展的一个重要原因 搜索服务搜索服务，典型场景包含：商品搜索，类似京东、淘宝、拼多多中的商品搜索；APP 搜索，支持应用商店里的应用搜索；站内搜索，支持论坛、在线文档等搜索功能。我们支持了大量搜索服务，它们主要有以下特点： 高性能：单个服务最大达到 10w+ QPS，平响 20ms~，P95 延时小于 100ms。强相关：搜索体验主要取决于搜索结果是否高度匹配用户意图，需要通过正确率、召回率等指标进行评估。高可用：搜索场景通常要求高可用性，支持单机房故障容灾。任何一个电商服务，如淘宝、京东、拼多多，只要故障一个小时就可以上头条。时序数据分析时序数据分析，典型的时序数据包含：Metrics，即传统的服务器监控；整个腾讯云的监控都是基于 ES 的。APM，应用性能监控；物联网数据，智能硬件、工业物联网等产生的传感器数据。时序数据的特点是写入吞吐量特别高，ES 支持的同时也提供了丰富的多维统计分析算子。这类场景具有以下特点： 高并发写入：线上单集群最大规模达到 600+节点、1000w/s 的写入吞吐。高查询性能：要求单条曲线 或者单个时间线的查询延时在 10ms~。多维分析：要求灵活、多维度的统计分析能力，比如我们在查看监控的时候，可以按照地域、业务模块等灵活的进行统计分析。上面通过腾讯的案例我们了解了三大应用场景， 日志实时分析场景搜索服务时序数据分析另外从这三大应用场景我们也可以归纳出ES的几大优势： 1、具有高可用性、高扩展性； 2、查询速度快，性能佳； 3、搜索功能强大，高度匹配用户意图。 因此，可以看出，ES在日志实时分析和搜索方面的应用优势简直是无敌的！起码目前，在这两方面，还没有强劲的对手！ ElasticSearch在京东的应用通过京东的案例，聊一聊ES在查询、检索、数据分析方面的应用场景 由于较高的性能和较低的使用门槛，京东内部有很多的场景都在使用 Elasticsearch。覆盖了京东多条业务线，同时也覆盖了很多应用场景： 补充关系型数据库的结构化数据查询主要应用的业务是商品、促销、优惠券、订单、收银台、物流、对账、评论等大数据量查询。此场景的核心诉求是高性能、稳定性和高可用性，部分场景会有检索要求，通常用于加速关系型数据库，业务系统通过 binlog 同步或业务双写完成数据同步。 全文检索功能主要的应用场景是应用、安全、风控、交易等操作日志，以及京东部分品类商品搜索。此类日志化场景对写要求很高，查询性能及高可用等要求相对较低，大的业务写会达到数千万 / 秒，存储以 PB 为单位来计算。这些场景对磁盘、内存有比较高的要求，因此，京东也做了相应优化，用于减少内存消耗，提升磁盘整体使用率，使用更廉价的磁盘来降低成本等等。 ...

代码洁癖狂们！看到一个类中有几十个if-else是不是很抓狂？设计模式学了用不上吗？面试的时候问你，你只能回答最简单的单例模式，问你有没有用过反射之类的高级特性，回答也是否吗？这次就让设计模式(模板方法模式+工厂模式)和反射助你消灭if-else！真的是开发中超超超超超超有用的干货啊！ 那个坑货某日，码农胖滚猪接到上级一个需求，这个需求牛逼了，一站式智能报表查询平台，支持mysql、pgxl、tidb、hive、presto、mongo等众多数据源，想要啥数据都能通通给你查出来展示，对于业务人员数据分析有重大意义！ 虽然各个数据源的参数校验、查询引擎和查询逻辑都不一样，但是胖滚猪对这些框架都很熟悉，这个难不倒她，她只花了一天时间就都写完了。 领导胖滚熊也对胖滚猪的效率表示了肯定。可是好景不长，第三天，领导闲着没事，准备做一下code review，可把胖滚熊惊呆了，一个类里面有近30个if-else代码，我滴个妈呀，这可让代码洁癖狂崩溃了。 // 检验入参合法性Boolean check = false;if(DataSourceEnum.hive.equals(dataSource)){ check = checkHiveParams(params);} else if(DataSourceEnum.tidb.equals(dataSource)){ check = checkTidbParams(params);} else if(DataSourceEnum.mysql.equals(dataSource)){ check = checkMysqlParams(params);} // else if ....... 省略pgxl、presto等if(check){ if(DataSourceEnum.hive.equals(dataSource)){ list = queryHive(params); } else if(DataSourceEnum.tidb.equals(dataSource)){ list = queryTidb(params); } else if(DataSourceEnum.mysql.equals(dataSource)){ list = queryMysql(params); } // else if ....... 省略pgxl、presto等}//记录日志log.info("用户={} 查询数据源={} 结果size={}",params.getUserName(),params.getDataSource(),list.size()); 模板模式来救场首先我们来分析下，不管是什么数据源，算法结构(流程)都是一样的，1、校验参数合法性 2、查询 3、记录日志。这不就是说模板一样、只不过具体细节不一样,没错吧？ 让我们来看看设计模式中模板方法模式的定义吧： 模板方法模式：定义一个操作中的算法的框架,而将一些步骤延迟到子类中. 使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。通俗的讲,就是将子类相同的方法, 都放到其抽象父类中。我们这需求不就和模板方法模式差不多吗？因此我们可以把模板抽到父类(抽象类)中。至于特定的步骤实现不一样，这些特殊步骤，由子类去重写就好了。 废话不多说了，我们先把父类模板写好吧，完全一样的逻辑是记录日志，这步在模板写死就好。至于检验参数和查询，这两个方法各不相同，因此需要置为抽象方法，由子类去重写。 public abstract class AbstractDataSourceProcesser <T extends QueryInputDomain> { public List<HashMap> query(T params){ List<HashMap> list = new ArrayList<>(); //检验参数合法性 不同的引擎sql校验逻辑不一样 Boolean b = checkParam(params); if(b){ //查询 list = queryData(params); } //记录日志 log.info("用户={} 查询数据源={} 结果size={}",params.getUserName(),params.getDataSource(),list.size()); return list; } //抽象方法 由子类来实现特定逻辑 abstract Boolean checkParam(T params); abstract List<HashMap> queryData(T params);}这段代码非常简单。但是为了照顾新手，还是想解释一个东西： ...

近年来，随着工业界多年的努力以及新兴技术的不断涌现，数据规模庞大的问题已逐步得到解决，而数据处理的时效性、数据价值的挖掘正成为企业及开发者面临的新的巨大挑战。也因此，大数据计算引擎、AI、数据仓库、数据湖等成为当前无可争议的热门话题。 当前大数据计算引擎各有千秋，如何选择适合自己的？数据仓库、数据湖、HSAP 架构，它们究竟能解决什么问题？机器学习平台那么多，好用的有哪些？ 6月14日，阿里巴巴计算平台事业部与阿里云开发者社区共同举办的大数据+AI Meetup 系列第一季即将重磅开启，此次 Meetup 邀请了来自阿里巴巴、Databricks、快手、网易云音乐的7位技术专家，集中解读大数据当前热门话题！ 活动亮点超豪华嘉宾阵容！多位资深技术专家在线分享对行业趋势的洞察！ 极丰富干货分享！集结大数据热门议题，一次看完：数据处理、数仓、数据湖、AI 等技术实践与生产应用落地。 多种奖品拿到手软！直播间已准备超多精美礼品，现场送送送！预约直播并参与互动即有机会领走哦。 本次 Meetup 您将了解： Spark 3.0 有哪些新功能从 Lambda 架构到 HSAP，数仓未来趋势如何流批一体机器学习算法平台 Alink 易用性的提升Flink + Kafka 在网易云音乐的落地实践数据湖如何解决数据实时入库问题2020 春晚活动中快手实时链路保障独家实践分享Flink 1.11 最新版本功能特性深度解读如何观看： 时间：6月14日 10:00 — 18:00直播预约链接：[https://developer.aliyun.com/...](https://developer.aliyun.com/...报名方式：扫描下方二维码即可报名 活动嘉宾与内容01《深入研究 Apache Spark 3.0 的新功能》李潇 | Databricks Spark 研发部主管 嘉宾简介：李潇，就职于 Databricks，Spark 研发部主管，领导 Spark，Koalas，Databricks runtime，OEM 的研发团队。Apache Spark Committer、PMC 成员。2011 年从佛罗里达大学获得获得了博士学位。曾就职于 IBM，获发明大师称号(Master Inventor)，是异步数据库复制和一致性验证的领域专家，发表专利十余篇。(Github: gatorsmile) 02《从 Lambda 架构到 HSAP，实时数仓的演进之路》姜伟华（果贝） | 阿里巴巴 资深技术专家 嘉宾简介：姜伟华博士，阿里巴巴资深技术专家。曾长期在 Intel、唯品会等公司工作。在 Intel期间，创建并负责 Intel 大数据研发团队，创立 Intel 大数据发行版，并连续多年保持国内市场占有率第一。领导 Intel 大数据开源，团队涌现出 10+ Apache Committer，创立两个 Apache 项目。曾获 Intel 最高奖（Intel Achievement Award）和 Intel 中国最高奖（Intel China Award）。在唯品会期间负责大数据平台与 AI 平台。现在阿里巴巴从事新一代大数据交互式分析引擎的研发工作。 ...

今年年初这场突如其来的疫情，让我们早晨醒来打开手机的第一件事情，从刷朋友圈变成了刷每日最新的疫情数据。看看国内外新增确诊人数/现存确诊人数，看看国内外疫情分布的地图。各大新闻平台也因为快速上线疫情实时动态板块，成为了大家了解疫情发展的阵地。 其实，在这背后是有着一个海量数据分析的架构平台做支撑。 对于很多企业的管理人员而言，这就是个很熟悉的T+1计算T日的报表场景。管理人员通过报表查看前一天企业的经营情况、库存情况、用户新增/流失情况等，用数据提高决策的准确率，减少误判。 支撑这个典型报表场景的背后，是一整套海量数据计算的大数据架构。根据笔者这几年几十家各行各业企业的交流经验来看，大致都经历了如下几个阶段： 关系型数据库最初，企业的技术人员通常都是在业务数据库相对空闲的时候（比如：晚上或者凌晨），直接在业务数据库备库进行一些数据分析查询。随着数据量的增多，一份逻辑上相同的数据，通常需要通过分库分表的方式分布在多个业务数据库中。快速分析全量数据且不影响在线业务变成了一件极其复杂的事情。 线下自建Hadoop集群2004年，Google发布MapReduce论文。2006年，Apache Hadoop项目发布。一些技术走在比较前沿的互联网公司，开始使用Hadoop的分布式处理能力解决数据分析中常见的数据量激增、查询出不了结果等问题。 随后几年，越来越多的公司开始在线下机房搭建开源Hadoop集群，Hadoop生态相关的Kafka、Hive、Spark、Flink等都开始百花齐放，懂这些开源组件的技术人员在职场上也变得越来越吃香。 Hadoop架构最本质的优势就是高扩展性，理论上，解决好节点间的通信、引入多管理节点，就能根据数据量无限扩展集群规模。集群规模跟需要参与计算的数据量（如：最近30天的数据）强相关，尤其像互联网APP，可能一把就火了，但火上半个月用户热情冷却，又下降到最初的业务量。线下机房采购服务器走流程，周期基本都是以月为单位，根本无法满足快速变化的业务场景。 云上自建Hadoop集群当时，国外的亚马逊已经诞生了几年，国内的阿里也开始大刀阔斧进军公有云。技术团队开始考虑公有云上购买虚拟机部署Hadoop集群，云上虚拟机按需使用的特点很好地解决了Hadoop集群对于节点伸缩能力的诉求。 云上半托管大数据服务 & 云上Serverless大数据服务云厂商也纷纷看到了企业对大数据分析的诉求，推出了云上半托管大数据服务（如：AWS、华为云的MRS等）。从单纯虚拟机的性能竞争演变成了大数据管理软件的易用性、大数据组件的性能等竞争。 云上半托管大数据服务对于用户来说，最核心的优势就是使得安装、升级、运维变得简单化、可视化。同时，因为组件都是开源 + 自研优化，所以在接口上和开源保持一致，减少了业务的改造成本。 但云上半托管大数据服务对于用户还是有一定的使用门槛（懂大数据运维和调优），而且需要长期持有一部分固定节点资源，存在一定的资源浪费。 注意到这些问题，AWS在2016年推出了基于Serverless架构的Athena服务。最初是主打使用标准SQL分析Amazon S3 中的数据。Athena没有服务器，无需管理任何基础设施，且只需为运行的查询付费。 华为云也在2017年推出了基于Serverless架构的数据湖探索DLI服务，完全兼容Apache Spark和Apache Flink生态，使用SQL就可轻松完成多个数据源的联合分析。 2019年2月，加州大学伯克利分校发表了这篇名为《Cloud Programming Simplified: A Berkerley View on Serverless Computing》的论文，论文中认为Serverless模式主要有三个特点： 1. 弱化了储存和计算之间的联系。服务的储存和计算被分开部署和收费，服务的储存不再是它本身的一部分，而是演变成了独立的云服务，这使得计算变得无状态化，更容易调度和缩扩容，同时也降低了数据丢失的风险。 2. 代码的执行不再需要手动分配资源。我们再也不需要为服务的运行指定需要的资源（比如使用几台机器、多大的带宽、多大的磁盘...），只需要提供一份代码，剩下的交由Serverless平台去处理就行了 3. 按使用量计费。Serverless按照服务的使用量（调用次数、时长等）进行计费，而不是像传统的Serverless服务那样，按照使用的资源（ECS实例、VM的规格等）计费。 在很长一段时间内，云上半托管大数据服务和Serverless大数据服务一定是长期并存的状态。 有大数据技术团队的大企业通常会选择半托管服务，一是因为使用习惯和自由度更像是开源Hadoop集群，二是因为技术团队自身也希望在大数据技术上有积累以便不时之需。 大数据技能较弱，且对成本敏感的中小型企业会考虑Serverless服务，吸引他们的是Serverless大数据服务即开即用免运维 + 标准SQL能力，用JDBC连上Serverless服务，体验十分接近传统关系型数据库。 Serverless大数据服务的未来Serverless大数据服务要真正被大众接受，对外需要做好宣传，对内需要练好内功。Serverless概念从2018年才开始真正火起来，很多用户一提到大数据，直观还是想到自建Hadoop集群或者云上半托管大数据服务。随着K8S容器和微服务被更多的用户接受和使用，Serverless大数据服务也在逐渐出现在技术人员选型的清单中。 内功修炼上，Serverless大数据服务必须要解决好“安全”、“弹性”、“智能”、“易用”四个核心问题 安全 大数据领域，无论是SQL中的UDF还是用户自己开发的应用程序，都存在会攻击其它租户的风险。当前想要解决这类安全问题的方法，不外乎沙箱隔离、安全容器隔离、物理隔离等这几个方法。每一个方法对架构和资源利用率的挑战都非常大。 弹性 Serverless大数据服务最初诞生的初衷就是让用户提交应用时，无需感知和指定具体的运行资源数。弹性分为两个方面：一是弹性的速度，二是弹性的预测。 弹性的速度取决于底层物理资源池的大小和扩容算法、资源预热的程度以及不同租户间的资源抢占机制。 弹性的预测可以从易到难分为几类：最简单的就是根据用户定时规则进行弹性，优点是及时弹性，缺点也显而易见用户需要对业务比较了解；其次就是如果是周期性任务，服务可以通过收集历史作业执行规律（作业数、资源利用率等），在下一次执行时根据历史规律进行弹性；更进一步，通常大数据的任务都是拆分成多个逻辑相同的Task，根据资源量进行多轮调度。第一轮运行的时候，可以收集到单个Task的运行时长、CPU利用率等，第二轮就可以根据单个Task的信息，跟弹性的速度做个平衡，获取最佳弹性策略。 智能 使用大数据组件，其实搭建、升级等都不算特别复杂的事情，真正复杂的是上百个参数的调优。Serverless大数据服务如果想要真正地吸引之前使用自建Hadoop集群的用户，核心就是解决用户最头疼的调优问题。Serverless大数据服务根据用户的业务及历史执行情况，智能对服务参数及数据组织进行调优。最典型的几个问题，比如：如何避免输出过多小文件、如何切分合适的Reduce个数、如何根据查询条件自动调整数据组织形式等。 易用 除了解决基本的部署、升级等运维相关的问题，真正做到免运维。在使用习惯上，相比云上半托管大数据服务，Serverless大数据服务一定会有一个适应过程，我们要做的就是让这个适应过程变得潜移默化。 基础功能页面的使用：如果跟微信一样，做好界面易用性设计和功能的取舍，这个学习过程会在潜移默化中完成。运维相关页面的使用：一定要尽可能保持和开源一样或者类似的页面逻辑，比如：Spark UI。作业操作脚本：包括作业的提交、作业的终止、状态的查询等，如果Serverless大数据服务是想搞定某个开源大数据框架的迁移场景，这一部分一定要全兼容开源习惯。Serverless大数据服务有些是基于开源大数据框架深度优化，有些是纯自研大数据框架。在应用开发的接口定义上，不管是哪种方式，对于从开源组件入门大数据的用户来说，开源接口就是标准，保持和兼容开源接口是Serverless大数据服务的基础。 总结Serverless大数据服务是一种面向未来的形态。随着逐个攻破当前存在的问题，它在大数据分析所占的比重一定会逐年增加。真正把大数据分析变成跟水和电一样随取随用，每个企业都能用得起的工具。 点击关注，第一时间了解华为云新鲜技术~

桔妹导读：在各大互联网公司都提倡数据驱动的今天，AB实验是我们进行决策分析的一个重要利器。一次实验过程会包含多个环节，今天主要给大家分享滴滴实验平台在分组环节推出的一种提升分组均匀性的新方法。本文首先会介绍一下滴滴AB实验的相关情况，以及在实验分组环节中遇到的问题。然后介绍目前在实验对象分组方面的通用做法，以及我们对分组环节的改进。最后是新方法的效果介绍。1. AB实验概述互联网公司中，当用户规模达到一定的量级之后，数据驱动能够帮助公司更好的决策和发展。在滴滴各个团队中，我们经常会面临不同的产品设计方案的选择或者多个算法方案的决策，比如顶部导航栏的排序方案一二三，派单算法一二三等等。传统的解决方法通常是由该领域经验丰富的专家来决定，或者由团队成员讨论决定，有时候甚至是随机选择一个方案上线。虽然在某些情况下传统解决办法也是有效的，但是让AB实验后的数据说话，会让方案选择更加有信服力。 滴滴Apollo AB实验平台，支持了滴滴诸多业务的功能优化、策略优化以及运营活动，提供了在线实验以及离线实验的能力，并行实验数达到 6000+ / 周。在分组方法上提供随机分组以及时间片分组来应对不同的实验场景。效果分析方面，我们对基础指标、率指标、均值指标、留存指标等多种类型的指标提供了均值检验、VCM、Bootstrap等多种分析手段。 2. 分组的问题一次完整的AB实验可以分为以下几步： 第一步：设计实验方案，包括确定实验对象，划分实验组，确定实验提升目标等。 第二步：进行人群分组，一般是一个空白组加一个或多个实验组 第三步：将需要实验的策略，方案或者功能施加到各个组，收集数据 第四步：对实验关心的指标进行分析观察 本文主要讨论其中第二步的实现。业界在进行实验对象分组的时候，最常用的是随机分组方式。这也是滴滴诸多实验中占比最大的分组方式。随机分组的做法可以实现为对实验对象的某个ID字段进行哈希后对100取模，根据结果值进入不同的桶，多个不同的组分别占有一定比例的桶。实验对象在哈希取模之后，会得到0 ~ 99的一个数，即为该实验对象落入的桶。这个桶所属的组就是该实验对象的组。 上述的这种分组方式称为CR（Complete Randomization）完全随机分组。进行一次CR，能将一批实验对象分成对应比例的组。但是由于完全随机的不确定性，分完组后，各个组的实验对象在某些指标特性上可能天然就分布不均。均值，标准差等差异较大。如果分组不均，则将会影响到第四步的实验效果分析的进行，可能遮盖或者夸大实验的效果。 待分流的个体具备一定的内在特点，比如就GMV这个指标来说，人群中会存在高GMV，中等GMV，低GMV等不同层次的用户。如下图所示，对于实验人群进行完全随机分流的方式，存在一定概率的不均匀，比如高GMV人群在某个组中的分配比例偏高，导致两个组的GMV相对差异较大。比如一次实验中，希望提升北京市的GMV 1%，在进行分组之后，实验组的人群GMV天然就比对照组的人群GMV高2%。这样实验进行的结果就变的无法比较。如果没有注意到实验前的组间不均情况，甚至可能验证出错误的结论。 基于CR的风险较大的情况，一般会对CR进行简单的一步优化，即进行RR（Rerandomization）。RR是在每次跑CR之后，验证CR的分组结果组间的差异是否小于实验设定的阈值。当各组的观察指标小于阈值或者重新分组次数大于最大允许分组次数后，停止分组。 相比于CR，RR通过牺牲计算时间，能在一定概率上得到符合要求的分组。重分组次数与输入的实验对象样本大小相关。样本量越大，需要进行重分的次数一般较少。但是RR分组能得到符合要求的分组有一定的概率，且需要花更多的时间。所以，我们希望通过对分组算法的改进，在一次分组过程中分出观察指标均匀的分组结果，如下图所示。 3. 自适应分组Apollo实验平台实现了滴滴AI LAB团队设计的Adaptive（自适应）分组算法。Adaptive分组方法可以在只分组一次的情况下，让选定的观测指标在分组后每组分布基本一致，可以极大的缩小相对误差。相比于传统的CR分组，Adaptive分组的算法更加复杂，在遍历人群进行分组的同时，每个组都需要记录目前为止已经分配的样本数，以及已经分配的样本在选定的观测指标上的分布情况。从分流人群中拿到下一个要分的对象后。会对实验的各个组进行计算，计算该对象如果分配到本组。本组的观测指标分布得分情况。然后综合各个组的预分配得分情况，得到最终各个组对于该实验对象的分配概率。 4. 系统设计系统交互流程如下： Adaptive分组方案的设计与实现复用了Apollo AB实验已有离线分组架构的能力。用户在实验平台通过API接口或者页面创建完Adaptive实验之后，实验平台会将分组需求发送到分组任务管理系统，生成分组任务存入数据库中。Adaptive分组执行分为以下几个步骤： 首先分组任务管理系统从数据库中获取需要进行分组的任务。然后根据任务类型调用不同的分组服务。Adaptive分组服务从数据库中获取实验对应的计算信息。根据实验计算信息中的观察指标，从HIVE中获取指标数据，根据人群信息的地址获取人群数据。执行完分组算法之后，将分组结果写入HDFS。 5. 算法介绍样本打乱&随机分配将人群shuffle打乱之后，对于人群的前2 * K（K是组数）的人进行随机分组，保证每个组中至少有两个样本之后再开始进行Adaptive分组。 组参数初始化根据实验的组以及每个组的人群比例计算出各个组的直接分配概率和间接分配概率。每个组上的直接分配概率和间接分配概率，分别表示了在直接分配以及间接分配情况下，选中该组后，样本分配到各个组的概率。根据已经分配的样本数据，初始化观测指标分布情况。 判断直接或间接分配计算各组已分配样本数和组所占比例之间的关系，得到各个组的平衡系数BS，如果各个组的比例平衡系数相差较大，则进行直接分配。选用BS最小的组的直接分配概率来分配接下来的一个样本。通过直接分配来粗粒度的调整各组的分配比例。如果平衡系数相差不大，则走接下来的指标分布计算，来决定使用哪个组的间接分配概率。 计算各组预分配得分 计算将要分配的一个样本，如果分配到组k后，组k的指标分布得分MS k，MS是根据ANOVA模型计算出来的每个组在各个观察指标上的均值，方差情况。通过比较各组的MS，选出向下偏离平均水平的组，以该组的间接分配概率作为各个组本样本的分配概率。 更新指标分布通过上述的流程，无论使用直接分配还是间接分配，最终得到一个样本的实际分组后。用这个样本在各个观测指标上的数据更新分配到的组的指标分布数据。如此遍历，直到分配完所有样本。 6. 方案效果使用Adaptive分组之后，1次分组得到符合要求的分组概率超过95%。 而不同算法间对于组间差异的实际优化情况不仅是与算法有关，也和进行分组的人群的大小，人群的分布特性相关。一般来说，人群大小越大，分布越均匀，使用随机分组的分组结果就会越好。组间差异会越小。下面进行测试的数据人群规模不大，所以直接随机分组的差异会显得比较大，并不代表所有情况。 如上图所示，是对一个大小为10000的司机人群进行分组测试，并观察分组后的结果在7日GMV，7日在线时长，全兼职三个指标上的分布情况，并取每次分组结果中三个指标上差异最大百分比作为本次分组的差异。其中CR（Complete Randomization）是指一次随机分组，RR（每次是跑CR100次，取最优结果得到），CAR（Covariates Adaptive Randomization）是指一次Adaptive分组。图中的纵坐标是该区间的次数，横坐标是差异的百分比。 每种方式均执行了400次，统计指标的组间最大差异。CR方式的差异最大，最大差异可能达到14%以上。RR在CR的基础上，通过时间换准确性，较大的降低了组间差异，最大组间差异能在2.7%以下，但是这个差异依然在实验中不能被接受。CAR通过算法的优化，进一步降低了组间的差异。95%的情况下能把差异控制在0.8%以下。 7. 总结通过提供Adaptive自适应分组能力，我们极大的提高了随机分组实验的数据精度。降低了无效实验的概率，缩短了实验周期。然而，对于已经通过CR方式完成的随机分流实验，用上述的这一套方案已经无法重新均衡。如何从这种已经完成的实验分组中抽取分布平衡的样本进行效果评估是一个更大的挑战，目前正在设计中，欢迎大家在本文留言，提宝贵意见，一起探讨实验相关问题。 团队介绍 滴滴工程效能团队肩负通过工程技术持续提升组织效能的使命，致力于建设世界一流的工程能力体系。为工程师提供极致的工作体验，打造高效能研发组织。 作者介绍 2018年北邮硕士毕业加入滴滴。在工程效能团队Apollo AB实验项目组，从事实验效果评估相关工作，负责实验科学性相关的研究。 ...

前言数据质量是数据分析结论有效性和准确性的基础，也是一切的前提。如何保障数据质量。 1.数据质量保障原则完整性完整性是指数据的记录和信息是否完整，是否存在缺失的情况。数据的缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确，所以说完整性是数据质量最基础的保障。准确性准确性是指数据中记录的信息和数据是否准确，是否存在异常或者错误的信息。比如一笔订单如果出现确认收货金额为负值，或者下单时间在公司成立之前，或者订单没有买家信息等，这些必然都是有问题的。如果确保记录的准确性，也是保障数据质量必不可少的一个原则。一致性一致性一般体现在跨度很大的数据仓库体系中，比如阿里巴巴数据仓库，内部有很多业务数据仓库分支，对于同一份数据，必须保证一致性。例如用户ID，从在线业务库加工到数据仓库，再到各个消费节点，必须都是同一种类型，长度也需要保持一致。所以，在建设阿里巴巴数据仓库时，才有了公共层的加工，以确保数据的一致性。及时性在确保数据的完整性，准确性和一致性后，接下来就要保障数据能够及时产出，这样才能体现数据的价值。一般决策支持分析师都希望当天能够看到前一天的数据，而不是等三五天才能看到某一个数据分析结果；否则久已经失去了数据及时性的价值，分析工作变得毫无意义。现在对时间要求更高了，越来越多的应用都希望数据时小时级别或者实时级别的。2.数据质量方法概述数据仓库建设过程中，经过不断的实践，总结出一套数据质量方法，在满足以上四个原则基础上，为数据做基础保障。 主要包括如下几个方面： 2.1消费场景知晓消费场景知晓部分主要通过数据资产等级和基于元数据的应用链路分析解决消费场景知晓的问题。 根据应用的影响程度，确定资产等级。资产等级划分： 毁灭性质：数据一旦出错，将会引起重大资产损失，面临重大收益损失，造成重大公关分险全局性质：数据直接或间接用于集团级业务和效果的评估局部性质：数据直接或间接用与内部一般数据产品或运营产品报告一般性质：数据主要用于日常数据分析，带来影响极小未知性质：不能明确说明数据的应用场景，则标注未知前面已经给出了数据资产等级的定义，但是对于庞大的数据量，如何给每一份数据都打上一个等级标签呢？ 首先要明白数据的流转过程： 数据是从业务系统中产生的，经过同步工具进入到数据仓库系统中，在数据仓库中进行一般意义上的清洗，加工，整合，算法，模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。而从业务系统到数据仓库再到数据产品都是以表的形式体现出来的。所以数据资产的落地方式则依赖于元数据应用链路方式，主要分为三步： 通过不同的数据应用确定资产等级根据元数据确定数据应用表的上下游血缘关系将消费链路上表打上资产标签2.2数据生产加工各个环节卡点校验数据生产加工各个环节卡点校验部分主要包括在线系统和离线系统数据生产加工各个环节的卡点校验。其中在线系统指OLTP系统，离线系统指OLAP系统。 在线系统卡点校验 在线系统业务复杂多变，总时在不断的变更，每一次变更都会带来数据的变化，数据仓库需要适应这多变的业务发展，及时做到数据的准确性。基于此，在线业务的变更如何高效地通知到离线数据仓库，同样也是需要考虑的问题。为了保障在线数据和离线数据的一致性，总结出两个行之有效的方法： 工具和人员双管齐下，既要在工具上自动捕捉每一次业务的变化，同时也要求业务人员在意识上自动进行业务变更通知。数据库表的变化感知。无论是随着业务发展而做的数据库扩容还是表的DDL变化，都需要主动通知到离线开发人员。离线系统卡点校验： 数据从在线业务系统到数据仓库再到数据产品的过程中，需要在数据仓库这一层完成数据的清洗，加工。正是有了数据的加工，才有了数据仓库模型和数据仓库代码的建设。如何保障数据加工过程中的质量，是离线数据残酷保障数据质量的一个重要环节。主要实现方法分为以下几个方面： 代码提交卡点校验：将每一次提交上线的代码进行扫描，将风险点提示出来任务发布上线卡点校验：发布上线测试主要包括Code Review和回归测试，对于资产等级较高的任务变更发布，则采用强阻塞的形式，必须通过在彼岸完成回归测试之后才允许发布Dry Run：不执行代码，仅运行执行计划，避免线上和线下环境不一致导致语法错误，真实环境的运行测试，则使用真实数据进行测试。数据重刷前变更通知：一般将变更原因，变更逻辑，变更测试和变更时间通过类似通知中心平台通知下游，下游对此没有异议后，在按照约定时间执行发布变更。2.3风险点监控风险点监控部分主要是针对数据日常运行过程中可能出现的数据质量和时效等问题进行监控，包括在线数据和离线数据的风险点监控两个方面。 在线数据的风险点监控主要是针对在线系统日常运行产出的数据进行业务规则的校验，以保证数据质量。利用实时平台进行监控。针对数据库表的记录进行规则校验。在每一个业务系统中，当完成业务过程进行数据落库时，实时平台同时订阅一份相同的数据进行逻辑验证，当校验不通过的时候，以报警的形式披露给订阅人。完成数据的校验，这也是数据的准确性把的第一道关。离线数据的风险点监控主要是针对离线系统日常运行产出的数据进行数据质量监控和时效性监控。利用离线平台进行监控。主要包括数据准确性和数据产出及时性的监控: 1.数据准确性采用DCQ检查，DQC 查其实也是运行 SQL 任务，只是这个任务是嵌套在主任务中的， 旦检查点太多自然就会影响整体的性能，因此还是依赖数据产等级来确定规则的配置情况。比如高等级A1,A2类数据监控率就要到达90%以上，规则类型也需要三种以上。 2.数据及时性为确保前一天的数据完整，天任务是从零点开始运行的，由于计算加工的任务都是在夜里运行的，而要确保每天的数据能够按时产出，则需要进行一系列的报警和优先级设置，使得重要的任务优先且正确产出，所以就要根据任务划分优先级，并制定对应的任务告警。优先级则根据资产等级来进行划分，任务告警主要包括出错告警，完成告警，未完成告警，周期性告警，超时告警以及自定义告警。2.4质量衡量上文提到的保障数据仓库数据质量的各种方案，如何评价这些方案的优劣，则需要一套度量指标。 1.数据质量起夜率 前文在介绍数据及时性时已经提到，数据产品或者管理层决策日报一般都要求在上午 9:00 之前提供，数据仓库的作业任务都是在凌晨运行的 一旦数据出现问题就需要开发人员起夜进行处理。因此，每个月的起夜次数将是衡量数据质量建设完善度的一个关键指标。如果频繁起夜， 则说明数据质量的建设不够完善。2.数据质量事件 针对每一个数据质量问题，都记录一个数据质量事件。数据质量事件，首先用来跟进数据质量问题的处理过程；其次，用来归纳分析数据质量原因；第三，跟进数据质量原因来查缺不漏，既要找到数据出现问题，也要针对类似问题给出后续预防方案。因此，数据质量事件既用来衡量数据本身的质量，也用来衡量数据链路上下游的质量，是数据质量的一个重要度量指针。3.数据质量故障体系 对于严重的数据质量事件，将升级为故障。故障是指问题造成的影响比较严重，已经给公司带来资产损失或者公关风险。比如财报计算错误等，都将带来恶劣影响。所以此类数据质量问题，已经不仅仅是一个事件，而是升级为故障。所以数据质量故障对于开发人员和部门来讲，都是一个重要的考核点，因此也是数据质量最严的一个指标。 故障定义首先识别出重要的业务数据，并注册到系统中，填写相关的业务情况，如技术负责人、业务负责人、数据应用场景、延迟或错误带来的影响、是否会发生资产损失等，完成后，会将这部分数据的任务挂到平台基线上，一旦延迟或错误即自动生成故障单，形成故障。 故障等级故障发生后，会根据一定的标准判断故障等级，如故障时长、客户投诉量、资金损失等，将故障按 pl到 p4 定级，各团队会有故障分的概念，到年底会根据故障分情况来判断本年度的运维效果。 故障处理故障发生后，需要快速地识别故障原因，并迅速解决，消除影响。在处理故障的过程中 会尽快将故障的处理进度通知到相关方，尽可能减少对业务的影响。 故障Review对于故障会进行 Review ，即分析故障的原因、处理过程的复盘、形成后续解决的 Action ，并且都会以文字的形式详细记录，对故障的责任进行归属，一般会到具体的责任人。注意，对故障责任的判定，不是为了惩罚个人，而是通过对故障的复盘形成解决方案，避免问题再次发生。

近期Hadoop消息不断，众说纷纭。本文以Hadoop的盛衰变化为楔子聊下大数据分析的发展现状和未来趋势。 15秒钟简缩版：Hadoop 巅峰已过，正在成为遗留系统Hadoop 和分布式数据库在同一个赛道上，Hadoop 在这个赛道上目前并无优势大数据 大数据市场是 SQL市场，是分布式数据库市场基础分析如BI、交互查询等技术已经成熟高级分析（机器学习）下沉，向数据库内嵌分析方向发展高级分析（机器学习）主要问题不在分析而在数据本身1. Hadoop 巅峰已过几多年，正在成为遗留系统自2015年开始 Hadoop 暴露出诸多问题引起注意。随后 Gartner、IDG 等公司分析师、Hadoop用户和Hadoop和大数据圈内人士越来越多的反映出各种问题。 究其原因，主要如下： Hadoop 栈过于复杂，组件众多，集成困难，玩转代价过高Hadoop 创新速度不够（或者说起点过低），且缺乏统一的理念和管控，使得其众多组件之间的集成非常复杂受到 Cloud 技术的冲击，特别是类 S3 对象存储提供了比 HDFS 更廉价、更易用、更可伸缩的存储，撬动了 Hadoop 的根基 HDFS对 Hadoop 期望过高，Hadoop 发迹于廉价存储和批处理，而人们期望 Hadoop 搞定大数据所有问题，期望不匹配造成满意度很低人才昂贵，且人才匮乏Hadoop 巅峰已过成为行业事实，本文不打算在这个问题上继续论证。有兴趣的读者可以参考网上的诸多评论，甄选了一些笔者觉得有参考价值或沾边的文章罗列如下（从标题可以感觉到浓厚的萧瑟之气）： Hadoop还有没有前途？Hadoop发展历史和未来方向解读Hadoop 气数已尽：逃离复杂性，拥抱云计算超越云计算：对数据库管理系统未来的思考Big Data Is Still Hard. Here’s WhyBig Data Will Get By (but only with a little help from its friends)Cloudera and Hortonworks merger means Hadoop’s influence is decliningFrom data ingestion to insight prediction: Google Cloud smart analytics accelerates your business transformationHadoop is Dead. Long live Hadoop (中文翻译：Hadoop已死，Hadoop万岁)Hadoop Has Failed Us, Tech Experts SayHadoop Past, Present, and FutureHadoop: Past, present and future（又一个）Hadoop runs out of gasHadoop Struggles and BI Deals: What’s Going On?Hitting the Reset Button on HadoopIs Hadoop officially deadMike Olson on Zoo Animals, Object Stores, and the Future of ClouderaMore turbulence is coming to the big-data analytics market in 2019Object and Scale-Out File Systems Fill Hadoop Storage VoidThe Decline of HADOOP and Ushering An Era of CloudThe elephant’s dilemma: What does the future of databases really look like?The Future of Database Management Systems is Cloud!The history of HadoopWhy is Hadoop dying?Ok，如果你和我一样，把上面所有文章都读了一个遍，说明你确实对这个问题很感兴趣。发邮件给我(yyao@pivotal.io)，请你喝酒细聊。 ...