大数据

01- 大数据经营的挑战 & 降级思考大数据经营面临的挑战中国电信大数据集群每日数据量宏大，单个业务单日量级可达到 PB 级别，且存在大量过期数据（冷数据）、冗余数据，存储压力大；每个省公司都有本人的集群，以及多个收集全国各省级业务信息的团体大数据集群，导致数据扩散冗余，省集群与团体集群数据无奈共享，跨地区工作提早高。 电信早在 2012 年就开始创立各种集群，外部集群由各个厂商或其余外部团队部署，承载的业务由各个厂商经营，运维团队也是由各个厂商提供，因而集群波及的版本十分多，包含 Apache、CDH、HDP 等多个版本。随着集群规模的一直收缩，运维压力越来越大，定位和修复问题都须要依附厂商，这并不是一种可继续倒退的路线。 为解决现网痛点，强化集群平安，聚焦降本增效，满足内外部撑持需要，2021 年，中国电信组建了 PaaS 自研团队。在两年中，PaaS 团队针对现有的集群进行了优化，保障上万台机器的现有集群安稳运行。 在 2022 年初，PaaS 团队开始自主研发 TDP（TelecomDataPlatform）大数据平台，逐渐替换现有集群，推动产品化。2022 年上半年，通过 Hadoop 2 版本的 TDP 底座部署了两大新集群，开始用于生产业务。2022 年下半年研发了 Hadoop 3 版本的 TDP 底座，开始面对如何应用自研底座降级现网大量的 Hadoop 2 集群的问题。 集群降级思考在降级集群的过程中，心愿新的集群设计能够解决现有痛点，具备业界先进的个性，并且为后续的技术迭代做好前置筹备。 以下是咱们在集群降级的过程中心愿能够解决的问题： 拆分为小集群咱们打算将大集群拆分为小集群，起因如下： 从机器资源层面来说，无奈同时应用几千台机器进行原有业务的迁徙。此外，针对局部十分重要、对 SLA 的保障要求很高的业务，无奈在生产环境间接从 Hadoop 2 原地降级到 Hadoop 3。 每个集群中都有许多不同的业务，将大集群拆分为小集群后能够依照业务进行划分，尽量减少它们之间的影响，升高业务迁徙的压力和危险。拆分成小集群后也能够改善一些工作可能引起的整个集群不稳固的问题，更好地管制稳定性。 举个例子：有些机器学习的工作，并没有应用 Sark、Machine Learning 这样的形式去编写，而是间接在本人的程序中调用 Python 库。这个操作没有限度线程的应用。这样即便工作只申请了 2 核 10G 的内存，实际上也可能把这台机器的负载打到 100 以上。因而，拆分成小集群后，能够缩小工作之间的相互影响，尤其是当平台上须要执行十分重要的工作时，在小节点的状况下，运维工作会绝对容易。 此外，拆分集群还能够防止 Namenode 和 Hive 元数据的收缩，升高整体的运维压力。因而，在业务容许的状况下，打算采纳大集群拆分成小集群的形式进行降级。 降级过程尽量平滑拆分小集群的过程中波及到数据和计算两个维度，数据的迁徙须要大量工夫，如果业务简单，计算也可能须要破费很长时间。因而，须要想方法将数据和计算的迁徙离开，尽量扩充这两个集群之间的并行工夫。 多集群之间的数据互访问题当大集群拆分成小集群之后，须要思考多个集群之间如何做数据互访。同时，在外部零碎中有上万台机器和海量的数据，始终面临着不同类型的数据搬迁、冗余以及冷热数据的问题。 大数据、AI 联合需要咱们的 PaaS 平台正在逐渐承接各种 AI 需要，其中最大的需要之一是非结构化数据的存储。将这部分需要与现有的结构化和半结构化数据存储集成在一起，这也是业界的一个前沿方向。 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群A/B 测试是在雷同的环境下，通过随机的抽样把对照组和控制组进行辨别，并别离履行新旧两种策略，联合肯定的统计办法来管制随机抽样中带来的随机误差，得出两种策略的比照状况，从而能够精确的对新策略成果进行评估。 A/B 测试具备小流量、低危险、抗干扰的特点，随机控制变量并对后果进行量化，以达到精确的评估成果，具备科学性和严谨性。目前 A/B 测试能够通过一些试验平台来进行大规模利用，通过统计策略的评估办法进行因果推断的新规范。 字节跳动的 A/B 测试平台叫做 DataTester，这个平台在字节外部曾经服务了 500 +多条业务线，在线上开的试验总量超过了 150 万个，同时线上运行的试验数有 3 万多个个，并且这些数字仍在继续上涨中。 在字节，A/B 测试是业务决策的根底性能，任何产品上线前都须要做小流量的验证。所有的团队偏向于把产生的每一个新想法都拿去做假如，用一个又一个 A/B 测试去一直验证，甚至是颠覆修改，继续的进行迭代，最终推动业务的增长。小到一条站外推送的音讯，大到整个技术底层架构的优化批改，都会做 A/B 测试。 在字节，A/B 测试被利用最宽泛的是内容举荐、营销流动、经营策略、产品性能以及技术优化这几个方面。“万物皆可 A/B”是字节的理念，甚至是抖音和西瓜视频这两个产品的取名，都和 A/B 测试无关。 字节跳动的 A/B 试验平台长什么样？DataTester 目前曾经正式通过火山引擎对外服务，它基于先进的底层算法，提供迷信分流能力，提供智能的统计引擎，试验后果牢靠无效，助力业务决策。通过火山引擎对外公布的 DataTester，无论对字节外部还是对外，都应用一样的产研团队和技术计划，其根底性能大致相同。 惟一不同的是因为内外部服务的客户不同存在的一些渺小差别。例如对外减少了许多场景化的监控模板，而外部则可能有更多绝对高级的性能。 因为 A/B 测试的整个零碎除了在数据链路上有一些数据产品常见的特色之外，它与业务零碎也有更多的连贯。一站式全栈多场景试验平台的 DataTester 框架整体分成了 5 层。 在应用层，DataTester 服务的行业十分宽泛，除了互联网行业之外，还包含金融、消费品、批发行业、汽车行业，包含泛互联网行业外面的一些细分的子畛域。这些客户在日常很多的工作场景中都是能够做 A/B 测试的。 这些场景形象下来次要包含广告优化、落地页营销流动优化和用户 push 流程、画布触达优化的试验。上面 4 层是 DataTester 怎么去和应用层进行接入来提供服务的。在接入层和会话层。通过 DataTester 的分流服务来聚合客户或外部业务的各种线上触点来进行对接，包含但不限于服务端，客户端，甚至是一些小程序和其余广告投放触点的接入。 内部的次要接入形式是通过 SDK 来进行接入，接入 SDK 的同时也会买通数据上报和数据采集的流程。同时 DataTester 也会通过分流服务，把分流的后果要下发到相应的配置，最初返回给这些利用的服务端或客户端，实现一个接入的过程。最两头也是 DataTester 最重要的一个性能层。 能够划分为三大模块，一大模块是试验治理的相干的模块，包含试验管控、从试验的波及到公布的全流程，还包含了试验的报告，实验报告外面也包含了十分丰盛的剖析性能，以及相干的试验的工具。 这是 DataTester 最根底的一个局部。第二块是智能公布（Feature Flag），DataTester 怎么去失效不同的策略，便捷地做试验的配置、失效和公布。第三块是场景化的利用，包含了一些智能化的利用，DataTester 其次要的性能层也是在这一块。 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群当露营成为年轻人的一种全新生存形式后，连带着户外野营帐篷、可折叠桌椅、卡式炉、多人趣味桌游等露营周边市场都迎来新一轮增长。 受限于户外环境，年轻人在露营期间可供选择的个体娱乐消遣形式更偏差于桌游、垂钓、烧烤等，到了晚间，个体“刷”综艺、电视剧则成了次要消遣之一，但手机、平板电脑、笔记本电脑等设施受限于屏幕大小与音量音质体验，很难满足三人以上的个体观影体验，于是体积小、重量轻、易于携带的投影仪，正在成为年老人们的心头好。 依据国际数据公司 IDC 日前公布的《2022 年投影仪市场年度报告》数据显示，2022 年国内投影仪总出货量为 505 万台，同比增长 7.2%；预计 2023 年投影仪销量无望达到 557 万台，实现匀速增长。 目前来看，随着 4K 技术、激光技术在投影仪上的深度利用，以及 L 形大音腔设计和 3D 平面盘绕音效，用户基于硬件设施的“视觉”“听觉”享受曾经可能失去较好满足。 但另一方面，包含电影、电视、音乐、综艺，甚至是游戏在内的第三方内容资源，以及面向用户的精准举荐，则是国内大多数智能投影硬件厂商的绝对弱势环节。前者能够通过版权购买、与视频网站内容单干等形式解决；而后者则须要通过精细化的数据经营做撑持。 作为国内智能投影仪行业当先的企业之一，峰米（北京）科技有限公司近年来曾先后推出峰米 X1 激光投影仪，小明 Q2 智能投影仪、Q2 Pro 智能投影仪等在内的多款产品，其中小明 Q2 和 Q2 Pro 作为目前千元投影仪市场的“顶配”，兼具个性化和实用性，自诞生之初便备受 Z 世代生产群体欢送，2022 年更被媒体评为「年度卓越千元投影机」。 值得一提的是，小明 Q2 和 Q2 Pro 都采纳了峰米科技在 2020 年 5 月正式公布自主研发的寰球首款面向大屏的智能生态大屏操作系统——FengOS，用户通过 FengOS 即可取得智能化的服务和性能、以及大屏人机交互体验。 数据显示，FengOS 视频量已达万级，月活用户数量超十万级，每日新用户占总当天登录用户的十分之一，如此庞杂的用户和数据量级，很难单纯依附人工经营和制订策略，因而在用户需要洞察和数据分析上，须要借力智能化数据产品。 火山引擎数智平台 VeDI 旗下的增长剖析 DataFinder 也在这时进入到峰米科技眼帘。 目前，峰米科技通过在 FengOS 中接入增长剖析 DataFinder，可能继续洞察用户群体在进入 FengOS 零碎的每一环节动静，实现相干数据的实时积淀，同时还能接入过往历史数据，实现「实时数据+历史数据」的综合剖析，从而制订以“用户需要”为核心的个性化服务，同时联合火山引擎举荐算法，让更多优质的内容可能被动呈现在感兴趣的用户背后，升高用户搜寻老本。 而“更懂”用户需要的峰米科技，也在业务层面取得新增长——峰米科技互联网事业部负责人吴尚走漏，通过引入包含火山引擎数智平台 VeDI 等在内的数智能力之后，用户在线时长显著晋升了 16%-17%，更好的内容体验也让峰米平台的用户付费率晋升了 15%以上。 点击跳转 火山引擎增长剖析 DataFinder 理解更多 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群日前，在 WOT 寰球翻新技术大会上，火山引擎 DataTester 技术负责人韩云飞做了对于字节跳动 A/B 测试实际分享。 DataTester 是字节跳动外部利用多年的 A/B 试验平台，至今已承载了字节外部 500 余条业务线的 A/B 试验工作，累计发展的试验多达 150 万次。 字节跳动外部有着十分浓重的数据文化和试验文化。抖音、今日头条的名字都经由 A/B 测试确定，而 A/B 测试也被作为根底环节，嵌入在了字节外部产品研发的链路中。 通常来说，一个产品新性能的研发流程如下所示： 而字节外部的产品新性能研发流程则会在惯例的根底研发流程中，额定嵌入两个环节：埋点设计与 A/B 试验方案设计。 A/B 试验在字节，就像研发敲代码、产品写需要文档一样，是产品从构思、设计到上线全流程中不可或缺的一环。 举个例子，如果抖音团队心愿晋升产品的用户活跃度，打算通过给产品减少一个“熟人 Tab”的形式进行，那么整个的产品优化改变流程是什么样子的呢？ 首先，从产品经理做 PRD 计划的时候开始，就会提供不止一种产品计划，包含用户门路计划、按钮地位计划等，不同的计划对于用户在抖音上的应用及留存数据，影响肯定是不同的。 多种计划的数据成果，将通过 A/B 测试进行量化。下方的页面款式，就是“熟人 Tab”搁置的 3 种不同计划示例：V0 组：不设置“熟人 Tab”，不呈现“熟人关注内容”，不呈现熟人投稿后展现V1 组：设置“熟人 Tab”，呈现“熟人关注内容”，熟人投稿后展现在“关注 Tab”页V2 组：设置“熟人 Tab”，不呈现“熟人关注内容”，熟人投稿后展现在“熟人 Tab”页 上述 3 组计划即为在 DataTester 中开启试验的 A/B 实验组。 因为抖音的用户体量大，如果粗率的决定某个产品设置可能会对整个生态有很大的影响，因而会首先开启小规模、小流量的多重 A/B 试验。 A/B 试验的目标，一方面要验证这个性能是否能无效达成初始设计指标，另一方面也要验证新性能是否对抖音大盘外围数据有正向影响，如是否能长期晋升用户活跃度以及投稿的志愿等。 在上述提到的例子中，DataTester 的试验结果显示 V2 组试验指标各项均更为优良，阐明新增“熟人 Tab”比照其余计划而言能对抖音价值有更为显著的晋升，那么后续在产品迭代中，会思考全量上线这个产品优化策略。 DataTester 而今也通过火山引擎对外开放服务，截止目前，已服务了包含美的、失去、凯叔讲故事等在内的上百家内部企业，为业务的提效、增长、产品迭代、经营流动等各个环节提供了迷信的决策依据，将成熟的“数据驱动增长”教训赋能给各行业。 ...

报表工具是日常工作中要害且必不可少的内容，须要定期进行保护和更新。不同工夫、不同岗位、不同职责的工作须要不同的报表。 然而，随着工夫的推移，手头的报表会越来越多，而这只是从集体角度登程。当咱们思考一个项目组、一个部门甚至整个组织时，报表会更加繁多和简单。如何无效地实现组织级的报表治理，成为每个企业都想要解决的问题。 以前，很多企业应用Excel来解决和治理报表。Excel是一种电子表格软件，能够用于各种计算和数据处理工作。它能够帮忙用户创立和治理数据表格、图表、图形等，并进行各种计算、数据分析和数据可视化操作。Excel通常是用于集体或小团队的数据处理和剖析，例如在家庭估算、集体财务管理、小型项目管理等方面。 然而，随着企业数据量的增长和复杂性的进步，Excel曾经无奈满足企业的需要。企业须要一种更业余和全面的报表工具来解决大规模的数据、反对简单的数据分析和报告、提供更好的数据可视化和共享性能，以及更好地满足企业的数据管理和报告需要。 为了无效治理报表，企业能够应用报表工具。这些工具能够帮忙企业提取、解决和设计报表，以及将它们公布到外部或内部用户。企业报表工具能够解决大规模的数据，反对简单的数据分析和报告，并提供更好的数据可视化和共享性能，以满足企业的数据管理和报告需要。 在市场上，有许多不同的报表工具可供选择，像Smartbi电子表格软件是基于“真Excel”的报表开发工具，次要提供给依赖技术人员开发中国式报表的企业。电子表格软件非常适合企业外面须要对立治理和利用数据、集中开发报表、灵便分享报表的利用场景；当然如果工作组/部门级利用场景，只须要把角色进行相应的整合，也是不错的抉择。上面咱们通过4个特点来意识Smartbi电子表格软件的个性。 1、成熟电子表格软件应用的核心技术——电子表格，诞生于2013年，至今已倒退10年，是Smartbi获得市场口碑的最大功臣。该技术曾经胜利利用在数千个我的项目，禁受了充沛的市场考验，成熟稳固； 2、可控源于Smartbi长期服务金融客户的基因，电子表格软件复用了“对立平台”的框架和能力，在元数据、多级治理、平安等零碎管控能力上有突出的劣势； 3、玲珑电子表格软件的报表设计器只有4MB大小，但其充沛借用了Excel/WPS表格的编辑和计算能力，联合“对立平台”的服务端能力实现各种中国式报表，堪称神奇； 4、灵便电子表格软件秉承灵便易用的设计思维，不仅容许灵便的抉择数据源表、数据集等数据起源，也容许在Excel中灵便的对数据进行二次加工，而且在Excel中灵便的设计表样、图形、公式、函数，为报表工程师提供了一个施展创意的全新舞台。 在具体产品应用层面，只有在Excel/WPS端装置电子表格软件的客户端插件，用户就能够间接在Excel和WPS中设计报表格局。 相比于市场上其余的报表工具，Smartbi电子表格软件的劣势非常显著。它的设计器采纳准B/S架构，前端浏览Web报表无需插件，登录后即可应用，降级简略便当；还具备“手自一体”的数据筹备能力，灵便满足需要，无论是技术人员还是业务人员，都能找到适宜本人的数据筹备工具；同时还能奇妙利用Excel和WPS本身的表格、图形、函数的能力，实现各种报表利用，并将报表一键公布到Web/App端进行浏览。 Smartbi企业报表工具可能极大水平上升高试用的门槛，晋升数据处理的效率，从而无效地实现组织级的报表治理，点击下方链接即可进行产品体验。 申请试用：https://member.smartbi.com.cn/index/formdesign/foreign/index/...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群日前，火山引擎数智平台VeDI直播流动「超话数据」在线举办，来自火山引擎DataLeap数据产品专家从数据治理与治理，企业数智化降级等角度，分享了DataLeap在字节跳动内的治理教训和实际。 DataLeap是火山引擎数智平台VeDI旗下的大数据研发治理套件产品，帮忙企业疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设，晋升数据研发效率、升高治理老本，自2022年推出至今，DataLeap提供的数据研发治理能力已陆续被多个行业企业所采纳。 本次分享次要围绕以下几个方向开展： 数据治理是数据中台外围能力之一一站式数据治理赋能企业数字化转型基于字节教训的数据治理解决方案以「在线教育」场景为例，解读数据治理实际 企业数字化降级业务场景及痛点1、数据孤岛一种状况是海量数据扩散在各处且形态各异，造成集成艰难；另一种状况则是批量数据和实时数据的集成技术不同，导致集成难度。 2、需要响应慢通常数据开发的需要是反对业务，但个别一个需要从提出到到沟通到交付，周期是2周以上，甚至更长，会影响到业务的一些麻利度。其次数据的需要不好复用，也会波及到像反复开发以及浪费资源的状况。 3、数据品质差第三个痛点是数据品质差，因为数据的杂质比拟多、品质不好，荡涤难度大，当呈现口径不统一的时，会影响到数据产出的时效。 4、资产共享难最初一个是数据资产的共享难，个别企业有让数据资产可能积淀，可能共享的诉求。如果是遇到源数据不欠缺，用户无奈找到数据，同时短少无效的常识体系的一些积淀，对数据价值的开掘也是一个难点。 火山引擎数据中台解决方案一站式大数据研发治理平台火山引擎目前提供的数据中台解决方案由两局部组成：一站式的大数据研发治理平台+大数据的平台。一站式的研发治理平台，它次要解决的包含数据的整合，反对多元异构的数据的接入。 其次是数据的全链路研发治理，包含反对多引擎以及对接各种各样的DATA、OPS、 CICD 的能力。第三层是全生命周期的治理，包含到品质基线、 SLA 等等。一站式的大数据研发治理平台第四层是数据安全共享，提供向细粒度的数据权限管控和审批。 大数据平台大数据平台是一个底座，提供的是数据的存储和计算能力，反对像 TB 到 PB 级的离线，实时检索各种场景。它有两个引擎，一是基于开源 Hadoop 生态的EMR，反对数据湖场景，二是火山引擎自研的湖沧一体剖析服务LAS，兼容开源生态，反对数据仓库&数据湖场景。 大数据研发治理套件 DataLeap 产品架构全链路的数据研发全链路的数据研发，涵盖数据源、数据集成、数据处理、数据服务等全流程。为了进步数据开发效率，DataLeap还提供反对数仓标准建模、代码审查的公布核心，以及反对工作运维、数据回溯的运维监控。 全域治理全域治理，包含治理布局、进度管控到治理收益反馈全流程能力，反对用户实现 SLA 治理、数据品质、数据安全、老本治理以及报警治理等工作。 资产地图资产地图，次要是反对数据资产积淀、数据共享以及数据复用。 要害能力1：一站式数据研发全链路管理一站式的数据研发全链路管理，次要面向研发场景，笼罩从需要设计到开发、测试、公布、验收、运维等全副流程。 首先能提供稳固、平安、高效的数据集成服务，反对 20 +以上多元异构数据集成；其次能提供一站式、全栈数据研发服务，兼容Spark、Flink 等多种计算引擎，提供HSQL、Spark、Python、Flink 、SQL、Notebook等10+数据开发能力；最初是全面的运维能力，丰盛的批、流工作监控规定，归类业务运维治理，监控全链路工作运行。 要害能力2：数据全生命周期治理-分布式数据自治第二个要害能力是全生命周期的数据治理，也可称为“分布式数据自治”。分布式数据自治场景涵盖稳定性、品质、平安、老本优化等内容。 在产品层面，火山引擎DataLeap提供布局式治理、治理诊断以及治理之后的指标验收和复盘，还具备SLA 数据安全资源优化等性能。 要害能力3：数据资产发现及细粒度权限管控第三个要害能力是数据资产发现以及细粒度权限管控，它次要是提供了痊愈的数据采集，基于血统可能展现进去所有的元数据，可能开掘数据价值，可能找数、用数等。数据资产提供了弱小的检索能力。并且DataLeap 有很丰盛的元数据的详情信息，联合数据血统，帮忙用户可能全面地摸索和了解各种各样的数据内容。 DataLeap 提供事先、事中、预先这种全方位的数据安全保障，做到最小受权准则，同时提供弱小的数据审计能力，包含权限审计、行为审计等等。 外围劣势第一是 DataLeap 是可能和多云多引擎开源兼容的一个大数据治理平台的软件产品，方才提到的像 EMR 、LAS 这种平台。 从产品状态上来看，DataLeap 提供私有云的 SaaS 以及私有化多云部署的能力。在研发上，实现了研发全链路笼罩，这是一整套欠缺的能力。第三是字节特色的分布式数据自治， SLA 细粒度的权限管控，事中事先、事中预先的全生命周期的数据治理的能力。第四个劣势是数据资产、地图共享，提供数据专题，指标平台、数据血统链路追踪、数据服务，帮忙搭建企业级数据资产体系和数据共享。 客户案例分享以失去APP为例，失去面临业务数据不稳固、数仓欠缺规范性等治理问题。 通过引入数据 BP 机制，联合专家征询，火山引擎DataLeap帮客户搭建可继续的治理体系。在提效方面，帮忙失去举荐以及落地数据品质和 SLA 达成率，解决了产出提早和脏数据的问题，显著的晋升了数据故障的解决效率，即从 3 天降为1天。同时，DataLeap帮失去积淀出一个规范化数仓，构建出八个业务域，使得数据地图的残缺度晋升，并进步了找数、用数效率。 从施行成果上来讲，失去团队实现从 0 到 1 的数据治理体系搭建，最终实现数据研发提效 50% ，使得4人数仓团队治理超过 3000 个数据工作，数仓易用性也晋升60%。 ...

ChatGPT最近大火，朋友圈、聊天群啊到处都在分享它、探讨它。我也凑了个冷落，先和它聊了一下孩子学习上的困惑，而后用它给孩子出了一套易错题型的练习题，缓解了我做为熊孩子家长的压力。 ChatGET能做的可不止这些，还能写文案，书写代码，写小说，写周报......,ChaGPT的大火，让各行各业看到人工智能的无穷后劲，拉进了科幻和事实的间隔。那么在BI界，是否也有一款像ChatGPT一样智能的BI软件，只有通知它咱们想看啥数据，它噔噔蹬就显示进去给咱们看，那效率得多高啊。明天，我就给大家介绍这样相似ChatGPT的BI产品—Smartbi对话式剖析。 目前市面上的BI软件很多，次要功能模块波及数据挖掘，报表，剖析，仪表板和数据可视化工具等，BI软件能够帮忙企业剖析和可视化其历史和实时数据，更好地了解其业务数据。以便更无效地治理业务决策。 然而目前市场上绝大部分BI软件是通过传统交互方式比方鼠标操作交互来进行数据分析，剖析的步骤多，比方咱们做一个柱图，须要把业务思维转换为图表思维，找到对应的数据集，而后把X轴和Y轴须要显示的字段和业务关联起来。 而通过Smartbi对话式剖析，你只须要输出语言或是语义，通知它你想什么样的数据，比方你说想看“查看2021年合同金额” ，它就会以表格或是图形的形式主动在聊天窗口展现给你。  Smartbi 对话式剖析——随思而行，升高门槛Smartbi 对话式剖析的呈现，解决了传统剖析工具操作门槛高、操作效率低的问题，使数据分析变得更加智能化和简单化。如果你是在出差或是会议中，能够通过手机或是平板在对话式剖析窗口中说出你想要的数据。 比方“看一下近两年广州区域的销售状况”，数据就会以表格或是图形的形式出现，如果你想持续看一下具体广州销售状况，还能够持续问“看一下往年广州区域销售额排名前五的销售状况”，不必放心过长剖析操作限度了你的思路，实现随思而行，高效决策。  插入视频（挪动端视频） 如果你感觉数据分析操作流程长，须要学习，有点麻烦，也能够试试Smartbi的对话式剖析，它能够实现数据分析零门槛。你能够间接在PC端输出想要看的内容，疾速查看后果后，还能够把重点或是有问题的数据一键分享给相干人员查阅。  插入视频（PC端视频） Smartbi 对话式剖析——高新技术，与时俱进对话式剖析是思迈特软件在2021年公布的性能，它基于Smartbi自主研发NLA（自然语言剖析）技术来实现的，NLA技术取得了多项发明专利技术的。 对话式剖析使用了数据建模、常识图谱、语义解析等高新技术，无缝对接各类数据源，将自然语言解析为机器能够辨认的语言，通过后盾的解决主动生成各种可视化图表，实现智能抉择适合图表的可视化出现，达到利用自然语言进行数据分析的目标。 理解详情点击这里：https://www.smartbi.com.cn/talk_analyseSmartbi 对话式剖析——曾经落地多个我的项目利用 Smartbi NLA目前曾经落地金融、制作、高校等行业的多个我的项目中。比方某大型保险团体领导感觉查看数据和数据分析的过程太简单了，操作不够简化，导致剖析的思路常常被打断，他们心愿借助高新科技来解决这个问题。 当他们采纳了Smartbi 的对话式剖析，发现以自然语言对话的形式进行数据分析，剖析效率失去了大大的进步，以前高管均匀一天的工夫只能看报表3.6次，当初晋升到均匀一天6.2次，应用频率和效率晋升一倍。 Smartbi 对话式剖析——取得认可，将来可期Smartbi在技术创新、人工智能等技术畛域，曾经取得来自行业、市场的高度认可。从2020年以来，作为纯BI工具畛域的惟一代表，思迈特软件间断三年成为Gartner中国人工智能守业公司代表厂商。 思迈特软件还和华南理工大学软件学院蔡毅传授（大数据与智能机器人教育部重点实验室主任）团队一起成立人工智能联结实验室，通过产学研深度单干，把先进的科研成果利用落地于理论行业利用场景，让智能对话式剖析成为越来越多行业的抉择，让更多的企业收益。  

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群ByteHouse 是火山引擎上的一款云原生数据仓库，为用户带来极速剖析体验，可能撑持实时数据分析和海量离线数据分析；便捷的弹性扩缩容能力，极致的剖析性能和丰盛的企业级个性，助力客户数字化转型。 本文将从需要动机、技术实现及理论利用等角度，介绍基于不同架构的 ByteHouse 实时导入技术演进。 外部业务的实时导入需要ByteHouse 实时导入技术的演进动机，起初于字节跳动外部业务的需要。 在字节外部，ByteHouse 次要还是以 Kafka 为实时导入的次要数据源（本文都以 Kafka 导入为例开展形容，下文不再赘述）。对于大部分外部用户而言，其数据体量偏大；所以用户更看重数据导入的性能、服务的稳定性以及导入能力的可扩展性。而对于数据延时性，大多数用户只有是秒级可见就能满足其需要。基于这样的场景，ByteHouse 进行了定制性的优化。 分布式架构下的高可用 社区原生分布式架构ByteHouse 首先沿用了 Clickhouse 社区的分布式架构，但分布式架构有一些人造性架构层面的缺点，这些痛点次要体现在三个方面： 节点故障：当集群机器数量达到肯定规模当前，根本每周都须要人工解决节点故障。对于单正本集群在某些极其 case 下，节点故障甚至会导致数据失落。读写抵触：因为分布式架构的读写耦合，当集群负载达到肯定水平当前，用户查问和实时导入就会呈现资源抵触——尤其是 CPU 和 IO，导入就会受到影响，呈现生产 lag。扩容老本：因为分布式架构数据根本都是本地存储，在扩容当前，数据无奈做 Reshuffle，新扩容的机器简直没有数据，而旧的机器上磁盘可能曾经快写满，造成集群负载不均的状态，导致扩容并不能起到无效的成果。这些是分布式架构人造的痛点，然而因为其人造的并发个性，以及本地磁盘数据读写的极致性能优化，能够说有利有弊。 社区实时导入设计High-Level 生产模式：依靠 Kafka 本身的 rebalance 机制做生产负载平衡。两级并发基于分布式架构的实时导入外围设计其实就是两级并发：一个 CH 集群通常有多个 Shard，每个 Shard 都会并发做生产导入，这就是第一级 Shard 间的多过程并发；每个 Shard 外部还能够应用多个线程并发生产，从而达到很高的性能吞吐。攒批写入就单个线程来说，根本生产模式是攒批写入——生产肯定的数据量，或者肯定工夫之后，再一次性写入。攒批写入能够更好地实现性能优化，查问性能晋升，并升高后盾 Merge 线程的压力。无奈满足的需要上述社区的设计与实现，还是无奈满足用户的一些高级需要： 首先局部高级用户对数据的散布有着比拟严格的要求，比方他们对于一些特定的数据有特定的 Key，心愿雷同 key 的数据落盘到同一个 Shard（比方惟一键需要）。这种状况下，社区 High Level 的生产模式是无奈满足的。其次是 High level 的生产模式 rebalance 不可控，可能最终会导致 Clickhouse 集群中导入的数据在各个 Shard 之间调配不均。当然，生产工作的调配不可知，在一些生产异样情景下，想要排查问题也变得十分艰难；对于一个企业级利用，这是难以承受的。自研分布式架构生产引擎 HaKafka为了解决上述需要，ByteHouse 团队基于分布式架构自研了一种生产引擎——HaKafka。 高可用（Ha）HaKafka 继承了社区原有 Kafka 表引擎的生产长处，再重点做了高可用的 Ha 优化。 ...

作者 | 性能中台团队 导读 性能平台负责MEG所有研发数据的治理、接入、传输、利用等各个环节。数据的提速对于公司报表建设、决策分析、转化策略成果都有至关重要的影响。重点介绍数据生产端与生产端提速落地实际，如何高性价比满足大数据生产端提速？如何在数据合规根底上疾速满足数据报表提速？本文从业务优化视角整体介绍提速思路，蕴含5类优化门路，波及18种提速办法。 全文3689字，预计浏览工夫10分钟。 01 概述1.1 性能平台性能平台是APP性能追踪的一站式解决方案平台，为APP提供全面、业余、实时的性能剖析服务与工具链。基于先进的端异样采集能力、实时反混同技术等，提供实时性强、定位速度快、场景丰盛的利用监控剖析能力，并构建异样解决的闭环，在厂内挪动端产品得以大范畴利用，保障挪动端用户体验，无效地缩小了用户散失。 1.2 接入状况已笼罩了厂内大多数重点产品，其中包含：百度APP全打点、小程序、矩阵APP等，数据指标如下： 接入状况：简直笼罩了厂内已有APP，小程序，翻新孵化APP，以及厂外收买APP。服务规模：解决数据千亿/日、端到端入库工夫毫秒级别、笼罩用户数6亿+。1.3 名词解释图灵：新一代数仓平台，在实时计算、存储能力、查问引擎、资源调度等均有晋升。 UDW：Universal Data Warehouse，百度通用数据仓库，UDW用平台化的存储管理、数据管理、数据建设过程治理和元数据管理技术，提供全面、统一、高质量、面向剖析的用户行为根底数据，百度晚期数据仓库。 TM：是一个面向工作流的分布式计算零碎，具备简洁、高可靠性和高吞吐量的个性，且易被不便地治理和监控。可能满足准实时（秒到分钟级）的流式计算需要，故障时能够做到数据不丢不重。 一脉：整合多种数据源的全业务自助剖析工具，为分析师、PM、经营、RD各角色提供服务。一脉突破了原有报表、工具的定制限度，反对零SQL根底的同学可视化拼接查问条件、或间接SQL查问，同时提供多种通用剖析模板供大家应用。 AFS：百度自研的Append-Only分布式文件系统产品，笼罩百度所有业务线，为开发者提供高性能、高可用、高可扩大的存储能力，广泛应用于离线计算、AI训练、数据备份等场景。 1.4 业务介绍覆盖范围：涵盖解体、卡顿、Flutter、端异样、日志回捞、网络库、磁盘等大部分性能场景，笼罩了公司多条产品线数据加工：提供实时、牢靠精确的实时用户监测，秒级准确加工10万QPS吞吐数据。异样感知方面：事火线下检测，事中平台上线check机制、预先分钟级告警、感知并剖析异样，疾速止损；问题分析阶段：多维聚类、多维探测、全网热力求、日志调用链分析、日志回捞等工具，帮助疾速定位问题；02 面临的问题2.1 数据生产阶段数据技术基建落后；存储系统（厂版化无奈迭代）、查问引擎（厂内引擎下线、查问速度较慢）、实时计算（不反对实时引擎）、资源调度（资源弹性弱）等能力有余；数据短少服务分级；外围数据与非核心辨别，服务级别保障机制不明确；离线数据流架构不合理、大量应用公共队列数据SLA无奈保障。预期：实时流数据分钟级别SLA、准实时数据30分钟级别SLA、离线流数据小时级别SLA；数据有效/反复上报；局部点位下线、点位之间性能重合度高仍在上报导致数据总量存在虚高；数据报表冗余，无人拜访或者业务反复；无限计算/存储资源供应到有效数据上。2.2 数据生产阶段数据合规性难保障；数据短少对立进口，数据生产同时存在接口、后果层数据库、中间层数据等零碎中进行数据报表出现，用于数据分析、报警监控。数据需要满足度低；报表类需要占咱们需要整体靠近50%, 数据需要须要点对点独自排期与开发，此研发流程投入大，需要交付速度慢。用户整体满意度低；数据实时性差：从数据产生到数据可被查问，两头存在较高时延(从数十分钟到天级别不等)查问较慢,SLA保障机制弱；数据需要交付慢：用户数据需要齐全依赖数据团队产出，当有人力补充时数据保护/学习老本高，容易呈现Delay，减少字段/批改数据源等会笼罩整个流程。03 优化门路3.1 新老基建比照思路：基于流批一体的思路，通过TM引擎的实时解析平铺 + Spark动静索引导入图灵的形式代替QE引擎动态导入UDW，从而进行ETL阶段的提速，在该阶段提前将嵌套字段进行铺平造成图灵研发大表去除旧数据流中的两头表产出环节。 3.1.1 新老基建比照 3.1.2 新老数据流 3.2 数据服务分级3.2.1 服务分级实践反对进步服务效率：更好地理解用户的需要，提供更加精准、业余的服务，从而进步服务效率。改善服务质量：服务分级能够让用户享受到更加贴近需要的服务，进步服务的品质和满意度。优化资源配置：更好地依据不同的服务需要和服务对象，优化资源配置，进步资源利用率。3.2.2 数据流/报表SLA 3.3 数据点位/指标/报表治理3.3.1 治理思路[外链图片转存失败,源站可能有防盗链机制,倡议将图片保留下来间接上传(img-ezx2sPvX-1678155747102)(https://mmbiz.qpic.cn/mmbiz_png/5p8giadRibbO9765J2SfqzcZFneaE...)] 3.4 数据合规性治理3.4.1 背景介绍2021年9月1日正式施行《中华人民共和国数据安全法》，波及数据的进口管制、数据分类分级、数据合规性等一系列数据方面法律法规要求。数据生产流程减少势必会影响用户应用体验，如何在数据满足合规的根底上疾速助力业务倒退是咱们的致力的方向。 数据BI平台/ 性能平台/其余数据分析平台数据接入计划大抵分为如下几种： 1、直连存储引擎； 2、数据抽象API ； 3、数据自产自销；咱们的业务特点连贯双端研发、多方数据、QA等多方面角色对接，初中期适宜API形式，缓缓收敛到数据自产自销。 补充阐明： 市面上的BI剖析均反对API形式连贯，根本已实现协定标准化。BI连贯数据库查问形式，次要长处在于疾速实现报表，然而在数据合规、数据缓存、负载平衡、多引擎数据聚合等能力上显著弱于API形式。 3.4.2 API优化点举例说明 3.4.3 元数据查问协定阐明// Schema 数据获取能力形容// 协定能力形容：// 1. 数据查问能力,多引擎/规范SQL查问能力封装「如:palo/mysql/clickhouse/es-sql等」Query构造。// 2. 数据聚合能力,具备单关键字数据组合&Merge能力,如果Len(Schema.Query)>1:具备数据聚合能力. // 3. 数据缓存能力,两层级缓存能力封装,Cache构造。type Schema struct { // 元数据查问能力形容 Query []Query `json:"query"` // 元数据整体缓存能力形容 Cache Cache `json:"cache"`}// Query 数据查问能力形容type Query struct { // 结构化查问形容 SQL string `json:"sql"` // 产品线信息, rpc_name = meta_{engine}_{prod}.toml, rpc通信具备超时管制、服务发现、高级负载平衡策略等稳定性晋升能力 Prod string `json:"prod"` // 存储引擎形容, 调用不同引擎能力 Engine string `json:"engine"` // 单次查问缓存能力形容 Cache Cache `json:"cache"`}3.5 数据自助化建设3.5.1 背景介绍通过近一年需要数据分析，报表类需要占整体数据需要的50%，如果实现数据报表自助化，须要依照数仓分层，可达成数据生产侧的需要疾速交付与报表时效性晋升。 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群本文将针对日常开设 A/B 试验过程中一个不太正当的应用办法——AABB 试验进行具体的解释，通知大家为什么不倡议开 AABB 试验。 在开始之前，先来回顾一下“什么是 A/B 试验”，A/B 试验是针对想调研的问题，提供两种不同的备选解决方案，而后让一部分用户应用计划 A，另一部分用户应用计划 B，最终通过试验数据比照来确定最优计划。 一：什么是 AABB 试验家喻户晓，AB 试验就是咱们在总流量中分流出两组用户，一组应用原策略 A，一组应用新策略 B，比拟两个策略的成果。 那么 AABB 试验是什么呢？ 简略来说，在做试验的时候，会从总流量中分流出 2 个原策略组（A1、A2）和 2 个新策略组（B1、B2）。两个原策略组的试验配置截然不同，两个新策略组的配置也是截然不同的。实验者会综合比拟 A1、A2、B1、B2 各组之间的指标差别（但其实少数实验者剖析的办法并没有理论依据，文章前面会作出解释），这样的试验被称为 AABB 试验。 当然，也有实验者会分流出更多策略组（AAABBB、AAAABBBB 等），或者引入多个不同的新策略（AABBCCDD 试验等）。这些试验与 AABB 试验存在的问题趋同，本文中权且先以 AABB 试验为次要剖析对象。 二：为啥总有人想开 AABB 试验在进行了局部用户调研后，火山引擎 DataTester 团队发现，开设 AABB 试验的实验者通常想解决以下问题： 验证用户分流是否“平均” 局部实验者放心火山引擎 DataTester 平台的用户分流不迷信，因而开设 AABB 试验，通过比拟 A1 与 A2、B1 与 B2 之间的试验指标差别，来测验用户分流是否正当。 现实状态下，如果用户分流是随机的，那么雷同的策略组（A1 和 A2 之间），在试验中检测出的指标差别应该很小 。这是用户对于试验后果指标的预期。这时候，如果试验后果中，A1、A2 的指标呈现很大的差别，甚至于出现“显著”，实验者就会认为，是火山引擎 DataTester 后盾的分流机制有问题。然而，这个判断是不迷信的。为什么呢？请浏览下文中的谬误 No.1。 比拟“AA 组内差别”和“AB 组间差别” 有的实验者认为：开设 AABB 试验，如果 AA 之间的试验后果差别很小，AB 之间的试验后果差别较大，那么在这种状况下，我的 B 策略应该就是有用的。这种想法自身没有问题，然而火山引擎 DataTester 的大部分指标提供了置信度性能，此时这种做法就显得有些画龙点睛了。具体的起因参考下文中谬误 No.2 和谬误 No.4。 ...

袋鼠云数栈从2016年公布第⼀个版本开始，就始终保持着以技术为核⼼、平安为底线、提效为⽬标、中台为策略的思维，坚韧不拔地⾛国产化信创路线，一直推动产品性能迭代、技术创新、服务细化和性能降级。 在数栈过来的产品迭代中受限于以后组件的版本，积攒了很多待解决的问题，随着新的性能需要一直减少，很多原先的组件以及交互设计须要进行优化。 2月，随同着数栈 UI5.0 的焕新降级，数栈前端团队一起将组件框架 antd 从 v3.x 降级到了 v4.x，更新组件的 UI，晋升产品的交互体验，使数栈产品可能更加灵便地适应将来产品性能迭代的需要。 本文将总结演绎袋鼠云数栈前端框架Antd 从3.x 降级到4.x 的相干步骤，及在这个过程中踩过的坑，解决的问题。 兼容性问题第三方依赖兼容问题· React - 最低 v16.9，局部组件应用 hooks 重构 （ react 降级相干文档：https://sourl.cn/6bM4Ep） · Less - 最低 v3.1.0，倡议降级到 less 4.x； · @ant-design/icons-antd - 不再内置 Icon 组件，请应用独立的包。 对 3.x 的兼容性解决或者是思考到局部组件降级的破坏性，antd4.x 中仍然保留了对 3.x 版本的兼容，废除的组件通过 @ant-design/compatible 放弃兼容，例如 Icon、Form。 留神：倡议 @ant-design/compatible 仅在降级过程中稍作依赖，降级 4.x 请齐全剔除对该过渡包的依赖。 降级步骤只有一步@ant-design/codemod-v4 自带降级脚本，会主动替换代码。 # 通过 npx 间接运行npx -p @ant-design/codemod-v4 antd4-codemod apps/xxxx# 或者全局装置# 应用 npmnpm i -g @ant-design/codemod-v4# 或者应用 yarnyarn global add @ant-design/codemod-v4# 运行antd4-codemod src留神：该命令和脚本只会进行代码替换，不会进行 AntD 的版本升级，须要手动将其降级至4.22.5。 ...

在当今的信息化时代，数据曾经成为企业经营的重要撑持。数据分析能够帮忙企业发现问题、辨认机会、优化决策，从而晋升业务竞争力。而在数据分析中，可视化报表是一个重要的工具，能够让数据更加直观、易于了解和辨认。明天我要介绍的是一款十分高效的可视化报表工具——Smartbi。 Smartbi是一款国内当先的商业智能可视化报表工具，它能够将数据转化为图表、图像、表格等模式，帮忙企业疾速发现数据背地的价值，优化决策，进步业务效率。在泛滥可视化报表工具中，Smartbi以高效、易用、灵便等特点著称。 Smartbi的高效体现次要体现在以下几个方面： 1、疾速数据处理能力Smartbi反对对多种数据源进行疾速导入、荡涤、解决和剖析。用户能够通过简略的拖拽操作，实现对大量数据的疾速解决，从而缩小了繁琐的手工操作，进步了数据分析效率。 2、自动化报表生成Smartbi反对主动生成报表和图表，用户只须要在数据集成的根底上，抉择相应的报表类型和款式，就能够主动生成报表。这大大减少了手动创立报表的工夫，进步了工作效率。 3、多维度数据分析Smartbi反对多维度数据分析，能够将数据按不同维度进行剖析和展现。用户能够通过交互式图表和图像，疾速理解数据背地的趋势和关联性，从而更好地把握数据背地的价值。 4、多维度数据共享Smartbi反对多种数据共享形式，包含在线分享、邮件发送、数据导出等形式。用户能够将数据分享给团队成员和合作伙伴，独特探讨数据价值，进步业务效率和决策品质。 总的来说，Smartbi作为一款高效的商业智能可视化报表工具，不仅具备疾速数据处理能力，自动化报表生成，多维度数据分析和共享等性能 除了上述提到的高效特点外，Smartbi还有以下特点： 1、易用性Smartbi的用户界面简洁明了，操作简略直观，不须要编写简单的代码或者须要业余的技能。对于非专业人士来说，也能够轻松上手，通过本人的操作和调整，获取所需的数据后果和报表。 2、多样化报表Smartbi提供了丰盛的报表类型和模板，用户能够依据须要抉择不同的报表类型和款式，疾速生成本人须要的报表。同时，Smartbi还反对多种数据可视化形式，包含表格、图表、图像等，使数据的出现更加丰盛多样化。 3、安全性Smartbi具备高度的安全性，能够通过权限设置、加密等措施，爱护数据的安全性和隐衷性。用户能够依据须要设置数据的拜访权限，控制数据的应用范畴，防止数据透露和平安危险。 4、高扩展性Smartbi反对多种数据源和第三方扩大，用户能够依据须要灵便抉择和配置不同的数据源和扩大组件，满足不同的数据分析和展现需要。 综上所述，Smartbi作为一款高效、易用、多样化、安全性和高扩展性的商业智能可视化报表工具，具备极高的价值和竞争力，可能帮忙企业疾速发现数据价值，减速决策过程，进步业务效率和竞争力。 想要理解更多欢送移步Smartbi官网征询！https://member.smartbi.com.cn...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群DataLeap是火山引擎数智平台 VeDI 旗下的大数据研发治理套件产品，帮忙用户疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设，升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。 数据血统是帮忙用户找数据、了解数据以及使数据施展价值的根底能力。基于字节跳动外部积淀的数据治理教训，火山引擎 DataLeap 具备齐备的数据血统能力，本文将从数据血统利用背景、倒退详情、架构演讲以及将来瞻望四局部，为大家介绍数据血统在字节跳动进化史。 背景介绍1. 数据血统是数据资产平台的重要能力之一在火山引擎 DataLeap 中，数据资产平台次要提供元数据搜寻、展现、资产治理以及常识发现能力。在数据资产平台中，数据血统是帮忙用户找数据、了解数据以及使数据施展价值的重要根底能力。 2.字节跳动的数据链路状况数据起源在字节跳动，数据次要来源于以下两局部： 第一，埋点数据：次要来自 APP 端和 Web 端。通过日志采集后，这类数据最终进入到音讯队列中。 第二，业务数据：该类数据个别以在线模式存储，如 RDS 等。两头局部是以 Hive 为代表的离线数仓：该类数据次要来自音讯队列或者在线存储，通过数据集成服务把数据导入离线数仓。通过离线数仓的数据加工逻辑，流转到以 ClickHouse 为代表的 OLAP 引擎。 另外，在音讯队列局部，还会通过 Flink 工作或者其余工作对 Topic 分流，因而上图也展示了一个回指的箭头。 数据去向次要以指标零碎和报表零碎为代表。指标零碎蕴含重要且罕用的业务指标，如抖音的日活等。报表零碎是把指标以可视化模式展示进去。 数据服务次要通过 API 提供数据，具体而言，从音讯队列、在线存储、上游生产以及上图右侧所示的数据流转，都涵盖在数据血统范畴内。 血统倒退详情接下来介绍血统在字节跳动的三个倒退阶段。 第一阶段：2019 年左右开始第一阶段次要提供数据血统根底能力，以 Hive 和 ClickHouse 为代表，反对表级血统、字段血统，波及 10+元数据。 第二阶段：从 2020 年初开始第二阶段引入了工作血统，同时反对的元数据类型进行裁减，达到 15+。 第三阶段：从 2021 年上半年至今在这一阶段，咱们对整个元数据系统（即前文提到的资产平台）进行了 GMA 革新，同步对血统架构进行全面降级，由此反对了更丰盛的性能，具体包含： 首先，元数据品种裁减到近 30 种且时效性晋升。之前以离线形式更新血统数据，导致数据加工逻辑变动的第二天，血统才会产生变动。目前，基于近实时的更新形式，数据加工逻辑在 1 分钟内即在血统中体现。 其次，新增血统生产形式的变更告诉。因为该版本反对实时血统，业务方产生及时理解血统变动的需要，变动告诉性能就是把血统变动状况以音讯队列的模式告知业务方。 再次，反对评估血统品质。新增一条链路，专门服务于血统数据品质。 最初，引入标准化接入形式。为了缩小反复工作、升高血统接入老本，咱们制订了具体的血统接入规范，业务方数据均以标准化形式接入。以上就是整体的倒退状况，目前处于第三个版本当中。 数据血统架构的演进接下来介绍血统架构的演进。第一版血统架构：建设血统根本能力，初探应用场景血统架构 在数据起源方面，目前血统次要包含两个数据起源（见上图左上角）：第一，数据开发平台：用户在开发平台写工作，并对数据加工，由此产生血统数据。第二，追踪数据：第三方平台（即工作平台）对用户埋点等数据进行计算，也会产生血统信息。在血统加工工作方面（见上图两头局部）：这部分会对工作进行血统解析，产生血统快照文件。因为第一版采纳离线形式运行，每天该血统工作均会生成对应的血统快照文件。咱们通过比照前后两天的血统快照文件，来获取血统的变更状况，而后把这些变更加载到图中。除此之外，血统中波及的元数据会冗余一份，并存储到图里。在血统存储方面（见上图左边局部），除了图数据库之外，血统自身也会依赖元数据的存储，如 Mysql 以及索引类存储。在血统生产层面，第一版只反对通过 API 进行生产。最初总结该版本的三个关键点： 血统数据每天以离线形式全量更新。通过比照血统快照来判断血统更新操作，前面将为大家具体解答为什么要通过比照的形式。冗余一份元数据存储到图数据库中。存储模型图中上半部分为表级血统，只包含一种类型节点，即表节点，比方 Hive 表、 ClickHouse 表等。 ...

可能很多人不晓得“数据可视化”具体是什么，而事实上在很多企业里早已利用很久了。 顾名思义，“数据可视化”是将企业数据库里的大量数据转化为视觉信息，通过各种模式可视化图表来对数据进行剖析。随后输入相干的图像和数据会显示到大屏幕，以便于企业管理人员更为便捷地观看。 由此，大量剖析数据信息跳到屏幕上，其剖析后果会更为清晰，可能帮忙管理者找到数据背地的关系和规定，为决策提供根据。 上面举荐几款罕用的可视化工具，大家能够依据本身的状况来应用。 1、 Excel毋庸置疑，Excel报表的普及率在85%以上。我置信大部分敌人都用过Excel的敌人，Excel的应用成本低，而且具备比拟弱小的数据分析工具、丰盛的函数库，能够疾速解决大量数据，进步工作效率。 2、 TableauTableau也是泛滥企业用户应用过的工具。它的长处在于其界面十分便捷，它提供了一系列的可视化工具，能够让用户疾速创立想要的可视化图表，却不须要编写任何代码。甚至它能够反对连贯到多种数据源，包含Excel、MySQL、Oracle等，能够让用户通过点击图表中的元素就能查看不同的数据。 3、Python最近几年，Python也是挺火也的数据分析新力军。它最大的益处是语法简略清晰，学习门槛低，没有编程根底的小白也能够轻松上手。其次Python有许多的第三方库能够去针对这些不同的格局和文件进行解决，而它开发的程序和脚本除了进行数据分析之外还可能对数据实现收集、荡涤、整顿、图表可视化等等操作** 4、Smartbi相比下面这3种数据可视化工具，当初我更偏向用Smartbi电子表格软件。它最大的长处是，只有在Excel/WPS端装置电子表格软件的客户端插件，用户就能够间接在Excel和WPS中设计报表格局。 懂行的敌人就晓得，这个长处对使用者来说是十分敌对的。另外，它的设计器采纳准B/S架构，前端浏览Web报表不须要插件，登录后即可应用，降级简略便当。再者，它基于SQL脚本或可视化拖拽的数据集，因此能在Excel中实现中国企业式报表的设计和公布。 总而言之，Smartbi电子表格软件在晋升了数据分析效率之余，又大大降低了应用门槛。当初Smartbi的官网上有收费的试用申请，大家能够去看看哦。 体验入口：https://www.smartbi.com.cn/sitebigdata

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群近日，火山引擎凭借云原生数据分析平台 ByteHouse，胜利入围行业媒体 Internet Deep（互联网周刊）公布的《2022 云原生企业排行榜》。 作为火山引擎数智平台 VeDI 旗下外围数智产品之一，ByteHouse 起源于字节跳动的外部数智实际，并于 2021 年 8 月正式外对公布，随后在 12 月公布数仓版本。 只管面向企业级市场提供服务的工夫不算长，但 ByteHouse 在过来一年多的工夫里凭借极速剖析体验，以及可撑持实时数据分析和海量数据离线剖析的能力，在多个企业业务的数字化实际中动作频频。 比方银行施行经营监控场景，该场景下的外围目标在于能通过不同数字化工具配合，实现银行用户的增长。但实时经营监控个别须要多套数据分析撑持，包含用户获取渠道剖析、不同用户属性 ROI 体现剖析等等，如此庞杂的数据量解决就能够引入 ByteHouse 的能力。 在具体执行过程中，ByteHouse 团队将该银行的需要拆解为三个阶段：第一阶段：上线整体指标的出现能力，不便银行能从宏观角度把控经营监控场景下的停顿方向；第二阶段：上线罕用指标，聚焦银行外部产品经营团队外围关注的数据去优先构建对应的指标，以可能尽快领导和优化产品经营动作；第三阶段：上线个性化需要指标，如用户行为、剖析细节指标等模板，进一步保障银行外部产品经营团队的数据洞察和应用能力。 在整个需要消化过程中，ByteHouse 不论是从高数据的吞吐和写入性能，还是数据的超低时延，或者是足够疾速的数据查问，都能适配银行施行经营监控场景下经营人员的工作须要，因而我的项目一经上线便备受好评。 而除了经营监控场景，ByteHouse 还在银行包含信用卡业务实时风控等其余场景中失去宽泛使用，帮忙银行实时拉取数据，保留入库后推送至风控规定引擎，从而进一步对数据进行加工和定义，实现风控规定的疾速迭代，数据显示，ByteHouse在该场景下的应用曾经可能笼罩银行信用卡业务日均万笔的交易危险，解决数据量级可达千万级别。 值得一提的是，金融行业还只是过来一年多率先利用火山引擎数智平台 ByteHouse 能力的行业之一。 截至 2023 年 1 月，海王团体、中国地震台网核心等多行业企业都已与火山引擎数智平台 VeDI 达成单干，基于业务个性化需要部署 ByteHouse，以实现更好更快地数智化降级。 点击跳转 对立的大数据分析平台ByteHouse 理解更多

本文介绍是云音乐数据资产化建设相干的内容，介绍了近一年在具体实际过程中的一些阶段性的成绩和思考；具体内容将从资产化建设的背景、近期的实际成绩以及下一阶段的思考与布局共三个方面来开展。 1 从几个典型的问题登程“我要取个数有没有现成的表？”，“按xx报表这个指标的口径，我想取清单明细怎么弄？”，“这么多表，很多指标存在多张表，哪个才是正确的？”…… “咱们的数仓建设得好不好？”，“数仓建设进度到哪儿了？模型公共性/拓展性如何？”，“数据品质怎么评估啊？”，“完整性、一致性、准确性、及时性 ？”，“如何量化？”…… “咱们建了几万张表了，到底有啥用呢？”，“谁在用咱们的表？用得怎么样？”，“建了这么多表，有什么价值？”…… 演绎问题，造成三类痛点：数据生产、数据生产、数据价值 2 初期所面临的内外环境2.1 外部环境在整个行业降本增效的大环境下，公司在近段时间也须要做相干的致力。咱们的数据资产化也是围绕降本增效的主旨，领导全链路的数据建设工作。 2.2 外部状况退出云音乐初期，云音乐数仓曾经具备了8年多的积攒，表总量达到6w+，数据库70+，业务线10+，存储空间超过100P，数据生产和生产相干的人员几百人，线上线下的计算工作10w+，大数据年度老本超过1.5亿，在等同业务规模下的业务复杂度和计存老本曾经达到了行业前列。 在过来几年，不论是业务环境还是团队人员都经验了好多轮的迭代，会面临很多事实的问题，诸如：继续一直的需要（来自业务、商分、技术、职能部门等）、永远短缺的人力资源，更可怜的是，基建能力的绝对有余会使得后面两个问题陷入继续好转的困境。 这也应该咱们大多数人可能面临的状况，很少有时机可能碰到从0-1到数据仓库搭建机会，更多是在前人积攒的现状下，一边持续反对业务，一边腾出手来做外部优化。 3 我的思考和口头3.1 找出线头：从数据生产端切入边建设边治理，相似开着飞机换引擎，必须在撑持失常业务需要吞吐的前提下，抉择ROI最高的形式来疾速拿到后果，并且被感知到。生产侧是一个比拟好的切入点。三个理由： 生产侧对于数据资产变动的感知最间接；现有根底上从底层开始颠覆革新代价过高，且危险和人力老本均不可承受；历史积攒的很多“宝藏资产”有被挖掘利用的价值。这里有一个很事实的问题值得咱们思考：为什么咱们建设了这么多有价值的表，生产方还常常感觉到数据不够用？——是真的不够，还是说找不到？有问题的中央就有咱们致力晋升的空间。 建得多vs不够用 这样的体感错位的问题，实质上是 生产视角vs生产视角 的错位，导致用户生产决策链路上破费了太多的老本，从开始到放弃，陷入“不好找、不敢用、从新做、建更多、更难找”的恶性循环。 咱们做了三件事件，来解决这个问题： （1）精简数据模型：梳理现有数仓模型表，提炼每块业务的外围表清单，将长期不必的库存表、疑似废除的垃圾表、适度设计的烟囱表等进行淘汰整合 （2）重塑信息结构：以生产视角，重新整理外围表清单的信息组织模式，编撰数据资产白皮书，并继续保鲜 （3）产品化经营：搭建连贯数据生产和生产的门户，提供数据资产化经营的平台——数据资产门户 起初咱们用灵犀文档编撰了数据资产白皮书的第一版，搭建一个简略的门户portal导航，并配套埋点以便统计门户拜访状况。 随后在与网易数帆大数据产品团队的交换单干下，促成了数据地图-数据专辑的上线，不便团体内各BU更好地从生产场景来组织本人的数据资产信息结构。 至此，数据仓库团队有了本人的产品阵地来承载外围数据资产，以便后续逐渐在消费者心中树立权威外围资产的心智。 3.2 抽丝剥茧：数据生产端的治理 不同于生产端的绝对轻量化的形式，在数据生产端的治理则是切实从细节一点点地沉下去继续打磨。咱们从立规范、搭工具两方面同时进行，来逐渐拆解落实整个数据治理工作。 这里须要答复的是第二类问题：“如何量化数据仓库的建设？” 如下图所示，咱们引入高质量、强标准、低成本三方面的指标来综合掂量之。 具体的施行过程，因为很多历史起因，既定的数仓研发标准并没有失去很好的落实，很多环节须要须要人工染指梳理。因而整个治理工作也会在不同阶段重点关注不同的指标用来牵引团队的工作重心。 通过近一年的实际落地，云音乐数仓外部曾经对“三度”指标体系达成了共识，并作为日常工作中的北极星指标时刻关注。 数据治理并非一锤子买卖，整个过程如果须要做到可继续，须要有配套的机制和工具来辅助。因而咱们设立了一系列的准则，来确保整个治理体系有序进行： 治理有根据权责有归属机制可继续成果可回收办法可积淀 通过跟网易数帆大数据团队单干，咱们拿到了生产链路的元数据血统，并以此建模，造成生产治理可行的根底；权责到人&机制保障 使得整个过程可能有序落地。在过程中，同时积淀了一系列的可视化监控看板和治理跟进工具，确保过程量化可控。 4 获得的一些成绩一图胜千言。 须要补充阐明的一点是，不仅仅是绝对值相干的数字后果可观，从增速趋势、产出稳定性以及研发人员的日常意识方面，都是有显著的正向晋升成果。  5 数据系统的全局长期指标思考提到数据系统，不仅仅蕴含数据仓库自身，还波及到上游生产零碎、中游数据平台、上游生产圈人洞察、报表零碎、智能服务等等，数据中台作为串联上下游的环节，是整个数据系统的外围。 在第一阶段的资产化建设达成指标后，咱们更须要从新来扫视利用视角的效率问题。如何升高上游业务利用的复杂性，则成为一个新的指标和命题。如下图所示，有一些事件曾经在进行中，更多能力建设还在路上。 6 阶段性实际小结用一张图来小结一下咱们在过来一年的生产实践中，曾经落地和正在落地的一些成绩产出，在面向业务的全域数据建设的根底上，在数据的采、建、管、用环节积淀一些列的方法论和工具集，一直夯实咱们的基建，做到降本增效，同时摸索数据联合业务的赋能计划和机会，更近一步摸索数据商业化的门路。 7 对于将来一张图，一场仗，一颗心 数据资产化是这场仗的终点，但远未达到起点，起步于资产化建设，与兄弟团队们一起逐渐饱满数据业务的大图。 使命和愿景 以数据资产思维和数据服务思维，一直推动数据中台化建设，打造云音乐数据对立，品质牢靠，服务便捷，治理平安的数据资产建设、治理和服务平台，是咱们这个团队的使命和愿景，愿与宽广有志之士共同努力！ 本次的分享就到这里，谢谢大家。 理解更多网易技术，试用大数据产品 ...

本文讲述字节跳动一款 App 产品的数据治理故事。该产品随着用户体量和数据体量一直增长，数仓的任务量、数据量也一直攀升，运维难、老本贵、稳定性等问题在一直凸显。通过应用火山引擎 DataLeap 的数据治理能力，3 个月工夫将计算成本大幅缩减 20%。 该产品是一款近千万级 DAU 的产品，疫情 3 年，催生了大量的线下需要转型至线上，海量的数据尽管为产品发明了微小的价值，然而也增高了计算成本和存储老本。“老本治理专项”成为了这个产品的重要工作之一，为了解决数据治理的问题，产品接入了火山引擎自研的大数据开发套件——DataLeap，次要围绕下述两个场景进行老本治理： 1. 疾速启动并取得收益 大数据场景下计算资源的重要价值和低廉老本，须要每个工作都按需应用。而在理论的业务开发过程中，存在大量的异样计算工作，节约了大量的计算资源。计算场景也因而成为该产品数仓团队老本治理的要害切入点。 通过 DataLeap，数仓团队能够设置明确治理指标，并配置治理域，通过选定各种规定的工作治理，比方敞开/下线有效工作、优化高耗时并且占用资源 TopN 工作、优化资源申请不合理 TopN 工作、优化表产出小文件 TopN 工作等，由此对队列阻塞状况进行改善，实现阶段性进行缩容。 DataLeap 还反对对工作执行进行全链路监控，主动发现这些异样的计算工作，并在工作台进行展现，让数据研发人员能够查看相应工作，并采取治理措施。 2. 按季度继续治理 数据治理是一项长期性、系统性的工作，通过 DataLeap 平台，该产品优先实现了数据按季度继续治理。 DataLeap 平台提供一系列工作圈选规定，能够圈选出有效、高耗时、资源申请不合理、小文件异样、近 7 天内无更新、写入数据、近 90 天无拜访表等规定，进行定期扫描，由此实现周期性老本治理。除此之外，DataLeap 还提供告诉、一键拉群等治理经营操作，反对查看治理成果，积淀治理教训，无效推动数仓团队老本推动停顿。 其次，为了能更直观监测到数仓衰弱度、量化治理成果，产品团队还引入了 DataLeap「衰弱分」体系。一旦呈现衰弱分不达标状况，会及时限度产品应用资源比例、资源申请等。DataLeap 还反对忙碌和闲置时段队列资源利用率的监测，能够帮忙飞书数仓团队优化任务调度措施。 最终，该产品的数仓团队次要从 YARN 和 HDFS 切入，在引入 DataLeap 的三个月内，疾速落地老本治理我的项目。在计算治理场景，实现 YARN 队列老本升高 20%；在存储治理场景，已开释 7PB 存储空间。 计算治理 达成指标：缩容 20% 的 CPU core，YARN 队列老本升高 20%治理场景 回收低使用率/老旧队列有效工作下线高耗时工作 &占用资源 TOP N 优化存储治理场景达成指标：开释 7PB 存储空间 随着数据的一直累积和业务的一直倒退，大数据的体量将会变得越来越大，而随之而来的宏大老本，也成为了大数据建设中越来越无奈漠视的问题。 火山引擎 DataLeap 基于字节跳动业务场景和实践经验，积淀有一套残缺的数据品质、SLA 治理、资源优化、告警优化的能力，能够为业务提供晦涩顺滑的数据治理体验；在流程上，笼罩布局式、响应式的用户数据治理双路，同时与各业务密切配合，落地和积淀多项治理规定。 ...

如何可能预知一个产品的将来？最好的方法当然是穿梭到将来看一看。 这种“模仿将来、窥探底牌”的构想仿佛只是一种天方夜谭。尤其在数字化浪潮冲击下，局部行业增长陷入困局，一些企业甚至面临生存挑战。在产品调整和版本更新的决策上，企业愈发审慎。有太多案例通知企业：失败和增长只在一念之间。无论产品还是企业，其命运的终局逃不出一个个小决策的叠加。这也意味着在前行的有数节点上，企业须要继续面对抉择焦虑。 令人庆幸的是，A/B测试让企业的“预知将来”变成了可能。A/B测试是指对不同策略进行比照试验，依据后果抉择最优计划。通过试验和数据排除主观臆断的误差，确定最优解。在少数人眼中，对A/B测试可能略感生疏，但对于字节跳动、谷歌、微软等国内外科技公司，A/B测试却是不可或缺的工具。 以字节跳动为例， A/B测试曾经融入公司的各个环节，和写代码一样，是业务根底的必备一环。抖音和今日头条等产品命名、交互设计、举荐算法等设置，无一不通过了 A/B测试的测验。A/B测试这种工具尽管重要，但在国内认知却非常无限。早在几年前，针对企业面临的流量红利消退、用户增长压力大、业务增长等问题，字节跳动就着手搭建了云服务平台火山引擎，将字节跳动疾速倒退过程中积攒的增长办法、技术能力和工具凋谢给内部企业，提供云根底、视频与内容散发、大数据、人工智能、开发与运维等服务，帮忙企业在数字化降级中实现持续增长。 值得一提的是，火山引擎推出 DataTester 工具，将 A/B 测试能力凋谢给更多行业。已经仅存在于互联网公司外部的秘密武器，现在正在走进更多畛域和企业。 在实现增长的企业故事里，不乏 A/B 测试的身影。 失去的“工具论”：产品改版不必再纠结“成小事者，不纠结。”这是失去创始人罗振宇常挂在嘴边的一句话。现实情况却远没这么简略。作为头部常识服务平台，失去将满足用户短时间内获取无效常识的需要为指标，改版针对性强、更新频率高则是平台引以为傲的特点。 截止2022年1月30日，失去APP累计用户规模就曾经冲破1亿人。如果改版方向谬误，不仅会节约推广投入，更致命的是浪费时间和影响口碑。面对高频率多选项的改版需要，仅仅依附商业直觉判断是很难不纠结的。失去抉择用数智化工具实现不纠结。自从引入火山引擎 A/B 测试 DataTester 工具后，A/B 测试广泛应用在失去的算法调优、转化晋升、内容浸透等方面。 仅 2022 年第三季度就开启试验超过 20 个，成功率达 80%，间接促成了产品渗透率和转化率的晋升。具体到实操层面上，A/B 测试就是在失去产品正式版本公布之前，为同一个指标制订两个（或以上）计划，将一小部分用户流量分成几组，让用户别离看到不同的方案设计，依据几组用户的实在数据反馈，迷信地帮忙产品进行决策。 俗话说得好：“鞋子适合不适合，只有上脚后才晓得。”以优化首页直播滚动布局为例，改版前屏幕只能露出一个直播模块，老师和题目显示存在感低，影响直播转化。DataTester 将设计布局晋升转化作为次要试验指标，设定了两个计划推给等同规模的用户进行试验： 从后果来看，B 组转化率高出 A 组 8%。在数据和试验的反对下，失去首页改版顺利落地。在打磨产品展现细节、晋升购买转化率上，DataTester 同样无效。在课表页面，试验测试了“默认收起课程表+点击开展课表”，以及“默认全副展现露出课表”两个选项。 在挪动产品设计上，收起内容的页面设定颇为风行，但测试数据显示后者体现更好。有试验和数据撑持，冲破风行设定改版也就更有底气。 通过 DataTester 的数据能力，失去对毕业证书展现页面、搜寻展现等进行了多维度优化和改良，常识付费行业最难晋升的“复够率”都有了显著提高。在用户增长艰巨的当下，失去的案例为增长提供了一种新思路。 用 A/B 测试，优化企业获客、转化、留存、复购的每一个环节，以数据为底色的取舍机制和逻辑，正在重塑企业决策。在创投圈，有句话很闻名——“抉择比致力重要，与谁同行比要去的远方更重要”。 关上思路，不局限于科技互联网企业，对于任何打磨产品细节，晋升要害数据有所谋求的企业，抉择一款成熟的数字工具，都会让决策变得些许轻松。 悟空租车的 A/B 功效：间接晋升 App 盈利A/B 测试不止能在细节调整上给出取舍意见，对于产品流程设计也能提供正当抉择。 如果流程改版波及到挑战“常识”，决策者就更须要来自数据和试验的信念。改版被动缩短用户领取门路，这不是悟空租车的一步“昏招”，而是让支出增长 7%的“神操作”。A/B 测试提供的数据撑持，让悟空租车敢于剑走偏锋。悟空租车创建于 2014 年，是国内头部预约出行服务平台。 截止 2022 年底，平台已覆盖全国 460 余个城市,服务网点超 4.7 万个,可租车型超 6000 款,产品应用用户达高达 2200 多万。用户在应用汽车在线租赁平台流程中，选车付款以外还有一个重要环节——押金缴纳。 更重要的是，如用户无奈应用信用进行免押金选项，就必须间接缴纳一笔大金额押金。从生产心理层面，大额领取的暗影会间接“劝退”不少用车客户，拉低平台成单率。面对领取流程上的痛点，悟空租车决定有所扭转。 ...

背景LSM-Tree（ Log Structured-Merge Tree）是数据库中最为常见的存储构造之一，其核心思想在于充分发挥磁盘间断读写的性能劣势、以短时间的内存与 IO 的开销换取最大的写入性能，数据以 Append-only 的形式写入 Memtable、达到阈值后解冻 Memtable 并 Flush 为磁盘文件、再联合 Compaction 机制将多个小文件进行多路归并排序造成新的文件，最终实现数据的高效写入。 Apache Doris 的存储模型也是采纳相似的 LSM-Tree 数据模型。用户不同批次导入的数据会先写入内存构造，随后在磁盘上造成一个个的 Rowset 文件，每个 Rowset 文件对应一次数据导入版本。而 Doris 的 Compaction 则是负责将这些 Rowset 文件进行合并，将多个 Rowset 小文件合并成一个 Rowset 大文件。 在此过程中 Compaction 施展着以下作用： 每个 Rowset 内的数据是按主键有序的，但 Rowset 与 Rowset 之间数据是无序的，Compaction 会将多个 Rowset 的数据从无序变为有序，晋升数据在读取时的效率；数据以 Append-only 的形式进行写入，因而 Delete、Update 等操作都是标记写入，Compaction 会将标记的数据进行真正删除或更新，防止数据在读取时进行额定的扫描及过滤；在 Aggregate 模型上，Compaction 还能够将不同 Rowset 中雷同 Key 的数据进行预聚合，缩小数据读取时的聚合计算，进一步晋升读取效率。问题与思考只管 Compaction 在写入和查问性能方面施展着非常要害的作用，但 Compaction 工作执行期间的写放大问题以及随之而来的磁盘 I/O 和 CPU 资源开销，也为零碎稳定性和性能的充分发挥带来了新的挑战。 在用户实在场景中，往往面临着各式各样的数据写入需要，并行写入工作的多少、单次提交数据量的大小、提交频次的高下等，各种场景可能须要搭配不同的 Compaction 策略。而不合理的 Compaction 策略则会带来一系列问题： ...

摘要：本文整顿自阿里云资深技术专家李钰(绝顶)在 阿里云EMR2.0线上发布会 的分享。本篇内容次要分为三个局部：1.EMR 平台概述2.EMR2.0 新平台外围能力3.总结一、EMR 平台概述EMR 平台是开源大数据的云原生运行环境，阿里云EMR 依据云原生的特点，在弹性伸缩、稳定性、智能化和研发效力四个方面进行了大量的性能优化： Elasticity 弹性伸缩，算力按需申请开释，冲破IDC物理限度；Stability 稳定性，故障节点主动替换弥补，要害事件主动告警；Intelligence 智能化，智能探查资源节约，预警集群潜在危险；Efficiency 研发效力，业务高效开发调试，作业一键调度上线。 二、EMR2.0 新平台外围能力Elasticity 弹性基于工夫的弹性伸缩能力弹性规定：定时减少或者缩小 ECS 实例数量；实用场景：业务负载变动存在工夫周期性；老本节俭：通过采取这种策略，与预置固定资源相比能够节俭大量资源；应用抢占式实例能够进一步降低成本；应用形式：在节点组上设置扩容规定的时候，抉择按工夫扩容；反对以下设置：执行频率和执行工夫；规定的有效期；重试过期工夫；单次扩容的节点数等。 基于指标的弹性伸缩能力弹性规定：通过预设的基于负载指标的规定，动静调整 ECS 实例数量；实用场景：业务负载动态变化，无固定工夫周期性；老本节俭：通过采取这种策略，能够动静的适应业务负载的变动；应用抢占式实例能够进一步降低成本；应用形式：在节点组上设置扩容规定的时候，抉择按负载扩容；反对以下设置：集群负载指标（比方“YARN 资源队列 pending 利用数”）；指标统计周期和统计规定；反复几次后扩容；单次扩容的节点数；冷却工夫等。 反对抢占式实例能力：反对实例规格筛选，单节点组可抉择多达10种不同规格；老本优化策略反对主动选取高价实例规格出价；成果：生产实证可升高80%+老本；典型客户案例撑持；应用形式：创立抢占式实例节点组：在集群创立实现后，新增抢占式实例的节点组；抉择实例规格：1）节点组的配置中抉择抢占式实例规格，最多能够抉择十种规格，能够依据每种规格的开释率和折扣率进行取舍；2）同时也反对依照资源筛选规格，比方：4核16G； 反对两种不同的策略：1）优先级策略，节点组所有实例都必须应用抢占式实例，而后依照设定的优先级程序申请抢占式实例； 1.劣势：最大化的降低成本；2.劣势：抢占式实例库存有余时，业务无奈及时获取到所需资源； 2）老本优化策略，会智能的优先应用抢占式实例，在抢占式实例库存有余时会补充按量实例； 1.劣势：在及时响应业务资源需要和综合老本上达到较好的均衡。 性能大幅晋升EMR新平台相比于老平台在性能上失去了大幅晋升，次要体现在以下三个方面： a. 高并行能力 节点组内和多节点组间均反对并行扩容反对缩容期间并行扩容，反对突发业务变动b. 疾速响应能力 更高的弹性速度，100节点扩容工夫<2分钟更快的感应速度，指标检测周期<30秒；c. 大规模服务能力 单次反对扩容节点数>1000；下图中左边的柱状图显示了 EMR1.0 和 EMR2.0 平台弹性扩容速度的比照，能够看到，EMR2.0 新平台对于不同规模的弹性扩容速度都能够稳固的管制在两分钟之内，扩容工夫不会随扩容节点数减少线性增长。 Stability 稳定性反对节点故障容忍和弥补EMR新平台反对节点故障容忍和弥补，次要体现在两个方面： a. 故障节点不影响扩容 Core/Task 节点 CPU 打满不影响扩容；Core/Task 节点 OS Hang 不影响扩容；Core/Task 节点宕机不影响扩容；b. 计算节点故障主动替换弥补 Task 节点 OS Hang 反对主动弥补；Task 节点磁盘满反对主动弥补；Task 节点网络问题反对主动弥补；节点故障容忍和弥补须要手动开启。依据后盾统计，在开启后，集群全场景稳定性可晋升1个9。 更加全面的服务巡检和事件告诉a. 服务巡检 在集群服务页面能够看到所有的大数据引擎服务，以及每个引擎组件的衰弱状态；针对不同组件的健康检查项进行继续巡检，并实时上报；帮忙用户及时发现和解决问题；b. 事件告诉 ...

此套面试题来自于各大厂的实在面试题及常问的知识点，如果能了解吃透这些问题，你的大数据能力将会大大晋升，进入大厂不可企及获取本文《2023最新大数据面试宝典》完整版带目录的PDF文档，请搜寻公众号【五分钟学大数据】，在对话框发送 2023面试 ，即可获取。参考链接：2023版最新最弱小数据面试宝典，附答案解析 温习大数据面试题，看这一套就够了！ 本文目录： 一、Hadoop\二、Hive\三、Spark\四、Kafka\五、HBase\六、Flink\七、Clickhouse\八、Doris\九、数据仓库\十、数据湖\十一、必备SQL题\十二、必备算法\十三、大数据算法设计题 前言此版本面试题相较于之前减少了很少数仓以及算法相干的题，同时新增了数据湖，必备SQL题，Clickhouse，Doris等面试题。 版本更新如下： 版本工夫形容V1.02020-12-18创立V1.22021-01-17新增：spark 面试题V1.32021-01-18新增：kafka 面试题V1.42021-01-20新增：hbase 面试题V1.52021-01-30新增：flink 面试题V3.02022-01-10新增：数据仓库，算法等面试题修复：局部答案不残缺或有误V4.0（此版本）2023-02-12更新：数据仓库及算法；新增：数据湖，必备SQL题，Clickhouse，Doris，大数据算法设计题获取本文《2023最新大数据面试宝典》完整版带目录的PDF文档，请搜寻公众号【五分钟学大数据】，在对话框发送 2023面试 ，即可获取。完整版链接：2023版最新最弱小数据面试宝典，附答案解析 HadoopHadoop中常问的就三块，第一：分布式存储(HDFS)；第二：分布式计算框架(MapReduce)；第三：资源调度框架(YARN)。 1. 请说下HDFS读写流程这个问题尽管见过无数次，面试官问过无数次，还是有不少面试者不能残缺的说进去，所以请务必记住。并且很多问题都是从HDFS读写流程中引申进去的。HDFS写流程： Client客户端发送上传申请，通过RPC与NameNode建设通信，NameNode查看该用户是否有上传权限，以及上传的文件是否在HDFS对应的目录下重名，如果这两者有任意一个不满足，则间接报错，如果两者都满足，则返回给客户端一个能够上传的信息；Client依据文件的大小进行切分，默认128M一块，切分实现之后给NameNode发送申请第一个block块上传到哪些服务器上；NameNode收到申请之后，依据网络拓扑和机架感知以及正本机制进行文件调配，返回可用的DataNode的地址； 注：Hadoop在设计时思考到数据的平安与高效, 数据文件默认在HDFS上寄存三份, 存储策略为本地一份，同机架内其它某一节点上一份, 不同机架的某一节点上一份。客户端收到地址之后与服务器地址列表中的一个节点如A进行通信，实质上就是RPC调用，建设pipeline，A收到申请后会持续调用B，B在调用C，将整个pipeline建设实现，逐级返回Client；Client开始向A上发送第一个block（先从磁盘读取数据而后放到本地内存缓存），以packet（数据包，64kb）为单位，A收到一个packet就会发送给B，而后B发送给C，A每传完一个packet就会放入一个应答队列期待应答；数据被宰割成一个个的packet数据包在pipeline上顺次传输，在pipeline反向传输中，一一发送ack（命令正确应答），最终由pipeline中第一个DataNode节点A将pipelineack发送给Client；当一个block传输实现之后, Client再次申请NameNode上传第二个block，NameNode从新抉择三台DataNode给Client。HDFS读流程： Client向NameNode发送RPC申请。申请文件block的地位；NameNode收到申请之后会检查用户权限以及是否有这个文件，如果都合乎，则会视状况返回局部或全副的block列表，对于每个block，NameNode都会返回含有该block正本的DataNode地址；这些返回的DataNode地址，会依照集群拓扑构造得出DataNode与客户端的间隔，而后进行排序，排序两个规定：网络拓扑构造中距离 Client 近的排靠前；心跳机制中超时汇报的DataNode状态为STALE，这样的排靠后；Client选取排序靠前的DataNode来读取block，如果客户端自身就是DataNode,那么将从本地间接获取数据(短路读取个性)；底层上实质是建设Socket Stream（FSDataInputStream），反复的调用父类DataInputStream的read办法，直到这个块上的数据读取结束；当读完列表的block后，若文件读取还没有完结，客户端会持续向NameNode 获取下一批的block列表；读取完一个block都会进行checksum验证，如果读取DataNode时呈现谬误，客户端会告诉NameNode，而后再从下一个领有该block正本的DataNode 持续读；read办法是并行的读取block信息，不是一块一块的读取；NameNode只是返回Client申请蕴含块的DataNode地址，并不是返回申请块的数据；最终读取来所有的block会合并成一个残缺的最终文件；2. HDFS在读取文件的时候，如果其中一个块忽然损坏了怎么办客户端读取完DataNode上的块之后会进行checksum验证，也就是把客户端读取到本地的块与HDFS上的原始块进行校验，如果发现校验后果不统一，客户端会告诉NameNode，而后再从下一个领有该block正本的DataNode持续读。 3. HDFS在上传文件的时候，如果其中一个DataNode忽然挂掉了怎么办客户端上传文件时与DataNode建设pipeline管道，管道的正方向是客户端向DataNode发送的数据包，管道反向是DataNode向客户端发送ack确认，也就是正确接管到数据包之后发送一个已确认接管到的应答。 当DataNode忽然挂掉了，客户端接管不到这个DataNode发送的ack确认，客户端会告诉NameNode，NameNode查看该块的正本与规定的不符，NameNode会告诉DataNode去复制正本，并将挂掉的DataNode作下线解决，不再让它参加文件上传与下载。 4. NameNode在启动的时候会做哪些操作NameNode数据存储在内存和本地磁盘，本地磁盘数据存储在fsimage镜像文件和edits编辑日志文件。 首次启动NameNode： 格式化文件系统，为了生成fsimage镜像文件；启动NameNode： 读取fsimage文件，将文件内容加载进内存期待DataNade注册与发送block report启动DataNode： 向NameNode注册发送block report查看fsimage中记录的块的数量和block report中的块的总数是否雷同对文件系统进行操作（创立目录，上传文件，删除文件等）： 此时内存中曾经有文件系统扭转的信息，然而磁盘中没有文件系统扭转的信息，此时会将这些扭转信息写入edits文件中，edits文件中存储的是文件系统元数据扭转的信息。第二次启动NameNode： 读取fsimage和edits文件；将fsimage和edits文件合并成新的fsimage文件；创立新的edits文件，内容开始为空；启动DataNode。5. Secondary NameNode理解吗，它的工作机制是怎么的Secondary NameNode是合并NameNode的edit logs到fsimage文件中； 它的具体工作机制： Secondary NameNode询问NameNode是否须要checkpoint。间接带回NameNode是否查看后果；Secondary NameNode申请执行checkpoint；NameNode滚动正在写的edits日志；将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode；Secondary NameNode加载编辑日志和镜像文件到内存，并合并；生成新的镜像文件fsimage.chkpoint；拷贝fsimage.chkpoint到NameNode；NameNode将fsimage.chkpoint重新命名成fsimage；所以如果NameNode中的元数据失落，是能够从Secondary NameNode复原一部分元数据信息的，但不是全副，因为NameNode正在写的edits日志还没有拷贝到Secondary NameNode，这部分复原不了。 6. Secondary NameNode不能复原NameNode的全副数据，那如何保障NameNode数据存储平安这个问题就要说NameNode的高可用了，即 NameNode HA。 一个NameNode有单点故障的问题，那就配置双NameNode，配置有两个关键点，一是必须要保障这两个NameNode的元数据信息必须要同步的，二是一个NameNode挂掉之后另一个要立马补上。 元数据信息同步在 HA 计划中采纳的是“共享存储”。每次写文件时，须要将日志同步写入共享存储，这个步骤胜利能力认定写文件胜利。而后备份节点定期从共享存储同步日志，以便进行主备切换。监控NameNode状态采纳zookeeper，两个NameNode节点的状态寄存在zookeeper中，另外两个NameNode节点别离有一个过程监控程序，施行读取zookeeper中有NameNode的状态，来判断以后的NameNode是不是曾经down机。如果Standby的NameNode节点的ZKFC发现主节点曾经挂掉，那么就会强制给本来的Active NameNode节点发送强制敞开申请，之后将备用的NameNode设置为Active。如果面试官再问HA中的 共享存储 是怎么实现的晓得吗？ 能够进行解释下：NameNode 共享存储计划有很多，比方Linux HA, VMware FT, QJM等，目前社区曾经把由Clouderea公司实现的基于QJM（Quorum Journal Manager）的计划合并到HDFS的trunk之中并且作为默认的共享存储实现。 基于QJM的共享存储系统次要用于保留EditLog，并不保留FSImage文件。FSImage文件还是在NameNode的本地磁盘上。 QJM共享存储的根本思维来自于Paxos算法，采纳多个称为JournalNode的节点组成的JournalNode集群来存储EditLog。每个JournalNode保留同样的EditLog正本。每次NameNode写EditLog的时候，除了向本地磁盘写入 EditLog 之外，也会并行地向JournalNode集群之中的每一个JournalNode发送写申请，只有大多数的JournalNode节点返回胜利就认为向JournalNode集群写入EditLog胜利。如果有2N+1台JournalNode，那么依据大多数的准则，最多能够容忍有N台JournalNode节点挂掉。7. 在NameNode HA中，会呈现脑裂问题吗？怎么解决脑裂假如 NameNode1 以后为 Active 状态，NameNode2 以后为 Standby 状态。如果某一时刻 NameNode1 对应的 ZKFailoverController 过程产生了“假死”景象，那么 Zookeeper 服务端会认为 NameNode1 挂掉了，依据后面的主备切换逻辑，NameNode2 会代替 NameNode1 进入 Active 状态。然而此时 NameNode1 可能依然处于 Active 状态失常运行，这样 NameNode1 和 NameNode2 都处于 Active 状态，都能够对外提供服务。这种状况称为脑裂。脑裂对于NameNode这类对数据一致性要求十分高的零碎来说是灾难性的，数据会产生错乱且无奈复原。zookeeper社区对这种问题的解决办法叫做 fencing，中文翻译为隔离，也就是想方法把旧的 Active NameNode 隔离起来，使它不能失常对外提供服务。 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群 近日，国内开发者技术社区稀土掘金公布「2022 稀土掘金引力榜」，旨在盘点 2022 年在数字化转型畛域内最具影响力、创新力及潜质的集体、企业、产品、案例。 其中，火山引擎 ByteHouse 凭借新一代的云原生架构，高效不便的运维模式，以及高性能更灵便的实时查问，胜利入围《Top10 年度翻新产品》榜单。 作为火山引擎数智平台 VeDI 面向企业级用户输入的数智产品之一，ByteHouse 起源于字节跳动的外部数智实际。2017 年，字节跳动大规模启用 ClickHouse，并领有着大规模 ClickHouse 集群。 在继续应用过程中，字节跳动应答了诸多挑战并将每一次教训加以积淀，在 2021 年 8 月正式公布 ByteHouse，并通过火山引擎对外服务。 从架构上来看，火山引擎 ByteHouse 与其余同类型产品相比，采纳了自研的高可用引擎，反对数据实时更新、删除，新增了自研的查问优化器，并且在集群的运维和多表关联的场景都做了相应的加强。 全自研的查问优化能力，让 ByteHouse 能够保障用户在简单查问的场景下具备更高的查问效力，这对器重实时数仓能力的用户来说，尤为重要。比方，丰盛的表引擎不仅能帮忙企业用户实现数据的疾速写入去重、更新、删除与剖析，还能反对高效不便的运维形式，实现高性能更灵便的实时查问。 截至目前，包含中国地震台网核心、海王团体等都已与火山引擎 ByteHouse 达成单干，尽享海量数据实时剖析的极速体验，实现本身数字化降级的进一步减速。 点击跳转 对立的大数据分析平台ByteHouse 理解更多

作者：王奇（花名慧青） 阿里云Hologres研发 随着实时数仓在业务生产零碎的遍及，资源弹性、资源隔离等保障业务稳定性方面的技术需要开始变得越来越迫切。Hologres在保障业务方面继续优化核心技术竞争力，过来一年中，Hologres翻新提出并实现了新一代弹性计算组实例，旨在通过更强的隔离和弹性能力，进一步提高业务零碎的稳定性。Hologres弹性计算组在2022年双11也胜利落地阿里泛滥外围业务场景，比方阿里巴巴CCO客服体验部，助力CCO在大促场景中实现更加安稳的客服调度和问题解决。 通过本文，咱们将会具体介绍Hologres弹性计算组实例的实现原理，助力更多业务进一步晋升企业级资源隔离和弹性能力。 大数据面临资源、老本、隔离、弹性的综合挑战在业务倒退初期，数据量和并发访问量较小的状况下，利用传统的实时数仓能够轻松满足各类业务数据的剖析。随着业务的极速倒退，业务复杂度、数据量、并发访问量逐渐减少，实时数仓技术开始被越来越多的业务应用，并逐步在生产业务中落地。于此同时，业务也开始不可避免的遇见剖析场景、服务场景、离线加工场景等场景的零碎负载抵触等资源隔离问题，业务对系统的隔离和弹性能力都提出了更高更严苛的要求，尤其是像双11等大促场景上，零碎须要有负载隔离、弹性等高可用能力来撑持更加迅猛的流量峰值。 传统分布式系统是通过正本和隔离来实现业务生产零碎的进一步稳固，而要实现生产更高的稳固也须要面临肯定的取舍和挑战： 零碎面向流量洪峰时的动静可扩大能力零碎因意外或者故障宕机时的疾速恢复能力多正本隔离带来的资源老本问题业务高下峰时资源的弹性能力.......为了解决以上挑战，实现更加稳固、弹性、低成本的零碎，Hologres一直演进其技术能力： 在产品设计之初，就采纳存储计算拆散模式，能够十分高效的实现资源程度扩大能力，满足不同流量洪峰对资源的不同需要内置调度零碎，实现了节点故障、Failover的疾速检测以及主动调度恢复能力，即便有节点挂了，也能疾速的拉起和切换，保障节点的可用性反对资源组隔离、多状态Replication包含Binlog、单实例Replication、主从实例等，无效解决数据读写拆散、实现资源隔离、故障隔离....更多对于高可用的实现请见>>Hologres高可用技术揭秘 随着业务的倒退和技术的演进，以及企业对降本增效的诉求加深，如何在降低成本的同时还能放弃更加极致的隔离和资源弹性能力，又成为实时数仓技术的另一大挑战。为了应答这个挑战，在往年Hologres翻新提出建设实现了新一代弹性计算组实例技术，与主从实例不同之处在于，业务能够通过将计算资源合成为不同的计算组模式，不同的计算组共享一份存储，计算资源可弹性调配，按需创立，可同时完满撑持读写拆散、资源隔离、业务隔离等诸多场景。 上面咱们将会介绍Hologres弹性计算组实例的具体技术实现原理和最佳应用实际。 Hologres技术再降级：新一代弹性计算组实例Hologres弹性计算组实例设计的最终目标是为用户提供高更强的资源隔离，不仅具备灵活性（即买即用）、资源隔离、弹性和极致扩展性等特点，最大化解决用户在数据分析上的诸多痛点难点问题，让“数据价值”不再可望不可即。 1、整体架构Hologres弹性计算组实例采纳 Multi-cluster&Shared Data架构，将计算资源合成为不同的计算组（一个计算组能够了解为一个Virtual Warehouse，下文对立简称Warehouse），计算组独立弹性可扩大（弹性调配、按需创立），计算组之间共享数据、元数据。 基于弹性、隔离和低成本的前提，Hologres弹性计算组实例的外围组件的设计都具备灵便扩大扩大、资源隔离的个性。外围组件次要有分为三个层面：以一个实例为例 计算组：计算组是独立弹性可扩大的计算资源，负责执行用户的查问申请。用户能够依据业务需要，创立不同的计算组，通过不同的计算组来撑持业务需要，比方写入、查问等。数据存储：数据存储在Alibaba Pangu存储服务上，不同的计算组共享一份pangu存储，无效节俭存储资源。云服务组件：云服务组件包含网关、Meta Service、Holo Master 等，次要有数据管理、平安认证治理、对立接入治理，以及节点治理等能力。 上面针对每个组件做更具体的介绍。 2、计算组Warehouse购买了一个Hologres实例之后，就领有了计算资源。而计算组Warehouse是由 Hologres的一组计算节点组成，用户能够通过SQL的形式非常灵便的按需定制每个计算组的计算资源大小。 --示例：创立一个128Core的WarehouseCALL hg_create_warehouse ('warehouse_1', 128);目前Hologres每个实例默认最多能够创立 10 个 计算组(可调整)，每个计算组最小为 32 Core，最大 512 Core(guc可管制)，用户能够依据须要设置适合的大小。 Warehouse之间共享数据、元数据，不同的计算组拜访同一个数据目录；计算组的内存局部的数据(mem table)会进行同步，默认是最终统一模式，也反对配置为强统一模式。 Warehouse具备资源隔离、弹性等外围能力，上面咱们次要逐个介绍。 资源隔离能够依据业务需要创立多个计算组，每个计算组之间是共享同一份数据，并任意按需扩大计算组的数量和配置，底层只须要存储一份数据。不同负载的查问工作能够运行在不同的计算组上，计算组之间的计算资源是相互独立的。每个计算组上能够并发运行多个查问，每个查问申请会被路由到某个计算组进行执行；不同的计算组不会共享计算节点，因而不同 计算组 上运行的查问之间相互不会有资源竞争和性能影响，这样能够保障不同负载的查问之间互不影响性能，做到很好的资源隔离。 因为不同的Warehouse之间人造的计算资源隔离，因而能够通过多个计算资源组的形式实现不同的隔离需要： 读写隔离：一个实例既有写入又有查问时，如果因为写入过猛，会应用大量的资源，就会导致查问因期待资源而呈现超时、变慢等问题，通过设置不同的计算组，能很好的解决因写入争抢资源，导致查问变慢的问题。读读隔离：在实时数仓场景上，一个实例可能会有多种查问需要，比方对内的BI报表OLAP剖析，对外的风控、举荐等在线服务，且不同的OLAP剖析业务的保障水平可能也会不同，当有大query须要耗费较多资源时，可能会导致其余SQL因期待资源而变慢、超时等问题，尤其是在线服务场景，如果变慢可能会影响在线业务。能够通过设置不同的计算组，来撑持不同的查问场景，查问之间互相隔离，互不影响，能无效的进步在线服务的稳定性写写隔离： 依据不同的业务需要，不同写入工作之间的优先级会有不同，通过设置不同的计算组，能够很好的实现写入拆散、离线写入拆散，以及 实时写入 和 离线写入等写入之间的隔离，保障写入的稳定性。业务场景隔离：除了工作、查问和写入之间的隔离，还能够通过Warehouse实现不同业务之间的隔离。将多个业务部门依照不同的计算组 隔离开，实现业务之间的齐全的资源隔离，防止业务之间相干影响。弹性作为纯正、弹性的计算资源，能够通过SQL的形式在任意工夫进行按需地创立、删除或者重新配置Warehouse。创立或者删除计算组不会影响底层存储的用户数据。能够依据业务需要动静地创立或者扩容计算资源，实现最大水平上的资源弹性，这样就能很好的满足用户在顶峰和低谷对不同资源的诉求。 计算组的弹性能够为用户带来性价比更高的服务：在简直同样的价格下，用户能够享受更快的性能。 例如：如果某个工作负载在4个计算节点上执行须要破费15个小时，那么在30个计算节点上执行可能只须要破费2个小时。尽管这两种模式的价格差不多，然而带给用户的体验却有着基本的区别：在同样破费的状况下，性能越快用户感触就越好。而计算组的弹性恰好提供了极佳体验的抉择，通过动静配置计算组，以更快地实现计算工作，然而并不需要额定多的破费开销。 Hologres 具备人造的计算存储拆散架构，因而能够同时做到计算、存储高度可扩大，在弹性计算组的加持下做到双重弹性。 3、数据存储Alibaba Pangu是阿里巴巴自研的分布式文件系统，将并不高牢靠的服务器中的磁盘连接成一个整体，向外提供平安稳固易用的文件存储能力，具备有限容量及性能扩大、繁多命名空间、多共享、高牢靠和高可用等个性。 Hologres借助Pangu 分布式文件系统，对用户提供高性能、高牢靠、高可用、低成本、弹性存储空间、弱小稳固平安等外围存储服务。不同的计算组共享一份pangu存储资源，这样就能无效的节俭存储资源，数据不须要存储多份，没有冗余，同时也保障了数据的一致性。 4、云服务组件在Hologres弹性计算组实例模式下，云服务组件也规范模式统一，包含元数据管理、平安认证治理、对立接入治理等能力，其中： 元数据管理：每个实例有对立的元数据管理的服务，被各个计算组共享。Hologres Gateway 次要负责 对立的 平安认证、接入治理 等，并负责对立的高性能路由转发和连贯治理Warehouse的能力Hologres弹性计算组实例产品劣势通过Hologres弹性计算组实例能够十分不便的反对/实现以下劣势： 1、生态兼容Hologres弹性计算组实例兼容Hologres已有产品状态，已有实例可无缝平滑迁徙至弹性计算组实例，应用计算组时能够像应用一个独自实例一样不便。性能应用上也无任何差别， Hologres自身内置的函数、 SQL扩大等全面兼容。 2、弹性可依据业务负载需要即时扩缩容计算组，同时也能够按时或按需暂停或者拉起计算组(Scale Out)，此外计算组可动静热扩缩容(Scale Up)，这样就能使得资源失去最充沛的利用。 ...

    目录 1. 钻研范畴定义2. 事务型关系数据库市场定义3. 厂商评估：万里数据库4. 入选证书 1.    钻研范畴定义在国内数字化转型以及信创建设继续推动的大背景下，泛滥厂商入局国内数据库市场，为企业提供了面向多种利用场景的数据库，以及相干的生态工具或服务。国内数据库市场因而迎来了诸多新的变动，新的产品类型、新的技术、新的服务，以及新的市场格局，而这些变动也让企业在抉择数据库时须要思考更多简单的因素。在本报告中，爱剖析将数据库市场划分为数据库产品、数据库工具和数据库服务。其中，数据库产品包含各种类型的数据库，如事务型关系数据库、剖析型数据库，以及图数据库、时序数据库等专用数据库等；数据库工具包含各种用于数据库治理运维、开发测试的工具；数据库服务包含征询布局、施行部署等服务。图 1：  数据库市场全景地图 综合思考细分市场的市场规模、企业关注度等因素，爱剖析在本次钻研中选取了事务型关系数据库、剖析型数据库、超交融数据库、图数据库、数据库云治理平台5个细分市场，进行重点钻研。本报告面向各行业企业的IT部门、大数据部门、科技翻新部门，以及相干业务部门的负责人，通过对各个特定市场的需要定义和代表厂商能力解读，为企业数据库布局与厂商选型提供参考。通过深刻调研，爱剖析遴选出具备成熟解决方案和落地能力的厂商，供企业在做数据库选型时进行参考。同时，在该市场下，爱剖析重点选取了事务型关系数据库厂商万里数据库进行能力评估。 2.    事务型关系数据库市场定义定义：事务型关系数据库是指采纳行和列形成的二维表格模型来组织数据，通过关系模型对表进行连贯，并针对数据“增改删”的事务处理而设计的数据管理系统。事务型关系数据库需具备事务的ACID个性、并反对SQL拜访和解析等性能。甲方终端用户：各行业企业的IT部门、大数据部门、科技翻新部门，以及相干业务部门甲方外围需要：近年来，随着企业数字化转型步入深水区，为了应答数据量爆发式增长、业务场景多样化扩大的趋势，甲方企业对于事务型关系数据库的选型要求也在一直晋升：除了要保障根本的零碎运行稳固及服务的可靠性，也须要数据库具备低劣的性能来更好地反对银行存取转账、电子商务订单等大规模的交易解决场景。此外，随着国家信创政策的一直深入，企业对应用的国外商用数据库替换的需要也一劳永逸，尽可能缩减迁徙改变老本成为甲方企业的次要诉求。具体而言，企业对于事务型关系数据库的外围需要包含： 可能稳固牢靠地运行。作为数据管理系统的外围，企业须要事务型关系数据库具备对外服务响应的灵敏性、整体零碎运行的流畅性和数据服务的可靠性，保障业务零碎可能稳固运行。数据库服务高可用。许多如银行、电信、政务等行业的重要业务零碎都要求数据库提供7*24不间断服务，须要事务型关系数据库尽可能缩短因为保护或者故障造成的服务不可用工夫。因而，在零碎硬件产生故障、人为出错或者软件报错等状况下，企业须要数据库服务可能在肯定工夫范畴内切换至可用状态，并且保证数据零失落。具备高性能的事务处理能力。面对数据量爆发式增长、业务场景多样化扩大的趋势，企业须要数据库可能实现海量数据处理的工作，并且反对大量业务人员同时进行读取或写入的事务处理场景。在诸如“双十一”、秒杀流动等高并发的交易解决场景，企业须要数据库可能提供毫秒甚至更短的响应工夫来面对一直增长的业务需要。要尽可能升高数据库替换老本。因为信创政策对数据库国产化的要求，企业须要对传统应用的国外商业数据库进行替换。在替换过程中，须要尽量减少对原有业务的革新，并且尽可能连续下层利用的应用。此外，自动化的数据迁徙工具也成为企业升高迁徙老本的需要之一。丰盛的生态资源。企业会对数据库的周边生态有肯定依赖性，因而生态资源的丰盛水平也成为甲方选型的思考因素之一，尤其是周边工具所提供的性能反对。 此外，局部企业对于事务型关系数据库还有以下冀望需要： 在某些行业，事务型关系数据库须要满足信创资质要求。在党政军、金融等须要严格保障信息安全的行业，核心技术须要自主可控来保障安全性。因而，企业须要严格参照信创测试报告或者信创名录来进行数据库选型。此外，因为某些企业曾经进行了国产化软硬件的部署，须要数据库可能在国产IT环境中顺利运行。 厂商能力要求：基于上述外围需要，数据库厂商需具备以下能力： 厂商提供产品可能稳固地运行在企业的业务环境中，并且保障事务数据的可靠性。具体而言，厂商产品提供数据的充沛冗余，并且保障备份数据的一致性。同时，具备欠缺成熟的机制保障事务处理的一致性。其次，厂商产品被宽泛驳回应用，运行的稳定性失去企业及用户的认可。厂商产品可能提供高可用的数据服务。厂商产品提供具备齐备的容备灾机制，反对数据的充沛冗余。在数据节点因为硬件故障或人为失误导致不可用时，备灾节点可能疾速切换，保障服务不中断。如果集群无奈提供服务，厂商有其余用于备灾的数据中心对服务进行无损接管，同时要保障服务的切换复原工夫在企业的可承受范畴内。在性能方面，厂商提供的产品具备事务的高吞吐、横向扩大和并发解决能力，并且反对数据的实时写入和读取。在海量事务处理的场景下，厂商提供分布式部署的事务型关系数据库产品，具备高吞吐能力来升高零碎服务的响应工夫，并且通过横向扩大来撑持一直增长的数据量。在读写高并发的需要下，事务型关系数据库须要具备肯定的并行执行能力，并且通过平衡调配读写负载来反对大量业务人员同时进行查问或写入操作。厂商数据库产品可能对企业原有数据库进行低成本替换。厂商提供的产品须要对相应被替换的数据库产品语法兼容，保障替换后下层利用的安稳运行，并且不须要进行太多的业务革新。此外，产品配套的迁徙工具也可能升高数据迁徙老本，不便企业做数据库替换。厂商提供的产品具备肯定的生态资源。厂商的产品具备肯定的周边生态工具和服务，或者可能兼容支流生态，可能满足企业对生态资源的应用需要，尤其是生态中数据库周边工具要可能满足数据库应用全生命周期的性能反对。 针对局部企业的冀望需要，数据库厂商需具备以下能力： 厂商提供的产品须要满足信创的要求。厂商的产品须要通过了相应的信创测试或进入了信创名录，证实了本身技术的自主可靠性。此外，厂商产品对甲方企业应用的国产操作系统、芯片等软硬件进行了相应适配，可能保障数据库系统在国产IT环境的安稳运行。 入选规范： 合乎事务型关系数据库的厂商能力要求；近一年在该市场服务客户数10家以上；3．近一年该市场相干服务收入规模在1000万元以上。 3.    厂商评估：万里数据库 厂商介绍：北京万里开源软件有限公司（简称“万里数据库”）成立于2000年，专一于国产自主可控的数据库产品技术研发，打造了性能、性能、稳定性、易用性当先的一站式数据库产品与解决方案，已服务金融、运营商、能源、政府、交通等多行业重点客户，助力超1000个利用场景实现国产化代替与数字化转型。万里数据库领有发明专利、软件著作权百余项，是国家级专精特新“小伟人”企业，已参加多个国家级的数据库行业标准制订工作。产品服务介绍：万里数据库GreatDB是一款国产自主可控的关系型数据库，可依据用户需要采纳分布式或集中式部署，具备动静扩大、数据强统一、集群高可用等企业级个性，满足业务高并发、高扩展性、高安全性等严苛的事务处理和轻量剖析需要，齐全兼容MySQL生态，兼容适配了国产支流操作系统、芯片等根底软硬件，广泛应用于金融、运营商、能源、政府等行业，其衍生的开源分支版本GreatSQL可间接对官网MySQL进行兼容替换。厂商评估： 万里数据库GreatDB在产品稳固可靠性、MySQL和Oracle技术兼容性、部署灵活性、容备灾能力和服务等方面具备劣势，在分布式和集中式部署下的性能体现能够满足金融、运营商、能源等重点行业多样化的场景需要，同时GreatDB可能适配支流国产软硬件，满足企业对信创的要求。 在产品能力上，GreatDB稳固牢靠且性能体现强劲，具备金融、运营商等多个重点行业外围业务零碎的技术撑持能力，可能满足海量数据、高并发场景下对事务容错性和解决效率的要求。如金融行业，万里数据库服务的全国股份制银行对立领取零碎，部署超24个节点，峰值撑持超2000TPS，采纳同城双活架构实现机房级的高牢靠，确保RPO=0；运营商行业，万里数据库服务的四川挪动开关机零碎，部署约10个节点，峰值撑持超4500TPS，撑持顶峰订单每日超2000万，指令下发量10000万，保障全省用户的各类根底业务及增值业务性能的办理开明。 在稳定性方面，GreatDB通过事务管理器的轻量化和读写快照的无锁化解耦，配合在通信网络技术上的优化，整体升高了网络稳定对事务响应工夫的影响；在可靠性方面，GreatDB采纳多正本冗余和 Paxos 协定来保障事务数据的强一致性；在容灾备份方面，GreatDB采纳备份复原机制，同城双活或三活加上异地容灾集群的部署达到了RPO=0和RTO<60秒的高可用性。在性能方面，GreatDB针对事务处理要求严苛的场景优化了SQL并行执行、事务快照保护、正本复制协定等方面来晋升整体性能体现；同时，GreatDB在小规模配置场景下性能体现良好，在国产鲲鹏等服务器上，用三台机器性能能够达到100万TPMC。 在技术能力上，GreatDB全面兼容MySQL及其生态，同时兼容Oracle语法及性能个性，助力企业顺畅实现数据库国产代替。在与MySQL的兼容性方面，万里数据库作为原MySQL中国研发核心积攒了深厚的技术教训。在语法上，GreatDB全面兼容MySQL的语法和性能个性，可能反对MySQL上既有业务的平滑迁徙。在生态上，GreatDB兼容了MySQL生态中数据链上下游的各种工具，可提供面向多元化终端用户的数据库工具链，升高了GreatDB用户的工具学习和应用老本。GreatDB还可能兼容Oracle的语法和性能个性，如递归查问、DBLink、窗口函数、序列等，升高了对Oracle存量业务替换的老本。 如万里数据库服务的河北挪动对立接触库的Oracle国产化代替我的项目，基于GreatDB的各类Oracle语法兼容个性，替换过程中业务保留了大量的Oracle个性语法，确保了我的项目周期和迁徙老本可控。在部署模式上，根据客户不同的业务场景需要，GreatDB可能采纳集中式或分布式的灵便部署模式。针对海量数据、并发量高的业务场景，客户能够抉择分布式的模式部署GreatDB，利用并行计算放慢数据处理能力，同时还能保障数据一致性，将来还能按需继续扩容；针对数据量偏小、对稳定性和事务一致性要求极高的业务场景，客户能够抉择应用集中式的部署模式。在国产生态上，GreatDB适配支流国产软硬件，满足国家信创要求。GreatDB与支流国产芯片（如龙芯、申威、飞腾、鲲鹏、海光、兆芯）、操作系统（如麒麟软件、统信UOS、麒麟信安、TurboLinux等）和第三方利用等软硬件适配，充沛满足企业在信创方面的需要。在开源奉献上，万里数据库主导成立了GreatSQL社区，助力开源数据库生态。GreatSQL社区致力于打造国内支流的开源数据库中国根社区，为金融、运营商、能源等泛滥行业客户提供自主可控的开源数据库产品。GreatSQL数据库实用于金融级利用，能够齐全兼容MySQL或Percona Server。目前，GreatSQL社区已笼罩2000+技术开发者，被Gitee评为“最有价值开源我的项目”。在技术服务上，GreatDB领有欠缺的服务体系和丰盛的利用实践经验，能够保障服务响应的及时性和故障解决能力。GreatDB配套的规范服务包含施行阶段的现场部署、调试，上线之后的故障处理、应急响应等；高配服务提供整体架构解决方案的设计探讨、迁徙过程和业务调试的配合等服务。万里数据库服务过银行、电网、运营商等多个行业的大型头部企业客户，曾为某银行客户提供MySQL源码级专家服务。公司在全国设有北京、上海、成都、广州、福州5个技术服务中心，分公司服务范畴覆盖全国，充沛保障了服务响应的及时性。 典型客户：四川挪动、河北挪动、中信建投、国家气象局、首都信息团体4.    入选证书  

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群在广告投放的场景下，一线广告优化师通常会创立多个打算，去测试不同的广告素材成果。 这套办法看似迷信，实际上却存在诸多问题：当广告打算过多时，容易使流量无奈平均分配而造成数据获取艰难，并节约广告优化师大量人力；同时，适量的广告打算，没方法将受众齐全实现隔离，如果同一用户能够看到多组广告，则测试后果无奈保障科学性。 这些问题间接导致企业在进行广告投放时节约了大量的工夫精力和金钱，最初也未必能失去迷信量化的的无效论断。 在互联网时代，企业该如何做好广告营销，让每 1 块钱都花在刀刃上，通过广告投放继续驱动盈利增长呢？ 火山引擎 DataTester 或者能够交出一份称心答卷。DataTester 是字节跳动外部利用多年的 A/B 试验平台，基于本身在因果推断和统计迷信方面的多年积淀，联合字节外部用户增长以及广告算法建设的诸多实际，摸索出了很多卓有成效的广告成果掂量办法和晋升策略。 针对企业在营销场景上的诸多痛点，DataTester 提供了全套的广告优化解决方案：在试验配置方面，对试验智能化调优，按照广告成果动态分配流量，实现收益最大化。 同时，买通了前后链路数据以及人群数据，实现产生正向反馈越滚越大的复利效应。 DataTester 领有跨渠道广告投放的能力，与多个建站工具深度单干，打造广告落地页搭建和 A/B 试验创立的无缝体验，大幅升高试验门槛。 DataTester 全域营销场景解决方案针对具体不同的场景，DataTester 还提供了拆分比照试验、落地页优化试验、增效度量试验、H5 落地页优化试验等多种试验类型，不便用户更加便捷地基于试验进行迭代。 DataTester 广告试验的细分类型广告试验作为 DataTester 在全域营销场景的重要解决方案之一，具备了大规模人群精准分流、广告页主动开启 A/B 试验、额定提供“MAB 试验”试验类型抉择的四个外围劣势。 例如，在收集到短缺的试验数据之后，DataTester 可能智能化生成剖析报告，并确保数据具备统计效劳，以准确披露在试验中获胜的广告打算或素材。 火山引擎 DataTester 已与橙子建站等多个广告落地页建站平台深度单干，在企业实现广告落地页搭建后，即可无缝开启 A/B 试验，大幅升高试验创立门槛，帮忙企业收益最大化。 DataTester 交融了字节跳动了多年在业务增长、转化、产品迭代，策略优化，经营提效等环节的增长理念，是一款性能弱小、应用便捷的 A/B 试验产品。此外，DataTester 也可能深度耦合举荐、搜寻、UI、产品性能等其余多种业务场景需要，为业务提供迷信的决策依据。 2020 年，DataTester 通过火山引擎面向内部企业凋谢服务，服务了美的、失去、凯叔讲故事等在内多家标杆客户，将成熟的“数据驱动增长”教训赋能给各行业。 点击跳转 A/B测试 DataTester 理解更多

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群2 月 9 日，国内当先的数字化市场钻研与咨询机构爱剖析公布了《2022 爱剖析·DataOps 厂商全景报告》（以下简称报告），报告面向金融、制作、汽车、消费品批发、能源等行业的大数据部门负责人、IT 部门负责人和业务部门（业务部门 ITBP），通过对 3 个特定市场的需要定义和代表厂商能力解读，为企业实现数据驱动业务增长与厂商选型提供参考。 基于成熟的解决方案和扎实的落地能力，火山引擎数据产品笼罩麻利数据管道、智能数据资产目录、指标中台、数据可观测行平台等全副畛域，胜利入选全景地图。除此之外，凭借旗下大数据研发治理套件产品 DataLeap，火山引擎荣膺一站式数据开发治理平台市场的代表厂商。 随着企业数字化水平加深，数据分析赋能业务价值被高度重视，也为企业数据分析场景带来显著变动。 一方面，数据分析场景日益丰盛以及数据分析需要疾速变动带来数据利用开发需要迅速减少；另一方面，数据分析工具多元化导致数据用户角色更简单，如数据工程师、数据管理员、报表开发人员、运维工程师等。数据利用开发需要增长与数据用户角色的简单以致企业数据开发、数据运维工作量以及数据利用交付协调难度大大增加，老本越来越高。 此外，单个环节的自动化无奈解决全局问题。因而，企业须要一套全新解决方案，真正实现数据驱动业务增长。作为大数据研发治理产品， 火山引擎 DataLeap 自 2021 年 12 月私有云版上线至今，已为泛滥企业提供了数据集成、开发、运维、治理、资产、平安等数据中台解决方案，帮忙企业晋升数据研发效率，升高运维治理老本。 其中，DataLeap 为企业提供了基于字节大数据研发流程积淀的 DataOps 麻利研发流程，具备海量工作秒级调度能力和开源计算引擎的拓展能力，实现数据全链路智慧运维。具体而言：在数据集成方面，DataLeap 具备批流一体架构，反对 30 余种异构数据源的丰盛传输方式，灵便对接各类业务零碎，实现数据在简单网络下稳固、高效的互联互通和信息共享。 在数据研发方面，DataLeap 具备全链路综合治理能力，联合基线监控、数据品质、SLA 治理、老本治理等能力，提供事先预警、事中解决、预先举荐优化的全生命周期的数据治理能力。 在数据资产建设方面，DataLeap 具备数据资产疾速接入及主动构建全链路血统等技术。以上欠缺的产品能力也离不开 DataLeap 对引擎和架构的优化。为了满足业务日益增长的高并发、实效性需要，火山引擎 DataLeap 通过自研散布式调度零碎，实现了秒级调度能力。 为了实现资源正当调配，DataLeap 还提供工作分级达标机制，并反对依据工作历史状况，提出配置优化告警倡议。 最初，火山引擎 DataLeap 翻新提出分布式数据治理理念，不仅使各个模块均可独立应用分布式治理模式，让数据治理对业务的冲击和影响最小化，还能够让业余的治理常识积淀下来，实现产品化协同，并联合智能化举荐性能，为企业晋升执行效率。 据理解，火山引擎 DataLeap 曾经利用于泛互联网、制作、新批发、汽车等行业企业等畛域。以失去 APP 为例，该企业通过引入 DataLeap，开释了团队在繁多的开源组件和零碎自研上投入的研发资源和人力，同时建设了可继续的数据治理方法论，将失去整体的数据治理能力跃进了3年程度。 点击跳转 大数据研发治理套件 DataLeap 理解更多

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群你有没有关注过 APP 给你推送的音讯？ 出于晋升用户活跃度的思考，APP 会定期在利用内面向用户进行内通推送，推送模式既包含 APP Push，也包含利用内站内信、举荐展示资源位等等。 其中，APP Push 专指当用户手机处于锁屏状态下，告诉栏展现或在操作前台顶端弹出的音讯告诉。当用户点击该类音讯时，即可唤起对应的 APP，并跳转至关联界面。 依据市场剖析公司 Localytics 基于 5 亿部设施和 2.8 万个利用的调研报告显示：在开启一款 APP 音讯推送性能的用户中，约有 62% 的用户会在几个月之后再次应用这款利用。 这阐明，音讯推送在唤醒沉睡用户晋升活跃度方面确实无效；但另一方面，近年来国内 APP 音讯推送“事变”频发，如 2018 年某新闻资讯 APP 因外部操作失误，向用户推送多条不文化非正常内容，2021 年某翻新教育 APP 在几分钟内推送同一条音讯 100 屡次……导致用户对 APP 音讯推送的好感急剧下降，局部用户抉择敞开 APP 的音讯告诉性能，甚至间接卸载相干 APP。 因而，APP 在看待音讯推送的内容抉择和推送频次的把控上，须要分外留神。 音讯推送的目标在于将优质的内容推送给感兴趣的用户，所以充沛洞察用户的趣味偏好就显得尤为重要。 在践行数字化转型的当初，大多数企业都曾经实现海量市场数据的原始积累，但难以将其利用在理论业务场景中，APP 也面临着同样的问题——明明曾经积淀了维度丰盛的数据，但总是很难用起来。 火山引擎数智平台 VeDI 推出的客户数据平台 VeCDP，刚好能聚焦音讯推送场景，为 APP 带来一套数据利用新思路。 据理解，火山引擎数智平台 VeCDP 在面对用户群体形成的市场数据时，反对以“用户”为核心构建 360 度画像标签体系，并提供包含市场分层、市场洞察等在内的多种群体剖析形式。 借助火山引擎数智平台 VeCDP，APP 能够轻松找准不同用户群体的趣味偏好，并以此倒推音讯内容设计：如这部分用户对家装设计类内容趣味度更高，那么在后续的音讯推送中应该面向这一部分用户多设计家居、建材、装潢类内容，投合用户趣味偏好，满足其内容浏览需要。 此外，火山引擎数智平台 VeCDP 还能以标签模式帮忙 APP 辨认低活跃度用户、高活跃度用户，帮忙 APP 进行针对不同人群的经营策略决策。 从洞察用户趣味偏好登程，进而帮忙 APP 实现推送音讯内容策动，最终满足用户浏览需要，火山引擎数智平台 VeDI 提供的这一套 APP 数据利用链路，或者将成为晋升 APP 音讯推送关上率、进步 APP 用户活跃度的新倒退方向。 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群DataLeap是火山引擎数智平台 VeDI 旗下的大数据研发治理套件产品，帮忙用户疾速实现数据集成、开发、运维、治、资产、平安等全套数据中台建设，升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。 本文次要具体讲述 DataLeap 中的 Notebook ，包含后期选型、技术路线、架构降级、调度计划、以及将来工作等五局部重点内容，带你具体理解 Notebook。 概述Notebook 是一种反对 REPL 模式的开发环境。所谓「REPL」，即「读取-求值-输入」循环：输出一段代码，立即失去相应的后果，并持续期待下一次输出。它通常使得探索性的开发和调试更加便捷。在 Notebook 环境，你能够交互式地在其中编写你的代码、运行代码、查看输入、可视化数据并查看后果，应用起来非常灵活。 在数据开发畛域，Notebook 广泛应用于数据清理和转换、数值模仿、统计建模、数据可视化、构建和训练机器学习模型等方面。 然而显然，做数据开发，只有 Notebook 是不够的。 在火山引擎 DataLeap 数据研发平台，咱们提供了工作开发、公布调度、监控运维等一系列能力。咱们将 Notebook 作为一种工作类型，退出了数据研发平台，使用户既能领有 Notebook 交互式的开发体验，又能享受一站式大数据研发治理套件提供的便当。如果还不够直观的话，试想以下场景： 在交互式运行和可视化图表的加持下，你很快就调试实现了一份 Notebook。简略整顿了下代码，依据应用到的数据配置了上游工作依赖，上线了周期调度，并棘手挂了报警。之后，基本上就不必管这个工作了：不须要每天手动查看上游数据是否就绪；不须要每天来点击运行，因为调度零碎会主动帮你执行这个 Notebook；执行失败了有报警，能够间接上平台来解决；上游数据出错了，能够请他们发动深度回溯，对立修数。选型2019 年末，在决定要反对 Notebook 工作的时候，咱们调研了许多 Notebook 的实现，包含 Jupyter、Polynote、Zeppelin、Deepnote 等。Jupyter Notebook 是 Notebook 的传统实现，它有着极其丰富的生态以及宏大的用户群体，置信许多人都用过这个软件。 事实上，在字节跳动数据平台倒退晚期，就有了在物理机集群上对立部署的 Jupyter（基于多用户计划 JupyterHub），供外部的用户应用。思考到用户习惯和其弱小的生态，Jupyter 最终成为了咱们的抉择。 Jupyter Notebook 是一个 Web 利用。通常认为其有两个外围的概念：Notebook 和 Kernel。 Notebook 指的是代码文件，个别在文件系统中存储，后缀名为ipynb。Jupyter Notebook 后端提供了治理这些文件的能力，用户能够通过 Jupyter Notebook 的页面创立、关上、编辑、保留 Notebook。在 Notebook 中，用户以一个一个 Cell 的模式编写代码，并按 Cell 运行代码。Notebook 文件的具体内容格局，可参考 The Notebook file format。Kernel 是 Notebook 中的代码理论的运行环境，它是一个独立的过程。每一次「运行」动作，产生的成果是单个 Cell 的代码被运行。具体来讲，「运行」就是把 Cell 内的代码片段，通过 Jupyter Notebook 后端以特定格局发送给 Kernel 过程，再从 Kernel 承受特定格局的返回，并反馈到页面上。这里所说的「特定格局」，可参考 Messaging in Jupyter。在 DataLeap 数据研发平台，开发过程围绕的外围是工作。用户能够在我的项目下的工作开发目录创立子目录和工作，像 IDE 一样通过目录树治理其工作。 ...

在上篇中，咱们曾经根本理解了多云治理。当初，咱们将深入探讨多云治理要害能力实现：AppManager。 什么是AppManager？下面咱们讲了实践、咱们本人应用的交付流程和整体架构，上面咱们进入要害能力实现与解析的环节，看看咱们是如何实现上述这些能力的。 回到 AppManager 这个服务自身，它就是一个基于 OAM 的几种拆散的角色，可能实现利用治理及交付的一个服务。 它因大数据侧业务诉求而成长，重视扩大能力、网络隔离环境交付、资源管理和版本治理。 扩大能力首先来看最重要的扩大能力。不论在一开始的平台设计的时候有如许欠缺，都很难满足后续继续演进的业务需要。所以扩展性是一个 PaaS 平台的重中之重。 依靠于 OAM 的设计，咱们将所有的 Component / Addon / Trait / Policy / Workflow 等均做成了可插拔动静加载的 Groovy 脚本，并在此之上提供了插件治理及市场散发的能力。 图中的所有绿色的中央都是可依据业务须要自行扩大的，所有能力都能够在整个流程中动静引入、插拔和替换。 最下面基础设施研发的同学负责编写反对的组件类型、工作流类型、资源类型的 Groovy 脚本，并注册到 AppManager 外部。 两头的 SRE 同学负责编写 Trait、Policy 的 Groovy 脚本注册到 AppManager 外部，并负责配置环境及部署约束条件等信息。 上面的用户只须要把本人的利用代码写好，而后依照事后定义的 CI、CD、Watch 流程运行即可。 三类角色各司其职，独特高效的实现多云环境下整体利用的治理与交付过程。 图中所有绿色的中央扩大的 Groovy 脚本都是去实现事后定义的 Interface 形象接口的，任何实现了这些 Interface 的 Groovy 脚本，都能够像搭积木一样被组装和替换到各个利用的生命周期中施展本人的能力。包含构建、部署、销毁、状态监测。 在服务外部，咱们为每个脚本定义了本人的 kind (类型) / name (名称) / revision (版本) 三元组，全局惟一。对于雷同的 kind + name 组合，仅加载指定的单个版本的代码版本。通过这样的设计，实现不同用处，不同名称的脚本动静加载，且能够自在切换脚本代码版本。 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，并进入官网交换群国内数字音乐市场正在保持稳定增长。依据华经产业研究院数据报告显示，2020 年数字音乐市场规模为 357.3 亿元，到 2022 年市场规模已增长至 482.7 亿元，在数字技术的推动作用下，数字音乐市场规模还将不断扩大。 对音乐 APP 来说，市场规模的扩张带来了潜在的更好利润空间，但另一方面，在新用户开发无限的状况下，各家对“存量用户”的二次“争夺”也使得音乐市场竞争更加白热化。 目前国内支流的音乐类 APP 包含 QQ 音乐、网易云音乐、汽水音乐、酷我音乐、咪咕音乐等，为了加强本身产品劣势，APP 正在极大丰富本身性能：除了根本的搜寻听歌性能外，还推出包含识曲、直播、社区等元素，以满足用户在音乐衍生层面的需要。 其中，为音乐 APP 附加社交属性，是新性能拓展的根底之一。 音乐 APP 的社交属性，具体表现在可能让用户更好地实现 APP 所承载的内容分享，比方音乐、海报、歌词甚至短视频等。然而，当用户在 APP 内产生分享志愿，到点击分享，再到分享胜利，只管理论破费的工夫可能只需 3-6 秒钟，但探索其背地的操作逻辑，及潜在的影响成功率因素来看，却是一个长链路过程，能够分为多个不同环节。 在这个过程中，有哪些环节可能会呈现分享失败？又是什么起因导致用户分享失败？为了解决这些问题，往往须要对分享行为全链路实现数据埋点，以实现实时数据洞察。目前市场上有不少产品能够被音乐 APP 所用，火山引擎数智平台 VeDI 推出的增长剖析 DataFinder 就是其中之一。 通过在事后设计的用户分享路线中，切分出各环节外围门路，并实现对应的埋点部署，当用户分享行为进行到哪一环节时，就能实时上报相干数据，以此判断用户分享动作在该环节中是否顺畅。 如当 DataFinder 发现音乐 APP 内明天有 100 个用户点击了音乐分享按钮，其中有 80 个用户在按钮弹出的分享渠道列表中抉择了「分享渠道」并「确认分享」，但最初理论实现分享的用户数却只有 60 个——那么，就能直观地发现，该音乐 APP 明天的分享成功率只有 60%，且分享失败产生的环节有两处，即「点击分享按钮」环节和「分享渠道抉择」环节。 而在实现数据上报后，DataFinder 还反对多套数据出现模板，音乐 APP 的经营人员能够依据本身习惯和偏好抉择可视化数据展示模式，并进行系列数据分析，由数据分析得出的归因能够绝对精确地倒推出报错具体起因，并辅以产品性能迭代降级或者经营策略调整等伎俩进行优化，以晋升后续用户分享体验。 而除了帮忙音乐 APP 精准定位用户分享失败节点，火山引擎数智平台 DataFinder 还在用户拉新、行为流转、用户留存、APP 评分晋升等多个业务场景中施展着重要作用。截至 2023 年 1 月，包含凯叔讲故事 APP、地上铁 APP、买什么都省 APP、缓缓买 APP 等都已抉择与火山引擎数智平台 DataFinder 一起实现「洞察用户需要、服务满足用户」的最佳数智实际。 ...

摘要：本文整顿自阿里云资深技术专家，阿里云Hologres负责人姜伟华，在FFA实时湖仓专场的分享。点击查看>>本篇内容次要分为四个局部： 一、实时数仓分层的技术需要 二、阿里云一站式实时数仓Hologres介绍 三、Flink x Hologres：天作之合 四、基于Flink Catalog的Streaming Warehouse实际 点击查看视频回放 一、实时数仓分层的技术需要首先，咱们讲一讲数仓的分层技术以及分层技术的现状。 1、实时数仓分层技术现状大数据当初越来越考究实时化，在各种场景下都须要实时，例如春晚实时直播大屏，双11 GMV实时大屏、实时个性化举荐等场景，都对数据的实时性有着十分高的要求。为了满足业务的实时性需要，大数据技术也开始逐渐倒退出实时数仓。 但如何构建实时数仓呢？ 相比离线数仓，实时数仓没有明确的方法论体系。因而在实践中，有各种各样的办法，但没有一个办法是万能。最近行业内提出了Streaming Warehouse的概念。Streaming Warehouse的实质是分层之间可能做到实时数据的流动，从而解决实时数仓分层的问题。 上面，咱们先来理解下实时数仓的支流分层计划。 2、实时数仓支流分层计划实时数仓的支流分层计划次要有4个。 计划1：流式ETLETL（Extract- Transform-Load）是比拟传统的数据仓库建设办法，而流式ETL就是指：实时数据通过Flink实时ETL解决之后，将后果写入到KV引擎中，供给用查问。而为了解决中间层不不便排查的问题，也须要将中间层数据同步到实时数仓中供剖析之用。最常见的做法就是数据通过Flink荡涤后，写到Kafka造成ODS层。再从Kafka生产，通过加工造成DWD层。而后Flink加工成DWS层，最初通过加工造成ADS层的数据写到KV引擎并对接下层利用。因为间接应用Kafka数据进行剖析和探查很麻烦，所以也会同步一份Kafka数据到实时数仓，通过实时数仓进行剖析和探查。 这个计划的劣势是档次明确，分工明确。但劣势是须要有大量的同步工作、数据资源耗费很大、数据有很多冗余、解决链路较简单须要很多的组件。除此之外，这个计划构建的实时数仓分层，尤其是Kafka分层，复用性十分差，也没方法响应schema的动态变化。 计划2：流式ELT而流式ELT则是将计算后置，间接将明细数据写进实时数仓（EL），不须要严格的数仓分层，整个架构只须要一层，下层利用查问的时候进行数据的变换（T）或者分层。常见的做法就是把数据加工荡涤后，写到实时数仓里，造成DWD层，所有的查问都基于DWD层的明细数据进行。 这个计划的益处在于，没有ETL，只有一层；数据订正很不便。但它的弊病有两个方面： 在查问性能方面，因为是明细数据查问，所以在某些场景下不能满足QPS或提早的要求。因为没有严格的数仓分层，所以数据复用很艰难，很难兼顾各方面的诉求。 计划3：定时调度既然实时流式无奈实现数据的实时数仓分层，咱们能够将数据实时写入实时数仓的DWD层。DWS层、ADS层用离线的高频调度办法，实现分钟级的调度，从而借用离线数仓，进行分层结构。这个也就是业界罕用的计划3。 这个计划的益处在于能够复用很多离线教训，计划成本低且成熟。但计划也存在如下毛病： 提早大：每一层的提早都跟调度相干，随着档次越多，调度提早越大，实时数仓也变成了准实时数仓。不能齐全复用离线计划：离线调度个别是小时级或天级，咱们能够应用全量计算。但在分钟级调度时，必须做增量计算，否则无奈及时调度。 计划4：实时物化视图第4种计划就是通过实时数仓的物化视图能力实现数仓分层。常见的做法就是Flink实时加工后，将数据写到实时数仓造成DWD层，DWS层或ADS层的结构依赖于实时数仓的实时物化视图能力。 当初支流实时数仓都开始提供物化视图的能力，但实质上都是提供了一些简略的聚合类物化视图。如果物化视图的需要比较简单，能够利用实时数仓里的实时物化视图能力，将DWS层到ADS层的构建自动化，从而让物化视图的查问保障较高的QPS。但这个计划最大的毛病在于，当初的实时物化视图技术都还不成熟，能力无限，反对的场景也比拟无限。 二、阿里云一站式实时数仓Hologres介绍接下来，先介绍一下阿里云一站式实时数仓Hologres产品。Hologres是阿里云自研的一站式实时数仓，它同时蕴含三种能力： OLAP能力：同传统的实时数仓一样，能够反对数据的实时写入、以及简单OLAP实时多维分析疾速响应，满足业务的极致数据摸索能力。在线服务Serving(KV)：能够反对KV查问场景，提供十分高的QPS和毫秒级的低提早。湖仓一体：可能间接查问数据湖的数据，以及可能减速阿里云离线数仓MaxCompute，助力业务更低成本实现湖仓一体。 上面为具体介绍： 首先，大家能够把Hologres当做一个常见的实时数仓。它的特点在于写入侧反对百万RPS的实时写入，写入即可查，没有提早。同时也反对高性能的实时整行更新和部分更新。其中，整行更新是把整行替换掉，部分更新能够更新一行中的部分字段，二者都是实时更新。在查问侧，一方面反对简单的OLAP多维分析，能够十分好的反对实时大屏、实时报表等场景。近期Hologres拿到了TPC-H 30TB的性能世界第一的TPC官网认证问题，见>>阿里云 ODPS-Hologres刷新世界纪录，当先第二名23%。其次，Hologres也反对在线服务查问，不仅反对百万QPS KV点查，而且也反对阿里云达摩院的Proxima向量检索引擎，能够反对十分高效的向量检索能力。同时这些能力在Hologres中是全用SQL表白，对用户应用十分敌对。此外，为了兼顾数据服务和实时数仓的需要，Hologres在行存、列存的数据格式根底上，也反对行列共存，即行列共存的表即一份行存，又有一份列存，并且零碎保障这两份数据是强统一的，对于OLAP剖析，优化器会主动抉择列存，对于线上服务，会主动抉择行存，通过行列共存能够十分敌对的实现一份数据撑持多个利用场景。因为Hologres同时反对OLAP剖析和线上服务，其中线上服务要求十分高的稳定性和SLA。为了保障OLAP剖析和线上服务时不会发生冲突，咱们反对了读写拆散，从而实现OLAP与数据服务的强隔离。最初，在湖仓数据交互式剖析方面，Hologres对阿里云MaxCompute离线数仓里的数据，数据湖中的数据都能够秒级交互式剖析，且不须要做任何的数据搬迁。除此之外，Hologres的定位是一站式的企业级实时数仓，所以除了上述能力，咱们还有很多其余能力。包含数据的治理、老本治理、数据血统、数据脱敏、数据加密、IP白名单、数据的备份和复原等等。 三、Flink x Hologres：天作之合1、Hologres与Flink深度集成Flink对于实时数仓可能提供十分丰盛的数据处理、数据入湖仓的能力。Hologres与Flink有些十分深度的整合能力，具体包含： Hologres能够作为Flink的维表：在实时计算的场景下，Flink对维表的需要很强，Hologres反对百万级至千万级RPS的KV点查能力，能够间接当做Flink维表应用，且能够做到实时更新，对于像实时特色存储等维表关联场景就也能够十分高效的反对。Hologres能够作为Flink的后果表：Hologres反对高性能的实时写入和整行实时更新的能力，能够联合Flink，输入须要弱小的Update能力，满足数仓场景下的实时更新、笼罩等需要。与此同时，Hologres还有很强的部分更新能力。部分更新能力在很多场景下，能够代替Flink的多流Join，为客户节省成本。Hologres能够作为Flink的源表：Hologres反对Binlog能力，一张表的任何变动，比方insert、update、delete等等，都会产生Binlog事件。Flink能够订阅Hologres Binlog，进行驱动计算。因为Flink反对Hologres的整表读取，二者联合形成了Flink全增量一体化的读取能力。并且，Hologres也对了接Flink CDC，它能够驱动Flink CDC的计算。反对Hologres Catalog：通过Hologres Catalog的任何操作，都会间接实时反映到Hologres里，用户也不须要在Flink建Hologres表，这样就使得Flink+Hologres就具备了整库同步、Schema Evolution的能力。 2、基于Flink+Hologres的Streaming Warehouse计划那Flink和Hologres如何构建Streaming Warehouse？ Streaming Warehouse：数据能在数仓之间实时的流动，实质上就是解决实时数仓分层的问题 最开始咱们介绍了常见的数仓分层计划，Flink+Hologres的Streaming Warehouse计划则是能够齐全将Flink+Kafka替换。具体做法如下： 将Flink写到Hologres里，造成ODS层。Flink订阅ODS层的Hologres Binlog进行加工，将Flink从DWD层再次写入Hologres里。Flink再订阅DWD层的Hologres Binlog，通过计算造成DWS层，将其再次写入Hologres里。最初，由Hologres对外提供利用查问。该计划相比Kafka有如下长处： 解决了传统中间层Kafka数据不易查、不易更新、不易修改的问题。Hologres的每一层都可查、可更新、可修改。Hologres的每一层都能够独自对外提供服务。因为每一层的数据都是可查的，所以数据的复用会更好，真正实现数仓分层复用的指标。Hologres反对数据复用，模型对立，架构简化。通过Flink+Hologres，就能实现实时数仓分层，简化架构和降低成本。 3、Flink+Hologres外围能力：Binlog、行列共存、资源隔离下面讲的Flink+Hologres的Streaming Warehouse计划，其强依赖于以下三个Hologres外围能力： Binlog：因为实时数仓个别没有Binlog，但Hologres提供了Binlog能力，用来驱动Flink做实时计算，正因为有了Binlog，Hologres能力作为流式计算的上游。行列共存。一张表既有行存数据，又有列存数据。这两份数据是强统一的。行列共存的个性让中间层的每张表，岂但可能给Flink应用，而且能够给其余利用（比方OLAP、或者线上服务）应用。资源强隔离。实时数仓个别是弱隔离或软隔离，通过资源组、资源队列的办法实现资源隔离。如果Flink的资源耗费很大，可能影响中间层的点查性能。但在Hologres强隔离的能力下，Flink对Hologres Binlog的数据拉取，不会影响线上服务。通过Binlog、行列共存、资源强隔离的三个特点，不仅能让Flink+Hologres造成Streaming Warehouse，并且可能使两头的每层数据复用，被其余利用或线上服务应用，助力企业构建最简略最残缺的实时数仓。 ...

导读 本文整顿自 2022 年 12 月的 DataFun 加强剖析论坛上的同名主题分享。 AI 正在让 BI 变得更智能，让业务不仅冲破了传统 BI 只能针对历史业务进行剖析的限度，还可能对将来业务的倒退产生指引。Sugar BI 推出的 DI（智能预测） 性能，使得业务人员能够利用历史数据对将来趋势变动进行预测，做到世事变动皆在方寸把握。 明天的分享会围绕上面三点开展： 介绍 BI 的倒退历程，详解各个阶段 BI 的变动；讲述智能 BI 时代的发展趋势，Sugar BI 在智能 BI 上的能力，附带介绍各类预测剖析平台的不同；分享 Sugar BI 的智能预测 DI 模块及其利用场景，并演示其 Demo，帮忙观众可能很好地将这个能力利用在业务中。 全文5237字，预计浏览工夫14分钟。 一、BI的倒退历程1.1 BI历史1865 年，银行家亨利在一本书中第一次应用到了“商业智能”一词，讲述了如何通过收集和剖析信息，当先于竞争对手采取商业口头从而去获利的过程，其中重点在于收集和剖析信息，而外围就是数据的剖析和收集。 1958 年，IBM 计算机科学家汉斯，也就是起初公认的“商业智能之父”，在 business intelligence system 中形容了 BI 的价值和潜能。 1989 年 Gartner 的一位分析师正式将商业智能作为涵盖数据存储和剖析的统称。 在 20 世纪 90 年代当前，BI 时代特点逐渐展示，到目前大略能够分为 BI 1.0 、BI 2.0 和 BI 2.5 三个阶段。 ...

新晋“网红”ChatGPT爆火网络，大家都很好奇ChatGPT到底是什么？各种解读/钻研的文章铺天盖地，但让小编更好奇的是：它眼中的Alluxio是怎么的？带着这份探知欲，咱们聊了聊！ 内容准确度与时效性咱们暂且不深究，但其对内容的收集、总结、提炼能力令人叹服！更要害的是，小嘴儿也很甜！想要理解更多对于Alluxio的干货文章、热门流动、专家分享，可点击进入【Alluxio智库】：

摘要：本文整顿自阿里云高级产品专家何源(荆杭)在 阿里云EMR2.0线上发布会 的分享。本篇内容次要分为三个局部： 开源大数据的痛点及EMR产品历程EMR2.0 新特色总结一、开源大数据的痛点及EMR产品历程开源大数据的痛点如何晋升性能，升高资源老本全面的性能优化须要大量的研发投入且门槛较高；大数据资源使用量大，宽广用户都在一直摸索降本计划。 如何升高运维老本开源大数据组件泛滥，开发上手绝对容易，然而一旦业务规模和业务复杂度回升当前，所带来的运维难度和开销也随之急剧回升。 如何保障数据和工作的可靠性数据是公司的无形资产，数据的失落往往是灾难性的，只管有多正本，然而动辄几十台，甚至上百台、上千台的服务器在机器故障、集群降级、迁徙过程中要保障数据的可靠性是一件不容易的事，而成千上万的工作实时或周期性的运行，也会耗费大量的运维投入。 如何治理数据开发和治理实现团队协同开发、平安合规的应用数据以及治理数据，也须要有方法论的撑持和产品反对。 EMR产品历程如下图所示，自2016年阿里云推出EMR以来，阿里云EMR团队始终致力于解决以上痛点。 通过一系列的性能优化，阿里云在 CloudSort 和 TPC-DS 上获得了世界第一的问题，推出了全托管的元数据和数据湖产品，大大降低了运维难度和运维老本。 通过 DataWorks on EMR 以及 EMR Studio 等产品，大大简化了数据开发以及数据治理的接入门槛。 二、EMR2.0 新特色概述基于云原生的理念和阿里云上日益成熟的设施，阿里云推出 EMR 2.0，构建新一代开源大数据的基础设施。 EMR 2.0的新特色包含： 全新平台体验 集群创立速度2倍以上优化；集群扩容速度3倍以上晋升；弹性规模反对千台以上；故障节点迁徙；集群诊断工具；全新数据开发 全托管EMR Notebook (Jupyter)；Workflow (Dolphinscheduler)；数据开发治理平台Dataworks on EMR；全新资源状态 EMR on ECS，反对倚天g8，性价比晋升超过40%；EMR on ACK(K8s)；EMR Serverless；全新剖析场景 新版数据湖数据分析数据服务实时数据流数据迷信EMR 2.0产品架构如下图所示，EMR 2.0产品架构自下而上包含： 硬件资源 EMR 2.0反对ECS（Intel, AMD, 倚天）/神龙/ECI； 存储资源 在存储资源上，数据湖架构曾经曾经逐渐成为业界的共识，阿里云在对象存储OSS 技术上降级为 OSS-HDFS 兼容 HDFS API； 调度资源 反对 EMR on ECS、EMR on ACK、EMR Serverless 管控平台 监控告警；弹性调度；集群诊断；故障弥补；权限&平安；组件治理；剖析场景 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群日前，在 WOT 寰球翻新技术大会上，火山引擎 DataTester 技术负责人韩云飞做了对于字节跳动 A/B 测试平台的分享。 DataTester 是字节跳动外部利用多年的 A/B 试验平台，平台自建设至今，承载了字节 500 余个业务线的 A/B 试验工作，累计已发展过 150 万次试验，当初字节跳动每天会新增试验 2000 余个，同时在 DataTester 上运行的试验有 3 万余个。 字节跳动外部有着十分浓重的数据文化和试验文化，抖音、今日头条的名字都经由 A/B 测试确定，而 A/B 测试也是整个研发链路上的必经一环。本文将以字节研发流程中的两个个案例，介绍 A/B 测试在研发全流程中的角色。 1.产品零碎重构今日头条是一款信息类互联网产品，它会基于数据挖掘的举荐引擎向用户举荐文章。今日头条晚期的信息流服务是应用 Python 的一项单体服务，但随着字节业务倒退的迅速，今日头条的流量也迎来了爆发式增长，产品在性能工程上的复杂度也在急剧升高。 为了优化产品，使之更加适应大流量下的响应，今日头条的信息流业务设计了一次大规模服务化重构：语言选型从 Python 切换到了 Golang，从单体服务架构演变成了分层的微服务架构。 但这个重构设计，是围绕产品性能方面的技术指标开展的，但对于用户体验的影响和业务指标的影响，却无奈通过短期察看失去论断。 为了防止简单的新零碎上线后，升高头条用户的产品应用体验，因而在重构方案设计结束后，今日头条业务破费了 6 个月以上的工夫，发展了新计划和旧计划比照的 A/B 测试，总共进行过几十次 A/B 试验，多点开启灰度测试，并一直剖析后果、迭代计划，确认改良点对业务数据指标的影响。 在半年多之后，这个简单的新零碎终于完结了 A/B 测试，并推全上线。上线后的新系统对今日头条大部分全局指标简直无影响，甚至一些要害指标获得了显示正向的后果。 2.产品 Bug 修复这个案例是字节直播产品的场景。该产品在设计了新的精排模型，本来冀望是想召回模型学习到更多信息，提前做一些召回合乎用户趣味的内容，晋升局部产品要害指标。但在实际操作中，因为模型配置呈现了 Bug，上线失败。 因而，该直播产品的团队针对这个 Bug 进行了修复，但只能采纳使精排模型变得更简单的计划。新的性能尽管曾经胜利跑通，但因为模型更加简单，对于用户产品体验负向影响的危险会随之升高。 为了验证新开发的性能对用户体验的影响，该团队应用 DataTester 开启了 A/B 测试，他们将用户分为新用户组、老用户组别离开启试验，通过数据察看发现，新的性能对于新用户的而言没有什么实质性影响，新用户的应用时长、留存等指标仍然是在一个特定区间稳定；但在老用户组的试验数据中，他们发现老用户在内容人均浏览时长上，有了 0.3%的显著进步。 尽管 0.3%是一个看起来不大的数字，但对于字节产品的用户体量而言，这种幅度的晋升，在用户内容生产时长上的本质晋升很大。上述两个案例是 DataTester 在字节跳动利用的缩影，实际上，在字节整个的研发流程中，开发、上线、BugFix、优化、重构，A/B 测试都会作为基础设施中的一环，来服务于整个研发流程。 除此之外，A/B 试验也广泛应用于字节跳动业务的方方面面，从产品命名到交互设计，从扭转字体、弹窗成果、界面大小，到举荐算法、广告优化、用户增长...... 能够说，DataTester 曾经融入在字节的每一个业务和每一项决策中。 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，并进入官网交换群春节期间累计接待游客 200.42 万人次，同比 2022 年增长 102.47%，同比 2019 年增长 19.27%，总收入同比 2022 年增长 206.71%。 刚完结的春节假期，文旅市场呈现出强劲的复苏态势。 文化和旅游部数据显示，春节假期国内游览出游 3.08 亿人次，同比增长 23.1%；实现国内游览支出 3758.43 亿元，同比增长 30%，复原至 2019 年同期的 73.1%。 其中，充沛交融地区与文化特色，将传统文化与现代科技、艺术翻新相结合的陕西省各景点，因为兼顾「年味」和「趣味」，老少皆宜，而成为不少省内外家庭出游的首选。 在延安，“陕北过大年 就来金延安”新春系列流动春节假期期间吸引入园游客达 26 万人次，较 2022 年同期增长 179.57%，创开园以来历史新高。 图片起源：公开媒体报道 华山突出“兔”年主题元素，假期期间日均接待游客超过万人。华山西峰索道累计接待游客 8 万余人次；少华山共接待游客 5.6 万余人，与 2019 年同期相比接待人次增长 302.6%；如意峰索道累计接待游客超过 6 万人，创春节假期游客接待最高记录，特地是大年初三单日客流量冲破 1.5 万人，创单日游客接待人数和支出历史新高。 此外，华清宫还推出年味十足的唐宫流动，搭配唯美震撼的冰火《长恨歌》，吸引入园游客逾 21.5 万人次，冰火《长恨歌》《12·12》《西安事变》上演接待观众近 7 万人次。；白鹿原影视城适逢第七届关中民俗文化节，人气火爆，入园游客达 33.25 万人次，较 2022 年同期增长 337%，支出增长 134%，客流量创开园以来历史新高…… 据统计，陕西游览团体旗下包含金延安、华山、华清宫、白鹿原影视城等在内的众景区，春节期间累计接待游客 200.42 万人次，同比 2022 年增长 102.47%，同比 2019 年增长 19.27%，总收入同比 2022 年增长 206.71%。 陕西游览团体的火爆并非仅踩准「春节」工夫点欲速不达，而是在后期长年累月地洞察用户需要并辅以多项服务保障，能力实现客流集中暴发，并将在春节完结后的长线日常经营中，继续受到游客关注和返回。 2022 年 4 月 2 日，陕西游览团体正式上线“陕旅嗨 GO”直播间，通过“内容+互动+电商”的线上模式，在抖音平台向公众展现、解说旗下各大景点特色，并同步举荐文旅周边产品，构建全新“以播带景带货的沉迷式直播”生产场景。 ...

内容简介：随着数字化一直倒退，各行各业数据出现海量增长的趋势。存算拆散将存储系统和计算框架拆分为独立的模块，Alluxio作为现在支流云数据编排软件之一，为计算型利用（如 Apache Spark、Presto）和存储系统（如 Amazon S3、Alibaba OSS）的数据拜访构建了桥梁。 本文应用亚马逊云、阿里云服务商产品，对Presto、Hive等计算框架与不同UFS直连时的要害性能指标进行测评，同时给出集成Alluxio组件后的性能评估，得出以下论断： √ Alluxio 可缩小工作运行工夫（低带宽状况下甚至能够缩小一个数量级）和 CPU工夫；这表明 Alluxio 肯定水平上能够节俭带宽并加重服务器运算压力。 √ Alluxio 可更好地兼容泛滥底层存储系统，这表明在不损失性能的前提下，抉择价格更为低廉的对象存储系统（如Alibaba OSS, Amazon S3）。 简而言之，集成数据驱动软件 Alluxio 既能晋升性能，又能升高经营老本。 实验设计本试验采纳 TPC-DS 生成的 1GB 数据集，抉择19条SQL作为该试验工作负载。[1] 咱们将原始数据存到底层存储系统中，应用Hive治理原始数据和元数据，将Presto作为计算利用，造成 Presto → Hive → (Alluxio →) HDFS/OSS/S3 的连贯模式，并进行Presto间接读UFS和Presto通过Alluxio缓存读UFS两种比照测试。咱们采纳挂钟工夫（WallTime，执行查问破费的总工夫）和CPU工夫（ProcessCpuTime，解决查问所破费的总CPU工夫）两组测量指标进行比照测试。 试验后果与意义试验后果剖析通过TPC-DS测试的比照后，可得出以下几点论断：（1）Alluxio 可缩小挂钟工夫，在低带宽下尤为显著。 √ 下图是在AWS上，应用HDFS作为存储系统，统计挂钟工夫均值（AWS实例带宽最高可达10G/s，性能小幅度晋升）： √下图是在阿里云上，应用HDFS作为存储系统，统计挂钟工夫均值（抉择阿里云按量付费最高带宽200M/s）： √下图是在阿里云上，应用HDFS作为存储系统，统计挂钟工夫均值（低带宽模式，带宽15M/s），能够看到性能晋升一个数量级。 （2）Alluxio 可节俭带宽。由上图可知，若想在无Alluxio的状况下达到有Alluxio的成果，须要设法进一步晋升公网带宽。 （3）Alluxio 肯定水平上可减轻服务器运算压力，CPU工夫较短。图2-1是在阿里云上应用HDFS作为存储系统，统计CPU工夫。 下图是在AWS上应用S3作为存储系统，统计CPU工夫。 （4）Alluxio 为计算框架和存储系统的数据拜访搭建桥梁，大大降低运行环境配置难度。目前 Presto 对 S3 兼容性较好，但对 OSS 和 COS 兼容性较差，目前尚无Presto间接拜访OSS数据的计划。但用Alluxio则无需思考计算框架和底层存储系统的兼容性问题，因为Presto对Alluxio、Alluxio对OSS兼容性很好，配置环境很容易。 （5）因为无需思考计算框架与底层存储系统兼容性，则可应用价格更为低廉的对象存储系统，其带宽老本与保护老本均比 Hadoop 低。并且由图3-1和图3-2得悉Alluxio缓存读状况下性能差异并不显著，但对象存储系统价格更为低廉，因而对象存储可作为存储系统更好的抉择。 下图为应用AWS服务器，别离对 HDFS 和 S3 进行测试，统计挂钟工夫。 ...

本文搭配同主题分享视频浏览更佳，《多数据源的数据治理实际》如果你装好某款数据库产品，比方：分布式图数据库 NebulaGrpah，蠢蠢欲动的第一步是不是就让它干活搞数据呢？好的，当初问题来了，如何把绝对原始的数据处理、建模并导入 NebulaGraph 呢？本文是一个端到端的示例演示，从多数据源聚合数据，清理、利用 dbt 转换成 NebulaGraph 建模的属性图点边记录，最初导入成图谱的全流程。 构建常识图谱当初假如你是一个相似于 Netflix、爱奇艺之类的视频服务提供商，咱们须要利用图数据库搭建一个 用户-电影 的常识图谱，来辅助、撑持视频举荐、问答和举荐理由等常见由图谱撑持的场景。因为工夫的关系，这里先用咱们相熟的老朋友——图数据库 NebulaGraph 来搞定常识图谱。 一般来说，常识图谱须要的数据会有不同的数据起源，比方一些公开的 API、数仓中的不同数据库、动态文件。这时候，咱们如果要构建常识图谱，须要以下 3 个步骤： 剖析可能获取的数据；选取关怀的关联关系，图建模；抽取关联关系，导入图数据库。数据源这里咱们会用到两个数据源 OMDB 和 MovieLens。 OMDB 是一个凋谢的电影数据库，将用来模仿公司外部的业务数据。咱们能够取得的信息有： 电影电影的分类电影中的工作人员，包含：导演、动作领导、演员、后期制作等人员信息电影封面、宣传片等电影信息MovieLens 是一个凋谢的数据集，用来模仿公司外部的用户数据。咱们能够取得的信息有： 用户电影用户对电影的评分交互图建模在之前的文章《基于图数据库的举荐零碎》 里咱们介绍了举荐零碎的图数据库根本用法。在那篇文章中，内容过滤偏重关注 用户-->电影、电影-->分类、电影-->演员、电影-->导演 等关系，协同过滤则关注 用户-->电影 的关系，以及举荐理由服务关注以上所有的关系。 总结起来，咱们须要的边有： watched(rate(double))with_genredirected_byacted_by联合已有信息，绝对应地将顶点中可能须要被关注的信息作为属性，给出点 tag 的初始布局： user(user_id)movie(name)person(name, birthdate)genre(name) 表数据到常识图谱的映射有了指标的图谱构造定义，咱们来看看手上的数据如何映射到它。 OMDB 数据首先是 OMDB 数据，它由很多表组成，比方 all_movies 这张表，存储了所有的电影、以及它们在不同语言下的名字： movie_idnamelanguage_iso_639_1official_translation1Cowboy Bebopde11Cowboy Bebopen12Ariel - Abgebrannt in Helsinkide03Shadows in Paradiseen03Im Schatten des Paradiesesde03Schatten im Paradiesde1而 all_casts 表格中保有所有电影相干的工作人员： movie_idperson_idjob_idroleposition11121 111113 111215Luke Skywalker111315Han Solo311415Leia Organa2然而这里的每一个人的姓名等信息、以及他/她在电影中任职的职位，则别离在表 job_names 和 all_people 中： ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，并进入官网交换群DataLeap是火山引擎数智平台VeDI旗下的大数据研发治理套件产品，帮忙用户疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设，升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。 本篇文章次要围绕火山引擎DataLeap一站式数据治理实际开展分享，从数据治理思路、平台建设以及能力降级三个步骤登程，带你全面复制字节跳动数据治理教训。 ▌时机与挑战 数据治理存在落地艰难的问题，体现在：首先，治理效益与业务影响存在矛盾。数据治理须要对业务零碎、生产流程革新，由此对业务造成影响。 第二，治理波及的组织和治理难度大。数据治理波及的角色多、范围广、链路长，且治理指标对齐、治理和跟进难度大。 第三，标准“人”的动作难度大。数据治理要依附人来推动和执行，人员能力参差不齐，组织文化、指标也存在不对齐的状况。 第四，不足适配性强、全局视角且灵便的数据治理工具。 上面联合字节的特点，介绍数据治理工作的时机和挑战。 字节文化首先，字节业务多、倒退快、麻利迭代，要求能疾速响应业务需要；第二，OKR文化使得每个人都能够参加制订数据治理布局和策略，并且被动寻找实现门路；第三，为谋求高效治理，没有设立对立的数据治理委员会，而是由各部门依据各自的业务状况进行治理。业务第一字节业务规模大，且强调数据驱动，导致数据品质对业务的影响十分大。综上所述，数据治理在字节是挑战时机与并存的工作。▌3个关键步骤，复制字节跳动数据治理教训步骤一：翻新数据治理思路——分布式数据自治什么是分布式自治？ 针对上述问题，综合思考治理收益、业务影响、执行效率，火山引擎DataLeap提出了分布式数据自治的思路。首先，在业务影响方面，为保障影响小，治理工作依照业务单元进行。一个业务单元可能是一个小团队或者小我的项目。 第二，积淀各业务线治理教训，晋升治理效率。 通过产品辅助业务自驱，实现规则化、策略化、自动化治理。通过低门槛、算法举荐等平台能力，升高治理门槛。反对灵便的治理形式，如管理者视角，自上而下布局性治理；如一线执行者视角，自下而上推动治理。第三，适配性强，产品建设笼罩治理全链路。 产品能力笼罩稳定性、品质、平安、老本、报警等多场景。各模块能够独立应用、按需组合。产品提供残缺的开发能力，反对业务依据本身特点和倒退阶段自行接入。与集中式治理的区别 与传统集中式治理相比，分布式治理有很多劣势。 集中式治理：要求制订制度，并进行大范畴组织推广；要求划分权责，定期抽查考核；建设周期长，适配能力弱，且组织投入多。分布式自治：业务影响小；周期短，见效快；效率高，节俭人力；便于算清业务收益，降低成本。步骤二：构建一站式平台，引入数据治理双门路一站式数据治理平台架构 DataLeap一站式数据解决方案，次要划分为三层。 第一层 视图层从资产视角、管理者视角 、实施者视角纵览数据治理的状况。第二层 计划层针对治理过程，提出了双门路。门路一【被动布局】布局式流程次要解决的问题是确定指标后，如何推动执行的问题。被动布局门路还反对治理指标拆解成治理规定进行诊断，并依据诊断后果，执行治理。最初，通过收益统计、改良打算等进行总结复盘。门路二【零碎发现】响应式流程先由零碎发现问题，再通过告警等模式告诉资产责任人，并进行解决。最初通过根因剖析等实现总结。第三层 工具层工具层次要为视图层、计划层提供齐备的治理工具，笼罩品质、平安、老本、稳定性、报警与起夜等场景。工具层还通过买通根底服务，赋能被动布局和零碎发现两条治理门路。实用于业务驱动的布局式流程接下来为大家介绍布局式门路的具体建设过程。 特点：资产清晰，规定丰盛，动线残缺，收益精确。思路： 制订指标，包含衰弱分指标，以及升高存储、计算资源等。依据指标制订治理计划，明确治理域、圈选治理规定。制定方案后，由零碎主动查问存储、计算等问题的明细，通过剖析后，通过音讯催办等形式，将问题下发到责任人，推动数据治理。零碎主动对治理成果进行采集，反馈指标达成状况，并对一段时间内的治理后果进行验收和统计。以上是布局式流程的主线思路 。上面介绍如何实现布局式门路的次要实现伎俩。 资产清晰 DataLeap次要从治理全景和衰弱分两个方面对资产进行形容。第一，治理全景。从各个维度，通过明细、统计量，对团队或集体资产的具体情况进行形容。如各个表占了多少存储空间，计算资源应用状况，工作报警率、起夜率，数据及时性和品质等。第二，衰弱分。次要依据治理的垂直方向划分为存储衰弱分、计算衰弱分、品质衰弱分三个层级。在第一层的维度下，第二层细化问题大类，如存储方面，包含：有效存储、异样存储等；品质方面，包含：及时性、报警、元信息配置标准等。第三层则将具体问题通过标签定义，如有效存储波及TTL不合理、热度方面信息(xx天无查问)等。综上，次要通过衰弱度和治理全景将资产清晰地表述进去，再通过元数据仓库进行底层数据建设。 规定丰盛 目前平台具备了齐备的治理规定，涵盖存储、计算、品质、报警4大维度，50多个规定。 其中包含全局规定，如：生命周期永恒、近7天产出为空、暴力扫描工作等；也包含一些自定义的规定，如生命周期xxxt天，近xxx天产出为空等。同时还兼具开掘类规定，包含基于统计信息进行聚合后造成的规定，以及基于资产（包含库、表等）相似性发现问题的规定。 DataLeap治理规定次要通过以下流程建设起来。 首先，通过底层与平台根底组件买通，实现数据收集，造成数据仓库的根底层；其次，基于根底层对数据资产进行画像形容，进一步造成特色域，做特色开掘和关联剖析；再将利用数据放到数据服务中，对外提供灵便的数据查问能力。最初，通过最上层的规定引擎，将数据和规定进行联动，利用于规定建设。动线残缺 明确出问题的资产后，如何尽快实现治理，缩小和业务的抵触，对于提高效率至关重要。 基于治理平台的能力，联合各个垂直场景，DataLeap建设欠缺的治理动线。大抵的思路如下： 工作治理方面，与工作开发、工作运维平台买通，反对工作敞开、调整、调参，链路优化等；库表标准方面，和元数据平台联动，实现表治理、库治理、资产移交、属性批改等；生命周期方面，通过治理平台将底层存储（包含hdfs、hive等组件）买通，造成闭环式治理；在数据品质方面，波及sla及时性，离线、实时数据监控等，通过与品质规定平台强联动，相互注销数据，进行sla签订以及强跳转交互等。残缺的动线能使用户在平台中，以低操作老本实现一站式闭环治理。 收益精确实现治理后，如何判断治理收益？ 目前DataLeap建设了基于事件核心的底层框架。通过定义数据的生产模型，由音讯通道来定时收集各个平台操作的音讯；同时，通过定义事件SDK,兼容API的形式，来灵便对接上游不同平台。 通过音讯订阅和生产的形式，数据治理平台和研发平台、元数据平台、品质平台等实现对接，将治理事件接入事件核心，并将事件核心的离线数据dump到数据仓库，进行离线加工，同时咱们也会将最新事件，注入在线元数据服务中，及时实现治理收益计算。 技术架构 在技术架构层面，遵循以下准则：对立数据查问、规定灵便组合、操作解耦、治理收益精确。 平台后端负责散发和转换治理逻辑，包含查数、设置指标、衰弱分展现与透出，治理操作等；依据获取的音讯后，后端平台进行具体事件拆分。举个例子，在看板类查数的局部，需要将对立发送到查问服务实现底层存储做适配，通过点查、list、聚合类查问，并在解析后选取不同的底层存储。规定引擎服务可与数据查问服务联动。通过数据查问服务获取数据，再通过规定定义成标签，并形象成服务。该服务能够对外提供对资产标签形容，并成为通用能力。数据治理具体实施被对立形象成后盾模块，包含设置音讯、设置ddl、进行删除等。由该模块下发到组件层进行操作，再通过事件收集服务，并返回数据查问服务，实现治理收益汇总。实用于教训积淀的响应式流程特点：预先治理、问题总结、教训积淀。 思路：首先，接到报警和音讯，包含sla破线、数据品质报警、计算工作报警等；其次，零碎将上述音讯汇总，并展现在治理平台中。数据开发人员通过治理平台进行音讯检索、问题归因，并实现根因打标，把问题具体定位到组件、平台等颗粒度；再次，通过公司组织形式找到组件侧对接人，或通过组织会议将问题提交给相干责任方，推动对方实现保障；最初，列出零碎中的问题形容、改良打算，定义问题并剖析治理成果，并在问题解决后，推动计划分享、积淀和复用。响应式治理架构与布局式治理大部分相似，最大区别在于音讯服务局部。作为根底能力，音讯服务将大数据平台相干产品中的音讯，接入对立服务中，成为所有报警音讯入口。并且音讯服务还能够做降级策略，如音讯聚合、音讯加急等。 **步骤三：凋谢接入、智能化数据治理能力降级凋谢接入 业务有各自倒退阶段以及不同治理指标。例如，新兴业务外围关注sla的能力；而成熟业务，则更器重规范性。如何防止一刀切，让不同业务需要都能通过同一个治理平台满足？凋谢能力很重要。也就是说，要构建数据治理生态，让业务能够自定义接入治理规定，并施行治理。 以后阶段，咱们将数据治理分为四个象限，横坐标为元数据（三方元数据、规范元数据），纵坐标为规定（表达式、算法包）。 第一象限&第二象限：第一象限次要为定义规范元数据和对立表达式，通过规定引擎间接适配。如果业务方存在第三方元数据接入已定义规定，则如第二象限所示，接入的第三方元数据须要遵循接入规范，并通过规定引擎实现适配。第三象限&第四象限：如果规定局部要进行类似度计算，且不是表达式能够形容的规定，则被定义为算法包或逻辑单元。如第三象限&第四象限所示，要求定义输出、输入规范，通过调用包或插件形式，执行逻辑。整体而言，将平台能力凋谢，让业务接入本身的规定和数据，根底是治理平台有欠缺的元数据格式和接入规范。 业务方只需负责加工本身接入局部，实现配置和数据映射，通过表达式或算法包计算后，实现对立输入。目前，上图的凋谢接入能力正在开发当中，将来将对外提供服务。 智能化能力接下来介绍智能化能力，该能力能够进一步升高治理老本，进步治理效率。代表性落地场景如下： 工作SLA签订举荐 问题：在SLA签订中，工作上下游可能存在上千个节点，如何预计产出工夫？解决思路：目前次要通过血缘关系找到节点的要害门路，基于运行工夫进行权重调配，确保节点有绝对正当的SLA buffer。在举荐签订环节，DataLeap目前曾经申请专利，并在生产中产生肯定成果。第二期将基于运行失败概率分布状况来调整上游buffer压缩，上游buffer宽松的问题。动静阈值监控 问题：数据量失常散布，但短期异样化的状况。如流量日志在假期或流动日，呈现失常突增或突降的状况。解决思路：惯例的数据品质监控通常限定绝对值阈值，如历史7天稳定率等，容易造成假期或流动日误报警，给值班人员造成不必要的打搅。DataLeap提出了动静阈值的思路：基于数据历史状况，演绎出不同散布状况，并提供不同的预测办法。例如，动静阈值预测整个表在某一天的量级状况，而后基于数据量级设置高低阈值，超出阈值再进行报警或音讯告诉。数据分布：数据量枯燥不减，大部分为快照表或全量表；假期或流动日可能呈现数据量突增或突降，往往为日志类表时；数据量比较稳定，维度发生变化时，能反馈出肯定问题，往往是维度表。预测办法：挪动平均法、指数平滑法、自回归法、同期检测法。 有类似工作辨认问题：因为业务宏大、开发人员多、任务量大，在开发过程中，存在不晓得线上是否存在相似工作的问题，在跨团队状况下更显著，因而工作检测十分必要。 解决思路：DataLeap的基本思路是将指标源代码和待检测源代码sql的ast序列化和向量化，对特征向量做余弦类似度计算，通过产品进行计算结果透出，再由业务实现标注，通过人工确认剖析，对工作进行合并或下线。 以上是DataLeap在智能化方面的一些摸索。 架构总结与将来瞻望架构总结最初总结一下，平台总体架构分为三层。 产品层，从管理者视角和执行者视角做出辨别。在具体治理过程中，遵循双门路形式：布局式治理：指标制订、规定圈选、治理施行、收益统计、经验总结响应式治理：订阅音讯、发现问题、施行治理、注销问题、复盘总结服务层，也称为整体服务逻辑层，拆分了数据服务、工作执行、音讯服务、事件核心等不同模块，特地是接入服务模块，可能提供凋谢能力。数据组件层，作为根底建设层，包含元数据仓库建设、大数据组件适配等。将来瞻望 将来瞻望次要包含三个局部。 体验打磨在平台建设阶段，DataLeap曾经建设比较完善的能力，并在外部无效利用。接下来，咱们会持续贯彻双门路的建设形式。在布局式门路上，使资产更清晰、规定更丰盛，进一步打磨动线，进步收益准确性。在响应式门路上，除了问题注销、归因外，后续将次要针对总结演绎、教训积淀进行建设，使字节外部治理教训更好地复用到其余业务方。凋谢能力分布式自治的理念，保障业务能够自定义指标，并对齐SLA。后续，咱们将从三个方面继续凋谢能力：自定义指标，比方自定义衰弱分、自定义组织，使不同业务能够本身状况定义衰弱分的组织模式和形容。自定义计划，进一步打磨自定义规定的接入流程，并将规定能力凋谢，反对业务调用，并实现本身资产剖析。买通业务，以业务视角对待问题，针对业务问题和需要，欠缺平台建设。增强型数据治理目前DataLeap大部分都是统计类规定，正在建设开掘类规定。后续会在智能化模型建设方面，做更多预测剖析。 以上介绍的一站式数据治理能力和实际，目前大部分已通过火山引擎DataLeap对外提供服务，点击跳转大数据研发治理套件 DataLeap理解更多

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，并进入官网交换群 A/B测试是企业产品新老性能迭代时，进行成果监测的办法。通过 A/B 测试，能够进步性能改变给产品带来正向收益的确定性。 无论是产品页面元素、布局、文案，还是产品策略、算法、逻辑，改变时均可抉择 A/B 测试，察看不同产品策略下的数据成果和产品收益。惯例的 A/B 测试平台，在设计配置 A/B 试验时，均须要产品、研发、运维通力合作能力实现，工夫老本和人力老本较高，同时上线性能呈现问题后回滚解决的工夫也较长。这种高老本和危险的不确定性，让很多企业对于 A/B 试验在本人业务中的广泛应用望而生畏。 针对上述痛点，火山引擎 A/B 测试（DataTester）推出“智能公布”性能，能够大幅升高企业在 A/B 试验时的人力老本，并且新性能发版时的自助式灰度扩量，能够显著缓解每一次上线公布的危险，有了智能灰度、疾速回滚等性能的多重保障，让企业的产品新性能的上线危险一直升高。 火山引擎 A/B 测试（DataTester）的智能公布能够在产品性能开发阶段，实现多个性能并行开发、一站式配置管理晋升开发效率。基于智能公布的 CI/CD，性能上线与失效拆散，使用者可通过开关管制性能何时失效，整个过程可继续集成开发，迭代速度显著高效；可一站式托管不同端（App、小程序、Web 等）的 Feature，高效治理利用下的不同 Feature。 DataTester 智能公布领有配置公布平台，可反对动静配置下发、灰度公布、疾速回滚，还能够实现人群定向公布、配置治理。 在性能开发实现测试后，通过 A/B 测试产生了优胜版本，智能公布能够间接将试验固化到 Feature，实现 A/B 试验的疾速全量，并可采纳灰度公布更加持重全量。 并且在智能公布中创立 Feature 后，可间接由 Feature 开启 A/B 试验，快捷试验试验的开启和后续治理。 在性能上线阶段，智能公布能够实现新性能发版能够逐渐灰度扩量，潜藏问题及时发现止损，同时能够设置定时公布打算，实现主动上线和下线，无需蹲点人工操作。 另外，DataTester 智能公布的每次更新均有版本治理，发版过程若有问题可疾速回滚或者敞开 Feature 开关，也反对回滚到历史任意版本。 DataTester 是火山引擎数智平台旗下产品，作为字节跳动外部应用多年的 A/B 测试平台，DataTester 有反对多种简单 A/B 试验及精准迷信的分流能力，可能深度耦合举荐、广告、搜寻、UI、产品性能等多种业务场景需要，为业务增长、转化、产品迭代，策略优化，经营提效等各个环节提供迷信的决策依据。 目前，火山引擎 DataTester 曾经服务了美的、失去、凯叔讲故事等在内的上百家标杆客户，将成熟的 " 数据驱动增长 " 教训赋能给各行业。 点击跳转 A/B测试 DataTester 理解更多

随着国内疫情管控的逐渐放开，国民经济倒退正逐渐复原，全国多个省份先后召开经济工作会议，强调要坚固各产业劣势并强化转型降级。3年疫情里，大量企业因为各种“不确定性”而时刻面临着生存危机；与此同时，也有不少企业在疫情倒逼下一直修炼本身，摸索顺境求生之法——这其中，数字化转型被胜利验证是一条可行的门路。 用数据去驱动生产则是数字化转型的“大脑”，它能够令资源配置更加正当，流程更加规范、省时、高效。在此背景下，企业须要以数据为外围驱动因素、实现数据的互联互通，重构和降级数字化基础设施的建设，以此作为翻新与改革的撑持，实现数字化转型的降级和迭代。 日前，思迈特软件携手镜舟科技联合推出《后疫情时代，企业抓住经济回暖红利的要害》线上直播流动。本次直播邀请到思迈特软件副总裁徐晶、镜舟科技解决方案架构师高雪熠及思迈特软件产品计划专家林钰隔空对话，并重点分享企业如何利用数据驱动企业倒退的的破局秘笈，以下是本次直播流动中精彩内容回顾。 危中有机，企业要抓住数字化转型最佳门路——思迈特软件副总裁徐晶 徐总示意，疫情过后，企业如何化危为机，把握数字化倒退契机，调整商业模式、优化经营治理，进而晋升企业竞争力，成为其生存与倒退迫不及待的课题。面对新问题，必须要有新思路，企业必须突破传统的门路依赖，摸索“无接触”生产和交易方式，通过“云办公”、“线上经营”和“智能化制作”等模式开辟新的倒退方向。 然而，中小型企业在数字化转型路线上仍是比拟吃力的，规模越小的企业对各项数字技术的采用率越低；越简单的数字技术中小微企业越难把握和施行，这源于一系列阻碍，例如信息匮乏、资本有余、意识有余等。 为此，徐总在直播间分享了中小型企业数字化转型的最佳实际门路，即业务数字化→数据资产化→资产价值化。 徐总剖析道，业务数字化次要依靠于业务实现挪动化和智能化；数据资产化是依靠于数据的无效治理；资产价值化则是通过数据分析让数据驱动业务倒退——由此造成良性的循环，让企业破局成长。 “真Excel”报表工具晋升数据化管理效率—— 思迈特软件产品计划专家 林钰 林老师在分享中提到，在数据量日益增大、数据存储扩散的背景下，企业往往存在以下痛点：业务零碎中自带报表无奈满足灵便多变的需要、代码开发报表周期长且不稳固、Excel开发报表数据难取且权限难管等。因而Smartbi推出电子表格软件，心愿在一站式BI产品之外，更多的企业用户能够通过成熟、可控、玲珑、灵便的报表工具，晋升数据化治理的效率。 Smartbi电子表格软件并不以数据模型为外围，也没有“人见人爱”的交互式仪表盘性能，而是真正回归到最亲民的“真Excel”特色上，基于SQL脚本或可视化拖拽的数据集，就能在Excel中实现中国式报表的设计和公布，晋升效率的同时又大大降低了制作企业报表的门槛，让数据驱动业务倒退，让企业紧抓经济复原的红利提供了无效工具。 Smartbix镜舟数据库，联结打造数据管理解决方案思迈特软件作为国内大数据分析软件厂商，致力于构建数据报表与剖析平台，通过 Smartbi 自身弱小的数据连贯能力、“手自一体”的数据筹备能力、基于 Excel/WPS 的报表设计能力、一键公布分享，具备高集成性、以及银行级的平安管理机制和字段级的元数据管理能力，帮忙用户建设企业级、全流程的大数据管理和利用能力。 而作为底层数据引擎，镜舟数据库兼容 MySQL 协定，可应用 MySQL 客户端并完满适配Smartbi ，具备程度扩大、高可用、高牢靠、易运维等个性，充沛满足金融、物流、汽车等政企客户对技术支持、解决方案、生态建设、售后保障等方面的极致要求。 2023年对于很多企业来说，是重构生产力、生产关系的重要时刻，思迈特软件作为BI行业的先行者，将在技术产品和客户服务等维度继续发力，为各行各业的企业客户提供精准化、个性化的解决方案，以当先的技术产品能力和优质的服务体系来赋能客户的数字化转型，推动数字经济高质量倒退。 想要理解更多直播回顾内容，请分割小麦：smartbixiaomai，更多产品信息，欢送到Smartbi官网

近日，火山引擎 DataTester 对 A/B 试验“可视化编辑器”进行了降级，可视化编辑器性能让用户无需编写任何代码，即可在网站或相干产品页面上进行根本的视觉更改，并发动 A/B 试验。 降级后， DataTester 可视化编辑器具备如下新个性：交互方式优化，页面和试验切换，抉择元素可视化编辑，聚焦更顺畅的操作缩小刷新初始化内容，让刷新加载更快捷沉迷式的预览体验，防止烦扰因素影响Xpath 的层次结构视图，让层级展现更清晰火山引擎 DataTester 的“可视化编辑器”性能可反对多种类型的 A/B 实验设计，本文将具体介绍其反对的“MVT 多变体可视化试验”性能。 多变体可视化试验（简称 MVT，全称 Multi-variate Visual Test）是同时对一个网页的两个或多个元素变体进行 A/B 试验，以查看哪个组合策略能够产生最好的后果，DataTester 新版“可视化编辑器”让多变体可视化试验的施行更加便捷。 据介绍，多变体可视化试验中的元素（Element），指的是页面中的元素，如页面按钮地位、款式、色彩等，DataTeater 反对针对页面中的多个元素进行 A/B 试验。 变体（variant）是针对页面元素中的批改，元素进行批改内容和款式保留之后就是变体。 而组合（combination）则是指实验组，即一个元素下能够有多个变体，一个变体下有同一个元素不同批改，元素中不同的变体互相穿插组成的一个版本。 举例而言，如果正在对 3 个元素进行 A/B 测试，每个元素别离有 2 个、3 个、4 个变体，每个变体下都有不同的元素批改内容和款式，则一共有 24 种组合 (2x3x4)。在 DataTester 中即可间接开启 24 组试验，并观测后果。 用户在 DataTester 中输出指标网页 URL 后，即可点击进入“可视化编辑器”。DataTester 将基于网站原页面关上可视化编辑器。网页元素配置入口，在可视化编辑器的右上角有 Tooltip 提醒，可间接进行元素拖拽操作。 在 DataTester 中抉择变体之后，左侧看板联动，显示以后对应的元素和变体，便于用户间接对选中元素进行编辑。如下图所示，反对可视化编辑元素文本、色彩、字体、款式等。 DataTester 多变体可视化试验实用于如下场景：当 Web 网站/H5/APP 访问量较高时，运行多变体试验尤为有用且无效。当用户有一个策略假如能够通过多种形式实现变体，但无奈决定该测试哪种组合时，则适宜多变体试验验证。 DataTester 是火山引擎数智平台旗下产品，作为字节跳动外部应用多年的 A/B 测试平台，DataTester 有反对多种简单 A/B 试验及精准迷信的分流能力，可能深度耦合举荐、广告、搜寻、UI、产品性能等多种业务场景需要，为业务增长、转化、产品迭代，策略优化，经营提效等各个环节提供迷信的决策依据。 ...

1 前言“世上无难事，只有不集成。” 数据中台开发阶段的前期工作，最艰难就是数据集成了。刚开始数据建模做的好坏，业务做的好坏，仿佛都有情可原，然而数据集成不上来，所有业务近景就如地基不牢的高楼随时都可能倾覆。 从之前的我的项目教训来看，数据加工的建模办法和SQL语言都是较为标准化的，在我的项目中与阿里云第一次单干的搭档和客户对于数据集成的学习和把握都是较为艰难。尤其是之前没有相似须要数据集成系统的企业，对数据集成工作的了解不是过于简略，就是过于担心，又或者过于严苛。究其原因，还是对数据集成工作做什么都不理解，进而有很多误会。 2 DataWorks的数据集成早年DataWorks是只有离线集成，没有实时集成的性能，因为其定位次要是基于MaxCompute的离线开发平台。然而这几年在面向DataOps的倒退上，定位曾经是全能的大数据开发平台，能够基于多种引擎做数据开发。例如holo这种实时数仓的产品。所以，实时数据集成也是箭在弦上，终于做了一些对应的性能，作为一个资深用户还是很惊喜。 然而目前从理论应用上来看，实时集成性能尽管补救了性能上的缺点，然而与离线集成的弱小比起来，还是有所欠缺。 首先是惊喜的局部。实时数据集成的间接构建了一键同步的性能，把简单的配置实时同步工作，归档到log表，而后从Log表又merge到全量表的所有逻辑都蕴含在内了，真的实现了一步取得数据。从理论应用上来看，客户和搭档学习配置一个实时数据集成工作与学习配置一个离线工作的成比起来更低。大部分人一次就配置胜利，取得感很强。从资深用户的角度看，这种弱小的整合能力也让理论运维的工作变得非常少，能够大大加重开发人员的工作量，几乎是幻想的此岸。之前在一个部委大型项目上，咱们的数据集成表高达几十万，每天调度运行的工作都是以十万计，有效运维压力山大。 而后是欠缺的局部。从理论应用上来看，单个一键同步工作所承载的工作数量还是须要限度。整合尽管带来了益处，屏蔽了细节，然而工作太多在一起部分异样会影响全局，影响范畴也会变大。再就是目前实时集成并没有缓冲的机制，再遇到源端数据库批量解决的时候，比拟容易过程异样，须要针对性的调整内存参数后才能够复原，也影响了数据产出的时效。再就是目前实时集成在混合云只反对oracle和mysql这两种数据库，反对的数据库品种还是十分的少。 3 实时集成就能够解决全副问题我敢置信，在设计之初，开发人员肯定是想用实时集成代替离线集成，因为相比离线集成实时集成更加完满。而且，我在之前的文章中也讲过实在的集成场景，实时数据集成肯定是支流，离线集成应该是辅助。 数据自身就是实时产生的，没有哪个原始数据不是实时产生的，只有后续的数据处理过程才可能离线。所以，实质上来说，原始的数据都是实时的，只有实时集成能力提供更高时效的数据用于数据分析。 以最罕用的数据库实时集成为例。数据库记录了业务零碎的操作型数据，业务零碎自身就是实时在变动的。网页日志记录了网页拜访的信息，这个过程产生的数据也是实时的。音视频数据流也是实时产生并且存储传输的。 那么离线数据是怎么来的呢？离线数据只是实时在变动的数据在某个时点的一个切片。咱们在做离线集成的时候，其实是向数据源端发动了一个某个时点数据的拜访申请。例如向某个数据库提交了一个SQL，数据库会返回提交这个时点数据表的一个时点切片。这只是这个数据库表的某个时点状态，过了这个时点再提交，数据表返回就可能不同。 实时集成就像接了一个石油管道，石油会源源不断的从数据源流到数据中台中去。然而这个管道投资是微小的，如果管道中的油始终都是满载的传输还能够，实际上的数据产生更像是变幻莫测的天气，白天热早晨冷，偶然刮风下雨，偶然气候灾害。所以，实时集成也有本人的缺点。 相比之下离线集成占用管道的工夫是短暂的，然而都是满载的，效率上会更高。 实时集成的次要缺点就是投资大，不足灵活性。为实时集成配置的资源不能够依照最小评估，必须依照最高的去评估。不论是传统的OGG这种历史长达几十年的产品，还是DataWorks这种新秀，都是会常常遇到突发的数据洪流导致过程解体。很多DBA或者数据库从业人士，一提到OGG就都头大，运维简单压力大，稳定性也是差强人意。集体认为这次要还是因为老本效率的问题，经济划算的去运行，就得承受局部状况下的异样。 那么是什么起因导致的异样呢？一般来说，很少是因为业务零碎自身的起因，因为大部分交易型零碎不是双十一那种场景，数据库系统个别都被用来做与人相干的解决，自身就是离散的。我遇到的100%的数据库实时集成问题的起因无外乎两种，一种是后盾运维批量更新，另外一种是后盾批量数据处理（存储过程出个报表，做批量计算）。所以实质的起因是：数据库没有做交易型的业务，去做了批量型零碎。在遇到这种场景，实时同步就会很解体，因为大部分时候都是乖乖宝，然而忽然就变身了绿巨人，一下子就能够把实时同步过程搞解体。而且，这种状况，因为有人的参加，变得不可预测。 4 要为你的零碎做出抉择谈到这里，你就晓得应该怎么做了。交易型可预测的局部做实时，因为实时简略牢靠，运维起来容易。不可预测的批量运维，和批量数据处理应该走离线，因为这两种操作自身就是一种离线解决。 再就是经济性，如果不思考老本，那其实能够尽可能全搞成实时，我用超大的资源节约来满足各种不可预测的异样，来保障我的运行。就像咱们国家的春运，是不是要把零碎设计成春运不堵车的模式，还是设计成平时不堵车的模式，还是看够不够豪。 而咱们做个别的小我的项目还是要考量一下的，上面是总结： 集成准则： 1 费用缓和，资源无限，尽可能应用离线集成。 2 批处理数据（次要指源端数据是批量产生，或者双十一式爆发式产生）集成，尽量走离线。如果的确估算十分短缺，资源十分丰盛，也能够走实时集成（很多时候，源端都可能扛不住）。 3 交易型数据集成，尽量走实时，如果资源无限能够走离线。 4 大表，例如数据超过200W、存储超过1G，尽量走实时，这种表个别在业务零碎中数量不会超过表数量的20%。离线集成时效性很难满足要求，当然也不是不行。个别离线集成的表在1-10亿这个级别也是能够一战（与系统资源相干）。再大基本上就很难了，集成工夫过久，业务零碎没有足够的快照空间，事务会报错，集成就会失败。 5 小表，例如长年不动的代码表，10W以下的小表，大略都能在30秒-3分钟内实现，倡议走离线。毕竟实时挺贵，这些小表，还是打包搞过来比拟适宜。 就到这里了，我为什么写这么多集成的文章，真的很头疼。我每年都要给新的搭档和客户教集成，每次还总能遇到新问题，把我搞的很狼狈。尽管集成看起来如同简略，然而真正客户化的把集成方案设计好，真的还是须要下一番功夫。 原文链接 本文为阿里云原创内容，未经容许不得转载。

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，并进入官网交换群进入数字经济时代，要用数据驱动业务增长曾经成为各个行业的共识，但很多企业还没能真正把握这项能力。如何最大限度转化数据价值，实现决策优化是企业数字化过程中面临的最大难题，字节跳动副总裁杨震原曾在火山引擎开放日中分享了字节是如何解决增长问题的认识： “数据驱动不是唯数据论，更不是数据至上。咱们常说的数据驱动，不是有数据就能够驱动，而是须要对能够量化评估的指标，以 A/B 测试这样的后果数据能力更好地驱动，它代表的是科学决策的理念，不然数据驱动的决策也可能是很蹩脚的决策。” 企业在决策优化时首先须要解决两大外围问题，一是要确认指标，这个指标既要档次正当，还需可掂量；二是要有靠谱的评估办法，尽可能去做更为精准的因果关联推断。 从公司层面来看，因为单纯依附主观指标决策会面临危险，因而战略决策往往是由人来做判断的。但它的问题在于执行层面很容易不统一。战略决策在执行过程中面临很多细节问题的决策，参加的人越多，越容易呈现不一致性和有偏性。 如果采纳非 A/B 测试的数据分析，关联剖析中往往带有偏见，可能会误导决策。而 A/B 测试则是相似于打造一个“平行时空”，把不同策略放进去比照试验，再基于“投石问路”的后果抉择更优计划，升高决策危险。 字节跳动在成立之初便开始应用 A/B 测试，为了晋升整个 APP 活跃度，从一个交互按钮色彩的变动，或者是一条站外推送的文案，再到外部的经营和公域上的这种营销的策略，甚至是模型算法的优化摸索和产品性能迭代，再到整个底层的技术架构的降级，其实都会去做 AB 试验。也因而在字节跳动有一句话叫做“AB 试验是一种信奉，万物皆可试验”。 目前，DataTester 在字节内每日新增 1500+试验，服务于公司 400 多项大大小小的业务，累计已有 150 万次的 A/B 试验进行过。 DataTester 当初已通过火山引擎，开始对外开放给更多企业客户，让更多内部用户能够应用这个增长利器。基于字节跳动的成长理念，以 A/B 测试延长开来的火山引擎，对外提供的整套的解决方案，中小企业也能借助字节跳动的技术力量拥抱最新的产品趋势，融入字节跳动的各种方法论，打造更加优良的产品。 点击跳转火山引擎A/B测试DataTester官网理解详情！

随着咱们迈入2023年，大数据分析、人工智能和云产业将迎来蓬勃的翻新和倒退阶段以下是咱们预测的，将对行业格局产生重大影响的五大趋势： 世界在巨变，咱们须要尽快寻找行业中的方向，迅速重回轨道 2023年，寰球经济层面的不确定性将继续存在。 在云上部署数据密集型负载的企业需从新评估其云策略，更加关注老本优化，依据现有或新我的项目的ROI（投资回报率）和TCO（总领有老本）来进一步扫视企业的云开销。 在新的一年里，实现老本优化的一个重要途径就是升高企业云老本中占比拟大的数据进口老本（egress cost）。 越来越多的企业会优化其架构，以防止受到超出预期的数据进口老本的冲击。例如，企业能够思考通过Alluxio缓存来升高经网络传输的数据流量。 此外，越来越多的企业在寻求实现“多云部署自在”， 从而可能不受限制地应用任何云厂商的服务。确保利用的可移植性将是实现这一“自在”的前提条件，这让企业可能依据本人的具体要求和估算抉择最佳的计划。 包含OpenAI 的对话模型ChatGPT 、DALL-E 2的图像生成模型以及谷歌LaMDA聊天机器人等大模型在2022年都已展现出微小的后劲。 预计这类模型将在 2023 年解锁更多用例和应用程序。 同时，这些模型的遍及将无望推动人工智能专业化基础设施和解决方案的倒退。 训练具备数十亿个参数的大模型须要非凡的基础设施和解决方案来解决计算需要。因而，可能反对这种规模和复杂性模型的人工智能基础设施将会一直倒退。 此外，随着大模型一直降级优化，研发人员将须要找到更多新的办法，用来把更多的大模型和理论的利用场景联合起来。因而，咱们预计随着人工智能基础设施的倒退，新的工具和平台将呈现，使研发人员可能更容易地开发和利用大模型。 数据共享既包含企业外部的数据共享，也包含企业间的数据共享。 只管数据共享目前尚未遍及，处于晚期阶段，然而，以数据共享为外围的生态体系，包含为数据消费者和数据提供者的基础设施、交易能力和服务，都将在 2023 年失去长足的倒退。 跨区域的数据价值实现将驱动企业外部数据的共享，进一步打消数据孤岛。随着越来越多的企业寻求将数据资产货币化，内部数据共享的利用场景和胜利案例也在显著增多。例如，面向学术界和钻研畛域，企业正在摸索利用数据共享平台来共享钻研数据，从而减速科研进度。 这一趋势将对数据基础设施产生重大影响，企业须要通过调整和降级零碎来反对跨地区、企业、云以及平台的数据共享。因为企业需确保以合规和平安的形式治理和拜访其数据，因而也将更加关注数据治理和数据安全。 在古代数据技术栈中，数据仓库和数据湖的交融趋势越发显著。 其背地的驱动力在于数据日趋复杂化和多样化，企业须要灵便和可扩大的零碎来反对大范畴的数据迷信和剖析用例。因而，数据仓库和数据湖的融合度也越来越高。 Apache Iceberg、Hudi 和 Delta Lake 等凋谢表格格局的衰亡在这一趋势中施展了重要作用。通过应用表格局定义层，能够在单个零碎中无效地存储和治理大量结构化和非结构化数据，使得企业可能以更低的老本更快地提取数据价值。 到 2023 年，随着这些解决方案的迅速采纳，更多的企业将应用凋谢表格格局存储数据。 长期以来，Kubernetes 中的存算拆散对数据本地性造成了挑战。只管在Kubernetes 中进行数据密集型利用的部署和弹性扩大曾经非常容易，但在拜访云原生数据源中的数据（例如 AWS S3 或近程数据仓库）时却更加艰难。 咱们预测，在2023 年，数据本地性的难题将失去解决。 对于Kubernetes调度器来说，可能独立于数据地位进行决策的能力变得越来越重要。这种能力对于Kubernetes接口来说将愈发要害，它将帮忙应用程序和调度器更加高效，诸如Alluxio等组件目前正在打算提供相干反对。 因而，新的一年将会呈现更多弥合计算和存储的解决方案，帮忙企业更好地治理和优化其在 Kubernetes 中的数据存储和解决。 2023年对于大数据、人工智能和云产业而言将是激动人心的一年。 大量的冲破和翻新将主导这些畛域的将来走向，许多技术范式将一直交融，造成一个以数据为核心的生态系统。 至于各项技术将如何演进并影响咱们的生存，让咱们刮目相待。 范斌 Alluxio开创成员兼开源社区副总裁退出Alluxio前, 在Google从事下一代大规模分布式存储系统的钻研与开发. 范斌博士毕业于卡内基梅隆大学计算机系, 博士期间在分布式系统算法和零碎实现等方向发表多篇包含SIGCOMM, SOSP, NSDI等顶级国内会议论文以及多篇专利。想要理解更多对于Alluxio的干货文章、热门流动、专家分享，可点击进入【Alluxio智库】：

岁末年初，在开源畛域刚埋下一颗生机勃勃的种子的 Tapdata，想和正在关注咱们的开发者，聊聊这一年的停顿和新一年的共建打算。 2022年4月，Tapdata 发表开源 PDK（Plugin Development Kit），将本身的数据接口技术抽象化，赋能开发者。同时联结 Apache Doris、OceanBase、PolarDB、SequoiaDB 等生态搭档，开启插件共建打算。 2022年7月，依靠 Tapdata 外围性能的 Tapdata Community 正式与大家见面，越来越多的搭档退出到咱们的开源社区中来。 2022 下半年，为了吸引更多优良的开发者参加共建，同时沉闷社区，回馈我的项目贡献者，Tapdata 数据源 Connector 挑战赛启动，更多陈腐力量随之涌入。 在内、内部开发者的合力之下，2022年 Tapdata 新增数据源近20个，其中包含数仓指标 BigQuery、Doris、Ckickhouse、阿里云存储、OSS HDFS、SelectDB 等，实现了60+数据源的接入能力。与此同时，PDK 架构可扩大能力进一步加强，能够反对：4小时疾速对接 SaaS API 零碎；16小时疾速对接数据库系统。 为了让大家充沛理解我的项目停顿，帮忙新退出的开发者无效躲避一些首次开发过程中的常见问题，咱们特地邀请到挑战赛首位胜利支付参赛奖金的内部开发者（GitHub ID: IssaacWang），以及官网技术支持 Jarad，围绕以下几点开展分享： 从开发者角度来看，Tapdata 我的项目新增了哪些变动？在开发过程中的常见问题有哪些？对于 Tapdata “开发老手”，有什么倡议和教训分享？一、Tapdata 我的项目停顿：对开发者更加敌对为了更加不便开发者上手，咱们在整体的敌对水平上，进行了如下优化： ① 反对在线 Debug在新数据源开发的过程中，无需关注引擎、TM（Tapdata Manager）等，只须要专一于数据源我的项目模块即可。开发实现后，还须要通过在线联调测试同步成果，但在此前，因为前端尚未开源，内部开发者实现起来就会没那么不便。但当初无需前端，只须要将引擎拉到开发工具中，在实现数据源插件开发后，就能通过环境变量配置，轻松关联 Tapdata 云版，补救前端页面缺失。开发者得以在云版治理端启动数据同步工作，而理论响应则是在本地 IDEA 中失效，从而反对开发者在本身开发工具的 IDEA 中打断点，达到在线 debug 的成果。 ② TDD 单元测试优化咱们在 TDD 测试框架上新增了不少测试用例，开发者在实现一个数据源的开发工作之后，只有有本人的开发工具，以及本地的数据源部署，就能够通过 TDD 用例来进行单元测试。 咱们的首位内部开发者在数据源 TDengine 的测试环节，就跑完了包含在线联调 P0 测试，以及 TDD 段元测试的全流程。 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，并进入官网交换群对大多数职场打工人来说，看数据、用数据始终是项有“门槛”的工作。特地是在企业业务疾速倒退的背景下，为了让参加我的项目决策的员工、管理层尽快看到业务相干数据（通常包含外围业务汇总数据、业务一线明细数据等），数据团队往往须要全力以赴应答数据需要，从而导致数据岗位人员、数据开发设施等在内的多项资源老本压力。 另一方面，企业业务零碎自带的数据看板个别无奈满足间接看数据的需要，因而数据岗位员工会抉择手动下载明细数据，并在 Excel 等本地文件中进行汇总剖析操作；当面对沉重的需求量时，往往只能做一些简略自动化数据处理，再加载到关系数据库（例如 MySQL、SQL Server、Oracle 等）中，通过 SQL 代码形式实现根底加工解决和出现。 但无论是 Excel 解决还是 SQL 代码解决，都无奈防止因为波及多层级/多部门逾越，而造成的角色应用数据范畴差别、数据实时性差、数据分析看板不易读、好看度差等系列问题。 为了更好地晋升企业员工在取数、看数、用数环节的体验，火山引擎数智平台 VeDI 目前曾经面向企业级用户推出智能数据洞察 DataWind。 从产品架构上来看，DataWind 能够分为数据源、存储计算引擎、数据建模、数据分析和数据利用五大版块。 值得注意的是，数据在利用端做数据分析时须要剖析引擎加持，DataWind 可根据企业特色反对两种不同模式：一种是产品内置存储的计算引擎 ByteHouse，能够反对千亿级别大数据量的自助剖析，数据显示，在大多数剖析计算场景（分组、占比、比照、排序等）下，ByteHouse 查问引擎计算速度相较一般剖析引擎至多可能晋升百倍以上；而另一种则是直连引擎，它能够间接与数据库交互，当企业的数据库性能足够的状况下，能够抉择应用。 从数据连贯上来看，DataWind 可反对从业务数据库、Excel/CSV、飞书上业务数据填报、内部平台数据（比方广告域、内容域、微信生态等），以及实时/离线数仓等 40 多种路径实现数据链接。 在数据处理方面，DataWind 着力于尽可能升高操作门槛，比方提供「AI+BI」的可视化建模服务，在此基础上，企业员工能够在数据分析环节实现可视化拖拽式操作，同时 DataWind 还可能主动将数据代码解析为可视化图表。 此外，在面向利用端方面，DataWind 早已可实现多端利用，与目前市场风行的多种 IM 办公产品深度集成，比方飞书、钉钉、企业微信等，保障用户在挪动办公场景下，仍旧畅享实时数据在线上传、查看、剖析、解决、利用等多种服务。 从肯定水平上来说，火山引擎数智平台 DataWind 汇合了以后字节跳动在外部多业务多场景上的智能数据洞察实际能力，并实现了产品式输入，截至 2022 年 12 月，该能力曾经在互联网、汽车、批发、金融等多个行业在内的多家标杆企业取得利用实效。 点击跳转火山引擎智能数据洞察DataWind理解更多

作者： 石烁摘 要：在大数据开发畛域，大家都会被一个问题困扰：调度工作提早，而后被老板、被业务“灵魂拷问”。本文将从问题挑战、指标掂量、口头计划、成绩展现、后续布局五个方面开展，详述网易云音乐在全链路基线治理的实际。 一、问题挑战基线治理前，咱们的基线运维存在较多的问题，有两个数字很能阐明问题：（1）月均匀起夜天数达80%以上。为什么会这么多呢，有很多因素，例如运维范畴不清晰、基线挂载没有束缚、集群资源缓和等等。（2）基线产出工夫较迟，常常无奈在下班前产出，月均匀破线时长将近十小时。 要进行全链路基线治理，面临的挑战也很大，次要来自3方面： 工作多：千亿级日志量，万级任务数，如何收敛在可控的范畴，如何在出错后，能较快的重跑完？资源紧：凌晨资源水位95%以上，没有任何的 buffer 预留，也没有弹性资源可用；要求高：显微镜下工作，以 MUSE 产品为例，上百 BD，每天下班就看数据，他们的 KPI 考核就以 MUSE 的数据为准。二、指标掂量全链路基线治理的价值，总结起来次要有4个方面： 服务于管理层，让管理层第一工夫能查看公司的经营数据。面向 C 端的业务数据，可能稳固、及时的让用户更敌对的应用。可能建设数据开发团队的研发口碑和影响力。晋升咱们数据开发同学的运维幸福度，进而晋升组织的稳定性。那么咱们用什么指标来掂量咱们的指标呢？咱们提出了两个数字来牵引： 98%：全年可用天数达到98%以上，即服务不达标天数全年不超过7天。基线工夫：外围 SLA 基线产出工夫需满足业务要求。三、口头计划3.1 整体计划基于上述问题挑战的分析，咱们对该问题的解题思路拆成3个方面： 平台基建：俗话说：“根基不牢，地动山摇”，首先要解决的就是平台基建，例如如何掂量咱们的集群资源是否饱和、咱们的队列如何管控、产品性能如何反对等等。工作运维：全链路上，哪些工作是卡点？超长高耗资源工作是什么起因？哪些工作须要高保障？组织流程：有没有规范的运维 SOP ？跨团队的合作机制如何建设？出问题后，如何无效的跟踪以及防止再次发生？用3个词演绎，就是稳基建、优工作、定规范。 3.2 稳基建基建这块，咱们梳理了存在的问题：（1）队列应用不明确：总共拆分了几十个队列，没有明确的应用标准；（2）资源监控靠教训，无通用指标掂量；（3）集群 Namenode 压力大，负载高；（4）资源管控弱，遇到突发状况无奈保障高优工作优先获取资源。 针对上述问题，咱们施行了如下的解决方案： 集群稳定性建设：联结杭研，对负载高的 Namenode 集群进行 DB 拆分，迁徙上百张表；同时欠缺集群的监控，例如 nvme 盘夯住主动监控修复，dn/nn/hive 等节点监控优化疾速发现问题。集群资源数字化：实现了一个高牢靠的资源应用模型，为集群资源管理员提供具体的数字化指标，以此能够疾速判断以后集群的资源应用状况，解决以后集群资源分配不合理的状况。产品化：通过产品层面晋升资源的应用效率，比方产品性能反对按工作优先级获取队列资源，产品层面实现自助剖析&补数性能凌晨禁用或有限度应用。队列资源应用领导倡议：制订队列的资源应用标准，明确各个队列的作用，管控队列应用，布局高中低级队列。3.3 优工作针对云音乐体量大、业务多、团队广的数据工作特点，咱们在这块做的工作次要有： 外围 ETL 引入流式解决，按小时预聚合数据，这样1小时内实现流量日工作批跑。工作优化：如 hive、spark2 版本升级至 spark3 ，队列调整、sql 革新等等。买通表、工作、基线间的血缘关系，优化工作的调度工夫，缩小工作依赖错漏配。指标的异样监控，咱们除了传统的 dqc 外，还引入机器学习模型，解决云音乐 DAU 这类指标具备周期性、假日因素的监控难点。其中，spark 降级失去了杭研同学的贴身服务，获得了比拟好的成绩，hive 降级到 spark3 实现大几百个工作的革新，节俭60%资源。spark2 降级 spark3，实现将近千个工作的革新，整体性能晋升52%，文件数量缩小69%。 指标的异样监控，引入的机器学习模型，咱们次要交融了 Holtwinter、XGBoost 算法，相比 dqc 的监控，咱们在 DAU 这个指标上，召回率晋升74%，准确率晋升40%，正确率晋升20%；同时这里还有一个很大的作用是，它能感知业务的动静趋势性变动，而且部署也很简略，配置化接入。在产品层面，咱们也正在联结杭研产研同学，将该能力集成到数据品质核心。 3.4 定规范在定规范方面，次要从两方面登程：运维的范畴和运维标准。基于这两点，咱们开展了如下的工作： 以外围产品+外围报表为载体，划定外围 SLA 运维基线+数仓两头基线，值班运维的范畴从原先的上万个工作缩减到千级任务数。明确任务责任人，解决之前事不关己高高挂起的问题，依照业务线划分，工具+人肉并行的形式将无归属的工作归属到责任人。制订基线挂载准则，明确约束条件、各角色职责等。制订规范的运维 SOP ，严格运维军规和奖惩机制；同时跟杭研建设数据运维交警队，多动作保障异常情况的及时处理。建设官网运维消防群，第一工夫告诉问题和解决停顿，解决信息传递不够高效，业务体感差的问题。与杭研、平安中台、前端等达成对立意见，引入 QA 作为公正的第三方，对立牵头解决问题的复盘和归因，确保问题的收敛。四、成绩展现我的项目成绩这块，次要分为业务成绩、技术成绩、产品成绩三方面。 ...

针对业务场景中数据利用价值的落地，网易数帆造成了以 DataOps、DataFusion、DataProduct 为内核，数据技术、数据资产、数据利用和数据经营为四因素的数据生产力模型，其中网易公司数据经营的一个重要伎俩是网易数据治理大赛。本文是第二届网易数据治理大赛获奖作品分享，来自于网易互娱用户体验核心数据团队。云音乐用户画像资产，存在链路强耦合、计存高老本、口径不对立、产品性能又有余的现状问题。本年度通过肯定的治理和产品能力扩大，实现资产治理和业务赋能。在现在降本提效的大背景下，用户画像资产在人维度数据上占据大头资源，历史遗留问题也不少，数据治理火烧眉毛。本文将从我的项目背景、我的项目挑战、我的项目计划、我的项目成绩四个方面进行分享论述，心愿分享能帮忙到大家。 1 我的项目背景着重阐明下业务和技术背景。首先是业务背景，云音乐现阶段用户增长瓶颈总量几十亿用户，日活几千万左右，月活几亿，想要再增长用户老本极高，精细化经营曾经是破圈的必须伎俩。面对当初不同的用户人群，具备不同的商业化潜质，须要对不同人进行商业化分层，能力更好的帮忙用户精细化运行。除了主站业务的拓展，子业务扩大也是火烧眉毛，用户画像能够帮忙子业务从主站业务开掘和扩大须要的用户群体，帮忙做业务扩大，扩单云音乐整体营收能力。 再说技术背景，次要也分3块内容，历史用户画像建设标签反复建设，多达32张相干画像表存在，局部依赖层级多，且标签反复建设。圈选产品不对立，存在多套产品，比方muse、诺伦、sniper等，产品侧须要做肯定的重组。圈选产品的响应速度，也是整个产品取得用户依赖的外围指标，通过肯定的技术改造实现从sql圈选到ms级圈选能力是很有必要的。 综上，能够概括为云音乐用户画像资产，存在链路强耦合，计存高老本，口径不对立，产品性能又有余的现状问题。   2 我的项目挑战数据侧难点：数量大，链路长，时效低，口径多。数量大体当初用户画像波及上千指标，须要对这些指标做对立的治理，确保指标及其对应表的高内聚底耦合，工作链路存在很多7-8层的工作层级，层级越多，工作的稳定性越差，须要对工作链路进行压缩；实效性方面，现阶段工作的时效性不高，每天产出的工夫是10点左右，远没有达到用户须要的6点时效性要求，须要进行产出工夫的压缩；对于工作的一致性，须要进行，则是如此之多的画像指标，如何做到指标的一致性是具备很大挑战的。 3 我的项目计划3.1 计划框架 针对以上内容，这些脏乱差数据应该如何治理是值得咱们花工夫去做的事件。本我的项目结合实际可实现的内容，整顿并欠缺整个我的项目计划，以治理降本和产品提效为两大主线为解决方案，如下图： 从图中能够看出，整个我的项目分为五层。底层为画像底表层，包含流量数据、用户中台数据、内容数据、会员数据、社区数据等数仓公共层数据；下层为画像逻辑层，通过对底层数据进行实体关系建模，形象成用户根底画像、用户行为画像、用户统计开掘几大块内容。 用户画像的逻辑层建模就是为了实现整个画像层，能够实现数据的一致性规范，确保数是高内聚低耦合的，同时也确保了整体的可扩展性，比方新增游戏业务的话，那就在行为画像中增加游戏实体，能够实现整个逻辑层的可扩大而不须要重构整个内容。 画像的应用层，测试整个画像的输入局部，包含画像外围全量表，以及各类画像的切片画像，如会员画像、日活画像、月活画像等等。 画像产品层是基于画像数据进行的画像产品，包含魔镜圈选产品，实现标签治理的标签工厂，实现标签服务化的标签服务能力等等。 在画像逻辑层和画像应用层波及整个画像的治理工作，包含画像的产出保障以及工作下线。 再向上则是最终服务业务的业务产品，魔镜通过买通和业务产品的能力，比方买通灵渠，能够实现从用户人群圈选到用户push的买通构建。还有天秤、音乐人经营等产品。 3.2 标签建设 用户画像标签建设以需要触发为出发点，需要调研case如下左表。需要起源包含各线分析师、魔镜、标签工厂产品、经营同学等。通过联合数仓分层和ER实体关系建模的办法、依靠业务诉求，设计画像逻辑层。实现数据的高内聚低耦合，从而确保了良好的可扩展性。 比方歌单、歌曲、直播、mv都是实体对象，通过与用户的二元叉乘失去相干数据指标，后续业务扩大游戏等，也可间接实现用户叉乘游戏，实现横向实体扩大。确保实体内数据高内聚，实体间数据低耦合。 3.3 保障体系 保障体系重点在于数据品质的监控保障，以数据稳定性、一致性、及时性、唯一性、完整性、准确性为外围保障内容，具体工具和形式见下图所示：   3.4 工作下线 工作下线机制则次要以定策略，用工具为次要伎俩，逐渐推动下线。  3.5 魔镜产品 用户画像上游接入魔镜产品，实现用户画像表服务各类业务的圈选性能，上游链接各类产品投放产品，实现画像数据的业务赋能。 4 我的项目成绩我的项目成绩从产品价值、治理价值、业务价值三大块阐明。 4.1 产品价值 对立数据服务基于画像数据及标签元数据提供高效的标签服务、圈选服务，根本笼罩了云音乐全副业务圈选服务，利用于用户经营、线上流动、AB试验、广告投放等多个产品及场景。对立数据凋谢接口的提供为用户经营、线上流动、AB试验、广告投放全业务线提供服务，做到一次开发多产品应用，缩小人力开发成本。   产品总计实现1900屡次人群包圈选，百亿次圈选，500万次多的push服务，笼罩音乐几十亿用户和上百+标签。 4.2 治理价值 总体预计下线32张表，上千多标签治理，预计节约存储老本近150万，年节俭计算成本近200万，预计年度总节俭300多万元。  4.3 业务价值 除了产品链路买通后大大节俭了push时效外，还有子业务的画像服务场景，也大大体现了业务价值。比方某子业务应用主站用户标签数据，每日实现拉新几千用户，年可节俭千万左右老本。 以上是对云音乐数据画像资产治理实际的分享，在这里感激网易数帆大数据团队对咱们的各种反对。 试用网易大数据产品

【前言】作为中国的 “Fivetran/Airbyte”, Tapdata Cloud 自去年公布云版公测以来，吸引了近万名用户的注册应用。应社区用户上生产零碎的要求，Tapdata Cloud 3.0 将正式推出商业版服务，提供对生产零碎的 SLA 撑持。Tapdata 目前专一在实时数据同步和集成畛域，外围场景包含以下几大类： 实时数据库同步，如 Oracle → Oracle, Oracle → MySQL, MySQL → MySQL 等数据入湖入仓，或者为古代数据平台供数，如： 惯例 ETL 工作（建宽表、数据荡涤、脱敏等）为 Kafka/MQ/Bitsflow 供数或下推具体场景则不可胜数，值此之际，咱们将以系列文章模式，为大家盘点 Tapdata Cloud 能够撑持的业务场景和 3.0 版本新个性，以便大家更好在业务中利用 Tapdata。本期为系列文章第三弹，将具体介绍 Tapdata Cloud 如何疾速买通数据与阿里云 Tablestore 之间的高速通路，减速体验海量数据低成本存储、毫秒级的在线数据查问和检索以及灵便的数据分析能力。（点击申请产品内测，领先体验 →） 数字化过程继续减速的明天，随着业务的倒退累积，以及企业对数据的器重，须要解决的信息量也越来越大。首先，是来自于海量数据的存储挑战，如在实现牢靠的长久化的同时，如何实现数据的并发写入？简单的剖析场景须要对数据进行即时拜访，存储系统运维如何更加高效。其次，大数据技术的倒退以及经营程度的一直晋升，也对后续的数据分析工作，如流批处理、ETL 等提出了新的要求。 上述种种行业变动与技术倒退，都对数据的存储系统提出了更高的要求。传统计划依赖关系型数据库在面对海量规模数据与简单数据检索业务场景时，为了补救能力限度往往须要分库分表、引入搜索引擎等，大大增加了开发工作量与运维复杂度。在这样的背景下，阿里云表格存储（Tablestore）可能反对海量数据长久化存储、反对数据简单检索的劣势日益凸显 。 一、阿里云 Tablestore：即开即用的 Serverless 表存储服务 作为阿里云自研的结构化数据存储，Tablestore 面向海量数据提供 Serverless 表存储服务，以及疾速查问和剖析的服务，同时针对物联网场景深度优化提供一站式的 IoTstore 解决方案。该产品实用于海量账单、IM 音讯、物联网、车联网、风控、举荐等场景中的结构化数据存储，提供海量数据低成本存储、毫秒级在线数据查问和检索以及灵便的数据分析能力。同时兼具零运维管控，即开即用，按量付费的个性。 如何在不影响原有业务的前提下，减速实现数据迁徙，把扩散的海量异构数据实时同步至 Tablestore，以应答更加简单的数据存储及查问需要？ 近日，以这一需要为出发点，Tapdata 作为异构数据实时同步及开发的当先平台，已与阿里云 Tablestore 实现产品集成认证。Tapdata 已反对 Tablestore 作为数据指标，从而为 Tablestore 提供海量异构数据导入能力撑持。（性能体验指路 Tapdata Cloud 3.0 现已凋谢内测通道） ...

随着信息产业的迅猛发展，大数据利用逐步落地，行业人才需求量逐年扩充。大数据成为目前最具前景的高薪行业之一，大数据分析工程师、大数据开发工程师等大数据人才也成为市场紧缺型人才，薪资一涨再涨。很多人想要退出到大数据开发行列，却又不晓得怎么动手。接下来小编就给大家分享一份残缺的大数据学习路线，助力大家疾速入门！ 第一阶段 为JAVASE+MYSQL+JDBC，次要学习一些Java语言的概念，如字符、流程管制、面向对象、过程线程、枚举反射等，学习MySQL数据库的装置卸载及相干操作，学习JDBC的实现原理以及Linux基础知识，是大数据刚入门阶段。 第二阶段为分布式实践简介，次要解说CAP实践、数据分布形式、一致性、2PC和3PC、大数据集成架构。波及的知识点有Consistency一致性、Availability可用性、Partition tolerance分区容忍性、数据量散布、2PC流程、3PC流程、哈希形式、一致性哈希等。 第三阶段为数据存储与计算（离线场景），次要解说协调服务ZK(1T)、数据存储hdfs(2T)、数据存储alluxio(1T)、数据采集flume、数据采集logstash、数据同步Sqoop(0.5T)、数据同步datax(0.5T)、数据同步mysql-binlog(1T)、计算模型MR与DAG(1T)、hive(5T)、Impala(1T)、任务调度Azkaban、任务调度airflow等。 第四阶段为数仓建设，次要解说数仓仓库的历史背景、离线数仓我的项目-伴我汽车（5T）架构技术解析、多维数据模型解决kylin（3.5T）部署装置、离线数仓我的项目-伴我汽车降级后退出kylin进行多维分析等； 第五阶段为分布式计算引擎。次要解说计算引擎、scala语言、spark、数据存储hbase、redis、kudu，并通过某p2p平台我的项目实现spark多数据源读写。 第六阶段为数据存储与计算（实时场景），次要解说数据通道Kafka、实时数仓druid、流式数据处理flink、SparkStreaming，并通过解说某交通大数让你能够将知识点死记硬背。 第七阶段为数据搜寻，次要解说elasticsearch，包含全文搜寻技术、ES安装操作、index、创立索引、增删改查、索引、映射、过滤等。 第八阶段为数据治理，次要解说数据规范、数据分类、数据建模、图存储与查问、元数据、血统与数据品质、Hive Hook、Spark Listener等。 第九阶段为BI零碎，次要解说Superset、Graphna两大技术，包含根本简介、装置、数据源创立、表操作以及数据摸索剖析。 第十阶段为数据挖掘，次要解说机器学习中的数学体系、Spark Mlib机器学习算法库、Python scikit-learn机器学习算法库、机器学习联合大数据我的项目。 大数据时代曾经降临，它将掀起滔天巨浪，如果你想把握这股浪潮，那就要及早动手。

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，并进入官网交换群对 C 端产品而言，增长的外围因素之一是用户活跃度。通过各类激发互动的形式，使信息得以在关系链中流转、流传，达成无效的信息交互，是产品生态是否被激活的要害。 本文将分享字节跳动的短视频产品增长案例。该产品团队通过 A/B 测试，圆满地实现了用户互动环节的优化，将产品流传率晋升了超 20%。 对短视频产品而言，用户互动行为是用户在观看内容时，做出的点赞、评论、分享等行为。 这些行为不仅能激励创作者，也能让优质作品产生规模效应，带来内容生产和生产的正循环。用户之间的分享行为，还会减速优质内容在不同媒体渠道间的流传，为产品引入新的用户。 该产品团队通过数据分析发现到一个问题：平台上的视频作品，无论是二次播放率还是点赞率，数据体现都都远远高于分享率。他们判断，视频作品的分享率可能有很大晋升空间，尤其是用户点赞过的视频，充分说明了用户对内容品质的认可，那么分享的动机和志愿也会更强。 因而，该产品团队的同学进行了大胆假如：在用户产生点赞行为后，产品界面中减少转发分享疏导，可能会促成更多分享行为。 那么如何确定上述假如是正确的？又如何在多个分享疏导界面设计中，选到最优计划呢？该产品团队利用了外部自研的 A/B 测试平台——火山引擎 DataTester，通过 A/B 试验，来帮忙他们找到最优的业务策略。 1.产品策略设计指标：通过疏导分享界面优化，晋升用户分享率。设计：绝对于线上旧版性能，新性能在疏导款式上由动态变为了动静；此外，触发机会由“用户循环播放 2 次该视频作品”改为了“用户点赞该视频作品”。疏导款式比照图如下：2.试验方案设计在实现了分享疏导新性能的设计后，该产品团队基于想要验证的指标，在 DataTester 上设计了试验分组。实验设计在原有的旧产品策略、新产品策略之外，还额定减少了一个“反转实验组”，该实验组是要验证分享策略是否对用户体验有负向影响。在试验运行一段时间后，该产品团队对 A/B 实验报告进行了剖析，发现在外围指标「人均分享量」上，“实验组 1”的数据呈正向变动，人均分享量显著晋升了 20%！数据阐明新产品策略能无效晋升用户互动志愿，该产品后续全量上线了实验组 1 的计划。这是一次胜利的 A/B 试验，这背地离不开产品团队后期筹备的多向摸索、实验设计时的一直纠偏。而到了从多个产品策略中择优的那一步，则体现出了 A/B 测试的精准和主观。 像这样的 A/B 试验，字节跳动每天都会新增 2000 余个，DataTester 依附它先进的底层算法及弱小的统计利用钻研，在字节跳动外部帮忙今日头条、抖音等多个产品“小步快跑、高效迭代”，用迷信的试验掂量决策收益。 现在，DataTester 也曾经由火山引擎对外开放服务，目前已服务了美的、失去、凯叔讲故事等在内的上百家内部企业，反对了多种业务场景需要，为业务的用户增长、转化、产品迭代、经营流动等各个环节提供了迷信的决策依据，将成熟的“数据驱动增长”教训赋能给各行业。 点击跳转火山引擎A/B测试DataTester官网理解详情！

Calcite在大数据系统中有着宽泛的使用, 比方Apache Flink, Apache Drill等都大量应用了Calcite，了解Calcite的原理能够说曾经成为了解大数据系统中SQL拜访层实现原理的必备条件之一。 然而不少人在学习Calcite的过程中都发现对于Calcite的实际案例其实很少，本文就将为大家具体介绍如何基于Calcite框架的SQL语法扩大摸索使之更合乎你的业务需要，以及扩大SQL在数栈产品的利用实际。 Calcite介绍及用处Calcite介绍Apache Calcite是一个动静的数据管理框架，自身不波及任何物理存储信息，而是专一在SQL解析、基于关系代数的查问优化，通过扩大形式来对接底层存储。 目前Apache Calcite被利用在宽泛的数据开源零碎中，比方Apache Hive、Apache Phoenix、Apache Flink等。 Calcite的用处Calcite提供了ANSI规范SQL的解析，以及各种SQL 方言，针对来自于不同数据源的简单SQL，在Calcite中会把SQL解析成SqlNode语法树结构，而后依据失去的语法树转换成自定义Node，通过自定义Node解析获取到表的字段信息、以及表信息、血统等相干信息。 下图展现了一部分对外提供的接口信息： sqlparser 解析模块次要提供了以下几种性能 : • 解析SQL蕴含的所有表、字段信息 • 解析SQL的udf函数 • 解析SQL的血统信息，包含表级血统、字段血统 • 解析自定义SqlNode • api服务变量解析替换 SQL语法扩大理解完Calcite是什么以及用处后，上面为大家分享Calcite SQL语法扩大的相干内容。 SQL语法扩大背景在 sqlparser 中进行sql解析的场景中，有两种状况须要应用到自定义扩大，一是Calcite不反对的一些语法；二是在一些场景中存在sql中带有${var}自定义变量语法。 那么针对下面的这两种状况，Calcite的自定义扩大是如何实现的呢？自定义扩大次要波及到以下三个文件： • Parser.jj：Parser.jj是一个Calcite外围的语法和词法文件，基于Apache FreeMaker模版，该模版蕴含着变量，这些变量在编译时能够被替换 • parserImpl.ftl：提供自定义SQL语句、literals、dataType的实现办法 • config.fmpp：该文件是FMPP的配置文件，提供了SQL语句、literals、dataType的接口扩大入口 Calcite应用javacc作为语法解析器，freemaker作为模版，把parserImpls.ftl、config.fmpp、Parser.jj模版合成最终的语法词法文件，最终通过javacc编译成自定义的解析器源码，整体流程如下图所示： 扩大SQL实现● 工程目录 ● 扩大sql实现案例 反对以下limit相干语法以及数字能够写成${var}模式： -> limit count， limit start count -> limit count offset start -> offset start limit count 在原生的Calcite解析是反对limit count语法的，然而因为返回SqlOrderBy对象外部类Operator的unparse办法在SQL输入过程中对原始SQL进行了改写，因而须要应用扩大SQL失去正确的SQL。 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，并进入官网交换群 数据技术是金融行业数字化转型的重要能源。 近年来，各大银行在全面推动数据技术建设上动作频频。比方，建设银行深入平台经营，依靠数字技术和科技赋能，一直优化“建行惠懂你”APP，2022 年 12 月公开数据显示，APP 累计访问量超过 1.7 亿次，下载量超 2250 万次，授信客户超 165 万户，授信金额超 1.3 万亿元。 此外，工商银行踊跃增强自有平台建设，打造客户服务线上主阵地，放慢服务、场景、经营等方面的翻新，截至去年 6 月末，集体手机银行客户达 4.88 亿户，挪动端月活用户超 1.6 亿户，客户规模与活跃度同业当先。 大银行依靠本身硬件实力与人才劣势，可能疾速实现数字化降级；但对大多数中小金融机构来说，数字化转型显然是件更为简单的事件。 一方面，中小金融机构在数字化实际上的教训绝对欠缺，哪些环节须要革新、哪些环节须要重建，难以精确把握；另一方面，与大多数大机构动辄进行全链路降级不一样，中小金融机构所面临的业务场景更为细分，与其大刀阔斧将本来曾经建设实现的业务链路全系推倒重来，不如聚焦最为外围的业务场景，用“小场景小革新”来得更为理论。 对中小金融机构来说，每一项经营决策的背地都须要投入肯定资源老本，如何能在资源起码的状况下实现经营指标，就成为必须思考的问题。 而其中，引入第三方成熟的数据技术和产品，往往能实现事倍功半的成果。 以最常见的 APP 首页广告投放为例，过来，大多数机构只能依附过往的相似流动数据，来大抵演绎用户对哪一类首页广告更为趣味，并以此作为新一轮流动的借鉴。 但其实这个参考逻辑只有稍加深究，就能觉察出问题。首先是无奈排除单场流动影响的外在因素，比方在参考过往流动数据的过程中，1 月份的流动与 11 月份的流动就可能别离受到元旦假期、双 11 促销流动影响，但这些外在因素仅靠单场的流动积淀数据是无奈体现的；其次，不同流动的主题、性质、目标，甚至是指标人群都不一样，如果对立以一个数字维度来做判断，有失偏颇。 因而，更迷信的参考形式应该是在确定指标定量的根底上，管制外在条件变量，即同时发展 AB 两个试验，同时别离上线两套不同的首页广告，并在此基础上保障包含上线工夫、出现地位等其余“场外因素”统一，以此来在理论场景中观测，哪一版本内容更受用户欢送。 值得注意的是，通过 AB 试验的形式进行测试，往往都是须要在小范畴内圈选肯定用户量级进行，而非一开始就开启全量用户测试，因而可能便捷管制参加试验的用户量，也是中小金融机构在首次尝试这类办法时须要思考的外围性能之一。 目前，火山引擎数智平台推出的 AB 测试 DataTester 曾经被包含金融、批发、互联网、汽车等在内的多个行业广泛应用。 通过 DataTester，企业能够将 AB 两套不同策略同时上线，并在产品内提前完成适用人群全选，被全选的用户将会随机被展示 AB 其中之一的策略，如 APP 新频道入口，A 策略的入口在首页的左上角，B 策略的入口在首页右上角——被随机展示的用户，则能够根据本身的习惯，去发现入口实现频道进入，或间接因不足趣味而疏忽。 通过这样的试验，企业就能够通晓哪一项策略才最受用户欢送，当试验周期完结，积淀出相干数据后，输入策略的部门就能够更好地做出决策，并在全量用户范畴内实现策略上线。 除了 DataTester 之外，火山引擎数智平台目前还全面输入增长剖析 DataFinder、智能洞察 DataWind、增长营销平台 GMP 和客户平台 VeCDP 等系列 SaaS 产品，助力中小金融机构轻量化部署，实现数字化转型过程中的诸多环节难点攻坚。 点击跳转火山引擎数智平台VeDI理解更多 ...

2022 年 10 月，字节跳动 BitSail 数据引擎正式开源。同期，社区推出 Contributor 激励打算第一期，目前已有 12 位开发者为 BitSail 社区做出奉献，成为了首批 BitSail Contributor。 江海的广大是由每一滴水珠形成的，BitSail 社区永远欢送每一位开发者的退出，咱们也想用本人的形式将大家的奉献和心路历程记录下来，所以推出了本档“对话 BitSail Contributor”栏目，为每一位 Contributor 留下与 BitSail 严密相干的独立记录。正因为有你们、有今后更多的 Contributor 存在，BitSail 能力像起名初衷一样，在数据的陆地里以代码做船帆，向无边际的远方怯懦航行。 “对开源的激情始终在驱使我” “我感觉迈出第一步很重要”，明天的这位 Contributor 与 BitSail 社区有着什么样的不解之缘？他对 BitSail 的将来倒退有着什么样的期待？接下来就让咱们一起听听他怎么说~ （PS：本栏目 Contributor 文章排序无前后、奉献大小之分，按内容提交程序进行推送） 社区奉献GitHub ID：https://github.com/aozeyu合并 PR：https://github.com/bytedance/...https://github.com/bytedance/...https://github.com/bytedance/...https://github.com/bytedance/...奉献心得：我程度还没到那种能够实现很简单的 issue 的程度，只能提一些比拟周边的 PR，比方文档上的谬误啥的，通过看 BitSail 的源代码，我深知有些代码须要很大的常识积攒能力看得懂，但我想说的是，不是说我看不懂就不能做奉献，对开源的激情始终在驱使我。我也常常逛 github，看大佬的代码我深信这是我提高须要迈出的一步,看不懂的就百度谷歌哈哈哈。 与 BitSail 结缘过程大略是 11 月的 18,19 号吧,具体哪天我有点忘了，反正是 11 月中旬，我那天上班没事的时候刷了下抖音，正好刷到了字节数据技术部的同学在直播分享 BitSail 开源，据说那是字节第一次分享 BitSail(算蛮侥幸的吧) 字节的同学都很强，分享的内容也很具体和风趣不难堪，听了分享会我感觉 BitSail 这个框架很 nb，因为它反对了包含抖音在内的所有业务线，我想既然这么厉害，抖音每天日活这么多人，它是怎么做到的呢？抱着学习的想法，就关上了 github 的 BitSail 仓库哈哈哈~~ 奉献能源这个问题我感觉是自身本人的学习和对开源的酷爱吧，因为我也是 java 程序员，那为啥字节的同学能写出这么 nb 的框架呢？我要学的货色还有很多，所以抱着学习的想法去看代码。有时我看到源码的时候一头雾水，这个变量是干啥的？这个办法有什么用？ ...

1. DataOps到底是什么？随同着寰球数字化转型的高速倒退，在云计算、物联网、5G、边缘计算、元宇宙等新技术的驱动下，数据爆炸的时代曾经降临。IDC Global DataSphere显示，2021年，寰球数据总量达到了84.5ZB，预计到2026年，寰球结构化与非结构化数据总量将达到221.2ZB。 此外，在《数字化转型架构：方法论和云原生实际》一书中也提到云原生利用平台的倒退将经验DevOps—DataOps—AIOps的演进门路，能够看出在云原生的浪潮下，企业也越来越须要数据。但在面对数据量微小、数据品种繁多、数据急剧增长的窘境时，对企业驾驭数据的能力也提出更高的要求。如果不能对海量数据进行正当有序的组织和治理，非但不能产生数据价值，反而会对企业造成极大的累赘，从某种程度上来说，也是一种“数据劫难”，而这也是DataOps始终处于热门话题的起因。在开源SREWorks我的项目数据化建设过程中，咱们也始终在思考：DataOps到底是在做什么？ 在探讨DataOps之前，咱们先来看下DevOps。DevOps是一种软件交付治理的思维，它谋求一种麻利的、标准的、跨团队的软件研发合作状态，力求将一套软件的开发模式，从小作坊状态演变成一条规范的生产流水线。DevOps在肯定水平上为DataOps的倒退奠定了根底，因而，DevOps是咱们在探讨DataOps时绕不开的重要话题。 DataOps自身也是属于麻利开发领域，相似DevOps以较短的开发迭代周期疾速满足各自的需要，同时DataOps也须要大量标准化数据工具或组件，依赖团队之间合作，进行数据的开发和剖析。与DevOps不同的是DataOps次要专一于数据流，因而，通过数据化的办法或方法论来推动企业经营程度的晋升都能够隶属于DataOps的领域。 DataOps 是 data operationalization的缩写，DataOps 不单单指数据技术的工具和平台，更重要的是一套数据全生命周期治理的方法论和思维。基于数据驱动，通过一系列面向流程的工具和平台，将DataOps思维进行工程化落地实际，可能将所有零碎的相干数据采集起来，突破数据孤岛，对立建设高效标准的数据模型和数据体系，深度开掘数据价值。 DataOps的方法论和思维次要是被剖析和数据团队应用，旨在简化数据应用、升高数据分析门槛，进步数据分析品质、缩短数据分析周期。也就是说，数据作为一种大数据时代的“新能源”，自身是须要通过平台化的能力， 实现围绕“数据集成、数据开发、数据存储、数据治理以及数据服务”等体系化的数据管理流程。更进一步，基于数据驱动的思维，进行数据分析和数据生产，通过数据赋能，做好各个业务畛域的相干工作，真正解决理论生产过程中遇到的痛点问题，实现数据价值落地的场景化输入。 2. DataOps可能解决哪些问题？上面列举一些常见的数据相干的问题，对于想要施行DataOps的公司来讲，能够判断一下是否有遇到： 如何确保生产的数据品质？如何判断生产的数据是否满足业务的需要？如何判断某个数据型我的项目工程的价值并继续投入？如何寻找大数据人才？如何进步数据处理的性能？大数据计划采纳什么技术栈？大数据计划的运维稳定性如何保障？引入了多个大数据计划，如何对立进行治理？大数据的数据权限如何治理？数据分析后果如何领导最终的决策？下面常见的问题，能够归为三大场景：数据管理、数据运维和数据应用。通常施行数据化的公司都是在初期尝到了一些数据带来的苦头，然而在继续投入之后，却又发现这块的收益产出仿佛带有很大的不确定性：数据表逐步地被芜杂的数据堆满，数据产出链路经常提早，而通过数据分析进行决策仿佛也没像之前那么无效了。 简而言之，以后数据质变大，数据工程变简单之后，如果没有标准的体系和流程，整体的协作关系又容易变回小作坊状态，存在诸如数据计算口径不对立、数据反复建设以及数据品质不低等问题，须要寻求一些标准化、规范化、体系化、工程化的形式来进行解决。 3. 如何进行DataOps实际？正如前文所说，DataOps自身是一套残缺的数据体系建设的方法论，其指标是可能让数据继续用起来，实现“数据集成、数据开发、数据存储、数据治理以及数据服务”等数据管理能力。这也意味着须要依赖泛滥的数据技术或数据组件来建设和经营DataOps数据平台，进而造成高效牢靠的数据资产化体系和数据服务化能力，也即针对Data的数据运维。 数据集成数据集成是构建企业级DataOps数据平台的第一步，依赖企业外部的跨部门合作，可能将不同起源的数据（不同的业务零碎）以及不同类型的数据（结构化、半结构化、非结构化、离线以及实时数据等）进行整合，实现互联互通。从源头上防止数据的反复造轮和资源节约问题，为构建规范化的数据体系、积淀数据资产以及开掘数据价值作筹备。 数据集成个别是通过数据引入形式，将一个零碎的数据按时按量集成到另一个零碎中。通常采纳ELT(Extract-Load-Transform，提取-加载-转换)的模式，重点在于数据汇聚，行将数据提取后间接加载到指标端存储中，这个阶段个别不做或者只做简略的数据荡涤和数据处理。业界优良的数据集成工具包含像Sqoop、DataX、Kettle、Canal以及StreamSets等。 数据开发数据开发的指标是可能将数据集成阶段的原始数据，依照业务的需要进行加工解决、将原始的低业务价值的数据转换成高业务价值的数据资产，也就是说数据开发阶段是实现数据资产化的外围技术手段。 数据开发作为数据加工解决的外围阶段，通常会采纳ETL(Extract-Transform-Load，提取-转换-加载)的模式并集成一系列的数据开发管控流程和工具，不便数据开发人员对ETL工作的编写、构建、公布、运维以及工作资源管控等，晋升效率。通常数据开发次要分成离线数据开发和实时数据开发两大场景。 离线数据开发次要用于离线数据的批量定时加工解决，离线数据开发须要蕴含离线计算引擎、作业开发、任务调度、数据管控以及运维监控等外围能力，理论应用过程中，相干的离线ETL工作会依照事后设定的加工逻辑和ETL之间的拓扑依赖关系，进行调度执行。常见的离线解决框架包含MapReduce、Hive以及Spark等。在阿里巴巴外部也早已造成体系的MaxCompute通用大数据开发套件，疾速解决用户的海量数据离线计算问题，无效升高企业老本并保障数据安全等。 实时数据开发次要波及对实时流式数据的加工解决，满足像监控告警、数据大屏等对实时性要求较高的场景。在实时计算场景下，业务零碎每产生一条数据，都会通过消息中间件（比方Kafka）被实时发送到流式解决平台进行加工解决，不再依赖调度引擎。常见的流式解决框架包含Storm、Spark Streaming以及Flink等。在阿里巴巴外部也基于Apache Flink构建了一站式的实时大数据分析平台，提供端到端的亚秒级实时数据加工解决剖析能力。 数据存储有了数据集成和数据开发的能力，下一阶段就是思考如何进行数据存储和数据组织，其外围是标准规范的数据仓库和数据模型建设，也就是说数据仓库是实现数据资产化的出现载体。 目前用的最多的数据建模形式是维度建模，典型代表有阿里巴巴建设的“OneData”数据建模体系，次要包含数据标准定义、数据模型设计以及ETL开发标准三局部。 数据标准定义：数据主题域、业务过程、指标标准、名词定义以及工夫周期等命名标准。 数据模型设计：模型档次划分(分成数据引入层ODS、数据公共层CDM以及数据应用层ADS三层，其中CDM层又包含明细数据层DWD、汇总数据层DWS和维度数据层DIM)、模型设计准则、模型命名标准、模型生命周期治理以及数据品质标准等。 ETL开发标准：数据处理作业的研发流程、编码标准以及公布运维准则等。 数据仓库施行工作流（起源：《大数据之路》） 数据仓库建设工程链路（离线链路+实时链路） 数据治理数据治理次要是对数据资产，配置数据管理策略，次要包含数据规范、数据品质、数据老本以及数据安全等内容。通过多维度进行量化评估，针对数据建设提出改良与优化倡议，确保数据品质、规范、平安、易用。它蕴含以下性能： 数据标准化治理：负责数据仓库中数据的表白、格局以及定义的规范性，包含模型标准、数仓元数据标准、名词术语标准、指标标准等进行治理，针对未标准化的内容提出改良倡议。数据老本：次要从存储量和拜访状况等积淀相干治理项，比方：空表、有效表（未关联ETL工作表）、长期未拜访表、长周期表、大数据量表等，通过对治理项的运作，提出优化倡议，推动数据开发人员进行老本治理。数据品质：围绕数据的完整性、准确性、一致性、有效性和及时性五个维度并对数据的重要性进行资产等级划分，对品质保障既包含事先保障，比方数据开发流程、数据规范执行等，又有事中保障，比方DQC的数据品质实时监控和告警，还有预先保障，比方数据品质故障复盘，确定品质问题根因等。数据安全：评估数据安全危险，对数据设定安全等级，包含反对平安认证和权限治理、资源隔离、数据加密、数据脱敏等，保障数据安全可靠的被传输、存储和应用。数据服务数据服务旨在提供对立的数据生产服务总线，可能将数据资产生成API服务，其指标是把数据服务化，让数据可能疾速集成到业务场景当中，施展数据平台的价值。它蕴含以下次要性能： 异构跨库查问：如果数据分布在多个异构数据库时，用户无奈简略的实现数据关联查问，通过数据查问服务，能够缩小数据同步作业，间接实现从多个源数据库加载数据与实现查问的能力。数据API 定义与治理：部份罕用的数据点查或统计分析，可通过定义数据集与API名称，并最终裸露为一个HTTP资源门路的形式，并对数据API进行公布和拜访受权，不便在各类脚本或代码中应用数据。数据缓存：对于罕用的数据查问，可定义缓存与更新策略，来缩小数据查问穿透到数据库，进步性能并升高对数据库的性能负载。服务编排：依照业务逻辑，以串行、并行和分支等构造编排多个API及函数服务为工作流。数据利用有了标准化的数据体系当前，针对数据进行剖析和应用又是DataOps所关怀的另一个维度的问题，这也是数据驱动的关键环节，也即以数据为核心进行决策，驱动业务行为。数据分析人员利用各种数据统计分析办法和智能算法，通过数据平台提供的数据服务API，对相干数据进行多维度、深层次的剖析开掘，撑持业务相干的数据利用场景，继续让数据用起来，真正施展数据平台的业务价值。 不同的业务有各自的利用场景，所以这一部分很难八面玲珑。本文仅简略介绍几种常见的数据利用场景，心愿能帮忙大家更好的了解，如何基于数据平台的数据资产和数据服务，进行数据分析和应用。 数据大屏：通过对数据进行剖析计算，借助BI类软件，联合业务需要，以图表等模式，把一些要害的汇总性数据展现进去，实现数据可视化，为业务决策提供精确牢靠的数据反对。 智能场景：属于AIOps领域，基于数据平台的数据，通过AI算法，从数据中进行提炼、开掘、洞察，为业务基于数据进行决策和运维经营时提供智能能力，取得更有前瞻性的数据反对。比拟典型的智能利用场景包含像智能举荐、智能客服、智能预测以及衰弱治理等等。 当然，数据分析也并不是数据的起点，因为随着数据的积淀，业务规模的扩充，很多数据分析的后果也可能会作为另一个更高维度模型的数据输出，被纳入数据平台的数据资产当中。因而，数据分析和开发人员须要从一个更高的维度和视角，整合海量的数据--这也就意味着数据处理的链路不是变化无穷的，是在一直随着业务成长的，数据模型也是在一直演进的。 4. 总结总的来说，DataOps 作为一种数据管理形式，利用 DevOps 方法论对数据的全生命周期进行治理，通过数据平台把数据变成一种服务能力，进而晋升数据的应用效率，实现数据继续用起来的指标。 以数据平台为承载，以数据场景为驱动，反对更大的翻新空间和更优良的业务模式。 SREWorks云原生数智运维平台，积淀了阿里大数据运维团队近十年经外部业务锻炼的SRE数智化工程实际，蕴含DataOps在运维畛域的最佳实际，欢送体验。咱们旨在秉承“数据化、智能化”运维思维，帮忙更多的从业者采纳“数智”思维做好运维。 参考资料 https://www.synopsys.com/blog... https://zhuanlan.zhihu.com/p/... http://www.uml.org.cn/bigdata... https://en.wikipedia.org/wiki... https://www.tamr.com/blog/fro...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，并进入官网交换群。在企业竞争加剧的明天，精益开发和麻利迭代已成为产品重要的竞争力。如何保障每一次 Feature 高效迭代与平安，如何疾速实现面对不同用户的精细化经营，成为了产品团队的新挑战。 为了帮忙企业解决此类痛点，火山引擎 DataTester「智能公布」性能应运而生。 「智能公布」是一种联合性能开关+动静配置+灰度公布+配置管理的麻利开发技术，基于先进的 Feature Flag 引擎和一站式配置托管能力，满足利用新性能灰度发版、A/B 试验到全量、人群定向公布等不同利用场景，帮忙开发、产品、运维人员在低危险环境下迭代新 Feature，实现精益麻利开发。 近期，火山引擎 DataTester 对「智能公布」性能进行了全面降级。降级个性如下： 1.一站式实现 A/B 试验+固化 Feature 操作DataTester 此次降级后，A/B 试验创立运行实现后，可将试验参数固化为 Feature 并公布到线上。个别有两种利用场景： 场景 1：A/B 试验得出结论后，有一组试验成果显著较好，即可通过智能经营，将其固化为 Feature 并全量上线。场景 2：A/B 试验暂未得出哪组成果好，但该性能后续会持续摸索，则可先将试验参数固化为一个产品 Feature，间接进行产品治理。 2.Feature 可设置主动公布打算、主动下线、公布管控Feature 若需失效到线上，需公布能力失效。为保障公布安全性、升高上线危险，DataTester「智能公布」提供了灰度公布性能，可管制流量由小到大逐渐放量，放量过程中观测用户反馈和数据指标，若呈现会异样疾速回滚，保障性能平安稳固上线。 同时，Feature 能够反对主动公布打算、主动下线、公布管控；针对公布平安也进行了降级，公布前须要确认变更 Diff 信息， 晋升公布安全性。 主动公布打算Feature 可设置定时主动公布可一键设置公布频率(例：每天公布 20%)主动下线某个版本公布时，可设置到期主动下线到期主动下线后主动回滚到上一个版本公布管控可设置不可操作公布的工夫，比方：非工作日限度不公布3.流程治理：反对自定义差异化公布计划DataTester「智能公布」新性能反对设置不同的 Feature 公布流程，不同的流程可配置不同的环节，不同环节可配置相应具体规定（如审批规定、内测规定等）。 通过对 Feature 流程的差异化治理，能够实现重要性能配置严格的公布流程，紧急 bugfix 配置快捷的公布流程，这样既保障了重要性能上线的谨严，同时又保障了紧急 bugfix 的麻利。 4.白名单测试：反对创立多个白名单测试工作在 A/B 试验正式开启之前，通常会先抉择几名白名单用户进入测试，察看试验是否能失常运行，参加这一步的用户被称为“白名单用户”。在「智能公布」性能降级后，可针对 Feature 同时创立多个白名单测试场景，并行测试多种试验或多个利用细节。 DataTester「智能公布」有诸多用处，其技术实质是按用户指定的规定下发不同的性能参数，以达到麻利公布的应用成果。除了最常见也是应用最广泛的“性能开关”外，还能够实现动静下发“利用配置”“业务配置”“环境配置”“平安配置”等诸多参数的能力。 DataTester 是火山引擎数智平台旗下产品，作为字节跳动外部应用多年的 A/B 测试平台，DataTester 可能深度耦合举荐、广告、搜寻、UI、产品性能等多种业务场景需要，为业务增长、转化、产品迭代，策略优化，经营提效等各个环节提供迷信的决策依据，让业务真正做到数据驱动。 目前，火山引擎 DataTester 曾经服务了美的、失去、凯叔讲故事等在内的上百家标杆客户，将成熟的 " 数据驱动增长 " 教训赋能给各行业。 ...

摘要：本文整顿自阿里云高级技术专家朱翥，在 FFA 核心技术专场的分享。本篇内容是对于在过来的一年中，Apache Flink 对运行时的作业执行管控进行的一些改良。 这些改良，让 Flink 能够更好的利用运行时的信息，来灵便的管制作业的执行，从而使得 Flink 批处理作业的执行能够更加的稳固、更有效率，并且更容易运维。 具体内容次要分为两个局部： 自适应执行打算同源实例的并行执行点击查看直播回放 & 演讲PPT 一、自适应执行打算 咱们先看一下，Flink 是如何形容作业的执行打算的。以这个 DataStream 作业为例，Flink 会基于它学生成一个 StreamGraph。这是一个有向无环图，图中的节点对应着计算逻辑，图中的边则对应着数据的散发形式。 Flink 会依据节点的并行度以及他们之间的连边形式，把一些计算节点进行链接合并，最终造成 JobGraph，从而升高计算节点间的数据传输开销。这个操作的目标是，是为了升高计算节点之间的数据传输开销。StreamGraph 和 JobGraph 都是在编译阶段生成的。JobGraph 会提交给 Flink Job Manager，从而启动和执行作业。 在执行作业前，Flink 会生成 ExecutionGraph。这个 ExecutionGraph 是依据 JobGraph 中的节点并行度，开展生成的。 咱们晓得，Flink 是一个分布式计算框架。而 ExecutionGraph 的每一个节点，都对应着一个须要部署到 TaskManager 上进行执行的工作，每一条边都对应着工作的输出和输入。所以说，它是作业的物理执行打算。 这个物理执行打算，形容了工作的计算逻辑、所需资源和并行度，同时也形容工作产出数据的划分形式，此外还形容了工作对数据的依赖关系以及数据传输方式。 通过它，Flink 就能晓得如何创立和调度作业的所有工作，从而实现作业的执行。 然而，如后面所说，它是在作业运行前就曾经确定的，是动态的。而 Flink 难以在作业执行前，预判什么样的打算参数更正当。所以，这些执行打算参数，只能依赖用户提前指定，也就是须要手动调优。 然而，对于批作业，因为其分阶段执行的个性，在执行一个阶段前，实践上 Flink 是能够取得很多有用的信息的，比方其生产的数据量大小、这些数据的分布模式、以后的可用资源等等。 基于这些信息，咱们能够让 Flink 对执行打算动静的进行调优，从而取得更好的执行效率。并且，因为 Flink 能够主动的进行这些调优，也能够让用户从手动调优中解放出来。 这就是 Flink 批处理作业的自适应执行打算。 为了反对自适应执行打算，最外围的一点，是须要一个能够动静调整的执行拓扑。所以，咱们革新了 ExecutionGraph，使其反对渐进式构建。 具体的来说，就是让 ExecutionGraph 一开始只蕴含 Source 节点，随着执行的推动，再逐步的退出后续的节点和连边。 ...

产品概述咱们不仅仅是数据的搬运工，还是数据搬运过程中加工解决的工厂。咱们不仅仅实用关系型数据库中，还适配当下风行的时序数据库、消息中间件中。etl-engine的核心思想是为用户疾速搭建ETL产品提供解决方案，让用户低代码乃至零代码将ETL产品集成到本人的我的项目或产品生态中。该产品由etl-engine引擎和etl-designer云端设计器及etl-crontab调度组成。etl-engine引擎负责解析ETL配置文件并执行ETL工作；etl-designer云端设计器通过利落拽的形式生成etl-engine引擎可辨认的ETL工作配置文件；etl-crontab调度设计器负责按工夫周期执行指定的ETL工作，及查问ETL工作执行日志性能。 架构图 etl-engine设计器 etl具体日志利用场景异构零碎数据交换传统行业各业务零碎数据绝对独立，随着信息平台一体化、数据中台及大数据时代的推动，要求各业务零碎数据互相交融，业务资源共享。etl-engine反对对关系型数据库、时序数据库等不同媒体进行数据交换。 数据散发网关电商、物联网等畛域在设施上报数据、日志采集、轨迹埋点等场景中从数据接管、再次加工、数据散发、数据格式化存储的要求尤为突出。etl-engine反对kafka、rocketmq、prometheus等多种数据源的接管；反对在接管过程中对数据进行各种转换、荡涤、治理；反对将同一数据源的数据通过再次加工后同时散发到多种指标中。 产品劣势轻量级该产品由Go语言开发，与生俱来的效率高，无需依赖各种动静库、动态库，部署不便，开箱即用，轻量级引擎。配置简略通过云端etl-designer设计器，可视化利落拽形式就能够实现ETL工作的定制化配置工作及调度配置工作。跨平台间接编译成二进制文件，反对跨平台执行（windows、linux、mac），只须要一个可执行文件和一个配置文件就能够运行，无需其它依赖。集成度高etl-crontab调度集成了etl-designer云端设计器，只需运行一个执行文件即取得两个产品性能，反对HTTP/HTTPS协定拜访，为不便用户产品集成，该性能可依据须要独立散发也可集成散发。解析Go脚本etl-engine中任意一个输入节点都能够嵌入go语言脚本并进行解析性运行，实现对输入数据流的格局转换性能。动静配置为满足业务场景须要，etl-engine反对ETL配置文件中应用内部传递的全局变量，实现动静更新ETL配置文件性能。遵循pipeline模型任意一个输出节点能够同任意一个输入节点进行组合；任意一个输出节点都能够通过组合数据流拷贝节点，实现从一个输出同时分支到多个输入的场景；任意一个输入节点都能够嵌入go语言脚本并进行解析，实现对输入数据流的格局转换性能。反对二开反对节点级二次开发，通过配置自定义节点，并在自定义节点中配置go语言脚本，可扩大实现各种性能操作。日志查问反对对etl-engine各节点执行状况的查问性能，不便监控执行轨迹。执行状况报警反对将工作执行失败状况通过HTTP/HTTPS、SMS形式上送报警性能。安全性裸露的服务接口反对HTTPS证书双向认证、Basic Auth认证、Token形式拜访。高可用反对将N个etl-crontab服务端注册到consul服务中心，集成商可通过从consul服务中心发现etl-crontab服务端地址，以实现高可用。 技术指标反对部署模式按原有产品性能前后端集成或前后端拆散部署；按用户个性化需要定制开发部署； 反对操作系统Windows、Linux、Unix、Mac 反对数据源类型文件类型Excel、CSV数据库类型MySQL、PostgreSQL、Oracle、Sqlite、Redis消息中间件Kafka、Rocketmq时序数据库Influxdb、Clickhouse、Prometheus

1 月 8 日下午，由苏州市人民政府领导、中国计算机学会主办、苏州市吴江区人民政府反对，CCF 大数据专家委员会、苏州市吴江区工信局、吴江区东太湖度假区管委会、苏州市吴江区科技局、苏州大学将来迷信与工程学院及 DataFounain 数联众创联结承办的第十六届中国大数据技术大会“AI 大模型技术停顿与挑战”、“数字经济倒退”、“开源数据库”、“数据驱动的 AIGC”、“百度·文心大模型技术赋能产业翻新”五大专题技术与行业系列分论坛同步举办。 本次专题技术与行业系列分论坛由中国移动云能力核心与中国农业银行苏州长三角一体化示范区分行资助单干，通过大会单干社区 DataFountain、LandInn 兰亭、CSDN、SegmentFault 思否以及视频号“今吴江”、“智源社区”、“白海 IDP”、“OCClab”、“PingCAP”、“百度飞桨 PaddlePaddle”同步直播，累计在线观看人次高达 15 万。 十五载耕耘一直 首开“1+X 模式”：专题论坛与分论坛先后落地｜年度高峰论坛行将启动作为大数据畛域极具影响力的行业会议，中国大数据技术大会已胜利举办十五年共十六届。它与数字经济伴生而行，见证了大数据在国内的萌芽、腾飞及其技术生态的日臻完善，已成为国内外大数据技术精英最期待的年度盛会和极具行业实际的业余大数据交流平台。 本次大会邀请中国科学院深圳理工大学计算机科学与管制工程院院长、中国科学院深圳先进技术研究院首席科学家潘毅，苏州大学计算机学院院长、哈工大深圳特聘校长助理张民，CCF 大数据专家委员会副主任、阿里巴巴团体副总裁、阿里云数据库产品事业部负责人、达摩院首席数据库科学家李飞飞负责大会主席，联结数十位行业大咖，独特开启第十六届中国大数据技术大会（简称 BDTC 2022）。 为锁定技术前瞻、摸索发展趋势、增强行业畛域推动、促成产学研用交融、欠缺大数据技术生态，BDTC 2022 首次尝试采纳“以年度高峰论坛为外围，同步开启多个专题论坛与分论坛”的“1+X 模式”，通过与中央高校、企业及政府的紧密结合，深刻调研中央需要，使得 BDTC 主题更聚焦，影响力更强，交换更深——“主动驾驶零碎大数据技术发展趋势与产业化停顿”、“图机器学习”、“企业数据智能”等专题论坛已先后落地合肥、北京、淄博等城市，以“AI 大模型”、“数字经济”、“开源数据”、“AIGC”等数据时代的外围问题与关键技术为关注点的五大分论坛于 2023 年 1 月 8 日以线上直播模式举办。此外，大会主论坛将于2月下旬于苏州市吴江区择期举办。 本次五大分论坛别离邀请了来自国内高校、钻研机构和企业的多位行业专家、学者，独特探讨大数据的外围迷信与技术问题，以深刻开掘大数据蕴藏的微小后劲，进一步减速大数据能量的开释与落地。 以大会聚人才 建“最强朋友圈”：五大分论坛同步启动｜34 位嘉宾思维碰撞“AI 大模型技术停顿与挑战”分论坛：从“大炼模型”到“炼大模型” 挑战与时机并存近年来，人工智能从“大炼模型”过渡到“炼大模型”的阶段，预训练大模型成为了人工智能畛域的钻研热点。一系列大规模语言预训练模型、大规模图文预训练模型、视频预训练模型、特定畛域预训练大模型被先后提出，大幅促成了包含自然语言解决、计算机视觉等畛域的研究进展，并催生了 AIGC 等新兴利用的产生。 “AI 大模型技术停顿与挑战”分论坛由 CCF 大数据专家委员会副秘书长、中国人民大学高瓴人工智能学院副院长窦志成负责主席并主持论坛，北京智源人工智能研究院总工程师林咏华、中国人民大学高瓴人工智能学院执行院长文继荣、百度卓越架构师&百度文心大模型 ERNIE 负责人孙宇、阿里巴巴达摩院高级算法专家周畅、清华大学长聘副教授刘知远、华为云EI高级研究员谢凌曦六位来自学术界和工业界的出名专家、学者别离为大家带来了精彩的学术报告，独特研究 AI 大模型技术倒退路线上的时机与挑战。 “数字经济倒退”分论坛：数据因素崛起 减速数智交融近年来，数字技术减速翻新，日益融入经济社会倒退各畛域全过程，数字经济正在成为重组寰球因素资源、重塑寰球经济构造、扭转寰球竞争格局的重要力量。数字化和智能化技术的倒退，为中国经济社会高质量倒退带来了新机遇和新变动。 “数字经济倒退”分论坛邀请了苏州大学将来迷信与工程学院副院长王进、中国科学院计算技术研究所研究员 &CCF 大数据专家委员会副秘书长靳小龙负责论坛主席并别离就论坛主题发表致辞。中国软件测评核心副主任吴志刚、北京师范大学经济与工商管理学院传授&金融大数据钻研核心主任孙运传、中国人民大学经济学院传授刘小鲁、亨通团体智慧城市事业部总经理王泼、浪潮信息产品计划部首席架构师刘志刚五位行业大咖作为论坛嘉宾，别离围绕数字经济倒退中遇到的理论问题开展了业余分享。 “开源数据库”分论坛：共话开源技术 共建开源生态数字经济时代，数字化转型已是大势所趋，人工智能作为驱动数字化转型的重要技术，对数字经济倒退有着重大而深远的影响。而开源凋谢也越来越成为人工智能倒退的寰球共识，数据开源将在人工智能倒退中施展无足轻重的作用。建设凋谢共享的开源数据库、打造人工智能翻新倒退的良好开源生态，是人工智能基础设施建设的必由之路。 作为“开源数据库”分论坛主席，PingCAP 联结创始人兼 CTO 黄东旭在线发表致辞并进行了主题分享。Head of Infrastructure System Lab ByteDance US 陈建军、Apache Doris PMC Member 李昊鹏、Co-Creator of Databend 张雁飞、阿里云数据库 PolarDB for MySQL 负责人 Jimmy Yang、NebulaGraph 布道师古思为及 NebulaGraph 产品总监方扬等业内专家，联合开源畛域内的具体产品与性能，独特探讨了开源技术的现状与发展前景。 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，并进入官网交换群2023 年的汽车市场，预计能有一个向好的转型。 据中汽协颁布的 2022 年 1-11 月累计汽车销量数据，达到 2430.2 万台，同比增加 3.3%；预计 2023 年汽车总销量能冲破 2760 万台，同比增长 3%——其中，预计 2023 年乘用车销量 2380 万台，同比增长 1.3%；预计商用车销量 380 万台，同比增长 15%；预计新能源车销量 900 万台，同比增长 33%。 对汽车企业来说，近两年汽车市场变动诸多。一方面是钢铁、铜等原材料价格的继续上涨，另一方面，消费者在汽车信息接管方面的习惯也有所扭转。 过来，汽车消费者往往只能通过线上汽车论坛，线下车展、4S 店理解汽车信息，但随着小程序、APP 等私域玩法的衰亡，消费者接触汽车信息时有了更多抉择。 正因如此，汽车企业如果还是抱着原有“期待消费者被动上门”的销售逻辑，将不再具备市场劣势，只有被动将信息触达指标人群，并全链路数字化追踪消费者需要动静，能力抢占市场先机。 但汽车行业的营销场景，如何实现高效数字化？ 过来一年，火山引擎数智平台 VeDI 和领克汽车尝试跑出一套齐备的车企数字化营销计划。 领克汽车，是由吉利汽车、沃尔沃汽车和吉利控股集团合资成立的新时代高端品牌，在过来的多年工夫里，其整体在线用户数约 160 万，车主 60 万，是国内汽车市场的佼佼者。 随同着数字化的迅速倒退，领克汽车开始思考企业数字化营销的模型，但在建设之初，却遇到了不少问题。 首先是底层数据，只管在过来的多年工夫里，领克汽车积淀了一大批用户数据，但数据不足归类和整顿，对于传统的结构化和非结构化数据的存储和计算没有收拢到对立的数据中台中，以至数据没方法被高效调用。 其次，尽管有底层的数据积淀，但上端的数据可视化和数据出现仍然很难做到，对领克汽车而言，其不具备将底层营销数据出现成的业务线索的能力。 除此之外，还有在用户层面的业余经营能力，比方标签、用户分类、精准营销等等，对领克汽车而言，“开始就有点难”。 好在，火山引擎数智平台 VeDI 为其提供了不少帮忙。 总体来说，火山引擎数智平台 VeDI 为领克汽车提供的是一套汇合 APP 征询+客户数据平台 VeCDP+增长营销平台 GMP 的综合解决方案，通过计划的接入，领克汽车能够间接实现从底层数据买通到下层数据利用，再到私域流量转化的全链条通路。 具体来看，客户数据平台 VeCDP 解决的是数据归集和数据出现的难点。即火山引擎的做法是买通数据底层，接入 15 个零碎数据源，彻底解决数据孤岛问题，同时将数据加工成用户标签，实现对用户的精准洞察及用户分群。 而增长营销平台 GMP 则解决的是前端的业务经营难题。即基于火山引擎增长营销平台 GMP，领克汽车能够实现差异化及自动化的用户经营，针对不同人群进行差异化营销。 据此前媒体报道的数据显示，在这项解决方案部署后，领克汽车通过 VeCDP 和 GMP 节俭了超过 70%的流动经营人力老本，流动效率大幅晋升。 ...

近日，火山引擎大数据研发治理套件 DataLeap 通过中国信通院第十五批“可信大数据”测评，在数据管理平台根底能力上取得认证。 “可信大数据”产品能力评测体系由中国信通院发动，是国内首个面向大数据产品的权威评测体系，包含解决方案、根底能力、性能、稳定性等专项评测，笼罩了23类大数据技术产品。 通过多年的倒退 ，“可信大数据”产品能力评测已成为大数据产业倒退的风向标。 本次数据管理平台根底能力测评，包含数据源治理、元数据管理、数据品质治理、数据规范治理、数据共享服务治理、数据安全治理、兼容性测试与平安测试等多项测试用例，火山引擎大数据研发治理套件 DataLeap在此次测评中全副通过，体现优异。 此前， DataLeap 曾经通过中国信通院第十三批“可信大数据”数据集成工具根底能力和数据开发平台根底能力测评。 图注：第十五批“可信大数据”数据管理平台根底能力专项测评证书 大数据研发治理套件DataLeap，是火山引擎数智平台VeDI旗下的PaaS层产品。自2021年12月Dataleap私有云版上线至今，已为泛滥企业提供了数据集成、开发、运维、治理、资产、平安等数据中台解决方案，帮忙企业晋升数据研发效率，升高运维治理老本。 以失去APP为例，该企业通过引入DataLeap，在数据基建能力以及治理办法上晋升其数字化能力。据失去团队介绍，DataLeap开释了失去技术团队在繁多的开源组件和零碎自研上投入的研发资源和人力，并通过先进的治理工具和配套的价值交付，帮助失去建设了可继续的数据治理方法论，将失去整体的数据治理能力跃进了3年程度。 除了继续摸索利用场景，DataLeap更在进一步晋升产品能力、翻新治理理念。在数据治理环节上，DataLeap提供了事先预警、事中解决、预先复盘及举荐优化的全生命周期的数据治理能力，具备了数据中台建设和管理所需的各个功能模块。DataLeap还翻新提出了分布式数据治理模式，该模式具备建设周期短，业务影响小，适配能力强，治理成果低等长处。 不仅能实现各级业务及集体的自驱治理，还能充沛依据业务阶段来制订治理的内容。各个模块均可独立应用分布式治理模式，这让数据治理对业务的冲击和影响能够尽可能最小化。 通过DataLeap的分布式治理能力，业余的治理常识能够积淀下来，实现产品化协同，并联合智能化举荐性能，为企业晋升执行效率。将来，火山引擎大数据研发治理套件DataLeap将更好地提供一站式大数据研发治理服务，助力行业开掘数据价值、为企业决策提供数据撑持。 点击跳转大数据研发治理套件 DataLeap理解更多

导读：DataTester是由火山引擎推出的A/B测试平台，笼罩举荐、广告、搜寻、UI、产品性能等业务利用场景，提供从A/B实验设计、试验创立、指标计算、统计分析到最终评估上线等贯通整个A/B试验生命周期的服务。 DataTester通过了字节跳动业务的多年打磨，在字节外部已累计实现150万次A/B试验，在内部也利用到了多个行业畛域。指标查问的产品高性能是DataTester的一大劣势。作为产品最简单的功能模块之一，DataTester的指标查问可能在无限资源的前提下，施展出最极致的A/B试验数据查问体验，而在这背地是屡次的技术计划的打磨与迭代。 本文将分享DataTester在查问性能晋升过程中的5个优化思路。 01 现状及问题挑战 1：版本治理试验指标报告页是DataTester零碎最外围的性能之一，报告页的应用体验间接决定了DataTester作为数据增长和试验评估引擎在业界的竞争力。该性能具备以下特点：① 株连零碎多、链路长：报告页波及到控制台（Console）、科学计算模块、查问引擎、OLAP存储引擎。整个链路包含了：DSL到sql转化、后端查问后果缓存解决、查问后果的加工计算、前端查问接口的组装和数据渲染。② 实现简单：试验指标有多种算子，在查问引擎侧中都有一套定制SQL，通过DSL将算子转换成SQL。这是DataTester中最简单的功能模块之一。 02优化思路从一条SQL说起。举一个例子，在DataTester中一次AB测试的查问分三局部逻辑。① 实时扫描事件表，做过滤② 依据用户首次进组工夫过滤出用户③ 做聚合运算须要查问具体的SQL代码，也能够点击开展查看详情。 printf("hello world!");SELECT event_date, count(DISTINCT uc1) AS uv, sum(value) AS sum_value, sum(pow(value, 2)) AS sum_value_squareFROM (SELECT uc1, event_date, count(s) AS value FROM (SELECT hash_uid AS uc1, TIME, server_time, event, event_date, TIME AS s FROM rangers.tob_apps_all et WHERE tea_app_id = 249532 AND ((event = 'purchase')) AND (event_date >= '2021-05-10' AND event_date <= '2021-05-19' AND multiIf(server_time < 1609948800, server_time, TIME > 2000000000, toUInt32(TIME / 1000), TIME) >= 1620576000 AND multiIf(server_time < 1609948800, server_time, TIME > 2000000000, toUInt32(TIME / 1000), TIME) <= 1621439999) AND (event in ('rangers_push_send', 'rangers_push_workflow') OR ifNull(string_params{'$inactive'},'null')!='true') ) et GLOBAL ANY INNER JOIN (SELECT min(multiIf(server_time < 1609948800, server_time, TIME > 2000000000, toUInt32(TIME / 1000), TIME)) AS first_time, hash_uid AS uc2 FROM rangers.tob_apps_all et WHERE tea_app_id = 249532 AND arraySetCheck(ab_version, (29282)) AND event_date >= '2021-05-10' AND event_date <= '2021-05-19' AND multiIf(server_time < 1609948800, server_time, TIME > 2000000000, toUInt32(TIME / 1000), TIME) >= 1620651351 AND multiIf(server_time < 1609948800, server_time, TIME > 2000000000, toUInt32(TIME / 1000), TIME) <= 1621439999 AND (event in ('rangers_push_send', 'rangers_push_workflow') OR ifNull(string_params{'$inactive'},'null')!='true') GROUP BY uc2) tab ON et.uc1=tab.uc2 WHERE multiIf(server_time < 1609948800, server_time, TIME > 2000000000, toUInt32(TIME / 1000), TIME)>=first_time AND first_time>0 GROUP BY uc1, event_date)GROUP BY event_dateDataTester底层OLAP引擎采纳的是clickhouse，依据clickhouse引擎的特点，次要有两个优化方向：① 缩小clickhouse的join，因为clickhouse最善于的是单表查问和多维度剖析，如果做一些轻量级聚合把后果做到单表上，性能能够极大晋升。也就是把join提前到数据构建阶段，构建好的数据就是join好的数据。② 须要join的场景，则通过减小右表大小来减速查问。因为join的时候会把右表拉到本地构建hash表，所以必然会占用大量内存，影响性能。 ...

12月27日,阿里云正式公布云原生开源大数据平台EMR 2.0，降级后的开源大数据平台在老本持平的状况下，扩缩容性能最高可晋升6倍。 据悉，阿里云EMR2.0为用户提供了全新的平台、开发、资源状态、剖析场景等更优的产品体验，通过EMR Doctor健康检查、全面的服务巡检和事件告诉、节点故障弥补等运维能力的降级，预估运维老本可升高20%-30%。新平台致力于为客户疾速构建高性价比、安全可靠、兼容生态的开源大数据平台。 EMR2.0与EMR1.0弹性扩容速度比照 云原生趋势下，开源大数据处于重构之中，以 Hadoop 为外围的开源大数据体系，开始转变为多元化技术并行倒退。阿里云EMR产品负责人何源介绍， 阿里云EMR于2009年开始服务阿里巴巴团体外部客户，2016年将过往的技术能力产品化凋谢，为客户提供商业化服务。作为开源大数据畛域的引领产品，EMR 2.0通过云原生能力重构平台层、数据层、计算层，满足数千客户流解决、数据可视化、交互式剖析、数据湖等多场景需要，从新定义了新一代开源大数据平台。为客户构建新一代开源大数据基础设施。 EMR 2.0产品架构图 客户基于EMR2.0平台可实现更加低成本、高效率、智能化的大数据集群管控和利用开发。通过应用抢占式实例，生产实证最多可升高百分之八十以上的老本。开启故障实例主动弥补，在全场景集群下，稳定性能够进步1个9。全新公布的EMR Doctor，通过健康检查服务的集群日报性能，查看集群是否存在资源节约；通过工作评分倒排Top N，找到资源节约最多的作业进行优化；通过继续优化，帮忙客户最大化利用资源，避免浪费。同时，还能够帮忙客户提前发现一些危险并进行解决。EMR Studio，提供Notebook和Workflow服务。全托管Notebook，兼容 用户Jupyter应用习惯，能够无缝对接EMR各计算、存储引擎，进行交互式的大数据开发和调试，曾经开发和调试完的作业能够退出Workflow工作流里进行调度和上线。此外EMR Studio的Workflow服务也还反对Flink等的作业。 2022年6月，阿里云EMR联结 OSS、 DLF、DataWorks等构建的云原生数据湖产品计划通过信通院评测认证，是国内首批且惟一满分的产品计划，该计划为用户提供“全托管湖存储、全面湖减速、对立湖治理、多模态湖计算和智能湖治理”等全面数据湖能力。（国内首批！阿里云云原生数据湖产品通过信通院评测认证） 国内出名广告营销服务商汇量科技已应用EMR产品4年。在业务快速增长的大好形势下，汇量科技面临越来越多的困扰：如数据起源简单、数据量大、数据维度多、实时经营业务秒级数据新鲜度需要等业务需要；本次降级后，汇量科技在素材平台、热力引擎等业务的大数据平台搭建上，数据同步和及查问效率有数倍晋升，零碎稳定性显著晋升，未再呈现之前cpu、mem、io负载低等状况。 随着阿里云EMR2.0的公布，阿里云EMR将技术引领劣势，转化为云上产品服务能力。从新定义的新一代 EMR 产品，将为各行业广大客户构建开源大数据平台提供最扎实的基座保障。

前几天把跨年搞的和人生分水岭似的 那么，2023年的你有什么不一样了吗？ 是不是还和去年一样的造型？新姿态，学起来！ 腾讯云开发者社区带着干货来了，腾讯云×尚硅谷大数据研究院强强联手，重磅推出新年第一弹： 腾讯云EMR数仓教程公布 腾讯云开发者社区“公开课”中转： 腾讯云开发者公开课 - 腾讯云开发者社区-腾讯云 这套教程由腾讯云官网与尚硅谷大数据研究院联合推出，分为实时及离线两局部。 实时数仓依靠国内电商巨头的实在业务场景，基于各大互联网企业对于腾讯云EMR架构体系的需要，将整个电商的实时数据仓库体系搭建在腾讯云架构上。教程全方面实现了整个实时数据仓库架构的海量数据采集、存储、计算以及可视化展现，整个业务流程全副搭建在腾讯云服务器上，并全副采纳腾讯云EMR的服务组件，将各EMR服务组件进行充沛联动。 离线数仓则基于腾讯云EMR平台买通数据采集通道，从数仓建模到逐层构建离线数仓，领有残缺的数仓建模实践及建模过程，且在构建过程中采纳了EMR平台组件和原生组件相结合的形式，让企业在组件抉择上更加灵便。 我的项目文档依照出书规范编写，具体解说一行一行手敲代码，内容全面且粗疏，教程附赠全套视频、文档、代码、材料。通过本套教程的学习，你能够全方位把握腾讯云的大数据服务组件应用和调优！ 【教程简介】 实时数仓课程介绍 离线数仓课程介绍 在“腾讯云开发者”公众号发送“数仓建设” 或扫码退出“腾讯云大数据EMR交换群”收费获取全套教程，群内提供腾讯云官网大数据团队导师全程领导及技术交换 【教程目录】 实时数仓： 001.腾讯云EMR实时数仓教程简介 002.需要及架构-简介 003.需要及架构-课程目标 004.需要及架构-数据仓库概念 005.需要及架构-我的项目需要 006.需要及架构-技术选型 007.需要及架构-数据流程设计 008.需要及架构-框架的版本选型 009.需要及架构-服务器选型 010.需要及架构-集群规模及集群布局 011.需要及架构-电商业务简介 012.需要及架构-EMR的购买与启动 013.需要及架构-EMR集群简略阐明 014.需要及架构-应用XShell连贯服务 015.需要及架构-批改主机映射&配置无密登录 016.需要及架构-电商业务数据阐明 017.需要及架构-上传材料包 018.需要及架构-MySQL的装置与启动 019.需要及架构-MySQL批改明码&近程拜访 020.需要及架构-生成业务数据 021.需要及架构-Kafka装置 022.需要及架构-Kafka配置环境变量&群起 023.需要及架构-同步策略&开启MySQL Binlog 024.需要及架构-Flink装置 025.需要及架构-我的项目构建 026.需要及架构-FlinkCDC代码解说&本地测试 027.需要及架构-FlinkCDC代码近程测试 028.实时数仓搭建-课程介绍 029.实时数仓搭建-分层框架-ODS&DIM层 030.实时数仓搭建-DWD&DWS&ADS层 031.实时数仓搭建-架构剖析 032.实时数仓搭建-筹备工作 033.实时数仓搭建-具体工作 034.实时数仓搭建-HBase部署 035.实时数仓搭建-HBase启动&测试 036.实时数仓搭建-IDEA代码环境阐明 037.实时数仓搭建-Phoenix部署 038.实时数仓搭建-Phoenix启动 039.实时数仓搭建-Redis部署 040.实时数仓搭建-Redis启动&测试 041.实时数仓搭建-ClickHouse装置&启动&测试 042.实时数仓搭建-课程阐明 043.实时数仓搭建-DIM层-思路剖析 1 044.实时数仓搭建-DIM层-思路剖析 2 045.实时数仓搭建-DIM层-思路剖析 3 046.实时数仓搭建-DIM层-思路整顿 047.实时数仓搭建-DIM层-生产&过滤&转换数据 048.实时数仓搭建-DIM层-配置信息表 ...

DAG 介绍DataLeap 是火山引擎自研的一站式大数据中台解决方案，集数据集成、开发、运维、治理、资产治理能力于一身的大数据研发治理套件。在平台中，一个外围的性能为工作的调度，会依据工作设置的调度频率（月级，日级，小时级等）运行工作，从而生成对应的实例。 在数仓研发中，不同的表之间会存在依赖关系，而产生表数据的工作实例，也会因而存在依赖关系。只有在上游实例运行胜利、上游实例达到设定的运行工夫且资源短缺的状况下，上游实例才会开始执行。所以，在日常的工作运维中，经常须要剖析实例上下游的运行状况，依据具体的状况对实例进行置胜利、重跑等操作。 而如何清晰地展现实例之间的关系，帮忙用户疾速地剖析整个链路的运行状况，并实现问题定位和运维操作，则是实例 DAG 须要解决的问题。上面比照下优化前后的成果。 优化前：能够看到在简单链路中，将所有节点的关系全副展现进去，导致连线凌乱，须要通过不停的拖拽、缩放，能力找到没有执行的上游节点。 优化后：通过采纳了将节点聚合的模式，简洁地展现上下游关系。同时，采纳了将实例状态进行分类的模式，提供快捷操作的按钮，让用户能够只关注特定状态的实例，缩小了无用信息对用户运维操作的烦扰。上面将具体介绍优化的整体过程。 概念1.工作：在 DataLeap 数据研发平台中，对数据执行一系列操作的定义。2.实例：通过工作配置的执行频率（月级、天级等）而创立的一个工作的快照。3.DAG：全称为 Directed Acyclic Graph，指有向无环图，具备紧密的拓扑性质，有很强的流程表达能力。4.DAG 布局：指依据有向无环图中边的方向，主动计算节点层级和地位的布局算法。 业务场景以其中一个场景为例：对于工作 test_3 在 2022-09-29 的实例进行剖析可知。以后实例没有运行，是因为上游工作 test_2 在 2022-09-29 的实例运行失败导致的，那么此时可分割上游实例对应的工作的负责人，对实例进行解决（包含但不限于重跑，置胜利等操作）。 问题在以后的实例 DAG 图中，用户在理论应用中会碰到如下问题：1.简单的实例 DAG 图无奈渲染。在一些业务方向中，会呈现 DAG 图中有几千节点。因为数据处理的简单和采纳了 svg 的渲染计划，经常会导致前端浏览器的解体。2.同层级节点过多，操作艰难。 以下图为例，在剖析上游实例中，是哪个实例没有运行，导致以后实例没有执行时，须要通过间断拖拽，能力定位到关注的上游实例。3.查看节点依赖时，只能一直开展，在对不同的上游依赖进行开展时，会导致图展现凌乱。 需要剖析在通过用户调研及应用过程中发现，应用 DAG 进行剖析时次要有以下场景：1.以后实例曾经达到指定运行工夫，然而没有运行。在这种状况下，用户关注的是上游没有运行的实例 / 运行失败的实例，分割上游实例的责任人进行问题定位。2.当实例曾经运行胜利，然而实现工夫比失常状况下有提早。 在这种状况下，用户关注的是上游实例中，最晚实现的实例。从而判断是否对链路进行治理优化。3.当实例运行失败，导致上游没有运行。在这种状况下，用户关注的是依赖以后实例的所有上游实例，同时须要对上游实例进行聚合筛选，比方工作的优先级（代表工作的外围水平），以告诉上游实例进行重跑等操作。 联合下面存在的问题可失去，次要起因是因为在简单链路状况下，上述需要比拟难满足。而在旧版的 DAG 中，针对简略链路和简单链路的解决是统一的，为此，咱们须要设计解决简单链路场景下的计划。 功能设计针对下面存在的问题以及对需要的剖析，咱们能够进行如下的性能实现与设计： 渲染计划替换将 svg 的渲染计划替换成 canvas 渲染，通过缩小页面中 DOM 的数量，进步前端渲染性能。 不同场景的功能设计通过下面的需要剖析，咱们设计了不同的性能模式以满足不同的需要。 通用模式在通用模式中，用户关注的是节点上下游的关系，在简单链路中疾速找到阻塞节点，同时关注阻塞节点的信息。 针对简单链路，咱们设计了多种优化模式：首先，在同一层的节点超过肯定的数量（可自定义）后，所有节点将聚合在一起，咱们称之为聚合节点。这种优化下，能够解决下面提到的因为同一层级节点过多，查找特定状态节点不便的问题。也反对点击聚合详情，通过列表的模式，查看所有被聚合的节点。并反对筛选，疾速查找到关注的节点并通过开展，复原与以后节点的依赖关系。 其次，以用户最关注的实例状态，对被聚合的节点进行分类，同时新增快捷开展操作。以下图为例，以后实例处于期待上游依赖实现状态，在这种状况下，用户关注的，则是上游没有开始执行的节点。在聚合节点中，能够清晰地看到存在一个实例，是在期待执行的，点击数字1，即可疾速开展实例。 在这个例子中，就将不须要关注的上游胜利节点暗藏在列表中，突出图所须要关注的重点信息。 同时，为了升高节点展现过多导致图显示芜杂的状况，新增了收起性能及跳转性能。 收起性能是指在通过在聚合节点开展的节点的状况，或是在间接开展上 / 上游的状况下，都反对对某个上游 / 上游节点的整条链路收起，不便用户在浏览完一条链路后，复原图之前的状态，持续浏览下一条链路，缩小对后续剖析的烦扰。 跳转性能是在查看以后节点的上游的其余上游，或是上游的其余上游，此时，用户关注的节点曾经转化为其余的上游 / 上游节点。所以，通过跳转新页面的模式，将须要关注的不同节点的上 / 上游信息辨别开，缩小在一张图中展现所有信息。 ...

外围概念整个SeaTunnel设计的外围是利用设计模式中的管制翻转或者叫依赖注入，次要概括为以下两点： 下层不依赖底层，两者都依赖形象流程代码与业务逻辑应该拆散对于整个数据处理过程，大抵能够分为以下几个流程：输出 -> 转换 -> 输入，对于更简单的数据处理，本质上也是这几种行为的组合： 内核原理SeaTunnel将数据处理的各种行为形象成Plugin，并应用SPI技术进行动静注册，设计思路保障了框架的灵便扩大，在以上实践根底上，数据的转换与解决还须要做对立的形象，譬如比拟有名异构数据源同步工具DataX，也同样对数据单条记录做了对立形象。 在SeaTunnel V1架构体系中，因为背靠Spark和Flink两大分布式计算框架，框架曾经为咱们做好了数据源形象的工作，Flink的DataStream、Spark的DataFrame曾经是对接入数据源的高度形象，在此基础上咱们只须要在插件中解决这些数据抽象即可，同时借助于Flink和Spark提供的SQL接口，还能够将每一次解决完的数据注册成表，不便用SQL进行解决，缩小代码的开发量。 实际上SeaTunnel最初的目标是主动生成一个Spark或者一个Flink作业，并提交到集群中运行。 SeaTunnel连接器V1 API解析架构概览目前在我的项目dev分支下，SeaTunnel连接器V1 API所在的模块如图所示： seatunnel-api-base：根底API层形象seatunnel-api-flink：Flink引擎API层形象seatunnel-api-spark：Spark引擎API层形象seatunnel-api-base在根底模块中，有以下代码： 为了更清晰的了解这些类之间的关系，笔者这里制作了一张简略的UML类图： 整个API的组成能够大体分为三局部： 插件层：提供Source、Transform、Sink插件定义执行层：提供执行器和运行上下文定义构建层：提供命令行接口定义构建层接管命令参数构建执行器，执行器初始化上下文，上下文注册插件并启动插件，至此，整个作业开始运行。 seatunnel-api-spark在Spark引擎API层有以下代码： 同样，笔者也整顿了一张UML类图来示意它们之间的关系： 整个流程与Base模块统一，在这里笔者不过多赘述，有趣味的读者能够自行观看源码。 seatunnel-api-flink在Flink引擎API层有以下代码： 同样，笔者也整顿了一张UML类图来示意它们之间的关系： 整个流程与Base模块统一，在这里笔者不过多赘述，有趣味的读者能够自行观看源码。 SeaTunnel连接器V1运行原理启动器模块概览整个我的项目的最外层的启动类都放在以下模块中： 跟连接器V1无关的模块如下： seatunnel-core-base：V1根底启动模块seatunnel-core-flink：V1flink引擎启动模块seatunnel-core-flink-sql：V1flink-sql引擎启动模块seatunnel-core-spark：V1spark引擎启动模块执行流程为了更好的了解SeaTunnel V1的启动流程，笔者在这里制作了一张简略的时序图： 程序最外层的启动由start-seatunnel-${engine}.sh开始，用户依据将配置文件从脚本传入，脚本调用org.apache.seatunnel.core.spark.SparkStarter或者org.apache.seatunnel.core.flink.FlinkStarter，实际上这个类只做一个工作：将所有参数拼接成spark-submit或者flink命令，而后脚本接管到spark-submit或者flink命令并提交到集群中；提交到集群中真正执行job的类实际上是org.apache.seatunnel.spark.SeatunnelSpark或是org.apache.seatunnel.flink.SeatunnelFlink，读者如果想间接深刻理解作业启动外围流程的话举荐浏览这两个类的源码。 执行原理SparkSparkSource插件将异构数据源接入为DataFrameSparkTransform插件将SparkSource接入的DataFrame进行转换解决SparkSink插件将SparkTransform解决好的DataFrame写入到指标数据源FlinkFlinkSource插件将异构数据源接入为DataStreamFlinkTransform插件将FlinkSource接入的DataStream进行转换解决SparkSink插件将FlinkTransform解决好的DataStream写入指标数据源SeaTunnel连接器V2 API解析架构概览目前在我的项目dev分支下，SeaTunnel连接器V2 API所在的模块如图所示： seatunnel-api：连接器V2所有的API定义数据抽象SeaTunnel连接器V2 API在数据层面做了形象，定义了本人的数据类型，这是与连接器V1最大的不同点，连接器V1应用的是引擎数据抽象的能力，然而连接器V2本人提供的这个异构数据源对立的能力： 在所有的Source连接器和Sink连接器中，解决的都是SeaTunnelRow类型数据，同时SeaTunnel也对内设置了数据类型标准，所有通过Source接入进来的数据会被对应的连接器转化为SeaTunnelRow送到上游。 API Common在API common包下有以下接口的定义： 在这里因为篇幅关系只介绍比拟外围的几个接口： PluginIdentifierInterface：插件惟一标识SeaTunnelContext：SeaTunnel利用上下文，每个SeaTunnel Job蕴含的上下文对象，保留了以后源表的元数据SeaTunnelPluginLifeCycle：插件申明周期具体接口中有哪些办法读者能够自行浏览对应类的源码，在这里笔者将不过多赘述。 API Source在API source包下有以下接口的定义： 在这里因为篇幅关系只介绍比拟外围的几个接口： Boundedness：标识数据有界无界，连接器V2设计理念基于批流一体，此接口用于区分流式作业还是批式作业Collector：数据收集器，用于收集Source连接器产生的数据并推往上游SeaTunnelSource：Source插件基类，所有的Source连接器主类均继承于这个接口SourceReader：Source插件真正解决数据接入的接口SourceSplit：数据分片接口，连接器V2反对数据并行读入，晋升数据接入效率SourceSplitEnumerator：数据分片器，此接口用于散发数据分片至对应的SourceReader中API Sink在API sink包下有以下接口的定义： 在这里因为篇幅关系只介绍比拟外围的几个接口： SeaTunnelSink：Sink插件基类，所有的Sink连接器均继承于这个接口SinkWriter：Sink插件真正实现数据输入的接口SinkCommitter：用于解决SinkWriter#prepareCommit返回的数据信息，蕴含须要提交的事务信息，连接器V2在Sink设计上提供二阶段提交的接口，从而使连接器有了实现Exactly-Once的可能性SinkAggregatedCommitter：用于解决SinkWriter#prepareCommit返回的数据信息，蕴含须要提交的事务信息等，用于在单节点多任务一起提交事务信息，这样能够防止提交阶段二局部失败导致状态不统一的问题（注：在实现连接器时优先实现这个接口，这样会兼容性更强）小结 连接器V2在架构分层上与计算引擎进行解耦，定义了本人的元数据定义以及数据类型定义，在API层和计算引擎层减少了翻译层，将SeaTunnel自定义的数据源通过翻译层接入到引擎中，从而真正实现接口和引擎拆散的目标。 SeaTunnel连接器V2运行原理启动器模块概览整个我的项目的最外层的启动类都放在以下模块中： 跟连接器V2无关的模块如下： ...

本期名人堂咱们有幸邀请到了Alluxio开创成员兼开源社区副总裁范斌学生。范斌学生讲述了本人的求学、工作、退出开源社区的经验，以及对将来十年数据编排倒退的瞻望，和对开发贡献者的一些倡议。 问题 1：范斌老师您好，很荣幸有机会采访到您，请先介绍一下您本人？大家好，我是Alluxio的开创工程师以及开源社区副总裁（VP of Open Source）。我本科毕业于中科大计算机系，随后别离在香港中文大学计算机科学工程系和卡内基梅隆大学计算机系获得硕士和博士学位。博士期间我在分布式系统算法和零碎实现等方向发表多篇包含SIGCOMM, SOSP, NSDI等顶级国内会议论文，包含提出了Cuckoo Filter算法。退出Alluxio前, 我在Google从事下一代大规模分布式存储系统的钻研与开发。 问题 2：您从大学本科到博士都是学的计算机专业，而且横跨了大陆、香港和美国三地，为什么会这么着迷于计算机呢？我算是从很小的时候就开始接触计算机了。小学三年级的时候，我加入了学校组织的计算机兴趣班，系统地学习了BASIC语言编程。我至今仍记得在老师领导下，编写的第一个BASIC程序“打印画布”，实现在电脑屏幕上重复输入同一个符号“#”，如同在一匹布上打印出难看的花纹。过后我一下子就被这个程序迷住了，感觉编写计算机程序，依照本人的想法去做这样或那样乏味的事件切实太好玩了。这就是我入门的经验，从此就十分分心地开始学习计算机程序设计。 小时候我只是感觉计算机是一个有意思的玩具，能够打游戏也能够编写游戏。念完大学、读完博士当前，十分粗浅地意识到这是一个十分了不起的行业，它粗浅的扭转了整个人类社会的运行形式，所以我很骄傲始终投身在计算机科学行业当中。 问题 3：在CS畛域TOP4的卡内基梅隆大学计算机系攻读计算机博士是什么体验？对退出Alluxio开源我的项目和守业公司有什么影响？我在2007年进入了卡内基梅隆大学攻读计算机博士学位，方向是分布式系统，次要是分布式网络系统和分布式存储系统等课题。这一期间，我十分有幸能和很多世界级的专家、学者以及一流的同学一起共事，这个贵重的经验使得我的业余程度以及对畛域的意识都失去了相当大的晋升。特地是让我近距离察看到最优良的学者是如何意识问题、钻研问题和解决问题的。咱们过后具体解决了什么问题可能绝对没有那么重要，而要害是播种了一套方法论，这样前面再做很多相似的事件都会十分得心应手，能够说这是我在整个博士阶段最大的收益之一。 因为同样做的是计算机分布式系统的一些钻研，所以我去加州大学伯克利分校拜访的时候，意识了过后正在那里攻读博士学位的李浩源博士。过后他的博士我的项目就是Tachyon，起初改名叫做Alluxio。也是因为这样的机缘，起初我就抉择从Google到职退出这家守业公司。 问题 4：您博士毕业后即进入谷歌并在外围存储基础设施团队负责构建散布存储系统的开发，这段经验有什么样的播种？我在攻读博士期间学习和养成了一套好的办法来钻研和解决一些零碎难题，但真正的工程实际能力还没有失去最好的锤炼。这是因为这一时期作为一个博士生我专一指标是发表好的论文。而为这些论文写的代码也就是俗称的钻研代码(research code)，谋求的是把一些好的想法疾速实现原型，展示给同行看，但并不要求达到生产规范（production ready）。这是从学校里做零碎钻研的一个常见问题。你也能够了解为学术界和工业界的分工是不一样的。 我在退出谷歌工作的两年里最大的播种是拓宽了视线以及造就了良好的工程习惯。我始终感觉Google就像是计算机江湖里的少林寺，整个大数据以及AI畛域里的各种各样的技术，其实很大一部分最早都是发祥于Google的。在这样的平台，你能够见证很多技术的倒退脉络，并提前五到十年看到下一个时代的技术趋势。这个对于宽阔我的眼界是十分有帮忙的。 问题 5：作为Alluxio最早的初创者，为什么会抉择退出Alluxio？有哪些吸引你的中央？比照谷歌这样的大厂光环，你怎么对待退出startup公司可能带给你的播种？其实我在卡内基梅隆大学念博士的时候就立下了一个信心，会去参加一个初创公司。我始终就没有什么大厂情节，始终感觉在小公司尤其是初创公司外面做事会更乏味，节奏更快，更有挑战性。对我来说， 我只是始终在等一个适合的机会，可能找到一个我喜爱并违心为之付出的团队和我的项目。 问题 6：Alluxio起源于开源我的项目，目前逐步商业化，在越来越多的行业被客户认可并应用，是否能够举几个典型例子，Alluxio如何给客户带来微小价值？这是一个十分好的问题，我在不同的客户环境下会看到大家应用Alluxio的不同办法。不过总体而言，大部分用例都是通过更快的把数据出现给计算，帮忙客户更高效地治理、应用数据，使他们可能更快的从数据之中开掘价值。举个例子，比如说在中国联通这样的场景下，通过应用Alluxio能够使他们对于相似Spark这样的工作环境有更好的数据管理成果，以及更好的数据输入速度。这样就能够使中国联通大数据平台上的工程师更有效率地实现他们的工作内容，同时更疾速的去迭代算法的开发以及一些不同业务逻辑的开发。这带来的是生产效率的微小晋升。再比方新加坡的星展银行，东南亚最大的银行之一，他们有一些要害的业务跑在Alluxio之上。以上例子都表明了咱们所提供的这套数据服务对咱们宽广用户的微小价值。如果这套服务出了问题，不工作了，那给相干企业带来的麻烦也是微小甚至是致命的。正因如此，我感觉咱们的工作责任重大，同时也对咱们的成就十分骄傲。 问题 7：展望未来十年，您感觉数据编排将在整个大数据畛域表演什么样的角色？我感觉数据编排会成为一个默认的数据层。无论什么时候，不管你是想获取数据，还是想要做大量的数据处理和计算，你都会习惯于从数据编排这层提取数据。它会成为一个大家默认的数据层，也会成为工业界外面的一层工业规范。有了这层规范之后，提供计算的厂商和用户都能够轻松自如地做他们想要做的事件，而不必去关怀具体的数据是怎么取得的，或者它是在一个什么样的服务里边怎么设置的。届时，这种绝对底层或是比拟繁琐的事件就交给数据编排层去解决了，我感觉这会是生产力的一个微小的提高，会让社会的生产效率达到一个更高的层面。 问题 8：作为Alluxio开源社区的PMC Co-chair对开源社区倒退有何冀望？有哪些想对开发奉献小伙伴们说的话，您有什么tips能够让大家疾速的玩转开源社区吗？好的，首先十分欢送大家退出Alluxio开源社区。我在读博士的时候就曾经做了一些我的项目，而后开源了进去，但过后并没有意识到这其实只是开源的程序，一个源代码并不是真正的开源社区。开源社区是人和人之间的组织，社区内的人和人之间会有很多流动和分割，而开源某个我的项目仅仅是把你的代码放到Github上或者是相似的服务上托管进来，和真正去做开源社区有很大的不同。 我作为Alluxio开源社区的co-chair，我的工作是如何把这个社区里的用户、代码批改的贡献者以及有能力去做整个我的项目演进的资深开发者很好的组织起来，使大家都能各取所需，并在我的项目中充分发挥本人的作用。在这个过程中会有很多十分优良的敌人参加进来，而咱们在结交新敌人的同时本人也会学习到很多贵重的教训。 如果说要给开发者一些tips的话，我感觉是尽可能多的加入社区活动，理解社区外面的人都在做什么事件，提前思考本人冀望失去哪些方面的领导，而后多跟社区里的人做分享交换。这样做会比本人自觉摸索的效率高很多。 咱们社区成员次要集中在Slack channel和微信群中，如果大家对这方面有趣味的话，欢送间接退出咱们的Slack channel或者分割微信小助手，和咱们的contributor或maintainer做一个沟通，置信会有事倍功半的成果。 想要理解更多对于Alluxio的干货文章、热门流动、专家分享，可点击进入【Alluxio智库】：

近日，“2022爱剖析·中国数据智能最佳实际案例”评选活动落下帷幕。流动面向金融、消费品与批发、工业与能源、政府与公共服务等行业的企业及机构，围绕实际当先性、案例创新性、利用成熟度、价值发明四个维度对候选实际案例进行评比。流动伊始便失去了各行业企业及科技公司的积极参与，通过申报、初评、调研、终评多轮角逐，最终评比出36个具备参考价值的翻新案例 ，并颁发利用翻新实际案例证书及奖杯。 现将本次入选案例予以颁布（按首字母顺序排列）： 数据因素不仅是国家数字经济深入倒退的外围引擎，也是企业把握新一轮科技反动和产业改革新机遇的策略抉择。数据智能交融大规模数据处理、数据分析与开掘、机器学习、可视化等多种大数据和人工智能技术，能为企业提供数据驱动的智能剖析与决策，成为企业数字化布局领先点。一方面，企业正将数据分析扩大到更多的利用场景，以在业务倒退与经营中实现降本增效，或构建创新性的业务模式；另一方面，随着数据规模的继续收缩与剖析场景的更加多元化，企业也对数据基础设施进行继续降级与优化，晋升体系化、智能化、平安可控程度。 然而企业在利用多种数据智能技术的过程中须要解决波及策略、场景布局、解决方案开发、基础设施搭建、组织与人才建设等多方面的问题，并且因为能够获取和参考的案例教训无限，企业在抉择技术、产品及厂商的过程中充斥挑战。 为了探讨和总结目前企业数据智能实际中的翻新案例，为行业提供具备参考、学习价值的前沿教训，帮忙企业更无效地实现数智化转型，爱剖析深刻调研了行业中一批国内当先企业的数据智能利用案例，并对利用落地过程中面临的需要与挑战、解决方案、成果评估等方面都进行了具体的钻研剖析，并将局部实际案例内容出现在《2022爱剖析·数据智能利用实际报告》中，详情可通过浏览报告原文理解。 爱剖析认为，多源异构海量数据曾经成为企业数字化的根底因素，目前企业更关注的是如何从海量数据中开掘价值，买通数据链路，以满足宽泛业务人员实时的、探索性的数据利用需要，最终实现企业数据驱动型决策模式的转变。对此，湖仓一体、实时数据平台、DataOps、商业智能等技术正成为企业晋升数据效力、实现数据驱动的要害。

导读：过来 3 年工夫里，Apache Doris 曾经在小米外部失去了宽泛的利用，反对了团体数据看板、广告投放/广告 BI、新批发、用户行为剖析、A/B 试验平台、天星数科、小米有品、用户画像、小米造车等小米外部数十个业务，并且在小米外部造成了一套以 Apache Doris 为外围的数据生态 。本文将为大家分享小米用户行为剖析平台基于 Apache Doris 向量化版本的革新实际，包含数据存储架构和查问服务架构的演进与革新教训分享。 作者｜小米数据智能部开发工程师 汤佳树 小米用户行为剖析对立平台是基于海量数据的一站式、全场景、多模型、多维度、自助式大数据智能洞察剖析服务平台，对接各类数据源，进行加工解决、剖析开掘和可视化展示，满足各类用户在用户洞察场景下的数据分析利用需要，提供高效极致的剖析体验。 业务需要平台能够基于数据进行工夫剖析，留存剖析，散布剖析，漏斗剖析等，业务方次要基于事件进行剖析，事件是追踪或记录的用户行为或业务过程，能够是单个事件也能够是多个事件组合的虚构事件。 数据来源于各业务的打点数据，且基于事件模型进行建模，用户在产品中的各种操作都能够形象成 Event 实体，并且外面都会蕴含五因素： Who：即参加这个事件的用户是谁，例如用户的惟一 IDWhen：即这个事件产生的理论工夫，例如time字段，记录准确到毫秒的事件产生工夫Where：即事件产生的地点，例如依据 IP 解析出的省份和城市How：即用户从事这个事件的形式，例如用户的设施，应用的浏览器，应用的 App 版本等等What：形容用户所做的这件事件的具体内容，例如点击类型的事件，须要记录的字段有点击 URL，点击 Title，点击地位等数据基于 OLAP 引擎 Doris 进行存储，随着接入业务一直增多，且接入的业务量一直收缩，Top 级利用能够达到 100 亿条/天，查问压力和工夫相继增大，用户对查问时延的吐槽愈来愈多，咱们急迫的须要晋升查问性能来晋升用户的体验。 痛点问题针对于业务需要，咱们总结了以下痛点问题： 为了实现简单的业务需要，OLAP 剖析引擎须要留存、漏斗等剖析函数撑持。增量数据 100亿/天，导入压力大，局部业务要求数据导入不丢不重。业务接入一直增多，数据量收缩，须要 PB 级的数据下的交互式剖析查问达到秒级响应。为了解决以上的痛点问题，咱们比照了多款 OLAP 剖析引擎，最终抉择了 Apache Doris。Doris 提供了留存、漏斗剖析等函数，极大水平的简化了开发的老本。在数据导入的过程中，咱们尝试 Doris 刚推出的 Merge On Write Unique Key 导入模型，能够抗住 100 亿/天的增量数据压力。针对于向量化查问引擎的革新也是的性能较之前的版本有 3-5 倍的晋升。 架构演进一个优良的零碎离不开继续迭代与演进。为了更好的满足业务需要，咱们在存储架构与查问引擎两个层面上一直进行尝试，小米用户行为剖析零碎在上线后，目前已实现 3 次革新，以下将为大家介绍革新历程。 数据存储构造：数据架构的演进 在小米的用户行为剖析平台中，原始数据通过小米自研的音讯队列 Talos，在 Flink 中荡涤与建模后，被上游的 Doris 与 Hive 生产。全量的数据会存储在 Hive 中，进行批量 ETL 或历史数据召回的查问。实时增量数据被存储在 Doris 中，用来做热数据的查问操作。基于冷热数据拆散的架构，咱们进行了 3 次架构的演进。 ...

2022年12月22日，Apache 软件基金会（ASF）官网发表 Apache Kyuubi 正式毕业，成为顶级我的项目（TLP）。 Apache Kyuubi 是一个分布式和多租户网关，用于在数据仓库和湖仓上提供无服务器SQL。 我的项目最后由网易数帆开发并于2018年开源，2021年6月捐献 Apache基金会，通过1年多的孵化于2022年11月通过投票，在12月顺利毕业，成为 Apache 基金会顶级开源我的项目！ Apache Kyuubi 简介Apache Kyuubi 在各种古代计算框架之上建设了分布式SQL查问引擎，例如 Apache Spark™、Apache Flink™、Apache Doris™、Apache Hive™和Trino等，以查问散布在异质数据源的机器群上的大规模数据集。 对立网关：通过一个入口点实现对任何集群资源的简化、平安拜访，为终端用户部署不同的工作负载 利用编程接口：反对各种API，包含Apache Thrift™、JDBC、ODBC、REST等，便于拜访。多租户：反对端到端的多租户，这对集群的安全性和并发性都无利。高可用性：确保其在指定工夫内间断无障碍运行，以满足约定的运行性能程度。无服务器SQL及更多：使最终用户更容易从数据宇宙中取得洞察力，并优化数据管道，无论他们的技术常识如何。它可能应用相熟的SQL为各种工作负载提供与RDBMS雷同的用户体验，在不同的数据源上提供宽泛和平安的数据拜访能力，并通过可扩大的计算资源为大量数据提供高性能。 易用性：终端用户能够有一个优化的体验，以无服务器的形式摸索他们的数据宇宙。相应的引擎，如 Spark 和Flink 的 "超能力 "不再是必要的。在任何中央以任何规模运行：所有的预编程引擎都有分布式后端，能够在单节点机器上或跨集群安顿工作。高性能：最先进的查问引擎、服务器端的全局和继续优化等保障了整个集群的性能晋升。社区倒退在孵化过程中，社区迎来了一百多个奉献，有数千个提交，总计胜利公布了九个版本。来自不同公司和国家的开发者和其余类型的贡献者在社区中度过了一段高兴的旅程。 Kyuubi 目前已被寰球数百家企业采纳，波及多个行业，如云基础设施、互联网、金融、医疗、打车服务、物流、游戏和ACG，等等。像阿里巴巴、Bilibili、中国移动、携程、丁香园、eBay、爱奇艺、广发证券、kt NexR、网易、腾讯、T3、Womply、小米、雪球和知乎等公司都在应用 Apache Kyuubi。 “这是 Kyuubi 的一个重要里程碑，毕业也证实了它在大公司的微小价值。在过来的一年里，咱们胜利地采纳了Kyuubi 作为 Ad-hoc 查问和批量 ETL 作业的对立网关。kyuubi不仅反对交互式会话，还反对批量作业提交，这对企业用户来说至关重要。”eBay Hadoop 团队经理 Jiaye Wang 说，“咱们期待着社区在将来提供更多令人兴奋的性能。” “广发证券在大数据平台迁徙中始终关注并采纳 Kyuubi。咱们将 Apache Kyuubi 视为下一代对立数据平台的旗舰服务之一，在数字化转型中引领金融科技架构演进，同时也是与大数据生态系统中其余我的项目实现独特凋敝的要害。”广发证券资深工程师梁博文评估道，“作为贡献者，在一个支持性的社区中一直做出奉献也是很欢快的。很兴奋看到 Kyuubi 毕业。” "毕业将为更多的公司引入 Kyuubi 框架带来信念，"Apache Kyuubi PMC，T3大数据平台研发负责人杨华补充道。"将来，咱们将尝试将更多的大数据查问/计算引擎与 Kyuubi 整合，同时，将其与外部数据地图连贯，加强其受权能力，使其真正成为咱们公司大数据的对立网关。" 毕业寄语（按姓氏首字母排序）“很快乐看到又一个国人主导的 Apache 我的项目可能从孵化器毕业。Kyuubi 提供了 Severless 的 SQL 减速剖析体验，不便企业便捷的买通各个数据源的拜访。作为 Apache兄弟我的项目，Kyuubi 也提供了Apache Doris JDBC连接器反对，欢送大家应用和反馈。也祝福 Kyuubi可能在开源的舞台书写新的篇章！” ...

欢送来到【微直播间】，2min纵览大咖观点 随着企业数据量的一直减少，为了进步深度学习训练的准确性、加快速度并且降低成本，许多企业开始逐渐在云上施行分布式训练的计划，本期内容将联合阿里、微软等理论利用案例，分享如何通过Alluxio减速云上深度学习。 内容次要围绕两个局部开展： 内容概要：Alluxio及其POSIX API简介 Alluxio是一个java开源我的项目，是云上的对于数据分析以及深度学习训练的一个数据抽象层。应用Alluxio，能够对数据利用以及数据源进行无缝连贯。Alluxio的一个很重要性能是可能对数据进行读写缓存，另一方面也能够对元数据进行本地缓存。Alluxio能够把来自不同的远端存储系统，以及分布式文件系统的数据都挂载到Alluxio对立的命名空间之内。通过Alluxio POSIX API，把这些数据变成相似于本地文件的模式，提供给各种训练任务。应用Alluxio减速云上训练Level 1 读取缓存与减速：间接通过Alluxio来减速对底层存储系统中的数据拜访。Level 2 数据预处理和训练：之所以有二级玩法，次要因为一级玩法有一些先决条件，要么数据曾经解决好就放在存储系统中，要么训练脚本曾经蕴含了数据预处理的步骤，数据预处理与训练同时进行，而咱们发现在很多用户场景中，并不具备这些条件。Level 3 数据抽象层：把Alluxio作为整个数据的形象层。以上仅为大咖演讲概览，残缺内容点击视频观看： 附件：大咖分享文字版残缺内容可见下文 Alluxio及其POSIX API简介 Alluxio是一个java开源我的项目，是云上的对于数据分析以及深度学习训练的一个数据抽象层。在Alluxio之上能够对接不同的数据利用，包含Spark、Flink这种ETL工具，Presto这种query工具，以及TensorFlow、PyTorch等深度学习框架。在Alluxio上面也能够连贯不同数据源，比方阿里云、腾讯云、HDFS等。 应用Alluxio，能够对数据利用以及数据源进行无缝连贯，Alluxio负责解决与不同数据源以及不同零碎的对接。 Alluxio的一个很重要性能是可能对数据进行读写缓存。大家可能很多数据是在云存储上，或者是在远端的HDFS和Ceph集群上，如果每一次的数据利用都要去远端一直反复地拿同样的数据，那么整个拿数据的流程是十分耗时的，而且可能会导致咱们整体训练或数据处理效率不高。通过Alluxio，咱们能够把一些热数据在凑近数据利用的集群进行缓存，从而晋升反复数据获取的性能。 另一方面，咱们也能够对元数据进行本地缓存。每一次获取元数据都要通过网络去获取是比较慢的。如果通过Alluxio，能够间接从本地集群获取元数据，延时会大大缩短。同时，模型训练的元数据需要是十分低压的，咱们在与蚂蚁金服的试验中，能够看到成千上万QPS，如果全副压力都压到存储系统中，存储系统可能会不稳固，或进行肯定的限流解决，导致一些读取谬误。通过Alluxio能够很好地分担这部分元数据的压力。 接下来重点解说一下Alluxio的POSIX API。深度学习训练框架PyTorch、TensorFlow、Caffe，它们的原生数据源都是本地文件系统。企业数据量日益扩充，导致咱们须要去应用分布式数据源。Alluxio能够把来自不同的远端存储系统，以及分布式文件系统的数据都挂载到Alluxio对立的命名空间之内。通过Alluxio POSIX API，把这些数据变成相似于本地文件的模式，提供给各种训练任务。 上图直观地展示了Alluxio POSIX API把远端的分布式数据变成了本地文件夹的模式。 应用Alluxio减速云上训练上面来具体解说如何应用Alluxio来减速云上训练。 Level 1 读取缓存与减速一级玩法比较简单，就是间接通过Alluxio来减速对底层存储系统中的数据拜访。 如上图示例，咱们有一些数据存储在咱们的存储系统中，它可能是曾经通过数据预处理的数据，也可能是一些原始数据。咱们的训练在云上的K8s集群上，与数据源之间存在肯定的天文差别，获取数据存在延时。咱们的训练须要反复去获取同样的数据源，在这种状况下，应用Alluxio集群，在凑近训练的集群内进行数据的缓存能够极大地晋升咱们获取数据的性能。 能够用简略的命令来设置数据源，以及一些平安参数，让Alluxio能够去拜访这些数据源。提供了数据源地址以及平安参数之后，就能够把它挂载到Alluxio命名空间内的一个文件夹目录上面。挂载后，能够用一个命令来把所有的数据都一键地分布式加载到Alluxio当中，这样所有数据都会进行分布式的缓存，为咱们的训练任务提供本地数据性能。 上图是阿里巴巴进行的一个实测，如果他们的训练通过oss Fuse间接去拜访阿里云存储，整个性能可能是几百兆每秒，而通过Alluxio进行缓存后，能够达到千兆每秒。 在Microsoft，他们的场景是：训练数据全副存在Microsoft Azure外面，有超过400个工作须要从Azure读数据，并写回到Azure中。这400个工作会波及到上千个节点，而他们的训练数据又是比拟对立的。在应用Alluxio之前，他们的计划是把一份数据从Azure中不停地拷贝到上千台机器上。整个过程耗时大，并且因为任务量太大了，经常会导致Azure对他们的数据申请进行限流解决，从而导致下载失败，还要人工去复原下载。通过应用Alluxio之后，Alluxio能够从Azure拿取一份数据，而后同样的一份数据能够供应不同的训练任务以及不同的机器，这样load一次数据，就能够进行屡次读取。 在应用Alluxio之后，训练任务无需期待数据齐全下载到本地就能够开始训练了。训练完结之后，也能够通过Alluxio间接写回到Azure。整个流程十分不便，并且gpu的使用率比较稳定。 Level 2 数据预处理和训练接下来看二级玩法。之所以会有二级玩法，次要是因为一级玩法有一些先决条件，要么数据曾经解决好就放在你的存储系统中，要么你的训练脚本曾经蕴含了数据预处理的步骤，数据预处理与训练同时进行，然而咱们发现在很多用户场景中，并不具备这些条件。 在很多用户的场景里，他们须要用其它形式来先对数据进行预处理，而后这部分预处理后的数据能力供应训练。比方会用Spark、Flink等大数据ETL工具来进行数据预处理，解决好的数据写到Alluxio，之后由Alluxio供应给训练集群。同时，对这部分数据能够进行备份、减速，来更快地提供给训练集群。 咱们通过一个具体案例来理解这个流程。在BOSS直聘，他们有两个工作，首先是用Spark/Flink来对数据进行预处理，之后再对这部分预处理好的数据进行模型训练。所有的两头后果和最初解决好的数据，都间接长久化到Ceph上，再由Ceph为模型训练提供数据。把两头处理结果也放到Ceph中，会给Ceph减少很多的压力。低压的模型训练给Ceph造成很大压力。当ETL工作以及训练多的时候，Ceph十分不稳固，整体性能受到影响。他们的解决办法就是把Alluxio加到Spark/Flink和模型训练之间。 Spark/Flink把两头后果写到Alluxio之中，由Alluxio来提供给模型训练。Alluxio在背地异步地把这部分数据长久化到Ceph中，以保障这些预处理好的数据不会失落。所以无论咱们的数据源是在本地还是远端，即便数据长久化的速度比较慢，也不影响咱们的训练流程。并且Alluxio能够是一些独自的集群，如果ETL或training工作多的时候，能够起更多的Alluxio cluster来分担这些工作，也能够对不同的Alluxio集群进行资源分配、读写限额、权限管制等。 这个流程能够晋升存储系统的稳定性，同时减速从数据预处理到训练的整个流程，并且能够用更多的Alluxio集群来应答更多的ETL或训练需要。 咱们发现大家会有不同的数据预处理形式。有些用户用C++、python程序来进行数据清理、转换等数据预处理。他们应用Alluxio把原始数据从底层存储系统中加载到Alluxio的缓存内，由Alluxio提供这部分数据预处理的框架，解决好的后果再写回到Alluxio当中，模型训练就能够用这部分预处理好的数据进行训练。 Level 3 数据抽象层Alluxio的三级玩法，就是把Alluxio作为整个数据的形象层。 ...

本 Quick Guide 面向 BitSail 新手入门应用人员，从源码编译、产物构造、如何提交作业、实机演示等多方面率领大家迅速入门 BitSail，从 0 到 1 理解并实现 BitSail 根底构建。 BitSail 源码编译BitSail 在我的项目中内置了编译脚本 build.sh，寄存在我的项目根目录中。新下载的用户能够间接该脚本进行编译，编译胜利后能够在目录：bitsail-dist/target/bitsail-dist-${rversion}-bin 中找到相应的产物。 BitSail 产物构造 BitSail 如何提交作业Flink Session Job第一步：启动Flink Session集群 session运行要求本地环境存在hadoop的依赖，同时须要HADOOP_CLASSPATH的环境变量存在。 bash ./embedded/flink/bin/start-cluster.sh 第二步：提交作业到Flink Session 集群 bash bin/bitsail run \ --engine flink \ --execution-mode run \ --deployment-mode local \ --conf examples/Fake_Print_Example.json \ --jm-address <job-manager-address> Yarn Cluster Job 第一步：设置HADOOP_HOME环境变量 export HADOOP_HOME=XXX 第二步：设置HADOOP_HOME，使提交客户端就找到yarn集群的配置门路，而后就能够提交作业到Yarn集群 bash ./bin/bitsail run --engine flink \--conf ~/dts_example/examples/Hive_Print_Example.json \--execution-mode run \--deployment-mode yarn-per-job \--queue default ...

A/B 试验的外围统计学实践是（双样本）假设检验，是用来判断样本与样本、样本与总体的差别是由 抽样误差 引起还是 实质差异 造成的一种统计推断办法。 假设检验，顾名思义，是一种对本人做出的假如进行数据验证的过程。 艰深地说，假设检验是一门 做出回绝 的实践，测验后果有两种：回绝原假如(reject H0)，无奈回绝原假如(fail to reject H0)。实验者往往将主观不心愿看到的后果（新策略没有成果）置于 原假如 （从英文命名就可以看进去感情色调 - 它叫 null hypothesis），而将原假如的互斥事件，即对事实自身无利的后果（新策略有晋升）置于 备则假如 （alternative hypothesis），如此形成的假设检验目标在于用现有的数据通过一系列实践演绎 回绝原假如 ，达到证实备择假如是正确的，即某项改良无效的目标，所以这一套办法也被称作 null hypothesis significance testing (NHST) 。 因为咱们永远只能抽取流量做 小样本 试验，所以每个假设检验都面临着 随机抽样误差 ，因而在做出推论的过程中，所有都围绕 概率 开展。 这意味着没有任何一个基于假设检验的演绎过程能够对后果 100%确定。但所幸，统计实践能够通知咱们在每一步中犯错的机会。因而，当时通晓咱们 可能犯什么错 ，以及 有多大机会犯错 就成了设计和解读假设检验的关键所在。 实验者在假设检验的过程中可能会做出 两类错误判断 - 不意外地 - 它们被命名为 第一类谬误 （弃真）和 第二类谬误 （取伪）。第一类谬误(Type I Error)：H0 为真，回绝 H0。“自身没晋升，但误判为有晋升”第二类谬误(Type II Error)：H1 为真，承受 H0。“自身有晋升，但没有觉察晋升” 比照上图，第一类谬误指的是原假如正确然而咱们做出了回绝原假如的论断，这个谬误在事实中经常体现为“我作出了统计显著的论断然而我的改变实际上没用”；相应地，第二类谬误指的是原假如谬误然而咱们没能回绝原假如，这个谬误在事实中经常体现为“我的改变无效，但试验没能检测进去”。 在 AB 试验的场景下，如果对某一个新 feature 是否无效进行假设检验，H0 为新 feature 没有成果，第一类谬误指的是“新 feature 理论有效但检测出存在显著性成果”，第二类谬误则指的是“新 feature 理论无效但未能检测出成果”。如果犯了第一类谬误，会导致新 feature 的谬误上线，可能会带来理论利益损失，如果犯了第二类谬误，理论无效的 feature 将不会上线，带来的是潜在利益的损失。 ...

本期内容咱们邀请到了来自蚂蚁团体的开发工程师陈传迎老师，给大家分享Alluxio在蚂蚁团体是如何反对大规模模型训练的。 首先是对于引入Alluxio的背景：为什么要引入Alluxio？Alluxio到底解决了什么问题？ 带着这些问题，咱们疾速get陈老师分享的核心内容：第一局部：稳定性建设 稳定性建设次要从两块进行：worker register follower和master迁徙。【价值】能够把整个集群做FO的工夫管制在30秒以内，如果再配合一些其余机制，比方client端有一些元数据缓存机制，就能够达到一种用户无感知的条件下进行FO。 第二部份：性能优化 性能优化次要进行了follower read only的过程。【价值】单个集群的吞吐曾经造成了三倍以上晋升，整个性能也会晋升上来，能够反对更大并发的模型训练任务。 第三局部：规模晋升 规模晋升次要是横向扩大。【价值】模型训练汇合越来越大，能够把这种模型训练引入进来，对外提供反对。 以上仅为大咖演讲概览，残缺内容点击视频观看： 附件：大咖分享文字版残缺内容可见下文 背景介绍首先是咱们为什么要引入Alluxio，其实咱们面临的问题和业界基本上是雷同的：√ 第一个是存储IO的性能问题，目前gpu的模型训练速度越来越快，势必会对底层存储造成肯定的压力，如果底层存储难以反对目前gpu的训练速度，就会重大制约模型训练的效率。√ 第二个是单机存储容量问题，目前咱们的模型汇合越来越大，那么势必会造成单机无奈寄存的问题。那么对于这种大模型训练，咱们是如何反对的？√ 第三个是网络提早问题，目前咱们有很多存储解决方案，但都没方法把一个高吞吐、高并发以及低延时的性能交融到一起，而Alluxio为咱们提供了一套解决方案，Alluxio比拟小型化，随搭随用，能够和计算机型部署在同一个机房，这样能够把网络延时、性能损耗降到最低，次要出于这个起因咱们决定把Alluxio引入蚂蚁团体。 以下是分享的核心内容：总共分为3个局部，也就是Alluxio引入蚂蚁团体之后，咱们次要从以下三个方面进行了性能优化：第一局部是稳定性建设、 第二局部是性能优化、第三局部是规模晋升。 稳定性建设首先介绍为什么要做稳定性的建设，如果咱们的资源是受k8s调度的，而后咱们频繁的做资源重启或者迁徙，那么咱们就须要面临集群频繁的做FO，FO的性能会间接反映到用户的体验上，如果咱们的FO工夫两分钟不可用，那么用户可能就会看到有大量的报错，如果几个小时不可用，那用户的模型训练可能就会间接kill掉，所以稳定性建设是至关重要的，咱们做的优化次要是从两块进行：一个是worker register follower，另外一个是master迁徙。 Worker Register Follower先介绍下这个问题的背景：上图是咱们Alluxio运行的稳固状态，由master进行元数据服务，而后外部通过raft的进行元数据一致性的同步，通过primary对外提供元数据的服务，而后通过worker节点对外提供data数据的服务，这两者之间是通过worker注册primary进行一个发现，也就是worker节点的发现，这样就能够保障在稳固状态下运行。那如果这时候对primary进行了重启，就须要做一次FO的迁徙，也就是接下来这个过程，比方这时候对primary进行了重启，那么外部的standby就须要通过raft进行从新选举，选举进去之前，其实primary的元数据和worker是断联的，断连的状态下就须要进行raft的一致性选举，进行一次故障的转移，接下来如果这台机器选举进去一个新的primary，这个时候work就须要从新进行一次发现，发现之后注册到primary外面，这时新的primary就对外提供元数据的服务，而worker对外提供data数据的服务，这样就实现了一次故障的转移，那么问题点就产生在故障产生在做FO的时候，worker发现新的primary后须要从新进行一次注册，这个局部次要面临三个问题： 第一个就是首个worker注册前集群是不可用的，因为刚开始首个worker复原了新的primary领导能力，如果这个时候没有worker，其实整个primary是没有data节点的，也就是只能拜访元数据而不能拜访data数据。 第二个是所有worker注册过程中，冷数据对性能的影响。如果首个worker注册进来了，这时就能够对外提供服务，因为有data节点了，而在陆续的注册的过程当中如果首个节点注册进来了，而后后续的节点在注册的过程当中，用户拜访worker2的缓存block 的时候，worker2处于一种miss的状态，这时候data数据是失落的，会从现存的worker中选举进去到底层去读文件，把文件读进来后从新对外提供服务，然而读的过程当中，比如说worker1去ufs外面读的时候，这就牵扯了一个预热的过程，会把性能拖慢，这就是注册当中的问题。 第三个是worker注册实现之后的数据冗余清理问题。注册实现之后，其实还有一个问题就是在注册的过程当中一直有大量数据进行了从新预热，worker全副注册之后，注册过程中从新缓存的这部分数据就会造成冗余， 那就须要进行预先清理，依照这个重大等级其实就是第一个worker注册前，这个集群不可用，如果worker规格比拟小，可能注册的工夫2-5分钟，这2-5分钟这个集群可能就不可用，那用户看到的就是大量报错，如果worker规格比拟大，例如一个磁盘有几tb的体量，齐全注册上来须要几个小时。那这几个小时整个集群就不可对外提供服务，这样在用户看来这个集群是不稳固的，所以这个局部是必须要进行优化的。 咱们目前的优化计划是：把所有的worker向所有的master进行注册，提前进行注册，只有worker起来了 那就向所有的master从新注册一遍，而后两头通过这种实时的心跳放弃worker状态的更新。那么这个优化到底产生了怎么成果？能够看下图： 这个时候如果primary被重启了，外部通过raft进行选举，选举进去的这个新的primary对外提供服务，primary的选举须要经验几局部：第一局部就是primary被重启之后，raft进行自发现，自发现之后两者之间进行从新选举，选举进去之后这个新的primary通过catch up后就能够对外提供服务了，就不须要从新去获取worker进行一个register，所以这就能够把工夫齐全节省下来，只须要三步：自发现、选举、catch up。 这个计划的效率十分高，只须要30秒以内就能够实现，这就大大缩短了FO的工夫。另一个层面来说，这里也有一些负面的影响，次要是其中一个master如果进行了重启，那么对外来说这个primary是能够提供失常服务的，而后这个standby重启的话，在对外提供服务的同时，worker又须要从新注册这个block的元数据信息，这个block元数据信息其实流量是十分大的，这时会对以后的worker有肯定影响，而且对局部注册上来的master性能也有影响，如果这个时候集群的负载不是很重的话，是齐全能够疏忽的，所以做了这样的优化。 Master的迁徙问题 如图所示，其实刚开始是由这三者master对外提供服务， 这三者达到一个稳固的状态，而后worker注册到primary对外提供服务，这个时候如果对机器做了一些腾挪，比方standby3把standby1替换掉，而后standby4把standby2替换掉，而后新的primary把老的primary替换掉，这个时候新的这个master的集群节点就是由这三者组成：standby3、standby4、新的primary，依照失常的流程来说，这个worker是须要跟以后这个新的集群进行建联的，维持一个失常的心跳，而后对外提供服务，然而这时候并没有，次要起因就是worker辨认的master信息其实是一开始由configer进行动态注入的，在初始化的时候就曾经写进去了，而且后盾是动态治理的，没有动静的更新，所以永远都不能辨认这三个节点， 辨认的永远是三个老节点，相当于是说这种场景间接把整个集群搞挂了，对外没有data节点就不可提供服务了，复原伎俩次要是须要手动把这三个新节点注册到configer当中，从新把这个worker重启一遍，而后进行辨认，如果这个时候集群规模比拟大，worker节点数量比拟多，那这时的运维老本就会十分大，这是咱们面临的master迁徙问题，接下来看一下怎么应答这种稳定性： 咱们的解决方案是在primary和worker之间维持了一个主心跳，如果master节点变更了就会通过主心跳同步以后的worker，实现实时更新master节点，比方standby3把standby1替换掉了，这个时候primary会把以后的这三个节点：primary、standby2、standby3通过主心跳同步过去给以后的worker，这个时候worker就是最新的，如果再把standby4、standby2替换，这时候又会把这三者之间的状态同步过去，让他放弃是最新的，如果接下来把新的primary加进来，就把这四者之间同步过去，重启之后进行选举，选举进去之后 这就是新的primary，因为worker节点最初的一步是存着这四个节点，在这四个节点当中便当寻找以后的leader，而后就能够辨认新的primary，再把这三个新的master同步过去 这样就达到一个平安的迭代过程，这样的状况下再受资源调度腾挪的时候，就能够稳固的腾挪上来。 以上两局部就是稳定性建设的内容。 性能优化性能优化咱们次要进行了follower read only的过程，首先给大家介绍一下背景，如图所示： 这个是以后Alluxio的整体框架，首先client端从leader拿取到元数据，依据元数据去拜访失常的worker，leader和standby之间通过raft进行与元数据一致性的同步，leader进行元数据的同步只能通过leader发动而后同步到standby，所以说他是有先后顺序的。而standby不能通过发动新的信息同步到leader，这是一个违反数据一致性准则的问题。 另一部分就是以后的这个standby通过后面的worker register follower的优化之后，其实standby和worker之间也是有肯定分割的，而且数据都会收集上来，这样就是standby在数据的完整性上曾经具备了leader的属性，也就是数据基本上和leader是保持一致的。 而这一部分如果再把它作为backup，即作为一种稳定性备份的话，其实就是一种资源的节约，想利用起来但又不能突破raft数据一致性的规定，这种状况下咱们就尝试是不是能够提供只读服务， 因为只读服务不须要更新raft的journal entry，对一致性没有任何的影响，这样standby的性能就能够充分利用起来，所以说这里想了一些优化的计划，而且还牵扯了一个业务场景，就是如果咱们的场景实用于模型训练或者文件的cache减速的，那只有第一次预热的时候数据才会有写入，前面是只读的，针对大量只读场景利用standby对整个集群的性能取胜是十分可观的。 上面是具体的优化计划，如图所示： 次要是针对后面进行的总结，所有的worker向所有的standby进行注册，这时候standby的数据和primary的数据基本上是统一的，另一部分还是primary和worker之间保护的主心跳，这个时候如果client端再发动只读申请的时候，就会随机散列到以后所有的master上由他们进行解决，解决实现之后返回client端，对于写的申请还是会发放到primary下来。而后在不突破raft一致性的前提下，又能够把只读的性能晋升，这个机器扩大进去，依照失常推理来说，只读性能可能达到三倍以上的扩大，通过follower read理论测验下来成果也是比拟显著的。这是咱们引入Alluxio之后对性能的优化。 规模晋升规模晋升次要是横向扩大，首先看一下这个问题的背景：如图所示： 还是Alluxio的框架，master外面次要蕴含了很多构件元素，第一个就是block master，第二个是file master，另外还有raft和snapshot，这个局部的次要影响因素就是在这四个方面：√ Bblock master，如果咱们是大规模集群创立下，block master面临的瓶颈就是内存，它会强占掉大量master的内存，次要是保留的worker的block信息；√ File master，次要是保留了inode信息，如果是大规模场景下，对本地存储的压力是十分大的；√ Raft面临的同步效率问题；√ snapshot的效率，如果snapshot的效率跟不上，能够发现后盾会积压十分多journal entry，这对性能晋升也有肯定影响； ...

作为一款面向ToB市场的产品——火山引擎A/B测试（DataTester）为了满足客户对数据安全、合规问题等需要，摸索私有化部署是产品无奈绕开的一条路。 在面向ToB客户私有化的理论落地中，火山引擎A/B测试（DataTester）也遇到了字节外部服务和企业SaaS服务都不容易遇到的问题。在解决这些问题的落地实际中，火山引擎A/B测试团队积淀了一些流程治理、性能优化等方面的教训。 本文次要分享火山引擎A/B测试以后的私有化架构，遇到的次要问题以及从业务角度登程的解决思路。 火山引擎A/B测试私有化架构架构图整套零碎采纳 Ansible+Bash 的形式构建，为了适应私有化小集群部署，既容许各实例对等部署，复用资源，实现最小三节点交付的指标,，又能够做在线、离线资源隔离进步集群稳定性。集群内能够划分为三局部： 1.业务服务: 次要是间接向用户提供界面或者性能服务的, 例如试验治理、实验报告、OpenAPI、数据接入等。 2.根底服务: 不间接面向用户,为下层服务的运行提供撑持,例如反对实验报告的计算引擎、为指标创立提供元信息的元信息服务;根底服务同时还会充当一层对基础设施的适配,用来屏蔽基础设施在 SaaS 和私有化上的差别, 例如 SaaS 采纳的实时+离线的 Lambda 架构, 私有化为了缩小资源开销,适应中小集群部署只保留实时局部, 计算引擎服务向下层屏蔽了这一差别。 3.基础设施: 外部团队提供对立私有化基础设施底座 minibase,采纳宿主机和 k8s 联合的部署形式,由 minibase 适配底层操作系统和硬件, 下层业务间接对接 minibase。 私有化带来的挑战挑战 1：版本治理h传统 SaaS 服务只须要部署保护一套产品供全副客户应用，因而产品只须要针对单个或几个服务更新，疾速上线一个版本个性，而不须要思考从零开始搭建一套产品。SaaS 服务的版本公布周期往往以周为单位，放弃每周 1-2 个版本更新频率。 然而，在私有化交付中，咱们须要确定一个基线版本并且绑定每个服务的小版本号以确保雷同版本下每套环境中的交付物等价，以加重后续降级运维老本。通常，基线版本的公布周期往往以双月为单位。 版本公布周期因为私有化和 SaaS 服务在架构、实现、根底底座上均存在不同，上述的公布节奏会带来一个显著的问题：团队要投入大量的开发和测试人力集中在发版周期内做历史 Feature 的私有化适配、私有化个性的开发、版本公布的集成测试，挤占其余需要的人力排期。 为了将周期内集中实现的工作扩散到 Feature 开发阶段，从新标准了分支应用逻辑、欠缺私有化流水线和上线流程，让研发和测试的染指工夫前移。 解法：1、分支逻辑分支治理SaaS 和私有化均基于 master 分支公布，非私有化版本周期内不特地辨别 SaaS 和私有化。 私有化公布周期内独自创立对应版本的私有化分支，公布实现后向 master 分支合并。这样保障了 master 分支在任何状况下都该当能同时在 SaaS 环境和私有化环境中失常工作。 2、公布流水线性能上线流程公布流水线外部搭建一套私有化预公布环境，建设了一套流水线，对 master 分支的 mr 会触发流水线同时在 SaaS 预公布环境和私有化预公布环境更新最新 master 分支代码，并执行自动化回归和人工回归测试。 ...

作者：京东科技隐衷计算产品部 杨博1.背景现在，组织在收集、存储敏感的个人信息以及在外部环境（例如云）中解决、共享个人信息时， 越来越关注数据安全。这是恪守隐衷法规的强需要：例如美国加利福尼亚州消费者隐衷法 (CCPA)、欧盟通用数据保护条例 (GDPR) 和世界各地的其余新兴法规，以及中国的《数安法》《个保法》等，都对平安解决敏感数据提出了要求。 加密静态数据不足以防止数据泄露。静态数据加密创立了一个“加密边界”，在该边界之外能够以明文模式拜访数据。因为解决通常须要明文数据，所以这个边界通常存在潜在的数据透露危险。静态数据加密也不反对与其余组织共享数据的计划。为了使数据有用，它们通常必须在应用程序中以明文模式拜访，这大大降低了加密的爱护能力。因而，不同的行业都须要新的隐衷爱护计算方法来满足法律合规要求并为数据共享提供隐衷保障。 狭义的隐衷计算技术是面向隐衷信息全生命周期爱护的计算实践和办法，涵盖信息所有者、信息转发者、信息接收者在信息采集、存储、解决、公布（含替换）、销毁等全生命周期过程的所有计算操作，是实现隐衷爱护前提下数据安全流通的一系列技术。包含但不限于： •基于数据限度公布的技术：如数据脱敏、去标识化（掩码、克制、泛化、截断、混同、k-匿名、l-多样性、t-贴近等） •基于数据失真的技术：如随机扰动、差分隐衷、合成数据 •隐衷计算技术：以多方平安计算、联邦学习、可信执行环境三大路线为根底 •相干辅助技术：如区块链、可验证计算、溯源审计技术 2.前言随着数字化和大数据分析技术的疾速倒退，对多方数据的需要也越来越多，例如对集体信用风险进行评估，就须要联结多个属性特色进行联结统计分析。集体征信过程中须要采集的信息包含个人身份、住址、职业等根本信息，集体贷款、贷记卡、准贷记卡、担保等信用流动中造成的集体信贷交易记录，以及反映个人信用情况的其余信息，根本涵盖了集体生存的方方面面。各家征信机构如果想要本人推出的信用体系实现精准信用评估，禁受住市场测验，它的信用模型就须要应用更多源、更及时且更有价值的海量数据来继续建模。 然而法规监管和采集老本使数据难以共享，因为征信数据是一种非独占性的非凡资源，具备复制成本低、所有权难确定、流通渠道难管控、应用范畴难限定等特点，稍有不慎，数据极易泄露。如何在保障数据安全和隐衷的条件下实现征信数据的交融？如何保障征信数据的应用和流传是可控的？多方平安计算（Secure Multi- Party Computation ，简称MPC）恰好解决了这个难题，为征信数据的丰沛流动提供了技术可能。 MPC技术具备爱护隐衷、后果正确、操作可控的劣势，这能够解决征信数据交融的技术窘境。MPC通过密码学伎俩，能够保障参加征信数据交融的各方自身的数据不泄露；通过密文函数计算，能够保障运算后果与明文计算雷同；它还能够规定征信数据应用的用处和用量，使每一步操作都是可控、受限且可审计的。 3.多方平安计算-MPC（ Secure Multi-Party Computation ）多方平安计算(MPC)是在无可信第三方状况下，多个参与方协同实现计算指标，并保障每个参与者除计算结果外均不能失去其余参加实体的任何输出信息。多方平安计算问题最后起源于1982年姚期智院士提出的百万富翁问题，起初通过多年一直的倒退，成为目前密码学的一个重要分支。多方平安计算是基于密码学的算法协定来实现隐衷爱护，常见的多方平安计算协定包含机密共享（Secret Sharing，SS） 、混同电路（Garbled Circuit，GC）、同态加密（Homomorphic Encryption，HE）、不经意传输（Oblivious Transfer，OT）等。多方平安计算技术能够获取数据应用价值，却不泄露原始数据内容，爱护隐衷，可实用于多方联结数据分析、数据安全查问（PIR，Private Information Retrieval）、隐衷求交（PSI，rivate Set Intersection）、数据可信替换等利用场景。一系列用于 MPC 的开源库（例如ABY、EMP-toolkit，FRESCO，JIFF 、MP-SPDZ，MPyC, SCALE-MAMBA，和 TinyGable等) 失去了倒退，进一步推动了 MPC 的利用和部署。 表1展现了多方平安计算与联邦学习和可信执行环境的个性比照。 多方平安计算是基于密码学的可证平安计算，具备高安全性，但对网络要求高，可利用在银行、政府等高平安要求场景。联邦学习效率高，适宜数据量大的联结机器学习场景，尽管存在梯度泄露问题，但可联合差分隐衷或者多方平安计算来晋升安全性。可信执行环境属于数据加密后集中计算，具备高安全性、高精度等特点，但须要数据加密集中到第三方环境，限度了其应用场景。 在 MPC 中，能够对多方奉献的数据执行计算，而任何一方都无奈看到他们奉献的数据内容。这使得无需受信赖的第三方即可执行平安计算。下图阐明参与者在计算上进行合作，只晓得计算的后果，而不晓得其他人奉献的特定数据。以计算平均工资为例，一种简略的的形式是有一个可信第三方F负责收集A，B，C每个人的工资收入数据，并计算平均数。然而，显示生存中的可信第三方不总是存在，也并不一定平安，其有可能会透露其收集的隐衷数据。另一种形式就是采纳多方平安计算，在无可信第三方的状况下，来保障各方的工资数据不透露，且能计算出平均工资数。 如下图所示，Allie（A） 的工资是 100美元。在加性秘密共享中，100美元被分成三个随机生成的局部（或机密份额）：例如 20美元、30美元和 50美元。Allie 为本人保留其中一份机密股份（50美元），并将一份机密份额调配给Brian(B)（30美元）和Caroline(C)（20美元）。Brian 和 Caroline 也遵循雷同的流程机密分享他们的工资薪水。每个参与者在本地汇总他们的机密份额以计算局部后果；在此示例中，每个局部后果是计算最终答案所需信息的三分之一。而后重新组合局部后果{-30, 480, 150}，将先前散发的残缺机密共享集相加求均匀，即可得出Allie、Brian 和 Caroline 的平均工资是 200美元。可见，在整个过程中，各方依据本人手中把握的局部机密份额以及最终后果是无奈推导出其余方的原始工资信息的。 ...

汽车行业的数字化，远不止是从传统汽车产品到新能源智能科技产品的转型。 在营销畛域，汽车企业正面临着新问题：首先是目标，汽车营销正在从简略的单次购买关系向长期的用户经营转型；其次是触达通道，随着小程序、APP 等私域新阵地的衰亡，车企与用户之间的信息纽带也变得更加多元简单；此外，消费者生产习惯的扭转，比方偏好个性化和差异化，偏好新服务等特点，也迫使车企在营销策略和重点上做出扭转。 可能实现多维市场洞察，全链路追踪投放数据转化，贯通用户汽车生产全生命周期把控的数字化营销，火烧眉毛。 对大多数车企来说，营销的最终目都在于可能将潜在的消费者转化成为本身汽车用户，因而可能清晰看懂营销后的数据流转尤其重要。 通常状况下，能够将营销场景中的数据流转依照「用户生命旅程」大抵分为三个阶段。第一阶段是通过精准营销，将圈选的指标人群转化成为具备购车动向的“线索”。 以火山引擎数智平台 VeDI 推出的客户数据平台 VeCDP 为例，它能通过接入车企多渠道市场数据，实现特色提炼，并以标签模式实现归类，不便在营销场景下即时调用。 此外，它还能进一步放大特色，实现公域指标人群的精准圈选，为营销放大提供可能。而在精准营销实现后，VeCDP 还能将市场数据实时回流，以此帮忙车企得出市场对本场营销的反馈，以及积淀高动向及感兴趣人群。 第二个阶段是线索培养，通过对回传后的数据二次加工，将动向人群依照车企本身所需的维度进行分级，如高动向人群可安顿金牌销售一对一沟通、一般动向人群可安顿一般销售进行对接、志愿绝对较低的人群能够通过机器人客服或智能外呼等伎俩分割。 在进行初轮沟通后，须要建设线索经营情况表，以便实时反馈跟进状态——这能够通过火山引擎数智平台的智能洞察 DataWind 实现，通过可视化建模实现表白根底维度搭建，负责与动向人群沟通的员工能够依照 DataWind 赋予的编辑、查看权限随时实现对应内容填写，此外，产品提供的可视化查问和多套内嵌数据看板，能够根据不同需要实现数据展示。 第三个是面向车主的精细化经营，当线索胜利转化为汽车用户后，还须要继续对用户人群进行精细化经营，实现后链路服务的及时跟进。 通过 VeCDP 和火山引擎数智平台另一款数据产品增长剖析 DataFinder 联动，能够实现惟一车主辨认，并实现画像构建，再联合 VeCDP 内的标签联动，能够实现人群偏好归类，比方有的车主对福利类型内容敏感、有的车主在乎社交属性内容……在精准洞察用户需要的根底上，通过增长营销平台 GMP 实现对应营销内容的精准触达，往往能够受到更多欢送。 目前，火山引擎数智平台 VeDI 针对这三大汽车企业长期面临的营销场景问题，曾经提炼成为可随车企个性化需要而实现产品耦合的行业解决方案，并为多个头部车企所复用，在线索转化、客群定位、增值服务等细分场景取得实效。 此外，基于在服务客户过程中积淀的汽车行业数字化实践经验，火山引擎数智平台 VeDI 还特地设计「“5 事 7 计”汽车数字化营销能力在线评分表」，收费面向正在数字化转型过程中的汽车企业提供，通过表单填写即可在线评测本身数字化停顿水平，进一步理解外围问题归类及对应解决方案。 点击链接，开启评测：https://www.volcengine.com/pr... 点击火山引擎数智平台VeDI官网理解更多

文 / DataWind 团队封声 在应用 BI 工具的时候，常常遇到的问题是：“不会 SQL 怎么生产加工数据、不会算法可不可以做开掘剖析？”而业余算法团队在做数据挖掘时，数据分析及可视化也会出现绝对割裂的景象。 流程化实现算法建模和数据分析工作，也是一个提效的好方法。同时，对于业余数仓团队来说，雷同主题的数据内容面临“反复建设，应用和治理时绝对扩散”的问题——到底有没有方法在一个工作里同时生产，同主题不同内容的数据集？生产的数据集可不可以作为输出从新参加数据建设？ DataWind 可视化建模能力来了由火山引擎推出的 BI 平台 DataWind 智能数据洞察，推出了全新进阶性能——可视化建模。 用户可通过可视化拖、拉、连线操作，将简单的数据加工建模过程简化成清晰易懂的画布流程，各类用户依照所想即所得的思路实现数据生产加工，从而升高数据生产获取的门槛。 画布中反对同时构建多组画布流程，一图实现多数据建模工作的构建，进步数据建设的效率，升高工作治理老本；另外，画布中集成封装了超过 40 种数据荡涤、特色工程算子，笼罩初阶到高阶的数据生产能力，无需 Coding 实现简单的数据能力。 零门槛的 SQL 工具数据的生产加工是获取及剖析数据的第一步。 对于非技术使用者来说，SQL 语法存在肯定应用门槛，同时本地文件无奈定时更新，导致看板每次都须要手动重做。获取数据所需的技术人力往往须要排期，数据的获取时效及满足度大大打折，因而应用零代码的数据建设工具变得尤为重要。 下方列举两个典型场景，零门槛实现数据处理在工作中是如何利用的。 【场景 1】所想即所得，可视化实现数据处理过程在产品经营迭代急需不同数据的及时输出反馈时，能够形象数据的处理过程，通过可视化建模利落算子构建数据处理过程。如要获取依照日期、城市粒度的订单数及订单金额，并获取每日 Top10 耗费金额数据的城市数据，操作如下： 【场景 2】多表疾速联合，轻松解决多数据关联计算在数据处理过程中，有多个数据源须要进行组合应用，惯例通过 Excel 须要把握高阶 Vlookup 等算法有些难度，且耗时长。同时数据量较大时，电脑性能可能没方法实现数据的组合计算。 如有两份数据量比拟大的订单数据和一份客户属性信息表，须要依据账单金额和老本金额计算利润金额，而后依照利润奉献高下取 Top100 的用户订单信息。 AI 数据挖掘，不再高不可及当根底的数据荡涤曾经没方法满足数据建设和数据分析，须要 AI 算法加持去开掘数据更多暗藏的价值时。算法团队同学可能苦于无奈很好与可视化图表联动应用，没方法生产好的数据疾速被利用；而普通用户可能间接被 AI 代码的高门槛间接压灭了这个算法的苗头——提需要又怕需要太浅、价值无奈很好评估输入，此时算法开掘成为了一种奢望。 DataWind 的可视化建模封装了超过 30 类常见的 AI 算子能力，用户仅需理解算法的作用能够通过配置化的形式配置算法算子的输出和训练指标即可实现模型训练，依据配置的其余数据内容疾速失去预测后果。 特色工程算子（13）机器学习算子（22）自然语言解决算子 （3）AI 算子参数配置AI 模型训练成果 下方将以两个典型场景为例，看不写 Python 如何实现数据挖掘。 【初阶】不会 Python 也可做数据挖掘用户日常工作根本不波及写 Python，但存在做数据挖掘的需要场景。他须要基于存量高动向客户样本做客户动向度开掘。此时可通过可视化建模构建数据挖掘流程：1.拖入样本数据和全副数据作为数据2.输出拖入分类算法，如 XGB 算法用于模型训练3.拖入预测算子，搭建模型与全副数据的关系进行预测4.理论数据和预测后果联合输入数据集，从而剖析全副用户数据的动向散布 ...

Doris Summit 2022 将于 1 月 6 -7 日在线上正式举办，本次峰会共分 2 天进行，首日上午为主论坛：核心技术解析，下午为商业与数据生态分论坛，7日全天为行业用户最佳实际案例。大会汇聚了来自寰球顶尖云厂商、一线互联网企业、明星守业公司以及开源畛域的泛滥资深技术专家，旨在探讨和洞悉 Apache Doris 最新技术趋势、行业最佳实际、以及数据上下游生态利用。 其中在首日的主论坛上，来自 Apache 基金会、SelectDB、百度、美团、字节跳动等企业的社区外围贡献者将与大家一道： 回顾过去，如何在 Apache Way 的指引下打造一个弱小而凋敝的开源社区；立足当初，如何在用户实在业务的考验下实现核心技术个性的飞跃性提高；展望未来，如何在数据分析架构的改革中探明并引领技术演进趋势；一场精彩的技术盛宴，不容错过！ 议题介绍Doris in Apache“作为寰球最大的开源软件基金会，Apache 基金会的使命是为公众提供收费开源软件。随着多年的倒退，以 Apache Hadoop、Apache Spark、Apache Flink 等为代表的 Apache 我的项目简直形成大数据技术畛域的事实标准，Apache Doris 也正是因而成为 Apache 大数据生态的一员，并逐步成长为 Apache 顶级我的项目，取得了寰球开发者的关注与认可。 在这次演讲中，我将以 Apache Doris 的故事为例，为大家介绍如何基于 Apache Way 打造一个弱小而凋敝的开源社区，并帮忙开源我的项目获得最终的胜利。” 新起点、新征程，Apache Doris 社区回顾与瞻望“2022 年必然是 Apache Doris 倒退历程中至关重要的年份之一。在这一年，Apache Doris 的飞速停顿引人注目，社区贡献者和提交代码量成倍数增长，外围性能个性获得了全面进化，寰球范畴内用户企业规模超过 1000 家，并且于 6 月正式毕业成为 Apache 顶级我的项目。 在本次演讲中，我将与大家一起回顾过去一年来 Apache Doris 的里程碑时刻以及重要停顿，并揭晓 2023 年社区的重要布局以及 RoadMap。” ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群在精细化经营的时代，经营流动同样须要有精细化的策略，例如在年末大促流动中，设计 APP 弹窗揭示、满减、会员领券时，咱们能够针对不同生命周期、不同的行为门路的用户设置智能的经营策略，并联合 A/B 试验验证出更加无效的策略。 在这个需要背景下，火山引擎 A/B 测试（DataTester）推出了「流程画布」性能，它作为智能经营的重要能力之一，能基于用户个性化旅程，自动化的筛选用户、编排营销策略、设置触达动作、设计分流试验、确定转化指标、查看数据统计，最终实现高效增长。 值得注意的是，DataTester 的「流程画布」设计将业务场景与 A/B 试验紧密结合，相比于以往试验只能进行单条件、单事件的 A/B 试验剖析，「流程画布」试验能够将多个事件组合在一起，进行组合试验剖析。 以往的惯例 A/B 试验只能基于推送机会、推送文案、推送渠道等单个事件别离进行试验；而「流程画布」试验却能够将多个事件组合起来，试验不同事件的组合及程序的变动，综合评估策略的好坏。 可组合的事件包含触达程序、推送机会、推送次数、推送距离、推送文案等。下方以金融行业场景为例，介绍 DataTester 的「流程画布」利用。银行为了进步用户的 30 天入金率，即用户开卡后往银行卡内转钱的比例，经营团队会有一系列的动作进行用户触达，包含智能外呼、短信、push、企业微信等渠道。 他们须要找到针对不同人群的最佳用户触达门路组合，此时能够利用 DataTester 的「流程画布」能力进行 A/B 试验。 计划组合 A： 开卡当天，进行短信触达，短信触达文案有 3 种开卡次日，进行二次短信触达，短信触达文案有 3 种开卡 7 日后，进行智能外呼触达计划组合 B： 开卡当日，进行智能外呼触达，触达后立刻发送一个短信，短信文案有 3 种开卡次日，进行短信触达，短信触达文案有 3 种从开卡次日至 7 日，期间每 3 天进行一次 app push 推送，推送内容依据用户不同画像标签有所区别金融行业用户能够在 DataTester 中，开启对“计划组合 A”和“计划组合 B”的 A/B 测试成果监测，并能同时监测到两个计划组合中，不同的文案所带来的不同的转化成果。DataTester 的「流程画布」能力能够大幅扩大 A/B 测试在业务场景中的适用范围，晋升了 A/B 测试的易用性和实用性。 DataTester 是火山引擎数智平台旗下产品，可反对多种简单的 A/B 试验类型，通过抖音、今日头条等字节业务多年验证，截至 2022 年 8 月，DataTester 已在字节跳动外部累计实现 150 万次 A/B 试验。此外也曾经服务了美的、失去、凯叔讲故事等在内多家标杆客户，将成熟的“数据驱动增长”教训赋能给各行业。 ...

背景介绍近期，BitSail 社区公布了 Contributor 激励打算第一期，蕴含泛滥 issue，吸引了很多热衷开源的小伙伴的退出，详情可查看https://mp.weixin.qq.com/s/Gk... Issue介绍为了扩大 BitSail 的应用场景、适配用户的需要，BitSail 社区新增了十余 issue 来优化 BitSail 的性能。这次的 issue 蕴含了类型系统优化、connector 性能反对、测试笼罩等方面，欢送大家前来反对奉献！ 上面介绍局部新增 issue，这些 issue 在各方面对 BitSail 进行了优化。 1.应用优化：Mysql Reader 反对 schema 发现用户在应用 Mysql reader 时，须要在工作配置中指定 schema，即要读取列的列名和类型。Mysql reader 会依据用户配置拼出一个 select 语句，用以从 mysql 拉取数据。 这种形式的益处在于能够灵便地抉择 mysql 中的局部列进行读取。然而在理论场景中，用户往往须要读取 mysql 表中的全部列，这种时候 schema 配置就成为了一种累赘。下图展现了一个读取蕴含 4 列数据 mysql 表的 schema 配置。 "job":{ "reader":{ // 仅展现schema配置局部 "columns":[ { "name":"id", "type":"bigint" }, { "name":"name", "type":"varchar" }, { "name":"int_info", "type":"int" }, { "name":"double_info", "type":"double" }, { "name":"bytes_info", "type":"binary" } ] }}因而，本次 BitSail 社区新增一个 issue 用于优化 Mysql reader 的 schema 配置，心愿能在用户未配置 schema 信息时间接应用 mysql 表的元信息。https://github.com/bytedance/... ...

近日，上海创元化妆品有限公司（以下简称“创元团体”）与火山引擎数智平台 VeDI 达成单干，旨在进一步降级其在化妆品研发、制作、品质治理、销售、客户及供应商协同等全链路数智化能力。 作为寰球化妆品行业知名企业之一，创元团体业务范围涵盖化妆品尤其是彩妆的设计、研发、制作、供应链治理等全产业链畛域。其中，睫毛膏、眼线笔、眉笔、口红、粉饼等彩妆品类的技术水平处于行业领先地位，亦是诸多国内国内高端品牌的重要 ODM/OEM 合作伙伴。 2008 年，创元团体自有品牌“玛丽黛佳”成立，凭借独创的嫁接式睫毛膏迅速打响市场声量，并于次年实现由单品向品牌系列化的逾越，随后更成为第一个入驻丝芙兰的国货彩妆品牌。 开创之初，创元团体就与数字化深度交融，构筑实现了多条全自动化妆品生产线，极大晋升了生产效率和质检准确率。 往年 8 月，CCTV 总台记者曾探访创元团体，直播玛丽黛佳“AI 赋能 X 光机质检生产线”，该产线采纳创元团体与合作伙伴共同开发的 AI 智能 X 光检测设施进行产品无损全检——以眉笔为例，过来全检次要依赖人工旋进旋出，以 1 小时为单位，6 集体仅能全检 2500 批次生产；而应用 AI 智能 X 光检测设施，2 集体可能全检 3000 批次生产，人效进步了 3.6 倍。在检出准确性方面，人工全检后的产品缺陷率在 200ppm 左右，通过 X 光全检后的产品缺陷率则能够管制在 20ppm 以下。 图片起源：央视新闻直播 随着市场需求日益简单，以及自有品牌业务倒退须要，创元团体的全面数智化策略也在玛丽黛佳品牌经营端减速推动。过来十几年间，基于前一阶段的数字化工具，玛丽黛佳品牌曾经积淀了相当体量的市场、工厂、商品、销售数据，冀望可能通过与火山引擎单干，利用数智平台的产品服务，将本来庞杂的数据体系对立建设，更麻利高效地使用在客群洞察、市场营销等业务场景中。 据悉，在本次单干中，火山引擎数智平台将为创元团体和玛丽黛佳提供包含湖仓一体剖析服务 LAS、大数据研发治理套件 DataLeap、增长剖析 DataFinder 等在内的多款数据产品。 前两者可能通过对接来自业务、智能制作等多个零碎的离线、实时数据，帮忙创元团体建设从数据集成、存储、离线和实时数据加工的残缺链路，并以此为根底构建可面向营销、生产、IOT 数据管理的综合性数据中台。 后者则可反对玛丽黛佳在商城、APP 以及小程序等在内的渠道实现埋点部署，实时洞察和用户全生命旅程剖析，帮忙玛丽黛佳能够更清晰地捕获市场趋势偏好，以及流量起源、追踪和转化。 图片起源：创元团体 单方示意，这次牵手只是开始，随着单干的逐渐深刻，创元团体还将和火山引擎数智平台有更多待开掘的机会点。 截至目前，火山引擎数智平台曾经服务来自互联网、汽车、批发、金融等多个行业在内的数百家标杆企业，包含失去、陕西游览、上海家化、万达、吉利领克、联合利华、海王团体、李维斯，并在数据根底建设、市场洞察、智能营销等多个数智化场景中取得实效。 点击火山引擎数智平台VeDI官网理解更多

往年天猫电商、京东均示意交易规模与 2021 年持平，跟今年急剧增长的销售额相比，往年的双十一显得稍微“平静”。2022 年双十一当天快递数是 5.5 亿，2021 年同期快递数为 6.7 亿，降落幅度达到 20%左右，依据艾媒的调查报告显示，消费者对双十一感兴趣的水平大略降落了 20%左右。 但在往年双十一的生产背景下，缓缓买的各方面数据却失去比拟大幅的增长。双十一期间，缓缓买帮忙用户查问商品历史价格，避坑 6120 万次，整体 GMV 的增长同比达到了 81.6%。此外订单量以及新用户数，同比增长也都达到了 50%以上。 缓缓买是一个可能跨平台查问商品历史价格的工具类软件，数据笼罩了淘宝、京东和拼多多等搜寻电商，次要对消费者提供历史价格走势、全网比价以及整顿底价商品的聚合页等服务。 用户复制一个商品的链接到缓缓买，就能够看到商品整个的历史价格走势图。以手机通信服务为例，由缓缓买提供的数据图可知，在 iPhone 13 刚刚公布时，价格稳定围绕着最低点 4690 元到最高点 6088 元的数值范畴稳定。消费者通过查问价格历史图，能够无效地做出生产决策，从而达到省钱的目标。 （缓缓买 APP 截图） 缓缓买的胜利离不开由火山引擎 A/B 测试平台—— DataTester 的帮忙。作为一个互联网化的数据比价平台，缓缓买的运行离不开大量的 A/B 测试和数据分析，而火山引擎 DataTester 为企业节约了大量工夫老本和人力老本。 在缓缓买以往传统的 A/B 测试流程中，不仅须要有一个业余的经营人员来进行试验操作，而且还须要一个产品经理+前端+后端的技术团队，实现试验上的技术支持。 而 DataTester 便捷的流程大大降低了 A/B 测试的施行门槛，任何工作人员都能够独立实现整个 A/B 测试的全副过程，并且一个人力就能同时操作 5 到 10 个 A/B 测试。缓缓买的产品版本公布和版本更新，都会通过 DataTester 小规模的 A/B 测试去验证，比起其余 A/B 测试的产品，DataTeater 在躲避危险、升高测试的流程和老本上都更胜一筹。 缓缓买做过整体计算，A/B 测试能够为产品晋升 17%的转化率，而他们在 DataTester 中，均匀两到三天就能够实现一个试验配置。截至 2022 年 11 月，DataTester 曾经撑持缓缓买实现了 173 个试验。通过 DataTester，缓缓买可能高效优化产品，这也成为了它在以后的经济局势下，仍然维持较高增长的重要起因之一。 ...

2002 年 10 月 18 日，我国第一个国家信息化布局出台，预示着信息化建设正式驶入快车道。随后几年，借势互联网高速倒退的东风，以及宽带中国策略、“互联网+”策略、大数据策略等国家级策略陆续确定，大多数传统企业在市场变动和政策疏导的双重推动下，接触到了初步的数字化降级：数控系统、ERP 软件等在金融、制作、批发、餐饮等多个行业深刻利用。 彼时的数字化降级，多聚焦于解决业务场景一直减少、数据利用需要日益频繁，因而在降级过程中谋求疾速响应业务需要，这也导致很多企业的数字化建设出现“烟囱式”特点，即一条业务线对应一套数字化流程。 但很快企业就发现，随着本身业务幅员的继续扩充，以及数据量级几何式暴发增长，“烟囱式”建设带来的弊病也日渐浮现。 首先是建设老本问题，对企业来说，烟囱式的数字化建设必然造成了数据的反复加工，这也间接导致研发效率、数据存储和计算资源的节约；其次，业务间的数据互相割裂，无奈高效流通，而且因为各个业务零碎的数据指标口径并不统一，这也减少了跨零碎数据整合利用的老本。 而数据中台理念的衰亡，给予了企业数据基础设施建设的新门路。从架构上来看，数据中台与过来的“烟囱式”建设有着显著区别。 数据中台借鉴了传统数仓面向主题域的数据组织形式，基于维度建模实践，构建对立的数据公共层和应用层，同时可能依赖大数据平台实现数据研发全流程，并减少了数据治理、数据资产以及数据服务化内容。 这样的益处在于，可能在进步数据共享能力的根底上，帮忙企业躲避数据的反复加工，并以数据服务化的模式撑持业务场景的数据利用。火山引擎数智平台 VeDI 凭借丰盛可耦合的数据产品矩阵及 9 年外部实际，积攒了丰盛的数据中台建设教训。 本月 20 日下午 19 点，火山引擎数智平台 VeDI「超话数据」栏目将推出《火山引擎 VeDI 数据中台架构分析与计划分享》直播流动，深度分析字节跳动 9 年实践经验。 通过详解 VeDI 大数据开发套件 DataLeap、开源大数据平台 EMR、湖仓一体剖析服务 LAS 等多款数据产品，最直观地还原企业在构建数据中台时可能面临的问题，以及包含数据采集、数据集成、数据治理、数据计算等在内的多环节链路难点和解决方案。 目前流动已凋谢报名，微信扫码即可进入社群预约。 点击火山引擎数智平台VeDI官网理解更多

在数字化转型的大趋势下，“数据”成为新的生产因素已达成共识，如何更好进行数据分析成为了数据价值开掘的要害伎俩。而当下大多数企业坐拥海量数据，而因资源限度、原架构冗余、数据难以迁徙等问题，导致数据的实时性及准确性无奈失去保障，数据的价值也大打折扣，数字化转型也遭逢瓶颈。 作为当今业界最为风行的实时剖析型数据库之一， Apache Doris 自开源伊始的指标就是为了帮忙更多人解决数据分析的难题。凭借极致的剖析性能、极简的应用体验以及极度沉闷的开源社区，Apache Doris 助力了寰球范畴内超过 1000 家企业用户构建了高效的数据分析平台和服务、帮忙业务决策效率获得卓越晋升、并已成为数字化时代企业实现转型的重要基石。 咱们欣慰地看到，从开源至今，Apache Doris 的初心始终未变，始终致力于帮忙更多人充沛享受数据带来的魅力。而展望未来，Apache Doris 又将如何引领数据分析技术的浪潮、带来一场怎么的数据架构新改革？ 所有答案皆在 Doris Summit 2022！ 本次峰会将于 1 月 6 -7 日于线上正式举办，分为核心技术解析、商业与数据生态、行业最佳案例 3 个论坛，您能够追随来自 SelectDB、百度、腾讯、美团、小米、京东、字节跳动、阿里、AWS、网易、360 等泛滥知名企业的技术大咖，围绕 Apache Doris 的最新技术趋势、行业最佳实际、数据上下游生态、企业级产品个性等，一道享受这场技术盛宴！ 残缺议程 收费报名报名地址： http://hdxu.cn/PpMyh 致谢本次峰会由 SelectDB 主办，百度智能云、腾讯云联结主办，感激不遗余力地筹备首届 Doris Sunmmit ，感激在人力、物力及工夫上的诸多投入。同时也非常感激以下合作伙伴、媒体合作伙伴，踊跃为 Doris Summit 2022 发声，对扩充大会影响力产生了至关重要的作用。 （排名不分先后，依照首字母程序进行排列） 对于 Doris SummitDoris Summit 是 Apache Doris 社区举办的年度技术盛会，大会汇聚世界各地 Apache Doris 社区成员及实时剖析数据库畛域的专家。社区通过大会颁布最新动静及年度 Roadmap，集结国内外各大厂商分享基于 Doris 的实践经验及行业将来发展趋势，更有畛域内大咖与大家在线互动交换。这是相干畛域从业者不可多得的技术盛宴，不容错过，期待您来加入！ 对于主办方SelectDB 是 Doris Summit 2022 的主办方，也是 Apache Doris 背地的商业化公司。SelectDB 致力于为 Apache Doris 社区提供一个由全职工程师、产品经理和反对工程师组成的团队，凋敝开源社区生态，打造实时剖析型数据库畛域的国内工业界规范。基于 Apache Doris 研发的新一代云原生实时数仓 SelectDB，运行于多家云上，为用户和客户提供开箱即用的能力。 ...

DataTester 是字节跳动在 2019 年正式通过火山引擎数智平台推出的对外服务的 A/B 试验工具，它基于先进的底层算法，提供迷信分流能力，提供智能的统计引擎，试验后果牢靠无效，助力业务决策。 让中小企业也能借助字节跳动的技术力量拥抱最新的产品趋势，融入字节跳动的各种方法论，打造更加优良的产品。DataTester 在字节内每日新增 1500+试验，累计已有 150W+ 的 A/B 试验进行过。 在内部客户的服务上，也已笼罩举荐、广告、搜寻、UI、产品性能等业务场景，提供从实验设计、试验创立、指标计算、统计分析到最终评估上线等贯通整个试验生命周期的服务。来自失去、美的、凯叔讲故事 APP 等企业客户，曾经通过火山引擎 DataTeser 开启了用数据驱动科学决策的路线。 点击 火山引擎DataTester官网 理解更多 一、初阶1.AB 试验为了验证一个新策略的成果，筹备原策略 A 和新策略 B 两种计划。随后在总体用户中取出一小部分，将这部分用户齐全随机地分在两个组中，使两组用户在统计角度无差别。将原策略 A 和新策略 B 别离展现给不同的用户组，一段时间后，联合统计办法剖析数据，失去两种策略失效后指标的变动后果，并以此判断新策略 B 是否合乎预期。 上述过程即 A/B 试验，亦被称为“对照试验”或“小流量随机试验”。2.互斥组互斥组，也称互斥层、试验层。“试验层”技术是为了让多个试验可能并行不互相烦扰，且都取得足够的流量而研发的流量分层技术。 举个例子，如果我当初有 4 个试验要进行，每一个试验要取用 30%的流量才可能得出可信的试验后果。此时为了同时运行这 4 个试验就须要 4*30%=120%的流量，这意味着 100%的流量不够同时调配给这 4 个试验。 那么此时咱们只能抉择给试验排序，让几个试验先后实现。但这会造成试验效率低下。试验层技术就能够完满解决这个问题。 咱们把总体流量“复制”无数遍，造成无数个流量层，让总体流量能够被无数次复用，从而进步试验效率。各层之间的流量是正交的，你能够简略了解为：在流量层抉择正确的前提下，流量通过迷信的调配，能够保障各试验的后果不会受到其余层试验的烦扰。 3.互斥试验互斥试验：互斥组中的所有试验都不会共享用户，如果一个用户/设施命中了试验 A，就不会命中该互斥组中的其余试验。 举例，你要同时做按钮色彩和按钮形态的试验，就须要将两个试验退出到一个互斥组列表。4.正交试验互斥组=互斥层=试验层 每个独立试验为一层，一份流量穿梭每层试验时，都会随机打散再重组，保障每层流量数量雷同。如何了解流量正交？ 举个例子。假如我当初有 2 个试验。试验 A（实验组标记为 A1，对照组标记为 A2）散布于试验层 1，取用该层 100%的流量；试验 B（实验组标记为 B1，对照组标记为 B2）散布于试验层 2，也取用该层 100%的流量。（要留神，试验层 1 和试验层 2 实际上是同一批用户，试验层 2 只是复用了试验层 1 的流量）援用如果把 A1 组的流量分成 2 半，一份放进 B1 组，一份放进 B2 组；再把 A2 组的流量也分成 2 半，一份放进 B1 组，一份放进 B2 组。那么两个试验对于流量的调用就会如下图所示。此时试验 A 和试验 B 之间，就造成了流量“正交”。流量正交有什么意义呢？ ...

摘要：本文整顿自 Apache Flink PMC&Committer 伍翀（云邪）在 9 月 24 日 Apache Flink Meetup 的演讲。次要内容包含： Hive SQL 迁徙的动机Hive SQL 迁徙的挑战Hive SQL 迁徙的实际Hive SQL 迁徙的演示将来布局 点击查看直播回放 & 演讲PDF 一、Hive SQL 迁徙的动机 Flink 曾经是流计算的事实标准，以后国内外做实时计算或流计算个别都会抉择 Flink 和 Flink SQL。另外，Flink 也是是妇孺皆知的流批一体大数据计算引擎。 然而，目前 Flink 也面临着挑战。比方尽管当初大规模利用都以流计算为主，但 Flink 批计算的利用并不宽泛，想要进一步推动真正意义上的流批一体落地，须要推动业界更多地落地 Flink 批计算，须要更踊跃地拥抱现有的离线生态。以后业界离线生态次要以 Hive 为主，因而咱们在过来版本中做了很多与 Hive 相干的集成，包含 Hive Catalog、Hive 语法兼容、Hive UDF 兼容、流式写入 Hive 等。在 Flink 1.16 版本中，咱们进一步晋升了 HiveSQL 的兼容度，还反对了 HiveServer2 的协定兼容。 所以，为什么 Flink 要去反对 Hive SQL 的迁徙？一方面，咱们心愿吸引更多的 Hive 离线数仓用户，通过用户来一直打磨批计算引擎，对齐支流批计算引擎。另一方面，通过兼容 Hive SQL，来升高现有离线用户应用 Flink 开发离线业务的门槛。除此之外，另外，生态是开源产品的最大门槛。Flink 曾经领有十分丰盛的实时生态工具，但离线生态仍然较为欠缺。通过兼容 Hive 生态能够疾速融入 Hive 离线生态工具和平台，升高用户接入的老本。最初，这也是实现流批一体的重要一环，咱们心愿推动业界尝试对立的流计算和批计算引擎，再对立流计算和批计算 SQL。 ...

作者：张高迪（花名杳天），Hologres研发。 同传统MySQL数据库，Hologres反对Hologres binlog，记录数据库中所有数据的变动事件日志。通过Hologres binlog，能够十分不便灵便的实现数据之间的复制、同步。同时在大数据场景上，反对Flink间接生产Hologres Binlog，相较于传统数仓分层，Flink+Hologres Binlog能够实现残缺的事件驱动，实现ODS向DWD，DWD向DWS等的全实时加工作业，满足分层治理的前提下对立存储，晋升数据复用能力，并且大大缩短数据加工端到端提早，为用户提供一站式的实时数据仓库解决方案。在本文中，咱们将会介绍Hologres Binlog技术实现原理以及应用最佳实际。 Hologres Binlog介绍1、什么是Binlog?Binlog即二进制日志（Binary Log），这个概念常见于MySQL数据库，是用来记录数据库所有可能引起数据变动事件的日志，比方表构造变更（例如CREATE、ALTER TABLE…）以及表数据批改（INSERT、UPDATE、DELETE…）事件。 MySQL Binlog最后有两个主要用途： 主从复制：主服务器将其Binlog文件中蕴含的事件发送到从服务器，从服务器执行这些事件以进行与主服务器雷同的数据更改，从而保障主从服务器之间的数据一致性。数据恢复：通过从新执行Binlog文件中记录的事件，使数据库复原到产生问题之前最新的状态。Binlog也被用作流式的数据源。用户经常通过Debezium或者阿里开源的 Canal等数据采集工具，采集Binlog作为流式的数据源，从而实现数据从MySQL到其余类型数据库的数据同步，个别先将采集的数据输入到消息中间件如Kafka等，而后通过Flink引擎去生产数据并进行相应计算，最终写入到目标端。目标端能够是各种 DB，数据湖，实时数仓和离线数仓等。 2、Hologres Binlog与传统数据库Binlog的区别Hologres Binlog与传统数据库Binlog的次要区别在于，前者个别只用于数据同步，而后者还利用于主从实例同步和数据恢复等高可用场景。因而两者的实现也有了肯定的差异，次要体现在以下方面： Hologres的高可用通过基于WAL log复制实现的物理Replication来保障，详见技术揭秘：从双11看实时数仓Hologres高可用设计与实际。Hologres Binlog不会记录DDL操作。Hologres的Binlog次要面向数据生产，不反对记录表构造变更（如CREATE TABLE、ALTER TABLE 等DDL）操作，只记录数据变更记录（INSERT、UPDATE、DELETE），记录形式相似MySQL Binlog的 ROW（row-based replication）模式，会残缺的记录每行数据的变更状况。 Hologres Binlog较为灵便，是表级别的，能够按需关上和敞开，且能够为不同的表设置不同的TTL。MySQL 开启Binlog是实例级别的，个别会占用比拟多的存储，并且关上Binlog往往须要重启集群；而Hologres 的Binlog更加细粒度，能够在应用中按需对某张表进行开启和敞开，并为不同的表设置不同的Binlog存活工夫，齐全不影响实例中的其余数据库和数据表，关上Binlog只会多出一份表级别的存储。 Hologres Binlog能够十分不便的进行查问。在应用中，用户能够通过在query中增加 hg_binlog_lsn,hg_binlog_event_type,hg_binlog_timetsamp_us 这三个字段来查问表的Binlog。如果查问的字段蕴含了上述三个字段之一，如select hg_binlog_lsn, * from test_message_src;便会主动路由到Binlog表进行查问。相对而言，用户在MySQL想要查看Binlog则不够直观，须要通过show binlog events命令或者MySQL Binlog工具去解析Binlog文件。须要留神的是，Hologres Binlog底层采纳行存表存储，因而在查问时，举荐过滤条件中蕴含hg_binlog_lsn字段来保障查问效率，依照其余业务字段查问会演变为全表扫描，表数据量大时查问会比较慢，应该尽量避免。 Hologres作为分布式的实时数仓，Binlog同样也是分布式的。Hologres Binlog与一般的Hologres表数据一样，散布在不同的shard上，读取Binlog等操作也以shard分片，相似kafka的partition，具体能够看下方的实现原理。 总的来说，Hologres Binlog能够简略的定义为：能够按需开关的，以行为单位记录Hologres某张表数据变更记录（INSERT、UPDATE、DELETE）的二进制日志。能够看到，Hologres Binlog自设计起便是为实时生产和用户应用而生的，相比MySQL Binlog领有的历史包袱，更加易用和灵便。 3、Hologres Binlog格局Hologres 的Binlog蕴含如下字段。 字段阐明： 阐明： UPDATE操作会产生两条Binlog记录，别离为更新前和更新后的记录。订阅Binlog性能会保障这两条记录是间断的且更新前的Binlog记录在前，更新后的Binlog记录在后。用户字段的程序与DDL定义的程序统一。Hologres Binlog应用场景1、数据实时复制、同步Hologres通过Binlog实现了逻辑Replication，从而能够订阅Binlog进行数据的复制和同步。 典型的逻辑复制应用场景有： 1、把一张Hologres的行存表复制成一张列存表，行存反对点查点写，列存反对多维分析型需要。 比方在阿里CCO的应用场景中，写入Hologres行存表的数据，会通过Hologres Connector Binlog订阅，将公共层明细数据有抉择的进行二次计算，并写入回Hologres列存应用层明细表中，提供给不同的应用层剖析和汇总场景。Hologres 1.1版本开始反对了同一张表行列共存的模式，须要通过Binlog手动实现行存转列存的场景更少了。 2、部分更新之后通过Binlog驱动整行计算 一些场景中，DWD层的数据更新之后，用户上游的计算逻辑须要残缺的表字段，但传统数据仓库可能反对的不够欠缺。比方阿里CCO在之前的架构中应用Lindorm，想要拿到残缺的表字段，就须要通过Hlog订阅，触发流工作反查事实表，将宽表字段对齐之后再输入到上游。而Hologres的Binlog，即便只更新局部字段，也会生成一条蕴含整行数据的Binlog。依据这种个性，部分更新也能够驱动整行数据的计算，无需反查便能够供应用层生产。 ...

作者：陆晨炜（花名遣云）阿里巴巴智能引擎事业部数据开发 前言： 2022年的双11，阿里淘宝搜推集群承载上千万每秒的的流量峰值，消费者的每一次浏览、点击都通过搜推集群进行流转，与今年双11不同的是，降本增效在往年也变成了特地重要的一个技术课题。在此背景下，阿里搜寻举荐团队与Hologres深度单干，在技术上，通过将传统的Text Array降级为JSONB，并应用JSONB列式存储，相比去年双11实现查问性能晋升 400%+ ，存储降落45%，共资源节俭数千core（预计节省成本数百万元），承受住双11生产稳定性考验，真正实现降本增效。 通过本文咱们将会具体介绍Hologres JSONB在阿里搜寻举荐团队的实际，以帮忙更多企业通过技术手段助力业务快速增长。 业务介绍阿里巴巴搜寻举荐事业部的实时数据仓库承载了阿里巴巴团体淘宝、淘宝特价版、饿了么等多个电商业务的实时数仓场景，提供了包含实时大屏、实时报表、实时算法训练、实时A/B试验看板等多种数据利用反对。从2019年开始，搜寻团队开始与Hologres进行共建，通过Hologres撑持了搜寻举荐的多个利用场景，包含即席多维分析，A/B test等，详情能够查看往期精彩内容： 阿里巴巴电商搜寻举荐实时数仓演进之路 Hologres在阿里搜寻举荐实时数据场景下即席多维分析的最佳实际 通天塔是搜寻团队对外提供的实时数据分析产品，提供了手淘搜寻、手淘举荐、拍立淘等多个业务的实时A/B报表服务，其重要性能之一为对A/B试验进行实时的比照观测。举个例子，算法同学须要看试验分层layerA下的1、2两个分桶的成果比照，须要从实时的数据别离统计 layerA:1、layerA:2 两个桶的指标，并计算GAP值。算法同学通常会通过通天塔报表查问实时的A/B试验成果，并对算法模型进行评估和调整。在实时报表中，咱们还提供了各种保护的筛选项帮忙用户对数据进行深入分析，如：用户属性、商品属性、类目属性、卖家属性等。 下图为通天塔次要的实时数据链路示意图，咱们将采集到原始日志从TT（Datahub）中读取，在Flink流作业中，咱们会对日志进行ETL解决，其中包含依据日志中的用户ID、商品ID、商家ID等关联对应的维表，并将相干属性字段一起存储到Hologres表，最初通过实时报表生成SQL Query，进行实时数据的查问剖析。 咱们近年来始终应用Hologres作为通天塔的实时数据查问引擎，因为咱们的业务场景中，有很多的用户标签、商品标签、卖家标签和算法桶号等多值属性，以用户标签为例，业务上对用户的画像属性不是变化无穷的，业务可能随时须要新增一类属性进行观测，如果每次都须要用一个新的字段来存储新的用户属性，那在整个实时链路上都会显得低效。因而在建表时，咱们通常应用Text Array(text [])类型作为多值字段的存储格局。 用户属性相干的标签都会以Text Array的模式存储到同一个字段中，须要业务有变动须要新增字段，Flink工作、Hologres表、实时报表中都不须要进行额定的批改。这从运维效率和数据时效性来看，都是很适合的抉择。对于商品、卖家等属性标签和算法桶号，也同样是这些长处驱动咱们抉择了应用Text Array，并稳固撑持了历年的双11，其中2021年双11 Text Array的均匀查问提早为1070ms。 但Text Array也并不是白璧无瑕的，在无限的资源配置下，当查问QPS较高时，尤其是大促期间，咱们会遇到查问慢、查问超时的问题，经剖析这与Text Array本身在查问性能上的限度有较大关系，这就使得咱们不得一直累加资源来晋升性能，从而也导致咱们的老本剧增。 为了解决这一问题，并实现降本提效的指标，本次双11前，通过与Hologres团队的单干，咱们胜利将Text Array 降级为性能更高、存储更低的 JSONB 格局作为算法桶号、用户标签等多值字段的存储格局，并在往年双11生产路落地，撑持上百万写入RPS，查问性能晋升400%+，节约数千core资源。 业务实际：Text Array格局降级为JSONB格局1. 原Text Array格局1.1 表构造与数据示例咱们之前应用Hologres（Text Array格局）存储了实时的明细数据，表的构造如下： CREATE TABLE wireless_pv ( second_timestamp timestamp with time zone NOT NULL, pk text NOT NULL, uid text NOT NULL, item_id bigint NOT NULL, seller_id bigint NOT NULL, cate_id bigint, bts_tags text[] NOT NULL ,PRIMARY KEY (pk, user_name));这张表为曝光明细表，其中次要的字段包含： ...

2022年8月2日， TPC事务处理性能委员会官网正式公布了星环科技在3TB数据量下的TPCx-AI测试后果，Sophon Discover 3.0以AIUCpm 2,740.05分的优异体现，成为该数据量下寰球首个胜利通过测试及官网审计的产品，也是截至目前该AI基准测试最大的数据量级。 TPCx-AI，贴合理论人工智能应用场景的Benchmark TPC（Transaction Processing Performance Council）全称为事务处理性能委员会，是寰球最出名的数据管理系统测评基准标准化组织。TPCx-AI是TPC组织定义的一种端到端AI基准测试规范，用于掂量机器学习或数据迷信平台的在AI端到端流水线中的性能。该AI基准测试对于数据处理量级、运行便捷性、性价比、宽泛适应性、ML&DL性能均做出要求，并需通过官网审计。TPCx-AI规范要求测试厂商领有人工智能畛域的技术能力，还须要提供残缺的软硬件解决方案和一站式的人工智能平台，并在AI前沿畛域具备突破性钻研。 TPCx-AI测试规范共提供10个机器学习和深度学习测试用例，涵盖客户分类、客户对话转录、销售预测、垃圾邮件检测、价格预测、分类和欺诈检测等利用场景。每个用例都蕴含：数据生成、数据管理、模型训练、模型评分和模型推理阶段。区别于其余AI基准，TPCx-AI应用多模态的数据集（蕴含结构化和非结构化的图像、音频等多模态数据格式），并可扩大到TB级别；数据管理阶段蕴含数据荡涤、数据摸索和预处理等过程，理论模仿了商业生产环境的数据处理流程。最初应用数据集进行模型训练、模型推理和模型评估。 AI测试用例的端到端流程 秉持研发翻新技术初心，星环科技朝TPCx-AI进发 作为长期从事大数据和人工智能根底平台研发的企业，一方面星环科技放弃凋谢的心态与业界共同进步，因而有责任和TPC一起，欠缺TPCx-AI这项在靠近企业生产环境中的人工智能（含机器学习）产品和计划的基准测试，为机器学习平台行业提供基线；另一方面，星环科技始终谋求技术自主性和先进性，一直测验本身产品体系和框架在以后业界支流人工智能场景中的线性扩展性、高性能、高性价比和宽泛适应性；此外，TPCx-AI作为首个端到端大数据+人工智能的数据迷信Benchmark，有对场景了解、大数据技术、AI迷信与技术的多重挑战，这和公司谋求的“把自主研发的当先翻新技术赋能全世界各行各业，促成社会可继续倒退，通过科技让人类的生存更美妙”的主旨也是高度符合的。 “简单计算环境”、“AI全流程”、“多模态”——大数据与AI交融的基准测试所带来的一系列挑战 简单的计算环境 TPCx-AI是规范的大数据和AI软件异构混合计算环境，其中大数据相干的装置软件包含：Hadoop、Spark、Yarn、HDFS、Horovod等，AI相干的装置软件包含：Tensorflow、Keras、Sklearn、XGBoost、Pandas等；同时也是规范的硬件异构混合计算环境，同时蕴含CPU减速和GPU减速，以及单机减速和分布式集群减速。一方面较为考验平台对于大数据和AI异构混合计算环境的适应性，另一方面对于不同品种硬件的异构运算，也提出了能力要求。 AI全流程的测试场景 TPCx-AI的测试场景蕴含数据生成、数据管理、模型训练、模型推理、模型评估、吞吐量并发测试，蕴含了端到端的数据迷信全流程，须要平台具备AI全生命周期的能力。 丰盛的测试用例 TPCx-AI共提供10个测试用例，蕴含7个机器学习模型和3个深度学习模型，模型波及有监督学习和无监督学习。其中，用例9应用的是混合模型（模型构造为：embedding神经网络+LogisticRegression）。对于平台而言，须要解决性能优化瓶颈，并且无效解决CPU/GPU密集型计算、IO密集型计算、内存密集型计算等多样的计算类型。 多模态的数据类型 区别于其余AI基准，TPCx-AI应用的是多模态的数据集，蕴含结构化和非结构化（图像、音频等）多种数据格式，对于平台多源异构的数据处理及剖析能力提出了要求。该测试集可扩大到TB级别，是将大数据与人工智能技术进行交融测试的场景。 “更快”、“更少”、“更极致”——一直摸索软件的可能性 为了应答上述挑战，星环科技对软件做了大量的优化工作，从而实现了内存占用更少、计算更快、产品更加极致的指标，具体优化工作如下： Spark参数优化/ UseCase参数优化：深刻理解每个UseCase的逻辑，剖析执行细节，确定优化方向；通过监控系统资源应用状况以及监控JVM中GC状况，对每个UseCase的Spark参数进行优化。针对不同UseCase的性能瓶颈：计算、IO、内存、通信，在TPCx-AI官网要求精度范畴内以及可批改参数范畴内，对UseCase自带参数进行调试最优化；联合RDMA、GPUDirect根底技术尝试晋升节点与集群的整体计算和通信性能；对模型训练及推理过程尝试编译级别优化，充分发挥CPU向量计算、GPU并行计算性能；应用混精、剪枝、蒸馏等技术尝试优化模型，内存占用更少，计算更快。一款自主研发的数据迷信平台，终在国内基准测试中获亮眼体现 至此，星环科技正式向TPCx-AI发动挑战。历经前后半年工夫，星环科技的数据迷信平台Sophon Discover别离进行了TPCx-AI scale factors为100GB、1TB、3TB的测试。其中，1TB数据的性能体现为1696，比4月TTA公布的性能后果高出超出491分，比8月DELL公布性能后果仍然超出218分。当然，咱们不满足于1TB数据的性能测试后果，向着3TB数据规模发动挑战，最终成为寰球首个通过TPCx-AI scale factors为3000基准测试及官网审计的厂商，且性能达到了2740.05。与同数据量下的其余后果相比，Sophon Discover每节点可奉献456.68的性能得分，优于CDP每节点奉献390.19的性能得分。 从颁布的测试后果不难看出，Sophon不管从数据量级、性能体现、性价比及自主性方面均达到了最优的问题。 值得一提的是，在所有颁布的测试后果当中，只有星环科技应用的是齐全自主研发的国产数据迷信平台。除了能够保障用户的平台应用平安外，此次基于数据迷信平台Sophon Discover 3.0的测试后果，也是真正意义上可理论商用的AI测试后果，其配置合乎企业理论落地AI利用时，应用分布式集群的商用配置。 建言献策，为国内基准测试奉献中国技术力量 在进行产品测试的过程中，咱们也发现了多处BUG并帮忙TPC欠缺了TPCx-AI套件的代码逻辑，使得测试环境更加稳固。此外，星环科技向TPC组织提出了TPCx-AI@Sophon测试计划，最终该计划通过了委员会审核，成为被官网认可的国内基准测试框架。今后，其余厂商能够在他们的硬件下面运行基于Sophon 的TPCx-AI测试套件，用于掂量硬件的性能。 至此，星环科技也成为了TPCx-AI的技术贡献者之一，为国内基准测试奉献了来自中国的技术力量。 作为寰球首家通过3TB TPCx-AI国内基准测试及官网审计的企业，星环科技为企业AI利用的商用落地摸索出了一条可行路线。将来，星环科技也将秉持“自主原创，当先一代”的技术倒退策略，为用户提供更强性能和更高性价比的人工智能框架和平台，在数字化转型之路上，以技术之力帮忙用户解决AI落地难题，更深刻地洞察数据价值。

作者: 舟柒、楼台 1. 业务背景与挑战1.1 实时计算集群现状对于热点机器解决始终是阿里云 Flink 集群运维的一大痛点，不论在日常还是大促都曾经是比较严重的问题，同时这也是分布式系统的老大难问题。而在往年整个阿里云老本管制的背景下，随着集群水位的逐渐抬升，热点问题愈发重大。日均有上千次的热点机器呈现，并且在早晨业务高峰期，整个热点持续时间会超过 60min，对于业务以及对于平台影响是比拟大的。 这里的影响是体现在稳固，老本，效率三方面的，首先热点会导致作业的局部节点延时，高 SLA 要求工作的性能得不到保障，相似于上面这张图。其次，受热点机器这个短板的影响，整体集群水位没有方法进一步抬升，影响老本管制。最初在咱们没有一个比拟好地机制去解决热点的状况下，是须要人肉并且十分被动地去解决热点，费时费力，影响效率。 面对全面影响运维畛域（稳固老本效率三个方面）的热点问题，咱们开发的 Flink 集群的自愈零碎，出发点就是要解决 Flink 集群的热点机器问题。 1.2 热点问题剖析接下来具体分析为什么会产生机器热点。实际上不论说集群是 20% 还是 60% 的物理水位，整体集群的物理资源对于承载业务来说都是够用的，K8S 的调度器默认会依照作业的 request 值去尽量平铺。然而目前阿里云的 Flink 集群是容许工作进行超用的，就会呈现上面这个图的状况。 当工作配置不合理时，会导致局部的 Pod 超用，局部 Pod 不超用。使得机器之间尽管 request 差距不大，然而理论的usage 就会偏差比拟大，毛刺的局部节点就会成为热点机器。下面这幅图咱们能够看到一台机器上 Pod 的理论耗费在业务高峰期会超过整体的申请值，这个时候就会造成热点机器。 咱们能够得出结论：热点的呈现与水位绝对值多少没有必然关系，而与作业的超用水平正相干。因而 Flink 热点的治理都是围绕着解决作业超用问题开展的。 2. 老本优化 - 热点解决2.1 热点机器解决思路面对热点机器问题，能够分为「大促」与「日常」两类场景。 针对大促场景，任何在大促峰值期间做的运维操作，对于业务来说都是有损的，因而要尽量避免大促期间产生热点而去执行运维操作，然而咱们通常能够通过压测去正当地预估作业在峰值的行为，通过一些提前的预测的办法在大促前躲避作业超用，从而躲避热点的呈现。因而，咱们设计了一套基于作业的画像零碎，在热点产生的事前去干涉热点的呈现。 针对日常场景，在 7*24 小时保障要求下，热点产生的频次高且类型多。叠加用户操作，平台变更等非预期行为烦扰，往往热点的呈现是绝对随机且没有方法提前预测的。咱们开发了热点的事中自愈能力，谋求热点隐患呈现后的疾速打消，当热点隐患产生后，可能在敏感工作受影响的时效内实现热点压抑。而与之相配套的预先复原与运维可观测性能力也同步建设。 整体的思路上，仍是围绕解决超用工作来做，事先画像是提前躲避超用，事中自愈则是对超用的工作进行应急解决。针对热点产生的工夫线，造成了事先画像，事中自愈，预先复原，可观测性四局部的热点机器解决方案。接下来我会具体开展介绍这四个局部的能力。 2.2 事先画像2.2.1 业务流程首先什么是事先画像。后面提到的，事先画像是针对大促场景下，通过对超用工作的提前躲避，来实现打消热点的计划。要提前躲避工作超用，就须要作业在大促峰值的资源配置是精准的。然而目前参加大促的工作，往往作业拓扑是非常复杂的，且作业的数量十分微小。单纯的依附数据研发同学人肉地去调优每个工作的每个节点是不事实的。因而，事先画像就是用来解决超大量简单作业资源精准配置的问题，让作业在峰值期间不超用运行。 咱们设计了一套主动迭代零碎，输出每个工作的指标 RPS，通过全链路的压测平台与 Flink 工作管控平台，让作业通过启动压测工作，灌入压测流量，生成作业画像后果，进行压测流量，进行压测工作，作业利用率及 RPS 理论值比对，更新画像后果到压测工作的模仿压测流程，自动化地执行 N 轮迭代，产出一份作业 usage 与 RPS 均合乎预期的资源配置文件。整个迭代过程不须要数据研发同学参加，全自动实现。 ...

我国制造业领有 31 个大类、179 个中类和 609 个小类，是寰球产业门类最齐全、产业体系最残缺的制造业。作为世界工厂，中国制造业在拉动外国经济增长、促成外国待业等方面奉献卓越，更是我国民生生产的底层根底。同时，中国从原来的原料出口国，逐渐转为工业品中间品、中间品等一般技术密集型产品的国家，为其余国家消费品的满足提供松软撑持。 随着数字化浪潮汹涌而至，制造业紧随金融、信息通信行业，正减速进入数字化转型的深水区。 制造业数字化转型价值制造业数字化转型的价值体现在： • 利用数字技术能够升高企业的老本 去年国内供应链大会上世界经济论坛公布的《第四次工业革命对供应链的影响》白皮书指出，79.9% 的制造业企业和 85.5% 的物流企业认为，在不思考金融影响的前提下，数字化转型将产生踊跃影响，数字化改革将使制造业企业老本升高 17.6%、营收减少 22.6%，使物流服务业老本升高 34.2%、营收减少 33.6%，使零售业老本升高 7.8%、营收减少 33.3%。 ・利用数字技术能够晋升企业的效率 互联网集中了大量数字技术资源和服务，通过大幅提高利用效率而产生经济价值。依据钻研显示，以 “数据驱动型决策” 模式经营的企业，通过造成自动化数据链，推动生产制作各环节高效协同，大大降低了智能制作零碎的复杂性和不确定性，其生产力广泛能够进步 5%—10%。 制造业数字化转型是横跨数据全生命周期的，包含数字化研发、数字化制作、数字化营销、数字化体验和数字化中台。 制造业解决方案，从数据到利用制造业数字化转型过程中，会面临着数据规模、数据复杂度的问题，数据规模体现在结构化、非构造、半构造数据量暴增，计算难度几何式递增；复杂度体现在数据简单、数据类型简单等。如何解决数据品质问题、数据规范问题、口径不统一问题，以及如何在治理过程中把剖析和机理联合起来？ 制造业数字化转型的外围在于数据，所以数据的链接、汇聚和治理是制造业企业数字化转型的第一步。 制作企业需聚焦一个老本、两个核心开展，笼罩制作企业的设计、生产、治理、销售及服务各个环节，并能基于各个环节产生的数据分析与开掘进行管制、监测、检测、预测等生产经营流动，在缩短研发周期、减少洽购实时性、进步生产效率与产品质量、升高能耗、及时响应客户需要等方面赋能。 袋鼠云为制作企业提供一整套的数据治理方法论和平台工具，围绕业务流、技术流、价值流三方面，从顶层布局、到数据资产体系建设，再到数据利用与服务，构建起残缺的数据治理体系。此外，基于袋鼠云自主研发的一站式大数据开发与治理平台 —— 数栈 DTinsight，制作企业可能更快落地数据治理体系，实现数据从贮存计算、开发治理到利用的全生命周期治理。   制造业胜利案例以某芯片企业为例，为解决团体对立数据管理和数据服务要求，须要突破数据壁垒，提供团体对立的数据服务规范和数据流程；须要通过数据采集、汇聚、加工和服务，建设对立数据资产平台进行数据管理，造成面向用户、面向治理、面向领导的全面数据管理视角。袋鼠云助力企业链接生产、研发和经营，构建团体数据资产平台提供对立服务。 以某合资车企为例，为更好应答数字化改革所带来的挑战 ，该企业现有的竖井架构的数据体系难以满足越来越多、越来越快的零碎和数据交互、麻利翻新利用、数据共享、新业务拓展的需要。 袋鼠云助力该企业建设数据中台，实现数字化经营治理，全面理解用户的需要变动，也为营销、生产、服务等各个环节提供撑持，进一步晋升企业的经营效率。 

Data Catalog 通过汇总技术和业务元数据，解决大数据生产者组织梳理数据、数据消费者找数和了解数的业务场景。本篇内容源自于火山引擎大数据研发治理套件 DataLeap 中的 Data Catalog 功能模块的实际，次要介绍 Data Catalog 在私有云部署和公布中遇到挑战及解决方案。 背景Data Catalog 是一种元数据管理的服务，会收集技术元数据，并在其根底上提供更丰盛的业务上下文与语义，通常反对元数据编目、查找、详情浏览等性能。目前 Data Catalog 作为火山引擎大数据研发治理套件 DataLeap 产品的外围性能之一，通过多年打磨，服务于字节跳动外部简直所有外围业务线，解决了数据生产者和消费者对于元数据和资产治理的各项外围需要。DataLeap 作为一站式数据中台套件，会集了字节外部多年积攒的数据集成、开发、运维、治理、资产、平安等全套数据中台建设的教训，助力 ToB 市场客户晋升数据研发治理效率、升高治理老本。Data Catalog 作为 DataLeap 的外围性能之一，本文会集了 Data Catalog 团队在最近一年私有云从 0 到 1 实际的整体教训，次要解说遇到的各项挑战和对应的解决方案。Data Catalog 私有云倒退历程Data Catalog 曾经随着 DataLeap 一起作为私有云产品正式在火山引擎对外公布，上面是 Data Catalog 在性能演进上的一些重要工夫节点： 2021 年 9 月，Data Catalog 随着 DataLeap 实现在火山引擎私有云首个版本部署和公布，蕴含 60%外部外围性能，反对 EMR Hive 数据源元数据管理。2022 年 2 月，Data Catalog 随着 DataLeap 实现火山引擎私有云 Beta 版本公布，吸引了一批客户试用。2022 年 5 月，Data Catalog 随着 DataLeap 实现火山引擎私有云 GA 版本公布，正式对外开放。2021 年 9 月至 2022 年 5 月，Data Catalog 公布 10+版本，对齐 95%外部外围性能以及公布新性能 20+，包含反对 LAS/ByteHouse 数据源、OpenAPI 和元数据采集等 ToB 场景新个性。Data Catalog 私有云整体架构Data Catalog 反对综合搜寻、血统剖析、库表治理、元数据采集、备注问答、专题治理、OpenAPI 等性能，和 DataLeap 其余功能模块（如数据开发、数据集成、数据品质、数据安全等）一起提供了大数据研发和治理场景的一站式解决方案。同时，Data Catalog 私有云产品是基于火山引擎提供的数据引擎和云基础设施来部署和服务的，上面会简略介绍下咱们所依赖和应用的产品和服务： ...

CDP（Customer Data Platform，客户数据平台）市场将迎来新一轮的高速增长。 国际数据公司（以下简称“IDC”）数据显示，2021 年寰球 CDP 市场规模达到 21.6 亿美元，将来五年年复合增长率 (CAGR)为 21.5%；聚焦国内市场，数字营销咨询机构纷析智库公布的《2021 年品牌 CDP 与营销数字化转型报告》指出，2021 年中国 CDP 行业份额是 28 亿元，五年内将达到 80 亿元。 一般来说，国内 CDP 的倒退能够追溯到 2013 年，相较于早前企业罕用的 CRM（Customer Relationship Management ，客户关系治理）、DPM（Digital Performance Management，数字化业绩治理）以及 SCRM（Social Customer Relationship Management，社会化客户关系治理）零碎，CDP 的数据起源更丰盛、颗粒度更细，而且在连贯数据后链路营销场景应用上也更为便捷，可适配更多数据产品。 数据起源：36 氪企服点 评以火山引擎数智平台 VeDI 推出的客户数据平台 VeCDP 为例，可能帮忙企业从多种渠道提取客户数据（包含自有第一方、平台第二方和其余渠道第三方数据起源）并进行治理和存储，并通过 ETL/ELT 将多种数据格式进行集成对立，同时买通跨渠道、设施和起源的客户身份解析，实现标识对立。 在此基础上，为了便于业务应用，VeCDP 还能对获取的数据进行对立治理，其中包含去重得系列数据加工，最大限度放弃数据完整性和新鲜度；并提供多样的标签模式、灵便的客户剖析，可对市场群体进行深度多维度洞察。 在备受关注的平安性能方面，VeCDP 反对数据隐衷爱护合规查看与权限限度治理。除此之外，VeCDP 还可充沛联动火山引擎数智平台 VeDI 旗下多款数据产品，在自动化营销、精准市场剖析、疾速 AB 试验等多个业务场景中，为企业带来能力反对。 首先，在营销自动化方面，VeCDP 中的标签、人群、ID Mapping 服务可被增长营销平台 GMP 调用。企业通过 VeCDP 实现客户分层，并进一步洞察客户画像，并针对不同客户群体制订差异化的经营策略——当策略实现后，能够通过 GMP 的多渠道（如短信、push、邮件、微信等）面向精准客户群体实现营销触达，而触达后回收的成果数据还能持续返回并积淀在 VeCDP 中，可供企业实现归因剖析与复盘，以便进一步优化经营策略，实现营销场景下的精细化经营闭环。 其次，在对客户画像有进一步洞察需要时，VeCDP 可能反对将人群及标签同步到数智洞察平台 DataWind 上做进一步剖析。 ...

火山引擎 DataTester不仅对外提供服务，也是字节跳动外部所利用的A/B试验平台，它基于先进的底层算法，提供迷信分流能力，提供智能的统计引擎，试验后果牢靠无效，助力业务决策。目前，已笼罩举荐、广告、搜寻、UI、产品性能等业务场景。 DataTester 提供从实验设计、试验创立、指标计算、统计分析到最终评估上线等贯通整个试验生命周期的服务。能够帮忙企业业务在疾速迭代的路上，大胆假如、小心求证。 在字节，A/B测试简直可能被利用到业务的所有方面。下述3类是十分典型的场景： 1. 产品优化类场景这里的产品优化，次要是产品在界面设计、交互功能设计中，因为界面的排布、元素、色彩、字体等方面有有限的抉择，因而面对宏大的产品用户，哪个计划是最优计划，是没方法靠理性感知决定的，须要用量化的数据才更有说服力。 如抖音App中，某个页面按钮具体采纳圆形还是方形，是用黄色还是红色，都是要通过DataTester进行AB测试，能力决定最终的计划。 2. 经营类场景经营类场景中，AB测试次要有两个利用方向。一方面是比照不同的经营策略的设置在短期成果上的优劣，如在App中设置用户7日签到的处分策略，处分规定如何设置、处分数量如何设置，可能达到DAU晋升的成果最优，是要在DataTester中配置AB测试，能力实现最终的决策。 另一方面，也要通过长线的AB测试对经营策略做长期收益的考量。字节在诸多实际中发现，一些经营措施尽管短期为产品带来了用户数量的增益，但拉长时间轴来看，长期的用户留存成果低于天然流量的留存。那么从久远的ROI来看，此类措施并不是一个好的经营动作。而这种长期成果的监测，也是要通过DataTester的反转试验能力才可能监测到。 3. 举荐模型优化场景信息流举荐在字节系产品中有比拟宽泛的利用场景。在这背地会利用到的是举荐算法模型，以及还会波及到深度学习等模型。这些模型因为变量很多，往往是牵一发而动全身的成果，具备很强的黑盒属性。在其中一个特色、一个轻微参数调整之后，整体模型所获取的用户反馈是否能取得预期指标，没有方法通过教训或者繁多的归因来判断。 此时只有通过AB试验，对不不同策略对产品外围指标的影响，能力验证新的策略在用户应用中所取得的的反馈。能够说举荐算法模型和AB试验是相伴相生的。 点击跳转火山引擎A/B测试DataTester官网理解更多

公共大数据集群中如何配置 YARN 的偏心调度器和容量调度器1 YARN 资源管理框架与偏心/容量调度器作为一款资源调度框架，Yarn 反对可插拔的调度器，常见的调度器有偏心调度器 fair scheduler 和容量调度器 capacity scheduler。常见的大数据发行版中，CDH 集成的是偏心调度器，CDP/HDP集成的是容量调度器。 在理论应用过程中，为充分利用资源，个别多个大数据利用会专用一个大数据集群，此时集群管理员会将YARN资源划分到若干个队列中并为不同队列配置不同的资源额度，而后不同的业务依据其业务特色和重要性，提交作业到集群管理员规定的 YARN 队列中。 笔者遇到过不少因为 YARN 集群队列资源配置不当，造成业务作业获取不到资源而执行失败的状况，所以在此跟大家分享下集群管理员配置YARN调度器时的常见注意事项。 2 偏心/容量调度器配置准则概述为保障各个业务的 SLA 并兼顾集群资源的高效应用，不论应用偏心调度器还是容量调度器，管理员在配置YARN调度器时，都须要遵循以下准则： 管理员须要依据集群撑持的所有业务利用的重要性/资源需求量/运行工夫等多种特色，将 YARN 集群整体资源按比例划分到不同的队列中，并要求业务利用提交到对应的YARN队列中；为确保不同利用运行在对应的 YARN 队列中，管理员能够对立配置搁置规定基于作业提交用户的身份映射到对应队列中，也能够由业务利用显示指定队列（联合预先的审计 audit 确保队列应用正确）；为不同队列指定资源配额时，偏心调度器通过指定权重 weight 来指定资源配合（YARN会依据不同不同队列的 weight 主动计算出队列的资源配额）；而容量调度器能够间接指定资源配额；队列的资源配额是动态的软限度，是长期来看各个队列可能取得的资源比；为了更高效地应用集群资源，管理员还能够指定队列的最小和最大资源，两者都是硬限度，其中最小资源数是为了确保本业务的 SLA，而最大资源数是为了不影响其它业务；为避免同一个队列下同时提交大量作业时互相争抢资源都得不到足够的资源，能够通过参数管制队列中作业的最大并发数；为避免同一个队列下所有 application master 占据大量资源而没有足够的资源分配给 executor 来执行工作，能够通过参数限度 am 的资源比；还能够配置 preemption 抢占策略，以容许某个队列在其理论取得的资源没有达到其资源配额时，抢占其它队列的超过其资源配额的资源（可能会kill该队列下的 container容器）；有些大数据集群的某些YARN队列具备显著的潮汐特色，即这些队列每天大部分时候都是闲暇的，但在特定的时间段内，YARN 客户端会在短时间内提交大量作业申请大量容器资源，此时思考到YARN队列的冷启动问题和YARN高并发下的性能问题，对于偏心调度器，集群管理员能够调整以下参数，确保YARN队列能及时取得足够的资源: 为进步YARN在高并发下响应客户端申请并分配资源容器的响应速度，能够调整以下参数，该调整须要重启 YARN 集群: yarn.scheduler.fair.assignmultiple (默认 false，能够调整为 true）；yarn.scheduler.fair.dynamic.max.assign (默认 true，不必调整）；yarn.scheduler.fair.max.assign (默认 -1，不必调整）；yarn.scheduler.fair.update-interval-ms(默认 500ms，不必调整）为应答队列冷启动问题，能够为相应的YARN队列配置较高的权重，较高的权重能够放慢队列运行作业时从0到取得足够资源的工夫（该调整是动静调整，不须要重启集群）; 3 如何排查调度器资源配置引起的业务问题当业务作业因为调度器资源配置不当而运行失败时，个别须要查看以下信息以剖析问题： 查看作业报错信息，比方能够查看 rm web ui 中该作业的 Diagnostics 信息，Hive 作业的话须要查看 hs2 日志，还须要查看作业的日志（开启了日志聚合的话，能够应用命令 yarn logs -applicationId xxx）；查看 YARN 队列的动态配置信息，比方通过 CDH 的动静资源池页面或 CDP 的 Yarn Queue manager UI 页面；查看作业执行期间 YARN 队列的动静状态，比方查看 yarn web ui 的调度器页面；偏心调度器下，某队列在 YARN WEBUI 的调度器页面截图如下： ...

作者：vivo 互联网存储技术团队- Qiu Sidi在企业大数据体系建设过程中，数据采集是其中的首要环节。然而，以后行业内的相干开源数据采集组件，并无奈满足企业大规模数据采集的需要与无效的数据采集治理，所以大部分企业都采纳自研开发采集组件的形式。本文通过在vivo的日志采集服务的设计实践经验，为大家提供日志采集Agent在设计开发过程中的要害设计思路。 一、概述在企业大数据体系的建设过程中，数据的解决个别蕴含4个步骤：采集、存储、计算和应用。其中，数据采集，是建设过程中的首要的环节，也是至关重要的环节，如果没有采集就没有数据，更谈不上后续的数据处理与应用。所以，咱们看到的企业中的经营报表、决策报表、日志监控、审计日志等的数据起源都是基于数据采集。个别的，咱们对数据采集的定义是，把各种扩散的源头上的数据（能够包含企业产品的埋点的日志、服务器日志、数据库、IOT设施日志等）对立汇聚到大数据存储组件的过程（如下图所示）。其中，日志文件类型的采集场景，是各种数据采集类型中最常见的一种。接下来，将围绕该场景提出咱们的设计实际计划。 通常，日志采集服务能够分为几个局部（业界常见的架构如下图所示）：日志采集Agent组件（常见的开源采集Agent组件有Flume、Logstash、Scribe等）、采集传输与存储组件（如kafka、HDFS）、采集治理平台。Bees采集服务是vivo自研的日志采集服务，本文章是通过在Bees采集服务中的要害组件bees-agent的开发实际后，总结出一个通用的日志采集Agent设计中的核心技术点和一些要害思考点，心愿对大家有用。 二、个性&能力具备根本的日志文件的实时与离线采集能力基于日志文件，无侵入式采集日志具备自定义的过滤超大日志的能力具备自定义的过滤采集、匹配采集、格式化的能力具备自定义的限速采集的能力具备秒级别的实时采集时效性具备断点续传能力，降级和进行不丢数据具备可视化的、中心化的采集工作治理平台丰盛的监控指标与告警（包含采集流量、时效性、完整性等）低系统资源开销（包含磁盘、内存、CPU及网络等）三、设计准则简略优雅强壮稳固四、要害设计目前业界风行的日志采集Agent组件，开源的有Flume、Logstash、Scribe、FileBeats、Fluentd等，自研的有阿里的Logtail。它们都有不错的性能与稳定性，如果想要疾速上手，能够无妨应用它们。然而个别大企业会有个性化的采集需要，比方采集工作大规模治理、采集限速、采集过滤等，还有采集工作平台化、工作可视化的需要，为了满足下面这些需要咱们自研了一个日志采集Agent。 在做所有的设计和开发之前，咱们设定了采集Agent最根本的设计准则，即简略优雅、强壮稳固。 日志文件采集的个别流程会包含：文件的发现与监听、文件读取，日志内容的格式化、过滤、聚合与发送。当咱们开始着手开始设计这样一个日志采集Agent时，会遇到不少要害的难点问题，比方：日志文件在哪里？如何发现日志文件新增？如何监听日志内容追加？如何辨认一个文件？宕机重启怎么办？如何断点续传？等等问题，接下来，咱们针对日志采集Agent设计过程中遇到的关键问题，为大家一一解答。（注：下文呈现的文件门路与文件名都为演示样例非实在门路） 4.1 日志文件发现与监听Agent要如何晓得采集哪些日志文件呢？ 最简略的设计，就是在Agent的本地配置文件中，把须要采集的日志文件门路都一一列举进去，比方 /home/sample/logs/access1.log、/home/sample/logs/access2.log、/home/sample/logs/access3.log 等，这样Agent通过读取配置文件失去对应的日志文件列表，这样就能遍历文件列表读取日志信息。然而理论状况是，日志文件是动静生成的，像个别tomcat的业务日志，每个小时都会滚动生成一个新的的日志文件，日志名字通常会带上工夫戳，命名相似 /data/sample/logs/access.2021110820.log，所以采纳间接配置固定的文件列表形式是行不通的。 所以，咱们想到能够应用一个文件夹门路和日志文件名应用正则表达式或者通配符来示意（为了不便，下文对立应用通配符来示意）。机器上的日志个别固定存在某一个目录下，比方  /data/sample/logs/ 下，文件名因为某种规定是滚动产生的（比方工夫戳），相似 access.2021110820.log、access.2021110821.log、access.2021110822.log，咱们能够简略粗犷应用 access.*.log 的通配办法来匹配这一类的日志，当然理论状况能够依据你须要的匹配粒度去抉择你的正则表达式。有了这个通配符办法，咱们的Agent就能的匹配滚动产生的一批日志文件了。 如何继续发现和监听到新产生的日志文件呢？ 因为新的日志文件会由其余应用程序（比方Nginx、Tomcat等）继续的按小时动静产生的，Agent如何应用通配符疾速去发现这个新产生的文件呢？ 最容易想到的，是应用轮询的设计方案，即是通过一个定时工作来查看对应目录下的日志文件是否有减少，然而这种简略的计划有个问题，就是如果轮询间隔时间太长，比方距离设置为10s、5s，那么日志采集的时效性满足不了咱们的需要；如果轮询间隔时间太短，比方500ms，大量的有效的轮询查看又会耗费许多CPU资源。幸好，Linux内核给咱们提供一种高效的文件事件监听机制：Linux Inotify机制。该机制可监听任意文件的操作，比方文件创建、文件删除和文件内容变更，内核会给应用层一个对应的事件告诉。Inotify这种的事件机制比轮询机制高效的多，也不存在CPU空跑节约系统资源的状况。在java中，应用java.nio.file.WatchService，能够参考如下外围代码： /** * 订阅文件或目录的变更事件 */public synchronized BeesWatchKey watchDir(File dir, WatchEvent.Kind<?>... watchEvents) throws IOException { if (!dir.exists() && dir.isFile()) { throw new IllegalArgumentException("watchDir requires an exist directory, param: " + dir); } Path path = dir.toPath().toAbsolutePath(); BeesWatchKey beesWatchKey = registeredDirs.get(path); if (beesWatchKey == null) { beesWatchKey = new BeesWatchKey(subscriber, dir, this, watchEvents); registeredDirs.put(path, beesWatchKey); logger.info("successfully watch dir: {}", dir); } return beesWatchKey;} public synchronized BeesWatchKey watchDir(File dir) throws IOException { WatchEvent.Kind<?>[] events = { StandardWatchEventKinds.ENTRY_CREATE, StandardWatchEventKinds.ENTRY_DELETE, StandardWatchEventKinds.ENTRY_MODIFY }; return watchDir(dir, events);}综合以上思考，日志文件的发现和日志内容变更的监听，咱们应用的是"inotify机制为主+轮询机制兜底"、"通配符"的设计方案，如下图所示： ...

图的可视化是剖析和了解图数据的一种重要伎俩。TuGraph 内置了TuGraph Browser，为大多数用户提供了一个简略易用的图可视化界面。因为 TuGraph Browser 不反对自定义界面，因而一些有自定义界面需要的用户只能抉择自行搭建新的前端界面。11月22日，蚂蚁团体将开源 GraphInsight（下文简称GI），该工具解决了疾速搭建自定义图剖析界面的问题。 作为例子，咱们应用 GI 搭建了 TuGraph Explorer，一个与 TuGraph Browser 不一样的可视化前端。 用户能够返回 GitHub 下载 TuGraph Explorer 的前端资产包，并将其与 TuGraph 连贯进行图可视化展现，具体步骤参看阐明文档。 （图1，TuGraph Explorer 应用界面） GraphInsight 是基于 AntV 开源技术栈构建的一款图可视化剖析利用研发工具。开发者可依据业务需要，在线进行产品模块的组合搭建，疾速生成新的图剖析利用。应用GI，用户能够： 疾速验证想法，享受搭积木的乐趣零代码上手开发，专一你所关怀的极速部署上线，所有只为凋谢而生GI 的具体步骤请参看 GI 阐明文档。 （图2，GraphInsight 应用界面） TuGraph 是蚂蚁团体开源的高效 HTAP 图数据库。它提供了齐备的图数据库根底性能和成熟的产品设计，领有残缺的事务反对和丰盛的零碎个性，单机可部署，应用成本低，反对TB级别的数据规模。随着 TuGraph 的开源，图数据库畛域将迎来一款性能卓越、性能齐备、生态丰盛的开源产品。开发者能够聚焦应用层，轻松打造属于本人的图利用，从而晋升行业整体技术利用程度。 TuGraph 致力于打造凋谢的图计算生态。除了齐全凋谢TuGraph的代码外，咱们还踊跃与其余零碎实现对接。目前，TuGraph 曾经对接了开源监控零碎 Grafana, Prometheus，以及 HDFS，HIVE，Kafka，MySQL 等数据源。近期，咱们开源了 OGM（Object Graph Model），不便用户应用面向对象的编程模式来调用 TuGraph。GraphInsight 是 TuGraph 对接的首个第三方图可视化工具，它将大大扩大 TuGraph 的可定制能力。将来，咱们将持续接入更多生态工具，推动图数据库的标准化。 （图3，TuGraph 生态系统） TuGraph 可视化工具简介TuGraph Browser：是 TuGraph 自带的可视化开发工具，次要用于开发人员进行数据和模型的操作。以及对服务资源实时状态的监控。TuGraph Explorer：是基于 GI 搭建的 TuGraph 可视化剖析工具，次要用于数据分析师和解决方案架构师对数据之间潜在关系和价值的开掘。Graphinsight：是基于 AntV 开源图技术栈构建的一款产品，它既是一款图可视化剖析利用研发的工具，也是图可视剖析的工具。能够供前端开发工程师基于 GI 提供的 SDK 进行图可视化利用的二次开发。也能够供产品解决方案架构师通过可视化的形式搭建带有业务语义的图利用。TuGraph App Store：是基于 TuGraph 搭建的图利用开放市场，以 TuGraph DB 作为底层引擎，用户能够应用 GI 或通过 TuGraph DB 提供的 API 自主研发图利用，也能够通过 TuGraph App Store 进行图利用的分享和交换。

近年来星环科技围绕着数据安全做了大量的工作，造成了一个数据安全的产品体系。本文次要给大家介绍下星环数据云基于零信赖平安理念在网络安全上的思考与实际。首先对星环数据云产品的平安需要进行梳理和分类，大抵可分为四类：l 数据应用层须要可信的数据利用机制，可能通过对内受权、对外隐衷计算等形式帮忙数据安全流通。l 数据资源层须要对进行数据安全治理和平安防护，对数据分级分类、脱敏、溯源，管理权限等。l 大数据平台层须要可信的软件环境，可能进行平台组件治理，数据加密传输和存储，审计操作，确权拜访等。l 云基础设施层须要可信的计算环境，可能对资源进行安全监控，资源隔离，破绽检测等。针对这四类需要，星环科技都针对性的提供了对应的平安产品用来提供相应的服务能力：l 在数据应用层能提供了 可信数据流通和可信隐衷计算。l 在数据资源层提供了 数据安全治理，数据安全防护。l 在大数据平台层提供了 数据传输存储平安，数据安全射进，平台权限管控产品。l 在云基础设施层提供看基础设施安全监控，包含容器隔离，镜像扫描，动静破绽检测大家能够看到目前星环科技提供了很多维度的平安产品。本文次要围绕网络和认证相干的底层技术如：微隔离安全区、 集群平安边界以及对立身份认证讲述零信赖网络实际。首先介绍的是微隔离安全区性能。针对大数据业务场景，咱们对微隔离性能进行了深度打磨，从根本元语/元素到性能/个性实现做了大量的工作。不再应用传统网络中的五元组作为根本元素，而是更多的应用了多元化的逻辑标识作为微隔离的根本元语 ：Node、Namespace、Label、Service&Endpoints、Service Account、IPBlock等。基于根本元语以网络安全区为外围从新定义微隔离根本元素，灵便配置微隔离逻辑范畴，防止适度隔离或者隔离不到位。新的微隔离根本元素有：SecurityZone、SecurityGroup、SecurityRule。SercurityZone是以微隔离根本元语为利用单位划分的灵便的微隔离逻辑范畴。同时咱们对安全策略通过SecurityGroup以组的模式进行治理。而SecurityRule则是具体微隔离安全策略的具体规定。SecuriytyRule最终会翻译为OpenFlow Pipeline，实现安全策略性能。微隔离安全区功还反对多种个性如：l 流量可观测性：多个维度对微隔离流量进行统计，并可视化展现，如：Node维度、Pod维度、Pod-Pod维度、Pod-Service维度、SecurityZone维度。l 反对L7的安全策略：咱们不仅反对L2-L4的安全策略访问控制，还在流量可观测性的根底上实现L7的更细粒度的平安防护。比方基于L7中的protocols、method以及pach等字段实现应用层的平安访问控制。l 流量按需加密性能：在不借助service mesh的状况下实现轻量级的流量按需加密，比方能够对SecurityZone外部流量进行按需加密或者对SecurityZone和内部的流量按需加密。l 微隔离安全区与 CNI 插件解耦：能够兼容多种支流 CNI 插件，如能够反对Flannel、Calico以及Antrea。l 安全策略引擎：对流量进行多维度的计算和学习。实现网络安全区内上架的利用的动静感知，主动依据流量通信记录学习生成安全策略。接着介绍的是集群平安边界性能。后面介绍的微隔离安全区性能，次要确保了集群内的网络拜访平安。而集群内部平安的拜访集群内的利用也是重要的性能，为了确保这类拜访平安，咱们做了三方面的技术防护：第一个是平安边界负载均衡器：咱们对立集群南北流量，在做到高性能，高可用的同时，加强了平安相干的个性。如白名单治理、实在源 IP以及网络加密。K8s自身不蕴含负载均衡器，基本上通过nodeport或者ingress对外提供服务，咱们为了确保安全拜访，自研了轻量的负载均衡器，对立了南北流量的拜访入口，能够将集群外部利用对立对外裸露，在确保高性能，节点高可用，AZ高可用的同时，加强了以下平安性能。l 白名单治理，放行指定源 IP/CIDR 对指定集群利用的拜访，并反对对阻止的报文进行流量审计。配合ingress能够做到七层网络的平安访问控制。l 实在源 IP，反对透传客户端 IP 性能，确保报文进入集群外部后进一步的平安审计解决。l 网络加密，反对 WireGuard 隧道通信模式，包含用户和集群间以及集群之间建设 WireGuard 隧道进行加密通信。第二个是跨集群平安通信：咱们之前曾经实现了跨集群的Full Mesh 通信，即不借助网关节点两个集群之间pod和pod能够间接通信，在这之上，咱们加强了平安相干个性，确保跨集群 Pod-To-Pod 的平安通信。能够在两个SLB之间建设wireguard隧道。两个集群的pod之间集中通过SLB进行加密通信同时针对有能力配置wireguard隧道的用户，负载均衡器也反对和用户建设wireguard隧道，确保整个链路的平安加密。第三个是边界防火墙：反对对 NodePort 类型的 Service、HostNetwork 类型的 Pod 以及局部配置端口映射的Pod设置集群维度、节点维度、内部拜访维度等多个维度边界平安规定。最初介绍的是对立身份认证。无论是隔离防护性能还是边界防护性能次要是被动或者被动防护的性能，咱们还须要星环数据云中的workloads之间通信的身份认证 。咱们认为星环数据云中的workloads之间网络通信都是不可信的，须要一个对立身份认证，在给workloads调配对立的标识ID的同时，实现基于ID的认证和通信策略管理。星环数据云是一个多租户云平台，反对租户严格的受权和平安管控以及租户数据管理。咱们基于 SPIFFE 规范，集成 Spire 实现了基于身份认证的网络安全拜访。大数据组件的身份认证与网络身份认证整合，对立治理，反对策略联动。实现对立身份认证性能。