马上注册，结交更多数据大咖，获取更多知识干货，轻松玩转大数据
您需要 登录 才可以下载或查看，没有帐号？立即注册
x
两个趋势下，你面临的可能是个无法解决的问题第一个趋势，是在任何一个公司，甚至是垂直领域的公司，数据量正在剧烈增长，而且数据类型越来越复杂。 我们已经没有办法通过单一、关系型数据库来存储这些数据了。将BI工具配置一下，指向数据存储，马上开始数据业务分析的日子，一去不返了。 事实上，传统的ETL工具栈，也在努力适应企业内现代化的数据格局，只是架构越来越复杂，效率越来越低。如下图所示： 从数据到洞察（灯泡所示），各个环节都需要精密的控制和配合
很多大型公司，已经认识到这种局面，启动了数据治理，希望可以一举扭转这种被动。我们把这个趋势称之为：现代化数据场景与传统数据工具链的不匹配。 然而，事情还没有结束。即使只是这一个挑战，处理起来就已经是按下葫芦浮起瓢了。若是将这个趋势，与另一个趋势相结合的话，只能用“雪上加霜”来形容了！我们来看下大数据的第二个趋势。 这个趋势就是，使用数据的用户，成分越来越多样，比如业务分析师、业务人员、产品经理、营销分析师、算法工程师等等。 这些身份中，很多人并不是数据专家，数据只是他们日常工作的辅助。问题在于，这些人，在日常生活中，都有令人惊叹的数据体验： 在生活中，这部分用户，对这种“数据的即时满足感”印象深刻。当他们回到公司，发现新创建一个可视化报表，从寻找数据源、数据采集、到清洗、到最终完成工作，需要两周、甚至一个月的时候，这种沮丧之情，是可以想象的。 这种与日常数字生活中，用户体验的巨大反差，也给公司解决大数据问题带来了很大的压力： 分析师和业务用户，对自助服务的呼声持续增大 公司内数据的复杂性，同样日益提升。
很快，你会发现，你面临了一个不可能解决的问题！ 如何理解传统数据架构回头再看下这些技术栈，会发现，多年来，它几乎没有什么改变。 我们看看这些数据。它们存储在不同的地方，倒是使用了越来越多的现代数据技术，如S3，hadoop，MongoDB，Elasticsearch等等，当然还有关系数据库。 我们看看数据的使用方式。下面是人们在数据分析中常用的工具。如果公司已经到一定规模，那么你还可能同时存在多个工具链（数据链路）来处理数据： 注意：我有意的不把ETL工程师和数仓工程师加进来，因为他们对数据的价值没有主张，是赋能业务线的。
可以看到，不同角色和背景的员工，倾向于使用不同的工具来处理和分析数据。 我们再看看团队间如何协同的。数据使用方非常依赖IT。 比如数仓内没有的数据，分析师只能向数仓团队提需求，然后等待数仓团队按照自己的优先级来处理 面对未被采集的数据源，数仓工程师只能向IT团队提需求，然后等待IT团队按照自己的优先级来处理 …也许一个月后…，数仓工程师把数据清洗并建模后，放到数仓某个地方了 分析师从数仓找到他们需要的数据，并可以通过BI工具进行后续工作了
上面三个方面构成的工作模式，我们称之为传统的数据架构， 那么他在现代化的企业中，有什么问题呢？ 传统数据架构面对的问题与分析-如何逐步演变成劳动密集型工种的数据链路的维护是灾难 首先通过ETL工具，把数据转移到一个特定区域里，通常是Hadoop集群、云存储、S3等数据湖中。当然，这个工作是需要很多人、很多数据处理脚本来完成的。 如果上游的数据源发生变化，比如，业务同学在Mysql数据表中添加了字段，下游数据该怎么做呢？是维持不变，还是自动的添加上这些新的字段呢？这都是需要考虑的问题。 因此，只是维护该数据链路的正常运行，就已经是一个非常具有挑战的工作了。 大数据已经是人力密集型行业了数据副本是灾难 大家都知道，直接在数据湖上进行分析，通常情况下都很慢。 一般都是通过ETL，把部分数据（可能是过去30天或某些聚合级别数据）放入数据仓库中，如基于云的Redshift，也可能是Teradata，Vertica，Oracle，SQL Server等非云环境。 这些都是专用系统，昂贵不说，能否提供BI用户想要的性能，还需要画个疑问号。 为了解决上面的问题，一般会引入一个额外的数据产品层-多维数据集（CUBE）。通常的做法是，在数据仓库中预先聚合数据： 最后才发现，你为大数据支付了巨大的费用： 在基础设施上。公司的每个数据都有10余个副本，无形中需要使用更多的机器。 数据管理的复杂性提升。当你拥有大量数据副本时，数据最终会出现不一致。 在受监管的行业或公司，不同版本不一致而提供不同的结果，会被罚款或处罚。
引入安全风险。这些零散的数据副本，由不同部门、不同角色的用户来创建和管理，增加了数据泄露和非法访问的可能性
既有架构上，无法构建大数据的自助服务 基于上面的事实，在目前既有的数据架构上，是无法构建起自助服务的： 上述这种非常繁琐、过度依赖的工作模式，已经维持了至少10年，基本上没有改变过。如果想让公司变成数据驱动，那么这套传统数据架构，已经不得不调整了。 我们呼吁：把数据使用的权利真正赋予数据公民，使那些通过BI工具、机器学习的员工，可以自给自足的完成工作。当然，这种自助的工作方式，需要在公司的管理和安全控制下。 传统与现代数据架构把数据使用权真正赋予数据公民有了上面的分析，我们就可以看看什么样的数据架构，是用户需要的。 首先，它必须支持任何数据源，但又允许以统一的方式访问。解决传统ETL带来的问题的有效办法，就是省去ETL。 大多数公司，都拥有许多不同的数据源，比如mysql、Elasticsearch。同时，必须适用于任何主流的分析工具，如Tableau、MicroStrategy、Excel和Python等等。 如果没有数据仓库和cube，世界将变得更加美好。当然，不可能在一天之内摆脱所有这些，但必须有一个更好的方法，没有人真的喜欢管理这些。 其次，我们深信，甚至崇拜，自助服务和协作。这是现代数据体系必备的能力： 再次，性能是所有这一切的关键。如果你做的东西不够快，就没有人愿意在它上面浪费时间。 如果你曾经在大数据基础上，使用过各种BI，并且需要十分钟才能看到查询结果，那就说明，这套架构是有问题的。 即使对于最大的数据集，甚至是数PB和数十亿条记录，我们也必须能够提供一到两秒的交互式体验。 最后，我们认为它必须是开源的。任何类型的数据基础架构，或分析技术都需要是开源的。任何公司不希望被绑死。同时，这也是构建健康的生态系统所需要的。 基于上面的分析，我们已经认清了，什么样的数据架构，才是数据消费者所需要的。那么如何构建这个数据体系呢？ 面向自服务的数据架构数据消费者，需要的不仅仅是服务的自助化，本质上，更是数据的自助化，即自服务的数据。 我们在数据工作栈中，引入一个数据抽象层，来解决数据自助服务的问题。这个抽象层架起数据本身与工具之间的桥梁。 需要使用数据的人，通过这个抽象层，可以获得它所需要的任何基础能力。比如： 这个数据抽象层，即自服务的数据架构，从物理层上来看，它需要提供如下的能力： 可以连接到不同的数据源，并执行查询请求 可以跨数据源执行联合查询，并进行查询的加速。
查询的加速，对于自服务的数据架构来说，是至关重要的。可以想象一下，即使面对PB级别的数据，业务人员还是想以交互的方式得到查询结果。也就是说，响应速度不能超过几秒钟。 如何实现一个自服务的数据架构呢？ 现代化自服务的数据架构从架构上来说，它需要包含如下的组件： 数据集管理。数据集可以理解为虚拟的数据，主要是解决传统ETL的问题。它不会生成数据备份，没有数据冗余和不一致。同时，也不占用额外的存储资源。 数据萃取。通过虚拟数据集的能力，实现数据变换，逻辑复用。 数据查找。通过数据地图提供数据的检索能力、元数据完善能力。由于数据集具有很强的规范性，因此可以轻易的根据数据血缘，找到数据的依赖、数据的使用方式 查询加速。采用了一套独立的数据加速层，可以称之为 “Data Reflections”，它类似于物化视图。通过Reflections，数据专家就有能力干预查询的加速了。数据查询加速和数据建模过程是统一的，他们合二为一。
相比于传统的数据服务优化，我更强调数据的优化，通过对数据服务和数据双向的优化，来提供协作和自助服务能力。 再强调一次，目前大部分的做法，是把注意力放在工具的优化上。短期来看，可能有效果，但是它不解决根本问题。我们需要从数据的角度，重新审视大数据当前面临的问题，在优化工具的同时，对数据本身进行架构的优化，才有可能解决当前企业快速发展和数据驱动中，面临的问题。 “数据分析”、“数据分析师”这些词很有误导性，它让人认为，分析的目标是数据本身。叫“业务分析”可能好点，它至少会让人把焦点放到业务本身，数据是它的支撑。
注：Dremio是上述数据架构的一个参考实现。文中部分图片来自Dremio。 来源于数据老铁匠 ，作者张彦龙001
| 
/1 
发表于 2020-3-5 16:00:23
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
赞
踩
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜