大数据

随同着国家产业降级的推动和云原生技术成熟，多点 DMALL 大数据技术也经验了从存算一体到存算拆散的架构调整变迁。本文将从引入 Kyuubi 实现对立 SQL Proxy 的角度讲述这一摸索实际的历程。多点 DMALL 成立于2015年，提供一站式全渠道数字批发解决方案 DMALL OS，目前已与130+连锁批发企业、近1000家品牌达成单干，笼罩5个国家和地区。作为一站式全渠道数字批发解决方案服务商，多点 DMALL 通过数字化解构重构批发产业，提供端到端的商业 SaaS。计划整体涵盖了从商品抉择、供应商引入、仓储供应链治理、门店经营、用户精准营销的整个产业链，实现了人人、事事、物物在线。 Apache Kyuubi 是网易数帆发动开源的一个分布式和多租户网关，用于在 Lakehouse 上提供 Serverless SQL，社区目前已汇集海内外百余名贡献者。 作为 DMALL OS 数字化能力的技术底座，大数据平台历经屡次迭代安稳撑持了公司 To B 业务的发展。随同着国家产业降级的推动和云原生技术成熟，多点 DMALL 大数据技术也经验了从存算一体到存算拆散的架构调整变迁。本文将从引入 Kyuubi 实现对立 SQL Proxy 的角度讲述这一摸索实际的历程。 技术背景行业技术发展趋势 第一代的大数据技术次要采纳传统 Hadoop 开源技术栈，简直所有的企业搭建大数据集群都是从 HDFS、Hive 和 YARN 开始的。除了 Apache 开源组件组合外，许多企业也会选用 CDH、HDP 等商业发行套件，不便运维和部署。随着技术的成熟，传统的 Hadoop 技术开始裸露一些毛病： 1. 部署运维老本高 Hadoop 生态组件所需根底硬件资源较多，组建集群时须要谨慎设计和调整，部署老本高，前期运维复杂度高。 2. 集群隔离，资源节约 大数据集群部署时经常须要独自申请机器，与业务服务集群资源隔离。总体来看，两个集群的潮汐景象都存在，大数据集群白天较为闲暇，业务服务集群夜间用户使用量低，隔离部署的形式会产生较大资源节约。 3. 存储老本继续升高 大数据集群的数据量是始终增长的。纵使企业做了冷热拆散的设计、定时归档的解决，也只是减缓了增长趋势，仍旧无奈解决存储老本始终升高的现状。当然，除了上述毛病，还有 NameNode 元数据压力过大、组件版本互相制约等问题。这些毛病对于企业外部应用尚且能够优化解决，然而作为一家须要为客户提供定制化服务的企业，尤其面对日益突出的“性能”、“老本”、“平安”、“稳定性”等外围问题，多点 DMALL 意识到必须做出扭转。 To B 的大数据平台建设趋势 To B 的企业商业逻辑和 To C 的差异很大，在大数据畛域的差异更大。 ...

「自学 Python？个别人我还是劝你算了吧！」在国内常识分享平台「知乎」上，这一吐槽话题取得了超过 2600 次点赞，引发近 600 条探讨。 从该话题下的高赞探讨来看，少数人对 Python 的应用性都持必定态度，但在门槛上却褒贬不一，有人认为 Python 可能让新人很快入门，从而在初始阶段就取得成就感，晋升趣味度；而有人则保持久远倒退观点，认为 Python 在语法上暗藏了大量概念，比方类型、多态利用原理等，如果基本功不扎实，即使是老手入了门，也难以进一步深刻。 作为目前被宽泛应用的解释型编程语言，Python 凭借多种弱小的算法和模型，和数据灵便整合剖析与建模等性能，近年来风头一时无两。依据 2021 年 TIOBE 编程语言社区的排名数据，Python 以市场占比 12.90%排名第一位，市场占比回升 0.69%；从 Python 市场占比的历史趋势来看，从 2014 年开始，Python 市场占比就开始逐年走高，至 2022 年，Python 市场占比达到历史最高峰。 但另一方面，Python 在应用过程中始终存在门槛问题，这导致企业内除算法工程师之外的员工，很难深度利用。 个别状况下，企业数据的采集、治理、剖析、利用往往都在平安权限的管控下有着既定流转链路，各环节对应不同岗位员工的工作要则，但不同岗位工作交接的过程中，却偶有呈现能力“断点”。 如，数据开发个别会提供宽表来应答火线业务的需要，但在局部状况下须要将数据做行列转换，能力对数据进行更进一步剖析，而这项操作能力对一般业务岗位员工来说，是一道“拦路虎”；即使是置身这一环节“专业对口”的算法工程师，也仍旧面临着另一个问题：目前市场上短少能够将长期生产好的数据与可视化图表联动的产品，但这凑巧又是数据能被后链路环节高效利用的要害。 针对将数据挖掘与可视化图表联动，以及升高非算法工程师岗位对数据挖掘需要的了解门槛，火山引擎数智平台 VeDI 旗下数智洞察 DataWind，近期推出了降级性能：可视化建模。 这项新性能封装了超过 30 类常见的 AI 算子能力，用户仅需理解算法的作用，就能够通过配置化的形式配置算法算子的输出和训练指标，实现模型训练，并依据配置的其余数据内容疾速失去预测后果。 过来，简单算法模型往往须要通过 Python 才得以实现，但当初通过 DataWind 同样可能实现搭建。 以电商企业场景为例，当员工须要依据现有数据构建「用户回购模型」时，思考整个过程须要通过数据荡涤、格局转换之后采纳梯度晋升树构建，外围波及的环节包含合并行、缺失值替换、one-hot 编码、梯度晋升树、聚合、提取字段总共 6 个，因而通过 DataWind 可视化建模构建的「用户回购模型」流程能够参考下图： 可视化搭建的形式，一方面升高了非算法工程师对流程的了解老本，另一方面对算法工程师本身来说，操作也将更加简略便捷，进一步晋升工作效率。 而可视化建模只是 DataWind 近期性能降级的一个缩影，在往年更早之前，DataWind 就曾经迎来协同层面大动作，实现与飞书、企业微信等在线协同办公 IM 工具全面协同，用户通过飞书等就能够实现 DataWind 数据服务一键订阅，随时随地查看数据、应用数据。 据理解，在历经字节跳动外部多业务多场景实际之后，目前火山引擎的系列数智能力曾经通过 DataWind 等产品全面对外输入，并在互联网、汽车、批发、金融等多个行业在内的数百家标杆企业取得利用实效。 ...

疫情让线下的需要大量转移到线上，催生出了近程办公、网络授课、线上健身等新的生态景象。如何更好地为用户服务，晋升用户体验，成为了诸多平台的一大课题。 明天的故事来自字节的一款 App，当它的倒退进入成熟期后，通过 A/B 测试等精细化数据分析晋升用户体验，实现 DAU（日沉闷用户数）增长数十万的故事。 在字节有一个专门保障用户使用性能体验的团队，他们在日常的数据察看中发现了一个景象：用户所应用的设施性能好坏，会影响到他们在产品应用中的活跃度。同时，他们在钻研中发现，这些根底性能体验的晋升，会缩短不同细分畛域的用户生命周期，最终晋升短视频产品的大盘 DAU。 为了进一步准确归因，这个团队应用专门为 A/B 试验打造的数据产品——DataTester，该产品是字节跳动外部利用多年的 A/B 试验平台，在 2020 年已通过火山引擎面向内部企业凋谢服务。 他们通过 DataTester 查看曾经取得正向收益的 A/B 试验，并对其中的每个性能指标和业务指标做线性剖析，尝试寻找会对业务指标造成影响的性能指标。 数据显示，字节每日有 3 万余个 A/B 试验在同时运行，而每一次渺小的产品改变，也都会通过 A/B 实验所得出的数据验证。 能够说小到按钮色彩和地位，大到举荐算法策略和规定，在字节都经验过 DataTester 的 A/B 试验成果验证。因而，该短视频产品也在 DataTester 中积攒了大量的试验记录。 当性能体验团队将 DataTester 中的历史试验进行演绎整顿后，他们发现有几个性能指标和产品的业务指标具备高度的相关性——当用户在刷短视频的过程中，遭逢到较多晦涩度、贮存占用、网络速度等问题，会间接的升高用户应用短视频产品的活跃度，而这个问题在设施性能较低的用户群体中更为显著和集中。 定位到问题后，性能体验团队开始有针对性地开启了产品策略的优化。他们集中优化了设施性能较低的用户，在关上产品启动速度和视频加载流畅性方面——启动速度：首刷视频加载工夫过长；流畅性：UI 动画和视频加载卡顿。 他们设计了优化后的产品状态，外围是将页面展现简洁化，并再次通过 DataTester 投放 A/B 试验，用以验证成果。 配合产品页面展现简洁化，也同时加重了一些特效、动效、快捷性能、附加组件等加载，综合性大幅晋升了该短视频 App 的启动速度和视频播放的晦涩度。从 DataTester 的试验后果上看，优化后的实验组计划在性能指标上有了大幅晋升，App 启动速度、播放晦涩度显著晋升，播放卡顿指标大幅降落。 而在业务指标的数据反馈中，用户生命周期、用户拜访时长等都有不同水平的正向收益。最终，本次的产品优化在 DataTester 中获得了晋升整个短视频 App 数十万日活的收益，超出预期。 从今日头条开始，字节的每款产品，在迭代中都离不开 A/B 测试。也正是因为 DataTester 在字节全业务线的深度遍及和利用，帮忙业务在每一个渺小决策的岔路口上，都做出了那个“更正确一点”的抉择。 DataTester 基于先进的底层算法，提供迷信分流能力和智能的统计引擎，反对多种简单的 A/B 试验类型。在利用和剖析场景上，DataTester 深度耦合举荐、广告、搜寻、UI、产品性能等多种业务场景需要，为业务增长、转化、产品迭代，策略优化，经营提效等各个环节提供迷信的决策依据，让业务真正做到数据驱动。 目前，DataTester 曾经服务了美的、失去、凯叔讲故事等在内的上百家标杆客户，将成熟的“数据驱动增长”教训赋能给各行业。 ...

行内人都晓得，二手车交易的外围问题在于车况信息不通明。中国二手车交易市场制度尚不欠缺，长期以来短少行业公认的车辆估值规范和车况检测规范，二手车商提供的估值和车况信息不够通明。这导致用户和车商交易单方都陷入了循环窘境：用户对车商信赖有余，购买志愿低；二手车商短少潜在客户线索，为招揽客户不惜采纳虚伪信息，使得市场环境进一步好转。为推动车况信息的透明化，汽车之家二手车不断完善优化“车史档案”，使二手车出险记录查得率达到 98%、维保记录查得率达到 85%，同时还有天天拍车平台发展线下检测业务，获取实在的车况数据欠缺档案数据。 现阶段，多方面的车辆信息已实现了物理层面上的集成，但在语义内容的解析和信息的视觉出现上还有待深入研究。用户须要亲自浏览碰撞、维保、电池报告来了解其中的内容，报告内容的丰富性、专业性与可读性将对用户的交易决策产生重要影响。例如用户浏览 APP 时被汽车外观、内饰的照片所吸引，却可能因不理解汽车车体构造和车况排查规范而无奈精确了解相应的碰撞、维保、电池报告中所蕴含的泛滥内容，最终导致交易转化失败。 一、提出解决方案的第一步：明确指标汽车之家二手车将利用数字能力和数据资源一直推动车况信息的透明化、标准化，使用户更易理解车况信息，进步用户决策效率和线索转化效率。具体来说，汽车之家二手车联合机器学习、自然语言解决和 VR 全景等技术重塑了二手车购买的业务场景，将二手车车源在估值、车史、VR 全景展现三个维度的信息进行了集成与交融，以交互式可视化的模式出现给用户，使用户更快捷、直观、详尽理解二手车车源的车况和估值，升高用户的信息搜查老本和信息了解老本，促成用户做出交易决策。 图1. 传统二手车买车场景和数字化二手车买车场景比照 如图所示，传统的二手车交易须要用户在不充沛理解车辆信息的状况上来与二手车商预约线下看车，再依据看车人的教训常识做出主观的评断。而数字化的二手车买车业务则是用户间接通过 PC、APP 从云端获取标准化的车辆信息，充沛理解车辆信息、初步评估后再决定是否线下看车，无效进步线下看车的效率。汽车之家二手车在为用户发明数字化体验的过程中，除了促成购车交易，也进步了买车新模式的商业增长。 二、制订解决方案：构建“买车新模式”1、业务场景图2. 二手车买车业务架构 二手车买车业务流程架构如图所示。结构化的数据来自从汽车之家二手车交易平台中的二手车的车辆数据、交易记录等数据。其中，二手车的车辆数据中包含省份、城市、车型、上牌工夫、行驶里程、公布工夫、过户次数等各种数据，二手车交易记录中包含成交价格、交易类型、检测车况等数据。这些结构化的数据按用于估值模型的训练，预测车辆在以后及将来的价格趋势。 半结构化的数据是指从第三方获取的车辆出险记录，4S 店维修保养记录、天天拍线下检测记录以及电池数据记录，这些记录具备多种数据类型，须要转化为对立的数据格式，解析其中的语义内容，抽取结构化的信息。对于新能源车的电池数据通过加工解析生成电池在线检测报告，综合得出维保、碰撞、电池等多维度的车史报告。 全景数据是指通过 VR 外观相机和 VR 内饰相机所拍摄的原始图像数据，原始图像数据通过 VR 拍摄组件生成 VR 图片，再通过 APP、H5 端的 VR 播放组件进行展现。从非结构化数据中抽取出的结构化信息除了造成车史报告，也能够与 VR 中图像进行跨模态的语义对齐，例如车史报告中如提到“左前门碰撞”，则能够在 VR 展现中提醒出左前门的状态异样。估值、车史和 VR 展现将独特出现于用户界面。 当用户浏览通过 PC、APP 浏览二手车车源详情时，可在用户界面查看车辆估值信息，查问车史报告，VR 全景看车，从价值、车况、外观内饰三个角度来评估车辆是否合乎需要，决定是否购买或留下购车线索。 2、技术难点估值：车辆的数据十分复杂，通常包含了区域、车龄、里程数、车型、车系、外观、内饰、车况等多达上百维的特色信息，并且这些特色存在着数据的局部缺失或特色间多重共线性的简单关系，给二手车价格的预测模型带来三大挑战：模型预测的准确率，模型推理的计算效率，模型的可解释性。尽管现有的机器学习技术如神经网络或梯度晋升树模型能够端到端地解决简单特色，但车辆特色数据的复杂性使得此类办法不适宜用于二手车价格的预测，已有的二手车估值模型准确率较低。为解决上述三个问题，本估值模型采纳了分而治之的思路，将车源依照省份、城市和车型分组，再将分组后的车源数据中与工夫相干的数据进行量化解决，依据相关性筛选特色，训练多元线性回归模型。 VR 全景：现有的 VR 外观技术计划是采纳单反相机+长焦镜头拍摄，在自带转盘的影棚内进行车辆外观的 360° 拍摄；或采纳单反相机+鱼眼镜头拍摄，车内应用单反进行 4 面拍摄，而后采纳人工前期解决的形式实现全景 360° 图像的生成。毛病在于单反+影棚+转盘造价高，条件刻薄，拍摄车辆须要专人负责运输，效率低，前期图像处理繁琐，产出一辆车的外观+内饰图片过程长，对于人员业余度要求刻薄。而通过手机 APP 疏导拍摄+前期人工解决的办法所得图像不够精准，前期人工解决耗时长。二手车 VR 看车全新设计研发了基于模型、车辆轮廓辨认、陀螺仪、磁场传感器综合性的对被摄车辆和场地进行计算，给拍摄者提供便捷的定位拍摄计划。 车史档案：维修保养记录、碰撞记录和电池充放电记录的数据也同样面临着数据维度微小、数据品质不一、不足规范化的问题。比方维保记录和碰撞记录，有着多种形式的数据起源，既有半结构化的记录表单，也有记录文档，甚至还有拍摄或扫描的文档图像，须要对这些数据源进行加工解决，标准为对立格局的数据模式。在车况信息的抽取过程中，须要依据领域专家常识明确须要抽取的信息类型，建设车况评估和电池情况评估的常识模型以及相应的标准化术语词表，建设车况和电池的评分、评级模型。 3、实现办法3.1 估值图3. 估值模型 对车辆进行估价，是二手车交易的重要环节，在交易过程中，须要依据车辆信息对二手车进行评估定价，取得较为精确估价区间。目前，咱们基于汽车之家丰盛的二手车车源数据研发了一种车辆估价模型,来满足商家、用户对二手车车源价格的评估。 咱们的车辆估价模型次要应用的车源数据包含：天文区域、车型、行驶里程、上牌工夫、公布车辆工夫等，首选咱们须要车源数据中提取天文区域和车型，并依照天文区域、车型对车源数据中的其余维度数据进行分组，失去分组数据，再将分组后的车源数据中与工夫相干的数据进行量化解决，解决后的各组车源数据作为训练数据，训练多元线性回归模型，模型定义如下： 表 1.不同理区域、不同车型对应预计模型的截距与回归系数 构建多个针对各个天文区域下的、不同车型的车辆估价模型，即每个省份对应多个车辆估价模型，每个省份、城市、车型下对应一个车辆估值模型。因为不同省份、车型的车辆价格存在肯定的差别，因而针对不同天文区域、车型训练不同的估值模型，能够无效缩小预测误差，使模型预计的准确性更高。失去针对各个天文区域下的、不同车型的截距与回归系数。 图4. (左）- 依据信息预测估值；（右）- 历史成交和倡议 ...

迷信欠缺的数据指标体系是企业发展数字化经营治理、打造数据驱动型组织的重要撑持。透过多维度的数据指标，经营人员可能清晰理解业务现状，产品/研发人员可能高效定位系统问题，管理人员可能更加精确地做出剖析决策。 那么，如何在充沛了解业务需要的根底上，搭建出一套无效、好用的数据指标体系？本文对个推TechDay“治数训练营”系列直播课第三期进行了回顾，与大家分享《数据指标体系设计与开发实战》。  课程回顾数据指标与指标体系数据指标是一种特定类型的元数据信息，是将业务单元细分后量化的度量值，同时也是业务和数据的交汇点。数据指标使得业务指标可形容、可度量、可拆解，可能为产品经营日常开发迭代以及疏导科学决策提供可量化的反对。 数据指标个别分为后果型指标和过程型指标两类。后果型指标，用于掂量用户在某个动作后所产生的后果，以及度量某个场景下用户的需要是否失去满足，这个后果通常是延后晓得的，人们很难进行干涉。过程型指标，是指用户在做某个动作的过程中所产生的指标，过程性指标更加关注用户的需要为什么被满足或者未被满足，人们可通过特定策略来影响过程性指标，从而影响最终的后果。例如，就一场电商促销流动而言，最终的销售额是后果型指标，商品页面的曝光、点击、加购等数据均为过程性指标，电商经营人员通过经营策略晋升曝光量、点击率、加购转化率等过程性指标从而影响最终的后果型指标。 通过剖析销售转化链路各环节上的数据指标，业务人员可能清晰掌握业务状况 单个的数据指标并不能残缺地反映业务经营状况，还须要咱们从全局登程，将零散、单点的、具备互相分割的指标，系统化地组织起来，构建一套数据指标体系。 数据指标体系的建设过程其实也是咱们对业务实质进行思考的过程。一套迷信、残缺的数据指标体系可能掂量业务倒退品质，帮忙咱们通过单点看业务全局，通过全局解决单点的业务问题。  数据指标设计与开发企业构建数据指标体系首先要依据业务指标，梳理相应的数据指标。咱们举荐参考OSM 模型来拆解业务指标，实现数据指标的设计。 OSM模型其中的“O”指的是指标Objective，“S”指的是策略Strategy，“M”指的就是度量指标Measurement。以电商经营场景举例，电商平台的经营指标（O）往往是进步GMV。依据公式“GMV=领取用户数×每笔单价×用户购买频次”，那么其晋升策略（S）和对应的度量指标（M）可能是：✦ 晋升领取用户数策略（S）是给予新注册用户9.9限时特价福利，度量指标（M）是新注册用户数。✦ 晋升每笔单价策略（S）是进行商品组合销售，度量指标（M）是每笔订单均匀单价。✦ 晋升用户购买频次策略（S）是节假日进行优惠券营销，度量指标（M）是用户下单频次。  OSM模型将巨大形象的指标拆解成系列具体的、可落地、可度量的行为，实用于产品经营、用户经营、绩效治理、企业经营等泛滥场景。以用户剖析场景为例，通过OSM模型和UJM用户旅程地图模型（User-journey-map）的联合应用，经营人员可能将用户从点击、浏览到加购、下单、分享的全过程体验进行量化治理，找出影响用户最终购买转化率的关键环节，并针对性进行优化。 再比方，在产品经营场景，产品人员将OSM模型和HEART模型联合，通过一系列指标来量化评估用户对产品特定性能的应用体验，为产品迭代降级提供数据撑持。  指标分级数据指标体系设计是一项比较复杂的工作，还须要企业依据本身战略目标、组织及业务过程等进行自上而下的指标分级，从而使管理层、业务人员等不同角色都能更高效地了解数据指标含意、透过数据指标的稳定疾速定位相干问题。 一般而言，咱们将数据指标分为三级：第一要害指标（又称“北极星指标”）、一级指标和二级指标。比方打车类App的第一要害指标是成单率，将成单率拆解，即可失去两个一级指标，别离是发复数、完复数；再将一级指标完复数拆分，可失去司机勾销订单数量、乘客勾销订单数量等二级指标。对于客服人员来讲，更须要关注二级指标，跟进理解司机和乘客勾销订单的起因，解决司乘用户体验问题。而对于打车类App的经营人员来讲，还须要更多关注发复数、完复数等一级指标，通过经营和激励措施晋升相应指标。  指标设计 设计指标前，咱们须要理解指标的几大组成因素：维度、度量、统计周期、过滤条件等。其中维度是描述性数据，指的是地区、产品名称、产品类型等指标统计的环境；度量是数字性数据，比方产品销售额、账户余额等；统计周期指的是计算指标的工夫范畴，比方本月、本季度、本年度等；过滤条件指计算指标的条件限度，比方无效状态、非工作日的等。 指标的组成因素决定了指标的生产逻辑。依据组成因素、生产逻辑的不同，数据指标可被分为原子指标、派生指标、复合指标等类型。其中原子指标，指的是对某一业务行为事件的度量，比方交易笔数、交易金额、交易用户数、账户余额；派生指标，指的是基于原子指标进行维度、统计周期或过滤条件的派生，比方近一周的账户生产金额、上一年的账户余额等；而复合指标就更为简单，个别是对多个指标进行加减乘除等运算得出，比方2022年月均匀GMV、投资年化收益等。   指标元数据企业能够依据指标类型、生产逻辑的不同，清晰梳理出生产指标所须要的数据源以及须要构建什么样的数据模型以计算得出指标后果。为了更标准地进行指标生命周期治理，咱们倡议企业能够输理出一份指标元数据说明书，清晰列举指标名称、指标编码、指标目录、指标分类、业务口径、技术口径、指标责任人、指标数据更新频率、形容信息等重要内容，给数据开发人员、指标应用人员、指标保护人员等提供更详尽的领导和参考。 指标评审与开发实现指标模型、指标内容等设计后，数据分析师/数仓架构师会召开指标评审会议，与数据开发/业务人员在指标的定义、业务口径、技术口径、更新周期等方面充沛探讨并达成一致意见。 业务人员是数据指标的需求方和使用者，在派生指标维度有哪些、统计周期是什么、复合指标由哪些指标加工而成等问题上可能提出建设性意见；数据开发人员较为理解企业的数据源现状，可能在派生指标由数仓的哪些数据模型加工产出等技术问题上给出业余倡议。 综合多方在指标评审会议上的反馈，负责指标开发的数据分析师/数仓架构师可对指标元数据和指标生产逻辑进行优化迭代，正式启动指标开发工作。  经验总结数据指标体系是企业十分重要的一项数据资产，联合咱们进行数据治理和指标体系建设过程中积攒的教训，咱们倡议大家在建设数据指标体系过程中把握以下三个要害要点：①遵循一套标准规范的指标搭建方法论，设计企业级的数据指标体系；②有一套对立的流程管制机制，对数据指标的生命周期进行全面把控和治理；③建设对立的指标治理平台，对数据指标进行集中管理，将指标资产积淀下来。  Q&A精选 直播过程中，大家就课程内容进行了交换，本文筛选了直播间的精彩发问做了Q&A梳理。  Q1：如何应用非结构化数据和半结构化数据搭建指标体系？这须要具体问题具体分析。一般来讲，咱们建设指标体系时，针对的都是结构化数据。对于非结构化数据，咱们还须要先将其治理、转换成结构化数据，后续再进行指标体系的建设。比方，对于视频格式的数据，咱们须要借助视频辨认算法将视频格式数据转换为结构化数据，将其纳入到整个数仓体系内，后续再针对性进行指标体系的搭建。 Q2：如何掂量指标体系的品质？高质量的指标体系不仅可能清晰反映企业经营现状，还可能给不同层级的人员应用，帮忙企业/组织更好地倒退。目前，很多企业都建设了数据看板、数据驾驶舱，依据不同主题对多种数据指标进行组合展现，帮忙管理层、中层领导、业务人员可能查看企业经营情况，剖析和研判企业经营问题，掂量业绩和经营指标达成状况。为了帮忙企业更便捷、高效地剖析和应用数据，个推每日治数平台DIOS采纳低代码的设计理念，使得营销、HR、财务等不同部门的业务人员也够能灵便创立数据看板、数据门户等数据利用，将数据指标体系的价值施展进去，更及时、迅速地响应业务场景中遇到的多样化数据需要。 Q3：能够应用数据湖中的非结构化数据建设指标吗？能够的。数据湖扭转了原来数仓先进行数据处理后进行数据应用的形式，数据湖强调先存储数据，待后续想要应用数据时再思考具体的数据加工解决形式。 数据湖中存储了大量的半结构化和非结构化数据，比方图像、语音、视频等。如何高效地从非结构化数据中提取有价值的信息，是咱们应用数据湖中非结构化数据建设指标体系的难点。  关注个推技术实际微信公众号，后盾回复“指标”，获取本期直播课件~ 下期预报个推TechDay治数训练营第四期行将来袭！11月30日（下周三）早晨19:30-20:30，来自个推治数平台部的资深数据产品经理将为大家具体梳理企业进行标签体系建设的方法论与外围策略，深刻分享标签数据的资产化经营治理教训，解读画像标签体系的场景利用案例。  

“数据加载速度变快了。”这是小吴在应用 DataWind 后的第一感触。 目前就任于国内一家手机企业的小吴，次要负责手机自带游戏的市场营销数据分析工作。她介绍，数据分析的前提是可能高效地将扩散在不同广告平台的根底数据及时回收，“通常状况下，各个广告平台都是一套独立的零碎，传统的做法是，咱们会去跟各个平台将营销期内的数据底表下载到本地，而后人工去合成一张贮存在本地的整体大表。” 显然，这并不是一套高效的工作流程——通过人工操作的模式，收集齐所有广告平台数据往往须要破费 1-2 个工作日工夫，此外，因为数据底表类似且复制、粘贴反复动作交替，数据整顿出错的状况也时有发生。 “咱们也尝试过目前市场上一些比拟罕用的 BI 产品，”小吴说道，“但其实加重跨平台数据接入的老本压力只是第一步，包含在数据分析、数据展示和数据利用上，咱们还有更多的需要，因而过来的一些 BI 产品比拟难以一次性满足。” 2021 年 5 月，抱着“再试一次"的心态，小吴所在的团队引入了火山引擎数智平台 VeDI 旗下智能数据洞察 DataWind。作为 VeDI 面向企业数据分析场景推出的智能数据洞察产品，DataWind 在历经字节跳动外部多业务多场景实际后，已全面对外进行能力输入。 通过 DataWind，小吴曾经实现罕用广告平台的数据接入，能够实时同步营销火线的数据体现，“从过来的 1-2 个工作，到当初简直 1 秒反馈，这两头多进去的时间差，足以撑持咱们在营销动作还没完结时，就实现前一阶段的数据分析，并将其提供给业务团队，保障对方可能及时实现策略调整，实现预期指标。” 除此之外，小吴对 DataWind 数据报表的展示速度也有体感，“尽管没有具体测算过，但根据当初团队共事们的广泛反馈，当初关上数据报表的速度确实会更快一些。” 但其实，“快”的背地是火山引擎自研 OLAP 引擎 ByteHouse 在做撑持——通过欠缺大数据自助剖析场景的定向优化，目前 DataWind 的查问性能失去极大晋升，比照市场同类型产品而言，在 500 万数据量级内 DataWind 的关上速度放弃在 1 秒以内，而在 5000 万数据量级以上，DataWind 的关上速度则为市场上同类 BI 产品的四分之一。 而在“反对跨平台数据源接入”和“数据分析、展示速度快”的根底需要被满足之后，小吴还提到了第三点，“咱们团队应用的外部沟通工具就是飞书，而通过飞书，即使是通过手机挪动办公，我也能随时随地查看数据。” 小吴所说的通过飞书随时随地查看数据，其实是往年 DataWind 实现的一项性能降级——在应用场景上，DataWind 曾经与飞书、企业微信等在线协同办公 IM 工具全面协同，像小吴一样日常有数据应用需要的员工，通过飞书等就能够实现 DataWind 数据服务一键订阅，突破工夫空间限度，随时随地查看数据、应用数据。 截至目前，DataWind 已在批发、汽车、手机、金融等多个行业实现实际验证，受到企业欢送。 点击跳转火山引擎智能数据洞察DataWind官网理解更多

抖音的名字是怎么来的？ 在字节跳动火山引擎技术开放日上，字节跳动副总裁杨震原曾走漏过“抖音”名字的来历。杨震原过后在现场笑着讲，“抖音”的名字不是传闻中找巨匠算进去的，而是综合了 A/B 测试和人为判断的后果。 过后，“抖音”这个名字在 A/B 测试后果中排名并不是第一，而是第二。但综合人为判断，产品组的同学们还是感觉“抖音”这个名字更合乎产品认知，更能体现产品状态，所以最终选了它。 杨震原介绍，当年做短视频产品时，有很多候选名字和不同的产品 demo。团队同学把这些 demo 产品起成不同的名字、用不同的 LOGO，以同样的估算、同样的地位，在利用市场商店做了 A/B 测试，看哪个在下载数据上是体现最好的。 这个 A/B 测试的办法能测出用户对这个名字的关怀水平、吸引力水平、下载转化率等。最终，"抖音"排名第二，但因为它更合乎产品的须要，被最终选为产品名称。 所以，杨震原说，在字节，A/B 测试的过程，有时不齐全看它的论断，但它会给你带来很多不同视角的认知，这就是教训带来的偏差。 A/B 测试能够纠正这些偏差。这个过程，肯定水平上也反馈了火山引擎 A/B 测试产品——DataTester 的特点。 所谓 A/B 测试，实质上是一种分离式分组试验，简略讲就是为同一个指标的达成制订两种计划——A 计划和 B 计划，而后记录、追踪用户应用状况和数据，看看哪一个计划更优，而后试验后果能够辅助业务更好决策。 当然，A/B 测试这项工具并不是万能的，也存在很多利用局限，比方独立性、置信度、长短期等问题。因此须要综合非 A/B 测试数据、教训判断来进行综合决策。 始终以来，DataTester 都是字节跳动一项十分根底的工具。字节跳动在产品命名、交互设计，比方改一个字体、一个弹窗、界面大小，都会做 A/B 测试；。包含举荐算法、广告优化、用户增长、市场流动等方面，也都在用 A/B 测试。 字节跳动当初每天大略新增 1500 个 A/B 测试试验，服务了 400 多项业务，累计曾经做了 70 万次试验。DataTester 当初已通过火山引擎，开始对外开放给更多企业客户，让更多内部用户能够应用这个增长利器。 基于字节跳动的成长理念，以 A/B 测试延长开来的火山引擎，对外提供的整套的解决方案，中小企业也能借助字节跳动的技术力量拥抱最新的产品趋势，融入字节跳动的各种方法论，打造更加优良的产品。 点击跳转火山引擎A/B测试DataTester官网理解详情

2022年11月7日，Taier1.3版本正式公布！ Taier 是一个大数据分布式可视化的DAG任务调度零碎，旨在升高ETL开发成本、进步大数据平台稳定性，大数据开发人员能够在 Taier 间接进行业务逻辑的开发，而不必关怀工作盘根错节的依赖关系与底层的大数据平台的架构实现，将工作的重心更多地聚焦在业务之中。 Taier自往年2月份开源之后，失去了社区开发者的广泛支持，咱们踊跃排汇社区开发者的意见建议，一直迭代版本，目前已公布了Taier1.1、Taier1.2这两个大的版本更新。 本次公布的Taier1.3版本，咱们新增了Flink Standalone组件，交融了DataSourceX的模块，并新增了Python、Shell、ClickHouse、Doris SQL等多种工作，工作数据源绑定，工作反对指定队列运行，并进行了部署优化，同时对官网社区的UI进行了全新的降级革新。 目前新版本已在Github与Gitee上线，同时应用文档也在社区推送，大家能够随时下载查阅，欢送大家返回体验（喜爱咱们的我的项目欢送大家点个Star），体验地址： Github: https://github.com/DTStack/Taier Gitee： https://gitee.com/dtstack_dev... 社区官网： https://dtstack.github.io/Taier/ 同时为了不便没有钉钉的开发者们更好的交换Taier开源技术，咱们新建了Taier开源技术微信交换群，欢送大家退出一起探讨开源技术~ Taier1.3版本详解01 新增Flink Standalone新增Flink Standalone组件，能够通过Flink Standalone应用Flink SQL、数据同步、实时采集等工作相干性能。移除Taier对Hadoop组件的强依赖，反对轻量化的数据处理。 02 DataSourceX交融Taier交融DataSourceX模块，移除Taier内部插件依赖。新增数据源插件相干个性，反对后续Taier对接更多的RDBMS类型的SQL工作。 03 新增Python、Shell工作新增Script组件，反对Python、Shell工作类型，能够在Taier上通过脚本类型工作进行操作。 04 新增ClickHouse、Doris SQL工作新增ClickHouse、Doris SQL工作类型，反对数据同步脚本模式到ClickHouse、Doris，再进行任务调度解决。 05 工作数据源绑定控制台组件移除SQL类型组件配置，SQL工作间接和数据源相互绑定，反对工作和数据源一对一的执行，将SQL执行域细分到具体的单个数据源。 06 工作反对指定队列运行Hadoop类型工作反对指定队列运行，队列资源隔离细分到工作级别。 07 部署优化Taier优化单机部署，优化前后端部署操作，简化docker镜像部署流程，升高上手难度。 08 官网降级Taier社区新官网上线，UI设计全面降级。 后续版本布局Taier往年更新了3个大的版本，依照社区规划，后续版本咱们打算重点围绕关键点： ● 欠缺Taier Datasource 模板反对SQL工作 ● HadoopMR、Spark Jar、PySpark 工作反对 ● 工作告警 ● Windows开发环境适配 咱们欢送社区的开发者们一起参加到Taier的版本建设中来，同时大家如果有其余的意见建议也能够给咱们提一个Issue或者PR，大家能够来一起探讨怎么更好的共建我的项目。感兴趣的小伙伴们能够退出咱们的技术交换社群，一起交换Taier的技术问题及难点，共建Taier！ 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack/Taier

2022年云栖大会上，阿里巴巴团体副总裁、阿里云计算平台事业部负责人贾扬清发表阿里云一体化大数据平台ODPS全面降级。降级后的ODPS反对对立存储、对立调度、对立元数据的一体化交融架构，反对离线计算（ODPS-MaxCompute）、实时交互式剖析(ODPS-Hologres)等引擎，提供机器学习、流式计算等可扩大的计算能力，具备寰球当先的技术性能和产品性价比。 10月31日，国内事务处理性能委员会（TPC，Transaction Processing Performance Council）官网公布TPC-H 30,000GB规范测试最新后果，首次加入此项评测的ODPS-Hologres以QphH超2786万分的性能后果斩获寰球冠军，当先第二名23% TPC-H是公认的掂量产品数据分析能力的权威规范测试之一，其QphH指标反映了零碎解决查问的多方面能力，包含数据规模的大小、串行提交时的Query提早、多租户并行提交时的Query吞吐等，是代表产品的综合性能的重要指标。TPC官网显示，ODPS-Hologres在[email protected],000GB达2786万分，为寰球第一。该问题证实了ODPS-Hologres在大规模数据多维分析（OLAP）场景上兼具超低提早和高吞吐性能，具备世界级数据分析性能，技术先进性可满足业务对数据的极速摸索需要。同时，ODPS-Hologres在性价比指标Price/kQphH的体现也领跑寰球，彰显了其以较低成本在大规模数据上取得极致性能的能力。 此外，作为ODPS的另一个主力计算引擎MaxCompute，也在TPCx-Bigbench 100TB规范测试中，从数据规模、性能、老本三个方面，自2017年以来间断6年放弃寰球冠军。2022年，更是较2021年在性能上晋升40%，同时老本降落近30%。 友邦人寿基于阿里云ODPS建设云上数据中台，实现外部数据对立的开发、服务、治理，数据处理效率晋升20倍，整体老本优化数百万元。依靠云的弹性扩大能力平滑应答“开门红”等业务流量顶峰，保障高峰期的实时剖析决策。 阿里云一体化大数据平台ODPS将继续夯实一体化的体验同时，满足客户多元化计算需要，为企业智能翻新提供基石般稳固保障。

在经济面临上行压力、疫情重复等不确定因素之下，推动数字化转型就成为了许多企业的“救命稻草”。然而，较高的数字化转型门槛、不成零碎的数据服务，以及不足标准的行业标准等都成了企业数字化转型路上的“绊脚石”。 2015年，袋鼠云成立并决然投身于具备微小想象力的数字经济倒退浪潮，通过7年致力实际，不断完善本人的数字化服务能力，在牢固地基的根底上一直向上搭建应用层，致力于让更多的企业可能一站式实现数字化转型。 现在，袋鼠云已胜利服务5000多家客户，涵盖金融、政务、教育、制作等20+行业。11月初，袋鼠云刚刚发表实现过亿元C+轮融资。袋鼠云秉承着“让数据产生价值”的使命，以科技翻新驱动倒退，一直迭代优化解决方案和生态构造，其中与阿里云的单干不得不说。 01 从“打地基”到“建房子”，袋鼠云全链路布局往年7月，以“数智进化，当初即将来”为主题的袋鼠云2022产品发布会正式揭幕。发布会上，袋鼠云公布了以数栈DTinsight、易知微EasyV、数雁EasyDigit、数驹DTengine为外围的全新产品体系。 该产品体系涵盖一站式大数据开发与治理平台、低代码数字孪生平台、数据智能剖析与洞察平台、极速湖仓引擎，将在贮存计算、开发治理和利用三个层面助力更多企业一站式实现数字化转型。这次全新产品体系降级帮忙袋鼠云实现了从“数字化基础设施供应商”降级为“全链路数字化技术与服务提供商”，也标记着它从“根底层”到“应用层”的拓展。 对此，袋鼠云董事长陈吉平示意：“Google的安卓生态体系成熟之前，得做好安卓操作系统，同样，微软生态体系，包含Office崛起之前，是先做了Windows操作系统。用户抉择某个平台，更看中的是下面所附带的利用。咱们当初做事件的逻辑跟它们是一样。” 过来，袋鼠云专一于“打地基”，做好根底技术底座与数据治理服务，在技术层和数据价值开掘上施展出最大的劣势；现在，随着服务的深刻以及客户事实需要的呈现，袋鼠云在此之上一直地“建房子”，发明了更多应用层。 例如在银行业，规范化指标加工与治理，主动进行指标工作的调度、指标数据生成，实现监管报送、征信报送、危险管制等场景，让信贷经营更加高效。 在证券行业，通过剖析行情数据、股票交易数据、两融数据、资金等数据，进行标签萃取，造成360°的证券用户标签体系，对用户进行标签的分级分类治理，实现智能选股、智能投研、危险管制等场景，助力证券业务营销与风控。 在基金行业，通过剖析清理零碎、自营APP、OTS零碎、客服零碎等数据，搭建画像剖析体系，实现“业务、技术、数据”的三位一体，精准地为用户匹配理财产品。 袋鼠云将来在产品研发上将一直晋升国产大数据软件的比例，通过进步技术的深度和自主掌控力。 比方极速湖仓引擎“数驹DTengine”中的大数据根底平台EasyMR基于最新的开源技术，提供Spark、Flink、Trino、HDFS等大数据组件和服务，可为企业提供大数据基础设施底座。 比方，袋鼠云基于长期价值登程，于2021年5月投资成立了子公司易知微，深耕数字孪生产业生态，致力于“让每一个组织和个体都看见并受害于数字化”。自主研发、自主可控的低代码数字孪生可视化平台EasyV，联合WebGL、3D游戏引擎等技术，致力于建设数字加强世界，帮忙客户实现数字化治理，减速数字化转型。 同时，基于DataOps理念，袋鼠云整合四大产品，买通不同产品之间的流程，进步产品间的协同和联动效应，打造集数据全生命周期的开发、治理、服务于一体的一站式大数据平台，大大缩短数据体系建设的周期，并升高后续的数据经营投入老本。 11月9日，易知微将举办在线发布会，包含自研数字孪生渲染引擎EasyTwin、可视化SaaS平台EasyV6.0，以及数据治理和数字孪生行业最佳实际等，将正式和大家见面。 02 从“保姆式”到“管家式”to B，继续为客户发明价值陈吉平负责过阿里团体数据资产与数据安全团队负责人，还曾是淘宝第一代数据仓库建设者，见证了阿里巴巴团体数据中台“从0到1”的整个过程。 正是在阿里的过程中，陈吉平发现市场对大数据的强劲需要，即使是占据中国公共云市场50%份额的阿里云也无奈齐全满足，阿里云急需生态合作伙伴。正在打算守业的陈吉平，随即自立门户于2015年11月成立了袋鼠云。 创业维艰，陈吉平也不例外。在成立的这7年里，袋鼠云经验了几次不一样的艰难。好在袋鼠云足够侥幸，走得也足够稳，在很短时间里失去市场和投资者的认可。 与泛滥企业一样，袋鼠云这几年也面临来自疫情的挑战。今年初，袋鼠云及时调整策略，更加重视回归商业实质，致力在现有根底上实现盈利。 同时，超出同行的前瞻性也帮了袋鼠云大忙。它很早就避开了房地产、在线教育、批发等行业，而是抉择了“足够牢固的洞穴”。由此，疫情之下的袋鼠云也只是“受了点皮内伤”。 除了前瞻性，袋鼠云服务市场更强调主动性。 陈吉平示意：“袋鼠云做的是‘管家式’to B，显著不同于传统的‘保姆式’to B。”换句话说，袋鼠云擅于被动地去发现用户需要，为用户发明价值。并且，管家式的to B更加重视长期的服务。 通过抢占数字化的外围点，袋鼠云可能精准把握客户的外在需要，并为此持续性提出正当的解决办法，与客户之间建设一个短暂的单干关系。 那么何为“数字化的外围点”呢？ 陈吉平举例类比称：“数据挖掘好比‘挖石油’，数据治理好比‘石油冶炼’，尽管冶炼进去的石油产品也有价值，然而，最终谁能能创造柴油机或者发电机，将这些石油资源进行最大价值的扩大，转化成动能、电能之类的，那就意味着谁就把握了数据的外围价值点。” 管家式的to B服务还有助于全面深刻地理解一个企业的现状，将各部门不同阶段数据买通，放慢企业数字化转型。 从“保姆”到“管家”，袋鼠云始终秉承着公司“让数据产生价值”的使命。 03 最心愿的是先“做大蛋糕”，而非急于“瓜分蛋糕”数字化转型是一个极其简单的系统性工程，绝非可能靠一己之力就可能实现，它须要各方力量汇聚以及各种技术的独特承载。 “一花独放不是春，百花齐放春满园。”袋鼠云作为数字化转型技术服务行业的先行者，深谙此理。陈吉平天然也是深知深入与生态搭档的单干，先“做大蛋糕”的策略。 以后，袋鼠云最心愿做的也正是“做大蛋糕”，而非急于“瓜分蛋糕”。它心愿更多同行退出进来。尤其是随着数字经济的前行，企业数字化转型逐步深刻，过来的一系列问题也逐步裸露进去。 首先最紧迫的问题之一就是行业不足统一标准，最终造成“数据孤岛”。“数据孤岛”问题若能一直解决，就能升高进入行业的门槛，带来更多的入局者，从而为用户提供更欠缺的数字化服务。 袋鼠云早已察看到此类问题，并付诸致力去扭转。 比方，一些过来参考的系列规范的局部内容已不实用，不足对元数据形容、扩大、校验等内容的规范性领导。袋鼠云就联结浙江省标准化研究院等10余家单位制订的全国首个《数据中台 元数据标准》个人规范，让行业数据逻辑更对立，从而缩小数据反复建设和数据非必要壁垒。 再比方，因为不同企业的数字化转型波及到的行业门类泛滥，场景也千差万别，如何精准地把握市场需求并为此提供专业化服务成了泛滥数据中台供应商的业务难题。 对此，袋鼠云的解决办法总结起来还是两个字“单干”。袋鼠云通过与生态合作伙伴共创解决方案，满足不同客户的需要，从而给不同行业的客户创立数据的价值。 现在，袋鼠云曾经服务了包含厦门建发团体、厦门国贸团体、厦门象屿团体、中化团体、中交二航局、宁波舟山港股份、万向集团、蒙牛乳业等多家500强企业，以及中国银联、华夏银行、国泰君安、招商证券、中金公司、中国安全、杭州东站枢纽管委会、杭州西湖景区治理委员会、教育部、浙江大学、四川大学、东风本田、吉利汽车、将来电视和航天科技、航天科工、中国电子、航空工业等（排序不分先后）超5000家客户。 04 成长在阿里云，携手云原生加速器，创立数字化服务生态闭环从云计算、数字化再到数智化，每一次迈步都标记着数字化转型迎来一个新的终点，整个数字化零碎须要产生新的降级迭代。 20多年前，企业广泛应用ERP、CMR做信息化改革；10多年前，生产互联网崛起时，互联网技术流行；现在，在产业互联网背景下，云原生成了更多用户的抉择。 中国信息通信研究院的钻研称，预计2022年云原生市场规模将超500亿元，并且将来发展前景非常可观。 阿里云作为寰球云计算领军者之一，云原生产品的集大成者，领有最大规模的云原生利用实际。从互联网经济开始，阿里云已逐渐延长到金融、政企、游览、教育、能源、批发等各行各业，生态合作伙伴也日渐扩充，可能帮忙客户构建“全、统、通”的大数据体系。 面对广大的市场，为了打造丰盛的云原生生态圈，阿里云在2021年正式启动了云原生加速器，通过强烈的线下路演，最终31家企业入选阿里云首期云原生加速器，其中超半数企业为B轮及以上融资，1/5企业为C轮及以上，入选企业总估值超过338亿。袋鼠云凭借大数据开发与治理平台、数字孪生和可观测运维等技术能力，以及丰盛的落地利用计划，胜利入选阿里云首期云原生加速器成员名单。 因为团队中弱小的阿里系守业基因，袋鼠云从一开始就和阿里云有着人造的默契感，也有着较高的单干终点，天然也成为阿里云生态合作伙伴。随着转型的深刻，企业的利用零碎越来越多，越来越简单，监控工具扩散、故障解决工夫长、运维效率低等问题也一一浮现，传统的IT零碎与保障形式已不能再适应新需要的变动，可能晋升数据价值、增强运维效率的数字化运维跃然纸上。 正是基于市场的迫切需要，阿里云与袋鼠云携手，联合开发推出ACOS对立运维监控平台，产品反对多源及海量的IT及业务数据接入、欠缺的数据处理和剖析，无效解决监控工具各自为政、数据处理和实时剖析能力单薄等难题，晋升工作效率。 当今的商业竞争格局之下，单干共赢已是大势所趋。“让数据产生价值”是袋鼠云的使命。为了更好地实现这个使命，袋鼠云曾经从“数字化基础设施供应商”降级为“全链路数字化技术与服务提供商”。这也将成为它将来为客户发明更多价值，行稳致远的要害力量。 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack/Taier

近日，国内当先的数字化技术与服务提供商——袋鼠云发表实现过亿元C+轮融资，本轮融资由源星昱瀚基金、国中资本、深创投投资。 本轮融资资金将次要用于袋鼠云外围产品的研发、产品生态体系建设和市场营销推广等方面。始终以来，袋鼠云都牢记“让数据产生价值”的使命，以科技翻新驱动倒退，一直迭代优化解决方案和生态构造，助力客户实现一站式数字化转型。现在袋鼠云已胜利服务5000多家客户，涵盖金融、政府、教育、军工、制作等20+行业。 为攻克“卡脖子”难题，袋鼠云在技术创新上不遗余力，2017-2022年，公司研发费用逐年晋升，研发费用占比高达20%以上，高于行业研发投入的平均水平。截至目前，袋鼠云已取得发明专利、软著等知识产权达180多项。与此同时，凭借科技成果转化和在高新技术产业倒退中的作用，袋鼠云还荣获国家高新技术企业、省级高新技术企业研发核心、杭州市专利试点企业、浙江大学联结科研、产学研基地等资质。 打造四大全新产品体系，实现全链路赋能 自2015年成立以来，袋鼠云始终走在数字化行业前列，不仅取得寰球权威IT钻研机构Gartner的继续认可，2020-2022间断3年获评“数据中台标杆供应商”，另外，2022年袋鼠云旗下品牌易知微的低代码数字孪生可视化平台——EasyV作为标杆产品也被收录为Gartner“中国剖析平台代表厂商”；除此之外，袋鼠云于2022年起草公布全国首个《数据中台元数据标准》个人规范，为困扰行业多年的“数据孤岛”问题摸索解决之道。基于多年来对行业、客户的粗浅洞察，2022年7月，袋鼠云定位再次进行降级，从“数字化基础设施供应商”，降级为“全链路数字化技术与服务提供商”。 为助力更多企业能够一站式实现数字化转型，袋鼠云对旗下产品进行全方位布局降级，构建了四大全新产品体系：一站式大数据开发与治理平台“数栈DTinsight”、低代码数字孪生可视化平台EasyV、数据智能剖析与洞察平台“数雁EasyDigit”和极速湖仓引擎“数驹DTengine”，在贮存计算、开发治理、数据可视化及数字孪生与数据利用多个层面助力更多企业一站式实现数字化转型。 将来，在产品研发上，除了继续的研发投入与自主可控之外，袋鼠云也在一直晋升国产大数据软件的比例，通过进步技术的深度和自主掌控力，实现对国外支流大数据产品Informatica、DataStage、TeraData、Cloudera CDP、Oracle等软件产品的国产化代替。 比方极速湖仓引擎“数驹DTengine”中的大数据根底平台EasyMR基于最新的开源技术，提供Spark、Flink、Trino、HDFS等大数据组件和服务，可为企业提供大数据基础设施底座，致力于Cloudera CDP等国外Hadoop商业版的国产化代替。 比方旗下全资子公司易知微自主研发、自主可控的低代码数字孪生可视化平台EasyV，联合WebGL、3D游戏引擎等技术，协同各个行业的生态搭档独特建设数字加强世界，帮忙客户实现数字化治理，减速数字化转型。 同时，基于DataOps理念，袋鼠云整合四大产品，买通不同产品之间的流程，进步产品间的协同和联动效应，打造集数据全生命周期的开发、治理、服务于一体的一站式大数据平台，大大缩短数据体系建设的周期，并升高后续的数据经营投入老本。 凭借全链路赋能的模式，现在袋鼠云已赋能5000多家客户胜利进行了数字化转型，包含厦门建发团体、厦门国贸团体、厦门象屿团体、中化团体、中交二航局、宁波舟山港股份、万向集团、蒙牛乳业等多家500强企业，以及中国银联、华夏银行、国泰君安、招商证券、中金公司、中国安全、杭州东站枢纽管委会、杭州西湖景区治理委员会、教育部、浙江大学、四川大学、东风本田、吉利汽车、将来电视和航天科技、航天科工、中国电子、航空工业等（排序不分先后），真正让数据产生价值。 紧随国产代替浪潮，共建信创产业生态圈 10月28日，国务院对于数字经济倒退状况的报告明确，我国要牢牢抓住数字技术倒退主动权，把握新一轮科技反动和产业改革倒退先机，大力发展数字经济。具体指出要放慢深入产业数字化转型，开释数字对经济倒退的放大、叠加、倍增作用，数字化转型已成为在中国经济倒退中的支流基调。 数字化转型并非易事。近年来，国内环境日益简单和深入，中国的高科技倒退频频面临“卡脖子”窘境，国防、科技平安重要性一直凸显，建设由我国主导的、自主可控的IT生态尤为迫切。在这样的背景下，信创产业疾速倒退，开始成为中国经济数字化转型、晋升产业链倒退的要害。 袋鼠云作为国内当先的数字化技术与服务提供商，始终保持自主研发和国产化路线，踊跃推动产品与根底软硬件的兼容适配。国产化代替的大趋势下，袋鼠云已与麒麟软件、中科方德、浪潮云、华为云、阿里云、瀚高、龙芯科技、中兴通讯等16家国内支流操作系统、服务器、数据库、芯片厂商实现产品兼容性互认证。这大大晋升了袋鼠云旗下产品在国内企业应用环境中的兼容性和扩展性，在软硬件层面全面兼容X86、ARM、MIPS架构体系，反对市面所有私有云、公有云、混合云厂商平台，反对CDH、TDH、Libra、Fushionlnsight等存储引擎。 弱小的国产信创生态血统和自主研发基因，使得“袋鼠云系产品”在国产市场中的利用蛟龙得水。凭借在信创畛域获得的突出成就，袋鼠云被评为2021信创产业实干者盘点实干企业，入选中国信通院开源供应商名录，同时还是中国信创服务社区、长沙市信创联盟、安徽省信创联盟成员。 在时机与挑战并存的时代，袋鼠云始终砥砺前行，为客户、市场和社会提供更高价值的全链路数字化服务，让数据惠及更多的组织。此次取得C+轮融资，袋鼠云弱小的技术创新实力与服务能力将进一步凸显，从而实现在数字化技术服务赛道上的一路领跑，将来前景值得期待。 对于本轮融资，源星昱瀚基金合伙人张帆示意：“随着倒退数字经济回升到国家策略高度，信创产业国产化是大势所趋。袋鼠云作为国产信创生态中的一员，领有弱小的国产信创生态血统和自主研发基因，行业实力引人注目。咱们看好袋鼠云的技术实力和服务落地能力，也见证了袋鼠云产品矩阵和倒退策略的不断完善。期待将来和袋鼠云一起见证更多案例的落地，携手推动数字化时代的倒退。” 深创投投资团队示意：“首轮投资以来，袋鼠云的倒退引人注目，各项经营指标和治理构造继续优化，曾经逐渐成长为当先的国产大数据基础设施提供商，多个翻新产品在国际性技术社区胜利公布，对诸多海内大数据根底产品造成代替，在数字化转型的长坡厚雪中造成了本人的品牌，失去了行业的尊重和客户的认可。” 布局数字孪生，减速产业数字化 2021年以来，以数字孪生为核心技术的“产业元宇宙”概念的爆发式衰亡，使得数字孪生技术失去了学术界和工业界的多方重点关注。数字孪生技术在智慧城市、智能制作、能源水利、交通港口等垂直行业宽泛拓展，产生了智能运维、虚构调试、异样诊断、危险预测、决策辅助、系统优化等诸多利用价值，已成为助力企业数字化转型、进步生产效率和促成产业数字化的重要抓手。 作为当先的全链路数字化技术与服务提供商，袋鼠云基于长期价值登程，于2021年5月投资成立了子公司易知微，深耕数字孪生产业生态，致力于“让每一个组织和个体都看见并受害于数字化”。2022年11月9日，易知微将举办在线发布会，包含自研数字孪生渲染引擎EasyTwin、可视化SaaS平台EasyV6.0，以及数据治理和数字孪生行业最佳实际等，将正式和大家见面，开启数字孪生新将来，敬请期待！ 扫描下方二维码或点击浏览原文扫码即刻关注2022Easy Future易知微秋季产品发布会↓↓↓ 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack/Taier

导读： 首先做个自我介绍，我目前在阿里云云计算平台，从事钻研 Flink 和 Hudi 联合方向的相干工作。 目前，Flink + Hudi 的计划推广大略曾经有了一年半的工夫，在国内风行度也已比拟高，支流的公司也会尝试去迭代他们的数仓计划。所以，明天我介绍的主题是 Flink 和 Hudi 在数据湖 Streaming 方向的一些摸索和实际，将会围绕以下四点开展： Apache Hudi 背景介绍Flink Hudi 设计Hudi 利用场景Hudi RoadMap点击查看直播回放 Apache Hudi背景介绍首先和大家分享下数据湖倒退的历史背景，以及Hudi的根本个性。 1.  数据湖倒退的历史背景在我个人观点看来，传统的数仓计划（如 Hive）其实自身也是数据湖，而且我会把Hudi、Iceberg、Delta Lake 都看成是数仓下一代新的解决方案，而不仅仅只是一种湖格局。那为什么近一年来会有数据湖这一新的数仓状态的诞生？ 随同着目前云存储（尤其是对象存储）逐渐成熟的大背景，数据湖的解决方案也会逐渐往云原生凑近。如图一所示，湖格局会适配云厂商的对象存储，做云厂商多云和云厂商用例，同时适配比拟风行的大数据计算框架（如Spark、Flink），以及查问端的 Presto、trino 以及传统 Hive 引擎，因而诞生了这样一套新的数仓解决方案。 2. Hudi 的四大外围个性由上可知，Hudi 作为下一代的数仓解决方案，借助上下游的计算和查问引擎，实现代替传统 Hive 离线数仓的一套新计划，其外围特色整体能够总结为以下四点： 开放性开放性体现在两个方面：** 第一方面，上游反对多种数据源格局。比方传统数据库的 change log 日志、音讯队列 log 等传输方式，都会在 source 端会有十分丰盛的反对。** 第二方面，上游查问端也同样反对多种查问引擎。像支流的 OLAP 引擎 Presto、国内比拟火的 Starrocks、云厂商的 amazon redshift、数据分析产品 impala，都会对接到这样一套数仓架构外面。 所以开放性是 Hudi 的第一个特点。 丰盛的事务反对Hudi 对事务的反对水平，会比原来 Hive 数仓的要求更高，更丰盛。其中外围特点是反对在文件存储布局上做更新。在传统基于 Hive 的 T + 1 更新计划中，数据反复度会比拟高，只能实现天级别的数据新鲜度。并且随同着业务需要越来越简单，实时性要求越来越高，对数仓存储体系提出了更高的要求，对端到端的数据新鲜度要求做到分钟级或者是秒级。 ...

导读： 随着大数据技术的倒退，Spark 成为当今大数据畛域最受关注的计算引擎之一。在传统的生产环境中，Spark on YARN 成为支流的工作执行形式，而随着容器化概念以及存算拆散思维的遍及，尤其是 Spark3.1 版本下该模式的正式可用（GA），Spark on K8s 已成燎原之势。 明天的介绍会围绕上面两点开展： Spark on K8s 的根底概念和个性Spark on K8s 在阿里云 EMR 的优化和最佳实际点击查看直播回放Spark on K8s 的根底概念和个性首先和大家分享下 Spark on K8s 的一些背景。 1. Spark 的集群部署模式 Spark 现如今反对 4 种部署模式： Standalone：应用 Spark 的内置调度器，个别用于测试环境，因为没有充分利用到大数据的调度框架，无奈充分利用集群资源。Hadoop YARN：最常见的一种形式，源自 Hadoop，领有良好的社区生态。Apache Mesos：与 YARN 相似，也是一个资源管理框架，当初曾经逐步退出历史舞台。Kubernetes：即 Spark on K8s，Spark3.1.1 对这种部署模式正式提供可用反对，越来越多的用户也在踊跃做这方面的尝试。应用 Spark on K8s 的劣势如下： 进步资源利用率：无需依照应用场景部署多个集群，所有 Spark 作业共享集群资源，能进步总体集群利用率，而且在云上应用时能够弹性容器实例，真正做到按量付费。对立运维形式：能够利用 K8s 的社区生态和工具，对立保护集群，缩小集群切换带来的运维老本。容器化：通过容器镜像治理，进步 Spark 工作的可移植性，防止不同版本 Spark 带来版本抵触问题，反对多版本的 A/B Test。尤其须要关注的一点是，依据咱们的测试，在雷同的集群资源条件下，Spark on K8s 和 Spark on YARN 的性能差距简直能够忽略不计。再加上充分利用 Spark on K8s 的弹性资源，能够更好地减速 Spark 作业。 ...

“5G+天翼云+AI 与城市共成长”—— 天翼云中国行在重庆胜利举办，天翼云邀请泛滥合作伙伴独特探讨云、网、数、智产业新生态建设，为智慧重庆加码。本次大会上，天翼云推出“天翼云管+”服务，开启全新贴身云管家时代。 在疫情防控常态化的大环境下，国家新基建策略减速，5G、人工智能、大数据、云计算等深度交融造成新基建核心技术，数字技术掀起新一轮翻新低潮。作为数字经济和实体经济深度交融的国家数字经济翻新倒退试验区，重庆聚焦新基建，集中力量建设“智造重镇”和“智慧名城”。 中国电信云计算分公司副总经理李云庄示意，新基建时代，中国电信将继续深入“5G+天翼云+AI”策略，提供网、云、数、智的一体化解决方案，在云网交融基础设施之上，打造天翼云大数据平台和AI开放平台，为企业降本增效，创始更多商业新模式。（中国电信云计算分公司副总经理李云庄） 同时，中国电信重庆分公司副总经理甘雨示意，中国电信将踊跃推动5G建设、云网交融，长期全力撑持经济社会数字化转型，踊跃构建凋谢、共赢的单干生态，为垂直行业赋能注智，同时建设行业BG，倒退"云终端"，全方位助推新动能发展壮大。（中国电信重庆分公司副总经理甘雨） “天翼云管+”，开启全新贴身云管家时代针对此次公布的“天翼云管+”，重庆电信云计算事业部市场总监于敉进行了深刻解读，数字化转型浪潮以后，客户面对诸多难题，从IT零碎架构迁徙产生的技术纳闷，到内部人员对于混合多云治理产生的运维问题以及零碎一直迭代的优化需要等都制约着企业数字化转型之路。 “天翼云管+”围绕征询、集成、治理、优化四大服务，为客户提供属地化、全生命周期上云服务。在征询层面，“天翼云管+”为企业提供云战略规划、零碎上云的评估、企业云架构设计、上云、运维的布局、云平安、培训等全周期的服务。在集成层面，提供混合多云治理平台，敌对适配支流私有云、公有云厂商，快捷连贯寰球、全国、全市各地数据中心。在治理层面，利用简略、强壮、弹性、智能的云治理平台和高效的属地化服务，让客户体验更为简洁的云管理模式。在优化层面，动静评估客户云上零碎架构、网络架构、平安架构可用性，提出优化倡议，帮忙客户零碎高效适配业务变动。四大服务，从新定义上云体验，为企业上云继续减速，助力企业胜利数字化转型。 智慧城市的凋敝倒退，离不开企业的数字化和信息化。中国电信云计算分公司产品治理专家李培源在会上讲到，天翼云将持续利用以资源能力、技术能力、利用能力、生态能力为外围，以信息安全及专属服务两大体系作为“护城河”的“4+2”能力体系，全力打造平安可信的云服务，赋能千行百业数字化转型。目前，天翼云曾经为智慧社区、公共安全、游戏互娱、智慧港口等泛滥行业企业数字化转型提供安全可靠、专享定制的云服务。 天翼云携手行业合作伙伴，构建天翼云利用生态天翼云在高度重视自主翻新的同时，也同样高度重视生态单干。天翼云将秉持凋谢单干的心态，与合作伙伴携手，赋能用户转型，引领行业共进。华为中国区运营商Marketing部张利指出，5G+云网是产业数字化降级的基石，华为将打造5G+云网端管边云一体化解决方案，提供端到端SLA保障，使能产业数字化降级。 本次大会，ZStack创始人及CEO张鑫提到，ZStack致力于联手硬件厂商造成软硬件一体的解决方案，依靠天翼云弱小的集成与服务能力，为客户提供端到端的服务。将来也将在云+网的趋势下，推动天翼云与合作伙伴更宽泛的市场利用。 作为5G与人工智能、大数据、物联网等新技术深度交融的产物，包含视频医疗、远程教学、近程管制等在内的实时视频通信迎来广泛应用，北京及时会总经理李晓勇对视频云通信倒退，提出“实力+办法+翻新”的策略。近年，国家重点推动“雪亮工程”、“智慧城市”、“安全城市”等我的项目建设，放慢了视频监控云化、网络化、智能化的过程。天翼云同样利用各方劣势独特建设数据联动、部门协同、天地一体的平面视频监控利用模式，全面翻新布局视频云通信零碎。 将来，在以“新策略、新动力、新格局”为基调的新基建大势下，天翼云将不断加强云网交融能力，打造基于云网交融的数字化平台和凋谢的生态，晋升专项定制服务能力，最终实现一体化云网基础设施、一体化云网产品和一体化云网经营体系，推动全社会的数字化转型。

回顾在《Alluxio-源码解析-上》次要讲述了Alluxio本地环境搭建，源码我的项目构造，服务过程的启动流程和服务间RPC调用。 本篇将在上篇的根底上，持续为大家讲述Alluxio中重点类详解，Alluxio中Block底层读写流程，Alluxio Client调用流程和 Alluxio内置的轻量级调度框架。 Part 1 重点类讲述1.1 JournaledJournaled接口定义可被Journaled长久化保护的通用办法，通过JournalEntryIterable#getJournalEntryIterator获取Journal元素遍历信息，该接口提供默认checkpoint办法。Journaled接口继承Checkpointed、JournalEntryIterable，定义的办法包含： getJournalEntryIterator：获取Journal所有元素；getCheckpointName：获取checkpoint class类名称；writeToCheckpoint：长久化写入所有状态的checkpoint；restoreFromCheckpoint：checkpoint复原；processJournalEntry：解决指定的Journal元素，Journal解决外围办法；resetState：重置Journal状态；applyAndJournal：对Journal元素执行和利用Journal操作。 1.2 UnderFileSystemAlluxio治理和适配数据在底层各个存储系统执行操作，实现UnderFileSystem接口的底层存储能够作为Alluxio的非法UFS。 1.2.1. 类图 UnderFileSystem的类图如下所示，次要由抽象类BaseUnderFileSystem实现，而BaseUnderFileSystem下次要分为两大类： ConsistentUnderFileSystem：具备一致性的UFS实现，次要包含：LocalUnderFileSystem、HdfsUnderFileSystem、CephFSUnderFileSystem等；ObjectUnderFileSystem：对象存储UFS实现，次要包含：S3AUnderFileSystem、COSUnderFileSystem、OSSUnderFileSystem等。 1.2.2. 接口办法 在UnderFileSystem中有两类接口API： 存储系统通用操作，如：创立/删除文件，文件重命名；解决数据长久化最终一致性的操作(eventual consistency)，如：解决当AlluxioMaster保护元数据胜利时，但执行UFS操作失败的问题。1.2.2.1. 存储系统操作 create：指定path门路，在UFS中创立数据文件(父目录不存在会主动创立)，可通过CreateOptions设置创立文件的用户组和ACL策略；deleteDirectory：删除指定目录，可通过DeleteOptions设置删除的策略和遍历形式；deleteFile：删除指定文件；getDirectoryStatus：获取UFS指定目录状态，需传入已存在的目录文件；getFileStatus：获取UFS指定文件状态；getStatus：获取UFS状态，可指定目录或文件；isDirectory：判断指定门路在UFS是否是目录；open：关上UFS上指定文件，可通过OpenOptions设置文件关上参数；renameDirectory：UFS上指定目录重命名；renameFile：UFS上指定文件重命名；exists：判断指定的文件或目录是否存在；getAclPair：获取UFS的ACL策略；getBlockSizeByte：获取指定目录下UFS的每个Block文件大小，单位bytes；getFileLocations：获取指定门路在UFS关联的存储Location列表；getFingerprint：计算并获取指定门路的文件标识(指纹)，文件标识(指纹)的计算必须是确定且不可变的；getOperationMode：获取底层UFS的操作模式，Alluxio的底层存储能够由多种类型UFS组成，该办法用来确定底层UFS的操作模式，例子：底层UFS为：hdfs://ns1/,hdfs://ns2/，则返回后果：{hdfs://ns1/:NO_ACCESS,hdfs://ns2/:READ_WRITE}；getPhysicalStores：获取所有UFS类型，包含数据结构和对应权限getSpace：通过制订SpaceType获取UFS中指定门路的存储空间信息，SpaceType包含：SPACE_TOTAL、SPACE_FREE、SPACE_USED；getUnderFSType：获取UFS类型，如hdfs；isFile：判断文件文件在UFS是否存在；isObjectStorage：判断UFS是否是对象存储；isSeekable：判断UFS是否反对搜寻；listStatus：指定UFS门路下的文件状态列表，该列表不保障程序，可通过ListOptions设置是否反对遍历；mkdirs：在UFS上创立指定目录，可通过MkdirsOptions设置目录创立规定，如ACL和递归父目录创立；setAclEntries：指定门路，设置UFS的ALC策略汇合；setMode：指定门路，设置UFS ALC Mode，如0777；setOwner：指定门路，设置UFS ALC的user和group；supportsFlush：判断UFS是否反对文件Flush；supportsActiveSync：判断UFS是否反对ActiveSync(拜访外部文件共享)，ActiveSync相干的接口包含：getActiveSyncInfo、startSync、stopSync、startActiveSyncPolling、stopActiveSyncPolling。1.2.2.2. 最终一致性操作 createNonexistingFile：创立不存在的文件，若文件存在，则退出；deleteExistingDirectory：删除指定目录；deleteExistingFile：删除指定文件；getExistingDirectoryStatus：获取UFS指定目录状态；getExistingFileStatus：获取UFS指定文件状态；getExistingStatus：获取UFS状态，可指定目录或文件；isExistingDirectory：判断指定门路在UFS是否是目录；openExistingFile：关上UFS上指定文件，可通过OpenOptions设置文件关上参数；renameRenamableDirectory：UFS上指定目录重命名；renameRenamableFile：UFS上指定文件重命名。1.2.2.3. 其余操作 cleanup：当数据文件创建时没有失常的胜利完结或被摈弃解决，则对底层UFS清理；connectFromMaster：指定AlluxioMaster主机地址，建设指定Master与UFS连贯；connectFromWorker：指定AlluxioWorker主机地址，建设指定Worker与UFS连贯；resolveUri：给定Alluxio根底URI和门路，返回拼装后的Alluxio门路。1.3 UfsManagerAlluxio中对底层UFS(Under FileSystem)治理操作的通用对立接口类定义，定义的接口办法包含： addMount：UFS挂载到Alluxio，该办法仅针对Alluxio解决，不对底层UFS操作；removeMount：移除Alluxio中的UFS挂载；get：依据mountId获取挂载的UFS信息；getRoot：获取Alluxio上挂载的根目录信息；getJournal：获取Journal的Location地址；其中AbstractUfsManager抽象类对UFS治理接口进行根本实现。 1.3.1. UfsClient 保护底层UFS的Client连贯信息和其余相干UFS的形容信息，基于UfsClient实现Alluxio对UnderFileSystem的操作。 1.4 BlockClientBlockClient抽象类定义调用方对Block根本的读写操作，其类图示意如下，次要包含：BlockWriter、BlockReader。 读写Block的定义的办法类： 1.5 DefaultFileSystemMasterMaster服务保护所有FileSystem(文件系统)元数据变更的治理操作，DefaultFileSystemMaster外部基于InodeTree保护文件系统构造，并将InodeTree长久化到日志文件(journal)；除此之外，其外部保护多个治理操作，如：InodeLockManager、MasterUfsManager、MountTable等；备注：DefaultFil1.5. DefaultFileSystemMastereSystemMaster的启动start办法详情后面所述内容。 1.5.1. 接口办法 FileSystemMaster接口定义master中针对FS的操作方法，DefaultFileSystemMaster继承FileSystemMaster，其接口办法次要包含： cleanupUfs：周期性清理底层UFS；getFileId：基于Alluxio门路URI 获取文件ID，若文件不缓存Alluxio，则调用UFS获取；getFileInfo：依据文件ID获取文件详情，该接口仅对外部服务凋谢，不对用户间接凋谢；getPersistenceState：依据文件ID，获取该文件的长久化状态；listStatus：指定Alluxio门路，获取文件状态列表；checkAccess：校验指定Alluxio门路的权限；checkConsistency：校验指定Alluxio门路的文件数据一致性；completeFile：敞开/完结指定Alluxio门路，敞开后，则该文件不可写；createFile：基于指定Alluxio文件门路，创立文件FileInfo；getNewBlockIdForFile：指定Alluxio文件门路，获取下个待操作Block文件的Block ID；getMountPointInfoSummary：获取Alluxio中mount(挂载)门路的快照信息；getDisplayMountPointInfo：获取Alluxio用户展现的Mount信息；delete：删除指定Alluxio门路的文件元信息；getFileBlockInfoList：获取指定Alluxio门路下的所有Block列表信息；getInAlluxioFiles：获取Alluxio中所有的文件列表门路；getInMemoryFiles：获取Alluxio中所有缓存在内存的文件列表门路；createDirectory：创立Alluxio对应的目录，并返回目录ID；rename：Alluxio中文件重命名操作的元数据变更；free：指定Alluxio目录下，开释所有alluxio缓存的block文件信息，反对目录下遍历的文件开释；getPath：依据指定FileId获取Alluxio URI门路；getPinIdList：获取被固定的inode id列表；getUfsAddress：获取master所需的UFS地址；getUfsInfo：依据挂载ID获取对应UFS信息；getLostFiles：获取worker节点失落的文件列表；mount：外围操作，将UFS门路挂载在Alluxio指定门路；unmount：勾销指定Alluxio门路上的UFS挂载；updateMount：更新指定Alluxio门路挂载信息；setAcl：设置Alluxio门路ACL；updateUfsMode：设置底层UFS Mode；validateInodeBlocks：验证inode block信息是否具备完整性；workerHeartbeat：指定worker ID，告诉对应worker进行文件的存储长久化；getWorkerInfoList：获取所有worker节点信息列表；getTimeSeries：获取alluxio master中元数据存储的工夫版本信息；1.6 DefaultBlockWorker1.6.1. 接口 Worker Server针对Block的治理操作，实现接口类：BlockWorker，其接口办法次要包含： getWorkerId：获取worker id；abortBlock：抛弃session中长期创立的block文件；accessBlock：拜访指定session和block id下的block信息，该办法可能会在block缓存开释被拜访；commitBlock：提交block到Alluxio的治理空间，待提交的block必须是长期的，当block提交胜利之前，block是不反对读写访问；commitBlockInUfs：将block提交到UFS长久化；createBlock：在Alluxio治理空间创立block，基于BlockWriter类可对block进行写操作，在block commit提交之前都是长期的；getTempBlockMeta：获取长期block元数据；createBlockWriter：基于session和block id创立BlockWriter，用于block的写操作；getReport：获取worker与master周期性心跳的报告；getStoreMeta：获取整个block存储的元数据信息，包含block中每个存储目录映射和每层存储的容量状况；getStoreMetaFull：与getStoreMeta类似，但包含残缺的blockId列表，获取代价更高；getVolatileBlockMeta：依据指定blockId获取block元数据信息；lockBlock：对block进行加锁操作；moveBlock：将block从以后存储Location挪动到指标Location；以后仅反对分层存储挪动；moveBlockToMedium：block挪动并指定对应的存储介质类型(MediumType)；createBlockReader：创立BlockReader进行Block读操作，可读取Alluxio Block和 UFS Block；createUfsBlockReader：创立BlockReader进行UFS Block读操作；removeBlock：从Allxuio治理空间移除Block；requestSpace：为指定block获取存储空间，该block必须为长期block；unlockBlock：对block去除锁操作；asyncCache：提交异步缓存申请进行异步的缓存治理；updatePinList：更新底层block存储占用的pin列表；getFileInfo：基于指定file id获取文件信息。1.6.2. TieredBlockStore ...

Part 1 前言目前数据湖已成为大数据畛域的最新热门话题之一，而什么是数据湖，每家数据平台和云厂商都有本人的解读。整体来看，数据湖次要的能力劣势是：集中式存储原始的、海量的、多起源的、多类型的数据，反对数据的疾速加工及计算。相比于传统的数据仓库，数据湖对数据有更大的包容性，反对结构化/半结构化/非结构化数据，能疾速进行数据的落地和数据价值挖掘。数据湖的技术体系能够分为三个子畛域：数据湖存储、数据湖计算、数据湖对立元数据。 数据湖存储提供海量异构数据的存储能力，反对多类型的底层存储系统，如分布式存储 HDFS、对象存储 AWS S3、腾讯云对象存储 COS 等，除此之外，在数据湖场景中计算和存储拆散，使得计算的数据本地性不复存在。因而有必要在数据湖存储和计算之间引入对立的数据缓存层。 Alluxio是一款基于云原生开源的数据编排技术，为数据计算与数据存储构建了桥梁，反对将数据从原始存储层挪动到减速计算的虚构分布式存储系统。Alluxio可为数据湖计算提供对立的数据湖存储拜访入口，反对跨不同类型的底层存储并形象出对立的数据拜访命名空间，提供数据本地性、数据可拜访性、数据伸缩性。 本文将对 Alluxio 底层源码进行简要剖析，分高低两篇：次要包含本地环境搭建，源码我的项目构造，服务过程的启动流程，服务间RPC调用，Alluxio 中重点类详解，Alluxio 中 Block 底层读写流程，Alluxio Client调用流程和 Alluxio 内置的轻量级调度框架。 Part 2 环境筹备2.1 本地部署从官网下载安装版本(下载地址)，以2.6.0装置为例，下载后解压安装包：1 tar -zxvf alluxio-2.6.0-bin.tar.gz批改根本的配置文件，(1). 批改alluxio-site.properties，设置master地址，设置默认Alluxio root挂载点：1 cp conf/alluxio-site.properties.template alluxio-site.properties2 #放开正文：3 alluxio.master.hostname=127.0.0.14 alluxio.master.mount.table.root.ufs=${alluxio.work.dir}/underFSStorage (2). 批改masters、workers配置对应ip，本地装置，可都设置为127.0.0.11 vi conf/masters2 vi conf/workers批改完配置后，筹备启动Alluxio服务，执行如下命令操作：1 # mount对应磁盘2 bin/alluxio-mount.sh Mount workers3 # 进行环境校验4 bin/alluxio validateEnv master5 bin/alluxio validateEnv worker 服务启动命令操作，对于所有服务操作包含：master、worker、job_master、job_worker、proxy1 # 启动所有服务2 bin/alluxio-start.sh all3 # 进行所有服务4 bin/alluxio-stop.sh all56 # 启动单个服务7 bin/alluxio-start.sh -a master8 bin/alluxio-start.sh -a worker9 bin/alluxio-start.sh -a job_master10 bin/alluxio-start.sh -a job_worker11 bin/alluxio-start.sh -a proxy ...

本篇文章为数禾科技数据开发专家杨涵冰的演讲内容整顿。次要内容包含： 特色平台概览特色存储服务流批一体计划模型策略调用计划点击查看更多技术内容 一、特色平台概览 首先是特色平台的概览，整个特色平台分成四层，别离是数据服务、存储服务、计算引擎、原始存储。数据服务层提供向外的服务，次要包含四种： 一是传统的 API 点查；二是圈选查问；三是事件音讯；四是同步调用计算。其中同步调用计算服务是即时计算的，相当于现场进行策略运算，而 API 点查服务是事后计算并存储的。为了提供数据服务，提供特色行存和特色列存两种服务形式，别离撑持 API 点查和圈选查问。计算引擎有两个，别离是离线运算引擎和流批一体运算引擎。特色平台的最底层是原始存储，原始存储是为了反对离线运算性能，而事件存储是为了反对流批一体运算。 上面以 MySQL 为例介绍简化的特色平台数据流转过程。 首先是离线局部，通过 Sqoop 或者其余的抽取工具将 MySQL 数库的数据抽取到 EMR，而后通过 Hive 运算，把最终的运算后果存到 HBase 和 ClickHouse 中，别离对应特色行存和特色列存，以提供 API 点查和圈选查问服务。同时 MySQL 的 Binlog 会实时写入 Kafka，而后 Kafka 的数据会被生产进入 Flink 流批一体运算引擎，同时Kafka的数据也会被生产进入到事件存储 HBase，事件存储 HBase 的数据也会提供给Flink流批一体运算引擎。通过引擎计算当前，数据被写入 HBase 和 ClickHouse 中，此外还会发事件音讯。直达到事件存储 HBase 的数据能够提供实时调用服务。 二、特色存储服务接下来介绍特色存储服务。 咱们将特色分为四类，别离是： 同步特色：实时写入、离线修改、流批一体。即时计算特色：API 调用时运算、线下批量计算，逻辑统一。实时特色：传统实时链路，实现简单实时逻辑，个别可应用流批一体代替。离线特色：传统离线链路，实现简单离线逻辑。为什么肯定要有离线的链路，起因有以下几点： 一是实时链路是一个纯增量的链路，它的链路会很长，并且在任意的环节都有可能产生问题，一旦出错，数据将会在很长的一段时间都无奈被主动修改。 二是实时链路对时效性有要求，特地是波及到多流 join 的时候，一旦有提早，须要尽快返回一个降级后果。为了管制实时特色的最终错误率，并且将谬误限度在一个较小的时间段内，须要进行离线链路修改。特色存储服务会用两种形式来进行修改，一种就是同步特色，其自身自带修改，是流批一体的链路；其余特色个别是通过实时+离线+即时计算的组合形式。 上面以 MySQL 为例，介绍下存储服务的整体数据流。离线局部，通过 Sqoop 抽取工具将 MySQL 数库的数据抽取到 EMR，而后通过 Hive 运算，把最终的运算后果存到 HBase 和 ClickHouse 中。同时 Binlog 会实时写入 Kafka，而后 Kafka 的数据会被生产进入 Flink 流批一体运算引擎，通过引擎计算当前，数据被写入 HBase 和 ClickHouse 中。HBase 和 ClickHouse 提供 API 点查和圈选查问服务。 ...

摘要：本文为 RocketMQ Flink Catalog 使用指南。次要内容包含： Flink 和 Flink CatalogRocketMQ Flink ConnectorRocketMQ Flink Catalog作者：李晓双 ，Apache RocketMQ Contributor Mentor：蒋晓峰，Apache RocketMQ Committer 一、Flink 和 Flink CatalogFlink 是一个分布式计算引擎，目前曾经实现批流一体，能够实现对有界数据和无界数据的解决。须要无效调配和治理计算资源能力执行流式应用程序。 目前 Flink API 共形象为四个局部： 最顶层的形象为 SQL。SQL 形象与 Table API 形象之间的关联是十分严密的，并且 SQL 查问语句能够在 Table API 中定义的表上执行。第二层形象为 Table API。Table API 是以表（Table）为核心的申明式编程（DSL）API，例如在流式数据场景下，它能够示意一张正在动静扭转的表。第三层形象是 Core APIs 。 许多程序可能应用不到最底层的 API ， 而是能够应用 Core APIs 进行编程：其中蕴含 DataStream API（利用于有界/无界数据流场景）和 DataSet API（利用于有界数据集场景）两局部。第四层形象为有状态的实时流解决。 Flink Catalog 提供了元数据信息，例如数据库、表、分区、视图以及数据库或其余内部零碎中存储的函数和信息。Flink 对于元数据的治理分为长期的、长久化的两种。内置的 GenericInMemoryCatalog 是基于内存实现的 Catalog，所有元数据只在 session 的生命周期内可用。JdbcCatalog 和 HiveCatalog 就是能够长久化元数据的 Catalog。 Flink Catalog 是扩大的，反对用户自定义。为了在 Flink SQL 中应用自定义 Catalog，用户须要通过实现CatalogFactory接口来实现对应的 Catalog 工厂。该工厂是应用 Java 的服务提供者接口 (SPI) 发现的。能够将实现此接口的类增加到 META_INF/services/org.apache.flink.table.factories.FactoryJAR 文件中。 ...

报名地址：https://www.bagevent.com/even... 2022年，世界正在扭转，开源发明价值。曾经办到第七届的开源年会首次来到杭州与开发者们相聚。你眼中的开源是怎么的？对于开源你有没有想要讲述的？ 「开源」对于很多人而言，其存在的意义早就不止在于源代码的凋谢会集，更在于一直退出的开发者们独特合作，生生不息。 因而，咱们想要在一个特定的工夫内，和大家相聚在一起，连贯乏味的开发者们，和大家聊点掏心窝的，玩点不一样的。 ✦ ✦✦ ✦✦ ✦✦ ✦ 2022年10月29日，来 COSCon'22 杭州线下团聚，新老朋友欢聚一堂，让咱们用趣味形式理解开源，摸索开源。 COSCon‘22杭州分会场将于10月29日13:00-18:00，在杭州市余杭区鼎创财产核心B2座2层举办。（地铁良睦路C口进去步行400米） ✦ ✦ ✦ ✦ ✦ ✦ ✦ ✦ Here’s nothing but HAPPY！！！ COSCon'22 杭州线下团聚四大特色流动 开源分享会等了良久终于等到明天，梦了良久终于把梦实现～开源年会首次来到杭州，当然要邀请重量级开源嘉宾来炸炸场、过过招。 来自阿里、华为、袋鼠云的技术领军者们都来了，你还不来吗？ 那么，咱们会聊些什么呢？ @贺小令，阿里高级技术专家、Apache Flink Committer，长期从事Flink的研发工作，目前是Flink SQL引擎优化方向负责人，搬好小板凳，听他讲讲Flink将来的方向。 @林国辉，华为云边缘计算技术专家，CNCF KubeEdge我的项目SIG - Security负责人，也是一枚云原生、边缘计算技术爱好者，和你侃侃在云原生边缘计算场景下如何实现无效的平安防护。 @吴繁荣，openEuler sig-high-performance-network maintainer，别被这么长的title吓到了，想理解「用户态协定栈」，听他就对了。 @赵章万，Taier我的项目负责人，同时也是袋鼠云资深技术专家，陪伴袋鼠云开源成长的最强见证者，听他聊聊袋鼠云开源框架那点事。 开源凋谢麦“夜太美，只管再心累，总有人敲着代码红着眼。” “那天有人向我借钱，我说借多少，他说一千，我说再借你24块吧，凑个整。” “我始终深信，在开源这条路上，没有什么迈不过来的坎，不信你们看看我，我变秃了，也变强了。” 捡起麦克风，咱们是最会说段子的开发者，扛起键盘，又变身最会写代码的凋谢麦演员。 不论是乏味的我的项目介绍，还是开源路上的喜怒哀乐。任何故事，任何情绪，Open Mic的麦克风属于你，把日子过成段子，让大家看看码农能够有多野～ 开源集市玲琅满目标货物，熙熙攘攘的人群，形成了专属于中国人的“集市记忆”。这一次，咱们把集市搬到了开源年会现场，由开发者和开源我的项目独特组成的微妙市集，将向所有人凋谢。 在这个非凡的集市上，ChunJun、FinRL、Gazelle、NebulaGraph、NEAR、sysmaster、StoneDB、Taier……每个开源我的项目都有固定的展台，向各位“赶集”的敌人展现本人的开源我的项目，交换前沿趋势，碰撞开源火花，一起来赶集吧！ 同时每个展台还提供了丰盛礼品，玩游戏即可获取哦，只有你来肯定让你盆满钵满～ 开源集市上的每一个我的项目都有属于本人的独特亮点，欢送你前来开掘： ChunJun我的项目地址： https://github.com/DTStack/ch... ChunJun是一个易用、稳固、高效的批流对立的数据集成框架，既能够采集动态的数据，比方MySQL，HDFS等，也能够采集实时变动的数据，比方binlog，Kafka等。同时ChunJun也是一个反对原生FlinkSql所有语法和个性的计算框架。 ChunJun次要利用于大数据开发平台的数据同步/数据集成模块，通常采纳将底层高效的同步插件和界面化的配置形式相结合的形式，使大数据开发人员可简洁、疾速的实现数据同步工作开发，实现将业务数据库的数据同步至大数据存储平台，从而进行数据建模开发，以及数据开发实现后，将大数据处理好的后果数据同步至业务的利用数据库，供企业数据业务应用。 FinRL我的项目地址： https://github.com/AI4Finance... FinRL 是第一个Financial Reinforecment Learning开源框架，旨在帮忙从业者建设基于深度强化学习 (DRL) 的交易策略。FinRL 曾经倒退成为一个生态系统，包含数百个金融市场、最先进的算法、金融应用程序（投资组合调配、加密货币交易、高频交易）、实时交易、云部署等。 ...

本文首发于微信公众号“Shopee技术团队”摘要Apache Hudi 是业内基于 Lakehouse 解决方案中的典型组件，相比于传统基于 HDFS 和 Hive 的数据仓库架构，基于 Apache Hudi 的 Lakehouse 解决方案有泛滥劣势，例如：低提早的数据刷新，高度的数据新鲜度；小文件自动化治理；反对数据文件的多版本读写；与大数据生态内 Hive/Spark/Presto 等引擎的无缝连接。基于这些个性，咱们开始尝试对以后次要基于 Hive 的数仓架构进行降级革新。 本文将重点介绍 Shopee Marketplace 业务应用 Flink + Hudi 构建实时数据仓库的解决方案、实际案例以及下一步布局。 1. 背景介绍1.1 现状在 Shopee 外部，Data Infra 团队曾经反对了数据入湖到 Hudi 的过程，提供了大量具备较高实时性和稳定性的数据源。咱们 Marketplace Data Engineering 团队也基于这些 Hudi 表构建了订单、商品和用户的小时数据 Pipeline，这些小时数据不仅在大促期间为业务人员提供数据反对，也被用于日常的风控业务中。 以后，咱们采纳了相似于 mini batch 的思维，每小时对最近 3 小时的数据进行计算和刷新，在保证数据及时更新的状况下，解决数据提早、JOIN 工夫不对齐等问题。但随着数据量的迅速增长，小时级数据 SLA 的保障难度和计算资源的耗费都在一直减少。咱们开始摸索晋升数据产出及时性并缩小资源耗费的解决方案。 1.2 痛点剖析通过对小时工作的架构进行梳理和剖析之后，咱们发现： 在小时表不同小时的批计算中存在较多的反复计算，因为一些未变更的记录也参加了计算；存在较多的大表全量 JOIN 操作，比方通过商品次要信息表关联商品价格表和商品库存表；读取的 Hudi 表数据时延从几分钟到几十分钟不等，大表的提早较高。可通过防止不必要的反复计算，用增量数据 JOIN 代替大表全量 JOIN，以及采纳及时性更好的数据源的形式来缓解或者解决以后的痛点。通过相干的技术调研之后，咱们拟定了以应用 Flink + Hudi 为外围的技术计划，通过实时计算和数据湖存储构建实时数据仓库。 1.3 典型实时计算利用与实时数仓的差别在介绍具体计划介绍，咱们先比照典型实时计算利用和实时数仓，以理解和辨别他们的不同点和侧重点。 其中，典型实时计算利用包含： 1）事件驱动型利用定义：它从一个或多个事件流提取数据，并依据事件触发计算、状态更新或其余内部动作。特点：偏重对输出 Event 的业务逻辑解决，会下发新 Event 给其余利用。案例：应用 CEP（Complex Event Processing）进行实时反欺诈。2）数据分析利用定义：对输出数据流进行实时剖析型计算，并将实时更新的后果数据写入内部存储系统，而后基于后果数据提供数据服务。特点：罕用于计算聚合类指标，用以满足特定的需要；可实现几个关联数据流的繁难复合指标计算；计算结果大多输入到外存零碎；多流场景下的计算结果不肯定完全正确，或者要失去最终完全正确的后果老本会极高。案例：实时数据统计监控。3）数据管道利用定义：实时转换、丰盛数据，并将其从某个存储系统挪动到另一个存储系统中。特点：从一个一直生成数据的源头读取记录，并将它们以低提早挪动到起点。案例：实时数据入湖。实时数仓可了解为将经典离线数仓实时化，给用户提供与离线数仓类似的数据应用体验，包含但不限于表的 schema，数据查问形式等。为了达到这一指标，实时数仓需满足以下要求： ...

作者： 李欣 诺亚财产数据总监， 卢帅  诺亚财产高级数据开发 客户简介诺亚控股有限公司以“诺亚财产”为品牌，源起于中国，是首家在港美两地上市的中国独立财产管理机构，首家创始了财产治理和资产治理的双轮驱动业务模式，同时也是国内首家取得规范普尔“投资级”评级的财产治理公司，公司业务涵盖财产治理、资产治理和其余业务。诺亚数据智能部门负责公司大数据体系框架建设，次要工作是撑持日常的BI剖析，数据看板，人群画像，自助剖析等场景。 在公司数字化转型的背景下，业务增长带来了数据量的激增，不同的数据需要衍生出各种数据服务，不同的数据服务抉择不同的数据库和数仓技术，比方MySQL，Impala, Greenplum，ElasticSearch等。为了最大化的升高运维老本，提供高性能的数据服务，做到真正的极速对立，从2021年上半年开始，诺亚数据智能部门开始上云，将自建CDH替换成阿里云对立大数据平台，同时正式引入Hologres，替换外围的Impala OLAP剖析局部，晋升数据查问效率，全面打造金融数字化剖析平台。因而在本文中，咱们将会具体介绍诺亚从CDH迁徙阿里云大数据平台的前因后果，以帮忙更多的业务更加方便快捷的建设实时数仓。 业务挑战：自建CDH组件多运维难、交易指标多元查问慢为了反对业务，诺亚原大数据架构采纳Impala和CDH构架构建，架构图如下： 在最后的架构中，咱们从Cloudera购买了License 基于CDH 搭建了一套数据服务平台：上游的源数据库次要是 MySQL，Oracle，Mongo等 ，业务相干的数据和局部日志数据都记录在外面。咱们通过 DataX 和 Sqoop 将数据库中的数据导入到 HDFS，通过 Hive的元数据映射生成 Schema，并接入 Impala 实现数据的即席查问。数据仓库的分层和建模全副都在 Hive 中实现，借助 LDAP 和 Sentry 进行用户权限治理，分析师在HUE中进行查问。 对于实时指标，咱们通过Debezium 采集 MySQL 的 Binlog 日志，解析到Flink中对数据进行解决建模，并关联Kafka中的埋点日志数据，生成实时指标写入到 MySQL 中。该流程实用于大部分的报表需要，然而因为 MySQL 对于OLAP 的工作执行效率较低，在单日报表超过50万记录的状况下，一些多维分析后果可能须要8+秒以上能力返回，十分影响报表查看体验。同时咱们也提供了相应的数据服务，分析师通过 JDBC 的连贯形式对数仓数据进行查问，数仓数据通过数据API间接利用于一线业务，相应的 BI 报表展现也基于 Impala 计算实现。 随着业务的增长，此架构面临如下挑战： 1、业务方面： 数据分析性能有余：因为咱们的用户可能多年的存量和交易指标特地多，数据须要简单关联查问能力失去数据指标，还有高并发查问工夫周期比拟长的数据，返回工夫太长，业务方体验很差。实时剖析场景有余：历史的数据架构导致数据提早频繁，无奈满足业务方及时做出决策。查问引擎不对立 ：零碎可能有多种查问引擎组成，每一种查问引擎都有本人的DSL，减少了用户的学习老本，同时须要跨多数据源查问也是一种不不便的的事，异构查问引擎也容易造成数据孤岛。用数据难 ：因为数据分布在各个系统中，用户无奈在一个零碎满足所有的数据需要。特地是一线的经营和剖析同学，须要通过各个系统导出大量的excel表格的形式做数据分析，费时费力，同时也存在肯定的数据隐患。2、技术方面： 应用的组件过多：实现不同的需要须要不同的组件，例如批处理采纳的Hive , 即席查问应用的Greenplum和 Impala ，这对于数仓外部的治理提出了较高的要求，对于分析师和报表同学不够敌对。运维难度大：CDH 尽管是商业软件平台，提供了界面化操作，然而大多数组件仍然须要本人去摸索保护，并且官网文档重大缺失。因为CDH曾经不在中国市场提供更新，裸露进去的破绽也越来越多，并且将来的不确定性也在减少，不足稳定性。大数据量查问较慢：咱们应用Impala进行减速查问，然而数据文件没有无效的索引，对于数据量的扫描过大的查问，有时候须要几十秒能力返回后果。并且本身的SQL优化器比拟毛糙，SQL略微写的不够标准，就会产生不必要的资源开销，导致查询卡死。Impala的本身的缺点：在表数据或者表构造更新的状况下，须要手动的刷新元数据能力查问到最新的数据，极其不不便。老本高：业务倒退快，产生数据疾速收缩，Impala的线性扩容老本比拟高。技术选项多维比照为了解决下面的痛点，咱们想要对架构进行降级，在寻求解决方案的过程中，OLAP剖析是咱们十分看重的一个局部，因而咱们依据业务需要评估了四个维度： 性能HologresStarrocksClickhouse规范SQL反对反对，兼容Mysql协定不齐全反对高并发查问端到端的全异步解决框架，能够防止高并发零碎的瓶颈，充分利用资源，并且最大可能地防止存储计算拆散零碎带来的读数据提早的影响。无限反对不反对高并发，官网倡议QPS 为 100运维欠缺的dashboard,包含查问日志，慢SQL等都能够查问社区版不提供dashboard，须要本人实现自动化部署依赖zookeeper，运维老本高性能Hologres反对行存储、列存储和行列共存多种存储模式, 能够依据业务场景抉择适合的存储类型大宽表和多表join性能比ck更好单机性能强悍，然而单表查问效率快。社区（技术支持）响应工夫较快，版本迭代快。较快较慢，社区活跃度较低解决方案：自建CDH迁徙上云，Hologres助力对立OLAP剖析通过4个维度的充分考虑和论证，咱们决定将自建CDH迁徙成阿里云大数据平台。迁徙后诺亚基于阿里云大数据平台架构图如下： 诺亚数据智能核心在2021年进行了上云的打算，全面实现数据中台的云原生，摈弃掉原来的CDH那套数据架构，咱们花了一年的工夫进行了整个数据中台的革新和迁徙，原来的数仓基于impala的表大略有1w+ 张，烟囱式开发，老架构的数仓是DL层 + DH 层，没有对于数据进行分层和积淀 ，导致数据冗余重大，工作之间相互依赖重大，没有很好的进行对于业务模块的划分。 ...

作者： 李欣 诺亚财产数据总监， 卢帅  诺亚财产高级数据开发 客户简介诺亚控股有限公司以“诺亚财产”为品牌，源起于中国，是首家在港美两地上市的中国独立财产管理机构，首家创始了财产治理和资产治理的双轮驱动业务模式，同时也是国内首家取得规范普尔“投资级”评级的财产治理公司，公司业务涵盖财产治理、资产治理和其余业务。诺亚数据智能部门负责公司大数据体系框架建设，次要工作是撑持日常的BI剖析，数据看板，人群画像，自助剖析等场景。 在公司数字化转型的背景下，业务增长带来了数据量的激增，不同的数据需要衍生出各种数据服务，不同的数据服务抉择不同的数据库和数仓技术，比方MySQL，Impala, Greenplum，ElasticSearch等。为了最大化的升高运维老本，提供高性能的数据服务，做到真正的极速对立，从2021年上半年开始，诺亚数据智能部门开始上云，将自建CDH替换成阿里云对立大数据平台，同时正式引入Hologres，替换外围的Impala OLAP剖析局部，晋升数据查问效率，全面打造金融数字化剖析平台。因而在本文中，咱们将会具体介绍诺亚从CDH迁徙阿里云大数据平台的前因后果，以帮忙更多的业务更加方便快捷的建设实时数仓。 业务挑战：自建CDH组件多运维难、交易指标多元查问慢为了反对业务，诺亚原大数据架构采纳Impala和CDH构架构建，架构图如下： 在最后的架构中，咱们从Cloudera购买了License 基于CDH 搭建了一套数据服务平台：上游的源数据库次要是 MySQL，Oracle，Mongo等 ，业务相干的数据和局部日志数据都记录在外面。咱们通过 DataX 和 Sqoop 将数据库中的数据导入到 HDFS，通过 Hive的元数据映射生成 Schema，并接入 Impala 实现数据的即席查问。数据仓库的分层和建模全副都在 Hive 中实现，借助 LDAP 和 Sentry 进行用户权限治理，分析师在HUE中进行查问。 对于实时指标，咱们通过Debezium 采集 MySQL 的 Binlog 日志，解析到Flink中对数据进行解决建模，并关联Kafka中的埋点日志数据，生成实时指标写入到 MySQL 中。该流程实用于大部分的报表需要，然而因为 MySQL 对于OLAP 的工作执行效率较低，在单日报表超过50万记录的状况下，一些多维分析后果可能须要8+秒以上能力返回，十分影响报表查看体验。同时咱们也提供了相应的数据服务，分析师通过 JDBC 的连贯形式对数仓数据进行查问，数仓数据通过数据API间接利用于一线业务，相应的 BI 报表展现也基于 Impala 计算实现。 随着业务的增长，此架构面临如下挑战： 1、业务方面： 数据分析性能有余：因为咱们的用户可能多年的存量和交易指标特地多，数据须要简单关联查问能力失去数据指标，还有高并发查问工夫周期比拟长的数据，返回工夫太长，业务方体验很差。实时剖析场景有余：历史的数据架构导致数据提早频繁，无奈满足业务方及时做出决策。查问引擎不对立 ：零碎可能有多种查问引擎组成，每一种查问引擎都有本人的DSL，减少了用户的学习老本，同时须要跨多数据源查问也是一种不不便的的事，异构查问引擎也容易造成数据孤岛。用数据难 ：因为数据分布在各个系统中，用户无奈在一个零碎满足所有的数据需要。特地是一线的经营和剖析同学，须要通过各个系统导出大量的excel表格的形式做数据分析，费时费力，同时也存在肯定的数据隐患。2、技术方面： 应用的组件过多：实现不同的需要须要不同的组件，例如批处理采纳的Hive , 即席查问应用的Greenplum和 Impala ，这对于数仓外部的治理提出了较高的要求，对于分析师和报表同学不够敌对。运维难度大：CDH 尽管是商业软件平台，提供了界面化操作，然而大多数组件仍然须要本人去摸索保护，并且官网文档重大缺失。因为CDH曾经不在中国市场提供更新，裸露进去的破绽也越来越多，并且将来的不确定性也在减少，不足稳定性。大数据量查问较慢：咱们应用Impala进行减速查问，然而数据文件没有无效的索引，对于数据量的扫描过大的查问，有时候须要几十秒能力返回后果。并且本身的SQL优化器比拟毛糙，SQL略微写的不够标准，就会产生不必要的资源开销，导致查询卡死。Impala的本身的缺点：在表数据或者表构造更新的状况下，须要手动的刷新元数据能力查问到最新的数据，极其不不便。老本高：业务倒退快，产生数据疾速收缩，Impala的线性扩容老本比拟高。技术选项多维比照为了解决下面的痛点，咱们想要对架构进行降级，在寻求解决方案的过程中，OLAP剖析是咱们十分看重的一个局部，因而咱们依据业务需要评估了四个维度： 性能HologresStarrocksClickhouse规范SQL反对反对，兼容Mysql协定不齐全反对高并发查问端到端的全异步解决框架，能够防止高并发零碎的瓶颈，充分利用资源，并且最大可能地防止存储计算拆散零碎带来的读数据提早的影响。无限反对不反对高并发，官网倡议QPS 为 100运维欠缺的dashboard,包含查问日志，慢SQL等都能够查问社区版不提供dashboard，须要本人实现自动化部署依赖zookeeper，运维老本高性能Hologres反对行存储、列存储和行列共存多种存储模式, 能够依据业务场景抉择适合的存储类型大宽表和多表join性能比ck更好单机性能强悍，然而单表查问效率快。社区（技术支持）响应工夫较快，版本迭代快。较快较慢，社区活跃度较低解决方案：自建CDH迁徙上云，Hologres助力对立OLAP剖析通过4个维度的充分考虑和论证，咱们决定将自建CDH迁徙成阿里云大数据平台。迁徙后诺亚基于阿里云大数据平台架构图如下： 诺亚数据智能核心在2021年进行了上云的打算，全面实现数据中台的云原生，摈弃掉原来的CDH那套数据架构，咱们花了一年的工夫进行了整个数据中台的革新和迁徙，原来的数仓基于impala的表大略有1w+ 张，烟囱式开发，老架构的数仓是DL层 + DH 层，没有对于数据进行分层和积淀 ，导致数据冗余重大，工作之间相互依赖重大，没有很好的进行对于业务模块的划分。 ...

2022云栖大会如约而至，精彩议程提前通晓！ 11月5日云栖小镇 · A馆 · 云栖厅听20位专家解读大数据+AI一体化！Back to Basic，一体化大数据智能峰会解读阿里云保持13年深耕根底技术，逐步形成大数据+AI一体化平台。 峰会联结IDC解读大数据+AI一体化发展趋势，联结凋谢原子开源基金会公布2022开源大数据热力报告，并与10位云上客户及生态搭档一起解读一体化大数据智能为数字经济带来的新动能！ 扫描下方海报二维码即刻锁定参会名额！

迷信欠缺的数据指标体系是企业发展数字化经营治理、打造数据驱动型组织的重要撑持。透过多维度的数据指标，经营人员可能清晰理解业务现状，产品/研发人员可能高效定位系统问题，管理人员可能更加精确地做出剖析决策。 为帮忙企业破解数据指标体系建设过程中遇到的难题，进一步拓展数据化经营思路，个推TechDay“治数训练营”系列直播课第三期《数据指标体系设计与开发实战》行将上线。 10月26日（下周三）19:00-20:00，来自个推治数平台部的资深数据架构师将为您深入浅出分享数据指标体系设计的思路和办法，手把手教学，带大家跑通数据指标体系建设全流程、轻松把握数据化经营策略。产品、经营、数据开发、数据分析师，都值得一看~

一、大数据系统简介扫衰弱码了没？置信大家每天都会不厌其烦地听到这种询问。支付宝付款，置信大家也是每天都在扫码付款，这曾经成为了生存的一部分。这些能产生十分巨量数据的利用零碎，咱们称之为大数据系统。大数据系统还须要从巨量数据中进行无效数据的筛选、解决，比方对衰弱码进行赋红码、绿码等。 1、大数据系统定义比拟官网的定义：大数据(BigData)是将包含结构化、非结构化、甚至多结构化海量数据进行整合，并通过对这些数据的剖析发现其中暗藏的相干信息，进而优化业务和治理。 2、大数据系统的特色对于大数据系统个别具备数据量微小、数据类型繁多、速度快、时效短、价值密度低的特点，因而处理速度要求快、及时，这样能力体现出价值，因而大数据系统要求计算效率要高。1）数据量微小咱们日常应用的网络从3G、4G到当初的5G，网速的一直晋升，带来也是数据存储上的晋升，从最后的MB、GB到TB，乃至当初有了PB，EB等存储。咱们每天都在产生数据，咱们扫一次衰弱码、应用支付宝进行一次领取、咱们发一条知乎文章、刷一条微博评论，都在为大数据系统提供数据，而千千万万个他们也在这么做。因而，大数据系统的一个很重要的特点就是数据量微小，而且还在一直地产生新的数据，从大量的数据中，咱们能力剖析出行为、法则，乃至能预测。2）数据类型多样化大数据系统还具备一个特点就是数据的多样，他能够是文字、图片、视频、语音等等，只有是在网络上流传的数据，都能够是大数据系统能够操作的对象。明天你在朋友圈晒了一张三亚旅游的照片。今天你与密友发了肉麻的语音。你将收藏多年岛国爱情片上传的BD网盘。这些可能在你不知情的状况下，就曾经被大数据系统盯上了，你还别不信。你有没有发现，你刚和敌人磋商中午吃什么，你的今日头条可能就给你推送外卖了。你有没有发现，你刚夸了敌人买的衣服丑陋，淘宝首页就开始展现各种漂亮衣服了。3）传输快、时效短对于大数据系统来说，数据多、类型繁冗，原本解决起来就是很辣手的事件，然而它还有一个致命的问题就是时效短，明天的数据可能明天无效、今天就有效了。比方咱们的衰弱码显示核酸数据，明天你是第一天，今天可能就是两天了，再过一天你就要再做核酸了，也就是说核酸数据的只有三天，解决上也就须要及时，如果你的核酸数据，隔两天能力展现，意义又在哪里呢？而且传输、解决快，必然要求零碎硬件要跟得上，像去年的西安衰弱宝、钉钉都有不止一次因服务器资源不够而导致的宕机。4）价值密度低大数据系统有时候可能会破费大量精力，而徒劳无功，咱们吃力收集了大量数据，如果不能在无效工夫内解决，并取得无效数据，过期就有效了，相当于后面的工作白做，价值为零。大数据分析、解决，也像是海底捞针，付出很多，后果不肯定好。比方，知乎粉丝的地区散布，可能这个数据分析起来没那么麻烦，然而如果作为用户，咱们不关注，可见它的价值密度根本为零。（本文图片源自网络，若有侵权分割立刻删除）

随着云原生技术的倒退和成熟，大数据基础设施踊跃拥抱云原生是业内倒退的一大趋势。网易传媒在 2021 年胜利将 SparkSQL 部署到了 K8s 集群，并实现与局部在线业务的混合部署，到目前曾经稳固运行了一年多。期间传媒联结杭研 Spark 内核团队和云计算团队对呈现的问题进行了继续的改良，本文将对这些落地优化实际进行初步的梳理总结，心愿能给大家带来一些有用的参考。目前，传媒大数据中心的大部分 SparkSQL 工作都曾经迁徙到了 K8s 集群，但仍有一部分算力保留在 Yarn 集群，作业调度次要依靠于无数平台，SparkSQL 工作的提交形式以 Kyuubi [1] 为主，Spark 版本次要基于 3.1.2 进行演进，下图简略形容了咱们以后 Spark 离线计算的根本架构： 以下将别离从 on K8s 落地收益、工作迁徙计划、集群和工作运行监控、工作资源占用治理、任务调度优化等几个方面逐步开展介绍。 SparkSQL 迁徙到 K8s 的收益 传媒大数据将 SparkSQL 迁徙到 K8s 次要基于如下考量： 能够将计算和存储进行解耦，即存算拆散。在存储和计算耦合的架构中，因为各业务场景对存储和计算的需要不均衡，绑定两者同步进行伸缩，会呈现其中一种资源节约的状况；将计算和存储解耦后则能够依据须要别离进行弹性伸缩，零碎在负载平衡调度方面能够更加灵便。对立算力资源池实现兼顾调度，SparkSQL 能够作为离线业务与其它在线业务进行混混部达到峰谷互补的成果，有助于晋升服务器资源利用率和治理运维效率，节约总成本。工作由 Yarn 迁徙到 K8S 的计划 迁徙方面，咱们已提前将大部分工作由HiveSQL 迁徙到了 SparkSQL 引擎[2] ，而 SparkSQL 从 Yarn 集群上切换到 K8S 集群上对用户来说基本上是无感知的。不过，迁徙初期为了保障未知危险尽量可控，咱们采取了如下措施： 先迁徙非核心的上游工作来踩坑，逐渐扩充规模再推动到上游工作。先迁徙自定义脚本类型工作，得益于对 Kyuubi 的应用，只须要大量代码就能够不便地将失败任务调度至 Yarn 集群进行重试。这样咱们在迁徙初期尽量减少了对须要保障的外围 SLA 工作链路的影响。工作在 K8s 上的运行监控 工作迁徙到 K8s 之后，在遇到问题进行排查时，用户都迫切希望能尽快看到作业的运行状况从而疾速进行问题诊断和作业优化。传统的 SparkSQL on Yarn 场景，咱们有 Yarn 的 web 页面作为入口来查看队列资源占用和工作运行状态，但在 K8s 环境下并没有一个相似的对立入口。而 Spark History Server 上的工作统计列表因为须要期待工作运行日志上传至 HDFS 后能力解析展现，绝对要滞后许多，这导致了在迁徙初期咱们对集群和工作的运行状况根本处于两眼一抹黑的状态。为了解决这个问题，咱们首先设置所有工作均应用 client 模式提交 SparkSQL，让 Spark Driver 在调度机本地运行，这样一来，便只须要在几台任务调度机上部署监控程序，通过 Spark Driver 本地的 Spark http 接口获取当前任务运行信息即可。这种形式尽管不是很合乎所有组件都跑在容器中的云原生理念，然而人力老本绝对较低，在后期简化了咱们的监控告警工作，未来待计划进一步欠缺后再切换到 cluster 运行模式。另外，随着优化工作的推动，咱们跟杭研 Spark 内核组配合搭建了 Hygieia 工作运行指标监控服务，跟部门运维和杭研云计算团队减少了调度资源相干的监控，对监控需要进行了进一步欠缺。以下简略列举了日常看得比拟多的几个监控报表： ...

一、什么是工作流？在论述什么是工作流之前，先说一下工作流和一般工作的区别，在于依赖视图。 一般工作自身他只会有本人的dag图，依赖视图是无边界的，不可控的，而工作流则是把整个工作流都展现进去，是有边界的，可控的，这是工作流的劣势。上面为大家介绍工作流的相干性能： 01 工作流—性能介绍● 虚构节点 虚构节点，它是不产生任何数据的空跑节点（即调度到该节点时，零碎间接返回胜利，不会真正执行、不会占用资源或阻塞上游节点运行），比如说工作并行执行，那么就会用到虚构节点。 ● 周期生成 指调度零碎依照调度配置主动定时运行的工作。 ● 补数据运行 当业务变更，能够应用补数据性能。如批改了某个工作的代码，可将本月的数据依照新的代码从新跑一遍，立刻生成所需数据。 ● 调度属性 工作流中的子工作依赖于父工作的周期调度属性，父工作批改后，子工作同步批改，以工作流的周期调度属性作为各个子节点的周期调度工夫。 ● 工作流所在目录 批改工作流目录同步批改工作流下的子工作目录。 02 工作流—依赖成环具体实现： 工作实现依赖的关系，key为以后节点，value为该节点的所有父节点Map < long list> nodeMap。 遍历nodeMap，以此遍历单汇合中的每一个节点。每遍历一个新节点，就从头查看新节点之前的所有节点，用新节点和此节点之前所有节点顺次做比拟。如果发现新节点和之前的某个节点雷同，则阐明该节点被遍历过两次，链表有环。如果之前的所有节点中不存在与新节点雷同的节点，就持续遍历下一个新节点，持续反复方才的操作。 二、Taier工作流周期实例运行理解完工作流的性能介绍后，咱们来为大家分享Taier工作流周期实例运行： 01 Taier—周期实例生成Taier主节点在启动的时候，会开启一个定时器，定时器会不停的去判断当日的实例是否曾经生成。如果没有生成，就会触发事件给CycleJobBuilder生成实例，再通过JobDependency封装实例之间的依赖关系。 ● CycleJobBuilder 用于生成周期实例。扫描数据库工作表并且获取zk上所有的Taier节点，把封装后的实例调配到每一台Taier节点上。 ● JobDependency 用于生成job之间的依赖关系。 02 Taier—调度流程在启动Taier服务时，会启动配置的所有调度器，并且开始扫描实例，并提交。 03 Taier—工作流工作状态批改逻辑工作提交拦截器解决： 1、工作流下无子工作更新为实现状态2、工作流下工作都是实现状态，工作提交队列能够移除3、同时更新工作流engine_job状态，工作流只有四种状态，胜利/失败/勾销/提交中：(1) 所有子工作状态为运行胜利时，工作流状态更新为胜利(2) 工作流状态依据子工作的运行状态来确定，失败状态存在优先级：运行失败>提交失败>上游失败a.子工作存在运行失败时，工作流状态更新为运行失败b.子工作不存在运行失败时，存在提交失败，工作流状态更新为提交失败c.子工作不存在运行失败时，不存在提交失败，存在上游失败时，工作流状态更新为上游失败(3) 子工作存在勾销状态时，工作流状态更新为勾销(4) 若子工作中同时存在运行失败或勾销状态，工作流状态更新为失败状态(5) 其余工作流更新为运行中状态三、Taier1.3行将上线性能## 新增性能 · ChunJun的向导模式数据源加强 hive1、hive2、hive3、sparkThrift、oracle、mysql、postgresql、sqlserver 、es7 · flink on standalone、python.shell、spark jar 、pyspark反对 · 自定义工作类型 web界面配置抽取 · windows开发环境适配 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack/Taier

敬爱的社区小伙伴们，咱们很快乐地通知大家，在 2022 年 10 月 17 日咱们迎来了 Apache Doris 1.1.3 版本的正式公布。作为 1.1 LTS 版本根底之上的 Bugfix 版本，在 1.1.3 版本中有超过 80 个 Issue 或性能优化项被合入，零碎稳定性和性能得以进一步增强，举荐所有用户下载和应用。 下载应用GitHub下载：https://github.com/apache/dor... 官网下载页：https://doris.apache.org/down... 源码地址：https://github.com/apache/dor... 重要提醒默认状况下禁用 PageCache 和 ChunkAllocator 以缩小内存应用，用户能够通过批改配置项disable_storage_page_cache和chunk_reserved_bytes_limit来从新启用。Storage Page Cache 和 Chunk Allocator 别离缓存用户数据块和内存预调配。这两个性能会占用肯定比例的内存，并且不会开释。这部分内存占用无奈灵便调配，导致在某些场景下，因这部分内存占用而导致其余工作内存不足，影响零碎稳定性和可用性。因而咱们在 1.1.3 版本中默认敞开了这两个性能。但在某些提早敏感的报表场景下，敞开该性能可能会导致查问提早减少。如用户放心降级后该性能对业务造成影响，能够通过在 be.conf 中减少以下参数以放弃和之前版本行为统一。 disable_storage_page_cache=falsechunk_reserved_bytes_limit=10%disable_storage_page_cache：是否敞开 Storage Page Cache。1.1.2（含）之前的版本，默认是false，即关上。1.1.3 版本默认为 true，即敞开。 chunk_reserved_bytes_limit：Chunk Allocator 预留内存大小。1.1.2（含）之前的版本，默认是整体内存的 10%。1.1.3 版本默认为 209715200（200MB）。 新增性能在 ODBC 表中反对 SQLServer 和 PostgreSQL 的本义标识符反对应用 Parquet 作为导出文件格式优化改良优化了 Flush 策略以及防止过多 Segment 小文件   #12706 #12716重构 Runtime Filter 以缩小初始筹备工夫  #13127修复了若干个在查问或导入过程中的内存管制问题   #12682 #12688 #12708 #12776 #12782 #12791 #12794 #12820 #12932 #12954 #12951BUG 修复修复了 Largeint 类型在 Compaction 过程中导致 Core 的问题   #10094修复了 Grouping set 导致 BE Core 或者返回谬误后果的问题 #12313修复了应用orthogonal_bitmap_union_count 函数时执行打算 PREAGGREGATION 显示谬误的问题   #12581修复了 Level1Iterator 未被开释导致的内存透露问题   #12592修复了当 2 BE 且存在 Colocation 表时通过 Decommission 下线节点失败的问题   #12644修复了 TBrokerOpenReaderResponse 过大时导致堆栈缓冲区溢出而导致的 BE Core 问题   #12658修复了呈现 -238 谬误时 BE 节点可能 OOM 的问题   #12666修复了 LEAD() 函数谬误子表达式的问题   #12587**修复了行查问引擎代码中相干查问失败的问题   #12712修复了CURDATE()/CURRENT_DATE()函数产生谬误后果的问题   #12720修复了lateral view explode_split函数呈现谬误后果的问题   #13643修复了两张雷同表中 Bucket Shuffle Join 打算谬误的问题   #12930修复了更新或导入过程中 Tablet 版本可能谬误的问题   #13070修复了在加密函数下应用 Broker 导入数据时 BE 可能产生 Core 的问题   #13009倡议反馈如降级至 Apache Doris 1.1.3 版本呈现任何问题下方论坛进行发帖，社区专家将帮忙你更快定位和解决问题。GitHub 论坛：https://github.com/apache/dor... ...

作者：vivo 互联网大数据团队- Wang Lei一、前言始终以来，许多产品平台都在尝试通过可视化搭建的伎俩来升高 GUI 利用的研发门槛，进步生产效率。随着咱们业务的倒退，数据建设的欠缺，用户对于数据可视化的诉求也日益增多，而数据大屏是数据可视化的其中一种展现形式，它作为大数据展现媒介的一种，被宽泛使用于各种会展、公司展厅、发布会等。 相比于传统手工定制的图表与数据仪表盘，通用大屏搭建平台的呈现，能够解决定制开发, 数据扩散带来的利用开发、数据保护老本低等问题，通过数据采集、荡涤、剖析到直观实时的数据可视化展示，可能多方位、多角度、全景展示各项指标，实时监控，动静高深莫测。 本文将通过麻利BI平台的通用大屏搭建能力的实现计划，来解说一下通用可视化搭建平台整体的设计思路。 二、疾速理解可视化大屏2.1 什么是数据可视化从技术层面上来讲，最直观的就是前端可视化框架：Echart、Antv、Chart.js、D3.js、Vega 等，这些库都能帮咱们疾速把数据转换成各种模式的可视化图表。 从业务层面来讲， 其最次要的意义就在于通过数据 -> 图表组合 -\> 可视化页面这一业务流程，来帮忙用户更加直观整体的剖析不同行业和场景的趋势和法则。 所以在数据畛域里，对于简单难懂且体量宏大的数据而言，图表的信息量要大得多，这也是数据可视化最基本的目标。 2.2 可视化大屏都有哪些局部次要由 可视化组件 + 事件交互 + 坐标关系 组成，成果如下图所示： 2.3 可视化大屏和常见的BI报表看板的区别常常会有同学会问到，可视化大屏和BI报表看板的区别是什么？ 这里简略的做一下介绍： 大屏和报表看板都只是BI的其中一种展示形式，大屏更多是通过不同尺寸的显示器硬件上进行投屏，而报表看板更多是在电脑端进行展现应用。大屏更加重视数据动态变化 ，会有极强的视觉体验和冲击力，提供丰盛的轮播动画、表格滚动等动画特效。而报表看板更重视交互式数据摸索剖析，例如上卷下钻、排序、过滤、图表切换、条件预警等。三、设计思路3.1 技术选型前端框架：React 全家桶（集体习惯）可视化框架：Echarts[DataV-React](https://github.com/DataV-Team...) (封装度高，json构造的配置项易拓展) D3.js（可视化元素粒度小、定制能力强）拖拽插件：dnd-kit （满足树状构造视图的跨组件拖拽）布局插件：React-Grid-Layout（网格自在布局，批改源码，反对多个方向的拖拽，自在布局、锁定缩放比等）3.2 架构设计下图是咱们搭建平台的整体架构设计： 整个大屏搭建平台蕴含四个十分重要的子系统和模块： 可视化物料核心：是整个平台最根底的模块，咱们在开源的图表库和自主开发的可视化组件下面定义了一层规范的 DSL 协定，这个协定和接入 画布编辑器 的协定是对应的，目前曾经有 40+ 相干组件，组件数量还在一直增长。画布编辑器：是搭建平台的外围与难点，反对页面布局配置、页面交互配置和组件数据配置等性能，另外还反对代码片段的配置，也能够称得上是一个低代码平台。数据中心：是提供专门用于连贯不同数据源的服务，例如直连 MySQL、ClickHouse、Elasticsearch、Presto 等，提供了大屏搭建所须要的原始数据。管理中心：是大屏的后盾经营治理模块，蕴含了大屏模版治理、大屏公布下线、拜访权限等治理性能。3.3 搭建流程通过下面提到的大屏组成元素，咱们能够剖析总结出大屏搭建主流程如下图所示： 四、外围性能实现接下来咱们会逐个对平台几个外围性能实现进行解析： 1、大屏自适应布局 背景：解决页面错乱问题，实现多种分辨率的大屏适配： 思考：首先咱们想到的是挪动端适配支流的 vh、vw、rem组合的形式以及 font.js+rem 等两种计划。第一种计划次要是通过媒体查问来定义父级大小，而后对组件的height、margin、padding等多种css属性采纳rem作为单位，继承父级设置等单位（1vw）,实现自适应适配，第二种计划是援用第三方脚本，通过在main.js中写代码计算，应用rem进行继承,实现适配。 ① vh、vw、rem组合 //vw vh单位 w3c的官网解释 vw：1% of viewport’s width vh：1% of viewport’s height//例如，设计稿的宽度为1920px，则1vw=19.2px，为了不便计算，咱们将html元素的font-size大小设置为100px，也就是5.208vw=100px。body,html { font-size:5.208vw}② font.js + rem ...

本文将次要介绍 NDH Impala 的物化视图实现。 接上篇，前两篇别离讲了执行引擎和虚构数仓，它们是让一个 SQL 又快又好地执行的要害。但如果某些 SQL 过于简单，比方多张大表进行 Join 并有大量的聚合类操作，那么再优良的执行引擎也无奈保障可能秒级执行实现，虚构数仓的弹性扩大能力也很难及时跟上，这正是物化视图可能发挥作用的场景。 1 物化视图简介 在计算机领域，物化视图是一个数据库对象，结构化保留了一个 SQL 查问的后果集，创立物化视图的过程可称为物化，是预计算的一种模式。物化视图是一个比拟宽泛的概念，可能是远端数据的一份本地拷贝，也可能是一个表或多表 Join 后某些行 / 列的子集，也能够是将聚合函数作用到表或 Join 后果后的汇总类信息。 1.1 物化视图分类 依据物化视图中原始数据表的个数，可分为单表和多表物化视图；依据物化视图 SQL 中是否存在聚合类操作，可分为明细和聚合物化视图；依据物化视图的后果集在更新时是否须要全量刷新，可将其分为全量和增量物化视图，后者又可称为分区物化视图，增量数据写入新分区中。 1.2 特点与作用 一般视图仅示意一个 SQL 语句，是个逻辑概念，而物化视图则有实体对象 / 表与之对应。这样在执行查问时，就能够通过查问对应的物化视图表数据，从而疾速失去查问后果。物化视图应用查问重写机制，当执行查问时，引擎主动抉择适合的物化视图进行查问重写，齐全对利用通明。 个别用于进行性能减速，具备比拟宽泛的应用场景，如果业务查问存在如下特色，即可尝试用物化视图进行减速：比方查问耗时较多且查问频次较高、雷同或类似的查问多并发或周期性产生、业务对查问后果的数据实时性没有过于严格的要求，容许分钟或小时级的提早等。具体业务方面，在数仓畛域，T+1 类 BI 报表是典型的能够通过物化视图进行优化查问的场景。 1.3 应用成果评估 物化视图应用切当可能数倍，甚至数十倍晋升查问性能，但其也不是万能的，如果不分场景自觉创立物化视图，其后果可能事与愿违。一方面是因为物化视图的创立和更新有老本，另一方面，断定 SQL 是否命中的逻辑也在性能敏感的代码门路上引入了额定的耗时。 笔者认为，应用物化视图的成果评估须要思考 2 个方面：首先，其是否带来了查问的性能晋升。这是最根本的指标；其次，是否升高了集群总的资源耗费，包含计算资源和存储资源。这是进阶指标，在每个物化视图都有大量的查问命中时，将会显著缩小每个查问对 CPU 和内存资源的需要，同时也不再须要拜访原始表，缩小 IO 资源耗费。 1.4 应用现状 物化视图是进行查问性能优化的重要伎俩，传统的商业数据库，比方 Oracle、IBM 和 SQL Server，以及目前商业数仓零碎，比方 Snowflake、AnalyticDB 等，均具备弱小的物化视图能力。 目前开源的数仓零碎，在物化视图反对水平上绝对有余，Doris、Clickhouse、Druid 等临时仅反对单表聚合类物化视图（或称为聚合索引），也无数仓引擎曾经在开发多表物化视图，比方 Meta 的 PrestoDB 等。网易 NDH Impala 在物化视图能力建设上投入较早，目前已在生产环境上规模应用，本章的后续大节次要介绍 NDH Impala 的物化视图实现和实际。 ...

本篇是「标签画像系列」的第四篇，此前咱们曾经介绍过了标签画像体系建设方法论、标签体系设计与加工、标签加工与落库，这次咱们来介绍一下「标签评分」。 标签评分是标签治理的一个重要措施，通过给标签打分，可清晰直观的从各个维度评估标签，把握标签实在应用状况，进行标签继续优化，助力业务经营。同时，也能帮忙数据团队判断哪些标签更应该投入计算与存储资源，正当布局集群资源。 一、为何要应用标签评分？通过后期标签体系设计、标签加工，标签终于能够上线，让业务人员应用，施展价值了！ 随着标签上线一段时间后，咱们开始关怀每天占用计算资源与存储空间，跑进去的上百个标签，业务同学真的用到了多少，业务收益是否能笼罩数据老本呢？标签上线后，其品质怎么样，是否存在老规定不实用、须要继续优化的状况？ 带着这一问题，咱们须要用一种办法来评估标签上线后的应用状况，标识各个标签的价值。参考电影评分、花呗评分等模式，咱们决定也给标签打个分、排个序，简单明了。 二、标签评分模型标签评分模型，通过思考咱们选取了5个维度作为评分入参： 标签总评分= a 标签应用度评分 + b 标签关注度评分 + c 标签品质评分 + d 标签继续优化读评分 + e * 标签平安度评分 其中标签应用度、标签关注度、标签品质、标签继续优化度作为外围维度，标签平安度可依据理论状况思考是否纳入。a、b、c、d、e是权重，总和为100%。 01 标签应用度评分标签应用度，用以评估标签被剖析、内部零碎的应用状况。 在袋鼠云标签产品中，标签有这几种应用场景： • 标签援用：如原子标签被衍生标签利用、衍生标签被组合标签援用等，基于该场景，计算“标签援用次数”指标。 • 标签剖析：标签在标签圈群、群组画像、群组比照、显著性剖析等画像剖析性能中被剖析的状况，计算“标签剖析次数”指标。 • 标签调用：标签通过数据API被内部利用查问的次数，计算“标签调用次数”指标。 基于以上3个指标，咱们首先采纳Sigmoid函数将指标转化为评分，再将各个指标的评分加权汇总成标签应用度评分。 02 标签关注度评分标签关注度，用以评估被搜寻、查看、珍藏的状况。 袋鼠云标签产品中，标签关注度与以下场景无关： • 标签搜寻：标签在标签市场被用户搜寻的状况，计算“标签搜素次数”指标。 • 标签查看：标签被点击查看根底信息、剖析页面等的次数，计算“标签查看次数”指标 • 标签珍藏：收藏该标签的用户数，计算“珍藏用户数”指标 以上3个指标可反映标签的关注热度，咱们仍然采纳Sigmoid函数将指标转化为评分，再将各个指标的评分加权汇总成标签关注度评分。 03 标签品质评分标签品质，用以评估用户被打标状况，反映标签规定的合理性。 当咱们定义了标签和标签值，通过计算之后，标签值打在用户身上的很少，那阐明咱们的规定执行不合理。比方咱们定义了“活跃度”这个标签，分为“高沉闷、中沉闷、低活跃度”等，但实在被打上的这个标签的用户，低于70%，还有很大一部分比例是空值，未打上该标签，阐明咱们制订的标签值规定有破绽，须要欠缺。 零碎将计算每个标签的“标签覆盖度”，将覆盖度归一化为分数，转化成评分。 04 继续优化度评分继续优化度，用以评估标签上线后，是否后续再去优化该标签。 在客户的生命周期中，一直有新用户流入、缄默用户散失。公司策略调整、产品公布等都会影响客户行为，这些变动咱们须要以数据的形式出现，所以咱们须要一直依据业务调整、客户变动调整咱们的标签策略，以谋求可通过标签间接地、迅速地反映客户状况，领导业务经营。 继续优化度，咱们通过“标签优化次数”指标来评估，指标签上线后标签被编辑再次公布的的次数。咱们同样采纳Sigmoid函数将指标转化为评分。 05 平安度评分标签平安度，不能反映标签的热度，但也将其作为了标签评分的一个维度，可依据企业状况思考是否纳入。 在袋鼠云标签产品中，标签平安相干的策略有： • 标签的可见度：标签可编辑、可查看的用户范畴 • 标签应用是否须要申请受权：标签公布后，其他人应用该标签，是否须要申请审批 • 标签是否进行行级权限管制：下面咱们管制了标签的列权限，行级权限反映该标签是否设置了行级权限 • 标签是否脱敏：标签是否进行脱敏 依据标签的平安度策略配置状况，咱们也采纳评分的形式来评估。 基于以上5个维度的评分，咱们依据后面提的公式加权汇总，失去总评分。 ...

一、引言Presto是开源分布式SQL查问引擎，能够对从GB到PB级大小的数据源进行交互式剖析查问。Presto反对Hive、Cassandra、关系型数据库甚至专有数据存储等多种数据源，容许跨源查问。（详见参考[1] ） 图1 Presto档次架构图（图源Presto官网） 无处不在的Presto当今大规模的互联网公司都在应用Presto。Uber将Presto用于SQL数据湖，每周有超过7000名沉闷用户，每天在超过50PB 的HDFS（Hadoop Distributed File System）数据上运行50万次查问。字节跳动对Presto 进行了宽泛的利用，例如数据仓库、BI 工具、广告等。 字节跳动的 Presto 集群领有上万个计算外围，每天解决约 100 万次查问，涵盖 90% 以上的交互式查问。这极大地缩小了查问提早并节俭了大量计算资源。 Meta公司（Facebook）应用 Presto 对多个外部数据存储进行交互式查问，包含300PB 数据湖。每天有超过 1,000 名 Facebook 员工应用 Presto 运行 30,000 多个查问，均匀每个查问扫描超过 1 PB。 腾讯将Presto 利用于外部的不同业务场景，包含微信领取、QQ、游戏等要害业务。日均解决数据量 PB 级，P90 查问耗时为 50s，全面晋升各业务数据实时剖析性能，无效助力业务增长。 阿里数据湖剖析集成了Presto的联结查问引擎能力，不仅让阿里云泛滥用户体验了大规模的 Serverless 云服务，也积攒了许多胜利的业务用例，比方日志数据分析和基因数据分析等，这些案例表明了Presto利用宽泛，剖析能力弱小。 图2 各大互联网公司Presto性能展现数据局部起源Presto官网 Presto零碎架构Presto 集群由一个Coordinator和一个或多个Worker组成。Coordinator负责接收、解析、布局和优化查问以及查问编排，Worker负责查询处理。Presto通过Connector适应底层不同类型的数据源，以便拜访各种数据源中的数据。如图3显示了 Presto 架构的简化视图（详见参考[2] ）。 图3 Presto 架构图 传统形式部署Presto存在的问题作为一个分布式架构的零碎，Presto为数据查问和解决提供了高效便捷的办法。随着数据量增大，为了保证数据查询处理的效率，Presto集群规模也要扩充。例如上文提到的Uber、字节跳动和Meta等公司每天查问的数据量是PB级别，一个Presto集群的节点数量曾经上千。当数据量远超单机解决能力时，分布式架构相比于集中式架构的劣势就体现进去了，然而对于一个规模宏大的分布式集群，继续高效地解决数据，将会面临一系列的问题： 对于一个规模宏大、节点数量上千的Presto集群，如果没有自动化部署工具，采纳传统形式一个一个部署Presto节点，消耗的工夫是难以想象的。此外对于部署好的Presto集群依据业务进行调优，须要一直批改Presto节点的配置信息，依照传统形式一一批改配置信息，消耗的人力和工夫老本也是难以忍受的。传统部署Presto集群，当其中某个节点产生故障时，无奈做到主动重启或者动静退出新的节点以维持集群数量，此时如果正好产生故障的是Coordinator节点，则整个集群将陷入瘫痪，导致服务不可用。Presto次要利用场景是即席查问，比方Uber和滴滴等网约车公司，查问业务顶峰时段次要在白天，早晨根本没有查问。如果早晨闲置的资源不能加以回收利用，将会产生很大的资源节约。此外，当业务高峰期的查问负载超过以后集群的承载能力时，如果不对集群立即按需扩容，也会对业务产生很大的影响。 应用Kubernetes部署Presto集群，将云原生与Presto相结合，借助Kubernetes便捷部署、自动化运维和弹性伸缩等长处，解决上述提到的一系列问题。 二、应用Kubernetes部署PrestoKubernetes，也被称为K8s，是一个用于自动化部署、扩大和治理容器化应用程序的开源零碎，目前已被业界宽泛承受并失去了大规模的利用。Kubernetes集群由管制立体和node组成。其中node上运行由Kubernetes所治理的容器化利用，也就是Pod。管制立体治理集群中的node和Pod，为集群提供故障转移和高可用性，而集群也会跨多个主机运行（详见参考[3] ）。 图4 Kubernetes部署Presto集群计划 如图4所示为本次测试所部署计划，Deployment负责创立、更新、保护其所治理的所有Pods。Presto Coordinator和Worker过程别离运行在Pod中，针对Presto集群内Coordinator和Worker别离配置不同类型的Deployment来进行治理。Deployment能够保障集群内可用Pod的数量，实现弹性伸缩，维持集群可用性和稳定性。 Configmap用来存储配置文件，Coordinator和Worker的配置信息别离通过Configmap进行存储，每次进行配置更改，只须要批改Configmap外面的配置信息，Coordinator和Worker就会更新相应的配置信息。 Service会对同一个服务的多个Pod进行聚合，向集群提供一个对立的入口地址，通过拜访Service的入口地址就能拜访到前面的Pod服务，实现负载平衡和服务发现。在Kubernetes部署的Presto集群中，Coordinator将本人的地址注册到Service，Worker通过Service中的域名地址与Coordinator连贯，从而实现Presto集群的服务注册与发现。 在Kubernetes部署Presto计划中，Deployment负责创立和治理Pods，Configmap负责存储配置信息，Service负责服务注册与发现。Deployment、Configmap和Service三类资源相互配合，保障了Presto集群继续高效工作。 Kubernetes部署计划的长处通过正当设置Deployment、Configmap和Service等资源对象，应用Kubernetes部署Presto集群，将Kubernetes的经营劣势与Presto技术劣势相结合： 便捷部署：在Deployment中设置Coordinator和Worker的正本数量，Configmap设置配置信息，Service设置Presto集群提供服务的入口地址。将上述三类资源对象提交到Kubernetes中即可实现Presto集群配置，比方设置Worker正本数量为1000，提交之后即可创立1000个Worker Pod，每一个节点的配置信息从Configmap文件中读取。只须要编写好资源对象文件，提交到Kubernetes，即可创立Presto集群，后续能够通过批改Configmap文件更新各个节点的配置信息。通过Kubernetes部署Presto集群加重了配置、部署、治理和监控容器化Presto应用程序的累赘和复杂性。* 自动化运维：能够更不便地和Prometheus联合，通过Prometheus能够实现对整个集群的监控数据采集、存储、剖析以及可视化。无效监控Presto集群，当产生故障时能够针对性修复，从而维持集群稳固，保障高可用性。弹性伸缩：当业务量激增，主动扩容Presto Worker节点，满足业务需要；当业务量处于低谷，主动缩容Presto Worker节点，节俭运行老本。Kubernetes部署计划的问题传统形式部署Presto集群是以物理机的形式运行，相比之下，在Kubernetes上部署Presto集群是以容器的形式运行。只管Kubernetes部署形式带来了很多长处，然而容器形式和物理机形式的性能差别依然未知，上面的测试将重点比照剖析两种不同部署形式的性能差别。 ...

Hadoop是Apache基金会旗下最出名的基础架构开源我的项目之一。自2006年诞生以来，逐渐倒退成为海量数据存储、解决最为重要的根底组件，造成了十分丰盛的技术生态。 作为国内顶尖的 Hadoop 开源生态技术峰会，第四届 China Apache Hadoop Meetup于 2022年9月24日在上海胜利举办。 围绕“云数智聚 砥柱笃行”的主题，来自华为、阿里、网易、字节跳动、bilibili、安全银行、袋鼠云、英特尔、Kyligence、Ampere等多所企业单位，以及来自Spark、Fluid、ChunJun、Kyuubi、Ozone、IoTDB、Linkis、Kylin、Uniffle等开源社区的多位嘉宾均参加了分享探讨。 作为此次Meetup参加社区之一，也是大数据畛域的我的项目，ChunJun也带来了一些新的声音： ChunJun框架在实时数据采集和还原上的实现和原理是怎么的？这段时间以来，ChunJun有哪些新倒退，对于将来倒退又有着怎么的新想法？ 作为袋鼠云资深大数据引擎开发专家，徐超带来了他的分享，将从一个独特的角度来介绍ChunJun数据集成在数据还原上的摸索和实际。 一、ChunJun框架介绍第一个问题：ChunJun这个框架是什么？无能啥？ ChunJun(原FlinkX) 是袋鼠云基于Flink 基座自研的数据集成框架,通过4年多的迭代，曾经成为一个稳固，高效，易用的批流一体的数据集成工具，可实现多种异构数据源高效的数据同步，目前已有3.2K+Star。 开源我的项目地址： https://github.com/DTStack/ch... https://gitee.com/dtstack_dev... 01 ChunJun框架结构ChunJun 框架基于Flink 进行开发，提供了丰盛的插件，同时增加了断点续传、脏数据管理、数据还原等个性。 02 ChunJun批量同步• 反对增量同步 • 反对断点续传 • 反对多通道&并发 • 反对脏数据（记录和管制） • 反对限流 • 反对transformer 03 ChunJun离线 二、实时数据采集上的实现和原理01 一个样例 02 ChunJun插件装载逻辑 03 ChunJun插件定义 04 ChunJun数据流转 05 ChunJun动静执行面对监听多个表的状况，包含新增加表的数据，咱们如何执行上游的写入： • 反对Update 转换 before,after • 增加扩大参数，DB,Schema,Table, ColumnInfo • 反对动静构建PreparedStatement 06 ChunJun距离轮询什么是距离轮询？咱们是如何做的？ • 校验轮询字段类型，如果不是数值类型且source并行度大于1，报错不反对 • 创立三个数据分片，startlocation为null或者配置的值，mod别离为0，1，2 • 结构SQL：不同SQL的取余函数不同，各自插件实现 ...

本期咱们带大家回顾一下无倦同学的直播分享《ChunJun类加载器隔离》，ChunJun类加载器隔离的计划是咱们近期摸索的一个新计划，这个计划目前还不是十分成熟，心愿能借由此次分享与大家一起探讨下这计划，如果大家有一些新的想法欢送大家在github上给我提issue或者pr。 一、Java 类加载器解决类抵触根本思维在学习计划之前，首先为大家介绍一下Java类加载器解决类抵触的根本思维。 01 什么是 Classpath?Classpath是JVM用到的一个环境变量，它用来批示JVM如何搜寻Class。 因为Java是编译型语言，源码文件是.java，而编译后的.class文件才是真正能够被JVM执行的字节码。因而，JVM须要晓得，如果要加载一个com.dtstack.HelloWorld的类，应该去哪搜寻对应的HelloWorld.class文件。 所以，Classpath就是一组目录的汇合，它设置的搜寻门路与操作系统相干，例如： 在Windows零碎上，用;分隔，带空格的目录用""括起来，可能长这样： C:\work\project1\bin;C:\shared;"D:\My Documents\project1\bin" 在MacOS & Linux零碎上，用:分隔，可能长这样： /usr/shared:/usr/local/bin:/home/wujuan/bin 启动JVM时设置Classpath变量, 实际上就是给java命令传入-Classpath或-cp参数. java -Classpath .;/Users/lzq/Java/a;/Users/lzq/Java/b com.dtstack.HelloWorld 没有设置零碎环境变量，也没有传入-cp参数，那么JVM默认的Classpath为，即当前目录： java com.dtstack.HelloWorld 02 Jar 包中的类什么时候被加载?● Jar包 Jar 包就是 zip 包，只不过后缀名字不同。用于治理扩散的 .class 类。 生成 jar 包能够用 zip 命令 zip -r ChunJun.zip ChunJun java -cp ./ChunJun.zip com.dtstack.HelloWorld ● 加载 “加载”（Loading） 阶段是整个“类加载”（Class Loading） 过程中的一个阶段，心愿读者没有混同这两个看起来很类似的名词。在加载阶段，Java虚 拟机须要实现以下三件事件： 1.通过一个类的全限定名来获取定义此类的二进制字节流； 2.将这个字节流所代表的动态存储构造转化为办法区的运行时数据结构； 3.在内存中生成一个代表这个类的java.lang.Class对象，作为办法区这个类的各种数据的拜访入口。 ● 解析 类或接口的解析 假如以后代码所处的类为D，如果要把一个从未解析过的符号援用N解析为一个类或接口C的间接援用，那虚拟机实现整个解析的过程须要包含以下3个步骤： 1.如果C不是一个数组类型，那虚拟机将会把代表N的全限定名传递给D的类加载器去加载这个类C。 在加载过程中，因为元数据验证、字节码验证的须要，又可能触发其余相干类的加载动作，例如加载这个类的父类或实现的接口。一旦这个加载过程呈现了任何异样，解析过程就将宣告失败。 2.如果C是一个数组类型，并且数组的元素类型为对象，也就是N的描述符会是类 似“[Ljava/lang/Integer的模式，那将会依照第一点的规定加载数组元素类型。 如果N的描述符如后面所假如的模式，须要加载的元素类型就是“java.lang.Integer"，接着由虚拟机生成一个代表该数组维度和元素的数组对象。 3.如果下面两步没有呈现任何异样，那么C在虚拟机中实际上曾经成为一个无效的类或接口了，但在解析实现前还要进行符号援用验证，确认D是否具备对C的拜访权限。如果发现不具备拜访权限，将抛出java.lang，llegalAccessEror异样。 03 哪些行为会触发类的加载?对于在什么状况下须要开始类加载过程的第一个阶段“加载”，《Java虚拟机标准》中并没有进行 强制束缚，这点能够交给虚拟机的具体实现来自在把握。然而对于初始化阶段，《Java虚拟机标准》 则是严格规定了有且只有六种状况必须立刻对类进行“初始化”（而加载、验证、筹备天然须要在此之 前开始）： ...

作者：哈九，菜鸟裹裹数据研发 无刃，菜鸟裹裹数据研发 夏招，菜鸟裹裹数据产品 菜鸟寄件业务以后为菜鸟的基础设施建设业务，是用户与【菜鸟】品牌最间接最根本的认知分割。通过与三通一达等巨头快递公司单干，降本增效，数字化、智能化的推动了中国快递行业腾飞。在新的一年里，菜鸟裹裹更是【做物流行业数字化转型的引擎】这一菜鸟大愿景的践行者。目前裹裹寄件日常寄件订单量百万级别，且双十一等大促期间订单量更是成倍增长。\智能化履约过程及一直精益化的业务零碎，菜鸟裹裹团队急需一套一体化的数据产品，可能智能化、专业化、高效化的解决日常遇到的数据问题与需要，并在日常的数据监控与成果剖析的过程中，用数据影响业务决策。基于业务越来越频繁的数据需要及数据利用，咱们应用Hologres构建万能查产品，一劳永逸的解决业务汹涌的需要与各种口径、降本增效等问题。 通过本文咱们将会介绍菜鸟裹裹基于Hologres构建万能查产品的最佳实际。 一、菜鸟裹裹数据旧时代的迷雾1.冗余建设，数据口径等差别导致的数据不准 菜鸟裹裹寄件业务倒退至今，已经验过多轮的业务方向调整以及组织架构的变动，必然会存在极重的数据历史包袱。各类数据指标依据业务类型、经营模式的不同扩散于不同的看板模块，成果剖析关联度低；或同时多数据看板反复建设，类型适度细分，找数难，间接影响业务剖析效率及体验感。此外，业务和BI所面对的剖析场景、汇报对象、理论指标的不同，对于同一个指标可能存在多版本多角度的统计口径，易呈现数据口径等轻微差别导致的数据不准的状况，导致了数据同学日益沉重的“找茬”工作。若再不协同各方梳理指标口径，确定口径定义模式，对立底层数据，删减冗余看板，最初压死数据同学的将是任意一个不出名的“包裹”。 2.数据开发周期长，妨碍倒退进度\晚期的数据产出经常以需要为导向，以疾速满足业务剖析为目标。因而之前合作模式，次要为业务提出取数需要，剖析现有数据看板是否反对，若无奈撑持则从新搭建，并未将数据产品化。疾速倒退的业务必然会衍生出新的剖析维度，目前固化的数据看板无奈疾速应答，同时也没有业务可自助查问数据的对立入口，数据分析进度与数据开发周期强绑定，从而导致业务经常不得不停下来等数据，对业务进度上造成了肯定的妨碍。 3.查问速度慢，业务体验差\离线数据分析和业务看板目前存在两种惯例设计方案，如下图所示： 用FBI等工具间接拜访MaxCompute（原ODPS）离线表，然而因为ODPS开发资源短缺和MR的解决架构导致数据访问速度绝对较慢，用户期待工作执行工夫往往超于数据分析自身；造成一个adm层的聚合指标后果宽表，通过表面或DataX工具将聚合后果写入OLAP引擎减速查问（利用ADB提供的稳固查问减速能力），但该计划数据需保护大量同步工作，且工作同步耗时较长。同时，该计划仅实用于较少且绝对稳固的维度和指标查问组合，只需对汇总层后果进行简略聚合计算。 二、新时代面临的挑战1.业务日益增长的数据须要和不均衡不充沛的数据服务倒退之间的矛盾业务倒退处于高速倒退阶段，裹裹寄件经营模式在疾速试验疾速试错的过程中急需数据中台提供强有力的反对。个性化举荐、麻利剖析，大数据的利用在这个时代发明了很多千亿级别的景象级公司，可见于此业务倒退迅速收缩，若数据中台仍旧保留一对一的数据服务模式，服务速度将远远跟不上时代的后退脚步。目前迫切于找到应答指数级增长的数据需要的前途，打造一套一体化的数据产品，智能化、专业化、高效化的解决日常遇到的数据问题与需要，真正做到数据赋能，驱动寄件模式降级。 2.在降本增效大背景下的人效匹配问题业务外围诉求是通过数据化产品疾速监控剖析，看清部分业务现状并作出决策，并不在乎如何取数。数据计算过程，易造成数据过于定制化、灵活性差、剖析维度不全面等问题。若后续呈现同类取数剖析需要，需减少新维度或指标时，数据同学需从新开发代替迭代，重启新看板模块，老本高、效率低、排期长，业务埋怨一直，与开始疾速响应业务疾速看数需要目标相悖。兼顾老本和体验，开释人力的同时保障业务同学可疾速自助获取数据，是一个火烧眉毛的问题。 三、迎难而上：Hologres的抉择，万能查的诞生1.裹裹稳固的业务状态目前裹裹寄件日常寄件订单量百万级别，且双十一等大促期间订单量更是成倍增长，其次要业务模式为收到各端寄件的需要（信息流），而后将寄件需要单分发给单干的快递公司网点及小件员（三通一达），小件员在包裹侠上接单/消费者到站寄件；包裹揽收后消费者实现运费领取，快递交付于第三方物流实现运输配送。 2.Hologres的弱小之处Hologres是一站式实时数据仓库引擎，反对海量数据实时写入、实时更新、实时剖析，与MaxCompute、Flink、DataWorks深度交融，提供离在线一体化全栈数仓解决方案，广泛应用在实时数据中台建设、精细化剖析、自助式剖析、营销画像、人群圈选、实时风控等场景。HOLO的次要个性有： 反对高并发数据实时写入和实时查问，存储计算拆散可独立扩大；底层数据架构对立，行存表反对高QPS KV点查问，列存表适应于OLAP剖析或Adhoc查问；同时反对负载隔离，对立数据拜访接口与安全策略；联邦查问，反对盘古2.0文件间接读取；表面减速Hologres无缝对接MaxCompute，反对内部表通明减速查问，反对OSS内部表读写；3.万能查产品构想通过目前现有的数据撑持能力，依赖Hologres引擎，将裹裹寄件罕用且稳固的维度和指标封装于万能查中。用户可依据本人的需要筛选字段，定制化本人的报表，疾速自助实现经营数据分析。基于一体化数据分析产品「万能查」，冲破目前数据产品的壁垒，达到降低成本、提高效率、保证数据准确性、实现体验降级的目标。 统一口径：协同BI、多方业务梳理业务过程、整顿刻画业务状态的关键性指标、对立数据指标计算口径、及对外输入查问口径；产品刻画：万能查为一套一体化多维度多场景的数据分析体系，疾速为经营决策、产品策略提供疾速无效的数据撑持。汰换之前的「报表」+「长期取数」的数据输入模式下，业务方可通过万能查无效地监控运力工作单据的生命周期，治理小件员运力流程，自主实现剖析论断、长期取数需要，缩小开发成本，进步经营效率。 四、万能查产品架构体系1.模块设计产品需要设计过程中，会承受到不同的用户各种的个性化诉求。业务团队次要将经营过程划分为订单经营和用户经营，而不同的需要会有不同视角和粒度的看数诉求。另外，因为淘退订单的业务特殊性，需基于全局淘退订单进行剖析，订单视角存在较大的区别。因而针对用户的个性化需要，以及理论业务场景，咱们将万能查划分为三大模块：订单，用户，淘退，设计多款万能查产品。 2.数据架构设计数据能力矩阵，依据后期的需要调研，踊跃协调业务、BI同学对裹裹寄件的剖析场景、产出逻辑、最终目标进行对立；收集整理刻画裹裹寄件业务过程的要害指标，构建数据指标矩阵 数据建模，实现外围指标需要收集和剖析后，划分数据域，分割多部门团队同学，确定数据中间层，并进行数仓模型评审 3.数据模型设计基于数据量大、周期长、链路范围广、维度特色多等业务需要特点，且联合Hologres存储费用低等问题。咱们整体万能查设计构造如下： 在ODPS中读取各主题的公共层及维表，构建可扩展性较高的轻度汇总层。将查问频率较高的近一年数据通过内表的模式导入Hologres表的各历史分区，进步高速查问；思考到业务剖析时应用跨年的数据进行同期比拟剖析，但剖析频率并不高，因而抉择就义速度提供表面的模式查问（表面最多反对512分区查问）。目前FBI一个组件只反对一个数据集，为保障用户的应用体验，咱们利用试图的形式在Hologres中将内表以及表面进行合并，对外只透传视图。基于轻度统计层的按工夫范畴的OLAP查问是次要的数据场景，存在大量聚合Group by等操作，因此Holo表的属性抉择上，毫无疑问是列存+日期分区表。一方面对于日期（ds）设置为分区字段，能够无效放大每次查问的扫描范畴；另一方面也能够较平安的进行运维和排查问题。具体构造如下： 1）索引设计Hologres提供了Distribution Key、Segment Key、Clustering Key、Bitmap Columns等一系列的索引形式对表进行优化，正当的应用各类索引，能够大幅晋升使用性能。 基于裹裹寄件业务导入数据为轻度汇总无惟一主键且无自增/类自增字段的个性，不设置Distribution Key以及Segment_key，采纳随机散发到shard的模式，其中，设计Segment_key索引中会存在一个误区，是指定具备递增逻辑列，区别于ds分区字段，同时设置分段列需排序后写入，才会失效。 此外，因为用户存在多种等值过滤查问场景，通过统计分析常常用在Filter和Range场景的字段，咱们将应用次数绝对较多的字段“业务子类”设置为聚簇索引Clustering Key，其余剖析维度设置Bitmap，如揽件网点，运力类型，发货城市等信息。 CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d', 'orientation', 'column'); CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d', 'clustering_key', 'send_sub_type'); CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d', 'bitmap_columns', 'fac_id,fac_name',...); CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d', 'time_to_live_in_seconds', '34560000');2）动静分区回刷设计因为采纳了Hologres分区表的设计形式，但在ODPS数据回流至Hologres时，Hologres分区表无奈间接向父表插入数据，需顺次删除并重建分区子表，将数据插入分区子表中，实现分区父表动静更新数据，且以后不反对python/shell等脚本循环调度Hologres SQL实现数据回刷。实现Hologres的分区表动静分区式更新回流数据，即循环执行Hologres分区表脚本将数据回流至每一个分区子表。（理解到前期holo1.3版本上线，将反对动静分区治理，离线将反对动静写入，且可反对并行补数据。） 3）其它设计Table Group的设置个别依据数据规模、拜访个性、资源规格和应用重心（Join频次）等综合思考。须要关联的表放入同一个Table Group，通过Local Join缩小数据的Shuffle，可极大晋升查问效率。肯定范畴内，Shard Count能够进步数据写入和查问剖析解决的并行度。但大量的Shard数须要更多的节点间通信资源、计算资源以及内存资源撑持，从而导致资源节约。 目前，裹裹寄件轻度统计层数据，数据起源对立，表单分区个别在数千万行量级，个别做灵便多维度汇总，并发不高，且无需做多流join。因而抉择默认Shard Count为12，不做非凡批改。 4.产品展现筛选所需指标维度，也能够在搜寻框中输出你想要查找的字段。比方【及时回单率】【网点ID】点击确定，指标数据将会主动聚合，秒级返回；可在同一数据入口，查问剖析包裹全链路的指标数据；自主上传运单号或用户ID，疾速剖析用户复购率、订单流程进度等剖析型数据需要；定制化，抉择指标后果及筛选项后果将会记录下来，在下次进入时依然会记住这些选项，无需反复操作； 五、高效的业务效力统一口径：万能查对立了数据指标计算口径、及对外输入查问口径，大幅度缩小不同报表数据对不齐、对不准等问题，预计下线30+FBI看板，且间接性达到对外传递数据撑持能力，反向积淀数据资产的成果。提高效率：万能查涵盖规模、客诉、服务质量、衰弱度考核、淘系逆向、用户等多维度多业务的数据，已可撑持业务日常的监控考核需要；同时，业务方可通过万能查多维度自由组合自行实现剖析论断需要、及95%+长期取数需要，数据指标开发需要从原来的一周提6次升高位两周提2次，大幅缩小开发成本，进步经营效率，业务同学满意度95%+。爽约率案例：疾速监控网点爽约率稳定，精准剖析稳定起因，并疾速触达至城市经理；疫情订单拦挡案例：针对突发疫情，业务方可疾速通过万能查明细查问异样包裹，将响应过程缩短至小时级别。降低成本：万能查数据产品上线以来，从新规整鸟查FBI数据看板，删减冗余看板近30+；产品影响力：万能查已笼罩了裹裹整条业务线的外部用户，涵盖商家、运力、线上寄件、IOT、大B销售、客服、体验、业务产品技术等将近15个团队，周均DAU200+，季度均DAU1000+，已收到几十位业务同学的称心反馈。目前该产品模式已宽泛复用于其余菜鸟业务线。六、将来方向和思考1.产品升级目前经营决策、产品策略的成果剖析关联度剖析能力还比拟弱，能较大水平的满足业务方全局监控剖析的需要，但却无奈精细化感知指标数据的稳定以及产品变更与数据稳定的因果关系。对于数据变动的业务能力降级，将是产品接下来迭代的重点方向； 2.时效降级目前产品次要是基于离线数据设计，然而存在较多的实时数据查问需要，如疫情预警时，需依赖实时/小时数据取出截止以后时段的包裹明细。咱们后续能够读取Hologres Binlog或者TT/MQ音讯，利用Flink的流解决能力，通过查问长久化存储的Hologres维表补全模型字段，形成明细表，写入到Hologres分区的当日实时分区；并在T+1日咱们通过Hologres的表面导出的性能，将T日实时写入的这类快照状态字段从Hologres导出到ODPS做长久化离线存储，充分利用Hologres资源。\ 最初：\菜鸟裹裹数据产品设计任重道远，Hologres在数据产品上的利用范畴十分宽泛，万能查只是该数据引擎的探路者，两头碰到了各种各样的问题，包含模型设计、性能调优等，感激数据团队同学在数据技术和Hologres架构等方面的反对和帮忙，将来咱们也将会继续应用共建。

据中国信通院公布，2012年到2021年10年间，我国数字经济规模由12万亿元增长到45.5万亿元，在整个GDP中的比重由21.6%晋升至39.8%。顺应时代倒退新趋势，“数据”成为新的生产因素已是毋庸置疑的共识。 如果说数据中台的崛起代表着企业数字化转型从流程驱动走向数据驱动，从数字化走向智能化。那么DataOps，则是实现数据中台的一个优良的理念或方法论。 DataOps的概念早在2014年即由Lenny Liebmann提出，2018年DataOps正式被纳入Gartner的数据管理技术成熟度曲线当中，标记着DataOps正式被业界所接收并推广起来。尽管目前在国内仍处于倒退初期，然而DataOps的热度逐年回升，在可预感的将来2-5年内将失去更加宽泛的实际利用。 袋鼠云便是其中的一位探索者。作为全链路数字化技术与服务提供商的袋鼠云，从创建以来便始终深耕大数据畛域。随同着各行各业减速数智化转型的步调逐年放慢，对于数据治理、数据管理等方面的许多问题也逐步露出。 为此，在技术提高和客户数字转型需要的驱动下，袋鼠云打造的一站式大数据开发与治理平台——数栈DTinsight，基于DataOps理念发展数据价值化流程，实现了数据全生命周期的品质监管和数据开发流程标准，为数据治理保驾护航。 响应变动DataOps的核心理念之一就是及时响应需要端的变动。上面是一张很典型的企业数据架构图： 数据从左侧的源零碎流入，中间环节是各类数据处理的工具，例如数据湖、数据仓库或数据集市、AI剖析等，数据通过荡涤、加工、汇总统计、数据治理等过程，最终通过BI、定制化报表、API等工具服务于各类需求方。 企业内的数据架构师或管理者，在定义平台架构时，个别次要思考生产环境下的极致的性能、提早、负载治理等问题，很多计算引擎/数据库都精于此道。但这种架构并没有体现出「响应疾速变动」的能力： 这就像是设计一条公路，在设计时只思考了失常状况下的通行能力，并没有思考事变、堵车、暴雨等各种长期变动，在「上线」之后发现每日疲于应答，并没有晋升太多通行能力（比方只有2个车道的隧道，一个小的剐蹭事变就可能把整条隧道堵住）。企业内的数据平台也会遇到相似的状况，企业内的数据工作者，每天甚至每个小时都要响应这种变动，有时一个简略的SQL变更上线甚至可能要花几天的工夫。 在设计阶段思考各种变动，能够更灵便、更稳固的响应，上面是DataOps视角下的数据架构。 DataOps视角下的数据架构数据架构师在建设伊始就提出如下一些敏捷性的规范，例如： • 工作从实现开发到公布生产，须要在1小时内实现，且对生产环境无影响 • 在公布至生产环境前，及时发现数据谬误 • 重大变更，在1天内实现 同时须要思考一些环境的问题，包含： • 必须保护独立的开发、测试和生产环境，但要在肯定水平上保障其一致性，至多是元数据的一致性 • 能够人工编排，或自动化的实现数据的测试、品质监控以及部署至生产环境 当架构师开始思考数据品质、疾速公布、数据的实时监控等问题时，企业就向DataOps迈进了一步。 DataOps架构的合成与实际讲完了DataOps视角下的数据架构，接下来来讲讲DataOps架构的合成与实际。DataOps具体实际能够合成为如下几个关键点： 多环境的治理DataOps的第一步从「环境治理」开始，个别是指独立的开发、测试和生产环境，每个环境下都能够反对工作的编排、监控和自动化测试。 数栈目前可反对同时对接多套环境，只有网络相通，即可实现一套数栈对多个不同环境的对立对接和对立治理。数栈是通过Console中的「集群」概念来进行不同环境的辨别，不同的集群可灵便对接各类不同的计算引擎，例如各类开源或发行版Hadoop、星环Inceptor、Greenplum、OceanBase，甚至MySQL、Oracle等传统的关系型数据库，如下图所示： 工作公布承接上个步骤的多环境治理，在理论开发过程中，须要进行多个环境之间的工作公布，假如存在开发、测试、生产环境，则须要在多个环境之间进行级联模式的公布，如下图所示： 在这种多环境公布的状况下，数栈可反对三种形式进行公布治理： ● 一键公布 当各个环境网络相通，可应用一套平台对接各个环境，实现「一键公布」。一键公布过程中，仅有肯定权限的用户才能够执行公布动作，晋升生产环境稳定性。与此同时，可主动替换一些要害的环境信息，例如同步工作中的数据源连贯参数、不同环境下的算力配置等。一键公布比拟适宜SaaS或外部云平台的治理形式。 ● 导入/导出式公布 在目前国内接触的绝大多数场景中，客户为了实现更高的安全等级，生产环境会采纳严格的物理隔离。这种场景能够采纳导入导出的形式实现工作的跨环境公布，用户可手动将新增、变更或删除的工作导入至上游环境。 ● Devops公布 某些客户可能曾经洽购或自研了公司级的线上公布工具，此时须要数栈定制化的对接其接口，将相干变更信息由第三方CI工具（例如Jekins）代为执行公布。 代码的版本治理每次进行跨环境的公布时，须要记录每次公布代码的版本，便于前期排查问题。在理论场景中，常常须要进行不同版本间的代码比照、版本回退等操作。 数栈除了反对对代码内容进行比照之外，还反对对工作相干的更多信息进行比照，包含任务调度周期的配置、工作执行参数、环境参数等，并能够「一键回退」至指定的版本。 拜访与权限治理在企业内的多个环境中，个别对生产环境的要求最高，对开发和测试环境绝对宽松。在这种状况下，即须要治理用户在不同环境下的认证或访问信息。实际上为了开发和测试不便，且没有敏感数据，在这2个环节，个别是普通用户都有全副的数据权限，并能够拜访各种工具，但在生产环境中，用户必定只有本人权限范畴内的数据权限。 依据引擎的不同，数栈可反对多种数据权限治理形式，包含： ● Hadoop引擎 以Kerberos为根底的认证平安+以Ranger/LDAP为根底的数据安全。能够反对库、表、字段级别的数据权限管制。同时可反对数据脱敏。 ● JDBC类引擎 局部场景中，客户可能并未采纳Hadoop来建设数据平台，而是采纳一些JDBC类的数据库（例如TiDB、Doris、Greenplum），而数栈自身并不治理JDBC数据库的权限，而是采纳账号绑定的形式来管制，以此辨别不同账号的权限，例如： · 数栈A账号，绑定数据库root账号 · 数栈B账号，绑定数据库admin账号 ● 工作编排、测试与监控 在公布上线至生产后，数栈可将上述各个环节串连起来，用户从开发阶段能够一键公布至测试环境，经测试环境验证后，察看工作实例、数据产出的运行状况，运行无误后可公布至生产环境。 写在最初的话DataOps是一种最佳实际的理念，但目前在国内还处于比拟晚期的阶段，数栈在这方面有过一些实践经验，但还有不少能够优化的内容，比方数据品质的规定也须要跨环境公布、工作代码、工作模板的导出须要反对更多的工作类型等等，期待将来行业内有更多的DataOps的最佳实际能产生。 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack/Taier

作者 | summer 导读：爱番番企业查问会集了全网2亿+企业多维度全方位信息，应用开源全文搜索引擎Elasticsearch（下文简称ES）作为搜寻平台，致力于让用户更快更准的找到所需企业，但怎么能让用户搜寻到称心的合乎预期的后果呢？本文将会讲述爱番番企业查问在检索后果优化方面的实际，冀望与大家一起交换。 全文3943字，预计浏览工夫10分钟。 01 初识数据同步，平台搭建省略，咱们直奔主题，本文中的样例来源于测试录入，仅用于dsl查问语句后果展现。 我：hello ES ，很快乐与你相识，我当初有个需要，须要依据要害信息查问出蕴含该要害信息的企业，用什么比拟适合呢 ？ ES：匹配查问 match 最合适不过了，它是一个高级 全文查问 既能解决全文字段，又能解决准确字段。 我：企业维度好多，我想多个字段进行匹配，应用 match 有些麻烦，有更便捷的形式吗？ ES：能够试试multi\_match， multi\_match默认状况下，它会为每个字段生成一个 match 查问。 我：哇，太好了，我试试。 查到后果了，但后果中有些 name 中没有 " 网讯科技 " 其余字段中能够查到，有些 " 网讯科技 " 没在一起不是间断匹配的，甚至有些数据程序还不一样，这样的后果是咱们想要的吗 ？ 每个平台对后果有本人的要求，有本人的评判规范，不能一概而论，咱们通过用户调研，行为剖析等形式发现用户次要关注以下几点： 查问后果与关键词的匹配度，次要偏重企业名称和法人；冀望能够依据用户关注的条件，查问到相干企业信息；在关键词匹配到的前提下，心愿可能依照企业衰弱状况排列（ 如：经营状态是否失常，注册资本怎么样，是否存在危险等 ）。如何让用户关注的企业被检索进去呢 ？该如何进行优化呢 ？ 02 摸索想要解决问题，先要晓得问题呈现的起因，这样能力针对性的解决，上面让咱们走进es吧。 ES 是一个开源的搜索引擎，建设在一个全文搜索引擎库 Apache Lucene™ 根底之上，全文搜寻次要包含索引创立和索引查问两个局部。 索引创立：文档，将原始文档依照肯定规定分词，创立索引的过程。分词：analysis 即文本剖析，是把全文本转化为一系列单词（ term / token ）的过程，也叫分词；在 es 中通过 analyzer ( 分词器 ) 实现分词，可应用内置分词器也可按需定制分词器。 analyzer ( 分词器 )： 由三局部组成： Character Filter：将文本中 html 标签剔除掉；Tokenizer：依照规定进行分词，在英文中依照空格分词；Token Filter：将切分的单词进行加工，小写，删除 stopwords，减少同义词；会依照规定进行分词，可通过 \_analyze 查问分词状况。 ...

CDH/CDP中开启kerberos后如何拜访HDFS/YARN/HIVESERVER2 等服务的webui在CDH/CDP等大数据平台中，当开启kerberos平安后，如何拜访HDFS/YARN/HIVESERVER2 等服务的webui呢？一起看下相干常识。 问题景象在CDH/CDP等大数据平台中，当开启kerberos平安后，一些常见服务如 HDFS/YARN/HIVESERVER2 的webui， 无法访问，通过chrome浏览器拜访时，报错 HTTP ERROR 403，Problem accessing xxx. Reason: java.lang.IllegalArgumentException。截图如下： 问题起因大数据集群开启kerberos平安认证后，基于http协定拜访常见服务如 hdfs/yarn/hiveserver2 等的webui时，这些服务在服务端大都有专门的参数能够管制是否应用启用 spnego（基于kerberos) 认证，当启用了 spnego 平安认证而客户端浏览器获取不到无效的 kerberos ticket 时，就会报上述谬误。 查看服务端配置，发现服务开启了 "Enable Kerberos Authentication for HTTP Web-Consoles", 截图如下： 通过查看后盾日志，也能确认是用户认证问题；同时在客户端浏览器没有获取到无效的kerberos ticket 时，通过firefox浏览器拜访指标链接，其报错提示信息更加明确地指出了须要认证： 留神：当开启了yarn的”Enable Kerberos Authentication for HTTP Web-Consoles“，而没有开启hdfs的”Enable Kerberos Authentication for HTTP Web-Consoles“时，拜访yarn web ui 的报错略有不同： 问题解决解决形式1能够关掉 Enable Kerberos Authentication for HTTP Web-Consoles （Secure Web UI for this service is disabled even though Kerberos is enabled.）, 如下图所示：（hdfs/yarn都有该选项；hive 须要通过配置高级参数 hive.server2.webui.use.spnego 实现）） ...

一、直播介绍之前的内容，咱们为大家分享了Taier根本介绍、控制台、Web前端架构、数据开发介绍以及Taier任务调度介绍，本期咱们为大家分享Taier工作流的介绍。 本次直播咱们将具体介绍什么是工作流，工作流的意义，工作流的运行逻辑，以及Taier1.3的新性能，通过本次分享，心愿大家能对Taier有更进一步的理解。 二、直播主题Taier工作流的介绍 三、直播工夫工夫：2022年9月28日晚 19:00--20:00（周三） 四、直播地点钉钉技术交换群（30537511）&B站袋鼠云直播间（22920407） https://live.bilibili.com/229... 五、分享嘉宾安陌 袋鼠云Java开发专家 六、开源我的项目地址https://github.com/DTStack/taier https://gitee.com/dtstack_dev... 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack/Taier

明天咱们来和大家聊一聊一个新话题，一个对于企业业务倒退非常要害的货色——指标。 指标建设是掂量企业业务成果的次要根据，本文联合本身实践经验和大家分享指标的设计与加工过程，讲述其根底概念和设计加工办法，以及设计加工过程中的留神点，心愿对感兴趣的同学有所帮忙。 一、指标建设的必要性1、什么是指标指标是主观形容某个事物某个特色的可量化的数字度量，如用户最近30天购买次数，某商品最近30天销售额等。 指标常从多个维度来形容，如某地区的新增用户数、线上线下的新增用户数，维度让指标更加具象与饱满。 2、建设背景大数据时代数字化转型背景下，企业所须要的往往不单单是数据，而是数据背地映射的业务洞察，相比拟数据咱们更加关怀的是其体现的业务价值以及笼罩的业务场景。 宏大的数据只有和业务相结合转化为信息，通过解决出现能力真正体现他们的价值。 指标作为数据计算的后果，是间接反映掂量业务成果的根据，利用在企业的方方面面，如数据报表、剖析平台及日常取数等。 ● 数据报表 它是间接的指标后果查看的载体，作为业务部门的人，可能每月或者每周甚至每天都要输入业务报表，不论是传统的纸质文档，线上的excel还是起初的报表工具，最终目标都是一样，咱们心愿通过报表实现数据驱动业务精益增长的目标。 ● 剖析平台 作为数据计算结果多样化展现的平台，不论是可视化大屏，还是其余一些BI零碎，都是通过数据计算结果的出现，更好地辅助业务理解行业现状。 ● 日常取数 有数据在哪里，便要去哪里拿，取数的过程，往往是基于不同的业务场景，满足不同的业务需要，对数据进行加工计算获取，当然在这过程中，数据计算结果往往须要保障较高的准确性和一致性。 3、建设过程中遇到的问题数据指标作为数据计算的后果，是企业数据价值的直观体现。在业务扩张、指标计算需要的暴增背景下，随之而来的指标治理问题也越来越多： 指标治理不对立：管理机制不对立、扩散治理、反复建设、老本高、费时费力指标口径不统一：同名不同义、同义不同名、计算逻辑复杂多变、开发技术门槛高，过程不可视指标流程不标准：没有对立的流程管制，开发和应用人员拆散，沟通老本高、周期长，后果可信度不高4、解决方案要解决以上问题，帮忙企业建设指标体系，咱们须要从以下三个方面动手： ● 指标平台 建设对立的指标治理平台，集中管理数据指标，积淀指标资产。 ● 指标体系 有一套标准规范的指标搭建方法论，搭建企业级数据指标体系。 ● 流程治理 搭载对立的流程管制机制，全面把控数据指标的生命周期。 如果是平台、流程是根底，那指标内容的搭建便是要害。指标体系的搭建作为整个指标治理的外围，为指标治理提供最松软的根底撑持。 二、指标建设五步法总结以下五个步骤，从0到1搭建指标体系： 1、明确指标搭建指标体系的第一步就是明确搭建指标，大部分企业因为指标不清晰造成指标管理混乱，通过指标体系的搭建，咱们要实现“一个指标、一个口径、一次加工、屡次应用”，做到对立指标口径，缩小反复工作，后果对立输入。 ● 对立要害指标 创立公司级对立的要害指标，帮忙企业通过对立的指标框架来助力业务扩张。 ● 缩小反复工作 为每一个成员提供对立的平台来协同，理解企业整体数据业务状况，缩小数据团队重复性工作和工夫破费。 ● 后果对立输入 针对指标后果，提供一套能将指标和下层利用联合起来的输入形式，施展数据指标最大的价值。 2、需要剖析明确指标之后，咱们开始着手去构建指标体系，在设计指标之前，咱们首先要进行需要剖析。 同一个企业，不同的业务线、不同的部门，甚至是同一部门的不同人员，提出来的指标计算需要都会有所不同。所以在需要剖析的阶段，咱们要做到基于不同行业的业务状况，剖析数据指标需要，正当划分主题，更好地为后续指标设计提供业务撑持。 1）需要调研 ● 主导人 数据分析师，数仓架构师； ● 调研形式 列好提纲，面对面访谈； ● 调研内容 · 指标利用场景调研：指标利用在哪些业务场景中，利用形式有哪些（BI应用、业务人员自行取数、数据门户展示等） · 指标起源调研：指标加工的源数据来源于哪些零碎，数据是否都采集上来，分为哪些业务域、业务过程 · 指标现有状况调研：当初有哪些指标，短少多少，能满足百分之多少的业务场景；指标建设当初遇到的问题是什么；之前的指标加工是否标准，是否须要调整 · 指标需要调研：理解客户须要实现的指标加工范畴 ● 产出 访谈汇总后果与需要收集表。 2）需要剖析 ● 指标 梳理须要加工的指标，指标业务口径，指标更新频率； ● 主导人 数据分析师； ...

 数据仓库的重要特点之一是反映历史变动，所以如何解决维度的变动是维度设计的重要工作之一。迟缓变动维的提出是因为在事实世界中，维度的属性并不是动态的，它会随着工夫的流逝产生迟缓的变动，与数据增长较为疾速的事实表相比，维度变动绝对迟缓。阴齿这个就叫做迟缓变动维。 这里介绍的就是这些维度变动的解决，这边整顿了一下目前支流的迟缓变动维的解决形式。 原样保留或者重写，这种形式实践上都是取最新的值作为维度的最终的取值，每个维度保留一条数据。这种解决形式是最简略的，间接将原零碎的维度同步过去应用就能够，不必做过多的解决。插人新的维度行，每当维度发生变化的时候，插入新增的一行。采纳此种形式，保留历史数据，维度值变动前的事实和过来的维度值关联，维度值变动后的事实和以后的维度值关联。也就是一个维度会存在多行的数据，按时工夫范畴将维度与事实表关联。增加维度列，采纳这种形式，次要是为了将变动前后记录的事实归为变动前的维度或者归为变动后的维度。也就是将产生变动的维度，能够在汇总的时候依照对立分组解决。快照存储,这种形式就是每一个周期定时保留一份数据，与第二点有点想，不过这里会产生很多冗余的数据，当维度里大部分行在周期内，变动频繁的时候，能够采纳。不过依照集体的开发教训，不恨很倡议采纳，具体要依据业务理论状况来抉择。极限存储历史拉链表，这种形式是形式2的优化版，就是当新的维度行与旧的维度行变动前后一致的时候，会合并一条。还有一点个别拉链表的工夫粒度可能晓得天，然而形式2，个别到秒，拉链表也是到秒。其余的与形式2统一。历史拉链表既能满足对历史数据的需要，又能很大水平的节俭存储资源。什么是历史拉链表？历史拉链表是保护了历史状态，以及最新状态数据的一种表。 拉链表存储的数据实际上相当于快照，只不过做了优化，去除了一部分不变的记录而已,通过拉链表能够很不便的还原出拉链时点的客户记录。 拉链表既能满足反馈数据的历史状态，又能够最大水平的节俭存储，进步查问效率。 微型存储维度，微型存储指的就是，将维度中，疾速变动的属性拆分进去，建设新的维度，这个是为了能够解决维度的适度增长导致历史拉链表成果大打折扣的问题，比方维度每几分钟变动一次。属性疾速变动的维度，称为疾速变动魔鬼维度。这个微型维度倡议保留基维度，不便后续数据处理。 当然具体维度须要怎么解决，须要依据业务来，毕竟数据开发是一个很贴近业务的岗位。 须要数据仓库材料能够点击这个支付数据仓库(13)大数据数仓经典最值得浏览书籍举荐 参考资料： 数据仓库(01)什么是数据仓库，数仓有什么特点数据仓库(02)数仓、大数据与传统数据库的区别数据仓库(03)数仓建模之星型模型与维度建模数据仓库(04)基于维度建模的数仓KimBall架构数据仓库(05)数仓Kimball与Inmon架构的比照数据仓库(06)数仓分层设计数据仓库(07)数仓标准设计数据仓库(08)数仓事实表和维度表技术数据仓库(09)数仓迟缓变动维度数据的解决数据仓库(10)数仓拉链表开发实例数据仓库(11)什么是大数据治理，数据治理的范畴是哪些数据仓库(12)数据治理之数仓数据管理实际心得数据仓库(13)大数据数仓经典最值得浏览书籍举荐

作者：旋宇，淘菜菜数据研发 前言：阿里淘菜菜（简称TCC）主营社区团购，其在阿里至多历经6年工夫，为了更好反对业务倒退，淘菜菜也在一直演进其技术架构。2020年淘菜菜开始与Hologres单干，历经2次大的架构降级，从传统多组件的架构降级为当初稳固的高可用实时数仓2.0，承载上千万RPS写入、几百T数据存储和秒级查问响应。在此单干过程中，淘菜菜技术团队一直积淀出实时数仓场景下的最佳实际、开发实际、开发标准等，基于此背景，咱们将会单干推出系列文章，介绍淘菜菜基于Hologres搭建实时数仓的最佳实际，内容将会包含架构降级、场景实际、容灾实际以及最近业界比较关心的老本治理等，冀望与更多的企业互通有无，在数仓建设上更加简略、不便、高效。 本期咱们将会带来系列文章第一篇：淘菜菜技术架构的前世今生--技术架构降级之路。 淘菜菜业务简介阿里淘菜菜(简称TCC)事业部的前身是盒马优选及批发通，2021年初合并成立了淘菜菜事业部，次要做社区团购，和多多买菜、美团优选业务模式统一，主营生鲜和日销品，采纳次日达的配送形式为用户提供服务。2022年开始和淘宝深度单干，作为淘宝生鲜和日销品类目标补充。目前淘菜菜属于稳固倒退阶段，微信、淘宝、淘特、支付宝等多渠道入口，日均用户访问量上千万，数据量约有几百T。 倒退历程：从数据库到高可用实时数仓为了反对淘菜菜丰盛的业务需要，其背地的技术倒退历经了最后的批发通原始数据库架构、批发通传统lambda架构、Hologres实时数仓、Hologres高可用实时数仓这4个阶段。 阶段1：16年之前原始架构- jstorm阶段该阶段为实时数仓的初期建设，次要用于批发通团队的实时作战大屏，以及外围数据产品的报表看板等。技术计划采纳的jstrom，有专门的实时团队同学反对，实时工作数10个以内，实时计算的资源在3000+CU。 阶段2：16-20年传统架构 -FlinkSQL阶段16年之后，批发通业务开始规模化增长，因而业务场景变得更加丰盛，包含实时大屏、实时营销流动剖析、渠道实时剖析等。这个阶段次要基于Flink SQL倒退，同时离线开发同学缓缓开始退出，和实时团队同学配合进行实时需要反对。直到到19年B系研发同学开始独立反对实时数据体系的建设，这个期间实时工作数快速增长到500+。资源应用也比第一个阶段回升30%。 阶段3：20年实时数仓 - Flink+Hologres阶段随着业务的疾速倒退，实时数仓的建设越来越臃肿，也开始呈现一些开发和运维问题。而过后Hologres也开始在团体内大面积推广，于是咱们开始思考用一套新的计划解决老架构存在的问题。因而这个阶段开始基于Flink+Hologres进行实时架构降级。 在这个阶段，批发通和盒马优选合并成淘菜菜团队。面对日益增长的数据，技术上次要要解决的问题就是实时开发提效，谋求高效率、高灵便，以此来满足淘菜菜所有小二实时&离线数据的查问需要，外围利用场景包含交易实时多维分析，物流供应链实时服务、指标核心自助剖析和离线报表减速等。 咱们用了一年的工夫（从20年9月到21年9月）实现了架构降级，通过新架构缩短了实时处理链路，进步数据处理效率，让实时数仓变得更加高效快捷。 阶段4：21年高可用实时数仓-Flink+Hologres读写拆散部署21年架构降级实现后，在新的阶段，咱们的外围指标就是晋升新架构的稳定性。同时业务倒退也逐步趋于稳定，除了惯例场景的反对，也开始参加双11、双12等大促节日，因而老本的治理也开始提上日程，咱们冀望可能用最简略的架构，起码的资源撑持所有的场景。 在高可用稳定性方面，咱们应用写链路的主备链路，应用层应用Hologres多子实例共享存储的部署形式，主实例用于写，不同子实例用于不同场景的查问，这样做可能十分好的做到读写拆散、资源隔离以及开发生产隔离。 在老本治理侧，咱们次要采取了将闲置实时工作及时治理、Hologres表存储优化等伎俩，21年共计节约200w+资源。 目前新的架构在淘菜菜业务稳固运行中，在本文中咱们将会介绍为什么要进行架构降级，以及架构降级后咱们遇见的挑战和对应的解决方案，以帮忙大家更简略高效的建设实时数仓。 淘菜菜实时数仓的典型利用场景随着业务的倒退和合并，咱们总结了淘菜菜实时数仓须要反对的业务场景和背地须要的技术能力。 1、高管实时播报场景阐明：淘菜菜外围数据实时查问，并且每日须要播报到高管钉钉群里，帮助管理层第一工夫做出业务决策。 特点：高保障、数据低提早、指标疾速勘误、问题疾速排查并复原 须要的技术能力：离线实时存储一体、列式更新、多表关联、即席简单查问 2、物流实时作业场景阐明：供物流小二应用，联合出入库、仓库作业等实时数据帮助小二日常物流订单剖析、订单派送等。 特点：高稳固、继续的在线服务查问能力，长周期实时数据生产能力 须要的技术能力：高可用，可疾速主备切换、高效问题排查、物化视图 3、指标核心&自助剖析场景阐明：配置外围指标和罕用维度的查问，自助生成多维报表，反对小二多维数据疾速看数，不便小二疾速做经营动作 特点：多维简单查问、大量Distinct去重、主动生成大SQL 须要的技术能力：实时多维OLAP能力，大表关联能力 4、增长平台(试验平台&圈选平台)场景阐明：为拉新和留存提供的数据增长平台，次要是提供不同试验的多维分析，同时也能反对标签圈选的能力，从而生成人群画像，帮忙业务精细化经营。 特点：多维分析、大数据量穿插(7亿多数据量表关联) 须要的技术能力：多维OLAP灵便查问 5、小二日常看数报表(数来宝)场景阐明：提供给行业、营销、用户、渠道、物流等小二日常看报表的能力，须要提供历史和实时数据的查问，同时报表可能疾速交付，满足小二的个性化剖析 特点：基于已有的基数数据可能疾速交付，灵便查问，缩短交付周期 须要的能力：表面减速、多维OLAP 回顾：传统架构及遇到的问题以下是20年架构降级之前的架构图： 能够看到为了反对好业务，整个架构还是比拟臃肿，采纳多套组件反对不同的场景，架构冗余，组件简单，随之而来带来的问题就是： 1、数据不统一： 数据团队和技术团队实时计划不统一，从底层音讯流的获取，到两头加工，再到最初的利用，别离用的自有计划，源、解决流程和逻辑不统一，经常出现数据不统一问题，须要破费较多人力去排查问题。 2、开发效率低下： 多维数据分析以及惯例开发模式须要别离进行开发，导致实时工作数变多，代码调试、数据测试等都比拟耗时，特地是数据测试，还须要写到对应的db中，而后进行核查，效率低下。 3、运维老本高： 1）工作排查耗时长：实时工作链路长，局部应用层ADS的设计达到5层，加上ODS和DWD总共达到7+以上的档次，再加上有些工作自身逻辑简单，导致整个计算链路十分长。另外因为实时自身的State不可见，在问题排查的时候十分艰难，均匀一个问题定位到解决就须要半天以上，重大影响线上查问效率。2）长周期回滚难：因为上游采纳的TT中间件（Datahub），只能回滚3日数据，对于长周期去重指标回滚就会有问题，同时为了保证数据一致性，须要另外将离线数据退出能力进行回滚。在压测的时候，上游的数据量不够，无奈达到压测预期，还须要额定造离线数据。4、实时资源节约： 有些实时数据并不是高频应用场景，比方大促预热期的多维实时蓄水成果监控跟踪，日常根本没查问，仅在大促前两天须要应用，日常的实时计算就会导致节约计算资源。 20年业务合并后，数据量变得更多，业务场景更加简单，传统架构无奈再持续满足需要，因而咱们迫切希望可能将现架构进行替换，以此来撑持更多的业务。恰逢过后Hologres在团体内大面积推广应用，因而咱们便开始了新架构的降级之路。 第一次架构降级：传统架构替换为Flink+Hologres实时数仓1.0面向公共层的对立数仓设计引入Hologres后，新架构如下： 1、数据源对立通过TT（Datahub）来对立数据源的入口。因为原架构技术、算法都本人创立数据源，比方交易，技术会用metaq、notify等各种音讯队列，而数据团队通常会采纳TT获取MySQL Binlog。ODS源不统一，导致数据统计的时候存在一些差别，因而首先就是要进行数据源对立，保障所有整个事业部的数据源头对立。 2、存储对立：CDM/ADS层降级为HologresCDM和ADS层对立用Hologres替换原架构的各种组件，其中： 1）CDM设计为Hologres行存表 上游能够间接订阅Hologres Binlog作为输出应用问题排查间接查问Hologres即可，不必再云存储到MaxCompute后解析生命周期可设置多天，保留更久的数据，便于长周期指标计算和压测2）ADS采纳Hologres行存和列存联合对接利用查问 简化代码档次，明细数据或者轻度汇总数据间接写入Hologres，而后前端调用时实时计算，保障用的时候才耗费资源，防止日常无人看的时候的计算资源节约对于高并发点查场景采纳行存模式，保障在线服务的高并发查问对于保障等级不同的利用进行实例隔离，如营销流动剖析等利用独立申请实例。3、计算降级1）实时计算降级 不同的实时工作进行独自分隔，互相计算不受影响，别离更新同一个表的不同字段。 运维独立，高效开发和运维；单个提早不会影响其余数据前端调用简略，只须要从一个表中就能够获取所有数据2）流批一体，计算对立、存储对立 实时计算实现后，间接通过同步工作写入MaxCompute上应用，不必再离线反复计算。离线、实时数据雷同代码在Flink引擎上采纳流和批的形式别离执行，当实时数据呈现问题时，能够用离线数据间接笼罩holo的历史分区。保障了口径统一、存储统一、服务统一。4、应用服务对立降级为Hologres1）OLAP多维分析报表疾速搭建 基于Hologres列存实时宽表，用FBI疾速搭建多维的数据报表。比方：将交易明细间接存储到Hologres中，对应行业、品牌、区域、商家、商品等各种维度的随便穿插能够实现疾速的开发上线。 2）指标核心&自助剖析平台初步搭建 与技术单干建设指标核心，通过可视化的配置化形式进行指标的开发，保障指标口径的一致性，且反对业务自主抉择须要看的指标和维度。 遇到的挑战及应答计划挑战1：Hologres随便应用带来的性能瓶颈Hologres初期估算只有400cu，无脑应用产生性能瓶颈，在双11前的B系压测中就呈现Hologres CPU使用率间接继续到100%，从而导致Hologres宕机的状况；另外Hologres的应用也没有几年，业务对于大促保障还不太熟悉。 应答计划如下： 首先遇到瓶颈的时候，通过文档及Hologres技术同学的调研，思考理论数据存储量、关联条件、写入QPS/并发等，思考对数据的散布Table Group和Shard count进行优化。其次，思考数据表自身优化计划，对多级索引进行优化，调整适合的表构造。最初，散布和表构造自身做到极致优化的时候，思考到还是可能存在简单SQL高并发的时候，会对整个数据库造成压力，对于重要的数据利用就进行实例隔离。挑战2：ETL逻辑后置带来的指标口径一致性问题以往传统架构根本是先通过Flink计算好各个粒度指标之后，写入到对应的MySQL/HBase等数据库中，而后配置数据服务查问。而当初通过Flink计算的都是明细或者轻度汇总的数据，不会算出最终的指标，有一些逻辑片段后置到前端编写，在利用调用的时候实时计算，那么逻辑大量数据写到汇总层后，如何治理这些指标口径，保障指标计算逻辑的一致性呢？ ...

7月28日，在袋鼠云2022产品发布会上，袋鼠云技术负责人思枢正式发表旗下产品「大数据根底平台EasyMR」公布。 EasyMR是袋鼠云自研的大数据根底平台，提供Hadoop、Hive、Spark、Trino、HBase、Kafka等组件，齐全兼容Apache开源生态；反对企业级平安管控，一键开启LDAP+Kerberos+Ranger认证权限体系；提供一站式运维治理平台，帮忙企业疾速构建大数据平台，升高运维老本。 联合袋鼠云在数字化畛域多年的寸积铢累，此次全新公布的大数据根底平台EasyMR紧跟开源生态的先进技术，不仅能够帮忙客户轻松应答海量数据的采集、存储、计算、剖析开掘和数据安全等利用场景，并且对于智能运维的部署、降级、扩缩容、监控等进行全方位反对，真正做到成为企业便捷、智能、高效的“数据底座”。 六大个性打造国产大数据根底平台不同于十年前的离奇，当初大家曾经齐全习惯本人身处于“大数据时代”这件事件，所有人都可能深切地感触到大数据对于生存带来的各种扭转和便当，数据暴发的时代推动着每个集体、企业、行业，甚至是国家往前走。 以后国际形势风云变幻，中美双边关系的割裂，国家对于信创国产化的大力支持，给国内的大数据行业带来微小冲击的同时，也带来了全新时机。 数据根底平台作为所有的根底和底座，天然成为国产代替的重中之重。只有真正领有了自主可控的平台建设能力，能力逐渐建设基于本人的 IT 底层架构和规范，造成自有凋谢生态。 EasyMR就是这样一款自主研发、齐全可控的，致力于助力企业信息化智慧转型的“企业数据底座”。 上面通过形容EasyMR的次要个性，来具体说说，EasyMR是如何帮忙企业实现智能的？ ● 界面化集群运维 Hadoop集群、大数据平台在日常运维中波及到的节点扩容缩容、组件进行启动、服务滚动重启、服务参数批改、版本升级与回滚等多种运维操作，通过逻辑化、流程化的产品界面展示，不便运维人员操作和监控，进步运维效率。 ● 自动化部署 EasyMR通过规范化的步骤和参数约定制作出产品安装包，公布包中的Schema文件中配置了安装包中所有的服务，蕴含各服务的配置参数、健康检查参数，服务之间的依赖关系等。产品部署时可依据Schema中的相干配置实现一键全自动化部署。 ● 仪表盘集群监控 通过集成开源的Promethus和Grafana，实现对集群、服务、节点的外围参数监控，并通过灵便形象的仪表盘进行数据展示。蕴含CPU占用率，RAM使用率、磁盘空间、IO读写速率等外围参数进行监控，实时把握集群、服务、节点的运行状态，升高运维故障率。同时，反对用户自建仪表盘及监控项，实现自定义监控项。 ● 实时告警 反对实时监控集群中各组件服务的运行指标，如CPU、内存、磁盘、读写IO等，并反对短信、钉钉、邮件告警通道配置，集成多种第三方音讯插件。当集群服务出现异常时，可触发告警条件，零碎将及时告诉接管人。 ● 强扩展性 通过自研的Easyagent Server形象出七大REST接口，装置、启动、进行、更新、配置批改、卸载、执行等与下层利用进行交互，可使agent类别和性能可轻松有限扩大。 ● 平安稳固 数据安全、产品安全是大数据产品须要重点思考的问题。EasyMR在产品设计中过滤掉rm、drop等命令行，避免对数据库的误操作，通过更加平安的形式执行相干命令。同时提供服务的滚动重启、产品的断电重启，解决运维时服务不进行运行的场景并节俭运维工夫。 丰盛的大数据组件夯实数据基座EasyMR反对Hadoop2.8.5、Hadoop3.2.1大数据集群搭建，反对丰盛的大数据组件，用户能够依据业务须要进行组件的抉择。 那么，EasyMR具体反对那些大数据组件呢？ ● Yarn 版本反对： · Yarn 反对Hadoop 2.8.5、3.2.1 次要性能为Hadoop的资源调度器，负责管理整个Hadoop集群的资源（CPU和内存）治理和调度。 ● Hdfs 版本反对： · Hdfs 反对Hadoop 2.8.5、3.2.1 Hdfs即Hadoop 分布式文件系统，是Hadoop的三大根底组件之一，次要是解决大数据场景下数据的增、删、改、查、文件切片等性能。 ● Flink 版本反对： · Flink 1.12 面向数据流解决和批量数据处理的可分布式的开源计算框架。 ● Spark 版本反对： · Spark 2.4.8 基于内存的新一代分布式开源大数据框架，反对离线，实时计算，也反对 SQL 语法以及机器学习的解决。 EasyMR对开源组件的SQL的DDL能力进行了加强，反对Add Column语法。 ● Hive ...

一、直播介绍前几期，咱们为大家分享了ChunJun的数据还原、Hive事务表及传输模块的一些内容，本期咱们为大家分享ChunJun类加载原理与实现。 本次直播咱们将从Java 类加载器解决类抵触根本思维、Flink 类加载器隔离的计划、ChunJun如何实现类加载器隔离及问题排查等方面为大家进行介绍，通过本次分享，心愿大家能对类加载相干内容有更进一步的理解。 二、直播主题ChunJun类加载原理与实现 三、直播工夫工夫：2022年9月21日晚 19:00--20:00（周三） 四、直播地点钉钉技术交换群（30537511）&B站袋鼠云直播间（22920407） https://live.bilibili.com/229... 五、分享嘉宾无倦 袋鼠云大数据开发专家 六、开源我的项目地址https://github.com/DTStack/ch... https://gitee.com/dtstack_dev... 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack/Taier

数据平台发展史-从数据仓库数据湖到数据湖仓做数据的同学常常听到一些数据相干的术语，常见的包含数据仓库，逻辑数据仓库，数据湖，数据湖仓/湖仓一体，数据网格 data mesh,数据编织 data fabric等. 笔者在这里回顾了下数据平台的发展史，也介绍和比照了下常见的概念，次要包含数据仓库，数据湖和数据湖仓，心愿大家有所播种。 回顾数据平台倒退历史，梳理数据平台变迁脉络，更全面精确地了解数据仓库数据湖和数据湖仓！ 1 数据平台概述所谓数据平台，次要是指数据分析平台，其生产（剖析）外部和内部其它系统生成的各种原始数据（比方券商柜台零碎产生的各种交易流水数据，内部行情数据等），对这些数据进行各种剖析开掘以生成衍生数据，从而反对企业进行数据驱动的决策：An analytics platform is a unified solution that combines technologies to meet enterprise needs across the end-to-end analytics lifecycle from data storage, data management, data preparation, and other data analytics processes. 数据分析平台既能够部署在本地，也能够部署在云端，其典型特色有： 数据分析平台，须要上游零碎（外部或内部）提供原始数据；- 数据分析平台，会通过剖析生成各种后果数据（衍生数据）；数据分析平台，生成的后果数据，个别次要服务于企业本身，反对企业进行数据驱动的决策，从而助力企业更好地经营：为顾客提供更好的服务，企业本身降本增效更好地经营，或发现新的商业洞察从而反对新的商业翻新和新的业务增长点等（foster innovation）；数据分析平台，生成的后果数据，也能够服务于内部客户: 通过数据变现，为企业发明新的业务模式和利润增长点；（各种提供数据服务的公司）数据分析平台，反对各种类型的数据分析利用，包含BI也包含AI; 数据（剖析）平台，常见的相干术语有：数据仓库，数据湖，数据湖仓，数据中台，逻辑数仓 Logical data warehouse，数据编织 Data fabric，Data mesh 等： 数据仓库，数据湖，数据湖仓/湖仓一体：是数据平台次要的撑持载体，是以后应用最宽泛的术语，其中数据湖仓也称湖仓一体，实质是数据湖的2.0版本；国内也常常讲数据中台：数据中台在数据仓库数据湖数据湖仓的根底上，强调了将数据进行服务化API化，从而反对更疾速敏捷地开发各种新型数据利用；数据编织 Data fabric，数据网格 Data mesh：是随着企业云化迁徙以及微服务架构衰亡，逐步流行起来的新的术语，在治理数据时更强调数据人造分布式的个性和数据产品的理念（数据是一种产品，来自不同服务由不同团队治理）；须要留神的是，数据仓库，数据湖与数据湖仓尽管有着显著的学术定义上的区别，然而在业界很多场景下咱们并不严格辨别三者；本次分享，咱们次要关注数据仓库数据湖和数据湖仓 2 数据平台发展史-从数据仓库数据湖到数据湖仓整个数据平台的发展史，其实能够用一句话简略概括下：数据平台的倒退，是随着企业信息化和数字化的逐步推动，从数据库，数据仓库，数据湖到数据湖仓逐步演进的： 在企业信息化晚期，建设了各种线上业务零碎如 ERP/CRM/OA等，这些业务零碎通过数据库积淀了多种数据，其数据库个别采纳的是 OLTP的关系型数据库；随着信息技术的进一步倒退，企业逐步意识到数据具备价值，并能够通过各种分析方法开掘其中的价值，反对企业的管理决策，于是逐步有了数据仓库平台（数据仓库诞生于数据库时代）；随着大数据时代的到来，数据在品种和体量上都有了爆炸式的增长，数据的存储和剖析解决技术也有了进一步倒退，为更好地开掘数据中的价值，呈现了数据湖平台（数据湖脱胎于大数据时代，有着很强的开源和凋谢的基因）；随着企业向数字驱动进一步迈进，对数据的存储和剖析解决有了更高的要求，呈现了交融数据仓库和数据湖各自特点的新型数据平台，其实质是数据湖2.0，也被称为数据湖仓； 2.1 数据仓库数据仓库(Data Warehouse)，是由被誉为寰球数据仓库之父的 W.H.Inmon 于1990年提出的，其绝对学术的解释：数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrated）、绝对稳固的（Non-Volatile）、反映历史变动的（Time Variant）数据汇合，用于反对管理决策和信息的全局共享； 所谓主题：是指用户应用数据仓库进行决策时所关怀的重点方面，如：支出、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务撑持零碎那样是依照业务性能进行组织的；所谓集成：是指数据仓库中的信息不是从各个业务零碎中简略抽取进去的，而是通过一系列加工、整顿和汇总的过程，因而数据仓库中的信息是对于整个企业的统一的全局信息。所谓随工夫变动：是指数据仓库内的信息并不只是反映企业以后的状态，而是记录了从过来某一时点到以后各个阶段的信息。通过这些信息，能够对企业的倒退历程和将来趋势做出定量分析和预测；之所以应用数据仓库而不是前台线上业务零碎的OLTP数据库进行BI等数据分析，一个重要的原始是OLTP只能应答简略的关联查问，撑持根本的和日常的事务处理，不实用数据的多维度剖析；而数仓底层个别是善于多维分析的OLAP数据库（还有一个起因是数据分析属于后盾零碎，不能影响前台线上业务零碎的性能） 数据仓库个别具备以下特点： 数仓强调数据建模，须要依据畛域常识依照分层建模实践，进行具体的模型设计；数据由内部零碎进入数仓时，须要通过荡涤转化后加载进数据仓库，即 ETL；数据须要ETL后进入数仓，实质是因为内部零碎中的数据模型跟数仓中的数据模型是不同的（内部OLTP零碎个别是依照范式设计的数据库中的表，而数仓个别是OLAP中反范式的大宽表）；数仓模型的建设个别耗时耗力，但数仓模型一旦创立结束，相对来说不会轻易做出扭转；ETL的实质是 SCHEMA ON WRITE，即数据进入数仓时经由 ETL 实现了荡涤和转换，所以数仓中的数据品质较高；数仓分层比拟经典的有：ODS,DWD,DWS,ADS等；数仓是商业智能BI的根底，次要基于建好的数仓模型，通过剖析答复固定的已知问题，从而撑持BI的报表和大屏等；数仓个别内置存储系统，且不对外间接裸露存储系统接口（不容许内部零碎间接拜访数仓底层存储系统中的数据比方文件），而是将数据抽象的表或视图的形式，通过提供数据进出的服务接口对外提供拜访（最常见的数据拜访形式是SQL，有的数仓对加载数据也提供了RESTFUL接口或专用的LOAD/COPY等命令）；数据仓库通过形象数据拜访接口/权限治理/数据自身，带来了肯定的封闭性，但换取了更高的性能（无论是存储还是计算）、闭环的平安体系、数据治理的能力等，能够应答平安/合规等企业级要求;数仓内置存储系统但不对外间接裸露存储系统接口，而是提供数据进出的服务接口，带来了以下优缺点： ...

第1章 Maxwell概述1.1 Maxwell 定义Maxwell 是由美国 Zendesk 开源，用 Java 编写的 MySQL 实时抓取软件。 实时读取 MySQL 二进制日志 Binlog，并生成 JSON 格局的音讯，作为生产者发送给 Kafka，Kinesis、 RabbitMQ、Redis、Google Cloud Pub/Sub、文件或其它平台的应用程序。 官网地址：http://maxwells-daemon.io/ 1.2 Maxwell 工作原理1.2.1 MySQL 主从复制过程➢ Master 主库将扭转记录，写到二进制日志(binary log)中 ➢ Slave 从库向 mysql master 发送 dump 协定，将 master 主库的 binary log events 拷贝 到它的中继日志(relay log)； ➢ Slave 从库读取并重做中继日志中的事件，将扭转的数据同步到本人的数据库。 1.2.2 Maxwell 的工作原理Maxwell 的工作原理很简略，就是把本人伪装成 MySQL 的一个 slave，而后以 slave的身份伪装从 MySQL(master)复制数据。 1.2.3 MySQL 的 binlog(1) 什么是 binlogMySQL 的二进制日志能够说 MySQL 最重要的日志了，它记录了所有的 DDL 和 DML(除了数据查问语句)语句，以事件模式记录，还蕴含语句所执行的耗费的工夫，MySQL 的二进制日志是事务平安型的。 ...

摘要：本文整顿自阿里云开源大数据高级开发工程师杨庆苇在7月17日阿里云数据湖技术专场交流会的分享。本篇内容次要分为两个局部： 数据湖元数据仓库介绍阿里云DLF数据湖治理与优化点击查看直播回放 数据湖元数据仓库介绍数据湖的实际过程中，咱们面临了诸多挑战： 第一，数据难以辨认和查找。数据湖内存在大量未被无效辨认的数据，可能是历史遗留或未被治理的数据，比方通过文件拷贝上传或其余工具引擎写入湖内的数据。其次，传统元数据服务里不足无效的检索服务，数据增长到肯定规模时，很难从大量元数据中搜寻和定位到特定场景下的数据。 第二，数据资产治理能力弱，湖上不足无效的数据资产剖析和优化工具，难以精细化把握库、表分区级别的数据明细。对 schema 维度存储分层计划落地艰难，数据冷热难以分别，无奈在库、表分区维度实现分层。 第三，湖格局优化不足零碎的解决方案。比方小文件合并操作须要用户对湖格局有肯定的理解，能被动发现局部 schema 存在不合理的小文件，且利用计算引擎运行小文件合并工作，存在肯定的应用门槛。此外，须要用户可能辨认有效的历史数据以对其进行清理。 为了解决数据湖实际过程中遇到的挑战，综合湖上数据特点以及计算引擎特点，阿里云提出了基于元仓数据底座，以云原生资源池的海量计算能力为根底，联合管控的在线服务能力，为用户提供全托管的湖治理和优化的解决方案。 数据湖元数据仓库架构元仓组成湖上元数据以及剖析和计算数据，为湖治理和优化提供了参考指标。通过数据采集、ETL、数据分析、计算等过程，将湖上散布在各处的数据进行整合，提取出有意义的指标，构建出剖析库、指标库和索引库，为下层利用提供数据撑持。 上图右侧是云原生计算池，通过 Spark 引擎利用云上的可伸缩资源运行 Analyze、Indexing、Compaction、Tiering 等剖析和优化工作，并实时将计算结果写回元仓，参加指标库与索引库的建设，丰盛和扩大元仓的指标资产，如在计算池内运行 stats 工作、获取表行数大小等指标，并回写到元仓指标库，用户可在第一工夫查看表的根底信息，并以此为参考做数据品质剖析等操作。 管控层提供用了在线服务能力，如在线目录、检索服务、指标服务等，优化引擎负责剖析元仓上的指标，并根据规定生成优化工作提交给云原生计算池进行计算。在此之上延长出了很多湖治理优化的能力： ①元数据能力：解决了数据难以辨认和操作的问题。比方针对元数据检索，通过建设检索库，疾速搜寻元数据以及相干的 schema 明细。元数据发现通过云原生池计算运行工作提取元数据信息，无效辨认湖内未知数据。 ②存储优化能力：解决了数据资产治理能力弱的痛点。比方存储统计分析，通过元仓的指标库剖析库、表分区级别的数据明细、冷热分层，通过指标库提供的表分区，最近拜访工夫、拜访频率、冷热指标对表分区主动分层。 ③查问优化能力：如小文件合并，通过指标库提取出小文件表和分区信息，依据规定在云原生资源池上运行小文件合并工作。此为全托管过程，用户侧无感知。 ④湖格局治理优化：实现了元数据减速和主动优化。 以上计划解决了数据湖治理与优化的局部问题，帮忙用户更好地应用和治理数据湖。 数据湖元数据仓库建设湖上元仓的原始数据由三类数据形成： ①存储数据：文件级别的OSS存储数据信息，包含大小、存储门路、存储类型、最近更新工夫等，均来自存储拜访日志和明细清单，这些根底数据形成存储属性的元数据，是剖析和治理对象存储的根底。 ②元数据：形容目录、库、表、分区、函数等的数据，包含索引、属性、存储以及 stats的统计数据。次要来自于引擎元数据服务存储以及 stats的计算裁减，是大表治理、小文件合并等优化操作的根底数据。 ③引擎行为数据：包含血统数据、引擎工作执行数据，比方文件大小、文件数、工作上下游依赖信息数据。这些数据在引擎计算时产生，是建设数据地图、生命周期治理的根底数据。 以上数据通过日志服务生产、Spark 批工作、离线同步、Spark Structured Streaming、流工作实时生产等形式集成到元仓，作为元仓的原始数据。元仓抉择 Hologres 作为存储库，因为Hologres对于海量数据的实时写入、实时更新、实时剖析能提供较好的反对。 对于实时性要求不高，但有较大数据量剖析的场景，比方库表存储剖析，能够通过 MaxCompute 离线数据加工的形式，将原始数据转换成明细数据，并提供离线指标给管控层；对于有较高实时性要求的场景，比方获取表分区行数、执行更新工夫等，通过 Hologres 实时剖析能力，实时计算出剖析指标，并提供给 DLF 管控。 元仓蕴含了实时和离线场景，为数据湖治理和优化提供了稳固、高质量的数据根底。 阿里云DLF数据湖治理与优化元数据检索元数据检索解决了数据湖上数据难以查找的痛点。次要提供了两种搜寻形式，一是全文检索，通过对元数据所有列属性建设索引，满足对任意单词的搜寻都能在毫秒级别内做出响应；二是提供了多列准确查问，满足在特定条件场景下的搜寻，比方按库名、表名、列名、Location地址、创立工夫、最初批改工夫等非凡属性准确匹配搜寻。 索引库抉择了阿里云Elasticsearch计划。 ES 是实时分布式的搜寻与剖析引擎，能够近乎准实时地存储、查问和剖析超大数据集，非常适合元数据的实时搜寻场景。为了达到搜寻后果秒级提早的成果，咱们选用 Spark Streaming 流技术，实时同步和解析引擎生产的 DML 日志写入 ES 库。 但生产日志存在着两个人造的问题：一是音讯的程序性，无奈保障程序产生的 DML 事件能被程序地生产并写入 ES 库；二是音讯的可靠性，日志服务无奈保障集群日志可能百分百被捕获并写入到 hub。 为了解决上述痛点，一方面会通过音讯内的最近更新工夫做判断，逻辑上保障了音讯的程序性；另一方面，通过每日的离线工作同步元数据库做索引弥补，保障了每日元数据信息的可靠性。通过流技术、离线弥补技术、ES检索能力，实现了湖内从大量元数据中疾速搜寻和定位的能力。 数据资产剖析剖析维度： ...

大数据问题排查系列 - 开启 Kerberos 平安的大数据环境中，Yarn Container 启动失败导致 spark/hive 作业失败 前言大家好，我是明哥！ 最近在若干个不同客户现场，都遇到了大数据集群中开启 Kerberos 后，spark/hive 作业提交到YARN 后，因 YARN Container 启动失败作业无奈执行的状况，在此总结下背地的知识点，跟大家分享下，心愿大家有所播种。 1 问题1问题景象某客户现场，大数据集群中开启了 kerberos 平安认证，提交 hive on mr/hive on spark 工作给 yarn 后执行失败，查看 yarn web ui 可见报错信息： Application xxx failed 2 times due to AM container for xxx exited with exitCode -1000......main : run as user is hs_cicmain : requested yarn user is hs_cicUser hs_cic not found Failing the application. 2 问题2问题景象某客户现场，大数据集群中开启了 kerberos 平安认证，提交 spark on hive 工作给 yarn 后执行失败，查看 yarn web ui 可见报错信息： ...

8月27日，ChunJun社区与OceanBase社区联结组织的开源线下Meetup胜利举办，会上重磅公布了「OceanBase&ChunJun：构建一体化数据集成计划」。 这是OceanBase&ChunJun联结解决方案的首次公布，将针对分库分表的实时数据集成、跨集群/租户的数据集成、不同数据源的实时数据集成、日志类型数据的全增量一体化解决等诸多场景，提供高牢靠数据集成解决方案。 上面为大家带来具体介绍，欢送分享给更多的开发者和爱好者独特学习、探讨。 课件获取： 关注公众号“ChunJun”，后盾私信“Meetup”取得分享课件 视频回看： https://www.bilibili.com/vide... ChunJun&OceanBase是什么ChunJun：一款稳固、高效、易用的数据集成框架ChunJun 是一款高效、稳固、易用的数据集成框架，目前基于Apache Flink 实时计算引擎实现批流一体的数据读取和写入。 ChunJun的外围能力• 多数据源：目前已反对30+数据源，涵盖了各类数据库、文件系统等 •灵便的工作运行模式：反对开箱即用的local模式运行，也反对flink standalone、yarn、k8s等模式；反对Taier、DolphinScheduler、Dlinky等大数据调度平台 • 数据还原：反对 DML 和 DDL 同步，能够最大水平保障源端和指标端的数据和构造对立 • 断点续传：依靠Flink的Checkpoint机制，能够从失败的位点重试 • 速率管制：反对多种分片形式，用户可依据本身业务调整分片逻辑；反对调整读取和写入的并发度，管制每秒读取的数据量 • 脏数据管理：反对多种形式存储脏数据，管制脏数据生命周期，并提供统计数据 OceanBase：企业级开源分布式 HTAP数据库企业级开源分布式 HTAP（Hybrid Transaction/Analytical Processing）数据库，具备原生分布式架构，反对金融级高可用、通明程度扩大、分布式事务、多租户和语法兼容等企业级个性。 OceanBase的外围能力• 高可用：基于 Paxos 协定，强一致性；多数正本故障，数据不丢，服务不停；RPO=0; RTO<30s •高扩大：在线进行程度扩、缩容；主动实现负载平衡 • 低成本：不依赖高端硬件，降低成本；极致的压缩比，节省成本 • HTAP：一套计算引擎同时反对混合负载；一套数据库，读写拆散 • 高兼容：兼容 MySQL 协定与语法；升高业务革新迁徙老本 • 多租户：一套环境独立运行多套业务；保障租户数据安全 ChunJun OceanBase Connector 实现OceanBase CDCOceanBase作为分布式数据库，日志信息散布在集群当中不同的机器上，须要有一个工具把这些日志信息进行汇总，拿到正确、残缺的日志信息。 OceanBase社区版利用CDC 组件架构进行这项工作，它次要是通过oblogproxy来提供日志拉取的服务，如果想集成OceanBase增量数据的解决，能够在本人的业务利用中去集成oblogclient来进行解决，目前已对接了ChunJun、Flink CDC、Cloud Canal等数据集成框架。 OceanBase 社区版 CDC 组件架构 ChunJun Connectors 的工作模式ChunJun中的读取和写入次要是通过Connector中的一些构造和模块来实现的，蕴含RDB、CDC 、NoSQL、MQ、File 等。 • RDB Connectors：基于 JDBC Connector，通过轮询反对了源表蕴含自增列且增量数据只有 insert 操作时的全增量一体化读取及写入。 ...

download：体系课大数据工程师2022版2.0升级版数据异构简略 何谓数据异构，上周交易部门商品的共事过去做分享，又看到这个词，他的PPT外面是 数据库异构。其实咱们以前做的事件，也是可能称之为数据异构。比如咱们将DB外面的数据持久化到Redis外面去，就是一种数据异构的形式。 如果要下个定义的话：把数据按需（数据结构、存取形式、存取形式）异地构建存储。 常见利用场景分库分表中有一个最为常见的场景，为了晋升数据库的查问能力，咱们都会对数据库做分库分表操作。比如订单库，开始的时候咱们是按照订单ID维度去分库分表，那么起初的业务需要想按照商家维度去查问，比如我想查问某一个商家下的所有订单，就非常麻烦。 数据异构总结起来大概有以下几种场景 数据库镜像数据库实时备份多级索引search build（比如分库分表后的多维度数据查问）业务cache刷新价格、库存变动等重要业务消息数据异构方向在日常业务开发中大抵可能分为以上几种数据去向，DB-DB这种形式，一般常见于分库分表后，聚合查问的时候，比如咱们按照订单ID去分库分表，那么这个时候咱们要按照用户ID去查问，查问这个用户上面的订单就非常不便利了，当然可能使用对立加到内存中去，但这样不太好。 所以咱们就可能用数据库异构的形式，从新按照用户ID的维度来分一个表，像在下面常见利用场景中介绍的那样。把数据异构到redis、elasticserach、slor中去要解决的问题跟按照多维度来查问的需要差不多。这些存储天生都有聚合的功能。当然同时也可能提高查问性能，应答大访问量，比如redis这种抗量银弹。 数据异构的罕用方法 完整克隆这个很简略就是将数据库A，全副拷贝一份到数据库B，这样的使用场景是离线统计跑工作脚本的时候可能。缺点也很突出，不适用于持续增长的数据。标记同步这个是业务场景比较简略的时候，现实情况下数据不会发生改变，比如日志数据，这个时候可能去标记，比如工夫戳，这样当发生故障的时候还可能回溯到上一次同步点，开始从新同步数据。binlog形式通过实时的订阅MySQL的binlog日志，生产到这些日志后，从新构建数据结构插入一个新的数据库或者是其余存储比如es、slor等等。订阅binlog日志可能比较好的能保证数据的一致性。MQ形式业务数据写入DB的同时，也发送MQ一份，也就是业务外面实现双写。这种形式比较简略，但也很难保证数据一致性，对简略的业务场景可能采纳这种形式。binlog形式 binglog是数据的日志记录形式，每次对数据的操作都会有binlog日志。现在开源的订阅binlog日志的组件，比如使用比较广泛的canal，它是阿里开源的基于mysql数据库binlog的增量订阅和生产组件。 因为cannal服务器目前读取的binlog事件只保存在内存中，并且只有一个canal客户端可能进行生产。所以如果需要多个生产客户端，可能引入activemq或者kafka。如上图绿色虚线框部分。 咱们还需要确保全量对比来保证数据的一致性（canal+mq的重试机制基本可能保障写入异构库之后的数据一致性），这个时候可能有一个全量同步WORKER程序来保障，如上图深绿色部分。 canal的工作原理 先来看下mysql主备（主从）复制原理 mysql主备（主从）复制原理，从下层来看，复制分成三步： master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，可能通过show binlog events进行查看）； slave将master的binary log events拷贝到它的中继日志(relay log)； slave重做中继日志中的事件，将改变反映它自己的数据。 canal模拟mysql slave的交互协定，伪装自己为mysql slave，向mysql master发送dump协定 mysql master收到dump请求，开始推送binary log给slave(也就是canal) canal解析binary log对象(原始为byte流) 咱们在部署canal server的时候要部署多台，来保障高可用。然而canal的原理，是只有一台服务器在跑处理，其它的服务器作为热备。canal server的高可用是通过zookeeper来保护的。 注意点确认MySQL开启binlog，使用show variables like 'log_bin'; 查看ON为已开启确认目标库可能产生binlog，show master status 注意Binlog_Do_DB，Binlog_Ignore_DB参数确认binlog格局为ROW，使用show variables like 'binlog_format'; 非ROW模式登录MySQL执行 set global binlog_format=ROW; flush logs; 或者通过更改MySQL配置文件并重启MySQL失效。为保障binlake服务可能获取Binlog，需增加授权，执行 GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON . TO 'admin'@'%' identified by 'admin'; FLUSH PRIVILEGES;MQ形式mq的形式，就绝对简略，实际上是在业务逻辑中写DB的同时去写一次MQ，然而这种形式不能够保证数据一致性，就是不能保障跨资源的事务。注：调用第三方近程RPC的操作肯定不要放到事务中。 ...

9月14日，阿里云云原生实时数仓降级公布。阿里云计算平台的产品专家分享了实时计算Flink版和Hologres构建企业级一站式实时数仓的外围能力降级及新性能解读。 以后，大数据正在从计算规模化向实时化演进，实时数仓的利用场景也越来越宽泛。例如：央视春晚，可通过大屏实时统计全国的收视率和观众画像；多个城市正在发展的城市大脑我的项目， 通过 IoT 的摄像头信息，实时捕捉各个城市中的交通、车辆、人流等信息进行交通监察与治理；银行、证券交易所等金融机构实时监控交易行为，进行反作弊反洗钱等行为的探测；电商大促场景下，可通过大屏实时展现成交额并实现毫秒级更新。除此之外，智能客服、物流跟踪、订单剖析、直播品质监控等也是实时数仓的典型利用场景。由此可见，实时数据的解决与剖析为越来越多的企业发明了业务价值。 实时数仓越来越重要。然而建设实时数仓时，企业却经常面临各种问题。以后实时数仓建设的痛点次要有以下三方面：首先，企业对于数据的准确性、时效性、性价比三方面都同时具备强烈需要。岂但对数据实时写入能力要求高、查问延时敏感、查问维度繁多且维度不固定，而且心愿兼顾明细查问和聚合查问两类不同负载，同时要求在老本上有所管制。其次，随着手机利用、小程序等场景日益增多，企业对于半结构化数据的剖析需要强烈。第三，因为业务需要更新频繁，实时工作变更频繁，企业须要更加麻利的实时数仓来适应频繁的变更。 为了解决客户建设实时数仓中面临的痛点，阿里云实时计算Flink版+Hologres实时数仓解决方案降级。 本次降级公布的新性能集中在数据写入、查问与剖析、企业级能力三个方面。 数据写入：领有实时利用场景的客户（如实时大屏、实时风控等）对于数据写入的实时性有着极高要求，要求数据写入即可见。同时，因为企业数据起源简单，会波及到许多的数据更新、修改的场景，进一步加大了实时写入与更新的难度。Hologres作为一站式实时数据仓库引擎，提供海量数据高性能的实时写入，数据写入即可查。同时，阿里云实时计算Flink版+Hologres可通过主键提供高性能的Upsert能力，整个写入和更新过程确保Exactly Once，满足对数据的合并、更新等需要。 企业在数据写入时，还面临着数据时效性低、老本高、同步效率低等艰难。本次公布的表构造变更主动同步性能解决了数据时效性问题，整库同步性能缩小了资源节约，分库分表合并同步晋升了数据同步效率。 随着业务的迭代和倒退，数据源的表构造变更已成为常见景象，企业须要及时批改实时同步作业以适配最新的表构造。这些操作带来了较高的运维老本，也影响了数据时效性。为解决这个问题，阿里云实时计算Flink版反对通过Catalog实现元数据的主动发现和治理，配合 CTAS （Create Table AS）语法，应用一行SQL实现数据同步和表构造的变更主动同步，升高运维老本，晋升数据时效性。在理论工作场景中，分析师常要通过单张表逐个同步的形式将整个数据库同步到数仓中做进一步剖析，岂但浪费资源，也为上游数据库带来较大压力。针对这个问题，阿里云 Flink CDC 提供了整库同步个性，节省成本，升高数据库压力。另外，分析师也经常须要将分库分表的业务数据汇聚到一张数仓中的大表中进行剖析，针对这种场景，阿里云实时计算Flink版+Hologres提供了分库分表合并同步个性，通过在 CTAS 语法反对源库和源表的正则表达式，源数据库的分表能够高效地合并同步到上游 Hologres 数仓中。 查问与剖析：本次公布的Hologres实时物化视图性能优化了聚合场景，缩小计算量，显著晋升查问性能。JSON列式存储优化晋升了半结构化数据查问和存储效率。Hologres Binlog + 阿里云实时计算Flink版反对了有状态的全链路事件实时驱动开发场景。 Hologres新版本已反对实时物化视图性能，数据在写入时即预计算，以空间换工夫，进步查问效率。JSON作为一个数据单位，提供了存储上的灵活性，但限度了剖析时的效率，为了拜访JSON中局部节点不得不读取整个JSON数据结构，效率十分低下，存储上也很难压缩。Hologres的JSON列式存储优化，均衡了灵活性(Schemaless)与性能，晋升数据存储压缩效率，缩小数据转换等操作，晋升查问效率。Binlog是Hologres很有特色的新能力，反对对每次数据更新的具体记录，利用在数仓档次间数据实时加工、多实例间数据同步、数据行列转换 、数据变化检测等多种场景。 企业级能力方面：Hologres提供了数据加密和脱敏、访问控制、容灾备份等能力。 除了产品性能公布外，产品专家还分享了某出名寰球TOP20游戏公司的案例。该客户通过阿里云Flink版+Hologres实时数仓计划替换开源架构，简化数据处理链路，对立数仓架构，对立存储，晋升查问性能，完满撑持数据分析、广告投放、实时决策等多个场景，助力业务快速增长。

大数据运维的挑战—如何保障集群稳固与运行效率企业级大数据集群通常领有海量的数据存储、日常运算成干上万的计算工作，须要满足各类下层业务的计算需要。对于这类集群的运维往往充斥着挑战：海量的数据、庞杂的组件以及组件之间简单的依赖关系、对于时效要求的的运算工作，都会晋升运维难度。作为撑持平台，大数据集群的稳定性和运行效率，会间接影响到公司业务的失常运作和倒退。 集群管理员往往对整体集群做好了监控运维体系，对于大数据集群，简略的监控运维体系可能帮忙管理员在遇到故障的时候定位问题。但对于整体集群的运行效率，集群的状态，通过单纯的监控指标很难给出一个全面的解答。 对于大数据集群，管理员以及 CIO 等更关注以下的内容： 集群内的节点的运行状态和资源应用情况；运行在集群上的服务组件的状态监控和异样解决，包含 YARN、HDFS、Hive 和 Spark 等；计算工作运行状况和执行效率；整体集群的衰弱水平和如何改良。面对运维挑战，EMR重磅推出：智能运维诊断系统(EMR Doctor)为了晋升大数据集群运维效率，辅助 EMR 用户欠缺集群监控体系。E-MapReduce 推出面向开源大数据集群的智能运维诊断系统 E-MapReduce Doctor（简称EMR Doctor）。 EMR Doctor 作为开源大数据集群的管家，会主动每日巡检集群。集群管理员只须要定期查看健康检查报告，并且依据报告中的倡议对集群做相应的优化调整，即可全局理解集群的健康状况和动静走势，并放弃集群的衰弱度。 如何应用 EMR Doctor进入 EMR 控制台健康检查页面。<!----> 登录 EMR on ECS 控制台。在顶部菜单栏处，依据理论状况抉择地区和资源组。在集群治理页面，单击指标集群的集群ID。单击上方的健康检查页签。在健康检查页面，您能够看到以后集群的健康检查报告（T+1）。衰弱状态列显示了该集群的衰弱度，您能够点击查看报告进入检查报告页面。 健康检查报告中蕴含集群计算资源的总体剖析 健康检查报告中蕴含计算工作从各个维度的排名并给出工作调优倡议 健康检查报告中蕴含对集群存储的总体剖析，以及大小文件和冷热数据的详细分析 健康检查报告次要剖析内容如下，更具体阐明请参见查看健康检查状态和报告计算资源剖析概述状态概述 须要关注的问题 计算根底信息集群计算评分 集群算力内存时 集群算力CPU时 计算引擎内存算力时 计算工作信息计算工作算力内存时剖析 计算工作评分排行榜 SparkSpark工作算力剖析及调优倡议 TezTez工作算力剖析及调优倡议 MapReduceMapReduce工作算力剖析及调优倡议HDFS存储资源剖析（需开启存储资源信息采集开关）概述状态概述 须要关注的问题 HDFS根底信息HDFS存储资源应用趋势 文件总数随工夫变化趋势 评分趋势 HDFS文件大小散布HDFS文件大小比例 一级目录空文件个数Top10 一级目录极小文件个数Top10 一级目录小文件个数Top10 一级目录中等文件个数Top10 一级目录大文件个数Top10 HDFS冷热数据分布HDFS冷热数据 一级目录极冷数据大小Top10 一级目录冷数据大小Top10 一级目录温数据大小Top10 一级目录热数据大小Top10HIVE存储资源剖析（需开启存储资源信息采集开关）概述状态概述 须要关注的问题 Hive根底信息存储趋势 文件数量趋势 评分趋势 Hive库信息库存储排名 库文件总数排名 库评分 Hive表文件大小散布Hive表文件大小散布比例 Hive表空文件个数Top10 Hive表极小文件个数Top10 Hive表小文件个数Top10 Hive中等文件个数Top10 Hive大文件个数Top10 Hive冷热数据分布Hive冷热数据分布 Hive表极冷数据大小Top10 Hive表冷数据大小Top10 Hive表温数据大小Top10 Hive表热数据大小Top10 Hive表存储格局散布Hive表存储格局散布 Hive表TextFile/Parquet/ORC格式文件剖析如何开明EMR Doctor开明及应用征询问题请见 EMR Doctor常见问题 ...

Databend 是一个应用 Rust 研发、开源、齐全面向云架构的旧式数仓，提供极速的弹性扩大能力，致力于打造按需、按量的 Data Cloud 产品体验。具备以下特点： 开源 Cloud Data Warehouse 明星我的项目Vectorized Execution 和 Pull&Push-Based Processor Model真正的存储、计算拆散架构，高性能、低成本，按需按量应用残缺的数据库反对，兼容 MySQL ，Clickhouse 协定欠缺的事务性，反对 Time Travel, Database Clone， Data Share 等性能反对基于同一份数据的多租户读写、共享操作当初应用 Databend 的用户越来越多后，大家面临一个问题，应用 Databend 如何备份呢？是不是须要如同 MySQL 一样每天做一个物理备份或是逻辑备份呢？答案是：可能还有更好的方法。这篇文章和大家聊一下 Databend 中数据的生命周期，而后再来看 Databend 如何做备份治理。 首先咱们来看一下 Databend 的架构 Databend 的写入操作是有事务性保障，基于事务隔离 RR 实现的，底层的数据存储是基于对象存储，本质上数据的长久化平安也是依赖于底层的对象存储，所以抉择云厂商的 S3, OSS, COS 也是不错的抉择，如果是自建的 minio, ceph 肯定要做集群保障。因为是基于对象存储写入，所以工作的写入都能够了解为是一个增量操作，这也让 Databend 省掉了日志治理，更多的须要把表和对应的 snapshot 关联起来就能够让数据恢复到任意的工夫点。接下来分 4 个方面看看 Databend 如何利用对象存储实现一个毋庸备份，但数据永远不失落的计划。 Databend 数据生命周期外围：Snapshot在讲 Databend snapshot 之前，抛出来一个问题： 如果想拜访一个表 5 分钟前的数据怎么解决，一个 delete from tb ; 没有 where 条件怎么复原？如果在别的数据库这两个需要，根本都是劫难。但在 Databend 中，这些是十分轻松能够实现的。演示如下： ...

前言数字化转型大背景下，数据作为企业重要的策略资产，其平安的重要性显而易见。 咱们会通过系列文章，来看下大数据生态中平安框架的实现原理与最佳实际，系列文章一共两篇，蕴含以下章节： 大数据生态平安框架概述HDFS 认证详解HDFS 受权详解HIVE 认证详解HIVE 受权详解金融行业大数据安全最佳实际本片文章是下篇，蕴含上述后三个章节，心愿大家喜爱。 1. HIVE 认证详解HIVE 的认证形式，通过参数 hive.server2.authentication 在服务端进行对立配置；该参数可选的值次要有三种：hive.server2.authentication=none/kerberos/ldapHIVE的客户端，不论是 beeline 等专用 cli 客户端，还是 dbeaver 等通用 jdbc gui 客户端，抑或 JAVA 利用（基于jdbc），都须要依据服务端配置的认证形式，应用对应的形式，进行认证后能力胜利连上 hiveserver2，进而提交查问命令。视乎大数据集群中是否开启了 kerberos，理论的认证形式，分为以下四种： 无认证模式只开启LDAP认证模式只开启Kerberos认证模式开启Kerberos和LDAP双重认证模式 1.1 无认证模式:hive.server2.authentication = none当不须要对用户身份进行校验，能够配置 hive.server2.authentication = none, 这种境况常常用在测试环境，生产环境个别不举荐;此时用户通过各种客户端如 cli/gui/java 登录时，能够不配置用户名和明码, 在服务端 Hive 会认为登录的是匿名用户 anonymous,（这点不同于 hdfs, 当没有开启kerberos平安时，如果没有配置 环境变量或零碎参数 Hadoop_user_name,hdfs 的默认用户是提交作业的LINUX零碎用户）如：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default此时用户通过各种客户端如 cli/gui/java 登录时，也能够配置为任意用户名和任意明码,在服务端 Hive 会认为登录的是用户申明的任意用户（用户名能够是任意用户名，甚至是不存在的用户名；明码能够是任意明码，或不配置明码），如：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n xyz；beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n xyz -p xxxx能够通过 hiveserver2 webui，验证登录的用户身份； 1.2 只开启LDAP认证模式:hive.server2.authentication = ldap中大型企业中个别都会有用户身份的对立认证平台，其底层个别都应用 ldap 协定，其具体实现有微软的 ActiveDirectory， 也有 openLdap, ApacheDS等开源实现；Hive 提供了基于 Ldap 的认证机制，能够应用企业的对立认证平台，来验证登录hive的用户的身份,其配置形式：hive.server2.authentication = ldap;具体的 ldap 工具的 url，须要通过参数指定：hive.server2.authentication.ldap.url；除了集成商业版的 ActiveDirectory，大数据集群中也能够应用独立装置的开源的ldap工具，此类工具常见的有 openLdap 和 ApacheDS，其中前者在大部分linux发行版中都自带了package安装包，更容易装置，不过次要通过命令行cli进行治理；而后者则自带了gui客户端 Apache Directory Studio，性能更为丰盛；以 openLdap为例，其装置命令如下：sudo yum -y install openldap-clients; sudo yum -y install openldap;客户端登录 ldap 认证的 hiveserver2 时，须要提供用户名和明码，hiveserver2 会到ldap中验证用户名和明码，只有验证通过后能力失常登录；以 beeline 登录为例，其命令格局如下：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n ldapUserName -p ldapUserPwd; ...

download：体系课大数据工程师2022版2.0升级版自建数据库可视化平台，在线治理数据库Bytebase简介Bytebase是一款面向开发者的数据库变更管理工具，目前在Github上已有3.6K+Star。它的次要个性如下： SQL审核：具备一站式SQL审核面板，可能直观地看到数据库所有变更记录。SQL倡导：能主动查看SQL语句规范，额定提供GitHub Action和API接入形式。SQL编辑器：可能在线治理及查看数据库表，反对语法的主动提醒。GitOps工作流：反对集成GitHub和GitLab，使用GitOps工作流进行数据库变更。备份复原：反对主动备份数据库及复原数据。 安装 首先咱们将在Linux下安装Bytebase，使用Docker来安装无疑是最便利的。 因为ByteBase对MySQL8的反对比较好，这里推荐安装MySQL8，首先下载MySQL8的Docker镜像； docker pull mysql:8复制代码 再使用如下命令运行MySQL8的容器； docker run -p 3506:3306 --name mysql8 \-v /mydata/mysql8/mysql-files:/var/lib/mysql-files \-v /mydata/mysql8/conf:/etc/mysql \-v /mydata/mysql8/log:/var/log/mysql \-v /mydata/mysql8/data:/var/lib/mysql \-e MYSQL_ROOT_PASSWORD=root \-d mysql:8复制代码 而后使用如下命令下载Bytebase的Docker镜像 docker pull bytebase/bytebase:1.3.1复制代码 下载胜利后，使用如下命令运行ByteBase容器； docker run --init \ --name bytebase \ --restart always \ --add-host host.docker.internal:192.168.3.105 \ --publish 5678:5678 \ --health-cmd "curl --fail http://localhost:5678/healthz || exit 1" \ --health-interval 5m \ --health-timeout 60s \ --volume /mydata/bytebase/data:/var/opt/bytebase \ -d bytebase/bytebase:1.3.1 \ --data /var/opt/bytebase \ --host http://localhost \ --port 5678 ...

Hadoop 的诞生扭转了企业对数据的存储、解决和剖析的过程，减速了大数据的倒退，受到宽泛的利用，给整个行业带来了改革意义的扭转；随着云计算时代的到来， 存算拆散的架构受到青眼，企业开开始对 Hadoop 的架构进行革新。 明天与大家一起简略回顾 Hadoop 架构以及目前市面上不同的存算拆散的架构计划，他们的利弊各有哪些，心愿能够给正在存算拆散架构革新的企业一些参考和启发。 Hadoop 存算耦合架构回顾2006 年 Hadoop 刚公布，这是一个 all-in-one 的套装，最早有三个外围的组件：MapReduce 负责计算，YARN 负责资源调度，HDFS 分布式文件系统，负责存数据。 在这三个组件中，倒退最迅速和多元的是计算组件这一层，最早只有一个 MapReduce，但业界很快在计算层下面各显神通，造出了一大堆的轮子，包含有 MapReduce，Tez，Spark 这样的计算框架，Hive 这类数据仓库，还有 Presto、Impala 查问引擎，各种各样的组件。配合这些组件的，还有像 scoop 这样的数据流转采集的组件也很丰盛，一共有几十款。 底层存储通过了大略 10 年左右的工夫，始终是 HDFS 一枝独秀，带来的一个后果就是它会成为所有计算组件默认的设计抉择。下面提到的这些大数据生态里倒退进去的各种组件，都是面向HDFS API 去做设计的。有些组件也会十分深刻的利用 HDFS 的一些能力，比方深刻看 Hbase，在写 WAL log 的时候就间接利用了HDFS 的一些很内核的能力，能力达到一个低时延的写入；比如说像最早的 MapReduce 和 Spark 也提供了数据亲和性（Data Locality）的能力，这些都是HDFS 提供的一些非凡的 API。 这些大数据组件面向 HDFS API 设计的做法， 为后续数据平台上云带来了潜在的挑战。 上面是一个简化的部分的架构图，通过这张图疾速了解 Hadoop 存算耦合架构。在这张图有三个节点，每个节点外面它都承载了 HDFS DataNode 的存数据的角色，但同时 YARN 也会在这里布一个 Node Manager的过程。有了 Node Manager 之后，YARN 就会认为 HDFS DataNode 的节点，在其治理范畴之内，当须要计算工作能够散发到这个节点上来实现。存储工作和数据就在同一个机器里了，计算的时候就能够间接读到磁盘上的数据。 ...

ChengYing是一站式全自动化全生命周期大数据平台运维管家，提供大数据产品的一站式部署、运维、监控服务，其可实现产品部署、产品升级、版本回滚、扩缩节点、日志诊断、集群监控、实时告警等性能，致力于最大化节俭运维老本，升高线上故障率与运维难度，为客户提供平安稳固的产品部署与监控。 ChengYing脱胎于袋鼠云数栈自主研发的一站式运维管家EasyManager，承继袋鼠云开源我的项目名剑家族的概念，取自十大名剑之承影剑，1.0版本于2022年5月30日在github上线。 2022年9月13日，ChengYing1.1版本正式公布！ ChengYing1.1版本在1.0的版本上，对之前的UI做了全面降级，并新增平台管理中心，蕴含：备份配置、装置目录、脚本治理、集群巡检等性能；在运维核心及部署核心原有的根底上做了全面降级优化，新增超多功能，进一步提高了运维及部署能力。 本次公布的1.1版本带来如下新亮点： ● 一般降级 用户在降级组件包时主动备份数据库，回滚时能主动还原数据库，不便用户进行数据备份及运维降级回滚。 ● 平滑降级 实现组件包的滚动公布，能够先降级一部分利用，等测试实现后，再全副更新利用。可能缩小因降级环境带来的硬件需要，不便用户运维降级、回滚利用。 ● 产品线主动部署 产品能够依据组件包的角色信息，主动编排服务器，主动解决组件包的部署依赖问题，主动部署，大大减少了运维工夫。 新版本已在Github与Gitee上线，同时应用文档也在社区推送，大家能够随时下载查阅，欢送大家返回体验（喜爱咱们的我的项目欢送大家点个Star），体验地址： Github: https://github.com/DTStack/ch... Gitee： https://gitee.com/dtstack_dev... 官网文档： https://dtstack.github.io/che... ChengYing 1.1版本详解● 整体优化 优化sql注入破绽解决 优化主机下架革除历史健康检查脚本 优化高版本零碎主机安装包解压失败 优化审计日志 优化脚本治理 告警复原处于pause状态 ● 运维核心1.【服务】新增配置下发的预览性能。 2.【诊断】新增巡检报告性能。 ● 部署核心 1.【组件治理】组件装置时，新增产品线级别部署。 2.【部署组件】新增主机编排抵触校验。 3.【已部署组件】新增产品包回滚性能。 4.【部署服务】新增在批改服务配置参数时，能够指定文件批改。 5.【组件降级】新增平滑降级。 6.【监控告警】新增点击告警仪表盘跳转grafana后选中ip；grafana规定列表批量启停。 7.【监控告警】告警模块新增搜寻性能。 ● 平台治理1.【备份配置】新增自定义备份门路目录，组件包卸载时，能够将以后组件快照挪动到自定义的目录下。 2.【脚本治理】新增脚本治理。 ● 系统配置1.【全局配置】新增全局配置页面，反对组件装置超时，自动化测试超时设置。 2.【平台平安】新增未操作会主动登出。 3.【平台平安】新增sm2国密认证。 4.【平台平安】新增初始密码强制批改，登陆谬误次数锁定。 ● 用户核心1.【部署信息下载】新增集群部署信息下载性能。 ChengYing 1.2版本布局目前ChengYing1.1版本已顺利公布，1.2版本咱们也正在布局中，新版本咱们将会重点围绕如下关键点： ...

欢送来到【微直播间】，2min纵览大咖观点，本期分享的题目是数据编排技术在联通的利用。本次分享内容将围绕四个方面讲述Alluxio数据编排技术在联通的利用，次要围绕缓存减速、存算拆散、混合负载以及轻量级剖析四个不同的应用场景进行分享： 摘要01. 在缓存减速方面的利用为了减速Spark计算，引入了Alluxio来减速数据的读写性能，进步数据写入的稳定性，以及接管Spark Cache后晋升Spark作业的稳定性。这是咱们一开始采纳的架构，数据编排在咱们的整个架构中的定位是缓存减速层。 * 减速迭代计算：减速上游SQL读取数据速度，晋升数据写⼊稳定性；* Spark Job间共享数据，替换Spark cache；* 内存多正本显著提⾼热数据访问速度；* 调整数据分布策略实现负载平衡；* Alluxio带来性能与稳定性晋升；02. 在存算拆散方面的利用 * 利⽤其余业务资源满⾜计算扩容需要；* 实现存储独⽴扩容，数据冷热拆散；03. 在混合负载畛域的利用 * 利⽤Alluxio Client Cache实现缓存隔离；* 利⽤Alluxio Fuse买通ETL与AI训练/推理；04. 轻量级剖析相干摸索Presto + Alluxio实现轻量级数据分析 * 1) 在⽤户集群搭建Alluxio + Presto两套零碎满⾜数据分析需要，运维复杂度绝对较低，纯SQL交互⽤户体验好；* 2) Alluxio mount平台HDFS⽤于公有数据共享，Alluxio SDS mount 平台Hive⽤于私有数据拜访及性能减速；* 3) 基于Presto Iceberg connector的hadoop catalog mode，采⽤只写缓存的⽅式在本地实现ETL，最终数据长久化⾄平台HDFS；* 4) Alluxio使⽤3正本策略保障缓存数据的可⽤性，可挂载独⽴存储集群长久化存储需⻓期保留的剖析数据。以上仅为大咖演讲概览，残缺内容【点击观看】： 附件：大咖分享文字版残缺内容可见下文 01. 在缓存减速方面的利用 首先介绍Alluxio作为分布式缓存减速大数据计算的应用场景。咱们事业部存在多个数据处理与数据分析业务，这些业务散布在不同的平台。应用GreenPlum数据库的数据处理业务基于批处理存储过程实现数据加工，对计算工夫有严格的要求，有明确的deadline。这些业务遇到的次要问题是GreenPlum集群规模达到几十台时遇到扩容瓶颈，进一步扩大给业务运维工程师带来很大挑战；还有一部分业务基于hive运行T+1批处理作业，遇到的次要问题是内存、CPU等资源耗费比拟大，并行度不高，跑的速度比较慢；还有一些传统统计业务是跑在Oracle上，Oracle单机跑的成果不是特地好，并且Oracle比拟贵，一台小型机可能就要两千多万，业务方冀望能有其余数据分析平台代替Oracle。 过后，咱们的课题是基于Spark、Hadoop这个开源体系，去做一个对立的计算平台，把上述三个引擎承接的业务全副接过来。咱们间接用Spark + HDFS遇到了一些问题： 首先，它的性能是没有方法满足GreenPlum承载的生产业务，因为GreenPlum是MPP数据库，等同体量下它会比Spark要快很多； 其次，GreenPlum承载的业务中存在伴生的交互式查问的场景，同样性能也是没有方法去满足的。 接着，对于一些批处理的业务来说，Spark + HDFS比拟欠缺稳定性，批处理的业务每一次工作周期会有几千、几万个SQL去做迭代计算，工作如果常常失败的话，没有方法很好地在那之前保障去实现。 所以，为了减速Spark计算，咱们引入了Alluxio来减速数据的读写性能，进步数据写入的稳定性，以及接管Spark Cache后晋升Spark作业的稳定性。这是咱们一开始采纳的架构，数据编排在咱们的整个架构中的定位是缓存减速层。 具体看一下应用案例，如果拿减速迭代计算来说，咱们会把Sink间接写到Alluxio上，而后下一个SQL的Source去读这个Sink，把Source和Sink之间的串联交给Alluxio的缓存去做，这样能够比较显著晋升整个pipeline的稳定性。因为不须要再和磁盘交互，能够极大升高磁盘压力。而通过内存，pipeline的稳定性失去了比拟好的改善，通过间接读取内存会进步整个pipeline的运行速度。 第二个应用案例，是咱们通过Alluxio去共享整个Job之间的数据，而防止应用Spark Cache。通过Spark Cache形式会对整个Executor JVM造成比拟大的压力。性能测试结果表明在数据量达到肯定规模的状况下，Spark Cache的性能是要比Alluxio差一些。而且Alluxio随着Spark两头数据的增大，它对性能的影响是能够预测的，是线性而不是指数性上涨的。所以说，咱们抉择用Alluxio做两头数据的共享层。 ...

所谓的事实表和维度表技术，指的就是如何和结构一张事实表和维度表，是的事实表和维度表，能够涵盖当初目前的须要和不便后续上游数据利用的开发。 事实表，就是一个事实的汇合。事实来自业务过程的度量，基本上以数量值示意。事实表行对应一个事实，一个事实对应一个物理能够察看的事件，例如，再批发事件中，销售数量与总额是数据事实，与销售事件不相干的度量不能够放在同一个事实表外面，如员工的工资。 事实表是理论产生的度量，对应的，这些度量咱们能够分为三中类型:可加、半可加、不可加。可加性度量能够依照与事实表关联的任意维度汇总。半可加度量能够对某些维度汇总，但不能对所有维度汇总。差额是常见的半可加事实，除了工夫维度之外，它们能够逾越所有维度进行加法操作。不可加度量，比方比率，任何维度都不能间接相加。因而对于不可加度量，咱们要尽可能的把不可加度量拆分为可加度量，例如比率，咱们能够别离存储他们的分子和分母，使其转为可加度量。 对于事实表，还有一类值NULL,须要咱们去校验和保障，对于事实表的度量，咱们能够容许存在NULL,不过对于一些外键，则不能存在空值，否在会导致违反参照完整性的状况产生，咱们能够赋予默认的代理键来示意未知或者NULL的状况。 参照的完整性要求关系中不容许援用不存在的实体。与实体完整性是关系模型必须满足的完整性约束条件，目标是保证数据的一致性。参照完整性又称援用完整性。如果一个度量呈现在多个事实表外面，咱们还须要保障，多个事实表汇总到同一个维度的时候，度量的值相等，并且命名尽量雷同，这就是一致性事实。一致性事实能够保证数据口径的统一和取数不便。如何保证数据事实的一致性呢？如何保障多张事实表雷同字段雷同？这里倡议有两个，一是字段名称雷同，二是开发实现的时候，能够对表数据的值比对，并且能够起一个数据校验的工作，定时校验比对，如果有问题就告警。 简略的，咱们能够大略分为事务事实表，周期快照事实表，累计快照事实表，无事实的事实表。 事务事实表：事务事实表的一行对应空间或者工夫上某点的度量事件。即流水行数据。周期快照事实表：周期快照事实表中的每一行汇总了产生在某一规范周期，例如某一天的多个事实。即按某个维度轻度汇总的数据。累计快照事实表：累积快照事实表的行汇总了产生在过程开始和完结之间可预测步骤内的度量事件。也就是记录整一个业务过程，如下单，蕴含下单工夫，领取工夫，赔付工夫等。无事实的事实表：有一些事件是没有事实的，事实蕴含多个度量，也就是局部事件没有度量，只有维度，例如某天学生加入的课程。 接下来说说维度表的一些要点，维度表蕴含繁多的主键列。维度表的主键能够作为与之关联的任何事实表的外键，当然，维度表行的形容环境与事实表行齐全对应。 维度表开发过程中有上面几个点。 维度代理键，维度表中会蕴含一个列，示意惟一主键，该主键不是操作型零碎的天然键，如果采纳天然键，须要多个维度行示意，另外，维度的天然键可能由多个源零碎建设，这些天然键可能会呈现兼容性问题。所以这里能够对代理键做一些解决，具体能够看业务状态，如果源零碎曾经保障了惟一，间接利用也是没有问题的。进化维度,有时，维度除了主键外没有其余内容，例如订单表外面的发票维度只有发票号，没有其余的信息，那么咱们能够将这个维度放入事实表外面，这个就是进化维度。一致性维度，当不同的维度表的属性具备雷同列名和畛域内容时，称维度具备一致性。利用一致性维度属性与每一个事实表关联，可将来自不同事实表的信息合并到同一个报表外面。咱们整顿了维度表和事实表之后，咱们须要造成一个总线矩阵。总线矩阵用于设计数据仓库架构的根本工具，矩阵的行示意业务过程，列代表维度。矩阵中的点示意维度与给定的业务过程是否存在关系，如下图。 造成这样的一个架构之后，咱们的数据仓库的构造分层，和外面的数据表设计实现了，就能够进行同步和开发了。 须要数据仓库材料能够点击这个支付数据仓库(13)大数据数仓经典最值得浏览书籍举荐 原文链接：数据仓库(8)数仓事实表和维度表技术

download：体系课-大数据工程师2022版2.0升级版无密大数据的历史2018年9月30日，中国互联网巨头腾讯公司总裁刘炽平向整体员工收回一封信，正式启动公司历史上第三次重大组`织架构调整。被外界解读为腾讯此举是为了将人工智能、大数据、云计算晋升到更外围的战略地位。事实上，不仅是腾讯，谷歌、亚马逊、阿里巴巴、百度、小米等互联网巨头近年来都在调整组织架构，都是为了适应ABC时代的必然到来。ABC是指以A(AI)、B(大数据)、C(云)为代表的产业趋势和技术改革。业界普遍认为，这将是继PC时代、挪动互联网时代之后的又一次产业改革，预示着一个全新的时代曾经到来。其中，云计算(C)将像咱们日常生`活中的水和电一样，作为整个互联网的底层基础设施，为企业的数据资产提供保存和拜访的场合和渠道。有了基础设施，只有数据才是企业真正有价值的资产。这里所说的数据包含企业外部的经营信息、互联网上的商品信息、聊天软件中的人际交往信息、地位信息等。这些数据的量将远远超过企业现有IT架构和基础设施的承载能力，企业应用的实时性要求也将大大超过现有的计算能力。如何利用这些贵重的数据资产，使其服务于国家治理、企业决策和集体生存，是大数据处理的外围，也是云计算的外在灵魂和必然降级方向。 在这种趋势下，大数据这个词在近几年的很多技术会议上越来越多地被提及。人们用它来形容和定义信息时代产生的海量数据，命名相干的技术倒退和翻新。寰球出名咨询公司麦肯锡率先提出大数据时代的到来。事实上，大数据在物理、生物、环境生态、军事、金融、通信等行业畛域曾经存在了一段时间，只是因为近年来互联网和it行业的倒退才引起人们的关注。依据中国信息通信研究院联合大数据相干企业的钻研测算，2017年中国大数据产业规模为4700亿元，同比增长30%。预计到2020年产业规模将达到万亿元。(材料起源:中国信息通信研究院《大数据白皮书(2018)》 大数据到底是什么？依据钻研机构Gartner给出的定义，大数据须要新的解决模式，以具备更强的决策、洞察和流程优化能力，适应海量、高增长率、多元化的信息资产。大数据技术的战略意义不在于把握宏大的数据信息，而在于对这些有意义的数据进行业余的解决。换句话说，如果把大数据比作一个行业，这个行业盈利的关键在于进步数据的“解决能力”，通过“解决”实现数据的“增值”。(起源:搜狗百科)而麦肯锡寰球研究院给出的定义是:规模大到在获取、存储、治理、剖析等方面大大超过传统数据库软件工具能力的数据汇合。具备数据规模海量、数据流转迅速、数据类型多样、价值密度低四大特点。在泛滥定义中，搜狗百科中的大数据词条更吸引我:大数据是指在肯定工夫范畴内无奈被惯例软件工具捕获、治理和解决的数据汇合，是一种海量、高增长、多元化的信息资产，须要新的解决模式来领有更强的决策力、洞察力和发现力以及流程优化能力。被誉为“大数据商业利用第一人”的维克托·迈尔·舍恩伯格认为，大数据是指对所有数据进行剖析解决的形式，而不是随机剖析(如抽样调查)的捷径。大数据的外围是预测，它将为人类生存发明前所未有的可量化维度。他认为大数据时代最大的变动是放弃对因果关系的渴求，转而关注相关性。也就是说，咱们只须要晓得它是什么，而不须要晓得为什么。这颠覆了人类几千年的思维惯例，对人类的认知和与世界沟通的形式提出了全新的挑战(起源:大数据时代作者访华与田溯宁大数据对话_网易科技)。这些IBM的总结就是5V的特色:量(大数量)、速(高速)、变(多样)、值(低值密度)和准(真实性)。大数据技术的战略意义不在于把握宏大的数据信息，而在于对这些有意义的数据进行业余的解决。换句话说，如果把大数据比作一个行业，这个行业盈利的关键在于进步数据的“解决能力”，通过“解决”实现数据的“增值”。从技术倒退的历史来看，大数据处理能够分为前身、生成和利用三个阶段。从90年代到本世纪初，能够说是大数据处理的前身。过后数据存储和解决的支流还是在数据库上。随着数据库技术和数据挖掘实践的成熟，数据仓库和数据挖掘技术开始逐渐倒退，各种商业智能工具开始利用，如数据仓库、专家系统、常识管理系统等。随着互联网上各种新服务的呈现，大量的非结构化数据涌现进去，这使得传统的数据库技术越来越难以应答。例如，脸书的风行使得社交利用产生大量的非结构化数据，而家喻户晓的谷歌公司的搜索引擎业务天然也要面对一直收缩的海量数据的存储和解决，这使得大数据技术的倒退进入了快车道。个别以Google 2003-2006年发表的三篇论文作为大数据处理技术的终点，别离是GFS、MapReduce和Bigtable。GFS(2003)是一个可扩大的分布式文件系统，用于拜访大量的分布式数据。它运行在便宜的一般硬件上，并提供容错性能。MapReduce(2004)是一种解决海量数据的并行编程模式，用于大规模数据集的并行操作。能够充分利用GFS集群中所有低成本服务器提供的大量CPU，在架构上能够看作是对GFS的补充。它与GFS一起形成了海量数据处理的外围。GFS适宜存储大量十分大的文件，但不适宜存储成千上万的小文件。为了解决大量的格式化和半格式化数据，治理非关系数据的分布式数据存储系统BigTable(2006)诞生了。它的设计指标是疾速牢靠地解决PB级数据，能够部署到数千台机器上。以这三篇论文为标记，能够看出大数据处理技术的起源。大数据处理技术的倒退不得不提Hadoop。2005年，阿帕奇软件基金会主席Doug Cutting在雅虎创建了这个我的项目。它是一个用于大数据分析的开源分布式计算平台，能够平安地扩大应用程序，以解决数千个节点和数Pb的数据。通过搭建一个对于MapReduce的开源平台，Hadoop在不经意间发明了一个欣欣向荣的生态系统，其影响力远远超出了其最后Hadoop的领域。在Hadoop社区中，工程师能够从晚期的GFS和MapReduce论文，以及Pig、Hive、HBase、Crunch等许多有用的工具中改良和扩大这些思维。都是在这个根底上产生的。这种开放性是整个行业现有思维多样性的要害，Hadoop的凋谢生态间接推动了流计算零碎的倒退。随着互联网行业的疾速倒退，数据生产、应用、解决和剖析的速度也在以不堪设想的速度增长。社交媒体、物联网、广告和游戏等垂直畛域开始解决越来越大的数据集。从业务角度来说，这些行业须要一种靠近实时的数据处理和剖析，所以像Hadoop这种批量解决大数据的传统框架并不适宜这些场合。自2007年以来，许多开源我的项目相继推出，以新的思路解决来自多个数据源的间断数据记录，其中Apache的许多我的项目最为驰名。目前，这些我的项目处于不同的倒退阶段。 现在，随着智能挪动设施、物联网等技术的广泛应用，数据碎片化、分布式、流媒体的特色更加显著。大数据技术开始与挪动、云技术联合，开始向简单事件处理、图形数据库、内存计算方向倒退。大数据的概念越来越被垂直行业和公众所承受。通过催化新的商业模式，大数据和传统行业之间的界线变得越来越含糊。人们开始更加关注商业翻新而不是技术自身。大数据行业的主题也转向了利用对行业的变革性影响，曾经到了真正的利用阶段。大数据的倒退方向大数据技术是一种新的技术和架构，致力于以更低的老本和更快的速度收集、解决和剖析各种超大规模的数据，并从中提取有价值的信息。随着这项技术的蓬勃发展，它让咱们解决海量数据变得更容易、更便宜、更快捷，成为应用数据的好助手，甚至扭转了很多行业的商业模式。在人工智能、云计算和物联网的帮忙下，即便是简单的大数据，一般的数据从业者也能够应用相应的数据分析工具进行解决。大数据分析曾经脱离了煊赫一时的IT趋势标签，当初曾经成为公司业务的必要组成部分。它将很快取代黄金成为人类最有价值的资产之一。《将来简史》中说:“谁领有数据，谁领有数据的解读权，谁就可能在将来的竞争中占得先机”。为了让读者疾速理解大数据的最新信息，以下是一些最热门的大数据趋势，以促成行业的将来倒退。以下是阿里云社区翻译整顿的大数据值得理解的十大数据发展趋势。快速增长的物联网网络因为物联网(IoT)技术，智能手机用于管制家用电器变得越来越广泛。随着小米和阿里等智能设施在家庭中自动化特定工作的遍及，物联网热潮正在吸引许多公司投资这项技术的研发。更多的组织将抓住机会提供更好的物联网解决方案，这必然会导致更多收集大量数据的办法，以及治理和剖析数据的办法。行业内的钻研趋势是推广更多能够收集、剖析和解决数据的新设施，如手环、智能音箱和眼镜。风行的人工智能技术人工智能当初更罕用于帮忙大型和小型公司改善业务流程。人工智能当初能够比人类更快、更精确地执行工作，从而缩小人类引入的谬误，改善整体流程，使人们可能更好地专一于更要害的工作，并进一步提高服务质量。人工智能的疾速倒退和更高的薪酬吸引了很多开发者进入这一畛域。好在市面上有成熟的人工智能开发工具箱可用，大家能够依据理论工作构建相应的算法，满足日益增长的需要。如果单个组织可能找到最无效的办法将其集成到业务流程中，他们可能会取得更大的劣势。预测的衰亡大数据分析始终是企业获取竞争劣势、实现目标的要害策略之一。钻研人员应用必要的剖析工具来解决大数据，并确定某些事件的起因。当初，通过大数据的预测剖析能够帮忙更好地预测将来可能产生的事件。毫无疑问，这种策略在帮忙剖析收集到的信息以预测消费者行为方面十分无效，这使得公司能够理解客户的下一步口头，以确定他们在进行相干开发之前必须采取的措施。数据分析还能够提供更多的数据脉络，帮忙了解背地的真正起因。光明数据迁徙到了云中没有转换成数字格局的信息称为暗数据，这是一个尚未开发的宏大数据库。预计这些仿真数据库将被数字化并迁徙到云上，而后用于有利于企业的预测和剖析。首席数据官将施展更大的作用。当初，大数据越来越成为施行商业策略的重要组成部分，首席数据官也在其组织中扮演着更加重要的角色。首席数据经理应该疏导公司朝着正确的方向倒退，并采取更加踊跃的措施。这一趋势为寻求职业倒退的数据营销人员关上了大门。量子计算目前，应用咱们现有的技术来剖析和解释大量数据可能须要很多工夫。如果咱们可能在短短几分钟内同时解决数十亿条数据，咱们就能够大大缩短解决工夫，让公司有机会及时做出决策，以达到更好的成果。这个艰巨的工作只能通过量子计算来实现。尽管目前量子计算机的钻研还处于起步阶段，然而曾经有一些公司在应用量子计算机进行相干试验，帮忙不同行业的实际和实践钻研。很快，谷歌、IBM和微软等大型科技公司将开始测试量子计算机，并将其整合到业务流程中。开源解决方案目前，有许多公共数据解决方案可用，如开源软件，在减速数据处理方面获得了长足的提高，同时具备实时拜访和响应数据的性能。因为这个起因，预计它们将在将来迅速倒退，需求量很大。尽管，开源软件很便宜，然而你能够用它来升高企业的经营老本。然而，应用开源软件也有一些毛病。这里有一些你须要晓得的毛病。边缘计算因为物联网的发展趋势，许多公司正在转向钻研互联设施，以收集更多的数据或解决客户的数据，这产生了技术创新的需要。这项新技术旨在缩小从数据收集到云、其剖析和采取行动的须要的滞后工夫。要解决这个问题，边缘计算能够提供更好的性能，因为进出网络的数据更少，云计算的老本更低。如果公司抉择删除以前从物联网收集的不必要的数据，公司也能够从升高存储和基础设施的老本中受害。此外，边缘计算能够放慢数据分析，为公司做出正确的反馈提供短缺的工夫。更智能的聊天机器人因为人工智能的疾速倒退，许多公司当初都在部署聊天机器人来解决客户查问和其余利用场景，以提供更个性化的交互模式，并打消对人工的需要。大数据与提供更欢快的客户体验有很大关系，因为机器人解决大量数据，而后依据客户在查问中输出的关键词提供相干答案。在互动的过程中，他们还能够从交谈中收集和剖析对于客户的信息，进而帮忙营销人员制订更简化的策略，以实现更好的用户转化率。摘要所有这些跨行业的技术飞跃，都是建设在大数据倒退所奠定的坚实基础之上的。技术提高将持续帮忙咱们通过更智能的流程发明更美妙的社会。咱们必须充沛了解如何应用这项技术，以及如何实现特定的业务指标。只有将两者联合起来，咱们能力最终受害于这些趋势。这些只是开始，大数据将持续成为咱们在业务和技术畛域所经验的改革的催化剂。咱们能做的就是思考如何无效地适应这些变动，并利用这种技术使咱们的业务蓬勃发展。他人网和去年公布的《2018寰球大数据产业》将出现七大发展趋势。 大数据处理框架介绍从技术角度来看，个别认为Google在2003-2006年发表的三篇经典文章是GFS、BigTable和MapReduce，这三者并称为Google的分布式计算三驾马车。由此，第一个在开源社区取得微小关注的大数据处理框架Hadoop诞生了。这个由HDFS、HBase和MapReduce主导的技术栈，影响至今。大数据处理一开始大多采纳离线解决，其外围解决逻辑是MapReduce。所谓Mapreduce就是把所有的操作分为两类:map和reduce。Map用于将数据分成多个局部，并别离进行解决。Reduce合并解决后的后果失去最终后果。MapReduce的概念是好的，但在理论利用中性能较差。而后Spark framework通过其弱小的高性能批处理技术逐步取代MapReduce成为大数据处理的支流。随着时代的倒退，很多商家曾经不满足于线下批量解决，越来越多的场景须要实时处理。为了满足这种需要，Spark引入了Spark Streaming以微批量模仿准实时成果，但解决成果并不现实。Twitter在2011年推出的Storm stream计算零碎就是标记，开启了更低提早的流解决计划。之后，流解决的模式被Flink发扬光大。Flink并不局限于简略的流计算引擎，而是提供了更通用的流解决框架，能够解决批处理工作，从而开始侧面挑战Spark的位置。在大数据处理技术的探讨中，咱们常常会听到两个词:解决框架和解决引擎。依照我集体的了解，引擎和框架其实没什么区别，都是指零碎中数据的计算。然而，大多数时候，理论负责解决数据操作的组件称为引擎，而一系列性能类似的组件称为框架。比方Hadoop能够看作是一个以MapReduce为默认解决引擎的解决框架，而另一个解决框架Spark能够并入Hadoop来代替MapReduce。组件之间的互操作性也是大数据系统如此灵便的起因之一。所以在谈大数据的时候，引擎和框架个别能够替换，也能够同时应用。如果依照解决数据的状态来划分大数据的解决框架，有的零碎以批处理形式解决数据，有的零碎以流形式解决一直流入零碎的数据，有的零碎两种形式都反对。所以咱们能够把大数据处理框架分为三种:批处理、流解决和混合解决。成批处理所谓批处理，就是先将一个数据处理工作分解成更小粒度的工作，这些工作散布在集群中的每个实例上进行计算，而后从新计算每个实例的计算结果，组合成最终的后果。批处理零碎通常操作大量的静态数据，直到这些数据都被解决后能力失去返回的后果。这种模式实用于须要拜访全副记录能力实现的工作。例如，在计算总数和平均数时，必须将数据集作为一个整体看待，而不是将其视为多个记录的汇合。批处理因其在解决海量持久数据方面的优异性能，通常用于解决历史数据。许多联机剖析解决零碎的底层计算框架是批处理。批处理中应用的数据集通常具备以下特色: 有界:一个批处理数据集代表一个无限的数据集。持久性:数据通常总是存储在某种类型的持久性存储地位。批量:批处理通常是解决十分大的数据集的惟一办法。 Hadoop，批处理框架的代表，是第一个在开源社区取得微小关注的大数据处理框架，在很长一段时间里，它简直是大数据技术的代名词。Hadoop是一种分布式计算基础设施。到目前为止，Hadoop曾经造成了一个宏大的生态系统，外部实现了大量的算法和组件，其外围是HDFS和MapReduce。HDFS (Hadoop分布式文件系统)是一个分布式文件系统，能够构建在低成本的集群上。MapReduce是分布式工作解决架构，是Hadoop的基石。Hadoop的外围机制是通过HDFS和MapReduce对数据存储、内存和程序进行无效的利用和治理。Hadoop将许多常见且便宜的服务器组合成一个分布式计算-存储集群，从而提供大数据的存储和解决能力。Hadoop实际上是一个大我的项目的统称，其中蕴含许多子项目: HDFS:Hadoop分布式文件系统。它是GFS的开源实现，用于在Hadoop集群中的所有存储节点上存储文件。它能够在一般PC集群上提供牢靠的文件存储，通过备份数据块的多个副原本解决服务器宕机或硬盘损坏的问题。MapReduce:基于Java的并行分布式计算框架，是Hadoop的原生批处理引擎，也是Google的MapReduce paper的开源实现。HBase:开源分布式NoSQL数据库，参考了Google的BigTable建模。Hive:一个数据仓库工具。猪:大数据分析平台。Mahout:机器学习Java类库的汇合，用来实现各种工作，比方分类、评估聚类和模式开掘。它提供了一些经典的机器学习算法。Zookeeper:开源分布式协调服务，由雅虎创立，是Google Chubby的开源实现。在Hadoop中，次要用于管制集群中的数据，比方治理Hadoop集群中的NameNode，Hbase中的Master选举，服务器之间的状态同步等。Sqoop:用于在Hadoop和传统数据库之间传输数据。Ambari:Hadoop管理工具，能够疾速监控、部署和治理集群。 Hadoop MapReduce及其解决引擎提供了一套通过工夫考验的批处理模型，牢靠、高效、可扩大，不便人们解决海量数据。用户能够通过低成本的组件构建性能齐备的Hadoop集群，因而这种便宜高效的解决技术能够在很多状况下灵便利用。与其余框架和引擎的兼容性和集成使Hadoop成为应用不同技术的各种工作负载解决平台的底层根底。但这种解决模式依赖于长久存储，计算工作须要在集群的节点上屡次读写，所以速度会略逊一筹，但其吞吐量也是其余框架无法比拟的，这也是批处理模式的特点。流程解决流解决模式能够随时实时计算进入零碎的数据。这种模式不须要对整个数据集进行操作，而是对通过零碎传输的每个数据项进行操作。流程中的数据集是无边界的，这有几个重要影响: 残缺的数据集只能代表到目前为止进入零碎的数据总量。工作数据集可能更相干，在特定工夫只能示意单个数据项。解决是基于事件的，除非显式进行，否则没有“完结”。处理结果立刻可用，并将随着新数据的到来而更新。 咱们小学的时候都做过这道数学题:一个水池有进水管和出水管。进水管开X个小时，出水管开Y个小时，水池会灌满水多久？流量解决零碎就相当于这个水池，对来水(数据)进行解决，而后将解决后的水(数据)从出水管排出。这样数据就像水一样永不平息，在池子里解决。这种不间断地解决输出数据的零碎称为流解决零碎。流解决零碎不操作现有的数据集，而是解决从内部零碎拜访的数据。流解决零碎能够分为两种类型: 逐项解决:一次解决一条数据是真正的流解决。微批:这种解决形式将短时间内的数据作为一个微批，在这个微批中解决数据。 因为海量数据的解决须要大量的工夫，批处理不适宜对处理结果要求较高的场景。无论是逐项解决还是微批量解决，其实时性能都远远优于批量解决模式，因而流解决实用于靠近实时处理要求的工作场景，如日志剖析、设施监控、网站实时流量变动等。因为及时反馈数据变动是这些畛域的广泛要求，所以流解决实用于必须对变动或峰值做出响应并关注一段时间内变化趋势的数据。流媒体零碎畛域的出名框架有Twitter的Storm、LinkedIn的Samza、阿里巴巴的JStrom、Spark的Spark Streaming等。它们都具备低提早、可扩展性和容错性的长处，并容许你在运行数据流代码时将任务分配给一系列容错计算机并行执行。它们还提供简略的API来简化底层实现。这些框架中应用的术语可能不雷同，但它们蕴含的概念实际上是类似的。这里以暴风为例介绍一下。在Storm中，有一种用于实时计算的图构造，叫做拓扑。这个拓扑将被提交到集群中，集群中的主节点将散发代码，而后将任务分配给工作节点执行。拓扑中有两个角色:spout和bolt，其中spout发送音讯，并负责以元组模式发送数据流。Bolt负责转换这些数据流。在bolt中能够实现计算、过滤等操作，bolt自身能够随机发送数据给其余bolt。spout收回的Tuple是一个不可变的数组，对应一个固定的键值对。

download：尚硅谷大数据2022年4月开班最新数据传输在Android开发过程中，咱们常常通过用意在各个组件之间传递数据。例如，当应用start Activity(Android . content . Intent)办法开始一个新的流动时，咱们能够创立一个intent对象，而后调用putExtra()办法来传递参数。 val intent = Intent(this，TestActivity::class.java)intent.putExtra("name "，" name ")开始流动(用意)复制代码开始新流动后，咱们能够在新流动中获取传输的数据。val name = getIntent()。getStringExtra("name ")复制代码一般来说，咱们传输的数据是很小的，然而有时候咱们想传输一个很大的对象，比方位图，可能会有问题。 val intent = Intent(this，TestActivity::class.java)val data= ByteArray( 1024 * 1024)intent.putExtra("param "，data)开始流动(用意)复制代码当调用此办法来启动新的流动时，将会引发异样。Android . OS . transactiontoolargeexception:数据包大小1048920字节复制代码很显著，谬误的起因是咱们传输的数据量太大了。官网文件中有这样的形容: Binder事务缓冲区有一个无限的固定大小，目前为1Mb，由过程中的所有事务共享。因而，当有许多事务正在进行时，即便大多数单个事务的大小适中，也会抛出这个异样。 也就是说，最大缓冲区大小是1MB，这对于该过程中所有正在进行的传输对象是通用的。因而，咱们能够传输的数据大小实际上应该小于1M。比拟计划 咱们能够通过动态变量来共享数据。应用bundle.putBinder()办法实现大数据传输。因为咱们心愿将数据存储在活页夹中，所以咱们首先创立一个类来继承活页夹。数据是咱们传递的数据对象。 类BigBinder(val数据:ByteArray):Binder()复制代码那就通过。val intent = Intent(this，TestActivity::class.java)val data= ByteArray( 1024 * 1024)val bundle = Bundle()val bigData = BigBinder(data)bundle.putBinder("bigData "，bigData)intent.putExtra("bundle "，捆绑)开始流动(用意)复制代码而后失常启动新接口，发现能够跳过去，新接口也能够接管咱们传过来的数据。为什么能够这样绕过1M缓冲的限度？这是因为零碎在间接通过Intent传递时应用的是复制到缓冲区的形式，而putBinder的形式应用的是共享内存，共享内存的限度远大于1M，所以不会出现异常。

download：体系课大数据工程师2022版2.0升级版含源码ppt编程猿自学it java python go c基于springboot的国际化解决方案1底漆1.1国际化概述作为一名服务器端开发人员，这里我想从本人的角度简略概述一下国际化(国际化也叫i18n，因为I和N之间有18个字母)是做什么的: 在理论的国际化我的项目中，责任是让服务器依据客户指定的语言，返回相应语言的内容。 1.2 spring/spring boot我的项目中国际化游戏性概述在spring/springboot的世界中，国内游戏基于以下界面:org . spring framework . context . message source .该接口次要定义了以下三种办法:公共接口音讯源{//如果国际化配置文件中找不到var1对应的音讯，能够给它一个默认值var3。@NullableString getMessage(String var1，@Nullable Object[] var2，@Nullable String var3，Locale var 4)；//如果在国际化配置文件中找不到var1对应的音讯，抛出异样String getMessage(String var1，@Nullable Object[] var2，Locale var3)抛出NoSuchMessageException//这个办法临时没有做太多的钻研，所以本文也不会波及。string getMessage(MessageSourceResolvable var 1，Locale var2)抛出NoSuchMessageException}复制代码该接口的三个重要实现类如下: ResourceBundleMessageSourceReloadableResourceBundleMessageSource动态音讯源 2如何播放ResourceBundleMessage源(默认)首先咱们来看看springboot我的项目中国际化最根本的玩法: (1)构建springboot我的项目(至多增加web依赖)。Messages.properties(默认配置) 用户名=溜溜球复制代码 messages_en_US .属性 user.name=yoyo-ENuser.name1=nrscuser.name2=nrsc{0}-{1}复制代码 音讯_zh_CN.properties 用户名1=张耳User.name2=张耳{0}-{1}复制代码(3)创立一个控制器测试类@RestController公共类i18d专制控制器{@主动连线公有MessageSource messageSource @GetMapping("/hello ")公共字符串hello() {String defaultM = messageSource。getMessage("user.name "，null，locale context holder . getlocale())；字符串message1 =音讯源。getMessage("user.name1 "，null，locale context holder . getlocale())；字符串message2 = messageSource。getMessage("user.name2 "，new String[]{"WW "，" MM"}，locale context holder . getlocale())；字符串message3 = messageSource。getMessage("user.nameXX "，null，" defaultName "，locale context holder . getlocale())； ...

download：某课大数据工程师2022版2.0升级版完结无密文章参考 自学it666 https://www.zxit666.com/形容你在玩一个蕴含多个角色的游戏，每个角色都有两个次要属性:攻打和进攻。给你一个2D整数数组属性，其中properties[i] = [attacki，defensei]代表游戏中第I个角色的属性。如果一个角色的攻打和进攻等级都比这个角色的攻打和进攻等级高很多，那么这个角色就被认为是弱的。更正式地说，如果存在另一个字符j，其中attackj > attacki和defensej > defensei，则称字符I是弱的。返回弱字符的数量。示例1:输出:属性= [[5，5]，[6，3]，[3，6]]输入:0阐明:没有一个角色比另一个角色有更强的攻击力和防御力。 复制代码示例2:输出:属性= [[2，2]，[3，3]]输入:1阐明:第一个角色很弱，因为第二个角色有更强的攻击力和防御力。复制代码留神:2属性[i]。长度== 2一个复制代码剖析依据题目，咱们正在玩一个有多个角色的游戏，每个角色有两个次要属性:攻打和进攻。给定一个二维整数数组属性，其中properties [i] = [attack，defense]代表第I个字符的属性。如果另一个角色的攻打和防具等级严格高于该角色的攻打和防具等级，则该角色被称为弱角色。更艰深地说，如果有另一个字符索引J，其中attackj > attacki，defence j > defence i，则索引为I的字符称为弱字符。返回弱角色的数量。其实这个问题是对于排序的，AC一次遍历就能够实现。咱们晓得问题须要弱字符的个数，所以咱们只须要数一数。我要判断的维度有两个维度:攻击力和防御力，所以能够依照物理学中“控制变量法”的思路，先判断一个维度，再判断另一个维度。要达到这个“严格大于”的要求，首先要排序。咱们依照攻击力降序和防御力升序排序，这样在确定弱角色攻击力满足“严格小于”时，就能够通过判断弱角色防御力“严格小于”来找到弱角色。而后咱们遍历属性。如果以后角色的攻击力小于之前穿梭过的角色，就不能判断是弱角色。因为防御力是不确定的，所以为了不便，咱们要用一个变量max_defense来记录被遍历角色的最大防御力，所以如果以后角色的防御力严格小于max_defense，就阐明肯定是真角色，后果能够加一。理论须要判断攻击力雷同但防御力严格小于前一个角色的状况。然而咱们的写法能够省去这个判断步骤，因为咱们是按防御力升序排序的，这样如果以后防御力严格小于之前的最大防御力，那么攻击力肯定是不相等的，因为攻击力相等时防御力是按升序排序的。依照下面的办法，一次遍历后失去的后果就是最终后果，能够返回。工夫复杂度是O(logN+N)，N是属性的长度，因为属性要先排序再遍历，空间复杂度是O(1)，因为没有开拓新的空间。解释类别解决方案(对象):def numberOfWeakCharacters(本身，属性):""":类型属性:List[List[int]]:rtype: int"""properties . sort(key = lambda x:(-x[0]，x[1]))后果=最大进攻= 0对于_，属性中的进攻:如果进攻<最大进攻:后果+= 1否则:max_defense =进攻回送后果复制代码运行后果运行工夫:2301 ms，比游戏中弱角色数量的Python在线提交快84.75%。内存应用:69.6 MB，不到Python在线提交的游戏中弱角色数量的42.37%。复制代码

课件获取：关注公众号“数栈研习社”，后盾私信 “ChengYing” 取得直播课件 视频回放：点击这里 ChengYing开源我的项目地址：github 丨 gitee 喜爱咱们的我的项目给咱们点个__ STAR！STAR！！STAR！！！（重要的事件说三遍）__ 技术交换钉钉 qun：30537511 本期咱们带大家回顾一下漫路同学的直播分享《ChengYing装置原理分析》。 本期内容多为实战演示，欢送有趣味的同学去B站配合视频观看，便于了解。 一、ChengYing装置原理ChengYing装置次要分为上面八个模块的内容，上面为大家介绍一下每个模块次要能做的事件： 1、主机编排一个组件包外面有很多服务，指定服务装置到哪些主机。 2、抵触校验依据组件包之间的依赖关系，校验编排后果是否合乎部署条件。 3、依赖配置获取依赖服务的配置信息，注入到本身服务。 （图片为：DTUic依赖DTBase组件包的mysql服务） 4、自定义配置获取用户自定义的配置，替换组件包内已有的配置： 1）获取自定义配置 2）依据编排信息设置ip 5、卸载老服务编排记录更新，旧服务须要更换服务器装置，须要先执行卸载操作： 1）进行服务 matrix通过http stopSync接口调用agent-server，sidecar收到如下音讯，进行服务。 2）卸载脚本内容 3）卸载服务 4）执行post_undeploy 6、配置解析依据配置信息，渲染用户的配置文件。 ● 解析规定 ● 渲染案例 7、装置服务执行下载组件包的脚本，并下发配置文件： 1）下载解压安装包 （图上为：insgall_agentx.sh内容） 2）下发配置 3）执行post_deploy 4）启动服务 matrix通过http startSyncWithParam接口调用agent-server，sidecar收到如下音讯，启动服务。 8、滚动更新编排记录未变动的主机，执行滚动更新。 二、ChengYing卸载原理理解完ChengYing装置原理后，咱们来为大家分享ChengYing卸载原理： ● 依据依赖关系，先卸载最外层依赖 ● 查看服务的状态，看是否须要先进行，而后再卸载服务 三、常见问题解说1、谬误类型 2、案例1 3、案例2 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack

download：体系课-大数据工程师2022版2.0升级版大数据 https://www.sisuoit.com 极限测试:如果您在vue我的项目中一次加载2000条数据，将会呈现正告:v-on处理程序出错:“谬误:已达到渲染我的项目限度，如下所示:问题的起因js操作dom时，对dom的所有操作都会触发“重排”(包含重绘或回流)，重大影响能耗。所以要尽量减少dom操作，缩小“重排”当DOM过多时，浏览器渲染会变慢甚至卡顿。所以能够思考虚构列表，保障每次显示的DOM数量少。解决方案:Js动态创建元素 /***代码片段1*每个标签一次creatElement和appendChild。*有余:屡次appendChild会造成页面重排，影响性能。*/const node = document . createelement(' div ')；node.className = ' giftinfo设msg = data.msg//赠送礼物的用户的头像let avatar = document . createelement(' img ')；avatar . class name = " avatar "；avatar.setAttribute('src '，msg . avatar | | userDefaultImg)；node.appendChild(头像)；//礼物的用户名。let name = document . createelement(" span ")；name.className = ' name姓名；innerText = msg昵称|| '未知'；node.appendChild(名称)；//送礼类型let gif timg = document . createelement(' img ')；gift img . class name = ' img '；giftimg.setAttribute('src '，getGiftLists[msg.content])。网址)；node . appendchild(gif timg)；复制代码/***代码片段2*应用字符串拼接来缩小appendChild插入。*有余:如果各个列表的显示比较复杂，拼接的字符串容易出错，保护老本高。你有更好的打算吗？*/const Li = document . createelement(" Li ")；Li . class name = user _ id = = = item . from _ uid？own_chat':'' + item.type === 'gift '？礼品我的项目“:”；let imghtml =//图片地址let name html = ` $ { item . from _ username } `；//昵称让texthtml =//内容if (item.type === "gift") {Let giftname = `发送了一个$ { item . content . value } `；let giftimg =text html = ` $ { gift name } $ { gift img } `；}否则{texthtml = ` $ { item.content }//内容}let infotop = ` $ { namehtml }//顶部分区let item info = ` $ { infotop } $ { text html } `；//次要内容分区Li . innerhtml = ` $ { imghtml } $ { iteminfo } `；appendChildnode.appendChild(李)；复制代码应用文档片段增加DOM元素什么是文档片段？文档片段是用于长期存储所创立的dom元素的容器。因为文档片段存在于内存中，而不是DOM树中，所以在文档片段中插入子元素不会导致页面回流。当DocumentFragment节点被申请插入到文档树中时，它不是DocumentFragment自身，而是它的所有后辈。这使得DocumentFragment成为一个有用的占位符，长期存储一次插入到文档中的节点。也有利于实现文件的剪切、复制、粘贴操作。DocumentFragment节点不属于文档树，并且继承的parentNode属性始终为null。罕用办法:document . createdocumentfragment()创立一个新的空DocumentFragment节点。Range.extractContents()或Range.cloneContents()获取蕴含现有文档片段的DocumentFragment节点。文档碎片有什么用？先在文档片段中增加大量元素，再将文档片段增加到须要插入的地位，这样大大减少了dom操作，进步了性能(IE和Firefox更显著)。/***持续下面的代码片段2。*在结尾增加一句话 ...

上一篇文章具体给大家介绍了标签的设计与加工，在标签生命周期流程中，标签体系设计实现后，便进入标签加工与上线运行阶段，一般来说数据开发团队会主导此过程，但咱们须要关怀以下几个问题： ·标签如何疾速创立和实现标签逻辑的在线化治理 ·业务人员怎么参加到标签建设流程中 ·百万级别的标签如何落表 一、加工形式：传统VS在线当企业无标签零碎时，个别由数据开发在离线数仓中实现标签的加工和运行，经营或市场同学须要某个标签须要通过产品经理向数据开发提需要，这个过程存在很多问题： · 标签资产不可见：标签是存在于表里的字段，业务人员不分明当初有多少标签；标签的加工逻辑与业务逻辑是否统一只能查看SQL代码；新上线的标签只有局部人晓得，标签价值散发慢等 · 标签资产不可管：加工好的标签，有多少在真正被应用，有多少没人用，齐全黑盒，不必的标签每天持续运行节约计算与存储资源 · 标签加工效率低：当业务人员须要某个简略标签时，也须要提交需要给数据开发，加工到上线根本须要2-3天流程 基于以上这些问题，标签的在线化创立与治理显得尤为重要，在线化次要蕴含以下内容： · 标签在线化加工 · 标签在线化治理 · 标签在线化更新 其让标签加工过程以及有哪些标签变得通明，业务人员也能够参加进标签建设的流程中。 二、各类型标签加工标签类型的辨别在此处便不再赘述了。在袋鼠云智能标签产品——「客户数据洞察」中，咱们依照标签加工逻辑，将标签分为以下类型，各类型标签的加工档次如下图： 接下来，咱们来看看具体各类型标签的加工。 1、原子标签该类标签由数据开发在数仓加工中实现，个别基于数仓DWD、DWS层的明细表与汇总表加工而来，解决逻辑较为简单，同时维表中的一些字段也能够作为原子标签。这类标签个别蕴含哪些内容呢？ ● 建设用户的标签体系： 用户维表中的用户根底属性：性别、年龄、置业、会员等级、手机号、身份证号等信息，个别用户零碎会有该类信息。 ● 基于交易表加工的交易指标 最近30天购买次数、最近30天交易金额、最近7天购买次数、最近7天交易金额。这部分标签也倡议放在数仓中实现，有以下几点起因： ·因为其自身也是一个指标，除后续作为标签进行画像剖析外，也罕用于在数据门户、BI报表中剖析，可作为对外服务的指标放在ADS层中，并且市场上也会有专门指标治理的产品，来实现该指标的加工 · 这类标签若属于同一个统计维度（如都计算最近7天），数据开发能够在一个SQL片段中计算多个标签，节约计算成本 · 若业务人员间接基于DWS层的轻度汇总表（每天汇总的交易次数、交易金额）、或DWD层的明细表（每条交易记录一行数据）来加工最近30天购买次数这个标签，须要针对对应的字段进行求和，略微波及到一点SQL了解，有一些难度 故该类应用场景多、对于业务人员有计算难度，可在数仓中合并加工降低成本的标签，可在数仓中作为原子标签加工。 ● 基于行为表加工的行为指标 可通过数仓加工成如下表格局，加工行为类的标签，便于后续业务人员去衍生。 原子标签在数仓加工好后，可导入到标签零碎中，进行在线化治理。 2、规定标签该类标签配置可由数据开发或数据分析师来实现，可基于单张表或关联表中的字段进行在线化加工，可设置统计周期、数据过滤条件，其内置罕用的聚合函数（求和、均值、计数、去重技术、最大值、最小值等）、操作符（大于、小于、区间、有值、无值、蕴含等），通过规则化的在线配置实现标签加工。配置界面如以下： 依据下面的形容，该类标签能够将指标的类型的标签在数仓或指标平台加工好，导入至标签平台作为原子标签，再基于这些原子标签取操作符更好。但在理论场景中，基于不同思考，有的客户也会在标签平台间接加工此类型标签，如以下场景： · 数仓无对应的根底标签，但业务人员很着急须要该标签某标签，走失常的排期、数仓加工、测试，上线到应用根本2天以上了，基于这种状况能够通过该类标签在标签零碎间接配置，5分钟即可配置、更新实现，业务人员便能够应用了 · 客户方想把标签的加工逻辑在线化出现、不便查找与追溯，通过可视化的形式在线配置 3、SQL标签SQL标签次要由数据开发、数据分析师应用，次要解决通过规定标签无奈表白的逻辑，如用到排序函数、字符转化函数、子查问等内容，能够通过规范SQL语法灵便实现标签加工。 4、模型标签模型标签可由业务人员创立。系统集成常见的用户分层RFM模型，用户营销AIPL模型、用户生命周期模型，用户输出对应的指标值区间，便可定义对应的标签值。 以RFM模型举例，基于该模型生成“客户价值”标签。可基于最近一次购买工夫、最近一年生产金额、最近一年生产频率等几个原子标签，进行不同区间的取值，给用户打上“重要价值客户”、“重要倒退客户”、“重要倒退客户”、“重要挽留客户”等。 5、组合标签模型标签可由业务人员创立。基于已生成的原子、规定、SQL、模型标签等，进行规定衍生，生成组合标签。如组合标签“高支出低购买”用户，可通过“收入水平”衍生标签，与“最近3年生产金额区间”衍生标签组合加工，如下图： 6、自定义标签自定义标签可由业务人员创立。手动为某些用户打上标签，该类标签手动导入，常见场景如下： · 客服人员和用户ID为1001的用户沟通后，给该用户打上”性情：温和、有急躁”标签 · 如监管机构提供的一些信贷黑名单用户，该类标签可间接导入进标签零碎，为用户打上新的标签 7、算法标签算法标签由算法开发同学创立，该类标签可在算法平台实现，将算好的后果存储至Hive表中，标签零碎可获取算法标签的元数据，拿到算法标签的中文名、英文名，注册至标签零碎中，在标签零碎中实现算法标签的标签信息查看、标签查问等。 如利用机器学习模型加工预测类的算法标签，如依据用户的特色，预测哪些用户是否行将散失，散失的概率等，从而在用户散失之前做一些措施来挽留。 8、实时标签实时标签由数据开发同学创立，该类标签可在流计算平台实现，实时行为数据打入到kafka中，用FlinkSQL生产，再输入到Kafka、或数据表中，上游间接订阅或查问。 三、标签更新与落库标签配置实现后，便须要进行标签更新与落库，行将标签打到对象（如用户）的身上，这样业务同学就能够依据标签圈选指标群组啦。在此处咱们须要阐明以下几个问题： 1、技术选型首先阐明一下标签加工的技术选型，在袋鼠云智能标签产品「客户数据洞察」中咱们用的 Trino（Presto）高性能剖析引擎读写 Hive 表的形式，标签表存储在Hive中。次要有以下几点起因： · 随着国家对数字化转型的反对，从金融、政府到小企业都在建设数仓，进行数字化利用，在这个过程中，大多采纳的是分布式的Hadoop零碎作为计算存储引擎（不论是开源Hadoop，还是发行版的CDH、TDH、FusionInsight等），Hive表便是最罕用的存储模式。标签是基于数仓模型搭建进去的，与数仓用同一种存储能够节俭存储资源以及不必两种存储之间进行数据交换 · 而用Trino（Presto）的起因是其首先是一个剖析型引擎，读写速度均可；其次是其SQL语法齐备、函数丰盛、灵便，能够解决绝大多是业务场景的需要；并且反对跨库同时读取，如Trino能够同时取Hive与MySQL的数据进行数据处理 但没有一种完满的技术选型，只能贴合企业本人的业务，选取最合适的技术。在这里咱们就不剖析各种标签的技术选型了。 ...

点击查看直播回放 一、元数据与权限背景介绍开源元数据体系由来、演进及问题 开源大数据体系是指以 Hadoop 为核心的生态系统，而目前 Hive 是开源数仓的事实标准。 对于大数据的由来和倒退，要追溯到谷歌在2003 年发表的论文，论文中提出了 HDFS 和 MapReduce 两个组件。HDFS 组件最早用于解决网页存储问题，它能够部署在大量便宜的机器上，提供极佳的硬件容错能力以及存储的扩展性。MapReduce 的初衷是解决搜索引擎中大规模网页数据的并行化解决问题。同时它也是比拟通用的并行处理框架，可用于解决很多大数据场景。 尽管 HDFS 和 MapReduce 很好地解决了大数据存储和大规模数据并行处理的问题，但仍然存在几个毛病： 第一，编程门槛较高。传统的数仓工程师接触的编程接口个别是 SQL ，但 MapReduce 框架有肯定的编程能力要求。 第二，HDFS 上存储的是文件和目录，并没有存储元数据，也无奈进行查问。因而即便晓得文件的构造，也无奈对文件的内容形式变动进行治理，导致程序自身可能丢失稳定性。 基于以上痛点，以雅虎为代表的公司提出了 Apache Pig，提供 SQL-like 语言，该语言的编译器会把类 SQL 的数据分析申请转换为一系列通过优化解决的 MapReduce 运算，屏蔽了 MapReduce 细节，能够很轻松高效地解决数据；而以 Facebook 为代表的公司提出 Hive 的解决方案，在 HDFS 上提供了一层数据抽象，屏蔽了文件系统及编程模型的细节，极大升高了数仓开发人员的门槛。通过对数据及文件系统到元数据的形象，可能十分不便地进行数据共享、检索以及查看数据变更历史。这一层的元数据抽象即现在大家所熟知的 Database、Table 、Partition和 Function ，同时在元数据上又衍生出了十分靠近 SQL 语言的 HiveQL。同时后续的 Hive3.0 版本新增了 catalog 的性能，Hive4.0版本新增了 Connectors 性能。依靠于元数据, 计算引擎能够很好地进行历史的追溯。除了追溯历史 schema 变更外，元数据还有一个重要性能是爱护数据（不做不兼容的变更）。 Hive3.0实现的 catalog 性能，次要基于以下两个场景： ① 多个零碎之间可能须要 MetaStore 元数据的 Namespace，冀望可能达到肯定的隔离。比方 Spark 有本人的 catalog ，Hive 也有本人的 catalog，不同的 catalog 上能够有不同的鉴权、经营策略。 ...

download：体系课-大数据工程师2022版2.0升级版大数据 https://www.sisuoit.com 极限测试:如果您在vue我的项目中一次加载2000条数据，将会呈现正告:v-on处理程序出错:“谬误:已达到渲染我的项目限度，如下所示: 问题的起因 js操作dom时，对dom的所有操作都会触发“重排”(包含重绘或回流)，重大影响能耗。所以要尽量减少dom操作，缩小“重排”当DOM过多时，浏览器渲染会变慢甚至卡顿。所以能够思考虚构列表，保障每次显示的DOM数量少。 解决方案: Js动态创建元素/***代码片段1*每个标签一次creatElement和appendChild。*有余:屡次appendChild会造成页面重排，影响性能。*/const node = document . createelement(' div ')；node.className = ' giftinfo设msg = data.msg//赠送礼物的用户的头像let avatar = document . createelement(' img ')；avatar . class name = " avatar "；avatar.setAttribute('src '，msg . avatar | | userDefaultImg)；node.appendChild(头像)；//礼物的用户名。let name = document . createelement(" span ")；name.className = ' name姓名；innerText = msg昵称|| '未知'；node.appendChild(名称)；//送礼类型let gif timg = document . createelement(' img ')；gift img . class name = ' img '；giftimg.setAttribute('src '，getGiftLists[msg.content])。网址)；node . appendchild(gif timg)；复制代码/** ...

分享嘉宾：孙方彬 中国移动云能力核心 软件开发工程师编辑整理：Hoh Xil出品平台：DataFunTalk  导读：在云原生 + 大数据的时代，随着业务数据量的爆炸式增长以及对高时效性的要求，云原生大数据分析技术，经验了从传统数仓到数据湖，再到湖仓一体的演进。本文次要介绍挪动云云原生大数据分析 LakeHouse 的整体架构、外围性能、关键技术点，以及在私有云 / 公有云的利用场景。 次要内容包含： 湖仓一体概述挪动云LakeHouse实际利用场景01 湖仓一体概述 对于湖仓一体“湖仓一体” 是最近比拟火的一个概念，“湖仓一体” 的概念最早起源于 Databricks 公司提出的 Lakehouse 架构，它不是某个产品，而是数据管理畛域中的一种凋谢的技术架构范例。随着大数据和云原生技术的倒退和交融，湖仓一体更能施展出数据湖的灵活性与生态丰富性，以及数据仓库的成长性。这里的成长性包含：服务器的老本，业务的性能，企业级的平安、治理等个性。大家能够看到（左图），在特定业务规模前，数据湖的灵活性有肯定劣势，随着业务规模的增长，数据仓库的成长性更有劣势。 湖仓一体的 2 个关键点： 湖和仓的数据 / 元数据在不须要用户人工干预的状况下，能够无缝买通、自在顺畅地流（包含：由内向内入湖、由外向外出湖、围绕周边环湖）；零碎依据特定的规定主动地将数据在湖仓之间进行缓存和挪动，并能与数据迷信相干的高级性能买通，进一步实现麻利剖析和深度智能。次要理念随着业务数据量的爆炸式增长以及业务对高时效性的要求，大数据分析技术经验了从传统数仓到数据湖，再到湖仓一体的演进。传统基于 Hadoop 的大数据平台架构也是一种数据湖架构，湖仓一体的核心理念以及与以后 Hadoop 集群架构的区别大抵如下： 存储多种格局的原始数据：以后 Hadoop 集群底层存储繁多，次要以 HDFS 为主，对于湖仓一体来说，逐步会演进为反对多种介质，多种类型数据的对立存储系统对立的存储系统：以后依据业务分多个集群，之间大量数据传输，逐步演进到对立存储系统，升高集群间传输耗费反对下层多种计算框架：以后 Hadoop 架构的计算框架以 MR/Spark 为主，将来演进为在数据湖上间接构建更多计算框架和利用场景湖仓一体的产品状态大抵有两类： 基于私有云上数据湖架构的产品和解决方案（例如：阿里云 MaxCompute 湖仓一体、华为云 FusionInsight 智能数据湖）基于开源 Hadoop 生态的组件（DeltaLake、Hudi、Iceberg）作为数据存储中间层（例如：Amazon 智能湖仓架构、Azure Synapse Analytics）02 挪动云 LakeHouse 实际上面介绍挪动云 LakeHouse 的整体架构及对湖仓一体的摸索和实际： 整体架构 上图是咱们的整体架构图，名字叫云原生大数据分析 LakeHouse。云原生大数据分析 LakeHouse 采纳计算和存储拆散架构，基于挪动云对象存储 EOS 和内置 HDFS 提供了反对 Hudi 存储机制的湖仓一体计划，通过内置 Spark 引擎进行交互式查问，能够疾速洞察业务数据变动。 咱们的架构具体包含： 数据源：包含 RDB、Kafka、HDFS、EOS、FTP，通过 FlinkX 一键入湖数据存储（数据湖）：咱们内置了 HDFS 和挪动云的 EOS，借助 Hudi 实现 Upsert 能力，达到近实时的增量更新，咱们还适当地引入 Alluxio，进行数据缓存，来达到数据分析的 SQL 查问减速能力。计算引擎：咱们的计算引擎都是 Severless 化的，跑在 Kubernetes 中。咱们引入了对立资源拜访 / 调度组件 YuniKorn，相似于传统 Hadoop 生态体系中 YARN 的资源调度，会有一些常见的调度算法，比方共性调度，先进先出等常见的调度智能元数据：智能元数据发现，就是将咱们数据源的数据目录转化成内置存储中的一个 Hive 表，对立进行元数据管理数据开发：SQLConsole，用户能够间接在页面上编写 SQL 进行交互查问；还有 SDK 的形式，以及 JDBC/ODBC 接口；后续咱们会反对 DevIDE，反对在页面上的 SQL 开发外围性能 ...

摘要：本文整顿自阿里云开源大数据技术专家陈鑫伟在7月17日阿里云数据湖技术专场交流会的分享。本篇内容次要分为两个局部： 数据湖演进历程云原生数据湖架构一、数据湖演进历程什么是数据湖？数据湖概念于 2010 年提出，其目标是解决传统数据仓库和数据集市所面临的两个问题：其一，心愿通过对立的元数据存储解决数据集市之间的数据孤岛问题；其二，心愿存储原始数据，而非存储数据集市建设过程中通过裁剪后的数据，以防止数据原始信息的失落。过后，开源的 Hadoop 是数据湖的次要代表。 随着云计算的倒退， 2015 年，各个云厂商开始围绕云上的对象存储从新解读和推广数据湖。云上对象存储具备大规模、高可用和低成本的劣势，逐渐代替了 HDFS 成为云上对立存储的支流抉择。云上的对象存储反对结构化、半结构化和非结构化的数据类型，同时以存算拆散的架构和更凋谢的数据拜访形式反对多种计算引擎的剖析，次要代表有 AWS S3 和阿里云的OSS。 2019年，随着 Databricks 公司和 Uber 公司陆续推出Delta Lake、Hudi 和 Iceberg 数据湖格局，通过在数据湖的原始数据之上再构建一层元数据层、索引层的形式，解决数据湖上数据的可靠性、一致性和性能等问题。同时，流式计算技术如Flink、AI 技术等也开始在数据湖上有了更宽泛的利用。 同年，AWS 和阿里云也相继推出了 Data Lake Formation 等数据湖构建和治理的产品，可能帮忙用户更疾速地构建和治理云上数据湖。数据湖架构的一直演进和成熟也失去了更多客户的关注和抉择。 数据湖架构演进晚期，用户根本在 IDC 机房里基于服务器或虚拟机建设 Hadoop 集群,次要的存储为 HDFS ，支流的计算引擎为 Hive 和 Spark 等。 随着云计算的倒退，很多用户为了解决 IDC 机房在资源扩缩容和运维方面的艰难，开始抉择在云上构建本人的数据湖平台。能够抉择云上提供的大数据构建平台，比方EMR，来帮忙疾速建设和部署多个集群。 但大部分晚期用户抉择间接将云下的架构搬到云上，仍然以 HDFS为次要的存储，因而 HDFS 的问题仍然存在，比方 NameNode 的扩展性问题、稳定性问题；比方计算资源和存储资源的耦合问题等；数据也存储于集群外部，跨集群、跨引擎的数据拜访也会存在问题。 而当初更支流的抉择是数据湖架构，基于云上对象存储如OSS做对立存储。在存储之上，有一套管控平台进行对立的元数据管理、权限治理、数据的治理。再下层会对接更丰盛的计算引擎或计算产品，除了 Hadoop、Hive、Spark 等离线剖析引擎，也能够对接流式的引擎比方 Flink，Olap引擎如 ClickHouse、Doris、StarRocks 等。 二、云原生数据湖架构阿里云数据湖倒退历程阿里云在数据湖方向曾经通过了很多年的倒退。最晚期的 OSS 公布于2011年，彼时数据湖的利用场景还很少。直到 2015 年，阿里云公布了云上 EMR 产品，开始将 Hive 和Spark 放至 EMR 集群，再将数据放至OSS，存算拆散的架构开始风行。 2018年和 2019 年，阿里云相继推出了数据湖剖析DLA和数据湖构建DLF两款专门面向数据湖的产品。 2022 年推出的数据湖存储（OSS-HDFS）以及 EMR Data Lake 集群，数据湖解决方案的产品矩阵逐步形成。 ...

一、直播介绍之前的内容，咱们为大家分享了ChengYing入门介绍，以及ChengYing部署Hadoop集群实战，本期咱们为大家分享ChengYing装置原理。 本次直播咱们将具体介绍ChengYing装置原理及卸载原理，以及其中会遇到的常见问题分析，通过本次分享，心愿大家能对ChengYing有更进一步的理解。 二、直播主题ChunJun装置原理分析 三、直播工夫工夫：2022年8月31日晚 19:00--20:00（周三） 四、直播地点钉钉技术交换qun（30537511）&B站袋鼠云直播间（22920407） https://live.bilibili.com/229... 五、分享嘉宾漫路 袋鼠云运维开发专家 六、开源我的项目地址https://github.com/DTStack/ch... https://gitee.com/dtstack_dev... 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack

点亮 ⭐️ Star · 照亮开源之路 GitHub:https://github.com/apache/dolphinscheduler Apache DolphinScheduler是一款十分不错的调度工具，可单机可集群可容 器，可调度sql、存储过程、http、大数据等，也可应用shell、python、java、flink等语言及工具，功能强大类型丰盛，适宜各类调度型工作，社区及我的项目也非常沉闷，当初Github中已有8.5k的star 筹备工作浏览本文前建议您先浏览下官网的文档 文档链接：https://dolphinscheduler.apache.org/zh-cn/docs/latest/user_doc/guide/parameter/context.html 在这里，先筹备下sql表资源，以下为postgresql的sql脚本: 表构造CREATE TABLE dolphinscheduler.tmp (id int4 NOT NULL,"name" varchar(50) NULL,"label" varchar(50) NULL,update_time timestamp NULL,score int4 NULL,CONSTRAINT tmp_pkey PRIMARY KEY (id) );表数据INSERT INTO tmp (id,"name","label",update_time,score) VALUES(3,'二狗子','','2022-07-06 21:49:26.872',NULL),(2,'马云云','',NULL,NULL),(1,'李思','','2022-07-05 19:54:31.880',85);我这里应用的 postgresql 的数据库，如果您是 mysql 或者其余数据的用户，请自行更改以上表和数据并增加到库中即可~ 表及数据入库，请将tmp所属的库配置到 DS后盾->数据源核心->创立数据源 ，以下是我的配置，记住，这外面的所有数据库配置均恪守所属数据库类型的jdbc 的 driver 的配置参数，配置实现也会在DS的数据库生成一条 jdbc 的连贯地址，这点要明确～ 简略的我的项目创立及阐明因为DolphinScheduler的工作是配置在我的项目上面，所以第一步得新建一个我的项目，这样：DS后盾->项目管理->创立我的项目，这是我创立的请看下图： 筹备完我的项目之后，鼠标点进去，并进入到工作流定义菜单 页面，如下图： 简略解释下DS的根本构造首先，DS个别部署在 linux 服务器下，创立工作的用户须要在 admin账户 下创立，重要的是创立的每个工作账户须要与操作系统用户一一对应. 比方你创立了一个 test 的DS账户，那所在的服务器也必须有一个test的账户才可行，这是DS的规定。 每个用户下(除了admin外）所能创立的调度工作均在各自创立的我的项目下，每个我的项目又分为多个工作(工作流定义),一个工作下又可分为多个工作节点。 下图为工作定义 ok,如果曾经筹备好以上步骤，上面开始持续定义一个简略的调度工作～ 简略的参数传递先看表： 如图咱们先做个简略的： 如果二狗子的本名叫李思，须要取 id=1 的 name 放到id=3 的 label 中，并且更新 update_time  01在工作流定义列表，点击 创立工作流 就进入一个具体的工作(工作流)的定义,同时咱们应用的是sql工作，须要从左侧拖动一个sql工作到画布中(右侧空白处)： 拖动 sql工作 到画布会自动弹出节点定义，上图为以后节点的一个定义，重点是：数据源、sql类型、sql语句，如官网所说，如果将 name 传递到上游，则须要在自定义参数重定义这个 name 为 out方向 类型为varchar。 ...

query 启动入口Databend-query server 的启动入口在 databend/src/binaries/query/main.rs 下，在初始化配置之后，它会创立一个 GlobalServices 和 server 敞开时负责解决 shutdown 逻辑的 shutdown_handle GlobalServices::init(conf.clone()).await?;let mut shutdown_handle = ShutdownHandle::create()?;GlobalServicesGlobalServices 负责启动 databend-query 的所有全局服务，这些服务都遵循繁多责任准则。 pub struct GlobalServices {    global_runtime: UnsafeCell<Option<Arc<Runtime>>>,    // 负责解决 query log    query_logger: UnsafeCell<Option<Arc<QueryLogger>>>,    // 负责 databend query 集群发现    cluster_discovery: UnsafeCell<Option<Arc<ClusterDiscovery>>>,    // 负责与 storage 层交互来读写数据    storage_operator: UnsafeCell<Option<Operator>>,    async_insert_manager: UnsafeCell<Option<Arc<AsyncInsertManager>>>,    cache_manager: UnsafeCell<Option<Arc<CacheManager>>>,    catalog_manager: UnsafeCell<Option<Arc<CatalogManager>>>,    http_query_manager: UnsafeCell<Option<Arc<HttpQueryManager>>>,    data_exchange_manager: UnsafeCell<Option<Arc<DataExchangeManager>>>,    session_manager: UnsafeCell<Option<Arc<SessionManager>>>,    users_manager: UnsafeCell<Option<Arc<UserApiProvider>>>,    users_role_manager: UnsafeCell<Option<Arc<RoleCacheManager>>>,}GlobalServices 中的全局服务都实现了单例 trait，这些全局管理器后续会有对应的源码剖析文章介绍，本文介绍与 Session 解决相干的逻辑。 pub trait SingletonImpl<T>: Send + Sync {    fn get(&self) -> T;    fn init(&self, value: T) -> Result<()>;}pub type Singleton<T> = Arc<dyn SingletonImpl<T>>;ShutdownHandle接下来会依据网络协议初始化 handlers，并把它们注册到 shutdown_handler 的 services 中，任何实现 Server trait 的类型都能够被增加到 services 中。 #[async_trait::async_trait]pub trait Server: Send {    async fn shutdown(&mut self, graceful: bool);    async fn start(&mut self, listening: SocketAddr) -> Result<SocketAddr>;}目前 Databend 反对三种协定提交查问申请（mysql, clickhouse http, raw http）。 // MySQL handler.{    let hostname = conf.query.mysql_handler_host.clone();    let listening = format!("{}:{}", hostname, conf.query.mysql_handler_port);    let mut handler = MySQLHandler::create(session_manager.clone());    let listening = handler.start(listening.parse()?).await?;    // 注册服务到 shutdown_handle 来解决 server shutdown 时候的敞开逻辑，下同    shutdown_handle.add_service(handler);}// ClickHouse HTTP handler.{    let hostname = conf.query.clickhouse_http_handler_host.clone();    let listening = format!("{}:{}", hostname, conf.query.clickhouse_http_handler_port);    let mut srv = HttpHandler::create(session_manager.clone(), HttpHandlerKind::Clickhouse);    let listening = srv.start(listening.parse()?).await?;    shutdown_handle.add_service(srv);}// Databend HTTP handler.{    let hostname = conf.query.http_handler_host.clone();    let listening = format!("{}:{}", hostname, conf.query.http_handler_port);    let mut srv = HttpHandler::create(session_manager.clone(), HttpHandlerKind::Query);    let listening = srv.start(listening.parse()?).await?;    shutdown_handle.add_service(srv);}之后会创立一些其它服务 Metric service: 指标服务Admin service: 负责解决治理信息RPC service: query 节点的 rpc 服务，负责 query 节点之间的通信，应用 arrow flight 协定// Metric API service.{    let address = conf.query.metric_api_address.clone();    let mut srv = MetricService::create(session_manager.clone());    let listening = srv.start(address.parse()?).await?;    shutdown_handle.add_service(srv);    info!("Listening for Metric API: {}/metrics", listening);}// Admin HTTP API service.{    let address = conf.query.admin_api_address.clone();    let mut srv = HttpService::create(session_manager.clone());    let listening = srv.start(address.parse()?).await?;    shutdown_handle.add_service(srv);    info!("Listening for Admin HTTP API: {}", listening);}// RPC API service.{    let address = conf.query.flight_api_address.clone();    let mut srv = RpcService::create(session_manager.clone());    let listening = srv.start(address.parse()?).await?;    shutdown_handle.add_service(srv);    info!("Listening for RPC API (interserver): {}", listening);}最初会将这个 query 节点注册到 meta server 中。 // Cluster register.{    let cluster_discovery = session_manager.get_cluster_discovery();    let register_to_metastore = cluster_discovery.register_to_metastore(&conf);    register_to_metastore.await?;}Session 相干session 次要分为 4 个局部 session_manager: 全局惟一，负责管理 client sessionsession: 每当有新的 client 连贯到 server 之后会创立一个新的 session 并且注册到 session_managerquery_ctx: 每一条查问语句会有一个 query_ctx，用来存储以后查问的一些上下文信息query_ctx_shared: 查问语句中的子查问共享的上下文信息 ...

你是否对 OpenDAL 的设计和应用还有不解，急需一个零碎的解释去深刻理解呢？对于 OpenDAL 在 Databend 中的利用是否理解？本次直播咱们会携手旋涡老师一起为大家答疑解惑，学习并把握 OpenDAL 的应用，理解 Databend 底层如何与存储交互，感兴趣的敌人们不要错过，连忙扫描下方二维码或点击文末「浏览原文」报名约起来吧～⏰ 工夫：北京工夫 9 月 03 日上午 10:00 - 11：00（周六） 扫描上方二维码或点击文末「浏览原文」即可报名 流动报名签到有机会取得： Databend 限量周边 T-shirt！ （名额 3） 对于 DatabendDatabend 是一款开源、弹性、低成本，基于对象存储也能够做实时剖析的旧式数仓。期待您的关注，一起摸索云原生数仓解决方案，打造新一代开源 Data Cloud。 Databend 文档：https://databend.rs/Twitter：https://twitter.com/Datafuse_...Slack：https://datafusecloud.slack.com/Wechat：DatabendGitHub ：https://github.com/datafusela...文章首发于公众号：Databend

https://www.bilibili.com/vide...

This article was originally published on InfoWorld on March 22, 2022.Reprinted with permission. IDG Communications, Inc., 2022. All rights reserved. Orchestrating data for machine learning pipelines. 作者导读人工智能（AI）和机器学习工作负载依赖大型数据集，并且对数据吞吐量有较高的要求，两者都能够通过优化数据工作流来实现。 当进行 AI 模型训练时，咱们须要高效的数据平台架构来疾速生成剖析后果，而模型训练在很大水平上依赖于大型数据集。执行所有模型训练的第一步都是将训练数据从存储输送到计算引擎的集群，而数据工作流的效率会大大影响模型训练的效率。 数据平台/AI 平台工程师在数据架构和数据管理方面须要思考以下几个问题： 数据可拜访性：当数据逾越多个数据源且存储在远端时，如何高效地获取训练数据？数据工作流治理：如何把数据作为工作流来治理，在训练流程中无需期待，保证数据的继续供应？性能和 GPU 利用率：如何同时实现低元数据提早和高数据吞吐量，确保 GPU 始终处于繁忙状态？本文将针对上述端到端模型训练数据流问题，探讨一种新的计划——数据编排计划。 文章首先会剖析常见的挑战和误区，而后介绍一种可用于优化 AI 模型训练的新技术：数据编排 AI 模型训练中的常见挑战端到端机器学习工作流是蕴含从数据预处理和荡涤到模型训练再到推理的一系列步骤，而模型训练是整个工作流程中最重要且资源最密集的环节。 如下图所示，这是一个典型的机器学习工作流，从数据收集开始，接着是数据筹备，最初是模型训练。在数据收集阶段，数据平台工程师通常须要破费大量的工夫来确保数据工程师可能拜访数据，之后数据工程师会对数据科学家搭建和迭代模型所需的数据进行筹备。 训练阶段须要解决海量的数据，确保 GPU 可能继续获取数据，从而生成训练模型。因而咱们须要对数据进行治理，使其可能满足机器学习的复杂性及其可执行架构的需要。在数据工作流中，每个步骤都面临相应的技术挑战。 数据收集上的挑战——数据无处不在数据集越大，越有助于模型训练，因而收集所有相干数据源的数据至关重要。当数据分布在本地、云上或者跨区域的数据湖、数据仓库和对象存储中时，将所有的数据集中成繁多数据源的做法不再可行。鉴于数据孤岛的存在，通过网络近程拜访数据难免会造成提早。如何在实现所需性能的同时确保数据可被拜访成为微小的挑战。 数据筹备上的挑战——串行化的数据筹备数据筹备从收集阶段的数据导入开始，包含数据荡涤、ETL 和转换，最初再将数据用于模型训练。如果孤立地思考这个阶段，则数据工作流是串行化的，训练集群在期待数据筹备的过程中会节约大量工夫。因而，AI 平台工程师必须想方法创立并行化的数据工作流，实现数据的高效共享和两头后果的无效存储。 模型训练上的挑战——受制于 I/O 且 GPU 利用率低模型训练须要解决数百万亿字节的数据，但通常是图像和音频文件等海量小文件。模型训练须要屡次运行 epoch 来进行迭代，因而会频繁地拜访数据。此外, 还须要通过一直向 GPU 供应数据来让 GPU 处于繁忙状态。既要优化 I/O 又要放弃 GPU 所需的吞吐量并非易事。 传统计划和常见误区在探讨不同的解决方案之前，咱们先来看一个简化的场景，如下图所示： 咱们在云上应用一个多节点的 GPU 集群，并把 TensorFlow 作为机器学习框架来进行模型训练。预处理的数据存储在亚马逊 S3 中。一般来说，让训练集群获取这些数据有两种计划，咱们接下来会别离探讨： ...

一、窘境频生 前端代码治理何解？前端代码治理始终是困扰不少前端开发团队的难题，从开发到公布的整体工作流程中，除了惯例的技术问题外，往往还随同着沟通老本、保护老本及合作效率等问题。这些问题在团队规模较小的时候可能不太显著，然而当团队规模变大时就矛盾越发凸显。 数栈前端开发团队负责着离线开发，实时开发，数据服务等多条产品线的开发和保护工作，面对泛滥的产品线，如何正当的治理代码，成了团队须要思考的问题，尽管借助了Multirepo进行治理，但还是遇到了许多难题： ● 公有源保护成本增加 为复用相干业务逻辑，团队外部形象出一些公有包，因为不能在公网裸露，为了治理这些公有包团队应用了公有源，但因为搭建公有源服务器资源问题，公有源经常不稳固且下载速度慢，特地是对于须要源码交付的某些客户来说，装置这些公有包更会遇到各种问题，交付的工夫和人力老本大大升高。 ● 逻辑难复用，反复造轮子 各个仓库中会形象出同一性能的组件，组件之间的共享往往难以同步，造成了「反复造轮子」等景象。 ● 工具/配置不对立，沟通老本高 各个仓库所应用的工具和配置没有进行对立，在进行配置更新等的过程中，往往须要同步到各个产品线负责人，沟通老本较高。 这些问题重大拖慢了数栈前端团队从开发到公布的整体流程，同时减少了团队的保护老本和沟通老本，如何寻找新的工具解决这些问题已火烧眉毛，在进行了深刻调研和屡次探讨的过程中，新的项目管理形式Monorepo 在这时映入了咱们的眼帘。 二、MultirepoVSMonorepo那么Multirepo和Monorepo到底是什么呢？其实他们别离代表的是两种前端代码治理形式： MultirepoMultirepo是一种分散式的前端代码治理形式，依照性能或其余维度，将我的项目拆分为不同模块并独自保护于各自仓库中。作为传统的治理形式，Multirepo具备灵便度高、安全控制等特点，但同时也带了治理老本和写作老本的减少，依赖降级等问题。 MonorepoMonorepo是集中式治理的前端代码治理形式，将所有的我的项目在集中一个代码仓库中进行治理，严格的对立和收归，有利于对立的降级和治理。作为新型的治理形式，Monorepo无效升高了经营及合作老本，但一个代码仓库的管理模式带来了我的项目体积的回升，获取工夫缩短，同时安全性也有所降落。 上图为Multirepo和Monorepo比照图，从图中咱们能够简要演绎： Multirepo是由多个仓库组成的项目管理形式，每个仓库有着独立的工作流、组件与配置Monorepo则将不同仓库整合成为一个仓库，并共享工作流、组件与配置。两种治理形式各有千秋，不能简略的定义哪种形式更好，但Monorepo的共享机制、对立治理及合作成本低等劣势，显然更合乎深陷简单产品线挑战的数栈前端团队的需要，抉择Monorepo也是团队摸索效率晋升的必然路线。 三、适合才最好 Monorepo计划布局确定了新的治理形式后，接下来面对的就是如何与数栈相适配的问题。市面上对于Monorepo的解决方案和相干工具有很多，尽管rush、nx 之类的工具可能在特定的畛域提供较好的解决方案，但却并不合乎咱们的理论需要。 在调研了社区的各种Monorepo实现和解决方案之后，联合咱们本身的业务场景和需要，最终咱们抉择了pnpm和turborepo作为底层的包管理工具和任务调度工具，因为只有最合适的产品才是最好的解决方案。 ● 包管理工具-pnpm在前端社区中，npm、 yarn、 pnpm 三个包管理工具三足鼎立，而咱们最终抉择了pnpm起因在于：pnpm对monorepo有着较好的反对，同时对比其余两个包管理工具，pnpm在性能等各个方面有着显著的劣势： ● 任务调度工具-turborepo任务调度方面，社区中也存在很多优良的工具，如 rush、nx、lerna、turborepo等，综合比照之后，咱们抉择了配置简略易懂、调度更加迷信的turborepo作为咱们的任务调度工具： 四、一直摸索 Monorepo落地实际在确定了底层包管理工具和任务调度工具后，数栈&Monorepo整体架构计划也就明确了： Monorepo解决了之前应用Multirepo时存在的问题，帮忙咱们更好的治理代码，接下来咱们将联合Multirepo存在的问题来具体阐明Monorepo是如何在数栈产品中落地的。 ● 对立配置Multirepo存在的一个显著问题是配置的不对立导致的难以保护，所以咱们须要对格式化、代码检测、打包等相干流程的配置进行规范化和对立，同时针对不同产品线的细微差别，也须要反对其灵便的扩大。因而咱们在Monorepo仓库的根目录提供了对立的根底配置，同时如须要进行调整，不同产品线能够继承该配置并进行必要的批改。 ● 逻辑复用Multirepo存在的另一个显著问题就是逻辑难以复用，迁徙之前的逻辑复用次要是靠形象到公有包并公布，或者间接复制粘贴，整体效率低，流程长且难以保护。迁徙之后咱们对各种配置等进行了对立的同时，也将专用的业务逻辑和组件整合到了仓库根目录的packages目录下，同时通过pnpm的 workspace protocal 链接到各个产品线中以复用。这样不仅解决了逻辑复用的相干问题，同时公有源也不必进行保护，Multirepo下的公有源保护老本问题得以解决。 ● 权限校验当根底配置和公共逻辑被裸露进去之后，就面临着这些内容能够被随便批改的问题，而这往往会影响所有的产品线，稍有不慎会有造成巨大损失，因而咱们须要给这些重要的内容施以限度和爱护。 咱们基于git hooks做了一些工作，在pre-commit和pre-push阶段别离对权限和分支名等内容进行了校验，并定义了Maintainer、Owner、Deverloper 三个角色，对应的权限别离为： Maintainer: 领有全副权限，能够批改包含根底配置文件等的所有内容。Owner: 各产品线或者公共组件次要负责人，领有对应范畴内的所有权限。Developer: 该产品线或者公共组件的辅助开发人员，只领有包含开发新性能等的局部产品线权限。角色权限进行明确的划分之后，咱们能够将根底配置和公共逻辑等内容的批改交给更有教训的工程师。同时权限调配配置保护在本地，这样能够更清晰的理解不同产品线对应的人员，不便沟通。 ● 自动化迁徙从 Multirepo迁徙到 Monorepo如果采纳手动的形式一一迁徙会有如下问题: 1.迁徙前的各产品线仓库存在多个版本须要保护，手动迁徙多个版本工作内容反复且效率较低。 2.人为的操作往往会出错，且出错时沟通老本较高。 因而咱们在迁徙的过程中实现了自动化的迁徙流程，次要流程如下: 1.主动克隆原仓库的指标分支内容到Monorepo删除须要对立的配置如commitlint等配置； 2.删除须要对立的配置如commitlint等配置； 3.删除babel, webpack等相干反复依赖； 4.检测并替换通过pnpm的 workspace protocal 链接的外部依赖引入形式； ...

ChunJun社区的开发者们 请您查收一份来自杭州的邀请函 8月27日下午14:00-17:00 杭州·方远海智核心8号楼 ChunJun将联结OceanBase举办线下Meetup 《构建新型的企业级数仓解决方案》 邀请您一起共享开源盛会 仅限50个席位 机会不容错过！ 让咱们一起探讨开源框架体系下，如何构建新型的企业级数仓解决方案，更有OceanBase&ChunJun联结解决方案首次公布，让咱们一起共聚杭州，共享开源！ 报名链接：OceanBase&ChunJun联结Meetup 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack

作者｜徐榜江 余文兵 赵红梅 随着大数据的迅猛发展，企业越来越器重数据的价值，这就意味着须要数据尽快达到企业剖析决策人员，以最大化施展数据价值。企业最常见的做法就是通过构建实时数仓来满足对数据的疾速摸索。在业务建设过程中，实时数仓须要反对数据实时写入与更新、业务麻利疾速响应、数据自助剖析、运维操作便捷、云原生弹性扩缩容等一系列需要，而这就依赖一个弱小的实时数仓解决方案。阿里云实时计算 Flink 版（以下简称“阿里云 Flink”）提供全增量一体化数据同步技术、弱小的流式 ETL 等能力，反对海量数据实时入仓入湖。阿里云 Hologres 作为新一代实时数仓引擎能同时解决 OLAP 多维分析、在线服务、离线数据减速等多个业务查问场景，通过阿里云 Flink 与 Hologres 的强强联合，实现全链路的数据摸索实时化、数据分析麻利化，疾速助力业务构建企业级一站式实时数仓，实现更具时效更智能的业务决策。 在本文中，咱们将会介绍阿里云 Flink、阿里云 Hologres 在构建实时数仓上所具备的外围能力以及二者联合的最佳解决方案，用户通过阿里云 Flink+Hologres 实时数仓解决方案，能够显著升高数仓建设门槛，让数据施展更大的价值，助力各行各业实现数字化降级。 Flink CDC 外围能力Apache Flink 是开源的大数据流式计算引擎，反对解决数据库、Binlog、在线日志等多种实时数据，提供端到端亚秒级实时数据分析能力，并通过规范 SQL 升高实时业务开发门槛。随同着实时化浪潮的倒退和深入，Flink 已逐渐演进为流解决的领军角色和事实标准，并蝉联 Apache 社区最沉闷我的项目。 Flink CDC 是阿里云计算平台事业部 2020 年 7 月开源的一款数据集成框架，与 Flink 生态深度交融，具备全增量一体化、无锁读取、并发读取、分布式架构等技术劣势，既能够代替传统的 DataX 和 Canal 工具做数据同步，也反对数据库数据实时入湖入仓，同时还具备弱小的数据加工能力。 在构建实时数仓的过程中，数据采集是必须的组件。在传统的 ETL 架构里，采集层国外用户通常抉择 Debezium，国内用户则习惯用 DataX 和 Canal，采集工具负责采集数据库的全量数据和增量数据。采集到的数据会输入到消息中间件如 Kafka，而后通过 Flink 计算引擎实时生产消息中间件数据做计算层的数据荡涤和数据加工，加工实现后再写入目标端（装载层），通常是各种数据库、数据湖和数据仓库。在传统 ETL 链路中，数据采集工具与音讯队列是比拟重的组件，可能保护在不同的团队，在上游的数据源有业务变更或者这些组件须要降级保护时，整个链路的保护老本会十分大。 通过应用 Flink CDC 去替换上图中的数据采集组件与音讯队列，将采集层（Extraction）和计算层（Transformation）合并，简化了整个 ETL 剖析链路，用户能够应用更少的组件实现数据链路的搭建，整体架构带来更低的运维开销和更少的硬件老本、更好的数据链路稳定性、以及升高端到端的数据提早。除了稳定性的晋升，Flink CDC 的另一个劣势就是用户只须要写 SQL 脚本就能实现 CDC 数据的荡涤，加工和同步，极大地升高了用户应用门槛。 ...

在7月28日的袋鼠云2022产品发布会上，基于对当初与将来的畅想，袋鼠云产研负责人思枢正式公布了全新的四大产品体系。 其中的数栈DTinsight，置信大家都很相熟了，不同于数驹这位新敌人，数栈作为袋鼠云和大家常常见面的“老朋友”，在放弃初心的同时，这次也有了一些不一样的变动。 作为袋鼠云打造的一站式大数据开发与治理平台——数栈DTinsight，包含离线数据开发、实时数据开发、数据服务、数据资产四款产品，在数据采集、加工、对立服务的根底上，将全域数据资产汇聚、数据治理交融其中，极大地缩短了数据价值的萃取过程，进步企业提炼数据价值的能力。 以下为思枢演讲全文：接下来我来为大家介绍一下“老朋友”数栈DTinsight，如何面向数据提供一站式数据开发与治理能力，帮忙企业实现数据价值出现。 一、惊喜变动 数栈全新起航晚期企业在进行数据价值化建设过程中，为了更好的服务下层业务需要，从业务需要登程，驱动后端业务零碎及对应数据库建设，这在肯定水平上满足了下层业务需要。但随着业务需要的增多，业务复杂性的减少，相干的问题也裸露了进去：如超过TB级以上海量数据的剖析能力差，各个业务板块数据进行交融剖析难度高，面向多变市场的灵活性业务需要难满足等。 原有的基于业务需要疾速迭代开发而造成的烟囱式业务零碎，无奈满足当下数字化场景需要，迫切需要一个可能解决多源异构数据源、PB级数据存储、弱小剖析引擎、规范数据标准，且灵便便捷的全新“零碎”，而数栈DTinsight也由此而生。 数栈DTinsight，对标一站式数据开发与治理，在面向多源异构数据源时，通过数据汇聚能力实现全域数据买通，而后通过数栈多年教训造成的数据治理方法论，在数据开发过程中，造成数据资产，实现数据治理工作，并通过数据服务能力，将高质量的数据高效共享，为报表剖析、决策分析等提供数据撑持，赋能各行各业。 在整个过程中数栈聚焦数据问题，买通数据链路，将全域数据资产汇聚，对立数据治理交融其中，缩短数据价值的萃取过程，加强企业提炼数据价值的能力，为企业提供一站式解决方案。 请大家看数栈的产品架构图： 在数栈整个产品的设计过程中，次要分为四大模块，别离是用于批工作的离线开发平台、用于实时工作的实时开发平台、用于数据治理的数据资产平台、用于数据服务的数据共享服务平台。 整个数栈通过集成自研的数据集成框架ChunJun对接30+异构数据源，包含传统的关系型数据库、NoSQL数据库HBase、文档数据库MongoDB、国产数据库达梦等，将数据对立存储在数驹或其余大数据平台，包含开源Hadoop体系以及商业版CDH、TDH、FI等，也能够存储在数仓引擎中包含GP、TiDB等，而后在这之上发展基于DataOps理念的数据价值化流程。 同时数栈各个板块基于解耦化的设计，可能基于客户需要灵便搭配，如离线+API实现传统数仓体系搭建，离线+资产+API构建数据治理体系，实时+API构建实时数仓等。 在这里也重点讲下数栈在DataOps理念下的实际。DataOps是一种合作式数据管理的实际，致力于改善组织中数据管理者与使用者之间数据流的沟通，集成和自动化。 数据开发同学在实现一个ETL工作的过程中，个别须要通过数据源的筹备—数据同步—数据查看—数据处理—数据校验—数据分析这6个步骤。在这过程中： ● 继续开发 数栈提供了SQL IDE、Gitlab等开发工具，来反对麻利的数据开发工作； ● 间断测试 数栈提供丰盛的sql测试集和性能测试，达到保障数据准确性的作用； ● 继续部署 数栈提供一键式测试工作到生产工作的公布和大规模工作流的自动化编排； ● 数据治理 数栈提供元数据的自动化生命周期治理和全链路的数据血统解析。 二、五大个性 数栈核心理念说了这么多，接下来重点聊聊数栈的产品个性，次要蕴含以下几点： ● DataOps 基于DataOps设计理念，数栈实现了数据全生命周期的品质监管和数据开发流程标准，为数据治理保驾护航； ● 数据还原 数栈不仅仅可能实现数据实时同步，也能实现源端数据结构到目标端的实时还原，真正做到数据复现，残缺对立； ● 金融级平安 数据的全域买通在放慢了数据价值化出现过程的同时，也放大了数据安全隐患问题。数栈基于系统安全、数据安全、服务平安和行为审计四大维度，实现数据安全管控，操作有迹可循，防止数据泄露，保障数据安全高效地共享服务； ● 全域数据治理 通过买通数据壁垒，建设基于对立数据规范和数据模型，监控数据品质，造成高质量的数据资产，为下层业务提供便捷的数据服务，并能生成品质报告，一直优化数据，继续赋能数字化场景； ● 兼容凋谢 数栈秉承凋谢兼容的设计理念，兼容多种底层计算引擎包含开源Hadoop体系、商业Hadoop版本和多种数仓引擎，在国产信创路线上兼容多种国产操作系统、国产数据库、国产服务器以及国产芯片。同时本着基于开源回馈开源的思维，数栈也将外围组件进行了开源，包含数据集成框架ChunJun、百万级调度引擎Taier。 三、赋能业务 数栈利用场景说完产品个性，接下来通过介绍三个数栈的理论利用场景，以点及面地帮忙大家更好得了解数栈。 数栈X金融场景咱们都晓得随着挪动APP的衰亡，咱们的金融交易不再局限于银行柜台，通过手机就能够实现各种各样的金融流动，这加大了金融交易的安全隐患，社会上因金融欺骗而被骗取钱财的新闻不足为奇。如何保障在海量金融交易过程中，进行金融交易行为的危险评估，保障消费者的权利是时下金融客户急需解决的问题。传统的数据分析模式，因数据规范不对立、数据品质差，导致数据分析逻辑简单，耗时周期长，无奈做到及时反馈后果，等发现时已为时已晚。 袋鼠云帮忙金融客户借助数栈一站式数据开发与治理的能力，汇聚金融各种交易数据，构建金融的实时数仓，实现数据分析的毫秒级响应，让消费者在享受金融交易便捷性的同时，无感剖析交易危险，防止金融欺骗等高危操作，同时对交易行为进行实时推送、异样行为实时预警，助力平安金融的构建。 数栈X水务场景咱们晓得在冬季，一些河流较多的城市容易产生洪涝，一旦降雨增多，还会附带泥石流等灾祸因素，对应的各级政府在旱季对于洪涝抢险救灾一贯是时刻关注。但传统的监控无奈做到精准的灾祸预警和灾后的应急响应，造成大量的国家资产损耗，甚至是人员伤亡。 袋鼠云数栈基于河流以及环境监测数据等，制订事先、事中、预先三步走策略，通过事先实时监测，包含降雨、水位等，实时将数据反馈到监控大屏中；而后在事中进行实时预测，包含降雨预测、灾祸预警等，将将来可能产生的事件实时展现到大屏中，为灾祸做好预防筹备，及时告诉人群疏散，最大水平防止人员伤亡；最初实现预先响应，对以后灾情进行统计分析，为抢险救灾提供数据决策撑持，正当调配人员安顿，最大水平防止国家财产损失。 数栈X团体港口场景对于一个港口而言，货物吞吐量是掂量港口能力的一个因素，如何最大化进步港口货物吞吐是所有港口始终在思考的问题。传统的港口调度因各个区域的职责所属，无奈感知全港口的货物走向，只能基于本身区域进行人员的调配和车辆的调配，实现区域内的“部分最优”，某种程度上进步了港口的货物吞吐量，无奈实现“全局最优”。 袋鼠云数栈从全港口角度登程，买通全港口数据信息，感知全港口货物走向，理解各区域货物吞吐速率，针对“拥挤”区域，进行资源歪斜和人员调配，同时感知“将来货物”量，及时做好资源筹备，最大水平上进步全港口的人员与车辆调度能力，实现港口货物吞吐量的最大化，让“信息化”港口降级为“智慧化”港口。 四、不忘初心 数栈砥砺前行从2016年推出数栈算起，一晃眼，数栈曾经走过了第六个年头，将来数栈将持续秉持初心，在一直打磨本身的同时，谋求更深层次的冲破。 将来布局 · 资源分配：从传统的定值设定，到联合工作负载，进行精细化参数调节，实现更加高效的资源利用。 · 数据共享：建设按需共享模式，实现企业内的跨业态、跨部门的教训分享，积淀企业内的数据知识库，满足更高的数据共享需要。 · 数据监控：实现自动化干涉数据，依据每日的工作运行状况等多维度信息建设零碎自诊断能力，及早预测、发现、干涉数据问题，变被动为被动。 · 数据校验：实现智能化规定创立，主动扫描SQL和表信息，获取不合规因素，主动建设正当的数据校验规定，升高手动配置工作量。 ...

课件获取：关注公众号“ChunJun”，后盾私信 “课件” 取得直播课件 视频回放：点击这里 ChunJun开源我的项目地址：github 丨 gitee 喜爱咱们的我的项目给咱们点个__ STAR！STAR！！STAR！！！（重要的事件说三遍）__ 技术交换钉钉 qun：30537511 本期咱们带大家回顾一下六六同学的直播分享《ChunJun数据传输模块介绍》。 一、ChunJun数据类型转换1、类型转换解决的问题大家一听到「ChunJun数据类型转换」这个概念，可能会联想到上下游之间进行数据交互时会波及到的隐式转换。如果上游和上游数据类型统一，则不须要对数据进行任何干涉，间接进行下发即可。 然而大多数状况下会波及到两个问题，一是上游的数据源类型和上游的数据源类型不统一。比方MySql的varchar类型要写到HdfsOrc文件里的string类型的话，在上游的示意是varchar，在上游的示意是string，但实际上两头段java的类型都是string。 另外一种状况则是，上下游之间不止数据源类型不一样，数据类型也不一样，除了要做类型的映射之外，还须要对数据自身进行改变。比方，MySql的date类型要写到上游timestamp类型，咱们须要进行的操作是把date中的毫秒级的工夫戳拿进去，转换成timestamp的类型，再往上游去写。 这样就引出了一个问题，如何建设所有数据源类型之间的映射/转换关系？上面将为大家解答这个问题。 2、类型映射概览• client端：在Factory类中通过RawConverter类建设映射关系 • source端：将数据封装成AbstractBaseColumn • sink端：通过AbstractBaseColumn中的转换方法将数据转换成对应类型 ChunJun目前反对的数据类型映射关系图如下： 3、类型映射详解以Timestamp为例，如果要写入到Long类型的话，依据上文展现的ChunJun数据类型映射关系图，最终映射到TimestampColumn中，具体流程如下图： 下面这个例子形容的是一个独自的字段，失常状况下，会解决多个字段，这时的类型映射详解状况如下图： as办法就是数据类型转换的办法。应用这个机制之后，在上游能够只关怀须要的数据类型，减少开发效率。 二、ChunJun数据传输过程理解完ChunJun数据类型转换后，咱们来为大家分享ChunJun的数据传输过程。 1、上下游数据传输方式在ChunJun中进行同步作业，有两种状况，一是算子链关上的状况，上游的Source和上游的Sink会被合并成一个task，有同一个线程去做调度；二是把算子链进行敞开，Source和Sink各自造成一个task，也有各自的线程去进行调度。 在算子链关上的状况下，上下游数据传输方式可分为两种，对象重用和拷贝。 ● 对象重用 · 上下游数据传输应用办法调用的模式，将上游产生的数据的对象援用间接交给上游 · 上下游算子须要造成算子链，作业开启对象重用 · env.getConfig().enableObjectReuse(); ● 拷贝 · 上游传输给上游的数据，须要通过一次深拷贝 · 上下游算子须要造成算子链 算子链的益处是能够缩小序列化的操作，那么为什么咱们还要引入序列化呢？因为ChunJun的特殊性。ChunJun同步作业的话，只有上下游两个算子，且都对接了正式的数据源，读写的时候会导致线程梗塞。因而下限由网络io决定，如果断开算子链，cpu会在一端线程阻塞的时候切换到另外一端。在序列化的性能较高时，线程上下文切换带来的性能降落齐全能够被补救。 通过测试，序列化的性能比对象重用和拷贝高30%左右。 ● 序列化 · 上下游数据传输依赖于网络传输。上游数据进行序列化成byte数组后进行网络传输，上游收到数据后须要进行反序列化 · 上下游之间不造成算子链 晓得要做序列化后，会产生一些思考，带着这些疑难，接着往下看。 • 序列化和反序列化在什么时候产生？ • Flink反对哪些序列化？ • 序列化是怎么做的？ • 怎么找到适宜的序列化形式？ • 如何实现自定义的序列化？ 2、序列化传输过程下图是ChunJun在进行序列化操作时的数据传输链路图： ...

从车间生产线的人工手动组装到智能机械臂几秒实现所有环节从关山迢递奔赴现场解决难题到运维平台实时查看设施运行状况工业制作正随着信息化和工业化的深度交融变得更加高效、智能。 在“中国制作2025”策略和“工业4.0”浪潮下，云计算、大数据、人工智能等新一代信息技术正在和传统制造业相交融，工业互联网的时代曾经到来。往年工业互联网已第五次被写入政府工作报告。五年间，从“嫩芽初露”到“百花齐放”，工业互联网从摸索起步进入到深入利用的新阶段。 随着工业互联网建设逐渐“走深向实”，越来越多的头部企业意识到，一个成熟的工业互联网平台，对于制作效率晋升有着强劲的推动作用。 在工业互联网平台建设中，数据是根底，平台是外围，平安是保障。如何做到三者的有序对立，让工业制作领有更强的“数字内核”？天翼云给出了答案！ 某团体是一家国家高新技术企业，致力于水煤浆协同处理城市生存污泥的技术研发。作为国家质检总局认证的A级制作企业，该团体在水煤浆细分畛域市场份额达90%以上，在国内居于遥遥领先的位置。 随着业务规模不断扩大，该团体产品逐步销往全国，要求团体必须对产品最终流向及治理进行更为严格的把控。在工业化、信息化交融大背景下，政府踊跃推动产业降级，该团体心愿以此为抓手，着手建设工业互联网平台，以解决业务痛点并推动业务实现进一步倒退。 针对团体现有运维平台数据连通性差、模块孤立、平台访问量大、实时性要求高，以及平安防护能力匮乏等难点，该团体要求新建的工业互联网平台必须具备高可靠性，确保业务全年无中断，保障终端节点泛在拜访品质，并具备残缺的数据安全防护能力。 天翼云从客户需要登程，向客户提供云+平安一体化能力，提供云主机、弹性负载平衡等服务搭建容器化利用、云网关中间件、工业数据湖平台，同时装备WAF、服务器安全卫士等产品进行平安防护。▪  数据层面：天翼云提供高性能云主机、弹性负载平衡服务构建高并发架构，解决大并发数据拜访的难题；海量资源储备，为外围容器微服务平台扩容提供保障。▪  平台层面：平台主域名下的子域名全指向同一主机地址，缩小分站零碎反复新增解析记录，减少平台拜访流畅性。▪  平安层面：天翼云联合云上“一个核心三重防护”平安产品组合实现内生平安，同时全面对齐等保2.0体系下工业信息安全防护扩大规范，为该平台提供满足国家工信规范的平安承载能力。 在天翼云的加持下，该团体的工业互联网平台实现了数据资源汇聚和公司治理的有序协同。平台部署后，可为企业升高5%~15%能耗，实现节能与环境协同治理。同时，基于平台的数据处理及决策能力，该团体可为旗下400家客户提供在线产品监测、远程管理运维等便捷服务，升高20%~50%售后人力保护老本。 工业互联网已成为大势所趋，将一直重构并优化工业制作倒退之路。天翼云也将与行业同频共振，继续放慢云上能力输入，助推工业制作“两化”交融转型倒退！ 

介绍Alluxio让计算引擎实现在任何云环境中的数据编排。Alluxio对立了本地和跨云环境下的数据孤岛，实现数据本地性、可拜访性和弹性，从而升高大数据和人工智能/机器学习（AI/ML）工作负载的治理数据和拜访数据的难度。 Alluxio能够帮忙所有计算框架高性能地拜访任何环境下的数据存储，让企业可能疾速地测试和利用新技术，从而放弃敏捷性和竞争力。 一、Apache Ranger目前，许多企业从最后的提取-转换-加载（ ETL）和批处理剖析的架构，演进到了集中式的数据湖的架构，这对集中式定义和管制准确的拜访权限提出了要求。越来越多的企业数据管理者通过应用Apache Ranger来满足这一需要。 Apache Ranger是用于启用、监控和治理整个Hadoop平台综合数据安全的框架1，可满足以下需要： 提供集中的平安治理，在central UI上或通过REST APIs治理所有与平安相干的工作。为Hadoop组件/工具执行特定的命令和/或操作时提供精密的受权，并通过集中管理工具进行治理。对所有Hadoop组件中的受权办法进行标准化反对不同受权办法的——基于角色的访问控制、基于属性的访问控制等。在Hadoop的所有组件中集中审核用户（与平安无关的）拜访和治理操作。 二、Alluxio和Apache RangerAlluxio实现虚构文件系统，容许对异构数据存储拜访，并提供对立的命名空间以及元数据缓存、数据缓存和基于策略的数据管理服务。为确保Alluxio虚构文件系统的安全性，Alluxio提供下述性能： 用户验证（User Authentication）用户受权（User Authorization）权限治理清单（ACLs）数据门路受权客户端侧Hadoop用户模仿审计（Auditing）加密Alluxio通过Ranger插件与Apache Ranger集成，反对用户受权和审计，如图2所示。 当Apache Ranger管理员在Ranger中定义集中的拜访策略后，Alluxio master节点能够检索到这些策略并缓存在本地，当用户向Alluxio虚构文件系统收回读写申请时，Alluxio会强制执行这些策略。 三、最佳实际Alluxio反对应用Apache Ranger来治理和管制目录和文件拜访。在Alluxio中应用Ranger有以下两种办法： 应用Ranger来间接治理Alluxio虚构文件系统门路的拜访权限。如果Alluxio底层文件系统（UFS）并非HDFS，或者有两个及两个以上底层文件系统应用Alluxio的对立命名空间性能，并且Alluxio将成为次要的拜访层时，应应用该办法。例如，HDFS UFS和兼容S3的UFS可能同时通过UNION UFS挂载到Alluxio。通过Alluxio对HDFS底层文件系统执行现有的Ranger策略。如果Ranger治理现有的HDFS拜访策略，并且除了HDFS之外没有其余的底层文件系统，则能够应用该办法。尽管Alluxio和底层文件系统的权限都能够应用Ranger来治理，但不倡议同时启用二者，因为多个数据源容易造成麻烦。 选项一：Ranger治理Alluxio文件系统权限如果应用该选项，须要在Ranger治理控制台中启用Alluxio服务插件。因为Alluxio应用HDFS Ranger插件类型，可在服务管理器页面中定义新的HDFS服务。 第一步：创立Alluxio HDFS服务在Ranger治理控制台的服务管理器页面上，点击加号（+）来创立新的服务。 Ranger上会显示创立服务页面，其中Alluxio master节点将被援用为指标服务。在该页面中，输出Alluxio服务的详细信息，包含惟一的服务名称。如果存在多个Alluxio环境，例如：一个用于开发，一个用于测试，还有几个位于不同数据中心的生产环境，那么Alluxio服务应应用具体的名称（例如alluxio-datacenter1-test）。同样，因为Alluxio应用HDFS插件，创立服务页面会显示HDFS属性。在Namenode URL一栏，输出Alluxio master节点的URI（比方alluxio://alluxio-master:19998）。 将 “Authorization Enabled（启用受权）”设置为 “Yes”将须要对所有用户进行验证，大多数企业会将验证类型设置为Kerberos。如果Ranger治理服务通过SSL证书进行配置，则应依据SSL证书的通用名称标准，正确设置证书通用名称（Common Name for Certificate）属性，Alluxio master节点应能够拜访这些证书文件。留神，用户名和明码会设为Ranger管理员用户名和明码，而不是Alluxio管理员用户名和明码。点击创立按钮后将创立新的HDFS服务并显示在服务管理器页面上。 第二步：配置Alluxio Master节点当应用Ranger治理控制台创立Alluxio Ranger HDFS服务后，就能够将Alluxio master节点配置为应用Ranger HDFS插件来检索和缓存Ranger策略。首先，将core-site.xml, hdfs-site.xml, ranger-hdfs-security.xml, ranger-hdfs-audit.xml 和ranger-policymgr-ssl.xml文件从HDFS namenode服务器上的$HADOOP_CONF目录拷贝到Alluxio master节点服务器上的$ALLUXIO_HOME/conf目录。批改ranger-hdfs-security.xml文件，以命名在上述第一步中应用Ranger治理控制台定义的Alluxio Ranger HDFS服务。如下所示： <property> <name>ranger.plugin.hdfs.service.name</name> <value>alluxio-datacenter1-test</value> <description> Name of the Ranger service containing policies for this Alluxio instance </description> </property>为启用Ranger集成，应批改Alluxio master 节点上的alluxio-site.properties文件，如下所示： ...

一、直播介绍前几期，咱们为大家分享了Taier根本介绍、控制台、Web前端架构及数据开发介绍，本期咱们为大家分享Taier任务调度介绍。 本次直播咱们将从Taier的任务调度实例生成、调度及提交等方面为大家进行介绍，通过本次分享，心愿大家能对Taier有更进一步的理解。 二、直播主题Taier任务调度介绍 三、直播工夫工夫：2022年8月23日晚 19:00--20:00（周二） 四、直播地点钉钉技术交换qun（30537511）&B站袋鼠云直播间（22920407） https://live.bilibili.com/229... 五、分享嘉宾大智 袋鼠云Java开发专家 六、开源我的项目地址https://github.com/DTStack/Taier https://gitee.com/dtstack_dev... 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack

导读：本文次要介绍网易数帆 NDH 在 Impala 上实现的虚构数仓个性，包含资源分组、程度扩大、混合分组和分时复用等性能，能够灵便配置集群资源、平衡节点负载、进步查问并发，并充分利用节点资源。接着上一篇。对于高性能剖析型数仓，除了须要有优良的执行引擎可能让查问尽快实现外，还需防止因为查问间的互相烦扰导致查问性能降落的问题，比方对计算和 IO 资源的竞争等。上节提到 Impala 能够通过资源池来进行计算资源的治理。但在应用时发现光有资源池还不够，依然会呈现不同的资源池竞争同一个计算节点上内存资源等问题。1 基本概念“虚构数仓” 来源于 Snowflake 的 “virtual warehouse”，简称 VW。虚构数仓可能按需进行程度和垂直扩缩容，是一种高效的资源调度办法，是存算拆散设计架构下，计算资源弹性伸缩十分好的验证案例。如下图所示，该 Snowflake 集群有两个虚构数仓，别离服务于 BI 和 ETL 用户。其中 BI 虚构数仓为了应答报表查问的高下峰，采纳了单元化的程度扩缩容模式，ETL 次要关注计算能力，采纳了扭转虚构数仓规格的模式。 NDH 的 Impala 组件也具备相似的能力，在开始之前，先联合 Impala 的理论来介绍两个基本概念，首先是社区版 Impala 已有的 executor group（执行组）。而后是为反对虚构数仓而引入的 node group（节点组）概念。Executor group下图是 CDP 文档中对于 Impala 执行组的示意图，执行组是 Impala 进行弹性伸缩的根本单位，用户能够配置执行组规格 (XSMALL, SMALL, MEDIUM, or LARGE)。若启用主动伸缩，则 CDP 每次会按指定的规格扩大或放大 Impala 的 executor 节点个数。 执行组为 Impala 集群提供了程度扩缩容的能力。但与 Snowflake 所述的虚构数仓还是有不小的区别，从目前的介绍看，执行组是对用户通明的概念，用户无奈通过执行组将 Impala 集群划分为不同用处的计算单元，如前述的用于 BI 和 ETL。因而，NDH Impala 引入了 node group（节点组）的概念。Node groupNDH Impala 集群的 impalad 节点能够被划分成多个独立分组，咱们称之为节点组。节点组能够仅有 executor 组成，也能够有 coordinator 节点。 ...

ChunJun是易用、稳固、高效的批流一体的数据集成框架，次要利用于大数据开发平台的数据同步/数据集成模块，使大数据开发人员可简洁、疾速的实现数据同步工作开发，供企业数据业务应用。 本文次要整顿ChunJun的各类链接以及如何提交pr、Issue的办法，心愿大家更好地参加开源，参加社区。 ChunJun百科● 开源地址 GitHub：https://github.com/DTStack/ch... Gitee：https://gitee.com/dtstack_dev... ● 官方网站 https://dtstack.github.io/chu... ● 疾速入门文档 https://dtstack.github.io/chu... ● 视频课程 Flink StreamSQL根底课程： https://space.bilibili.com/67... 2021年ChunJun课程： https://space.bilibili.com/67... 2022年ChunJun课程： https://space.bilibili.com/67... ● 课件获取 关注公众号“ChunJun”，回复“课件”，即可取得您须要的对应课程的课件。 提交pr&Issue指南如何提交一个优良的pr在GitHub上提交pr是参加ChunJun我的项目开源的一个重要途径，小伙伴们在应用中的一些性能上feature或者bugfix都能够向社区提交pr奉献代码，也能够依据已有的Issue提供本人的解决方案。 ● 第一步：fork ChunJun到本人的GitHub仓库 点击fork后就能够在本人仓库中看到以你名字命名的ChunJun我的项目了： ● 第二步：clone ChunJun到本地IDE ● 第三步：将DTStack/ChunJun设置为本地仓库的近程分支upstream ● 第四步：提交代码 任何一个提交都要基于最新的分支 切换分支 本地批改代码后，提交commit commit_message格局： commit_type message commit_type: feat：示意是一个新性能（feature) hotfix：hotfix，修补bug docs：改变、减少文档 opt：批改代码格调及opt imports这些，不改变原有执行的代码 test：减少测试 eg:hotfix-12345 Fix mysql time type loses precision. rebase近程分支 这一步很重要，因为咱们仓库中的chunjun代码很有可能曾经落后于社区，所以咱们 push commit前须要rebase，保障咱们的commit是基于社区最新的代码，很多小伙伴没有这一步导致提交的pr当中蕴含了其他人的commit rebase后有可能呈现代码抵触，个别是因为多人编辑同一个文件引起的，只须要依据提醒关上抵触文件对抵触局部进行批改，将提醒的抵触文件的抵触都解决后，执行 依此往返，直至屏幕呈现相似rebase successful字样即可 rebase之后代码可能无奈失常推送，须要git push -f 强制推送，强制推送是一个有危险的操作，操作前请仔细检查以避免出现无关代码被强制笼罩的问题 ...

摸索背景随着大数据利用的一直倒退，数据仓库、数据湖的大数据实际层出不穷；无论是电信、金融、政府，各个行业的大数据热潮蓬勃发展。在过来的4-5年中，咱们一直看到企业用户大数据收缩问题日益加剧，大数据翻新下数据存储老本出现线性增长，使得企业对于大数据的利用开始变得审慎、变向放缓了企业外部数据化转型的速度。 外围的挑战：如何更加经济地构建数据湖存储体系。 大数据存储引擎从2006年公布以来，百花齐放，计算侧MapReduce、Spark、Hive、Impala、Presto、Storm、Flink的问世一直冲破应用领域，不过在大数据存储方面反而显得谨慎与沉稳。在过来十多年，在Apache Hadoop生态被宽泛提及的次要还是HDFS与Ozone。 HDFS Hadoop HDFS 是一种分布式文件系统，旨在在商用硬件上运行以进步其普适性。它与现有的分布式文件系统有很多相似之处。然而，HDFS的特点也是显明的：具备高度容错性、旨在部署在低成本硬件、容许程度扩缩容。HDFS提供对应用程序数据拜访的高吞吐量，实用于须要解决海量数据集的应用服务。 Ozone Apache Ozone 是一种高度可扩大的分布式存储，实用于剖析、大数据和云原生应用程序。Ozone 反对 S3 兼容对象 API 以及 Hadoop 兼容文件系统协定。它针对高效的对象存储和文件系统操作进行了优化。 经济化数据存储策略，次要体现在两个要害个性上，只有实现了，其余的加强都会锦上添花： 应用最合适的存储系统存储对应的数据分块；数据存储策略对下层利用的侵入性越低越好；比方HDFS典型场景下应用3正本的策略，一方面是确保数据块的高可用性，同时多个正本也能够更好地保障数据局部性的要求，进步数据拜访的吞吐量；为了更好地提供数据服务，硬件环境也会选用绝对更好的磁盘；对于晚期的大数据实际而言，规范对立的软硬件抉择能够进步对新技术栈的推动，然而随着数据的一直积攒，很多数据的拜访频率出现指数级降落，尤其是针对合规查看的冷数据，不仅仅占据了生产集群的大量空间，可能一年到头都没有被拜访过一次。这是对资源的极大节约。 大数据倒退的现阶段，精细化数据存储被提上了议程。须要一种分层的存储体系，在维系现有计算性能的同时，将温、冷数据实现对下层利用通明的自主迁徙，控制数据存储与保护的老本。 要害个性验证通过这篇文章，咱们心愿能够对经济化数据存储策略做一个初步摸索，首先咱们将先前提到的两个要害个性具象化，而后通过几组试验对技术可行性进行一个探讨。 要害个性一：应用一套存储系统作为热数据系统；应用另一套存储系统作为冷数据系统；要害个性二：对立命名空间同时兼容多套存储系统，通过对立命名空间对下层利用提供数据拜访服务； 技术抉择： 计算引擎: Hive (大部分企业用户应用SQL引擎作为数据开发工具)存储引擎: HDFS/Ozone (业界罕用的Apache生态存储)数据编排引擎: Alluxio (第三方开源组件，兼容大部分Apache生态组件)Hive Apache Hive ™ 数据仓库软件有助于应用 SQL 读取、写入和治理驻留在分布式存储中的大型数据集。构造能够投影到曾经存储的数据上。提供了一个命令行工具和 JDBC 驱动程序容许用户连贯到 Hive。 对于Alluxio “Alluxio数据编排零碎”是寰球首个分布式超大规模数据编排零碎，孵化于加州大学伯克利分校AMP实验室。自我的项目开源以来，已有超过来自300多个组织机构的1200多位贡献者参加开发。Alluxio可能在跨集群、跨区域、跨国家的任何云中将数据更严密地编排到靠近数据分析和AI/ML应用程序的集群中，从而向下层利用提供内存级别的数据访问速度。 作为大数据生态系统中的存储与计算拆散技术标准，在阿里云、腾讯云、华为云、金山云等国内顶级云厂商服务中失去生产测验，是建设企业公有云的基石和核心技术。2021年成立后，先后荣登“中关村国内前沿科技翻新大赛大数据与云计算畛域TOP10”、“2021投资界数字科技VENTURE50”、“科创中国”开源翻新榜等多项榜单。 技术可行性研究，咱们分两个阶段进行： 阶段一：应用同一类型的存储系统HDFS，实现不同HDFS零碎之间的冷热分层【模仿场景：应用新的HDFS3.0 EC或者用磁盘密集型的机器专门搭建冷数据HDFS】阶段二：应用不同类型的存储系统，应用HDFS作为热数据存储系统；应用Ozone作为冷数据存储系统 【模仿场景：HDFS负责热数据/Ozone负责冷数据】 验证步骤部署架构 软件版本： 计算引擎：Hive 2.3.9存储引擎：Hadoop 2.10.1，Ozone 1.2.1，Alluxio 2.8所有组件均为单机模式部署集群布局： 试验一：基于Alluxio实现跨HDFS的通明数据冷热分层Step 1: 在Hive 中创立库、分区表，默认数据存储在 HDFS_1 上 create database test location "/user/hive/test.db";create external table test.test_part(value string) partitioned by (dt string);创立库 ...

概要速览美国艺电 (EA) 是游戏行业的翘楚，每年为寰球几十亿用户提供数十款游戏。是否针对EA的在线服务做出近实时决策对于业务倒退至关重要。本文介绍了在AWS上搭建的基于Presto和Alluxio的数据平台，如何为游戏产业提供即时响应的在线服务。 EA的数据与人工智能部门搭建了数百个平台，来治理游戏和用户每天产生的PB级数据。这些平台蕴含从实时数据导入到 ETL工作流在内的各类数据分析作业。部门产生的格式化数据曾经被公司高管、制作人、产品经理、游戏工程师和设计师等宽泛驳回，用于市场营销和货币化、游戏设计以及晋升客户参与度、玩家留存率和终端用户体验。 用例EA的在线服务须要可能获取近实时信息，这对于制订业务相干的决策（如推广流动和故障排查）至关重要。这些服务包含但不限于实时数据可视化、仪表板（dashboarding) 和会话剖析，咱们的团队正在踊跃寻找能够反对这些用例的框架。 在EA，为获取反对决策的数据分析后果，咱们采纳了诸如 Tableau 和 Dundas等一系列的数据可视化工具。这些工具通常连贯多个数据源，例如 MySQL DB、AWS S3 或 HDFS。用户可能同时从多个数据源加载数据来运行计算复杂度较高的算法。因为数据加载是 I/O 密集型的，因而可能成为重大的性能瓶颈。尤其当雷同的数据须要被屡次加载时，性能瓶颈问题可能更重大。因而，咱们须要一种解决方案，通过在本地缓存数据的形式来升高数据的拜访开销。 仪表板是另一个常见的用例，用于实时追踪用户参与度、客户满意度或零碎状态。在这些场景下，数据量通常是GB级的，但须要可能对频繁的信息刷新进行即时解决。目前，咱们应用Redshift等商业数据库来解决工夫敏感型数据，心愿寻求一种在不升高性能的状况下削减老本的代替计划。 咱们最近开发了一款汇报式聊天机器人，来提供即时的游戏相干剖析，例如实时用户满意度和实时利润剖析。该零碎的后端运行 Presto，PB级的数据存储在 S3 上。聊天机器人会将用户的发问转换为 ANSI SQL查问语句，并在 Presto 集群上运行这些查问。查问通常会波及简单的计算过程，例如在跨数据集搜寻后进行预测和合并。咱们迫切希望找到一种解决方案，与基于S3存储的数据集互补，确保在不减少老本的状况下进步性能。 架构为了服务这些具备近实时需要的不同用例，咱们搭建并评估了以Presto为查问引擎，S3为数据存储，Alluxio为作业数据集缓存层的数据平台。文中，咱们模仿了上述在以后生产环境中搭建的基于S3的 Presto（没有Alluxio）架构，与环境设置（Presto和S3）雷同但部署了Alluxio的技术计划进行比拟。架构如下图所示： 对于设置的具体信息如下： √ 每个实例启动并置的Presto 和Alluxio服务。√ 硬件方面，咱们应用了三个 h1.8xlarge AWS 实例，每个实例上都挂载了 8TB 长期磁盘，供Alluxio把数据缓存到Presto 的本地地位。S3 作为底层长久文件系统挂载到Alluxio。√ Presto 配置了两个目录；一个连贯到咱们现有的 Hive metastore，关联到存储在内部S3 上的基准测试数据集，另一个连贯到一个独自的Hive metastore，其中蕴含在 Alluxio 中创立的基准测试数据表。√ 咱们在 S3 上应用雷同的数据集进行性能比拟，并通过 alluxio fs distributedLoad /testDB指令将数据预加载到 Alluxio。√ 为了晋升解决海量小文件时的查问性能，咱们在alluxio-site.properties 中启用了元数据缓存性能来进行性能调优。 alluxio.user.metadata.cache.enabled=truealluxio.user.metadata.cache.max.size=100000alluxio.user.metadata.cache.expiration.time=10min基准测试后果咱们选取了代表各类工作负载的四个独立基准测试。基线（baseline)是 Presto 间接查问 S3 时的性能。 基准测试1 测试1是咱们对玩家在游戏中事件的外部合成快照，代表 I/O 密集型用例。测试的三个数据集的总数据大小别离为 1GB、10GB 和 100GB，文件为 ORC 格局。每个数据集都是应用雷同的 DDL 创立的，蕴含 49 个 cols（列）、40 个 varchar、5个布尔值和 4个映射。基准测试查问选取所有列以及针对一个varchar 字段的过滤条件。 ...

本文依据作者于 Arctic 开源发布会演讲内容整顿（略有删减），零碎解读 Arctic 我的项目研发初衷、生态定位、外围个性、性能体现及将来布局。首先感激大家参加咱们 Arctic 开源发布会。我是马进，网易数帆实时计算和湖仓一体团队负责人。咱们在 2020 年开始关注数据湖新的技术，并用它来构建流批一体、湖仓一体的架构。最早咱们应用 Flink+Iceberg，然而实际过程中发现这个架构间隔生产场景还有很大的 gap，所以有了 Arctic 我的项目（http://github.com/NetEase/arctic）。数据湖 Table format 之争先看目前 Apache Hudi、Apache Iceberg、Delta 这几个支流的开源 Table format（表格局）的选型。Table format 这个概念最早由 Iceberg 提出，当初行业对它的了解次要有两点。第一点是 Table format 定义了哪些文件能够形成一张表，这样 Apache Flink、Apache Spark、Trino、Apache Impala 等任何引擎都能够依据 Table format 去查问、检索数据。第二点就是 Table format 标准了数据和文件的散布形式，任何引擎写入数据都要遵循这个规范，通过 format 定义的规范来反对以前 Hive 不反对的 ACID 和模式演进。咱们看到 Iceberg、Delta 和 Hudi 在这些性能上基本上是拉平的，尽管他们在各自实现上有很大不同，但形象他们的共性集体认为是十分有意义的事件。拿目前支流的数据湖 Table format 和 Hive 进行比照，Hive 简略定义了表和 HDFS 上动态目录的映射关系，它自身是没有 ACID 的保障的，咱们在实在的生产场景中只能单读单写。目前咱们下层的数据中台或者是 DataOps 平台可能通过工作流的形式保障咱们能正确应用 Hive，当然只能用于离线场景。新的 Iceberg、Delta、Hudi 所主导的 Table format 能力中，减少了一个快照的概念，表的元数据不再是一个简略的表和文件的关系，变成了表和快照以及快照和文件的关系，数据的每次写入会产生新的快照，而这个快照和文件产生一个动静的映射关系，这样它能实现每次写入 ACID 的保障，也能通过快照的隔离实现用户的多读多写。而且基于快照也能给下层提供一些比拟有意思的性能，比如说能够基于快照的增量写入实现增量读，也就是 CDC 的性能，能够通过快照去反对回溯，例如咱们在 time travel 或者数据的 rollback。总结下来 Table format 有四点外围个性。第一，构造自在。像之前的 Hive 只能反对简略的加列操作，而在 Delta、Iceberg 这样的 Table format 之上用户能够自在地更改表的构造，能够加列、减列、改列，而且对数据的迁徙和变更不会有要求。第二，读写自在。因为它通过快照可能保证数据的 ACID，任何实时、离线以及 AI 的需要都能够自在地往这个表外面写数据或者读数据。第三，流批同源。因为 Table format 外围的一个性能是能够很好地反对流场景，咱们的批和流都能够往新的 Table format 去写和读。第四，引擎平权。这点十分重要，它不能只是绑定某一个引擎，比如说像 Delta 在 1.0 时代是 Spark 生态中的一个组件，在一个月之前 Delta2.0 的公布再次向咱们证实了去适配多个引擎的重要性。在 Table format 这些我的项目的官网中，他们会主推一些性能次要蕴含 CDC、SQL 扩大，数据的 Rollback，以及 time travel，模式演进（Schema evolution）以及咱们常常说的流式更新（Upsert）、读时合并（merge-on-read）的性能。CDC 肯定水平上能起到平替音讯队列的作用，比如说在生产场景中，实时计算次要会用 Kafka 或者 Pulsar 做流表的选型。有了 Table format 之后，咱们能够基于数据湖来实现相似于音讯队列的性能，当然它的数据提早会从毫秒或者秒级降级为分钟级别。像 Upsert、读时合并和行业内或者说很多公司去推广数据湖的次要场景，就是拿这个实时更新以及读时合并去平替 Apache Kudu、Doris、Greenplum 这些实时更新的数仓零碎。企业须要怎么的数据湖首先一点是如果咱们只是关注数据湖 Table format 中个别的性能，推广起来是十分艰难的。比如说数据湖的 CDC 性能，的确在某种程度上可能平替音讯队列，然而也会引入一些其余的问题：首先是提早的问题；其次是用数据湖做音讯队列可能会引入很多小文件，这个小文件谁来治理？还有第三个是比拟隐形的问题，以前音讯队列的老本就是挂在业务团队那边，如果咱们当初用一个公共的数据湖底座，这个老本该怎么摊派？在过来两年中，咱们跟行业内很多公司交换，大体上都是在这样一种矛盾之中挣扎，想用数据湖的新技术来代替一些其余计划，对业务的吸引力是十分有余的。咱们的数据湖或者 Lakehouse（湖仓一体）的技术到底能给企业带来怎么的价值？在咱们的生产场景中，咱们的整个数据平台体系在 2020 年遇到最次要的问题，就是流批平台割裂。大家晓得咱们围绕 Hive 这套离线数仓曾经产生了十分丰盛的方法论，从数据模型、数据资产到数据品质，基于数据湖的凋谢架构咱们产生了十分好的一套标准、规范以及治理体系。然而咱们把眼光切换到实时场景下，目前次要用 Flink 做实时计算，用 Kafka 作为流表的选型，当咱们做流表 join 时可能独自须要从数据库那边拉一个实时同步的工作，前面如果咱们做数据分析，须要比拟高的数据新鲜度，须要引入 Kudu 或者 Doris 这些可能准实时或者实时更新的数仓零碎。这套货色和咱们离线整套的技术选型以及工具是十分割裂的，而且没有造成比拟好的标准，次要还是点对点的开发为主。举个例子，如果咱们既要做实时也要做离线，就须要拉两套链路。离线的链路依据咱们整套方法论，依据离线整个流程的工作流，是能比拟容易标准地定义出一套进去。实时场景下咱们更多须要开发者，须要用户本人去理解 Flink 怎么玩儿，Kafka 怎么读，这个过程中序列化、反序列化怎么做，怎么在 Kudu 上建表，这一套标准给用户带来了十分大的累赘。尤其是 AI 的一些业务，他们要做数据生产，其实更加关注数据训练、样本这些跟 AI 相干的流程自身，对 HBase、KV 这些他们是一律不理解的，所以他们会把需要提到另外一个团队，而另外一个团队只能点对点地去响应。总结一下传统 Lambda 架构给咱们带来哪些弊病。第一是数据孤岛的问题。如果咱们应用 Kudu 或者其余跟数据湖割裂的一套数仓计划，会带来独立的洽购和部署老本，会因为容易存储而节约老本。因为数据之间难以复用和互通，如果咱们在雷同的业务场景下须要一个实时的数仓，可能须要从源头从新拉一份数据进去，导致老本和人效的节约。第二是研发人效低，研发体系割裂，研发标准不通用。这在 AI 特色、举荐的场景比拟典型，须要用户本人去搞定什么时候调用实时的货色，什么时候调用离线的货色，会导致整个业务层非常复杂。最初是指标和语义的二义性问题。比方过来几年咱们次要是应用 Kudu 作为实时数仓计划，用户须要本人在 Kudu 外面建一个数仓表，会有 Kudu 的一套 Schema，在 Hive 这边有一套通过数据模型创立的表，而这两套货色都须要用户本人去保护。当业务逻辑产生变更的时候，用户可能改了 Hive 然而没有改 Kudu 的，短暂下来就会导致指标和语义的二义性问题。而且随着工夫的推移，保护的老本会越来越高。所以业务冀望的是什么呢？其实是咱们在平台层，在整个数据中台层或者在整套数据的方法论这一层，可能用一套标准、一套流程把实时和离线，以及 AI 等更多的场景对立。所以咱们回过头来看 Lakehouse 这个概念发明进去的意义，就是拓展产品的边界，让数据湖能更多地服务于流的场景、AI 的场景。在咱们的生产场景中，Lakehouse 给业务最终带来的该当也是一个体系上的收益，而不在于说某一个性能上用了它。比如说我在 CDC 或者在剖析的场景下用了，然而如果用户只是单纯地去比拟 Kudu 和 Hudi 或者 Iceberg 之间的差别，他可能很难说到底带来什么样的收益；然而如果咱们通知用户说整套平台能够即插即用地把离线和实时全副对立掉，这个收益就很大了。基于这样一个指标，咱们开发了流式湖仓服务 Arctic 这样一套零碎。了解 Arctic 流式湖仓服务Arctic 是什么呢？简略来说 Arctic 是由网易数帆开源的流式湖仓零碎（Streaming LakeHouse Service），它在 lceberg 和 Hive 之上减少了更多实时场景的能力，所以 Arctic 首先强调的是实时场景的能力，并且面向 DataOps 提供开箱即用的元数据服务，而且让数据湖更加好用和实用。咱们用一句话概括会比拟形象，前面咱们会用更多功能的举例以及咱们一些干货上的分享，让大家深刻了解 Arctic 到底是什么。生态位差别首先咱们通过这张图强调生态位的差别，Arctic 从生态位上在 Table format 之上，所以严格意义上说咱们不应该把 Arctic 当成是另外一套 Iceberg 或者另外一套 Table format。另外一点，咱们在 Table format 之上，次要思考跟开源的 Table format 做兼容，所以 Arctic 的一个外围指标是帮忙企业用好数据湖的 Table format，以及解决或者拉平在 Table format 以及用户，或者说产品实在的需要之间的 gap。Arctic 自身蕴含两个外围组件，第一个是元数据服务 AMS，它在咱们零碎中定位是下一代 HMS 的角色。第二个，咱们继续自优化的性能，会有整套 optimizer 组件和机制，来实现后盾数据优化。Tablestore 设计与劣势咱们之前和很多用户聊过 Arctic，大部分用户的第一个问题是咱们跟开源的 Iceberg 具体是什么关系。通过这张图我想来阐明这点。首先在 Arctic 中有 Tablestore 这个概念，Tablestore 是一个存储单元的定位，有点相似于传统数据库外面聚簇索引的概念。当流式写入的时候，咱们会用一个 change 的 Tablestore 存储一个 CDC 写入的数据，这个数据有点相似于咱们数据库中的 binlog 或者 relog，前面这个 change table 能够用于 CDC 的回放，也能够当作一个独自的表来拜访。Hudi、Iceberg 也有 upsert 的性能，但 2020 年咱们开始做这个事件的时候 Iceberg 还没有这个性能，社区出于对 manifest 这层设计的谨严考量在实现上会有一些斗争，所以最终咱们决定了在下层去做这个事，并且会体现咱们的一些劣势。Change 表次要存储的是 CDC 的 change 数据，另外还有一套 Basestore 会存储咱们的存量数据，两个 Tablestore 其实是两张独立的 Iceberg 表。另外咱们还可选的集成 Kafka 的 logstore，也就是说咱们的数据能够双写，一部分先写到 Kafka 外面，再写进数据湖里，这样实现了流表和批表的对立。这样设计有什么样的劣势？首先 change 表里的 CDC 数据能够按程序回放，会解决 Iceberg 原生的 V2 CDC 不太好回放的问题。第二个是 change 表能够凋谢拜访。在很多电商、物流的场景里 change 数据不光是作为一个表内置的数据用，很多时候订单表、物流表的变更数据也会作为独立的数仓表来用，咱们通过这样的设计容许把 change 表独自拎进去用，当然会增加一些写入爱护。如果将来业务有一些定制化需要，比如说在 change 表中额定增加一些字段，增加一些业务本人的 UDF 的计算逻辑，这个设计也具备这样的可能。第三点咱们这套设计理念 change 和 base 之间的转化，这个过程是 optimize。这个概念在 Delta、Iceberg 和 Hudi 中都有介绍过，它的外围是做一些小文件合并，咱们把 change 数据到 base 数据的转换也纳入 optimize 的领域，并且这些过程对用户来说是通明的，如果用户间接用 Iceberg 或者 Delta，所有的 optimize 操作在底层都会有一个快照，这样对用户是不敌对的，咱们在下层把这套货色封装起来了。当用户读一个高新鲜度的数据做剖析时，咱们的引擎端会做一个 change 和 base 的 merge-on-read。Arctic 架构和组件了解了 Tablestore 的概念之后再来看 Arctic 的架构和组件，咱们就会更加容易了解。在数据湖这一层咱们有 change files、base files，别离对应 changestore 和 basestore。Tablestore 的概念不仅能够用于 CDC 的场景，将来对于一些排序，对于 ZOrder 一些具体的需要同样能够采纳下层架设独立的 Tablestore 来解决。在下层咱们有一个后面介绍过的 AMS（Arctic Meta Service），AMS 是 Arctic 流式湖仓服务中 “服务” 这一层所重点强调的组件，是面向三元组的元数据中心。三元组是什么呢？就是 catalog.table.db 这样的三元组，大家晓得在 Spark 3.0 和 Flink 1.2 之后，主推的是 multi catalog 这样的性能，它能够适配不同的数据源。目前咱们在支流的大数据实际中更多的是把 HMS 当作元数据中心来应用，HMS 是二元组的构造，如果咱们想扩大，把 HMS 外面依据更多的数据源，须要做很多定制性的工作。比如说网易数帆无数平台其实是在 HMS 之外独自做了一个元数据中心，来治理三元组和数据源的关系，AMS 自身就是面向三元组设计的元数据服务。第二个咱们的 AMS 能够和 HMS 做同步，就是咱们的 Schema 能够存在 HMS 外面，除了 Hive 所可能存储的一些字段信息外，一些额定的组件信息，一些额定的 properties 会存在 AMS 中，这样 AMS 能够和 HMS 一起提供服务，所以业务不必放心在应用 Arctic 的时候肯定要做一个替换，这其实是一个很灰度的过程。第三个是 AMS 会提供事务和抵触解决的 API。在 optimizer 这儿，咱们有一整套残缺的扩大机制和管理机制。首先咱们有一个 optimizer container 的概念，实质上是平台调度工作的组件，咱们整个后盾的 optimize 过程对业务来说是通明的，后盾须要有一套调度服务，可能把 optimize 的过程调度到一个平台中（比方 YARN 上、K8s），这种不同的模式就是 optimizer container 的概念，将来用户也能够通过 container 接口去扩大它的调度框架。optimizer group 是在 container 外部做资源隔离，比如说用户感觉有一些表的 optimize 须要高优先级运行，能够给他抽出一个独立的 optimizer group 执行他的优化工作。第三点在咱们架构中有独自的 Dashboard，也是咱们的一个治理界面，咱们十分重视湖仓自身的治理体验。最初一点也是十分重要的，方才提过咱们有 Table format 齐全兼容的个性。目前提供两种，一个是 Iceberg，因为咱们是基于 Iceberg 来做的，basestore、changestore 都是独立的 Iceberg 表，并且咱们的兼容是随着 Iceberg 的迭代继续推动的，目前曾经兼容 Iceberg V2。另外咱们也有 Hive 兼容的模式，能让业务在不必改代码的前提下，间接应用 Arctic 的一些次要性能，如果用户应用的是 Hive format 兼容，它的 change 数据还是存在 Iceberg 外面的。治理性能之前有提到 Arctic 十分重视治理体验，尤其对于咱们后盾继续优化的治理，有一套性能以及绝对应的度量和标定的能力提供给大家。下图中所展示的，哪些表正在 optimizing 用到的资源、继续的工夫，将来应该怎么做一个更正当的资源调度，通过咱们的治理性能都会给到大家。咱们的 table service 的性能，对于表有很多元数据的信息，包含每张表动静的变更，一些 DDL 的历史信息，事务的信息，都会在表服务中体现。并发抵触解决当咱们采纳了 Table format 去解决流批同源场景的时候，举个例子，比方下图上半局部，咱们在做一个数据的 CDC 同步，失常状况下是一个 Flink 工作去做继续的同步，然而如果咱们想做数据回滚或者要做数据更正，比如说增加了一列，这一列有个默认值，须要咱们通过批的形式把数值初始化一下，会起一个 Spark 工作和 Flink 同步去跑。这个时候如果 Saprk 工作和 Flink 工作操作到了同一行数据，这个数据的主键是一样的，就会遇到数据抵触的问题。当初在 Table format 这一层广泛提供的是乐观并发管制的语义，当咱们呈现抵触的时候首先想到的是让某一个提交失败，换句话说，乐观并发管制的语义外围的一点是不容许并发呈现，那么在咱们这个场景里 Spark 工作可能永远提交不胜利的，因为咱们对它的期待是做全副的数据重写，这样它的数据领域是肯定会和咱们的实时数据抵触的。但业务必定心愿他的数据可能提交胜利，所以咱们提供了并发抵触解决的机制，让这个数据可能提交胜利，并且同时保障它仍然具备事务一致性的语义。下半局部也是相似的，咱们对一个数仓表、湖仓表进行了 ad-hoc 并发的更新 c1 和 c2，c1 在 c2 之后提交，然而 c1 在 c2 之前开始，当它们呈现抵触之后是 c1 笼罩 c2，还是 c2 笼罩 c1？从目前数据湖计划来说，个别是谁后提交以谁为准，然而在更多的生产场景中咱们须要谁先开始以谁为准。这一块工夫关系就不开展，有任何疑难能够在用户群里与咱们深刻交换。Arctic auto bucketing在性能方面 Arctic 也做了很多工作，咱们目前是基于 Iceberg 的，Iceberg 是非常灵活凋谢的 Table format，它在 partition 之下没有思考我的数据以及我的数据对应的更新，应该怎么更好地做映射来晋升它的性能。在 Iceberg 之上咱们做了 auto bucketing 的性能，这个性能跟 Hudi 中 file_group 的概念有些相似。不同的是咱们没有给用户裸露 file_group 或者 file_index 这样的概念。咱们在文件之上提供了分组的性能，是一种可扩大的形式，通过二叉树的扩大形式让每一个节点的数据量尽可能维持在用户配置的大小。比如说 Iceberg 默认配置 128 兆，咱们通过后盾的一整 optimizing 套机制，会尽可能保护每个 node 的大小向 128 兆聚拢。当一个 node 数据超过这个领域之后，咱们会尝试把它决裂，之前也提到咱们分了 changestore 和 basestore，它们都是依照同样的形式治理，这样在每一个节点之上能够对应到 change 数据和 base 的数据，就能实现更精密的数据映射，数据分析的性能会有一个十分好的晋升。能够看到在 merge-on-read 的过程也能够用到整套机制。2000 年左右伯克利有一篇论文专门形容这种计划，感兴趣的同学也能够本人去理解。Arctic 性能测试流式湖仓，或者在数据湖上做实时流式数仓的整套实际，目前还没有十分好的 benchmark 工具来定义它的性能怎么样。对这个问题咱们也做了很多思考和摸索，目前咱们的计划和 HTAP benchmark 采纳的思路是统一的，依据 TiDB 的介绍，找到行业里很早就有的 CHbenchmark 这个概念加以革新。CHbenchmark 反对一个数据库既跑 TPC-C 也跑 TPC-H。从下图右边能够看到，有 6 张表是重合的，既在 TPC-C 中跑也在 TPC-H 中跑，有 3 张表是在 TPC-C 中援用，3 张表只在 TPC-H 中援用。基于这套计划咱们做了一个革新，首先用 TPC-C 跑数据库，在上面咱们再跑一个 Flink CDC 工作，把数据库实时流式地同步到 Arctic 数据湖中，用 Arctic 数据湖构建一个分钟级别数据新鲜度的流式湖仓，在这之上咱们再跑 CHbenchmark 中 TPC-H 的局部，这样能失去比拟规范的流式湖仓的数据分析的性能。针对 optimize 前后的 Arctic、Iceberg 和 Hudi 测试的后果（Trino 下测试），咱们按阶段做了一个简略的比照，分为 0-30 分钟、30-60、60-90 分钟和 90-120 分钟四组。下图蓝色的局部是没有 optimize 的数据分析的性能，从 0-30 分钟，到最初的 90-120 分钟，提早从 20 秒升高到了 40 多秒，升高了一半多。而黄色局部有继续合并的 Arctic，性能稳固在 20 秒左右。灰色的是原生的 Iceberg upsert 计划，0-30 分钟是在 30 秒左右，从 30-60 分钟性能是急剧下降的。为什么 Iceberg 呈现了这么大的性能滑坡呢？因为原生 Iceberg 的确没有 insert 数据和 delete 数据的精细化的映射，所以当咱们继续写入流式文件之后，每一个 insert file 都会跟 delete file 产生十分多的关联，从而导致咱们在 Trino 中做 merge-on-read 的性能急剧下降。前面测 60-90 分钟、90-120 分钟就间接 OOM，跑不进去了。黄色局部是 Hudi。目前来看 Arctic 和 Hudi 一样，通过后盾优化可能保障数据分析的性能，维持在一个比拟安稳的数字。目前来看咱们通过下层的优化，比 Hudi 要好一些。后续咱们也会在官网中把咱们整个测试流程和相干配置向大家公开。Arctic 目前看 mor 性能相比 Hudi 有肯定劣势，这里咱们先不强调 Arctic 做得有多好咱们也钻研了 Hudi，它有 RO 和 RT 两种模式，前者是只会读合并数据，RT 模式是 merge-on-read 的一种模式。它的 RO 模式和 RT 模式性能差距十分大，所以将来可能会有很大的优化空间。Arctic roadmap 与总结最初咱们对 Arctic roadmap 以及整个零碎做个简略的总结。Arctic 是一个流式湖仓服务，提供别离对应 streaming、lakehouse、service 的外围个性。streaming 层面咱们提供了主键的高效流式更新，咱们有数据自分桶、构造自由化的能力，Spark、Trino merge-on-read 的性能，提供分钟级别新鲜度的数据分析。在 lakehouse 层面咱们做到格局的兼容，百分之百兼容 lceberg 和 Hive 的表格局语法，如果有一些性能是 Arctic 没有而 Iceberg 有的，用户只须要切换到 Iceberg catalog，就可能把一张 Arctic 表当作 Iceberg 表来应用，并且咱们提供了 base 和 change 两个表的拜访形式。引擎平权反对 Spark 和 Flink 读写数据，反对 Trino 和 Impala 查问数据，目前 Impala 次要是用到 Hive 的兼容个性，能够把 Arctic 表作为一个 Hive 做查问，从而反对 Impala。在 service 这一块次要强调治理上的性能：第一个是反对将数据湖和音讯队列封装成对立的表，实现流批表的对立，这样用户应用 Arctic 表不必放心从秒级或者毫秒级升高到分钟级别，他仍然能够应用数据湖提供毫秒或者秒级的数据提早的能力。第二点提供流式湖仓标准化度量，dashboard 和相干的管理工具。第三点是解决并发写入抵触，实现事务一致性语义。在治理层面咱们聚焦答复上面这几个问题，这些工作还有很长的路要走。第一个是表的实时性怎么量化，比如说咱们搭建一个流式的湖仓表之后，以后的新鲜度是一分钟、两分钟还是多少，是否达到了用户的预期。第二个怎么在时效性、老本、性能之间给用户提供 trade off 计划。第三个查问性能有多少优化空间，须要投入多大的资源做这样的事件。第四点数据优化的资源该怎么量化，怎么最大化利用这些资源。如果用户深刻理解 Arctic，会发现咱们 optimizing 跟目前 Hudi 其余的有很大不同，首先咱们 optimizing 是在平台层面调度的，不是在每一个写入的工作里做的，这样咱们能够集中化治理这些数据优化的资源，并且能够提供最快的迭代。比方咱们发现通过一些优化可能让合并效率有很大的晋升，就能够很快迭代。最初一点是怎么灵便分配资源，为高优先级来调度资源。在将来 Core feature 维度的工作，首先咱们关注的是不依赖内部 KV 实现 Flink lookup join 性能。咱们之前看到的一个架构里，如果在实时场景下做一个维表 join，可能须要一个内部的 KV 做同步，目前咱们在做这样的计划，就是不须要做内部的同步了，能够间接基于 Arctic 表来做维表 join。第二个是流式更新局部列，当初咱们次要是通过 CDC 来做 streaming upsert，很多场景，比方特色、大宽表，咱们可能须要可能更新局部列。前面是更多的 optimizer container 反对，比如说 K8s；更多 SQL 语法的反对，比如说 merge into—— 目前咱们在 Arctic 层面还没有这样的语法，用户能够把 Arctic 的表当成 Iceberg 表来用，来反对 merge into。将来如果在 Arctic 层面反对了 merge into，它会和 Iceberg 有所不同，因为咱们的变更数据首先会进入到 change 空间。最初一点因为咱们的生态位是在数据湖 Table format 之上，所以将来咱们会做架构的解耦，去扩大到更多的 Table format，比方 Delta、Hudi。最初谈谈咱们开源的初衷。过来咱们做开源可能没有一个十分对立的步调，去年咱们领导层下了一个信心，会依照一种更加专一的形式做开源，以 Arctic 这个我的项目为例，咱们不会做任何的商业暗藏。而且从组织架构而言咱们团队推动开源也是十分独立的过程，如果可能有商业化会由其余的团队推动。咱们会致力于为开发者、用户、成员构建一个公开、自在的数据湖技术交换社区。当然目前咱们次要面向的是国内用户，官网也是以中文为主。心愿更多的开发者参加到咱们这个我的项目中来。这是我明天要分享的全部内容，谢谢大家！Q&A主持人：有没有关注过对于 Flink Tablestore 的个性，跟 Arctic 又有怎么的区别？马进：有。首先大家做的货色都比拟类似，去年咱们就看到了 Flink 社区外面这样的 proposal。我了解 Flink 肯定会做这样的事件，他们也是心愿能搭建一套本人残缺的生态，就像 Delta 对于 Spark 一样。尽管是类似的，然而大家的指标是不太一样的，Flink 做这个事对流这个场景而言更加原汁原味，然而必定不会像咱们更多思考到怎么在 Spark 上，在其余的引擎上做一些事件，怎么在下层提供更多的治理性能。所以抛开一些性能上的重合，我了解大家的初衷或者最终要解决的问题还是会有差别。主持人：尽管在表现形式上是类似的，然而 Flink tablestore 的这种形式更贴近原生 Flink 的场景，然而咱们除了兼容 Flink 的场景之外还会有更多偏差于 Spark 的场景做兼容和反对。马进：不光是 Spark，咱们还提供了 Hive 兼容。如果是 Hive 用户，怎么能让一些 Hive 表比拟顺滑地降级到咱们湖仓一体新的架构上，这是咱们零碎去考量的一些货色，在这个过程中怎么提供一些便当的治理性能，提供度量指标，这些可能和 Flink Tablestore 思考的点是不一样的。主持人：Arctic 底层方才讲到是基于 Iceberg 实现的，在代码上有强绑定的关系吗？当前会不会思考基于其余的 Table format 做这种转换？马进：咱们也经验过一些变动。当初咱们本人定的规范首先不会侵入到 format 外部的实现，也不会魔改开源的代码。但晚期咱们并没有这样明确的指标，会有一些在 Iceberg 上的更改。当初咱们代码和 Iceberg 相对来说是能够做一个比拟洁净的解耦，然而目前咱们没有做这个事，比如说 Schema 这些定义用的还是 Iceberg 包里的货色，然而这个货色要解耦是很容易的。这外面有个设计上的初衷，产品要去思考怎么把数据湖用起来，会有一些思考，比方 Iceberg 和 Delta 谁更可能成为将来的支流？咱们心愿用户能罢黜这样的懊恼，将来咱们心愿能在下层给用户提供一个对立的他须要的 Lakehouse 计划，上层咱们再做这样的选型。主持人：说白了咱们不帮用户做出最终的决定，而是提供更多的可能性，无论将来是 Iceberg 还是 Delta，咱们都能用一种比拟凋谢的形式兼容。马进：这个是久远的，当初咱们还会和 Iceberg 联合得严密一些。嘉宾简介马进，网易数帆大数据实时计算技术专家、湖仓一体我的项目负责人，负责网易团体分布式数据库，数据传输平台，实时计算平台，实时数据湖等我的项目，长期从事中间件、大数据基础设施方面的钻研和实际，目前率领团队聚焦于流批一体、湖仓一体的平台计划和技术演进，及流式湖仓服务 Arctic 我的项目开源。Arctic 文档：https://arctic.netease.com/ch... 地址：https://github.com/NetEase/ar...视频观看：https://www.bilibili.com/vide...交换群：微信增加 “kllnn999” 为好友，注明 “Arctic 交换”理解更多：从 Delta 2.0 开始聊聊咱们须要怎么的数据湖 ...

内容速览：本期分享的题目是Alluxio元数据和数据的同步，从设计实现和优化的角度进行探讨，包含以下6个方面内容： 01. Alluxio简介 Alluxio是云原生的数据编排平台，通过解耦计算和存储层，在两头产生了一个数据编排层，负责对下层计算利用暗藏底层的工夫细节。 02. Alluxio的数据挂载 挂载操作有一个进阶版操作，所做的事件就是让用户能够把两个存储挂载到同一个门路下，能够相互笼罩。同时通过配置读写策略，定义读写文件到哪个存储里，并给出操作的先后顺序。 03. Alluxio和底层存储的一致性 Alluxio和底层存储的一致性，要从Alluxio命名空间中文件的起源说起。 文件的操作分为两类： （1）下层利用通过Alluxio创立一个文件，通过Alluxio写入UFS； （2）下层利用通过Alluxio读一个文件，当发现自己没有这个文件的时候，Alluxio从UFS进行加载。 一致性能够分为两个局部： （1）Alluxio UFS元数据的一致性； （2）Alluxio UFS数据的一致性。 04. Alluxio和UFS的元数据/数据同步 Alluxio提供两种同步机制，一个是工夫戳机制，另一个是基于音讯的同步机制。 05. 元数据同步的实现原理和优化 目前元数据的同步粗略分为以下几个步骤： （1）RPC线程向UFS读取文件的元信息。 （2）如果在解决递归的时候，发现上面还有其余目录，整棵树都须要进行一次搜寻，此时把递归文件/文件夹提交到同步线程池（sync thread pool）。 （3）预取线程池负责从读取文件或者文件夹信息，把后果交给这个同步线程池，来减速这个具体的同步过程。 优化次要蕴含3种形式： （1）性能优化-缓存； （2）算法优化-锁优化； （3）性能优化-调整并行度； 06. 对不同场景的举荐配置 场景一：文件全副由Alluxio写入，之后从Alluxio读取。 场景二：大部分的操作通过Alluxio，但不排除有一些场景会绕过Alluxio间接改变原来外面的文件。 场景三：大部分或全副更新都不通过Alluxio，而更新又十分频繁。 以上仅为大咖演讲概览，残缺内容可点击观看： 附件：大咖分享文字版残缺内容可见下文 01. Alluxio简介Alluxio是云原生的数据编排平台，通过解耦计算和存储层，在两头产生了一个数据编排层，负责对下层计算利用暗藏底层的工夫细节。Alluxio提供了对立的存储命名空间，在中间层提供了缓存和其余数据管理性能。在下图能够看到有Spark、Hive、Map reduce这一类传统的Hadoop大数据计算利用、Presto 这种OLAP类型的数据分析，还有像Tensorflow、Pytorch这样的AI利用。存储层比拟丰盛，包含各种各样的存储。 上面是Alluxio用户列表，这些公司都公开展现了Alluxio的应用场景。通过粗略分类，看到十分多的行业，包含互联网、金融、电子商务、娱乐、电信等。感兴趣的同学能够关注公众号，下面有相干文章的汇总。 02. Alluxio数据挂载这部分将首先回顾Alluxio如何通过数据挂载实现对立编排层；之后探讨Alluxio如何和底层存储保持一致；介绍元数据和数据同步性能；Alluxio的工夫原理和优化；最初对不同场景的举荐配置给出倡议。 1. Alluxio对立的数据命名空间首先介绍数据挂载这个性能。Alluxio通过把底层存储挂载到Alluxio层上，实现了对立的数据命名空间。 上图的例子中Alluxio挂载了HDFS和对象存储。Alluxio的文件系统树就是由左右两棵树合成，造成了一个虚构文件系统的文件系统树。它能够反对十分多的底层存储系统，对立把它们称作Under File System。称为Under是因为它们都处于Alluxio的形象层下。Alluxio反对各种各样不同的底层存储系统，比方不同版本的HDFS，反对NFS, Ceph, Amazon S3, Google Cloud之类不同的对象存储。除此之外还反对十分多其余类型的对象存储，比方微软Azure、阿里、华为、腾讯，也包含国内其余供应商，如七牛对象存储。左下图中的例子是在本人的电脑上运行Alluxio，能够挂载不同的存储，比方挂载HDFS，另外还能够挂载不同版本的HDFS，挂载对象存储，挂载网盘。 2. Alluxio挂载点Alluxio的对立命名空间，理论就是把挂载合成了一个Alluxio的虚构层。Alluxio的挂载点能够粗略分成两种：（1）根挂载点（2）嵌套挂载点 根挂载点间接挂在根节点上，组成了Alluxio的根节点。如果没有根节点，无奈产生，持续造成上面的构造。所以要求在配置文件外面定义根挂载点，系统启动的时候就进行挂载，不挂载就没有方法启动。 嵌套挂载点比拟灵便，能够通过指令进行挂载。通过这个命令行，发出通知，做挂载的操作。同样地，能够挂载，也能够卸载，就是把Mount换成Unmount。嵌套挂载点是嵌套在目录的上面，能够挂在某个局部上面，不肯定挂载在根节点上面。这里有个要求，即两个嵌套点的树不能相互笼罩，这样带来的益处是比拟灵便。如果根挂载点未来须要更换，为了防止须要改配置和重启服务，能够应用一个dummy的根挂载点，比方就挂载在本地门路上面，不应用它，且不在它上面创立任何文件，它存在的惟一目标就是能够启动Alluxio服务。而后在此基础上，把所有要治理的存储，都以嵌套挂载点的形式挂载下来。之后如果要扭转，就间接卸载更换为其它挂载点，这样就很灵便。所有挂载和挂载操作，都会记录在日志里，重启零碎，并重启服务之后，无需再手动操作。 3. Alluxio策略化数据管理 ...

【点击理解更少数仓常识】市场的变幻，政策的欠缺，技术的变革……种种因素让咱们面对太多的挑战，这仍需咱们一直摸索、克服。往年，网易数帆将继续推出新栏目「金融专家说」「技术专家说」「产品专家说」等，汇集数帆及合作伙伴的数字化转型专家天团，聚焦大数据、云原生、人工智能等科创畛域，带来深度技术解读及其在各行业落地利用等一系列常识分享，为企业数字化转型胜利提供有价值的参考。明天由网易数帆大数据离线技术专家尤夕多带来能帮忙标准化企业级离线数仓优化存储，进步性能，且已在网易外部实际验证过的成熟技术计划，为大家提供技术思路参考。 一、Spark 企业级离线数仓面临的痛点企业级数仓类的工作根本以 ETL 类型为主，典型的读取多张表的数据通过一系列 SQL 算子转换后写到一张表。那么除了在性能上 Spark3 曾经有了充沛的保障，剩下的应用痛点集中在了写这个环节。Hive 和 Spark2 在写这个环节也存在很多问题，比方小文件&文件歪斜，数据压缩率不现实，动静分区写难以优化。针对这些问题，上面咱们一一剖析以后的情况，并给出新的解决方案。 小文件 & 文件歪斜传统的解决方案是在 SQL 前面减少一个 DISTRIBUTE BY $columns ，这实质上是减少一次额定的 Shuffle 来对数据从新分区，产出的文件品质强依赖于这个 Shuffle 字段，然而在大部分场景中，数据歪斜是必然的，这造成了局部计算分区须要解决特地大的数据量，不仅带来文件歪斜问题，在性能上也会连累整个工作实现工夫。对执行引擎有肯定理解的同学可能会用十分 hack 形式来优化DISTRIBUTE BY rand() * files，然而这无论是咱们外部曾经复现的 rand() 导致数据不统一，还是 Spark 社区抛出来的问题：Repartition + Stage retries could lead to incorrect data ，都足以证实这是一个有缺点的计划，可能会导致数据不统一，咱们该当防止这种应用形式。除此之外，一些有教训的同学会通过取模的形式来调整歪斜的数据，比方DISTRIBUTE BY $column % 100, $column。这是一种可行的解决方案，但存在几个缺点：1）存在优化下限；通过优化调试很难判断最佳的取模范畴，只能给一个绝对能够承受的优化后果2）有很大的优化代价；须要十分理解字段的数据分布状况，再通过一直调试验证最终找到较为正当的值3）保护老本比拟高；可能过1个月，数据产生了一些变动，那么之前优化的取模值就变得不合理 数据压缩率不现实传统的解决方案是在 SQL 前面减少一个 SORT BY $column，这实质上是在写之前减少一次分区内的排序来进步数据压缩率。或者联合 Shuffle减少 DISTRIBUTE BY $columns SORT BY $columns 让雷同数据落到一个分区后再做部分排序进一步提高数据压缩率。那么问题来了，首先这也绕不过 小文件 & 文件歪斜的问题，这里就不再反复。其次传统的字典排序不能很好的保留多维场景下数据的汇集散布，这里的多维在数仓场景下能够了解成多字段。而优良的数据汇集散布能够在查问阶段进步数据文件的 Data Skipping 比例。咱们目前大部分工作都只思考工作自身的性能，须要逐步器重上游工作查问的性能，从而造成一个良好的循环。 ...

标准设计在这里取《大数据之路：阿里巴巴大数据实际》中的定义，这里记录一下自己对这一块本人的了解。 标准定义指以维度建模作为实践根底 构建总线矩阵，划分和定义数据域、业务过程、维度、度量 原子指标、润饰类型、修饰词、工夫周期、派生指标。所谓的标准的定义，简略了解，如果把数据当作货物，那就是货物的分类，以及对应相干的属性，比方生产日期，某个原料的含量等，咱们能够把相近或者雷同货物，依照肯定的法则，放在一起，不便入库与出库，须要某个货物依照这些法则就能够，以比拟快的速度拉取出来。 个别的标准设计蕴含一下几个方面:划分和定义数据域、业务过程、维度、度量 原子指标、润饰类型、修饰词、工夫周期、派生指标。 数据域：指面向业务剖析，将业务过程或者维度进行形象的汇合。其中，业务过程能够概括为一个个不可拆分的行为事件，如买家下单事件，买家是维度。数据域须要形象提炼，并且长期保护和更新，不可轻易变动。划分数据域时，既要能涵盖以后所有的业务需要，又能在新业务进入时无影响地被蕴含进已有的数据域和扩大新的数据域。 业务过程：指企业的业务流动，如下单、领取等，业务过程是一个不可拆分的行为事件。 工夫周期：用来明确数据统计的工夫范畴或者工夫点，如最近30天、天然周、截至当日等。 润饰类型：是对修饰词的一种形象划分。润饰类型从属于某个业务域，如日志域的拜访终端类型涵盖无线端、PC端等修饰词。 度量/原子指标：原子指标和度量含意雷同，基于某一个业务事件行为下的度量，是业务定义中不可再拆分的指标，具备明确业务含意的名词，如领取金额。 维度：维度是度量的环境，用来反映业务的一类属性，这类属性的汇合形成一个维度，也能够称为实体对象。维度属于一个数据域，如天文维度、工夫维度。 维度属性：维度属性隶属于一个维度，如天文维度外面的国家名称、国家ID、省份名称等属于维度属性。 派生指标：派生指标=一个原子指标+多个修饰词(可选)+工夫周期。能够了解为对原子指标统计范畴的圈定。如原子指标：领取金额，最近1天海内买家领取金额则为派生指标（最近1天为工夫周期，海内为修饰词，买家作为维度，而不作为修饰词）。这里说说对下面的了解，下面的定义，实际上就是对数据的分类，以及对指标统一口径，对立命名的过程。首先，咱们须要划分数据域，这个是业务过程的汇合，所以这个是对数据的一个大的分类，这个很重要，因为会影响到后续咱们的数据怎么开发和存储，以及咱们后续须要数据时，怎么查问，从哪里查问。 数据域是一个业务过程+维度的汇合，也就是咱们在建设标准定义的时候，须要先定义目前以及将来将有的业务过程，这个须要和业务一起定义探讨，因为这一块要贴近业务，个别的开发人员不够业务人员对业务了解深刻。确定好业务过程之后，再看看目前的业务过程有哪些维度，抽取进去，做好维度总线矩阵，保护好一致性维度。一个业务过程属于一个数据域，然而一个维度能够属于多个数据域。 定义好业务过程和维度之后，就要对业务过程和维度分类了，看看每一个数据域都有哪些内容，做好划分。 分类好了之后，就是确定，每一个业务过程，有哪些原子指标，以及对应的修饰词，工夫周期。 做好之后，再依据需要生成咱们想要的派生指标等，或者抽取一些数据宽表，用于数据分析，这样咱们就能够想要晓得某个数据，就能够通过数据域->业务过程->相应的物理表->对应的指标，修饰词，工夫周期等，通过这个分类，定位到咱们的数据，这样也能够不便咱们后续对数据地图，数据资产的治理，这个就有点像是图书馆对图书的分类，想定义大类，再细分，图书是依据类目划分，咱们这里要依据业务行为过程，具体的业务划分。 下面的图是网络上某一个图书馆的图书分类，咱们能够留神到，每一个图书分类后面都有一个字母，这个是每一个类目标代码，用于图书的编码记录，这里咱们也是一样，须要对每一个数据域，也就是数据的分类，调配一个编码。这样用于表命名，最简略的就是作为前后缀，这样咱们就能够简略的通过表名晓得这个表是数据哪个数据域的，同样的情理咱们须要对下面提到的业务过程，维度，修饰词等取一个对立的编码，用于对后续数据开发过程中，表命名，字段命名等，这样咱们通过表名称，字段名称，就能够大略晓得这张表是什么数据。 这里举一个简略电商的例子，比方交易数据域(transaction)，业务过程属于下单(order)，领取金额(pay_amount),工夫周期为最近1天(1d),依照下面的逻辑就是表和字段的逻辑示意为transaction_order.pay_amount_1d，这里为一个伪代码，帮忙理解，具体以独特的约定为准。 须要数据仓库材料能够点击这个支付数据仓库(13)大数据数仓经典最值得浏览书籍举荐 原文链接：https://zhuanlan.zhihu.com/p/...

Hi，我是ChunJun，一个乏味好用的开源我的项目。 明天咱们正式开明了本人的公众号！欢送大家关注~ 数字经济时代，各行各业数字化转型大趋势下，数据因素成为要害。海量多源异构数据汇聚，使得数据同步面临同步速率受限、稳定性差、保护老本低等挑战。 批流一体的数据集成框架ChunJun，积淀了团队六年来在数据同步和集成方面的实践经验，秉承易用、稳固、高效的指标，满足更多用户对新型数据集成治理需要的响应。 ChunJun是什么ChunJun是易用、稳固、高效的批流一体的数据集成框架。 次要利用于大数据开发平台的数据同步/数据集成模块，通常采纳将底层高效的同步插件和界面化的配置形式相结合的形式，使大数据开发人员可简洁、疾速的实现数据同步工作开发，实现将业务数据库的数据同步至大数据存储平台，从而进行数据建模开发，以及数据开发实现后，将大数据处理好的后果，数据同步至业务的利用数据库，供企业数据业务应用。 外围个性• 基于json、sql构建工作 • 反对多种异构数据源之间数据传输 • 反对断点续传、增量同步 • 反对工作脏数据存储管理 • 反对Schema同步 • 反对RDBS数据源实时采集 开源地址https://github.com/DTStack/ch... https://gitee.com/dtstack_dev... ChunJun的故事我的项目最早启动的初衷是为袋鼠云的外围业务一站式大数据开发治理平台-数栈DTinsight，打造一款具备“袋鼠特色“的外围计算引擎，承载实时平台、离线平台、数据资产平台等多个利用的底层数据同步及计算工作。 2016年，数栈技术团队初步研发实现了这款基于Flink的分布式离线/实时数据同步插件——FlinkX，它能够实现多种异构数据源高效的数据同步，反对双向读写和多种异构数据源。有它助力，袋鼠云在批流一体的钻研实际以更迅猛的势头往前挺进。 尔后，FlinkX在业务场景中投入理论利用，失去了超过预期的成果，团队继续投入研发力量，在脏数据、分布式、整库同步、连接数管制等方面逐步欠缺。成为反对数栈实现异构数据源之间高速稳固数据同步的外围计算引擎。 2018年4月，秉承着开源共享理念的数栈技术团队在github上开源了FlinkX，吸引了大量的开发者们一起技术交换和单干共建，FlinkX失去了更好的倒退。 2022年4月，在FlinkX进行初版开源的整整四年后，FlinkX曾经从当初的一个小我的项目，成长为领有3200+star，1400+fork的开源我的项目。技术团队决定对FlinkX进行整体降级，并更名为ChunJun，心愿为大家真正提供一个稳固、高效、易用的批流一体的数据集成框架。 ChunJun的技术ChunJun既能够采集动态的数据，比方MySQL，HDFS等，也能够采集实时变动的数据，比方binlog，Kafka等。同时ChunJun也是一个反对原生FlinkSql所有语法和个性的计算框架。 次要架构ChunJun基于Flink并采纳插件式架构，将源数据库形象成Reader插件，将目标数据库形象成Writer插件。 外围能力● 多源异构数据汇聚 作为一个开放式系统，用户能够依据须要，开发新的插件，接入新的数据库类型，也能够应用内置的数据库插件。目前兼容30+异构数据源的数据读写与SQL计算。 ● 断点续传 针对网络稳定等异常情况，导致数据同步失败的工作，在下一次工作时主动从上一次失败的数据点进行数据同步，防止全部重跑。 ● 数据还原 除了DML操作以外，一些源端数据库的DDL操作也能做到同步，最大水平保障源端数据库和指标端数据库的数据对立和构造对立，做到数据还原。 ● 脏数据管理 数据传输过程中，因数据品质或主键束缚等其余因素导致数据无奈同步到指标数据库，针对这些脏数据进行统计和治理，便于后续进行脏数据分析。 ● 速率管制 数据同步过程中，数据传输效率是要害，ChunJun针对各种场景，对症下药地管制速率，最大水平保证数据同步的失常进行。 ChunJun的劣势简略易用● 实现“开箱即用” 反对Docker 一键部署，反对多种工作运行模式。 本地 local模式，实用于调研、测试阶段应用；Flink 集群 standalone模式；Yarn 调度 session 模式及 per-job模式，罕用于生产环境；K8S 环境 application 模式及 session 模式。● 丰盛工作类型 反对json 同步工作，以及sql 计算工作，用户能够依据本人的须要，思考是应用配置更加灵便的json同步工作，还是计算更加弱小的sql计算工作。 ...

1. 数字化转型与国产化过程推动为了响应国家“十四五”数字经济倒退布局的号召，中国企业推动翻新资源共建共享，促成翻新模式凋谢化演进，在信息化、数字化、智能化的强烈需要下，中国龙头企业兼顾全渠道的技术能力，逐步造成了一套笼罩团体业务倒退、经营治理等外围倒退策略须要的策略方向。 数字化转型初见成效，数据能力一直开掘与翻新；大数据技术新陈代谢，国产化步调日益放慢。无论是互联网企业还是传统行业下的领导企业，有什么数据，如何应用数据，如何更加智能地利用数据这些议题被一直开掘与迭代。 在东数西算的理念下，数据跨平台、跨机房、跨地区的技术问题与挑战逐步浮现进去。这篇文章咱们次要从技术的角度，对跨地区的数据联邦，或者说总公司和分公司不同数据域的互联互通进行探讨，钻研相干技术可行性与分享整个钻研过程。为了放慢国产化软硬件的推动，本次实际采纳国产化硬件ARM服务器（鲲鹏920）以及国产化操作系统统信进行相干的技术验证。 2. 原型指标与设计通过对跨地区数据联邦的调研，咱们发现中国很多企业面临的业务挑战尽管不同，然而技术难点是类似的，次要有： 挑战一：总公司通过传统的ETL作业采集分公司数据（比方通过Informatica、Kettle、DataX等），这些作业往往是按需定制，并且定期执行的；当有新的数据合规要求或者总公司数据分析要求时，都须要进行定制开发、测试、部署，这对数据汇总的时效性带来了很大的负面影响。另外通过ETL作业采集的分公司数据，在遇到分公司数据更新时，非常容易造成总公司与分公司之间的数据不统一，导致剖析后果有所纰漏。 挑战二：子公司的自助式查问，一方面是对总公司的数据申请，很多时候整个数据拜访链路是断裂的，往往须要通过流程筛查、繁琐的数据同步伎俩进行（比方通过FTP传输，甚至是物理介质的长途运输）。思考到数据安全以及国家审计合规的要求，总公司数据是否能够在子公司长久化存储、数据拜访脱敏、权限管控等等也都是以后中国企业面临的具体技术挑战。 因而咱们本次的钻研次要会关注在数据流的双向流动方面。 2.1 钻研原型技术选型以后大数据技术曾经成为企业外部典型的数据分析伎俩，因而在原型实现的过程中，咱们次要应用开源的大数据技术，从存储、计算（剖析）、编排3个维度进行选型。其中每个维度咱们抉择时下最支流的组件，以确保该原型的通用性。 数据存储： √ HDFS：Hadoop分布式文件系统（Distributed File System） 数据分析（以SQL剖析为主）： √ Hive：构建于Hadoop之上的数据仓库，通过一品种SQL语言HiveQL为用户提供数据的演绎、查问和剖析等性能。 数据编排： √ lluxio：Alluxio是一个开源的虚构分布式文件系统( Virtual Distributed File System, VDFS)，位于大数据栈中的计算和存储之间。它为计算框架提供了数据抽象层，使得利用可能通过一个独特的接口连贯底层不同的存储系统。 环境模拟：总公司/分公司-1/分公司-2 √ 每个公司有自建的HDFS集群； √ 每个公司有自建的Alluxio集群：用于实现与本公司HDFS集群和其余公司HDFS集群的数据联邦； √ 每个公司有自建的Hive集群。 备注： CPU型号: 鲲鹏920 HDFS 3.1.1 Hive 3.1.0 Alluxio 2.82.2 数据流定义应用HDFS、Hive、Alluxio定义数据长久化与数据拜访链路。在总公司和分公司构建对立的技术栈（技术标准），实现数据共享闭环： 1 在总公司数据域，实现分公司数据联邦，容许总公司实现全域数据拜访与剖析； 2 在分公司数据域，合规拜访总公司数据湖，并联合子公司公有数据进行自助化剖析； 3. Alluxio在ARM环境下的根本测试3.1 Alluxio基于ARM编译## 编译 mvn -T2C -DskipTests -Dmaven.javadoc.skip -Dlicense.skip - Dcheckstyle.skip -Dfindbugs.skip clean install3.2 Alluxio基于ARM服务器的部署与根本测试## 根本测试 [root@node1 ~]# alluxio runTests ...

一、直播介绍之前的内容，咱们为大家分享了ChunJun数据还原的DDL模块，以及ChunJun同步Hive事务表，本期咱们为大家分享ChunJun数据传输模块介绍。 本次直播咱们将从ChunJun数据类型转换，到数据传输过程以及ChunJun的序列化实现为大家进行具体解说，通过本次分享，心愿大家能对ChunJun有更进一步的理解。 二、直播主题ChunJun数据传输模块介绍 三、直播工夫工夫：2022年8月16日晚 19:00--20:00（周二） 四、直播地点钉钉技术交换群（30537511）&B站袋鼠云直播间（22920407） https://live.bilibili.com/229... 五、分享嘉宾六六 袋鼠云大数据引擎开发专家 六、开源我的项目地址https://github.com/DTStack/ch... https://gitee.com/dtstack_dev... 袋鼠云开源框架钉钉技术交换qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack

上一篇咱们演示了严格近邻模式的成果，接着上一篇咱们来演示一下宽松近邻：（1）pom依赖：<dependency> <groupId>org.apache.flink</groupId><artifactId>flink-cep_${scala.binary.version}</artifactId><version>${flink.version}</version></dependency>（2）定义一个音讯对象 public static class Ticker { public long id;public String symbol;public long price;public long tax;public LocalDateTime rowtime;public Ticker() {}public Ticker(long id, String symbol, long price, long item, LocalDateTime rowtime) { this.id = id; this.symbol = symbol; this.price = price; this.tax = tax; this.rowtime = rowtime;}}（3）结构数据，定义事件组合public static void main(String[] args) { EnvironmentSettings settings = null;StreamTableEnvironment tEnv = null;try { StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); settings = EnvironmentSettings.newInstance() .useBlinkPlanner() .inStreamingMode() .build(); tEnv = StreamTableEnvironment.create(env, settings); System.out.println("===============CEP_SQL_10================="); final DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); DataStream<Ticker> dataStream = env.fromElements( new Ticker(1, "ACME", 22, 1, LocalDateTime.parse("2021-12-10 10:00:00", dateTimeFormatter)), new Ticker(3, "ACME", 19, 1, LocalDateTime.parse("2021-12-10 10:00:02", dateTimeFormatter)), new Ticker(4, "ACME", 23, 3, LocalDateTime.parse("2021-12-10 10:00:03", dateTimeFormatter)), new Ticker(5, "Apple", 25, 2, LocalDateTime.parse("2021-12-10 10:00:04", dateTimeFormatter)), new Ticker(6, "Apple", 18, 1, LocalDateTime.parse("2021-12-10 10:00:05", dateTimeFormatter)), new Ticker(7, "Apple", 16, 1, LocalDateTime.parse("2021-12-10 10:00:06", dateTimeFormatter)), new Ticker(8, "Apple", 14, 2, LocalDateTime.parse("2021-12-10 10:00:07", dateTimeFormatter)), new Ticker(9, "Apple", 19, 2, LocalDateTime.parse("2021-12-10 10:00:08", dateTimeFormatter)), new Ticker(10, "Apple", 25, 2, LocalDateTime.parse("2021-12-10 10:00:09", dateTimeFormatter)), new Ticker(11, "Apple", 11, 1, LocalDateTime.parse("2021-12-10 10:00:11", dateTimeFormatter)), new Ticker(12, "Apple", 15, 1, LocalDateTime.parse("2021-12-10 10:00:12", dateTimeFormatter)), new Ticker(13, "Apple", 19, 1, LocalDateTime.parse("2021-12-10 10:00:13", dateTimeFormatter)), new Ticker(14, "Apple", 25, 1, LocalDateTime.parse("2021-12-10 10:00:14", dateTimeFormatter)), new Ticker(15, "Apple", 19, 1, LocalDateTime.parse("2021-12-10 10:00:15", dateTimeFormatter)), new Ticker(16, "Apple", 15, 1, LocalDateTime.parse("2021-12-10 10:00:16", dateTimeFormatter)), new Ticker(17, "Apple", 19, 1, LocalDateTime.parse("2021-12-10 10:00:17", dateTimeFormatter)), new Ticker(18, "Apple", 15, 1, LocalDateTime.parse("2021-12-10 10:00:18", dateTimeFormatter))); Table table = tEnv.fromDataStream(dataStream, Schema.newBuilder() .column("id", DataTypes.BIGINT()) .column("symbol", DataTypes.STRING()) .column("price", DataTypes.BIGINT()) .column("tax", DataTypes.BIGINT()) .column("rowtime", DataTypes.TIMESTAMP(3)) .watermark("rowtime", "rowtime - INTERVAL '1' SECOND") .build()); tEnv.createTemporaryView("CEP_SQL_10", table); String sql = "SELECT * " + "FROM CEP_SQL_10 " + " MATCH_RECOGNIZE ( " + " PARTITION BY symbol " + //按symbol分区，将雷同卡号的数据分到同一个计算节点上。 " ORDER BY rowtime " + //在窗口内，对事件工夫进行排序。 " MEASURES " + //定义如何依据匹配胜利的输出事件结构输入事件 " e1.id as id,"+ " AVG(e1.price) as avgPrice,"+ " e1.rowtime AS start_tstamp, " + " e3.rowtime AS end_tstamp " + " ONE ROW PER MATCH " + //匹配胜利输入一条 " AFTER MATCH skip to next row " + //匹配后跳转到下一行 " PATTERN ( e1 e2+ e3) WITHIN INTERVAL '2' MINUTE" + " DEFINE " + //定义各事件的匹配条件 " e1 AS " + " e1.price = 25 , " + " e2 AS " + " e2.price > 10 AND e2.price <19," + " e3 AS " + " e3.price = 19 " + " ) MR"; TableResult res = tEnv.executeSql(sql); res.print(); tEnv.dropTemporaryView("CEP_SQL_10");}（4）要害代码解释：须要借着贪心词量来实现宽松近邻成果。 ...

数仓开发平台1.背景数据仓库是存储各种数据的仓库，形同于事实当中存储货物的仓库，不可避免的存在“乱放”、“不不便存取”、“节约空间”等状况。在数仓开发的过程当中，发现只有标准的存在是不能齐全的防止数仓凌乱、品质不低等问题。有些状况可能是因为数仓开发人员标准不对立、认知不对立、需要效率与品质均衡等因素影响。那么以后的数据仓库都存在哪些问题呢，大抵如下： 代码不标准命名不对立代码版本迭代管理混乱反复开发跨层依赖指标没有精确的定义没有残缺的表、指标血统链路查找数据艰难调度编排不合理存储与计算资源节约模型设计不合理数据与模型品质监控不欠缺上下游数据感知滞后保护老本高元数据不对立为了解决上述的这些问题，咱们采纳了平台化的形式来对立生产工具，把数仓开发的各个环节的标准做了线上的标准与对立，在保障数仓开发效率的根底上，同时做到老数仓体系的疾速迁徙。整体指标如下： 数仓开发标准线上化指标、元信息、建模、物理表 各端元信息对立调度主动优化闭环无SQL化数仓建设数仓地图数仓表品质监控批流一体化老数仓疾速迁徙数据治理2.数仓标准线上化惯例数仓开发流程： 数据调研数据域划分明确统计指标构建总线矩阵标准定义明确模型设计汇总模型设计代码开发部署运维数仓开发线上化流程 数据域治理总线矩阵治理模型建设： 维度 指标 分区字段 其余建模标准校验审批上线零碎整体尽可能把非业务相干的标准、调度、代码、资源管理做到尽可能的零碎托管，开发人员能够不须要关怀这部分内容，缩减开发流程，只须要专一到业务模型建设当中。并且因为标准的线上化、审批、数据品质监控等方面的性能，人造的帮忙开发人员晋升了数据品质与开发效率。 3.零碎功能设计整体零碎功能模块划分大抵如上图所示，性能阐明如下： 字典元信息管理：该局部次要是对一些零碎的字典信息、业务库字典信息等相干内容的治理，包含我的项目空间、业务域、总线矩阵、业务字典信息、数仓分层信息等根本信息的保护；维度建模治理：这个局部是该零碎的外围功能模块，须要通过sql图形化编辑的形式，对新老数仓模型进行可视化建设，共事保护了改模型的各种分层信息、业务域、维度、指标、分区字段等各类元信息。在审批通过之后零碎后端性能主动创立表与保护表元信息，并依据建模逻辑主动编排工作与调度，自动化最优的执行我的项目空间下的有向无环图调度流程；作业调度治理：依据维度建模生成的作业工作，对相干工作进行最优状况下调度安顿，并且监控工作运行状况。该局部要满足高可用，分布式，可扩大等个性；并且能够反对多种计算与存储引擎抉择。模型与数据品质监控：这部分次要是对模型的品质进行汇总，大抵分为资源型监控、价值型监控、数据内容监控三个方面，并且在该功能模块下反对模型资源管理，分区保留工夫，冷热数据管理等数据治理等性能；表与指标血统地图：在零碎的治理下各类模型的元信息比拟全面和标准，在这个根底之上咱们就能够分层追踪表、指标的血统逻辑关系，并且能够通过图形化、文字化的形式表白指标业务口径逻辑。之前尝试过各种前置指标字典治理，成果并不现实，开发和业务人员保护老本都比拟大，所以这次采纳了反向追踪解析的形式通过理论模型来表白展现指标口径问题。在呈现指标问题的时候也能够疾速的找到指标逻辑，晋升问题排查效率；自助剖析性能：该模块次要是反对各种模型下的业务BI剖析的工作，通过图形化的形式展现模型剖析数据，可扩大性能生成各类BI看板，也能够间接对接到其余BI平台应用；数据探查性能：次要是实现上下游表的元信息监测工作，产生表字段等变更的状况，主动判断对上游影响大小，依据状况主动告诉上游相干表负责人，防止业务方改变未及时告诉所造成的数据问题。提前发现问题尽快解决问题，升高各种改变对数据的影响。4.零碎架构设计零碎架构设计关键点： 数仓与存储:以hive数仓为根底，在此基础上能够扩大数据至kylin或者clickhouse，以供下层自助BI剖析查问应用，晋升查问剖析效率，晋升用户体验；SQL解析模块：这个性能非常重要，须要完满的解析老的数仓SQL进行图形化展现与迁徙保护、并且须要高效的UI页面设计来表白模型SQL逻辑，从可视化、逻辑表白上都有更高的要求；任务调度：是保障模型每天可能稳固产出的要害模块，调度零碎能够应用开源调度零碎，进行二次开发来对接开发平台的工作生成与调度治理监控；自助剖析模块：基于模型开发元数据，生成各类数据集，对接one-service进行数据查问与展现。根底性能如下图，能够进行各种展现模式的开发与丰盛，以适应各种剖析场景；模型与数据监控治理：这个是很重要的一个环节，平常的状况是你开发了一个模型也就你的业务在援用，从模型价值与资源、数据状况上有没有相应的统计，没有一个正当的指标来监控表白一个模型的品质，所以对于模型要从资源型监控、价值型监控、数据内容上做到残缺的监控与定期的评估，正当形象优化数仓各层模型表。在此基础上提供数据治理的各种性能，升高资源的耗费，晋升数仓模型品质，达到高复用的状况；数据探查：次要联合业务库mysql-cdc的数据与数仓模型的上下游表信息来实时监控，上游表字段改变对上游的影响，及时的发现与揭示上游用户，用来防止数据问题，保证数据品质与稳固。5.总结大数据基于数据这个方向根本分三个：1、大数据平台 2、数据仓库 3、数据中台产品。数据仓库是一个企业数据进行数据化决策一个最重要的基石，一个高质量的数据仓库会极大的晋升数据应用的效率，助力业务进行商业剖析与业务决策，升高业务不确定性，从而产生业务价值。有了高质量、模型正当、构造清晰的数据仓库能够大大降低各种应用老本，在此基础上也能更好的构建出好的中台产品。 数据中台产品：大抵能够分成3类，1、大数据平台的运维产品 2、面向开发提效的中台产品 3、面向业务应用的中台产品，数仓开发平台就是面向开发提效提质的一个中台产品，用平台的形式打造出一个高质量的数据仓库，这个是一个长期有价值的事件，是一个公司数据基建中的基石与根基。

课件获取：关注公众号“数栈研习社”，后盾私信 “ChengYing” 取得直播课件 视频回放：点击这里 ChengYing开源我的项目地址：github 丨 gitee 喜爱咱们的我的项目给咱们点个__ STAR！STAR！！STAR！！！（重要的事件说三遍）__ 技术交换钉钉 qun：30537511 本期咱们带大家回顾一下陆地同学的直播分享《ChengYing部署Hadoop集群实战》 一、Hadoop集群部署筹备在部署集群前，咱们须要做一些部署筹备，首先咱们须要依照下载Hadoop产品包： ● Mysql https://dtstack-opensource.os... ● Zookeeper https://dtstack-opensource.os... ● Hadoop https://dtstack-opensource.os... ● Hive https://dtstack-opensource.os... ● Spark https://dtstack-opensource.os... 接着咱们能够将下载好的产品包间接通过ChengYing界面上传，具体门路是：部署核心—组件治理—组件列表—上传组件安装包： 能够通过两种模式上传产品包： 本地上传形式产品包在先下载到本机电脑存储中，点击本地上传，选在产品包上传。 网络上传模式间接填写产品包网络地址上传（ChengYing的网络须要和产品包网络互通）。 Hadoop集群部署流程做完筹备后，咱们能够开始进入集群部署，Hadoop集群部署流程包含以下步骤： 集群部署程序阐明首先须要部署Mysql和zookeeper，因为Hadoop须要依赖zookeeper，Hive元数据存储应用的是Mysql；其次须要部署Hadoop，Hive最初部署Spark，因Spark依赖hivemetastorePS：部署程序是不可逆的 Hadoop集群部署角色散布 产品包规范部署流程 抉择须要部署的产品包，点击部署按钮，而后抉择对应须要部署的集群，默认集群为dtstack，集群名称可配置；下一步抉择须要部署的服务，默认产品包下的服务都会部署，能够依据理论需要部署，在此阶段能够对服务的配置文件进行批改，例如：批改Mysql连贯超时工夫等；最初点击部署，期待部署实现。Mysql服务部署流程演示接下来咱们以Mysql服务部署流程来为大家理论演示下整体流程： ● 第一步：抉择集群 ● 第二步：抉择产品包 ● 第三步：抉择部署节点 ● 第四步：部署进度查看 ● 第五步：部署后状态查看 Hadoop集群应用与运维集群部署结束后，若有需要能够进行配置变更操作。 ● 配置批改 例如：如果须要操作批改yarn的配置文件，能够先抉择yarn-site.xml文件，能够在搜寻框搜寻须要批改的配置文件key，如cpu_vcores。 ● 配置保留 ...

作者 | 郑德来 导读：本文次要介绍如何基于流批一体的技术架构构建实时数仓，在严格的资源老本限度下，满足业务对于数据时效性、准确性的需要。文章整体蕴含4个局部，首先会介绍下大数据架构演进，从经典架构到Lambda架构再到Kappa架构；而后会介绍下咱们做流批一体实时数仓的背景，旧架构面临的次要问题；第三会介绍下咱们流批一体实时数仓的技术计划，关键问题的冲破；最初一部分是总结和布局，咱们的技术计划达成了什么样的业务成果。 全文4735字，预计浏览工夫12分钟。 一、大数据架构演进1.经典离线数仓架构介绍 经典的离线数据仓库次要分为4层： 1）操作数据层（Operational Data Store），存储根底数据，做简略数据荡涤。 2）明细数据层（Data Warehouse Detail），构建最细粒度的明细层事实表。 3）汇总数据层（Data Warehouse Summary），依照主题，对明细数据进行汇总。 4）利用数据层（Application Data Store），寄存业务个性化统计指标，面向最终展现。 经典的离线数仓的优缺点非常清晰，长处是架构简略，开发成本低，资源成本低，数据易治理，数据差异小；毛病是数据时效性差、短少实时数据。 2.Lambda架构介绍 lambda架构是由Storm作者Nathan Marz于2011年提出的实时数仓架构，初衷也是补救经典数仓架构时效性差的问题。整个架构会分三层： 1）Batch Layer：批处理层，这一层其实根本是复用了经典数仓分层架构，数据也是基于ods 、dwd、dws、ads的构造进行组织，也就保留了经典数仓数据精确、全面的特点。应用技术栈也是跟经典数仓统一，次要以mr、hive、spark等离线计算框架为主。 2）Speed Layer：减速解决层，这一层的重点在于产出高时效性的数据，对于数据的准确性和完整性可能会有一些降级，个别会采纳kafka等消息中间件进行数据传输和存储，采纳一些像Storm、Spark streaming 、Flink 等流式计算框架进行数据计算。 3）Serving Layer：服务层，这一层会将speed layer和batch layer层的数据进行合并和替换，输入到一些数据库或者olap引擎中，撑持下层的数据利用。 相比于经典数仓，Lambda架构因为引入了speed layer，可能把数据的时效性大大提前，因为同时具备speed layer和batch layer，使得Lambda架构可能同时兼顾数据准确性和数据的时效性，另外batch layer根本兼容了经典数据架构，所以在从经典数仓架构迁徙Lambda架构的时候，能够省去一部分惨重的历史包袱，至于毛病嘛，也是因为Lambda架构同时具备speed layer和batch layer，那就会导致这么几个问题： 1）一个需要会有两套代码，同时开发两遍，也就会造成开发成本的节约。 2）资源须要两份，一份离线的资源，一份流式的资源，整体资源占用比拟多。 3）数据差别问题，离线和实时的数据总是有差别，对不齐，体验比拟差。 3.Kappa架构介绍 随着流式计算框架的一直倒退，尤其是针对不重不丢语义的反对越来越好，Confluent公司CEO Jay Kreps于2014年提出了kappa架构。Kappa架构的核心思想是去掉Lambda架构的batch layer，实时计算和离线计算应用同一套代码。通过一套架构来同时满足业务对于准确性、全面性、时效性的要求。 首先，kappa架构必定是解决了Lambda架构的几个毛病，因为实时离线应用一套代码，整个开发成本大大的升高，资源的老本也有了肯定的节俭，同时最要害的是实时和离线的统计做到了对立，打消了各类在离线数据diff问题。那当然，kappa架构也不是完满的，它也有一些毛病： 1）数据回溯的问题，业务口径的变更会带来数据回溯，kappa架构没有离线数据流，回溯的老本是很高的。 2）随着业务的复杂度减少，数据源的复杂度也减少，流式计算环节会面临各种简单关联场景的挑战，开发和保护的老本十分高。 一些新业务，数仓能够从0开始建，Lambda架构的落地老本还是能够承受的。然而大多数状况下，咱们的数仓建设都有惨重的历史包袱，好多存量逻辑面临实时化的革新，而这些革新往往是老本高，收益小。 二、背景 首先介绍一下旧的架构，依据后面讲的大数据架构演进，能够看进去旧的架构是一个Lambda架构。旧的架构也是基于经典数仓架构演变而来，新增了实时流局部，满足业务的高时效性诉求。深蓝的局部是离线流，浅蓝局部是实时流： 1）离线流 最底层是数据源，次要有两类，一类来源于日志打点，比方一些展示日志、点击日志，一类来源于业务的数据库，比方一些订单数据、物料数据。日志打点的数据通过日志采集工具小时或天级采集到文件系统上，业务数据库的数据通过dump工具天级别采集到文件系统上，再通过离线的数据荡涤，构建数据仓库。数据仓库也是经典的分层数仓，数仓下层次要是承接多维分析和报表需要。 2）实时流 日志打点这块通过实时的数据采集，将有时效性要求的数据写入到音讯队列，业务数据库的数据也通过采集binlog等变更流信息，将有时效性要求的数据写入到音讯队列，音讯队列之后就是流式计算环节，这个环节会依照需要，别离进行数据加工，满足策略信号、实时报表、实时利用的诉求。 旧架构在理论的应用过程中，也遇到了一系列的问题： 1）因为业务比较复杂，采纳分层建模，数据表量级在千张级别，表关联场景多，一次查问可能须要关联几十张表，查问时效慢，均匀时效在几十分钟级别。 2）数据提早重大，大部分数据都是天级产出，个别小时级的数据产出也要提早几个小时。 3）实时和离线数据存在差别，不能对齐，每次须要开发两套代码，保护老本高。 三、技术计划1.整体架构 ...

近日，Kyligence 正式实现国内权威鉴证规范 SOC 2 审计，取得 SOC 2 Type II 审计报告。SOC 2 报告是寰球公认最具权威性、专业性的数据安全审计报告。此次 Kyligence 再获权威认证，从数据安全和信息生命周期治理、破绽、安全事件和故障治理、身份辨认和拜访治理、变更治理、可用性治理等多个畛域无力证实了企业产品的高安全性、高保密性及高可用性。Kyligence 也将通过弱小的平安保障体系，打造可信赖的企业级数据分析与治理平台服务寰球客户。 Kyligence 致力于打造下一代企业级智能多维数据库，为企业简化数据湖上的多维数据分析（OLAP）。此次通过 SOC 2 Type II 审计的 Kyligence Cloud 产品及服务体系，利用云计算带来的低成本、高扩大、易运维等特点，使各企业和组织能在数据湖上灵便地开发创新型的大数据分析利用，同时实现老本的最优化，助力用户疾速洞察数据外在价值，驱动商业决策。 Kyligence 产品服务架构图 本次审计由第三方审计机构安永会计师事务所执行。此前，Kyligence 已通过 ISO9001 、ISO27001 以及 SOC 2 Type I 等各项认证及审计。平安合规是 Kyligence 产品设计的重要准则。通过数据保护、⽹络平安、认证与受权和基础设施等⽅⾯的部署，Kyligence Cloud 构建了端到端的平安合规架构，为云上数据分析与治理提供了全⽅位、多层级的企业级平安保障。将来，Kyligence 将持续通过可信赖的企业级产品、欠缺的客户胜利服务体系、继续的技术迭代保障客户利用，一直满足寰球客户在牢靠、稳固、平安、合规等方面的更高要求。 欢送大家致电 400-865-8757 或者拜访 Kyligence 官网理解更多。 对于 Kyligence上海跬智信息技术有限公司 (Kyligence) 由 Apache Kylin 开创团队于 2016 年开办，致力于打造下一代企业级智能多维数据库，为企业简化数据湖上的多维数据分析（OLAP）。通过 AI 加强的高性能剖析引擎、对立 SQL 服务接口、业务语义层等性能，Kyligence 提供老本最优的多维数据分析能力，撑持企业商务智能（BI）剖析、灵便查问和互联网级数据服务等多类利用场景，助力企业构建更牢靠的指标体系，开释业务自助剖析后劲。 Kyligence 已服务中国、美国、欧洲及亚太的多个银行、证券、保险、制作、批发等行业客户，包含建设银行、浦发银行、招商银行、安全银行、宁波银行、太平洋保险、中国银联、上汽、Costa、UBS、MetLife 等寰球知名企业，并和微软、亚马逊、华为、Tableau 等技术领导者达成寰球合作伙伴关系。目前公司曾经在上海、北京、深圳、厦门、武汉及美国的硅谷、纽约、西雅图等开设分公司或办事机构。