数据中台技术选型最佳实践
2023-数据中台建设实施路径解决方案-1
数据中台建设实施路径解决方案数据中台建设实施路径解决方案：从零开始构建数据中台数据中台是企业数字化转型的重要基础，但是如何从零开始构建一套有效的数据中台，是众多企业面临的难题。
本文将从以下几个方面来阐述实施路径与解决方案。
1. 定义数据中台的愿景和目标数据中台的愿景和目标需要基于企业的战略和业务需求，明确数据中台对于企业数字化转型的意义和作用。
同时，需要设计相应的数据治理和数据架构架构，以满足业务和技术的需要。
2. 构建数据治理框架数据治理是数据中台的核心，一方面需要明确数据的来源、流程和质量标准，另一方面需要建立数据治理规范和流程。
同时，需要设计一个完整的数据生命周期管理流程，包括数据获取、交换、清洗、融合、存储、分析、监控等环节。
3. 配置数据中台技术架构构建数据中台需要涉及到多个技术平台，如数据存储平台、数据分析平台、数据可视化平台等。
需要评估和选择适合企业需求的技术平台，并进行合理的配置。
4. 开发适配数据中台的业务应用数据中台建设最终的目的是为企业业务服务，在数据中台技术平台的基础上，需要开发适配数据中台的业务应用。
需要将业务应用和数据中台进行无缝衔接，实现数据与业务的紧密结合。
总结通过以上四个方面的阐述，我们可以看出，企业数字化转型需要从建立数据中台开始。
只有拥有了一个高效稳定的数据中台，企业才能更好的进行数字化转型，并赢得市场竞争中的一席之地。
这需要企业针对实际业务需求，综合考虑技术、人员、数据等多方面因素，深入挖掘数据的价值，建立完备的数据环境，才能达到预计的目标。
因此，对于企业来说，建立数据中台是一场长期的运动，需要不断地完善和调整，才能更好的适应新的技术和市场变化。
数据中台的利用，是企业数字化战略的有效落地的保障，也是企业走向数字化竞争胜利和未来的新经济发展的重要开端。
基于阿里云的商业银行数据中台建设实践
栏目编辑：梁丽雯E-mail:****************基于阿里云的商业银行数据中台建设实践■ 广州万融数据服务有限公司 王玉娟一、再谈数据中台2019年底在全球爆发的新冠肺炎疫情，打乱了正常的生产经营秩序。
而结合自身的服务范围，“数据”仍然是许多金融机构和金融科技企业2020年度预算的重心。
2016年开始，广州万融数据服务有限公司（以下简称“万融”）对传统商业银行的数据仓库从技术到基于开源和商业化的大数据平台进行了能力转型升级，特别是2017年开始，伴随着阿里云在金融行业特别是商业银行领域的技术输出计划，万融陆续和阿里巴巴、蚂蚁金服进行了方案合作、咨询合作、项目交付落地合作。
成功实施的案例中，既有业界标杆的农信管理机构、上市多年的城商行，也有从城市信用社转型的股份制城市商业银行，以上都是阿里云大数据平台在商业银行领域最早、最成功的几个案例。
谈到数据中台，不得不说阿里云和大数据，这里笔者想引用时任阿里巴巴集团学术委员会主席的曾明教授在《大数据之路 阿里巴巴大数据实践》作序时写到的一段话“因此，仅仅因为本能，阿里巴巴一开始就自然生长在这样一个数据的黑洞中，并且被越来越多、越来越密集的数据风暴裹挟。
阿里巴巴在大数据方面所做的各种艰苦努力，其实就是力图对抗这种无序和复杂的熵增，从中梳理结构、提炼价值。
”在“DT时代”，阿里巴巴如此，商业银行又何尝不是在对抗这种无序和复杂的熵增，并从中梳理结构，提炼价值。
笔者认为近5年来，商业银行大胆拥抱金融科技公司的初衷，既有基于商业银行科技能力升级、技术自主可控的监管要求，也有双轮驱动、业务创新的内在动力；既有获客和活客的经营压力，也有风险控制的运营要求；既需要通过传统渠道服务好优质存量客户，也作者简介： 王玉娟，具有多年金融行业数据领域建设经验，现任广州万融数据服务有限公司资深顾问，曾主导及参与多家大型国 有银行和股份制商业银行、保险公司、证券公司等金融领大数据体系建设。
数据中台解决方案
4.数据整合：通过数据整合，消除数据孤岛，实现数据的统一管理。
5.数据安全：采用加密、权限控制等技术，保障数据安全。
五、实施方案
1.数据资源梳理：分析各业务系统数据，梳理数据资源清单。
2.数据标准制定：制定数据标准，规范数据命名、数据类型等。
3.数据治理：开展数据治理工作，包括数据清洗、数据质量监控等。
9.项目验收与优化：8个月内完成项目验收，并根据反馈进行优化。
七、风险评估与应对措施
1.数据安全风险：加强数据安全体系建设，定期进行安全评估和漏洞修复。
2.技术风险：采用成熟、稳定的技术方案，降低技术风险。
3.项目进度风险：合理安排项目进度，建立项目监控机制，确保项目按期完成。
4.业务协同风险：加强跨部门沟通与协作，提高数据共享和业务协同效率。
2.数据标准制定：参照国家和行业标准，制定企业数据标准，包括数据命名规范、数据类型规范等。
3.数据治理：开展数据治理工作，包括数据清洗、数据质量监控、数据标准执行等。
4.数据仓库建设：基于大数据技术，构建数据仓库，实现数据的集中存储、管理和分析。
5.数据服务体系建设：搭建数据服务平台，提供统一的数据查询、交换、分析等服务接口。
6.数据应用开发：根据业务需求，开发数据应用，如数据报表、数据大屏、数据分析模型等。
7.数据安全体系建设：从数据加密、权限控制、安全审计等方面，构建全方位的数据安全体系。
六、项目实施与进度安排
1.项目启动：成立项目组，明确项目目标、范围、进度计划等。
2.数据资源梳理：1个月内完成各业务系统数据资源梳理。
4.数据仓库建设：构建数据仓库，实现数据的集中存储和管理。
数据中台技术方案
数据中台技术方案本技术方案主要明确公司数据中台建设目标、建设原则、能力框架、技术要求和演进策略等内容，为公司数据中台建设提供技术指导。
一、建设背景（一）建设现状当前公司信息内网建成了覆盖公司总部及27家省（市）公司的两级全业务统一数据中心分析域，初步具备了数据接入、数据存储计算、数据分析应用相关能力，实现公司核心业务系统数据的接入及整合汇聚，支撑了各专业数据分析类应用的构建。
在数据接入方面：通过OGG、ETL等技术实现业务系统结构化数据接入至分析域贴源区，通过采集量测数据接入工具实现采集量测数据接入大数据平台。
在数据存储方面：贴源历史层采用分布式关系型数据库（SG-RDB-MS）实现各业务系统贴源数据的存储。
数据仓库层采用MPP数据库（GBase8a），基于统一数据模型（SG-CIM）实现部分数据标准化存储。
数据集市层采用关系型数据库（SG-RDB-PG）实现分析计算后结果数据存储；采集量测数据采用大数据平台分布式列式数据库（Hbase）进行存储。
在数据计算方面：针对小规模数据计算分析需求，通过MPP数据库（Gbase8a）并行计算技术实现。
针对大批量的离线计算需求通过大数据平台批量计算组件（MapReduce）实现。
针对实时数据计算需求，通过大数据平台实时消息队列（kafka）、内存计算（Spark）、流计算（Storm）等组件实现。
在数据应用方面：针对大数据分析应用需求，通过自助式分析工具、Tableau等工具实现。
（二）存在问题当前分析域在各单位分析应用中发挥了一定的作用，但从应用角度来看仍存在技术门槛高、数据难读懂、数据获取难等问题，具体如下：1.技术组件多样，应用难度大。
分析域主要包括数据接入、数据存储、数据计算等方面的21个技术组件，涉及厂商多，技术体系性差，组件之间技术集成复杂，相关工具友好性不足，对专业能力要求高，应用难度大。
2.找数据困难，数据应用门槛高。
一是当前分析域未形成完整的数据资源目录，数据资源检索困难；二是分析域目前尚未构建数据服务，数据应用复用性差，增加数据应用难度。
数据中台设计方法实施方案
其他潜在风险及防范策略
法律合规风险
可能违反相关法律法规，如数据保护法等。应对策略是加 强法律合规意识，确保业务合法合规。
运营风险
数据中台运营过程中可能出现故障或异常。应对策略是建 立完善的运维体系，确保系统稳定运行。
财务风险
项目预算超支或投资回报不达预期。应对策略是加强成本 控制和预算管理，制定合理的投资计划。
04
培养数据人才
加强数据人才培养和引进，建立数据 团队，提高数据中台建设和运维能力 。
THANKS
感谢观看
数据集成风险
数据集成过程中可能出现数据冲突、数据冗余等问题。应对策略是进行数据清洗、数据整合，建立数据标准 。
数据质量风险
数据可能存在不准确、不完整等问题。应对策略是进行数据治理，提高数据质量。
技术更新风险
技术更新换代迅速，可能导致系统不兼容、技术过时等问题。应对策略是保持技术敏感性，及时更新系统架 构和技术栈。
08
总结与展望
项目成果总结
数据中台架构搭建
完成数据中台的整体架构设计，包括 数据采集、存储、处理、分析和应用
等模块。
数据治理与规范
建立数据治理体系，制定数据标准与 规范，提高数据质量和可用性。
数据资产沉淀
实现数据资产的统一管理和沉淀，为 业务提供数据支持。
数据安全与隐私保护
建立数据安全防护体系，确保数据的 安全性和隐私保护。
系统测试
对系统进行全面的测试，包括功能测试、性能测试、安全测试等，确 保系统稳定可靠。
上线部署与调试阶段
系统部署
将系统部署到实际的生产环境中，确 保系统的可用性和可扩展性。
系统调试
对系统进行调试和优化，解决部署过 程中出现的问题和性能瓶颈。
可实操,数据中台选型示例
可实操，数据中台选型示例在了解清楚了选择数据中台时应关注的内容后，CTO/CIO可以借鉴以下数据中台选型示例，企业选购合适的数据中台。
01项目背景数字化时代，数据已经成为企业的战略级资产。
某集团把建设数字化转型作为重要发展战略，致力于将数字化转型的重要组成部分—数据中台，打造成数据资产与数据能力中心，推动业务创新与变革。
该集团有70多套应用系统，各事业部根据自身的业务需要独立搭建系统。
这些系统中的数据未实现全面融合，为该集团带来了一些重复开发、成本浪费的问题。
从烟囱式的多个平台向数据中台转变，建立统一的数据采集、处理、计算及服务平台，降低数据使用成本，是该集团要突破的重点问题。
另一方面，开展有效的数据治理，搭建功能强大的数据中台来管理庞大的数据资产，深度挖掘数据潜在价值，是该集团未来工作的重中之重。
该集团的数据现状如下。
•数据资产大、复杂度高、融合度低。
•未建立统一的数据标准及管理平台。
•未深度挖掘数据价值。
02项目目标•数据采集组件与存储库搭建•数据管理和分析组件搭建•数据全面有序入湖•完成数据治理和质量监控体系的建设•提供数据服务03项目范围项目范围包括ERP、CRM等业务数据，内外部设备数据等。
最终数据范围和系统对象以蓝图设计阶段的成果为准。
04时间要求项目预计总工期X个月，预计自某年某月某日起，至某年某月某日结束。
05主要任务、交付件项目共分为8个阶段，下面将对各个阶段的任务进行详细说明。
1）策划、招标、启动阶段。
主要任务为对现状进行调研、资源评估、项目立项、商务招标，供应商需要交付项目方案、立项报告。
2）需求调研、分析。
主要任务为对业务需求进行分析，供应商需要交付项目需求说明书、源系统需求清单、数据规格说明书、硬件资源需求说明书。
3）蓝图设计。
主要任务为架构设计，供应商需要交付架构设计说明书（含集成架构、技术架构、功能架构、硬件部署架构）、功能说明书、数据库设计说明书。
4）搭建技术平台。
数据中台技术架构方案
数据中台技术架构方案随着大数据技术的快速发展和企业对数据价值的认知不断提高，数据中台作为一种新兴的数据架构模式，逐渐引起了各行各业的关注和应用。
数据中台用于企业将分散在各个业务部门的数据集中管理、分析和应用，从而实现数据的高效价值利用和业务的迭代创新。
本文将探讨数据中台技术架构方案，分析其核心组成和实施流程，并对其在企业中的应用进行解析。
一、数据中台的定义和背景在数字化时代，企业积累了大量的数据资源，这些数据分布在各个业务系统中，造成了数据孤岛和信息孤岛的问题。
数据中台的概念应运而生，其目标是将企业内部各业务线的数据资源集中起来，通过数据集市的形式为各个业务部门提供数据支持和服务，实现数据的高质量、高效益的利用，为企业的业务创新提供支撑。
二、数据中台的核心组成1. 数据接入层：负责将企业内部各个业务系统的数据进行采集、清洗和整合，构建数据标准化和一致性的基础。
2. 数据存储层：用于存储和管理各种类型的数据，包括结构化数据、半结构化数据和非结构化数据等。
3. 数据计算层：提供数据处理和计算能力，包括数据分析、数据挖掘、机器学习等，为业务部门提供数据分析和挖掘的技术支持。
4. 数据服务层：将数据加工成可供业务使用的数据产品，为业务部门提供数据接口和服务，满足不同业务场景的需求。
5. 数据治理层：负责数据质量管理、数据安全管理、数据合规管理等，保障数据的质量和安全。
三、数据中台的实施流程1. 确定目标和愿景：明确数据中台建设的目标和愿景，明确业务需求，制定建设规划和路线图。
2. 数据建设和整合：对业务系统进行数据调研和评估，建立数据标准和规范，进行数据的采集、清洗和整合。
3. 架构设计和技术选型：根据企业需求和数据特点，设计数据中台的技术架构，选择合适的技术工具和平台。
4. 系统开发和集成：进行数据中台系统的开发和集成，实现数据的接入、存储、计算和服务能力。
5. 测试和优化：对数据中台系统进行测试，发现和解决问题，优化系统性能和用户体验。
数据中台的设计与实现
数据中台的设计与实现随着信息技术的发展与普及，数据已经成为了现代生活不可或缺的一部分。
各种企业、组织和政府都在致力于利用数据来推动其业务的开展和发展。
然而，面对数据过多、类型繁杂的现实，他们普遍面临一个共同难题：数据管理和使用的效率相对较低。
为了解决这个问题，数据中台逐渐成为了当今企业普遍采用的一种解决方案。
一、什么是数据中台数据中台，顾名思义，就是将所有的数据都统一地管理到一个构架之中，而这个构架被称之为“中台”。
这个中台可以承载各类业务系统和数据仓库，以达到更加高效、快速、稳定地访问数据的目的。
它也可以通过对数据的管理进行创新，来建立一些更加符合实际情况的业务模型，供用户快速使用。
二、数据中台的优势1. 数据中台可以帮助企业更好的管理和处理数据，让其更好的服务于业务。
通过将所有数据放在一个中台之中，企业可以更好地掌控数据的质量和完整性，可以更便捷地获取数据，从而更快速高效地进行决策和业务扩展。
2. 数据中台可以极大地减少重复工作，提高效率。
由于数据在中台中是被统一管理和维护的，因此在数据维护和数据流转过程中就不需要做重复的工作，这大大提高了生产效率和质量。
3. 数据中台可以提高数据的共享性和开放性。
数据在中台中得到了统一的管理，可以更快速地流转到需要的用户部门。
同时，为了让更多的用户能够使用数据，数据中台还可以提供数据服务API，方便大家进行数据的调用和访问。
这样可以打破部门之间的数据“壁垒”，提高数据存储、使用的灵活性。
三、数据中台的设计要素数据中台的设计要求特别严格，需要考虑很多方面的问题。
其中比较重要的设计要素有：1. 数据架构设计：找到合适的架构，对数据进行处理、管理、存储及提供服务。
在这个方面，考虑通用性、扩展性，不同层次数据的管理等等。
2. 数据管控系统：建立完善的数据管控系统，对数据进行标准化管理，保障数据的质量、完整性等。
3. 数据服务设计：设计统一的数据服务接入层，通过API的形式向上提供服务，方便用户和上层系统接入查询数据。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据中台技术选型最佳实践目录一、大数据演进，从数据仓库到数据中台 (3)二、数据中台架构与技术选型 (8)三、数据研发实践 (13)一、大数据演进，从数据仓库到数据中台第一阶段21世纪的第一个10年，企业级数据仓库（EDW）从萌芽到蓬勃发展，“IOT”( IBM、Oracle、Teradata)占领了大部分市场，提供数据仓库建设从硬件、软件到实施的整体方案。
这个时代的数据仓库实施不仅需要购买大（中、小）型机，配套商用的关系型数据库（Oracle、DB2、SQL Server）以及一些ETL/OLAP套件，实施成本相对高昂，数据仓库建设主要集中在金融、电信、大型零售与制造等行业。
数据仓库的应用主要通过为企业提供报表、分析等数据，辅助企业的经营决策。
像电信行业的经营分析系统、银行的风控管理等，都是这个期间比较典型的应用。
第二阶段2010-2015年，大数据平台阶段，移动互联网的飞速发展带动Bigdata(大数据)的发展。
其中Hadoop生态技术开始逐步在国内大范围使用，企业只要基于Hadoop分布式的计算框架，使用相对廉价的PC服务器就能搭建起大数据集群。
数据湖的概念也是这个阶段诞生（主要是为降低传统数仓较为复杂的中间建模过程，通过接入业务系统的原始数据，包括结构化、非结构数据，借助hadoop生态强大计算引擎，将数据直接服务于应用）。
这个阶段不只是金融、电信这些行业，国内主流互联网企业也纷纷搭建起大数据平台。
大数据应用更为丰富，不仅限于决策分析，基于APP/门户站点的搜索推荐、以及通过A/B Test 来对产品进行升级迭代等是这个阶段常规的应用点，用户画像在这个阶段也得到重视，主要应用于企业的营销、运营等场景。
第三阶段就是我们现在所处的阶段，数据中台以及云上大数据阶段，通过前10多年不断的技术积累，大数据在方法和组织的变革上也有了新的沉淀，主要体现在几个方面：1）数据统一化其核心思想是数据流转的所有环节进行统一化，如从采集到存储到加工等过程，在这些过程中通过建立统一的公共数据模型体系、统一的指标与标签体系，提高数据的标准性、易用性，让数据本身更好地连通，提升使用效率。
2）工具组件化数据在采集、计算、存储、应用过程中涉及多业务线条，多场景，将这些场景与工具（采集工具、管道工具、计算&调度工具、数据服务工具，数据管理工具、可视化工具等）进行沉淀，研发出通用、高效的组件化工具，避免重复开发，降低研发成本。
3）应用服务化之前大数据应用的数据调用比较混杂，有些直接访问数仓数据表，有些调用临时接口等。
通过数据中台应用服务化建设，提供标准的应用服务，以数据可视化产品、数据API工具等服务，支撑应用的灵活调用。
4）组织清晰化数据中台团队专注于数据内容&数据平台开发，提供各种基于数据的能力模块，而其他部门人员如业务产品、运营、分析等角色，只需要借助工具/产品有效地使用数据，发挥其价值，无需关注数据加工的过程，做到各尽其职，充分发挥各自专长，同样也能达到降本提效目的。
大数据团队内部本身组织和职责也倾于清晰化，比如按照职责分为平台（工具）研发、数据研发、数据产品、数据分析等不同组织。
当前阶段数据应用到各个角落，除了之前可以支撑的决策分析以外，大数据与线上事务系统（OLTP）的联动场景非常多，比如我们在电商平台查询个人所有历史订单，再比如一些刷单、反作弊的实时拦截，以及一些实时推荐等，这些都是通过将数据的运算交给数据中台部门处理，前台部门直接通过API进行结果调用。
数据中台的集中化建设也更好地支撑起创新业务，比如通过大数据+分析建立起商业化数据变现产品，进行数据售卖，把数据变成新的业务。
大家知道共享复用是中台建设中很关键的一个词，这也是为什么我们很多数据中台下面会包括共享数据组，公共数据组等。
实际上共享复用并不是大数据发展的一个新词，在早期数据仓库（建立公共数据模型）、大数据平台（研发一些组件化工具）的建设中，也是满足共享复用的。
如上提到，数据中台本身是组织，方法的升级与变革，更多是利用技术的进步更好地支持这些升级变革，如果你当前的建设还是数据平台+数仓（数据湖等）但是已经具备这些方法和特性，我个人认为也是合理的。
数据中台的建设也需要相应的成本与门槛，例如集群搭建、工具建设等。
云计算的发展可以快速提供数据中台建设的能力，例如企业无需自己搭建机房，使用云计算的弹性计算存储能力以及丰富的工具，可以支撑数据中台的快速搭建。
关于数据中台的合理性也一直颇有争议，大型（集团型）公司有相互独立的子公司，数据之间不需要太多连接与共享，分别构建自己子数据中台也是合理的架构，集团层面可以利用数据子中台进行数据上报解决集团层面数据大盘、统计、分析、财务等诉求。
再比如一些小型公司是否需要在一开始就按照数据中台的架构进行建设，也是存有一些争议。
数据中台是2015年阿里提出来的双中台的概念其中的一个重要组成，阿里作为先驱者，提供了数据中台架构、以及非常多的建设思路供大家参考。
从目前的建设效果来看，很多公司在数据中台建设中有不错的成效（尤其是大中型公司），数据中台整体思路得到了验证。
但是数据中台本身还算一个新鲜事务，这个新鲜事务目前还没有标准答案，只有参考答案。
二、数据中台架构与技术选型1、数据中台架构核心组成我认为的数据中台核心架构包括四大组成部分，具体是：•底座是数据基础平台，包括数据采集平台&计算平台&存储平台，这些可以自建也可以使用云计算服务；•中间部分两大块是中台的公共数据区，公共数据区包括数据仓库(数据湖) ，主要负责公共数据模型研发，还包括统一指标（标签）平台，负责把模型组织成可以对外服务的数据，例如数据指标、数据标签；•上层是数据应用服务层，主要将公共数据区的数据对外包装并提供服务，包括数据接口平台、多维查询平台，数据可视化平台、数据分析平台等。
另外，数据研发平台和数据管理平台贯穿始终，其中：1）数据开发平台包括数据开发的各类工具组合，例如：数据管道工具（比如数据接入、数据导出）、模型设计工具、脚本开发工具、数据调度工具等。
2）数据管理平台包括统一元数据管理、数据质量管理、数据生命周期管理。
针对数据全链路的数据管理，保证数据中台可以监控数据链路中的数据流向、数据使用效果、数据生命周期，以衡量数据的价值与成本。
以上是数据中台的核心部分，数据中台的组成也可以更加丰富，比如包括：数据资产平台、算法平台等等。
在数据中台的建设中一定不要忽视的是与业务的衔接，因为数据来源于业务并最终应用于业务，在数据中台的建设中需要有一系列的流程制度明确与业务的充分衔接，以保障数据源&数据产出的质量。
2、数据中台技术选型参考在搭建数据中台方面，基于开源技术的选型，尤其是Hadoop生态圈有非常多的选择，从数据整体流向来看各大层级的选型。
•数据抽取层：sqoop和flume是两大主流工具，其中sqoop作为结构化数据（关系型数据库）离线抽取，flume作为非结构化日志接入；•数据存储层：Hadoop文件系统Hdfs大家都比较了解，而kafka作为流式数据总线应用也非常广泛；•计算与调度层，包括：o离线计算：离线计算主要是hive，spark，也有部分选用tezo实时计算：前些年storm，spark比较流行，最近几年大家纷纷往Flink转型o数据调度：除了像Airflow Azkaban Oozie等，易观开源的Dolphin-scheduler也非常活跃•数据引擎层：也就是我们常说的OLAP层，我们看到这一层里的选择非常多，就不一一列举了，（业务需求带动技术进步的典型，选择丰富主要是可以适配不同的数据应用场景）。
从概念上讲分为ROLAP、MOLAP以及两者混搭。
MOLAP提前做一些预计算，以生成Cube的方式，达到空间换取查询效率；而ROLAP是即查即用，效率完全取决于查询引擎的性能，我个人认为从将来看，ROLAP的趋势会更加明显，因为没有中间的数据链路。
但目前看来，没有一个统一的引擎足以支撑各类数据场景（这或许是将来的机会~）；•数据可视化层：比较主流的有Metabase、Superset、Redash，也可以选择阿里、百度的一些开源控件。
在开源技术的选择里，我们看到各层里都有越来越多国内开源的工具（也充分体现了我们在大数据技术领域的进步）。
除了以上列举的这些，整个Hadoop生态圈的技术选择非常多，可以结合自己的实际场景选择自己的架构，在选型层面可以参照的一些原则，比如：•是否有鲜活的成功案例，优先找自己类似业务场景；•接口的开放性，与其他组件的兼容性；•社区活跃性度&发展趋势。
当然，数据中台的选型不只是开源技术，开源本身也不是完美的，例如维护开发成本较高，升级迭代不好把控，通过开源技术去建立数据中台还是有一定研发门槛。
所以也有很多商业化的套件、以及基于云的数据组件可以选择，包括数据采集、处理、分析、数据可视化全过程，国内外有很多厂商都提供了丰富的选择。
尤其在大数据可视化这块，国内有许多非常专业的商业套件。
三、数据研发实践1、数据处理架构下面是一个简单的数据处理架构演进过程：最早数据仓库的计算只支持批处理，通常是按天定时处理数据，在后期逐步进化到准实时，本质上还是批处理，只是处理频度上得有提升，到小时级，或者15分钟这种。
随着技术不断进步，后期演化出一条新的流处理链路，这个链路和之前的批处理分别处理，然后在服务层面利用大数据的计算能力进行合并，向外提供离线+实时数据服务，这也是著名的lambda架构。
最近几年随着Flink等技术的发展，有一个趋势是流批一体化，在接入层统一采用流式接入，计算层采用统一套框架支持实时计算+离线计算，批处理仅仅作为流处理的一个特殊场景进行支持。
整体上可以做到流处理、批处理的自由切换。
流计算和批处理在需求场景上有一些本质区别，前者主要用于支持线上业务场景（比如互联网的推荐、搜索、风控等），而批处理更多是支持离线统计分析。
日出而作，日落而息，大家针对大数据的统计分析习惯不会发生根本性变化，最简单的T+1批处理方式也还是数据应用必不可少的环节。
在使用同一套架构上，由于数据源变化&维度变化的多样性，批处理往往面临一些复杂场景，这是采用同一套框架上的一些难点，充分支持好批处理也是将来流批一体框架的发展方向。
2、数仓分层与主题分类1）数仓分层与传统ETL不同的，我们采用的是ELT的数据架构，较为适合在互联网，总体分为业务数据层、公共数据层、应用数据层三大层次。
①业务数据层（ODS层）原始数据经过缓冲层（STG）的加载，会进入数仓的业务数据层，这一层采用范式建模，基本保持与数据源完全一致的结构，对于变化的数据，使用数据拉链加工与存储。