晚上听了几十分钟数据中台的讲座，联想到自己入职现在这家公司的第一个项目

朋友圈看行里的领导分享的视频课程。吃饭的时候听得，就只是截图了几张PPT哈。

1 因为之前写了ETL相关的专利交底书，所以对ETL、数仓这方面的架构规划还蛮感兴趣的。

讲座里推荐了一本书叫《数据中台》有空可以买来读读

2.下面两张图是在讲数据中台的建设思路，然后下面是我自己的理解：

其中有两种建设思路：一种是自顶而下的，就是先从数据架构开始规划，再明确需要开展的业务有哪些，最后再考虑如何获得这些数据

这种方法的优点，就是思考数据的需求会比较完善，比较系统。相对节约时间，整体的系统架构也会比较有逻辑。

而缺点则是，最后采集数据的时候，也有可能遇到问题，此时再反过头来逐层反推，重新分析整理，那么很耗费时间精力。

第二，在项目的资金成本方面。因为最后才进行数据的采集与整理，那么此时的数据量会是极大的，工作量会一下子急速上升，成本也会相对较高。可能在结束了项目的初期设计。就会有极大的项目预算（预算报的高，领导也不一定给批，给立项啊）

而自下而上的方法，则是先根据现有业务系统，先确定几个核心主题域的数据，此时可以先进行数仓的初步建立，初步挖掘。而在上诉步骤的进行过程中，可以同时从数据集市购入数据，进行数仓数据的扩充。

这种方法的优点是：在项目的立项初期，需求的项目成本较低。项目相对更容易开展与立项。

这种方法的缺点是：系统整体会比较杂乱，此时需要很好地数据质量管理系统进行监管，对数据进行筛选，对不合格的数据源进行定义与取舍。会造成时间成本与人员成本的浪费。
甚至之前迁移好的数仓需要被返工，需要被重新建立。

而在我刚入职就经历的实际ETL项目中，其实也有所经历这些步骤，感觉实际项目往往是以上两种方法的结合。

一开始尽可能地考虑购入或者爬取有效数据，而在之后在项目进行的过程中，做一定程度的数据质量管理与血缘管理（其实在数据清洗过程中，清洗人员就会逐步反馈数据相关的问题）。那么在项目过程中，对不合格(质量不合格、更新频率不合格等情况的)数据进行购买补充，或是再次、循环爬取。

3.下面这张图反映了数据中台的技术架构 （自己已经接触了ETL,HBase,ES,数据挖掘四个步骤）

数据中台的定义很广泛，它包括数仓与数仓的ETL，包括大数据技术中台，包括数据分析，包括数据治理，也包括系统运行期间的数据管理与数据安全等等内容。

现在想想，对于自己入职的第一个项目还是有几点疑问，HBase自己不是也有查询语句吗？为啥查HBase不用HBase自己查询的语句，而选择用了Phoenix在HBase上再架一层？

今天听讲座，这个老师说为啥喜欢用Spark SQL呢？

说就是因为SQL会的人多，业务逻辑复杂的情况下需要许多人来完成数据清洗工作。

后来想了想，自己做过的项目，当时好像是因为想要解决HBase中的数据连表join的问题（开始的时候一个查询接口甚至需要join三四个表才能查全）。不过后面由于Phoenix 连表join操作的效率太低（啥工具连大表join，那效率都低），就对照需要查询的接口，把所有需要连表操作的内容，全都重新建立数仓，建在一张HBase表格里面的。所以这时候其实是可以用HBase自己本身的查询语句的。

4.数据分析数据挖掘的重要性就更不用多说了，不继续学是傻子

5.
讲座还讲了建表的两个主要结构：

星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余
但一般在互联网公司推崇星型模型，使用便利方便

而当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。**雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。**如图 2，将地域维表又分解为国家，省份，城市等维表。

它的优点是 :通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

而我经历的项目并不是上述两种情况，而是由于数据量的巨大，查询性能的高要求，选择建立多张无关联却拥有同一主键的大表。 我们为了避免关联表，减少查询数据所需的时间。将每一次查询任务获取的内容都定义成了一张大表。这样极大地增大了数据的冗余，但却也极大地提高了查询的时效。 同样的，这种情况也是很符合我们项目本身的数据内容特点的，这个因为申请专利以及查询数据的场景不同就不多展开来讲了。